Simulation

Simulation in Modeloop is not an approximation of your future system — it executes the same model, under the same fixed-step semantics, that code generation will ship. This page covers the practical workflow: configuring a build, feeding inputs, running, and reading the results.

Build configuration

A simulation runs a build: what participates, and the scheduling decisions that bind it together. In the build configuration you choose:

1. What participates. A single model in isolation — even a flat one — or the full multi-model system.
2. The scheduling order. Tasks activated at the same solver tick execute in this explicit order. It is part of the design — review changes to it like model changes.
3. Timing. The solver’s base step and the simulation duration. Each periodic task’s period is defined on the task itself (default sample time is 10 ms; resolution is microseconds).

When you press Run, Modeloop compiles the build, executes it, and streams results back. There is no separate “prepare” step to keep in sync.

Scenario profiles

Model inputs are driven by scenario profiles — time-varying generators evaluated by the solver at every step and published to the input signals.

Profile	Parameters	Behavior
constant	value	Fixed value for the whole run
sine	amplitude, frequency, offset, phase	offset + amplitude · sin(2π · frequency · t + phase)
ramp	initial_value, slope, start_time	Holds the initial value, then increases linearly from start_time
step	initial/final value, step time	Discontinuous jump at a configurable time
table	list of (time, value) points	Linear interpolation between points — arbitrary test waveforms

Profiles are per-input and per-scenario, so one model can carry a library of scenarios: nominal operation, limit conditions, fault injection. table profiles are the general escape hatch — measured data or hand-crafted edge cases replayed exactly.

Choosing profiles for verification

• constant — steady-state behavior, operating-point checks.
• step — transient response: rise time, overshoot, settling.
• sine — frequency response, attenuation, phase lag.
• ramp — rate-dependent behavior, saturation onset.
• table — recorded drive cycles, regression fixtures, fault sequences.

Execution

Each solver step follows the fixed sequence described in The Solver:

1. Scenario profiles are evaluated at the current time and published.
2. Due tasks execute in scheduling order; each reads the latest value of its inputs, computes in data-flow order, and publishes its outputs.
3. Logged signals are recorded into traces.
4. Time advances by the base step.

Determinism is total: same model, same scenario, same timing — same trace, every run, on every platform.

Results

Every published signal can be logged and inspected:

• Interactive plots — signal traces over time, directly in the environment.
• CSV export — logged signals with their timestamps, named by signal, for external analysis in Python, MATLAB, or a spreadsheet.

Because signal names flow through unchanged from the model, a well-named model (guidelines) produces self-describing exports.

Runtime diagnostics

While the simulation runs, Modeloop validates the values the model publishes. At every step, each published output is checked for:

• NaN — not-a-number, typically from 0/0, sqrt of a negative, or log of a non-positive value;
• Infinity — overflow of floating-point range, typically a division by zero or an unstable feedback loop;
• Numeric overflow — values exceeding the representable range of the signal’s declared type.

When a check fails, Modeloop does two things:

1. Reports a diagnostic issue with the error code, the offending signal, the value, and the simulation time — so the defect is precisely located.
2. Substitutes a safe value (0.0) for the corrupted output before publishing, so one fault does not cascade NaNs through every downstream component and destroy the entire trace.

The substitution is a containment measure, not a fix. A clean run reports zero diagnostics; treat every reported issue as a model defect to investigate — usually a missing domain guard or saturation (robustness guidelines).

From simulation to target

When the model behaves correctly in simulation, the next steps are systematic: turn your scenarios into test specifications with assertions and run them against the real generated code, and let formal verification prove the properties testing can only sample. Because simulation and generated code share one execution model — fixed-step timing, deterministic data-flow ordering, last-value communication — validated simulation behavior carries over to the generated Python and C without re-verification of the semantics.