Blog

Model Based Development Code Generation: Best Practices & Mistakes to Avoid

· Model Based Development

As embedded systems grow more complex and deadlines get tighter, automatic code generation has become a cornerstone of Model-Based Development (MBD). Done right, it delivers faster development, fewer bugs and certification-ready code. Without the right practices, though, you can end up with bloated, unoptimised code that is tough to debug.

This post covers the best practices and common pitfalls of code generation in MBD, with tips and tools to help you go from model to machine with confidence.

What is code generation in Model-Based Development?

In Model-Based Development, engineers design algorithms and control systems using graphical models, typically in tools like Simulink or SCADE. These models are then automatically converted into C/C++ code for deployment on microcontrollers, ECUs or real-time processors.

Think of it like translating a Lego model into precise CNC machine instructions. It automates the build without compromising the design.

Why code generation matters

Traditional hand-coding is slow and error-prone, requires deep hardware knowledge and lacks traceability to requirements. Automatic code generation speeds up development, reduces manual errors, ensures consistency with the models and supports safety compliance (for example ISO 26262 and DO-178C).

The quality of the generated code still depends heavily on how your models are designed and configured.

Best practices for code generation in MBD

These practices keep generated code robust, clean and efficient.

1. Design for code, not just simulation

Many engineers build models for simulation only, and forget that simulation-friendly features such as continuous blocks or floating-point math may not suit embedded code.

Design using discrete-time blocks, fixed-step solvers and hardware-compatible data types (int16, uint8, etc.). You can use the Embedded Coder Advisor tool in Simulink to validate model settings for code generation.

2. Use strong naming conventions and signal labels

Code readability matters, even for auto-generated code. Poorly named blocks can result in cryptic variable names like rtb_Gain1_f. To avoid this:

  • Use descriptive block names.
  • Label inputs and outputs clearly.
  • Prefix subsystems consistently (for example CTRL_, SENS_).

Readable code helps with debugging, documentation and code reviews, even if you did not write it manually.

3. Modularise with reusable subsystems and libraries

Large monolithic models lead to huge, unmanageable code files. Instead:

  • Use library blocks, subsystems and model references.
  • Encapsulate functional units (for example PID, filters, diagnostics).
  • Enable code reuse across projects and teams.

Think of each block as a microservice: clear input and output boundaries improve maintainability.

4. Choose the right code generation settings

Tool settings affect performance, memory usage and compliance. Make these choices deliberately:

  • Optimise for speed, memory or readability based on the target hardware.
  • Enable function partitioning, inlining control and code replacement libraries.
  • Choose MISRA C or certification-compatible options for safety-critical systems.

Simulink Embedded Coder and dSPACE TargetLink offer fine-grained control over these settings.

5. Simulate first, generate later

Always simulate your model under real-world conditions before generating code.

  • Perform Model-in-the-Loop (MiL) testing.
  • Use assertions, test harnesses and signal logging.
  • Validate boundary conditions, saturation behaviour and fail-safes.

Catching simulation bugs before they become code-level bugs is cheaper and faster.

6. Validate with Software-in-the-Loop (SiL)

Once the code is generated, run Software-in-the-Loop (SiL) to confirm functional equivalence with the model.

  • Compare simulation output with generated code output.
  • Use coverage tools to test logic completeness.
  • Automate SiL in CI pipelines (for example Jenkins, GitLab CI).

If SiL does not match, your generated code may not reflect the intended behaviour.

7. Profile performance on target hardware

Generated code may behave differently under real-time constraints.

  • Profile task execution times.
  • Check for CPU overload or memory bottlenecks.
  • Use hardware debuggers (ST-Link, J-Link) for runtime analysis.

Tools like Simulink Real-Time, dSPACE and Speedgoat help with real-time testing.

Common pitfalls in MBD code generation

These are the mistakes to avoid.

1. Overusing floating-point math on low-end MCUs

Many MCUs lack floating-point units (FPUs), so using double or float types can slow execution dramatically. Use fixed-point math, int16 or uint8 where appropriate. Tools like Fixed-Point Designer in Simulink help with data type scaling.

2. Hardcoding constants and magic numbers

Hardcoded values lead to inflexible code. Define constants in a Data Dictionary, MAT-files or Model Explorer for easy tuning and code reuse.

3. Ignoring loop timing and task deadlines

Generated code might miss real-time deadlines if it is not profiled correctly. Estimate Worst-Case Execution Time (WCET), use Rate Transitions and configure sample times properly.

4. Skipping traceability

Without linking code to requirements, you will struggle with audits or certification. Use Simulink Requirements, DOORS or Polarion to establish end-to-end traceability.

Summary: the best code comes from smart models

Code generation in MBD is not just about pressing a button. It is about designing models with code in mind, testing thoroughly and configuring tools correctly. When done right, you go from weeks to minutes for controller software updates, from handwritten bugs to tested and validated code, and from isolated development to full traceability and compliance.

Finally, do not treat models as prototypes. Treat them as products. Your model is not a rough sketch; it is the source of truth that defines your product's behaviour, so design it like production software: modular, readable, testable and maintainable.

Watch our workshop videos on the Reynlab YouTube Channel. You can also explore our automotive training programs at www.reynlab.com/our-courses.