Skip to content
LunCo / Platform / System-level co-simulation
For systems engineers

See subsystem interactions before integration does.

System-level simulation is where the vehicle, its continuous models, the environment, and mission behavior meet. LunCoSim connects those parts through explicit named ports so the decision is made against the assembled system.

USD scene topologyModelica equationsAvian mechanicsRhai mission policy
LunCoSim system-level co-simulation Four engineering layers connect through a shared named-port boundary to one mission result. ONE STUDY / MANY PARTICIPANTS USD sceneidentity · topology · frames Modelica modelsequations · controls · sensors Avian physicsbodies · joints · contacts Named portsinputs · outputsconnections · timing Missiondecision Rhai policy reacts to events
The point is the coupling. A model that passes alone is not yet evidence that the assembled mission behaves as intended.

The integration gap is a modeling problem.

Teams often have a dynamics model, a controls model, a vehicle assembly, and a mission script. The expensive failures happen between them: mismatched frames, stale signals, hidden assumptions, and behavior that only appears when the pieces run together.

01 / ASSEMBLE

Keep structure and behavior traceable.

OpenUSD carries the composed scene identity, hierarchy, references, and connections. Modelica carries continuous equations and control math. Each layer has a job, and the connection between them is inspectable.

02 / COUPLE

Exchange values at declared boundaries.

The co-simulation runtime exposes named scalar ports and explicit SimConnections. Model outputs propagate to physics inputs, physics observations return through the same boundary, and held values have a declared communication point.

03 / OBSERVE

Diagnose the wire, not only the plot.

CosimStatus, ReadPorts, and GetBrokenConnections let an engineer inspect whether a participant exists, whether values are changing, and where a connection is unresolved.

04 / DECIDE

Test the system question that matters.

Run the assembled vehicle or mission, then change the parameter or connection that drives the decision. Use specialist CFD, FEA, or qualification workflows when their fidelity is what the decision requires.

A practical system-level study

Start with the engineering question, not a catalog of models.

01 / Define

Name the mission outcome

Choose the requirement or CONOPS decision: touchdown margin, traverse completion, power state, or a behavior transition.

02 / Compose

Assemble the participants

Reference the vehicle and environment in USD, attach the relevant Modelica programs, and author the connections at the assembly boundary.

03 / Verify

Inspect the live exchange

Check the composed ports and diagnostics before interpreting a result. A pretty scene is not proof that a subsystem is connected.

What the study puts in one place.

The useful result is a connected engineering question that can be inspected from the scene definition to the live exchange.

System definition
The scene describes the vehicle, environment, participants, ports, and connections that make up the study.
Physical behaviour
Modelica carries continuous equations while rigid-body physics carries mechanics, contacts, joints, and forces.
Mission behaviour
Rhai scenarios express objectives, tasks, events, and responses through the same commands and observations used by the rest of the application.
Engineering evidence
Ports, diagnostics, telemetry, and generated model source let the team trace a result back to the assembled system.

Start with the interaction hidden between subsystem tests.

Read the engineering rationale in Why subsystem models pass while the mission still fails, then download the platform and build the study around the decision at hand.