Control system co-simulation with multibody and FE models, from MIL to SIL
A controller tuned on a rigid, ideal plant fails where the machine is flexible, sampled and stiff. How a checked closed loop of controller, multibody dynamics and finite element modes, linked by FMI, finds that before the first power-up.
Control system co-simulation runs your controller against a multibody or finite element model of the machine it drives, so that gains, sample times, limits and fault handling are proven in a closed loop before the hardware exists. We build that loop as a checked workflow, from model-in-the-loop to software-in-the-loop, with flexible modes, actuator and sensor dynamics and the exchange step all inside the model.
The controller passed every test at the desk. At first power-up the arm rings, the drive saturates, and the commissioning engineer turns the gains down until the machine is safe and slow. The model had a rigid arm, an ideal motor and a continuous-time controller; the machine has none of those. The programme loses rig time, a software freeze behind mechanical rework, and any claim about how fast the machine can go. Which of these failures could a desk model have shown, and which model?
Why does a controller that works on a rigid model fail on the real machine?
Because the loop contains everything between controller output and measurement. A multibody plant is a set of differential-algebraic equations, M(q)q̈ + ΦqTλ = Q(q, q̇, u, t) with constraints Φ(q, t) = 0, where u is the actuator command. A controller with sample time Ts reads yk at tk = kTs and holds uk = C(yk) until the next sample. Gains are chosen so that the loop gain falls through one at a crossover frequency with phase margin to spare, and every element adds lag there: actuator bandwidth, sensor filtering, sample and hold, and the computation delay of the code.
Flexibility is what the rigid model removes. An elastic link, shaft or frame gives the plant modes, each a lightly damped oscillator in modal coordinates, η̈ + 2ζωη̇ + ω²η = modal force. Whether a mode is harmless depends on where the sensor sits. A collocated pair, sensing where and in the direction the actuator pushes, behaves passively: the mode shows as a resonance then an anti-resonance, and the phase stays bounded. A non-collocated pair lets a mode add up to a half turn of phase at its own frequency, and near or above the crossover the loop can go unstable. A tool-centre sensor on a flexible arm, or a load encoder behind a compliant gearbox, is non-collocated.
- Rigid-plant loop gain. A controller designed on the rigid plant sees a smooth gain falling through one, with comfortable phase. This is the picture a rigid-body model gives.
- Flexible mode. A mode from the finite element model adds a narrow resonance. If the peak reaches the gain-one line the loop can go unstable, and a non-collocated sensor lets the mode add up to a half turn of phase there.
- Crossover. The frequency where the loop gain is one. Phase margin is read here, and it is the budget that actuator, sensor, sample and exchange lag all draw on.
- Step and sample lag. The held command and the computation delay add phase lag that grows with frequency. The gap between the curves is the exchange step and sample time taken out of the margin.
- Frequencies the step cannot resolve. Beyond roughly half the exchange rate a co-simulation cannot represent the signals. A mode in or near this region is aliased or ignored, so the loop must not depend on it.
- A stiff plant. Slow rigid-body motion and the fastest retained mode span a wide range of time scales. That spread decides the solver: explicit methods need a small step, implicit ones damp what they do not resolve.
How do exchange step size and stiffness break a co-simulation?
In co-simulation the plant and the controller are separate simulators that exchange signals only at communication points. The FMI 3.0.2 specification writes the i-th point as ti and the communication step as hi = ti+1 − ti, and says that between points an FMU must assume its continuous inputs change continuously; a discrete change needs an event. An input held over a step lags the ideal signal by about half a step, so the exchange adds roughly ωh/2 radians of phase lag at frequency ω, besides the controller's own delay. The step size is part of the controller model, and a loop with thin margin can pass at one step and fail at the next.
Stiffness comes from the plant. A flexible machine mixes slow rigid-body motion with fast, lightly damped modes, a wide spread of time scales. An explicit integrator is stable only below a step bound that shrinks as the highest mode frequency rises. An implicit one removes the bound at the cost of a solve per step, and it damps the fast modes it does not resolve, which can remove a mode the controller has to meet. The solver is a modelling decision.
Coupling adds its own limit. With explicit exchange each side extrapolates the other's input over the step, and a loop with direct feedthrough, where an output depends algebraically on an input, can go unstable although both solvers are stable alone. The FMI specification says that without declared dependencies the worst case is assumed, every output depending on every input. Gomes, Thule, Broman, Larsen and Vangheluwe name modular, stable and accurate coupling of simulation units as the main research need in their co-simulation survey, which is why we test it in every project.
- Plant FMU. The multibody model, with flexible parts reduced from finite elements, packaged with its own solver. Inside it the solver takes many small steps; outside it, only the signals at the communication points are visible.
- Sensor path. The measurement is not the true state. Filtering, delay, noise and quantisation sit between the plant and the controller, and they add lag at the crossover.
- Controller FMU. The controller as a model (MIL) or as compiled production code (SIL), running on its own sample clock. It reads once per sample and holds its command until the next.
- Actuator path. The command reaches the plant through drive dynamics, a rate limit, saturation and backlash. The plant feels what the actuator delivers, not what the controller asked for.
- Communication points and held command. Fine ticks are the plant solver, bold ticks are the points where signals are exchanged. The held command (solid) lags the ideal one (dashed), so the exchange step h adds phase lag to the loop.
- Master. The co-simulation master sets the communication step, orders the exchanges and can reject a step and return to a stored state when an FMU cannot accept it. It is part of the model that has to be verified.
How do MIL, SIL and FMI fit together in one workflow?
Model-in-the-loop (MIL) runs the controller as a model against the plant model. Software-in-the-loop (SIL) swaps in the compiled production code, so fixed-point arithmetic, saturation order, state machines and scheduling run as they will on the target. Both use the same plant, so the MIL trace is the reference for SIL, and the two must agree to a tolerance you set before either is called verified. Hardware-in-the-loop later runs the controller hardware against a real-time version of the same reduced plant.
The Functional Mock-up Interface connects the pieces. The FMI project describes a free standard that defines a container and an interface to exchange dynamic simulation models as XML files, binaries and C code in a ZIP file, and lists the tools that support it. FMI 3.0 added what controller work needs: virtual electronic control units exported as FMUs, Clocks to control the timing of events and model partitions across FMUs, and early return, an event mode and an intermediate update mode in co-simulation. The System Structure and Parameterization (SSP) standard describes a complete system of FMUs and their parameters in a form tools can exchange.
The plant comes from the tools you already run, such as Simpack, MSC Adams, Ansys or Abaqus, with flexible parts reduced to a modal or Craig-Bampton form; the controller from your own environment or build. We are solver-agnostic and build the harness around them. See our control systems page and the multibody dynamics section.
| Loop | What runs in it | What it finds | What it cannot see |
|---|---|---|---|
| MIL, rigid plant | Controller model, rigid multibody plant | Logic errors, first gains, actuator sizing, cycle time | Flexible modes, sample timing |
| MIL, flexible plant | Controller model, plant with modes reduced from FE | Margin lost to modes, tip vibration, saturation | Behaviour of the production code |
| SIL | Compiled code, same plant | Number formats, state-machine paths, scheduling, drift from the model | Hardware latency, drivers |
| FMI co-simulation across tools | Plant and controller as FMUs from different tools | Interface mismatches, exchange error | Nothing until the exchange step is studied |
| HIL on your rig | Controller hardware, real-time reduced plant | I/O timing, watchdogs, driver faults | What the reduced plant omits |
How should a control co-simulation be built and checked?
Each stage gets a check before the next is trusted. First the plant. Flexible parts are reduced from the finite element model, by component mode synthesis, to the modes the loop can see, and those modes are compared with a modal test of the part or the assembly. The retained set must reach above the frequencies where the loop still has gain, and the check is the frequency response of the reduced plant against the full one along the actuator-to-sensor path.
Second, the loop in the frequency domain: the plant linearised with its modes, closed with the controller, actuator, sensor and delays, and the margins read from that. Third, the time domain, where steps, disturbances and faults meet the saturation, rate limit, backlash and quantisation that a frequency plot cannot hold. Fourth, the exchange: the same scenarios at step h, h/2 and h/4 with matched solver tolerances. The closed-loop metrics must stop moving before a step is accepted, and the accepted step is an integer multiple of the sample time. Fifth, SIL against MIL on the same scenarios. Sixth, validation against rig data, with parameters a drawing does not fix, such as payload, joint stiffness and backlash, sampled so that the margin is a spread, not a point.
Quote margins only from the loop you will run
Where does machine learning help control co-simulation, and where does it not?
- A surrogate plant trained on planned runs of the full multibody and finite element model, so a sweep over gains, payloads and speeds takes minutes. Finalists are re-run in the full co-simulation. See surrogate models for CFD and FEA.
- Constrained gain tuning by Bayesian optimisation on that surrogate, trading settling, overshoot, energy and actuator effort against margin and saturation limits.
- Worst-case search: adaptive sampling of disturbances, payloads and parameters that finds the scenario that breaks the loop.
- Parameter calibration of damping, stiffness and delay from rig data, with a Bayesian fit whose uncertainty the margin then carries. See AI surrogate models you can sign off.
Where it does not help: replacing the stability check. A data-driven plant can match amplitude in the time domain and be wrong in phase near the crossover, and a controller tuned on it looks excellent and fails. The surrogate carries a stated range, its phase is checked against the full model at the crossover and at each flexible mode, and a request outside the range goes back to the full co-simulation. The same runs give the structural loads for durability and fatigue life work.
From one tuning campaign to a control co-simulation capability you keep
The return comes when your own team can change a gain, actuator or payload and read the closed-loop answer, checked the same way every time.
- Physics model. CFD and FEA set up once, as templates: geometry clean-up, mesh, solver settings and post-processing that every later run reuses.
- Validation. Mesh and time-step studies, and comparison with tests or full-scale data, so the model's uncertainty is known before it is trusted.
- Automated runs. Scripted runs over the parameters and operating conditions that matter, on your hardware or in the cloud.
- AI surrogate. A machine-learning model trained on those runs answers in seconds and says how sure it is; low-confidence questions go back to the solver.
- Decision tool. Optimisation, trade-off charts or operating guidance, in a form your engineers and operators use every day.
- Field data. Test, trial and monitoring data flow back to recalibrate the model, so it improves with every project instead of being rebuilt.
- A parameterised plant chain in your existing solvers: flexible parts reduced from FE, joints, actuators and sensors as parameters, exported as an FMU with its dependencies declared.
- A controller harness for your model or compiled code, with exchange step, sample time and solver settings in one configuration and the step study scripted.
- A scenario suite: steps, disturbances, payload changes and faults, with pass limits agreed with you, run on every change, and MIL traces compared with SIL.
- A validation record: modal and frequency-response data from your rig, and the damping, stiffness and delay fitted from them with their uncertainty.
- A surrogate plant with a stated range for tuning sweeps, and a gate that returns out-of-range requests to the full model.
- Handover and training, so your engineers extend it themselves. See our training and software development services.
Questions engineers ask about control system co-simulation
What is the difference between MIL and SIL?
What step size should a co-simulation use?
Can a finite element model sit inside a control loop?
Does FMI work with Simpack, MSC Adams, Ansys and Abaqus?
What do you need from us to start?
If a controller and a flexible machine are on your desk, send us the sample time and I/O list, the actuator and sensor specifications, the plant model or drawings, and any recorded step or frequency response. We will reply with how we would build the loop, which plant fidelity and exchange step we would check first, which measurements would calibrate it and what the first margin study would let you decide. Start with a conversation.
