Co-Simulation with Modelica

An overview of the concepts and objectives of the tutorial.

Functional Mockup Units (FMUs) are standard blocks that can enclose any dynamic model into a standardized interface, allowing for an easy interaction with the components of the importing framework.

While both building and linking to FMUs, it is important to understand how to properly split the model to allow for an effective coupling between the co-simulation environment and the FMU itself.

When it comes to Modelica components, you must also consider an additional conversion: although FMU blocks requires pure numerical signals at their interface, Modelica components are usually connected through “physical” connection. For example, a connection between a spring and a mass appears as a single link, but it internally connects two numerical sub-signals, namely the position and the force.

For this reason, Modelica “physical” connections should be exploded into their underlying numerical signals before being wrapped into an FMU. The Modelica Standard Library already offers these physical-numerical adapters for the various domains (Electrical, Mechanical, etc).

Demonstration of how the engine and load subsystems are split.

The example consists of two main parts: an engine subsystem and a load subsystem. Assume that the latter has to be replaced by an FMU providing the same capabilities, thus identifying a split on the interface between the two subsystems.

How to expose rotation angle and torque.

As previously mentioned, the line connecting the two Modelica blocks is a representation of a proper “physical” connection that, in this case, is carrying two underlying numerical signals: the rotation angle and the torque. You now need to expose these signals to end up having only numerical connections at the interface.

The Modelica Standard Library offers dedicated adapters to be picked depending on the physical domain of the model.

Add the adapters under Modelica > Mechanics > Rotational > Components named TorqueToAngleAdaptor and AngleToTorqueAdaptor.

These adaptors add directionality to the connection. On the Engine subsystem, the TorqueToAngleAdaptor provides the rotational angle (and its derivative) as output, and the Load subsystem takes angle as input and provides torque as output, thus forming a perfect pair.

Although the model could run perfectly fine even by switching sides (AngleToTorque on the left and TorqueToAngle to the right), it is generally preferred to let the main co-simulation framework hold the rotation angle.

The augmented number of connection lines between the two subsystems reflects the internal number of signals passed through the (single) original Modelica connection, while the color is now stating that these signals are numerical Modelica signals. However, a further conversion is needed from numerical Modelica to numerical Activate signals.

Add FromModelica and ToModelica components to the model.

To convert from Modelica to Twin Activate numerical signals, the pair of FromModelica and ToModelica components need to be used. You can find these in Activate > Interfaces but they are also automatically added whenever a link is created between these two types of entities.

These thinner black lines passing the boundaries clearly tell you that the data transferred is of a Twin Activate numerical type. These components have an evident direction.

Wrap the load subsystem into a super block and export as FMU.

It is now possible to wrap the “load” subsystem into an FMU.

First, wrap it into a super block whose perimeter will be the one of the equivalent FMU. It is important to go through this step only when the connections passing the super block boundaries are purely of Twin Activate signal type.

Select Export > Export from the menu ribbon. You can also right-click on the super block and select Code Generation and Export. Select FMU as the Target, and then click Generate.

A similar setup is required while importing an FMU. The leftmost part (the “Engine” subsystem) is identical, while the rightmost is simply replaced by an FMU Twin Activate block (in the palette Activate > >CoSimulation > FMU). The very same connections apply.

This is a discussion of the importance of only one side setting the state of a component or its rigidly-connected neighbors.

The model below shows a very common issue in models built to work as FMUs: the two masses, rigidly connected together, have their positions set by two different sources.

The Modelica compiler will throw an error even if the two position sources have the same numerical values. This is typically signaled by an error of the type “system is overdetermined.”

Although it is clear in a very trivial model, it might come unnoticed in more complex cases, especially when either one of the two subsystems is wrapped inside an FMU.

It is important to make sure that only one of the two sides sets the state of a component or of its rigidly-connected neighbors. Any model that breaks this rule will inevitably incur convergence issues.

To overcome the problem of an overdetermined state, you might soften the coupling between the two subsystems before replacing one part with an FMU. You can add a spring-damper for the mechanical domain, an LC circuit in the electrical domain, etc. In this case, the binding happens through forces and torques (for the mechanical domain) or currents (for the electrical domain) instead of, respectively, position and rotations, or voltages. This solution, however, should be taken only as last resort, for example, when you cannot modify the models.

Although this workaround is not recommended, the following is even less recommended. For the mechanical domain, it is possible to fix the issue by means of a source-sensor pair. The mechanical sources can be used without flagging their exact option. This introduces a sort of softening effect but with the drawback of not having a clear view of its physical meaning.

In some cases, you might need to link an FMU to more than one subsystem.

In this example, two different cases are shown. The first refers to a case in which there is a rigid coupling, the other a soft one.

In the first case, the causality of the subsystems is such that a unique direction can be identified. The leftmost block sets the position at the interface for the second and the second for the third. In this way, the risk of over-determining the state of a subsystem is avoided.

In the second case, on the contrary, both the leftmost and rightmost blocks provide information about a position to the central one. This is possible since the central block provides a soft coupling between the two lateral blocks.