A dynamics model can be correct and a controller can be stable, yet the assembled mission can still fail. A subsystem test asks whether one model behaves under its assumed inputs. A mission study asks whether several models exchange the right values, at the right time, in the right frame, while the vehicle and mission policy change state around them.
The failure is between the models
Integration risk tends to hide in the seams. A wheel model may assume a velocity convention that the vehicle assembly does not provide. A power model may be present in the scene but not connected to the driven load. A guidance model may publish a valid force while the physics participant reads a different port. A mission script may infer touchdown by polling a threshold even though the lander already owns a touchdown event.
Each local test can look reasonable because each local test is answering a smaller question. The system question is different: what does this mission do when these assumptions meet? NASA’s systems engineering guidance treats interface management and interface verification as part of system verification, not as paperwork after the models are finished. That is the right mental model for simulation too.
Make the interface an engineering artifact
In LunCoSim, the assembled USD stage carries identity, hierarchy, references, and topology. A Modelica program carries continuous equations and control math. Rigid-body mechanics remain in the physics participant, and Rhai carries mission policy. The important part is not the list of technologies. It is that the connection between them is explicit.
The co-simulation boundary exposes named scalar ports and SimConnections. A source output is propagated to a target input; observations travel back through the same shared port surface. The runtime can therefore answer questions that a rendered scene cannot:
- Does the participant exist on the composed entity?
- Which named port is connected to the state-writing endpoint?
- Are values changing at the declared communication point?
- Is the connection unresolved, terminal, or merely waiting for the next sample?
CosimStatus, ReadPorts, and GetBrokenConnections expose those checks through the same control surface used by the UI, HTTP API, MCP, and scripts. That makes wiring part of the evidence instead of an assumption hidden behind a screenshot.
Time is part of the contract
Two models can have the same units and still disagree because they do not communicate under the same timing contract. LunCoSim advances the world on a fixed master clock, while participants publish at declared communication points. Outputs are held between points, and a coupled participant must complete its exchange before the shared world crosses the causal boundary.
This timing contract gives each participant a clear exchange point and keeps the causal path understandable. It also gives the team a place to compare the effect of a faster or slower model without hiding the timing assumption inside a wrapper.
What to inspect before believing a result
A useful system-level study has a short evidence chain:
- Start with the mission decision: route completion, touchdown margin, power state, or a behavior handoff.
- Open the composed scene and identify the actual participants and connections.
- Read the boundary ports before interpreting a plot.
- Run the mission behavior through its real control path.
- Change one assumption that matters to the decision and rerun.
Detailed CFD, FEA, thermal qualification, hardware testing, and flight certification answer their own questions. System-level simulation answers an earlier one: whether the interaction between the chosen models and the mission plan is coherent enough to justify the next engineering step.
Where to start in LunCoSim
The system-level co-simulation workflow describes the architecture. For a concrete vehicle question, start with rover mission simulation or powered descent and lander simulation. Each workflow starts from a decision, identifies the connected models, and gives the team a path to inspect the result.