A route is also an energy and thermal decision. Every slope, turn, wheel load, payload activity, and control choice can change the power drawn by a space robot. The resulting heat and battery state can change what the mission is allowed to do next.
When mobility, power, and thermal analysis live in separate studies, those effects are often represented as fixed assumptions. A system-level study turns them into connected variables so the team can see which interaction changes the mission outcome.
A route includes more than geometry
A geometric planner can find a path between waypoints. A mission needs to know whether the vehicle can execute that path with its actual mechanics, resources, and operating constraints. Terrain slope can increase wheel force. Wheel force can increase motor demand. A longer or slower traverse can change the solar and thermal environment. Payload operations can compete for the same energy budget.
The route planner can stay focused on path geometry. The system model needs an explicit boundary for the quantities that affect the decision, so the planner can be evaluated against the vehicle, resources, and operating constraints it will actually use.
What to connect in a first study
- Mobility: terrain, wheel contact, suspension, drive law, mass, and velocity.
- Electrical behaviour: source, storage, bus, motor load, payload load, and measured state of charge.
- Thermal behaviour: dissipated heat, thermal mass, transfer paths, and an operational limit.
- Mission policy: waypoints, pauses, payload tasks, communications windows, and low-margin responses.
- Evidence: route progress, current, energy state, temperature, events, and the reason the mission stopped or completed.
This is a decision-oriented model. Its value comes from connecting the domains that can change the answer, not from adding detail that no one will use.
Why conservation semantics matter
In a physical network, a connection is more than a data copy. Electrical and thermal connectors carry potential-like and flow-like quantities with balance semantics. When the topology changes, the connected equation system should change with it. A new load should affect the network solution; a new heat path should affect the thermal state.
That is why LunCoSim uses Modelica for continuous physical definitions and dynamic schema synthesis for composed networks. The scene defines which components are present and connected. The generated Modelica source carries the component instances, ports, equations, and public outputs that the runtime solves.
What the mission can learn
A connected run can reveal more useful information than a single “distance completed” metric:
- Which terrain segment creates the largest change in demand?
- Does a slower, safer route preserve more energy than a shorter route?
- Does a payload activity need to move to a different part of the traverse?
- Is the limiting condition battery state, heat, communications, or vehicle stability?
- Which measurement or model refinement would reduce the uncertainty most?
The answer can guide requirements, route planning, component sizing, sensor selection, autonomy policy, and the next specialist analysis.
How this maps to LunCoSim
The rover simulation workflow treats traverse completion as a system decision. OpenUSD provides the composed vehicle and terrain identity. The rigid-body path handles motion and contact. Modelica can carry electrical and thermal behaviour. Mission scenarios decide how the vehicle responds to observations and events. The API and telemetry surface exposes the state that an engineer or agent needs to compare runs.
The co-simulation guide explains the interface and timing problem in general. The lunar surface systems article extends the same reasoning from one rover to a growing network of vehicles, power, payloads, and operations.
Use specialist detail where it changes the decision
Detailed battery electrochemistry, CFD, FEA, thermal-vacuum testing, and wheel-soil qualification each answer focused engineering questions. A system-level study carries the behaviour that affects the mission decision into one run, helping the team identify which detailed question is worth answering next.
A route that succeeds only under an ideal load profile is not a robust mission result. A route that fails because the model exposes a thermal interaction is valuable evidence. The system-level model turns that interaction into a concrete engineering question.