A CONOPS explains how a mission is supposed to operate. A simulation becomes useful when that intent can run, pause, fail, and be inspected against a changing world. The practical challenge is deciding which parts belong in physics, which belong in mission policy, and how the two communicate without creating a second source of truth.
A CONOPS names behavior, not implementation
“Land, release the rover, drive to the survey points, and enter a safe state if power or terrain makes the route unsafe” is a mission sequence. The implementation stays open: the descent controller may be a continuous model, touchdown may come from a contact event, and rover arrival may be defined by the mission state.
That separation is healthy. The mission designer should be able to change the sequence without rewriting the vehicle dynamics. The controls engineer should be able to retune a continuous law without hiding a new mission transition inside it. The integration work is the explicit boundary between those decisions.
Keep policy separate from continuous physics
LunCoSim uses Modelica for continuous equations and control math, the physics runtime for rigid bodies and contacts, and Rhai for high-level mission policy. A scenario defines a task tree, objectives, lifecycle hooks, and event reactions, while PID loops, numerical integration, and force mixing remain in their owning models and runtime participants.
This division makes iteration cheaper and review clearer. A policy change is visible in the scenario asset. A model change is visible in the Modelica source. A vehicle assembly change is visible in the USD topology. When a result changes, the team has a better chance of locating the changed assumption.
Use events for mission handoffs
Mission operations are full of transitions: touchdown, engine cutoff, rover release, waypoint arrival, low fuel, or a switch to safe mode. Polling a threshold in several scripts is an easy way to create competing definitions of the same event. It also makes a run difficult to explain after the fact.
An explicit event gives the handoff one name and one owner. A script can wait for or react to the event, while the model or authored scene remains responsible for the condition that produces it. The sequence becomes readable: wait for the lander’s touchdown event, release the rover, start the surface traverse, and stop when the authored objective is satisfied.
Drive the same mission through the API
Keep the mission scenario accessible beyond the renderer. LunCoSim exposes a typed command and query surface used by the interface, HTTP API, MCP, Rhai, and Python helpers. An engineer can start a run, inspect entities, read named ports, check script status, and collect an outcome from the same mission boundary.
This is valuable for more than automation. It gives a reviewer a path to reproduce the study and check the mechanism behind a claim. “The rover moved” is a visual observation. “The authored scenario reached its traverse objective, the vehicle traveled, and the expected event sequence occurred” is a more useful engineering statement.
A small lander-to-rover example
- Compose the surface, lander, rover, and camera in a USD scene.
- Attach the lander’s Modelica guidance and propulsion behavior through typed ports.
- Expose touchdown and landing handoff as explicit mission events.
- Attach a Rhai scenario that waits for touchdown, releases the rover, and drives its waypoint task.
- Observe the run through the API and keep the authored verdict alongside the scenario test.
The mission operations simulation workflow describes this pattern as a product use case. The lander-to-rover tutorial shows the underlying authoring path.
Turn the run into an engineering handoff
An executable scenario gives the team a shared starting point for the next stage of work. It records the mission objective, the sequence of events, the commands and observations involved, and the conditions that changed the outcome. Those records can then guide project-specific validation, operations tooling, hardware tests, and specialist analysis.