Code Generation

Code generation is where the model stops being a design and becomes the product. Modeloop generates two targets from the same model — Python for fast iteration and simulation, and MISRA C:2012 compliant C for embedded deployment — with identical behavior: the Python you simulate and the C you deploy implement the same semantics, verified by the generator itself.

What gets generated

The model hierarchy maps directly onto code artifacts:

Model element	Generated artifact
Task	An independent module: an init function, a step function, private state. The atomic unit of integration.
Model	A wrapper that instantiates its tasks, wires their signals, and enforces execution order.
Build	A system-level driver: scheduler, signal exchange, scenario handling (for simulation builds).

Tasks are export functions by design: each one compiles to functions you can call from any external scheduler or RTOS, with the task’s Model Input / Model Output signals as the interface. You can take a single generated task and integrate it into an existing embedded project without adopting anything else.

Containers generate readable, named private functions rather than a flattened wall of expressions — the generated code mirrors the model’s organization, so a reviewer can navigate it with the diagram open next to it.

The C target: MISRA C:2012

Generated C is designed for safety-critical embedded review processes:

• MISRA C:2012 compliant output. Every type conversion is an explicit cast — nothing converts implicitly. Expressions are fully parenthesized, so correctness never relies on precedence knowledge. Numeric literals carry the correct type suffixes. Only safe standard-library math functions are referenced.
• Static allocation only. All state lives in statically allocated variables — no dynamic memory, no recursion, a fixed memory footprint known at compile time.
• Fixed-bound loops. Vector and matrix operations emit loops with compile-time constant bounds.
• Named constants. User-defined enums become proper C enum types; state chart states become named constants. The code reads like the model.
• Simple control flow. State machines emit plain conditional chains that are easy to review line by line.

Model data in C

• Type declarations for user-defined enums are emitted once and shared across the modules that use them.
• Parameters marked calibration are emitted as addressable symbols in a dedicated build-level calibration unit — stable names for calibration tooling, defined exactly once across the build.

The Python target

The Python target produces clean, dependency-light modules used both for simulation and as reference implementations. Execution order, state handling, initial conditions, and type behavior match the C target — validating one validates the other.

Traceability and integrity

Generated code is a verification artifact, not just an output:

• Traceability — generated code carries structured comments linking code sections back to the blocks that produced them. Every line answers “which part of the model asked for this?”, which is what code review and safety audits need.
• Integrity — generated artifacts are fingerprinted, so any manual edit to a generated file is detectable. Generated code should never be hand-edited; change the model and regenerate.
• Equivalence — the generator verifies that its output faithfully implements the source model before handing it to you, catching would-be translation defects instead of shipping them. See Formal Verification.

Practical workflow

1. Model and simulate until behavior is verified and diagnostics are clean.
2. Generate — C for the target, Python if you integrate in a Python environment.
3. Integrate the generated step functions with your scheduler/RTOS: call each task’s step function at its declared period, wire the interface signals to your I/O layer.
4. Never edit generated files. All changes go through the model. The model is the single source of truth; the code is its compiled form.