System-level co-simulation is a way to run several specialised models as one engineering study. Each model keeps the knowledge it is good at — vehicle mechanics, power, thermal behaviour, control, terrain, or mission operations — while a coordinating runtime defines how the models exchange state and advance in time.
The purpose is not to merge every discipline into one giant model. It is to make the interactions between models explicit enough to answer a system question.
Why teams use co-simulation
A subsystem model usually has a clear owner and a clear purpose. A dynamics team may own the rigid-body equations. An electrical team may own the battery and load model. A controls team may own a controller. An operations team may own the mission sequence.
The mission, however, depends on their combination. A steering command changes wheel forces. Wheel forces change motor demand. Motor demand changes power and heat. The power state changes which activity can happen next. The mission procedure responds to an event or asks an operator for a decision.
Co-simulation creates a place where those dependencies can be tested without pretending that every discipline has the same solver, timestep, or modelling language.
The four parts of a useful co-simulation
1. Participants
Participants are the models or engines that contribute behaviour. In a space-robotics study they may include a Modelica physical network, a rigid-body physics engine, a sensor model, and a mission-policy runtime.
2. Interfaces
Interfaces define what can cross a boundary. A named port might expose force, position, current, temperature, sensor validity, or a mission event. The interface belongs to the model contract, not to a one-off script that happens to read a value.
3. Connections
Connections state which source feeds which target. They make ownership and direction visible. They also give diagnostics a place to report missing, incompatible, or broken links.
4. Time coordination
The coordinator decides when participants exchange values and how held values are treated between communication points. This is part of the physical meaning of the study. A controller, vehicle, and energy model cannot be considered connected if they silently use inconsistent time assumptions.
The coordination contract
Several programs can exchange numbers and still leave the engineering meaning unclear. A useful co-simulation gives the team a shared contract:
- What does each signal mean, and in which frame or unit?
- Which participant owns the state?
- Who advances time, and what happens when a participant is late?
- Are a connection and its conservation law represented in the model?
- Can the team trace a runtime signal back to the authored component?
These questions are why system-level simulation is a modelling and architecture problem, not only a software-integration problem.
How LunCoSim uses the idea
LunCoSim exposes named scalar ports through a shared surface used by the co-simulation graph, API, inspector, scripts, and Python. Modelica participants publish declared inputs and outputs. Avian rigid bodies, joints, and sensors contribute their own port families. Explicit connections propagate values and forces through a fixed-step world and the declared participant communication periods.
For connected physical networks, the composed USD facts can be projected into generated Modelica source. This lets topology and identity remain authored in the scene while continuous equations remain in Modelica. The runtime coordinates that participant with the rigid-body and mission-policy participants through declared ports and communication periods.
Read the system-level co-simulation solution page for the workflow and Why subsystem models pass while the mission still fails for the engineering motivation.
When to use it
Co-simulation is useful when a decision depends on more than one model and the interaction deserves an explicit, repeatable study. Examples include:
- rover traverse and energy margin;
- lander descent, touchdown, and surface deployment;
- payload operation during a constrained power or communications window;
- robot autonomy under changing sensor or vehicle conditions; and
- surface infrastructure planning involving vehicles, resources, and operations.
When a question belongs entirely inside one specialist model, that tool is the right place to answer it. Bring its result into the system study when it affects the mission decision.
The outcome is a better boundary
A successful co-simulation gives the team a shared, explicit boundary: what is connected, what is exchanged, when it is exchanged, and what evidence the run produces. Each model can keep the level of detail appropriate to its engineering question.
That boundary is what allows a mission team to compare configurations, expose integration failures, and decide which detailed analysis or hardware test should happen next.