This example shows how to use co-simulation and signal compensation for interfacing signals.
In co-simulation, components (slaves) have their own local solver. During simulation, local solvers maintain their own time by integrating from the previous step to the current step using the data exchanged between components at the previous step.
Simulink (master) serves as an integration platform and performs data exchange between slaves. Slaves do not expose their internal states to the master. The master treats slaves as discrete blocks that exchange data at discrete time intervals.
Connecting these co-simulation components does not form an algebraic loop. Instead, it introduces one-step delay during data exchange. This one-step delay can cause simulation to be less accurate or unstable.
To mitigate this issue, Simulink automatically identifies interfacing signals between these components. These signals are ideally continuous quantities that must be sampled due to co-simulation. To achieve better co-simulation stability and accuracy, Simulink performs numerical compensation on these signals. A 'gear' icon displays on the affected component to indicate this.
This example shows how to perform numerical compensation for three standalone mass-spring components (two implemented in C-MEX S-Function, one implemented using FMU Co-Simulation v2.0). These components are connected to form a triple mass-spring system. When you update the block diagram, the numerical compensation icons appear at the input ports.
The monolithic subsystem uses Simulink continuous blocks and is solved using a Simulink solver. It represents a pure form of the triple mass-spring system. Simulating the monolithic subsystem results in the most accurate output. Experiment toggling the numerical compensation behavior of the co-simulation components and compare the output of the co-simulation components with the monolithic subsystem output.