A simulation result is only as useful as the explanation behind it. When a team sees that a rover stopped early, a lander missed a condition, or a mission lost margin, it needs to know which model, connection, parameter, event, and input produced the result.
Traceability is the path from the authored system definition to the evidence observed during the run. It is what turns “the simulation failed” into an engineering question that can be reproduced and improved.
What engineering evidence needs to show
A screenshot can show that a vehicle is in a particular state. Engineering evidence also identifies the scene, active parameters, model that generated the force, controller command, and sensor state behind that image.
Good evidence preserves the relationship between the result and its source. At minimum, a reviewer should be able to identify:
- the composed system and the version of its authored assets;
- the components, ports, and connections that participated;
- the solver or participant boundaries and communication timing;
- the commands, scenario policy, and initial conditions;
- the telemetry and events that describe the outcome; and
- the assumptions and validation limits that still matter.
One source of truth for connected physical models
Traceability becomes difficult when the visual diagram, the generated code, and the runtime graph are three separate artefacts. They slowly disagree: a connector is moved in one place but not another, a label loses its identity, or a plot continues to refer to a solver variable that no longer has a clear physical owner.
LunCoSim’s generated Modelica path keeps the composed USD facts, generated source, diagram projection, and runtime telemetry connected. USD owns the scene topology and identity. A registered Rhai synthesizer emits the Modelica source and connection equations. The compiler and runtime solve that source. The shared signal registry retains canonical paths and metadata for API, plots, and other consumers.
The purpose is practical: an engineer can move from a plotted signal back to the component and system definition that gave it meaning.
Trace the failure through boundaries
When a coupled study produces an unexpected outcome, inspect it in layers:
- Mission layer: What objective, task, event, or operator command was active?
- Control layer: What command was issued, and which observation did it use?
- Physical layer: Which model and state produced the response?
- Connection layer: Which named ports carried the value or force across the boundary?
- Timing layer: At which communication point did the exchange occur, and what value was held between points?
- Evidence layer: Which telemetry, diagnostics, or authored observer records the result?
This is also the right way to debug an AI-generated change. Review the proposed system definition and the generated source before trusting the output. The agent should be able to explain which boundary it changed and which evidence changed afterward.
Traceability makes collaboration cheaper
Teams lose time when every result requires a meeting with the person who ran the model. A reproducible, inspectable run gives systems, robotics, controls, and operations engineers a common object to discuss.
It also improves the boundary with specialist tools. A detailed thermal or structural model can remain authoritative for its domain while the system-level study records which approximation was used at the mission boundary and why. The team can then replace the approximation when the decision justifies the work without discarding the rest of the mission scenario.
How to make a LunCoSim study inspectable
- Author component identity and connections in the scene rather than hiding them in one-off glue.
- Expose every quantity that matters through a named port or declared telemetry channel.
- Keep continuous control and physical equations in their owning model, not in mission scripts.
- Record mission commands, events, and scenario state alongside physical observations.
- Inspect generated Modelica source when a physical network is synthesized.
- Use diagnostics for broken or unavailable connections instead of silently substituting values.
The system-level co-simulation workflow shows the integration boundary. The AI-first simulation article explains why inspectable source and runtime evidence matter when an agent participates in the workflow.
Evidence is a design requirement
Design traceability into the model from the beginning. If a team can identify the signal, event, model, and assumption behind a decision, the system boundary is ready to support that decision and its review.
LunCoSim treats generated source, ports, telemetry, and mission events as part of the simulation product. The result is inspectable evidence that another engineer can reproduce and use to decide what needs to happen next; qualification evidence comes from the project’s verification process.