An AI-first simulator gives an AI agent the same system definition, observations, and control paths that an engineer uses. The numerical solution remains inspectable, and the engineer keeps authority over the model, the run, and the decision.
That is the idea behind LunCoSim. An agent starts with a declarative system definition, helps compose the connected equations, runs the appropriate numerical machinery, and studies the result through a shared interface. AI becomes useful because it can work with the same structure, state, and constraints as the engineering team.
The engineering problem AI must solve
Engineering teams already have models, scripts, spreadsheets, CAD, simulation tools, and mission documents. The harder problem is keeping the definition of the system aligned while the team asks new questions:
- What is actually in the vehicle assembly, and which parts are connected?
- Which equations describe each subsystem and which values cross the subsystem boundary?
- Does changing the topology require a new hand-written wrapper or a new solver integration?
- Can a mission scenario use the same state and events as a human operator?
- When an AI proposes a change, can an engineer inspect the resulting system before trusting its output?
A language model can suggest components, parameters, and experiments quickly. The suggestions become engineering work when they map onto a connected physical system with explicit assumptions, equations, controls, and observations. The shared system definition is what turns an AI suggestion into a study the team can inspect and repeat.
The general solution: separate system definition from numerical solution
There is a deep distinction between what a system is and how a particular solver computes its state. A system definition says that a battery, motor, thermal mass, radiator, and controller exist; it gives them parameters, connectors, equations, and relationships. The numerical solution determines the state trajectory that satisfies those equations under the chosen initial conditions and integration method.
Keeping those concerns separate makes the system easier to change. A different number of motors, an added load, a new radiator, or a moved sensor changes the assembly and its parameters while the numerical machinery remains reusable. An AI agent can reason about that stable space of components and connections instead of rebuilding the simulator for every experiment.
A declarative system model changes the workflow. Components describe reusable physical knowledge. The assembly describes which components are present and how they connect. A compiler or translator derives the solvable mathematical system. The same component can then be reused in a different topology without rewriting its physical law.
Why Modelica matters: the semantics, not the brand
Modelica is useful here because it is an equation-based, object-oriented language for cyber-physical systems. Its value goes beyond the size of its model library. Reusable components can be connected acausally: the component describes the physical relationship, while the assembled system and the tool determine how the equations are solved.
That abstraction fits physical networks because it preserves the meaning of a connection. An electrical pin can expose voltage as a potential and current as a flow. A thermal connector can expose temperature and heat flow. When connectors are joined, Modelica’s connection semantics derive the relevant balance equations: currents sum at an electrical node, and heat flows balance at a thermal node. Each component remains reusable as the surrounding topology changes.
In the LunCo library, this is explicit in the connector definitions:
connector Pin
Real v; // potential: shared across the connection
flow Real i; // flow: balanced across the connection
end Pin;
connector HeatPort
Real T;
flow Real Q;
end HeatPort;The flow variables carry the physical meaning of the connection. They tell Modelica to generate balance equations: current is conserved at an electrical node, and heat flow is conserved at a thermal node. An AI can therefore add a battery or radiator to a model whose energy and flows remain constrained by equations, rather than merely adding them to a visual scene.
This is what makes the definition reusable and the result physically meaningful. Add another load and the network solution changes as the balance equations are solved. Add a thermal mass and radiator and the temperature evolves from the connected heat flows. Change the assembly and the equation system changes with it.
Modelica’s own language materials describe this as mathematical equations that a tool translates into differential, algebraic, and discrete equations; no particular variable has to be selected by the model author as “the answer.” The important engineering outcome is decoupling: physical definitions and topology can evolve without turning every change into a new numerical implementation. See the Modelica language overview and the Modelica connector semantics.
LunCoSim makes the definition dynamic
LunCoSim applies the same separation across a composed mission scene. OpenUSD owns the assembled identity, hierarchy, references, parameters, ports, and topology. The Modelica library owns continuous equations and state. The physics engine owns rigid-body mechanics and contacts. Rhai owns mission policy and event-driven behavior. Rust owns the generic projection, validation, scheduling, and runtime mechanisms.
The important step is dynamic Modelica schema synthesis. The runtime reads the composed USD facts and invokes a registered synthesizer policy. The shipped acausal-network synthesis policy emits a Modelica source document containing:
- the component instances and their source classes;
- typed ports and public boundary ports;
- authored parameters and constants;
- executable
connect(...)equations; - causal bridges where a subsystem crosses into another participant;
- standard Modelica diagram and icon annotations; and
- stable mappings from generated components and outputs back to their USD prims.
GeneratedModelicaSource is the source-and-diagram artifact used by the editor, compiler, runtime telemetry, and API. The simulator compiles this source, and an engineer can read the same document when a result or compiler diagnostic needs explanation. The visual graph and the physical model therefore share one source. The generated Modelica architecture notes document this ownership explicitly.
In practical terms, an AI agent can change the definition of a system—what is assembled, how it is connected, and what mission policy acts on it—while reusing the simulator’s physical and numerical machinery. LunCoSim synthesizes the corresponding Modelica topology, compiles it, and exposes the resulting state through the common simulation boundary.
What this enables in a multiphysics mission
Consider a lunar rover. A useful question is not merely “how fast does the rover move?” It is whether the rover can complete a traverse when terrain interaction, wheel demand, electrical power, heat rejection, sensing, and mission policy interact.
The system definition can contain reusable electrical components such as a battery, solar panel, power distribution unit, and motor facet; thermal components such as a heat load, thermal mass, conductor, and radiator; and a USD/Avian drivetrain that owns the vehicle mechanics. The electrical and thermal networks can remain equation-based and acausal inside their own synthesized Modelica units, while causal outputs such as motor heat cross into the thermal network and mechanical forces cross into the rigid-body participant.
The assembled system turns a route decision into a chain of physical consequences: terrain or control demand can alter motor current; current can alter battery state and dissipated heat; thermal state can affect the next operation; and the mission scenario can respond to an event or loss of margin. Fidelity depends on the chosen models, parameters, timestep, and validation evidence. The architecture keeps those interactions representable and inspectable.
The same idea applies to a lunar lander. Propulsion and guidance equations can be connected to a rigid-body vehicle, propellant mass can affect the vehicle state, sensors can feed the controller, and touchdown can become an explicit event for the surface mission. See the lander simulation workflow and the co-simulation tutorial.
AI is the user of the system definition
Once system definition and numerical solution are separated, AI has a useful role. It can operate at the level engineers think about:
- Start from a decision. “Will this rover reach the survey site with margin?” is a better input than “generate a simulation.”
- Inspect the available definition. The agent reads the scene, components, ports, commands, generated source, and current diagnostics before proposing a change.
- Change the definition or policy. It can compose an asset, adjust a parameter, connect a component, or write a mission scenario through the authored source paths.
- Let the runtime synthesize and solve. Dynamic Modelica schema synthesis derives the connected equation model; the appropriate runtime participant solves it.
- Inspect the result. The agent reads generated source, named ports, telemetry, events, and broken-connection diagnostics alongside the visual result.
- Hand the decision back to a human. An engineer reviews the change, compares expected and failure cases, and manually takes authority when the scenario requires it.
This is why the simulator can be AI-first and human-controllable. AI and human operation share the same system definition and command/query boundary. The human can edit the model, inspect the generated equations, operate the vehicle, change the mission plan, or stop the run. AI accelerates exploration while the engineer remains responsible for the model and the decision.
Keep the physical meaning inspectable
Physical accountability comes from preserving the things that make the system inspectable:
- equations and state remain in the domain models rather than being approximated by mission scripts;
- conservation laws are expressed through domain connectors and generated connection equations;
- topology remains visible in the authored assembly;
- cross-domain coupling occurs through explicit boundaries;
- the generated Modelica source is available for inspection; and
- runtime ports, telemetry, and diagnostics can be checked before a result is accepted.
Detailed CFD, FEA, thermal qualification, hardware testing, and mission-specific verification provide the evidence required for their respective engineering decisions. LunCoSim addresses an earlier systems problem: making the interactions between the chosen models, vehicle, environment, and mission policy executable enough to expose the next decision.
Human authority remains explicit.
Where the authored vehicle and scene expose the relevant authority and control path, a mission can be flown by an autopilot or operated by a human. Possession is the explicit answer to who is driving. A scenario can own high-level policy and yield to manual authority without creating a second hidden controller.
Continuous dynamics remain in Modelica and the engine kernels so that the equations stay stable and reviewable. Manual control means the engineer can operate the exposed vehicle inputs, tune authored parameters, change the system definition, inspect the generated model, override mission policy, and stop or rerun the study when required.
Where LunCoSim fits in the engineering workflow
LunCoSim is the layer where a mission idea becomes an executable system study. An engineer or AI agent can assemble the vehicle and environment, connect the relevant domains, choose the level of detail, and ask a concrete operational question. The simulator then turns that definition into a run whose equations, topology, controls, events, and observations can be inspected together.
That role complements specialist engineering tools. Detailed CFD, FEA, thermal qualification, hardware testing, and mission verification provide domain-specific evidence when it is required. LunCoSim helps teams reach those decisions earlier by making the interactions between vehicle mechanics, power, thermal behavior, sensing, and mission policy visible in one evolving study.
The platform’s leverage comes from keeping the system definition reusable. AI can propose a new assembly, parameter set, or mission sequence; a human can edit the same definition, inspect the generated equations, take manual control, and decide whether the result is credible. Lunar rover and lander missions are the proof domain, while the underlying idea applies to any engineered system whose behavior emerges from connected subsystems.
Where to start
When subsystem models must work as one study, the system-level co-simulation workflow explains the integration boundary. When a CONOPS must become an executable sequence, the mission operations workflow shows how events, policy and live state fit together. The Modelica component index, generated Modelica architecture, and AI agent guide trace the underlying model path.