A lunar rover mission becomes a systems question.

Route completion is only the first question

A rover may reach a waypoint in a kinematic test and still fail the mission it was meant to support. Wheel demand changes with terrain. Current draw changes with load and control effort. Battery state changes the energy available for the next task. Heat accumulates in the drive system. A ridge can remove the communications link at exactly the moment a science product is ready to transmit.

These are not separate questions in operation. They are consequences of the same route, vehicle, environment, and sequence of decisions. A useful mission simulation therefore needs a system definition that lets those domains run together while keeping each model understandable to the engineer who owns it.

The mission study: a rover, a route, and a resource decision

The Summer Space School mission study uses a compact Apollo 15 surface scenario. It places one resource-capable rover on real Apollo 15 terrain, gives the vehicle an authored traverse, and asks it to reach a crater-floor point of interest before returning to the authored start. The route and the rover’s starting identity are defined in the composed scene, so the study tests an actual mission condition rather than a vehicle moving near a convenient visual marker.

The study is intentionally structured as a separate mission model. It is evidence of the workflow and its interfaces, not a claim that the public website package reproduces every terrain and acceptance asset. The value is the shape of the question: whether an operational plan remains viable when the system that executes it is allowed to behave as a system.

One definition, several physical domains

LunCoSim keeps the assembled mission and the equations that solve it connected without making them the same artifact.

• OpenUSD owns the composed scene: identity, hierarchy, references, parameters, ports, and the authored route.
• Modelica carries continuous equation-based behavior for domains such as electrical and thermal systems. Dynamic schema synthesis derives the connected Modelica topology from the composed system.
• Rigid-body and terrain mechanics determine motion, contact, wheel interaction, and the vehicle state produced by the route.
• Rhai mission policy expresses objectives, phases, autonomy, observations, and the response to events.

This separation matters because it lets the same mission definition be inspected and changed at the level of the decision. Adding a load changes the energy network; changing the route changes vehicle demand; changing a policy changes what the rover does with the resulting state. The solver still handles the equations and the mechanics. A mission script does not become a hidden substitute for continuous control math.

What the run checks

A mission study earns trust when it produces evidence for each interaction that matters to the decision. The compact Lunar Shift acceptance slice checks the following paths automatically:

Why dynamic Modelica synthesis is useful here

Electrical and thermal behavior become difficult to maintain when every new assembly requires a hand-written model and a second set of connections. Dynamic synthesis changes the ownership boundary. The runtime reads the composed USD facts, selects a synthesis policy, and emits the Modelica source for the components, typed ports, parameters, connection equations, and cross-domain bridges that the assembled mission requires.

That generated source is not an invisible intermediate. It is the shared artifact used by the editor, compiler, runtime telemetry, and API. An engineer can inspect which components were generated, how they were connected, and where a diagnostic belongs. The system definition can evolve without turning every topology change into a new numerical implementation.

The result is useful because it remains inspectable

The study does not turn one successful run into a certification claim. Its purpose is earlier in the engineering workflow: expose whether the chosen route, models, controls, and resource assumptions interact in the way the team expects. Detailed terramechanics, specialist thermal analysis, CFD, FEA, qualification, and hardware tests still provide the evidence needed for their domain decisions.

What LunCoSim contributes is a common executable definition in which those system interactions can be explored before they are buried in separate spreadsheets, scripts, and subsystem demonstrations. The mission team can inspect the topology, generated equations, policy, telemetry, events, and result together; an AI agent can propose and compare changes through the same model boundary; and a human can edit the definition, take manual control, stop a run, or reject an assumption.

Start with the decision, then download the platform

The rover simulation workflow focuses on traverse, mobility, power, and autonomy. The power and thermal article explains why resource margins belong in the same study. The mission operations workflow connects objectives, events, and operator handoffs.

For the software itself, download LunCoSim, follow the documentation, and keep the first run tied to a decision the team needs to make. That is where a simulator becomes an engineering instrument rather than another isolated demonstration.