Hristo Hristoskov

Picture a mobile machine during testing. An experienced operator makes a movement and notices something immediately. It feels a little too aggressive. Perhaps it overshoots slightly before settling, or the transition does not feel as smooth or predictable as expected. A control system engineer looks at the implementation.

Not long ago, trying another approach could require a significant amount of work: study the problem, modify the algorithm, review the change, compile it, deploy it, find another machine test slot, and ask the operator to reproduce the situation. Now the first part of that process can look quite different. The engineer may ask an AI coding assistant to propose a modification that reduces the overshoot, smooths the transition, or takes a different structural approach. A plausible alternative can appear quickly.

That implementation is not automatically correct. It still needs to be understood, reviewed, and verified. But producing the next candidate may no longer be the slowest part of the loop. AI assistance increasingly extends beyond implementation as well. Tools can help create tests, suggest edge cases, analyze failures, and work with test results. So the interesting change is not simply that we can write code faster. More of the engineering experiment can potentially become faster.

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.

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.

Continuous integration (CI) is a crucial practice in modern software development, helping teams maintain code quality and catch issues early. In the control systems world, concepts like model-in-the-loop (MIL), software-in-the-loop (SIL), and hardware-in-the-loop (HIL) are widely used to validate and verify control algorithms before deploying them to real hardware. In this blog post, we will explore how to integrate simulation-based testing into your CI pipeline for process-based code.

I am starting this blog series with one of the simplest processes I could imagine. We do it every day and rarely stop to think about how it actually happens.

Take a glass, open the tap, and when the water level is high enough, close the tap. It sounds simple. It feels simple. Yet if we try to explain this process precisely enough for a machine to do it automatically, it turns out to have real structure underneath — the same structure engineers use to control much bigger things, like a thermostat keeping a room at the right temperature or a cruise control keeping a car at the right speed.