What Level of Simulation Do You Really Need?
If you're developing control system software today, you have no shortage of ways to simulate and test it. You can write unit tests, build a higher-level engineering model, run an application in a simulated controller environment, model the physics of a machine, place that machine in a virtual environment, emulate an embedded target, connect a real controller to HIL, or test on the machine itself.
All of these approaches can be useful. The more interesting question is not which simulator is the most capable, but:
What are you actually trying to understand?
That question matters because simulation is not only about how much of the system we reproduce. It is also about the abstraction at which we choose to represent the problem. A unit test may be enough to verify a calculation. A higher-level model may be the right place to design a control concept. A physical model may be necessary when hydraulics or mechanics dominate the behavior. And sometimes the production implementation already contains the behavior we need to investigate.
The table below is not a ranking, and the products listed are not necessarily direct competitors. It is a map of different starting points and the kinds of questions they help answer.
| Approach | Examples | What it helps you understand |
|---|---|---|
| Unit testing | GoogleTest, Catch2 | Individual calculations, conditions and module behavior |
| Code-first control system simulation | CppModel | How the production implementation behaves over time |
| PLC engineering & simulation | CODESYS, Beckhoff TwinCAT, Siemens PLCSIM | Running, debugging and observing controller applications in a simulated controller environment |
| Model-Based Design | Simulink, SCADE | Control design and behavior represented at a higher modeling abstraction, including model-based development and code-generation workflows |
| Physical/system modeling | Simscape, OpenModelica | Interaction between control and physical processes |
| Robotics/environment simulation | Gazebo, Webots, CoppeliaSim | Motion, sensors, physics and interaction with a virtual environment |
| Embedded platform simulation/emulation | Renode, QEMU | Software behavior in the context of simulated or emulated target hardware |
| Distributed embedded-system simulation & test | Vector CANoe | Software, ECU, communication and distributed-system behavior |
| Hardware-in-the-loop | HIL platforms | Real controller hardware interacting with a simulated process |
| Real-machine testing | The machine itself | Actual machine and process behavior |
The part of this landscape I want to focus on here is control system software and the behavior it creates in processes, machines and mechanisms.
CppModel starts from a deliberately simple premise: the code is the model. Instead of first creating a separate representation of the control system, it works directly with the production implementation—which in embedded and machine control is often C or C++—and observes its behavior over time. CppModel currently supports this approach for production C and C++ code.
This does not mean that the production implementation is always the only model we need. It means that when the behavior we are interested in is already expressed there, we can start there rather than first rebuilding the same logic at another abstraction level.