![\"CppModel](\"https://www.cppmodel.com/assets/images/velocity-ramp-max-acceleration-4-ab3947874b696b24521fc7816c87f0e5.png\")
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.
\nNot 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.
\nThat 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.
\nSuppose we produce three alternative implementations. One reduces the overshoot but makes the machine feel sluggish. Another settles quickly but introduces more aggressive acceleration. A third stays close to the original behavior while removing the sharpest part of the transition. Which one is better? There is no answer hidden in the source code. The answer depends on intent: performance targets, safety constraints, mechanical limitations, energy consumption, operator comfort, and probably several other considerations.
\nSome of that intent is captured in requirements. Some may be represented in models and tests. Some exists as engineering knowledge that has never been formally written down. And sometimes an experienced operator notices something that none of them captured. If an operator says, \"This doesn't feel right,\" even though the existing checks pass, that observation should not simply be dismissed. It may expose a missing requirement, an incomplete test, or behavior that the current model does not represent sufficiently well.
\nCode is executable, but that does not make code the definition of correct behavior.
\nControl system engineers already have mature ways of learning about behavior before or alongside testing the final machine. Model-Based Development, Software-in-the-Loop, Hardware-in-the-Loop, virtual controllers, and many other forms of simulation exist precisely because experimenting directly on the physical system can be expensive, slow, or difficult to repeat.
\nThere are also development environments where the feedback loop can already be very short. Engineers working with PLC environments such as CODESYS are often accustomed to changing logic, downloading it, and observing what happens on the machine during commissioning. That immediacy can be extremely useful. Teams moving more functionality into C or C++ can lose some of that feeling if the development process becomes edit, compile, deploy, and wait for access to the machine. Simulation offers another possibility: move some of that exploration away from scarce machine time while keeping a short feedback loop around the implementation. AI does not invent that idea, and it does not make established simulation and testing methods obsolete. What it may change is how frequently and cheaply we can move around the loop.
\nWe do not necessarily need to modify and recompile the control algorithm every time we want to learn something. If inputs, parameters, and test conditions can be supplied externally, the same snapshot of the implementation can be executed repeatedly under different conditions. Instead of asking only \"Can I simulate this implementation?\" we can start asking \"Which parameter values produce the behavior we want?\"
\nWe can run parameter sweeps, try different input sequences, compare results, and optimize against measurable objectives without rebuilding the control algorithm for every experiment. The implementation remains fixed while the experiment around it changes. That can make a surprisingly large difference. Once an experiment becomes cheap enough to repeat, we naturally start asking questions that would have been impractical if every attempt required another build, deployment, and machine test.
\nRecorded machine data gives us another way to tighten the loop. Suppose we have logs from a real machine showing inputs and measured responses during a particular movement. Instead of immediately modifying the controller until the simulated result looks better, we can first ask a different question: does our simulation reproduce what actually happened on the machine? If it does not, the limiting factor may not be the control algorithm. Perhaps the representation of the plant is too simple. Perhaps a delay is missing. Perhaps an assumption about the dynamics is wrong.
\nMeasured behavior can provide an anchor while we improve the simulation context until it represents the behavior we care about well enough for the engineering question in front of us. It does not need to become a perfect representation of the entire machine. And a model fitted to one set of logged data should still be challenged against other operating conditions and independent data rather than assumed to be universally valid.
\nOnce the simulation context is credible enough for the question we are asking, we can start changing the controller and exploring alternatives with more confidence that the observed differences are meaningful. This creates another iteration loop. We are not only iterating over code. We can iterate over parameters, inputs, assumptions, and the simulation context surrounding the code.
\nNone of this means every control problem can be solved with a simple simulation. Sometimes a generated input sequence and a plot are enough. Sometimes recorded machine data provides the missing context. Sometimes we need a plant model, Software-in-the-Loop, Hardware-in-the-Loop, or a more detailed simulation. And for many questions, we still need the real machine.
\nReal-machine testing also depends on something that is easy to underestimate: access to the right people. An experienced operator may be able to reproduce or evaluate behavior that a control system engineer cannot. The operator knows how the machine feels under load, which combinations of movements expose a problem, and when a response that looks reasonable in a graph simply does not feel right from the cab. The objective is not to replace that stage. It is to arrive there having already learned as much as we reasonably can, so that valuable machine and operator time can be used for the questions that genuinely require them.
\nThese approaches are not competitors. They provide different kinds of evidence. The engineering task is to understand what question we are trying to answer and what evidence is sufficient to answer it.
\nThat may be the more consequential change. AI can make producing another implementation cheaper. External parameters and inputs can make another simulation run cheaper. Recorded data can make a real situation easier to reproduce. A simulation context can let us investigate that situation repeatedly without occupying the machine. AI can increasingly help create experiments, explore alternatives, and interpret the resulting data. None of these things determines what the machine should do.
\nRequirements still matter. Models still matter. Tests still matter. Engineering judgment still matters. And the operator who says, \"No, that still doesn't feel right,\" may still provide the most valuable piece of information in the entire experiment.
\nWhat changes is the cost of asking the next question.
\nThe opportunity is not merely to write control system software faster. It is to shorten the loop between intent, implementation, behavior, and evidence—and to learn faster about the system we are actually building.
", "url": "https://www.cppmodel.com/blog/when-ai-writes-the-code", "title": "When AI Writes the Code, What Becomes the Model?", "summary": "AI can make the next implementation cheaper to produce. For control system engineers, the bigger opportunity may be making the next experiment cheaper to run.", "image": "https://www.cppmodel.com/img/blog/when-ai-writes-the-code.png", "date_modified": "2026-10-01T00:00:00.000Z", "author": { "name": "Hristo Hristoskov", "url": "https://cedge.se" }, "tags": [ "AI", "Simulation", "Control Systems", "Embedded Systems" ] }, { "id": "https://www.cppmodel.com/blog/what-level-of-simulation", "content_html": "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.
\nAll of these approaches can be useful. The more interesting question is not which simulator is the most capable, but:
\n\n\nWhat are you actually trying to understand?
\n
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.
\nThe 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.
\n| 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.
\nCppModel 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.
\nThis 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.
\nConsider a simple velocity ramp. A machine receives a desired velocity, but we don't want the value sent toward the actuator to jump immediately to the requested value. Instead, we limit how quickly the current value can move toward the target.
\nThe core logic can be remarkably small:
\nstatic float RampStep(float current, float target, float maxDelta)
{
float delta = target - current;
if (delta > maxDelta)
{
return current + maxDelta;
}
if (delta < -maxDelta)
{
return current - maxDelta;
}
return target;
}
There is deliberately nothing CppModel-specific in this function. It is intentionally minimal so the behavior is easy to follow. Production embedded code may use explicit project types, diagnostics, additional checks, saturation handling, and project-specific coding rules such as MISRA C.
\nThe function itself has no concept of time. maxDelta is simply the maximum velocity change allowed during one call. In this experiment the function is executed every 1 ms, so the configured acceleration limit is converted into the corresponding velocity change for each execution step. For example, 2 m/s² corresponds to a maximum change of 2 mm/s per 1 ms step.
Reading the function tells us what happens during one call. What it doesn't immediately show is what happens after hundreds of calls while the requested velocity changes. To see that, let's give it a simple velocity schedule:
\nstatic const VelocityLevel_ts VELOCITY_SCHEDULE[] = {
{0, 50.0f},
{300, 150.0f},
{600, 30.0f},
{900, 0.0f},
};
The requested velocity starts at 50 mm/s, steps to 150 mm/s after 300 ms, drops to 30 mm/s after 600 ms, and finally goes to 0 mm/s after 900 ms. In a short experiment we get acceleration from standstill, another acceleration step, a large deceleration, and braking to zero.
\nThe experiment has three parameters:
\n| Parameter | Purpose |
|---|---|
Max Acceleration [m/s²] | Limits how quickly the actual velocity can change |
Acceleration Window [ms] | Defines the allowed time to reach a higher desired velocity |
Braking Window [ms] | Defines the allowed time to reach a lower desired velocity |
For the runs below, both timing windows are set to 100 ms. The simulation runs for 1.2 seconds with an execution step of 1 ms. Velocity is expressed in mm/s, while acceleration is configured in m/s².
\nThe blue and orange traces mark when the acceleration and braking windows are active. Their height is only used to make the windows visible on the same graph; their duration is represented by the time axis. The validation result is shown below the response, so we can see not only whether a run passes, but where a requirement is violated.
\nThis is the transition from code to behavior that matters here. The function calculates one control step. Execute it every millisecond through a defined scenario and those individual steps become a time-domain response that we can inspect and validate.
\nNow keep the code, input schedule, execution step and timing windows identical and change only Max Acceleration.
With Max Acceleration set to 4 m/s², the controller reaches each requested velocity quickly and comfortably satisfies the configured timing requirements. On a real machine, however, we might decide that such a rapid response is unnecessarily aggressive.
So let's halve the acceleration limit to 2 m/s².
\nThe response is now visibly slower, while the same validation requirements still pass. If this produces the machine behavior we want, we have reduced the aggressiveness without violating the requirement.
\n![\"CppModel](\"https://www.cppmodel.com/assets/images/velocity-ramp-max-acceleration-2-b6a46d74b3677d3846ebf6d3107b4cac.png\")
Both simulations pass, yet they clearly do not behave in the same way. That is an important distinction. A parameter tells us what we configured; the graph shows us what that configuration means for behavior over time.
\nOn a real control system, the same idea extends beyond a simple ramp. We may be interested in filtering, settling, overshoot, oscillation, sequencing, state transitions, or the interaction between several pieces of logic. These are all things that can be difficult to understand from isolated function calls or individual values.
\nWhat happens if we halve the acceleration limit once more?
\nAt 1 m/s², we have gone too far for the requirement we defined.
\n![\"CppModel](\"https://www.cppmodel.com/assets/images/velocity-ramp-max-acceleration-1-failure-0bc90fcc7b0e2dd72c4d353154002e15.png\")
At the 600 ms transition, Desired Velocity drops from 150 mm/s to 30 mm/s. With Max Acceleration limited to 1 m/s², Actual Velocity cannot reach the new target within the configured 100 ms braking window, so the validation fails. The red region below the graph shows where the requirement was violated.
This is where simulation and testing start to complement each other. The test answers:
\n\n\nDid the behavior satisfy the requirement?
\n
The graph helps answer:
\n\n\nWhy didn't it?
\n
That becomes particularly useful in continuous integration. The same scenario can be executed after a change and the requirements checked automatically, but the result does not have to stop at pass or fail. The behavior that produced the result can be preserved as evidence.
\nThe earlier runs show the other side of the same idea. 4 m/s² and 2 m/s² both pass, while their responses are visibly different. Tests tell us whether the behavior satisfies the requirements we thought to encode. Looking at the behavior can also expose differences we never thought to express as assertions.
\nFor control system software, where important behavior develops over time, that context can be as useful as the final test result.
\n\n\nThe function gives us one step. The simulation gives us the behavior. The test tells us whether that behavior meets the requirements.
\n
The complete simulation setup, including input handling, parameters, validation windows and the CI result, is available in the simulation code.
\nThe example above treats the production implementation itself as the model. That is one possible abstraction, but it is not the only one. The same control system can be represented at a higher level, surrounded by a model of the physical process, placed in a simulated environment, or eventually exercised together with real hardware.
\nIn CppModel, that choice is explicit: the production implementation is the executable model. Model-Based Design makes a different choice about where the model lives and at what abstraction level.
\nIn a Model-Based Design environment such as Simulink, the engineering model typically exists at a higher abstraction level. Control behavior can be described using blocks, signals, state machines and other modeling constructs. That representation can be simulated and validated and, depending on the workflow, used to generate production code.
\nThis can be a powerful approach when the engineering model itself is intended to be a primary design artifact. CppModel starts from the other direction: when the behavior is already expressed in the production implementation, simulation, visualization and validation are built around that implementation rather than around a separate representation of the same algorithm.
\nNeither abstraction is inherently the right one. They answer somewhat different development needs. If you want to design and reason about the control system through a higher-level engineering representation, Model-Based Design may be the natural starting point. If the production implementation is the artifact you want to develop, observe and validate, working directly with it can be more direct.
\nPLC engineering environments add another variation. Tools such as CODESYS provide simulation and debugging workflows that are often centered on running the controller application and observing or modifying it much as an engineer would with a live controller. The approach discussed here has a different emphasis: execute a defined scenario over a defined time interval, preserve the resulting behavior, validate it, and make the experiment repeatable in CI.
\nThat distinction is not fundamentally C/C++ versus IEC 61131-3. It is also about how the control system implementation is exercised and how its behavior becomes part of the development and verification workflow. CppModel currently supports C and C++, but the idea of treating the production implementation as the model is not tied to those languages.
\nThere is, of course, a limit to what the production implementation can tell us by itself.
\nSuppose the question is no longer whether the velocity algorithm reaches its target within 100 ms, but how a hydraulic cylinder, flexible structure, or loaded crane actually responds to that command. The missing behavior now lives in the physical system. Hydraulics, mechanics, electrical systems, loads, and other dynamics have to become part of the model. This is where tools such as Simscape or Modelica-based environments such as OpenModelica become appropriate.
\nThe model may need to grow in another direction as well. If we want to understand how a controlled machine interacts with its environment—its motion, sensors, collisions, geometry, or surroundings—we need to represent that environment too. Robotics simulation environments such as Gazebo can provide this context, often as part of a ROS-based development workflow. At that point the question is no longer only what the control system implementation does over time, but what happens when that behavior is placed inside a simulated machine and environment.
\nEventually, some questions depend on the real controller. When the behavior depends on the actual controller hardware, its I/O and electrical interfaces, or sufficiently realistic machine dynamics, HIL can bring the real controller into the experiment. And some behavior can only be established with confidence on the real machine.
\nOther tools extend the engineering context in different directions rather than simply making the physical model larger. Embedded simulation and emulation frameworks such as Renode and QEMU move the focus toward executing software in a representation of the target hardware. Their scope differs—Renode can also model sensors, environments and multi-node embedded systems—but the engineering question is generally closer to how software behaves in its target-platform context. CANoe extends the context around software components, ECUs, communication and distributed systems. Those can be essential engineering problems, but they are different from the process, machine and mechanism behavior considered here.
\nThis is why the approaches in the opening table should not be interpreted as one ladder from simple to advanced. They add different information and operate at different abstractions. The useful question is what information the current model needs in order to answer the engineering question in front of us.
\nCppModel fits when the production implementation contains the model you want to investigate and the question is primarily about its behavior over time. When the answer depends on information the implementation does not contain, we need to add that information or move to another simulation approach.
\nThere is also a much closer alternative to CppModel than many of the tools above: build the workflow yourself.
\nCompile the controller as a library. Write a test harness. Feed it input data. Export CSV files. Plot the results using Python. Add GoogleTest or another testing framework. Connect everything to GitHub Actions, GitLab CI, or another CI system.
\nFor a capable software team, this is entirely possible, and many teams already have some variation of it. The question is not whether it can be done. It is whether building and maintaining the execution, visualization, result comparison and CI infrastructure is part of the engineering problem the team wants to solve.
\nCppModel packages that workflow around the production implementation so the engineering effort can stay focused on developing and validating behavior.
\nThis feedback loop is becoming more relevant for another reason. Modern AI coding tools can generate and modify implementation code increasingly quickly. Asking for another ramp implementation, a different filter, or an additional limit may take seconds. Generating an alternative is becoming cheaper; understanding what that alternative actually does remains important.
\nThat makes the loop increasingly useful:
\nproduction code → change → simulation → behavioral evidence → tests → CI
\nAI can help produce alternatives. Simulation and testing provide a way to understand and validate the behavior those alternatives create.
\nNone of these approaches replaces all the others. A control system may begin with unit tests and code-level simulation, later be exercised together with a physical model, continue through HIL, and eventually be validated on the real machine. Another project may begin with a higher-level Model-Based Design workflow. PLC engineering, robotics simulation, embedded platform emulation and network simulation answer still other questions along the way.
\nThe useful boundary is not a particular tool or language. It is whether the representation we have contains enough information to answer the engineering question in front of us.
\n\n\nUse code-first simulation when the production implementation contains enough of the behavior you need to understand. Move to another abstraction when the answer depends on something the implementation alone cannot represent.
\n
So perhaps the useful question isn't:
\n\n\nWhich simulator is the most powerful?
\n
It is:
\n\n\nWhat's the smallest simulation, at the right abstraction level, that gives me the answer I need right now?
\n
Sometimes that means a higher-level engineering model. Sometimes the production implementation is already enough. Sometimes it means adding a physical system or a virtual environment around it. Sometimes it means HIL or the real machine.
\nThe goal is not to simulate everything. It is to model enough of the right things to answer the question.
\nContinuous 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.
\nUpdated in October 2026 for CppModel 0.9: the build now uses the CppModel CMake package, and the CI workflow no longer installs OpenSSL or zlib.
Traditional CI pipelines focus on unit tests and integration tests, which are essential for ensuring that your code behaves as expected. However, these tests are usually static and focus on a binary result (pass/fail), often lacking the ability to capture the dynamic behavior of your system. MIL, SIL, and HIL testing, on the other hand, let you simulate the behavior of your system under various conditions, providing a more comprehensive validation of your algorithms.
\nWith CppModel, the code you write is the model itself, so you can get significantly closer to MIL and SIL testing — and even HIL testing, if you have access to the hardware — while still staying in the code domain. This makes it easy to integrate simulation-based testing into your existing software pipelines and workflows, so you can catch issues early and break down test results into specific pass and fail time intervals, which is crucial for understanding how your system behaves over time.
\nFor this example, we will follow the process described in the previous blog post How do you fill a glass of water? which is already modeled in CppModel. As the code is already hosted on GitHub, we will use GitHub Actions to set up our CI pipeline.
\nWe will focus on the Glass of Water simulation and prepare a short verification test that checks whether the simulation behaves as expected. To track the simulation result at every step of time, we will use CppModel.StepResult, which captures the current step result and lets us summarize the overall pass/fail status of the simulation. This gives us a clear, easy-to-integrate view of simulation performance in the CI pipeline. To make sure the executable runs as a test in the CI pipeline, we will use CMake's enable_testing() and add_test() functions, which let us run the simulation as part of our CI pipeline and check the results.
Here is the CMakeLists.txt file for the Glass of Water simulation, with the verification source and test setup added. It expects the CppModel library to be extracted into a dependencies folder, which the CI workflow below takes care of:
cmake_minimum_required(VERSION 3.21)
project(GlassOfWater_Project LANGUAGES C)
enable_testing()
list(APPEND CMAKE_PREFIX_PATH \"${CMAKE_SOURCE_DIR}/dependencies\")
find_package(cppmodel REQUIRED)
add_executable(GlassOfWaterSim GlassOfWaterSim.c GlassOfWaterLib.c GlassOfWaterVerification.c)
target_link_libraries(GlassOfWaterSim PRIVATE cppmodel::cppmodel)
cppmodel_deploy_runtime(GlassOfWaterSim)
add_test(NAME GlassOfWaterSim_Test COMMAND GlassOfWaterSim)
I'll break the verification of the process down into three steps:
\nThe goal of this article is to present the CI workflow, so we won't get into the specifics of testing against exact time intervals or specific interface values. Instead, we'll break the steps down based on tap opening and closing. With this in mind, we can implement a simple state machine that initializes in the Pre-filling state and transitions to Filling when the tap opens, then to Post-filling when the tap closes.
\n#include \"GlassOfWaterVerification.h\"
typedef enum
{
PRE_FILLING,
FILLING,
POST_FILLING
} FillingState_t;
static FillingState_t fillingState = PRE_FILLING;
static float previousLevel = 0.0f;
uint8_t PreFillingCheck(unsigned long delta)
{
// Before we start filling, the result is always satisfactory, as we haven't started yet.
return 1;
}
uint8_t FillingCheck(unsigned long delta, float actualLevel, float previousLevel)
{
return (actualLevel > previousLevel && actualLevel > 0.0f) ? 1 : 0;
}
uint8_t PostFillingCheck(unsigned long delta, float actualLevel, float desiredLevel)
{
return (actualLevel >= desiredLevel) ? 1 : 0;
}
uint8_t VerifyGlassFilling(unsigned long cycleTime, float actualLevel, float desiredLevel, float tapOpening)
{
uint8_t result = 0;
switch (fillingState)
{
case PRE_FILLING:
if (tapOpening > 0.0f)
{
fillingState = FILLING;
}
else
{
result = PreFillingCheck(cycleTime);
break;
}
case FILLING:
if (tapOpening <= 0.0f)
{
fillingState = POST_FILLING;
}
else
{
result = FillingCheck(cycleTime, actualLevel, previousLevel);
break;
}
case POST_FILLING:
result = PostFillingCheck(cycleTime, actualLevel, desiredLevel);
break;
default:
result = 0;
break;
}
previousLevel = actualLevel;
return result;
}
The verification keeps its own previousLevel variable with the level from the previous step, which is used to check whether the level is increasing during the filling state.
Now we can use the CppModel.StepResult interface in our simulation code to capture the verification test's status at every point in time. Here is how the cyclic function looks with the added verification logic:
CMODEL_CYCLIC()
{
float dt = self->stepTime_ms / 1000.0f; // Convert milliseconds to seconds
float plumbingFlow = CppModel_getParameterF32(self, \"plumbingFlow [l/min]\", 15.0f) / 60.0f; // Default plumbing flow is 15 liters per minute converted to liters per second
float glassCapacity = CppModel_getParameterF32(self, \"glassCapacity [ml]\", 250.0f) / 1000.0f; // Default glass capacity is 250 ml converted to liters
float openingSlope = CppModel_getParameterF32(self, \"openingSlope [%/s]\", 100.0f) * 0.01f; // Default opening slope is 100% per second converted to a fraction
float closingSlope = CppModel_getParameterF32(self, \"closingSlope [%/s]\", 400.0f) * 0.01f; // Default closing slope is 400% per second converted to a fraction
float desiredLevel = CppModel_getInputF32(self, \"desiredLevel [0.01%]\", 80.0f * 0.01f); // Default desired level is 80%
// Control loop
float error = desiredLevel - actualLevel;
tapOpening = control(dt, openingSlope, closingSlope, tapOpening, error);
actualFlow = actuator(plumbingFlow, tapOpening);
actualVolume = glass(dt, glassCapacity, actualVolume, actualFlow);
actualLevel = sensor(glassCapacity, actualVolume);
CppModel_setOutputF32(self, \"error [0.01%]\", error);
CppModel_setOutputF32(self, \"tapOpening [0.01%]\", tapOpening);
CppModel_setOutputF32(self, \"actualFlow [l/s]\", actualFlow);
CppModel_setOutputF32(self, \"actualVolume [l]\", actualVolume);
CppModel_setOutputF32(self, \"actualLevel [0.01%]\", actualLevel);
uint8_t stepResult = VerifyGlassFilling(currentTime_ms, actualLevel, desiredLevel, tapOpening);
CppModel_setOutputI8(self, \"CppModel.StepResult\", stepResult);
}
As you may have guessed, the simulation was expected to fail in the post-filling state, since the actual level won't exactly equal the desired level once we account for the closing slope on the tap opening — in this case we significantly overshoot the desired level.
\n![\"Failed](\"https://www.cppmodel.com/assets/images/sim-desired-level-fail-2e71d4ff0cd5888b82b088073ad2eb0a.png\")
The overall test result is shown as a failure in the terminal where the executable ran — in my case, a red circle with a cross in it. That's the signal our CI workflow will use to determine pass or fail. Here is what the terminal output looks like when the simulation fails:
\n![\"Failed](\"https://www.cppmodel.com/assets/images/desired-level-fail-7726c5f8180db86180f489fe87f9c7a7.png\")
In real life, nobody complains about a few extra drops of water in the glass, so let's relax the post-filling check to consider the simulation successful if the actual level is equal to or greater than the desired level. This way, the simulation will pass in the post-filling state too.
\n return (actualLevel >= desiredLevel) ? 1 : 0;
Here are the simulation results after the modification:
\n![\"Successful](\"https://www.cppmodel.com/assets/images/sim-desired-level-success-939dcd272a53209b4f2ed2b0fecbe05e.png\")
And just for completeness, here is what the terminal output looks like when the simulation passes (a blue dot in my case):
\n![\"Successful](\"https://www.cppmodel.com/assets/images/desired-level-success-8e645aa88997a79889d26be7cef6517b.png\")
Before we jump into the workflow implementation, let's make sure our simulation won't try to run interactively and prompt for credentials. To do this, we'll store the credentials as GitHub secrets and pass them to the simulation as environment variables, keeping them secure while letting the simulation run non-interactively. By default, CppModel checks whether the CPPMODEL_USERNAME and CPPMODEL_PASSWORD environment variables are set and uses them to authenticate with the CppModel server. If they aren't set, the simulation falls back to interactive mode: it prints a sign-in link and waits for someone to sign in. Setting CPPMODEL_LOGIN_TIMEOUT=0 turns that off, so a missing or wrong login fails the job right away instead of waiting.
Next, we'll create a GitHub Actions workflow that runs our simulation and checks the results. If the CppModel credentials are set, the workflow will automatically submit the results to the CppModel workspace, where they can be observed and analyzed. Since we're focused on simulation-based CI and expect to see those results, we'll add a credential check to the workflow so it fails outright if the credentials aren't set.
\n - name: Verify CppModel credentials are set
env:
CPPMODEL_USERNAME: ${{ secrets.CPPMODEL_USERNAME }}
CPPMODEL_PASSWORD: ${{ secrets.CPPMODEL_PASSWORD }}
run: |
if [ -z \"$CPPMODEL_USERNAME\" ] || [ -z \"$CPPMODEL_PASSWORD\" ]; then
echo \"::error::CPPMODEL_USERNAME and CPPMODEL_PASSWORD secrets must be configured for this workflow\"
exit 1
fi
The next step is to prepare the build environment. For this example we use the gcc16 container image, to which we additionally add git (required for the checkout action) and curl (to download the CppModel library). The library has everything else it needs built in, so there are no other packages to install. For CMake, we'll use the lukka/get-cmake action to install the latest version of CMake and Ninja. Here is how the build environment setup looks:
- name: Install dependencies
run: apt-get update && apt-get install -y git curl
- name: Get latest CMake and ninja
uses: lukka/get-cmake@v3.27.7
Downloading and installing the CppModel library is straightforward: we use curl to grab the latest Linux x86_64 release and extract it into the ./dependencies directory, matching what the CMakeLists.txt configuration expects. Here is how that step looks:
- name: Download and extract the CppModel library
run: |
curl -fsSL https://download.cppmodel.com/CppModel-latest-Linux-x86_64.tar.gz -o cppmodel.tar.gz
mkdir -p dependencies
tar -xzf cppmodel.tar.gz -C dependencies --strip-components=1
rm cppmodel.tar.gz
The final part of the workflow builds and runs the simulation. We'll also add a timeout to this step in case the credentials are wrong or the simulation gets stuck.
\n - name: Run CMake
run: cmake -S . -B build -DCMAKE_BUILD_TYPE=RelWithDebInfo
- name: Build
run: cmake --build build --config RelWithDebInfo --target all
- name: Test
timeout-minutes: 5
working-directory: build
env:
CPPMODEL_USERNAME: ${{ secrets.CPPMODEL_USERNAME }}
CPPMODEL_PASSWORD: ${{ secrets.CPPMODEL_PASSWORD }}
CPPMODEL_LOGIN_TIMEOUT: 0
run: ctest --output-on-failure
Note that the CPPMODEL_USERNAME and CPPMODEL_PASSWORD secrets need to be set in your GitHub repository for this workflow to run: go to Settings > Secrets and variables > Actions > New repository secret and add both.
![\"GitHub](\"https://www.cppmodel.com/assets/images/github-credentials-07d387733f9967d6d2c776805c457cfc.png\")
All that's left is to commit the workflow file and push it to GitHub. Once triggered, the workflow runs the simulation and checks the results: if the simulation fails, the workflow fails and you're notified. If it succeeds, you can view the results under the corresponding user in the CppModel workspace, just as we did earlier.
\nHere is how the workflow looks in GitHub Actions:
\n![\"GitHub](\"https://www.cppmodel.com/assets/images/ci-results-87aab526709829532535d0ce02548e13.png\")
Bringing simulation into CI closes a real gap in how process-based code typically gets tested. A conventional unit test tells you a function returned the right value; it doesn't tell you whether your control loop overshoots, oscillates, or settles cleanly over time. By running the actual model as the test and capturing CppModel.StepResult at every step, you get that dynamic, time-resolved picture for free, in the same pipeline that already gates your merges.
The Glass of Water example is deliberately simple, but the pattern holds for anything process-based: define the states your system moves through, decide what \"correct\" means in each one, and let the simulation tell you when reality drifts from that definition. The state-machine approach we used here only checks pass/fail per phase — it doesn't yet look at how a value evolves against a reference trajectory, which is often where the more interesting bugs hide, like quantization-induced oscillation, which capturing CppModel.StepResult at every step already puts you in a position to catch.
The bigger win in this approach is structural: simulation results are no longer something you eyeball locally and forget. They run on every push, fail the build when the system misbehaves, and land in the CppModel workspace where the whole team can inspect them.
\nIf you try wiring this into a process-based project of your own — or think the pass/fail checks should be structured differently — I'd love to hear about it. Reach out or leave a comment below.
\nI 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.
\nTake 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.
\nLet's start with the thing being controlled — the glass. In engineering, we'd call this \"the plant,\" but really it's just whatever we're trying to influence.
\nThe idea is simple: the more water flows in, the fuller the glass gets, until it's full — after that, no matter how much more water flows, the glass doesn't get any fuller (it just overflows). So the glass's behavior can be described as a simple rule: given how much water is flowing in, and how full the glass already is, figure out how full it will be a moment later.
\nWritten as a function, that rule looks like this:
\nvolume = glass(capacity, filledVolume, waterFlow)
Breaking this into the four parts we'll use consistently throughout this post:
\nSettings, decided ahead of time and fixed while the process runs:
\ncapacity — the size of the glassState, what the process remembers from one check to the next:
\nfilledVolume — how full the glass currently isInput, what changes moment to moment from outside the process:
\nwaterFlow — how fast water is pouring in right nowOutput, the result handed back:
\nvolume — the new fill level, after this moment's flow has had a chance to add water; this becomes the State going into the next checkSince a computer checks on things at discrete moments in time rather than continuously, we also need to say how much time has passed since the last check, dt:
volume = glass(dt, capacity, filledVolume, waterFlow)
And here's what that looks like as actual code — you don't need to be a programmer to follow the gist: add the water that flowed in during this brief moment, then cap the result at the glass's capacity so it doesn't \"overflow\" mathematically:
\nfloat glass(float dt, float capacity, float filledVolume, float waterFlow)
{
float deltaVolume = waterFlow * dt;
filledVolume += deltaVolume;
if (filledVolume > capacity)
{
filledVolume = capacity;
}
return filledVolume;
}
Now that we have a model of the glass, we can simulate it with different steady flows. Here I fill a 250 ml glass three times, with the tap running at 5, 10, and then 10 liters per minute. Here's how each fill plays out over time:\n![\"Glasses](\"https://www.cppmodel.com/assets/images/glass-fills-76c4bfc745863014af8f4c880da4fbf5.png\")
Unsurprisingly, each run is a straight line climbing up to the glass's capacity, with a steeper slope for a faster flow. If you tried pouring at different, changing speeds — the way you probably experimented as a kid — you'd get more interesting, curvier lines. That's actually a common way engineers test a system: run it under different conditions and watch what happens.
\nThis little piece of code is about as small as a model gets, and it happens to be written in the same programming language (C) that's often used for the real control logic driving mobile or even industrial machines. The same code would run just as well on a hobbyist kit like an Arduino or Raspberry Pi.
\nThe controller is the part that decides what to do next. It looks at the gap between \"how full we want the glass to be\" and \"how full it actually is\" (we'll call that gap the error), and decides how far open the tap valve should be, as a percentage.
\nThink about how you actually do this by hand: when you start filling a glass, you open the tap a little, then gradually more, to avoid splashing — and as you get close to the level you want, you start closing it, finishing with a firm close right at the target. Often you close much faster than you opened: spilling is a concern with the first drops of water, not the last, so once you're near the target there's no need to stay gentle. In engineering terms, this is a controller whose behavior is different depending on whether it's opening or closing — a very ordinary thing for real controllers to do.
\nHere's the shape of that idea, again as a function:
\nopening = control(openingSlope, closingSlope, actualOpening, error)
Breaking this into the same four parts:
\nSettings, decided ahead of time:
\nopeningSlope — how quickly the valve opens, in percent per secondclosingSlope — how quickly the valve closes, in percent per secondState, what the controller remembers between checks:
\nactualOpening — how far open the valve currently isInput, what changes moment to moment:
\nerror — the gap between the desired and actual water levelOutput, the result handed back:
\nopening — the updated valve position; here it's the same value as the State above, since the valve position is both what the controller needs to remember and what it reports back to the rest of the systemTurning this into code, the controller nudges the valve open a bit if the glass isn't full enough yet, or closed a bit if it's gone past the target — always keeping the valve position between fully closed (0%) and fully open (100%):
\nfloat control(float dt, float openingSlope, float closingSlope, float actualOpening, float error)
{
if (error > 0) // we need to open the tap
{
actualOpening += openingSlope * dt;
if (actualOpening > 1.0) // limit to 100%
{
actualOpening = 1.0;
}
}
else if (error < 0) // we need to close the tap
{
actualOpening -= closingSlope * dt; // error is negative, so this will decrease actualOpening
if (actualOpening < 0.0) // limit to 0%
{
actualOpening = 0.0;
}
}
return actualOpening;
}
To check that this behaves sensibly, I simulated a 2-second burst where the error is pinned at 100% (as if the glass were completely empty and we wanted it completely full), using:
\nHere's the result:\n![\"Tap](\"https://www.cppmodel.com/assets/images/tap-control-5365820d19648443259ffae0cec96d0a.png\")
With both pieces defined — the glass and the controller — we can connect them into a complete, self-correcting loop: the controller looks at the gap between the desired and actual level and adjusts the valve; the valve's opening determines the flow rate; and that flow rate is what fills the glass.
\nTwo more small pieces connect the controller to the glass: a sensor and an actuator. They're not part of the \"thinking\" — they just translate between units.
\nThe sensor converts the glass's water volume into a fill percentage (relative to its capacity) — like your eyes glancing at the glass and judging \"it's about 80% full.\" The actuator converts a desired valve-opening percentage into an actual flow rate — like your hand turning the tap. In real life, sensors and actuators have their own quirks and delays, but for this example we'll treat them as perfect.
\nFitting these into the same four parts, both are simpler than the glass or the controller: neither needs State, since neither has to remember anything between checks — each just turns its Input into an Output using a fixed Setting:
\ncapacity; Input: filledVolume; Output: fill percentagemaxFlow; Input: valveOpening; Output: flow rateHere's what they look like in code — each is just a one-line conversion:
\nfloat sensor(float capacity, float filledVolume)
{
return filledVolume / capacity;
}
float actuator(float maxFlow, float valveOpening)
{
return maxFlow * valveOpening;
}
Before wiring everything up, let's be clear about the goal: when you walk up to the tap, your intention is usually to fill the glass to some target, say 80% full. That target is called the setpoint.
\nIn real life, your eyes are the sensor, judging the fill level, and your hand is the actuator, opening and closing the valve to some flow rate between zero and the maximum the plumbing can deliver. You probably don't think about that maximum flow much, but it's usually enough to fill a small glass in about a second — here I'll use 15 liters per minute. Put together, the controller's job is: look at the gap between the desired and actual level, and output how far open the valve should be. Here's what that whole system looks like as a block diagram:\n![\"Control](\"https://www.cppmodel.com/assets/images/glass-control-80f1620c839d0653ebdbe0645c327dc9.png\")
I simulated this full system aiming for 80% full, with:
\nWith the rest of the functions already sitting in a file called GlassOfWaterLib.c (and its header, GlassOfWaterLib.h), here's the simulation code that wires them together using the CppModel framework — all in under 50 lines:
#include \"GlassOfWaterLib.h\"
#include \"cppmodel/CModel.h\"
float tapOpening = 0.0f;
float actualVolume = 0.0f;
float actualLevel = 0.0f;
float actualFlow = 0.0f;
CMODEL_CYCLIC()
{
float dt = self->stepTime_ms / 1000.0f; // Convert milliseconds to seconds
float plumbingFlow = CppModel_getParameterF32(self, \"plumbingFlow [l/min]\", 15.0f) / 60.0f; // Default plumbing flow is 15 liters per minute converted to liters per second
float glassCapacity = CppModel_getParameterF32(self, \"glassCapacity [ml]\", 250.0f) / 1000.0f; // Default glass capacity is 250 ml converted to liters
float openingSlope = CppModel_getParameterF32(self, \"openingSlope [%/s]\", 100.0f) * 0.01f; // Default opening slope is 100% per second converted to a fraction
float closingSlope = CppModel_getParameterF32(self, \"closingSlope [%/s]\", 400.0f) * 0.01f; // Default closing slope is 400% per second converted to a fraction
float desiredLevel = CppModel_getInputF32(self, \"desiredLevel [0.01%]\", 80.0f * 0.01f); // Default desired level is 80%
// Control loop
float error = desiredLevel - actualLevel;
tapOpening = control(dt, openingSlope, closingSlope, tapOpening, error);
actualFlow = actuator(plumbingFlow, tapOpening);
actualVolume = glass(dt, glassCapacity, actualVolume, actualFlow);
actualLevel = sensor(glassCapacity, actualVolume);
CppModel_setOutputF32(self, \"error [0.01%]\", error);
CppModel_setOutputF32(self, \"tapOpening [0.01%]\", tapOpening);
CppModel_setOutputF32(self, \"actualFlow [l/s]\", actualFlow);
CppModel_setOutputF32(self, \"actualVolume [l]\", actualVolume);
CppModel_setOutputF32(self, \"actualLevel [0.01%]\", actualLevel);
}
CMODEL_SIMULATE(\"Glass of Water\", 2000, 10)
Here's how it behaves over time:\n![\"Closed-loop](\"https://www.cppmodel.com/assets/images/glass-tap-system-17eb814fbdfea64f92f7b3c3506bd669.png\")
You can see the glass filling as soon as the tap opens, and as it nears the 80% target, the tap starts closing. Because it closes faster than it opened, the system still slightly overshoots the target before settling. Tuning those opening and closing speeds can reduce that overshoot and make the fill smoother.
\nI chose to simulate this entire system directly in a general-purpose programming language, without any specialized physics or simulation software, to show just how little machinery is needed to model and test a real process — even one as ordinary as filling a glass. The same approach scales up to far more complex systems; the underlying ideas don't change. By understanding how the thing you're controlling behaves, and designing a controller that responds sensibly to it, you can get useful, predictable behavior out of all kinds of automated systems.
\nKeeping the simulation this lightweight also means it can double as the real production code and be run automatically as part of a software testing pipeline. And as AI tools become part of more engineering workflows, keeping the simulation and the real control logic written in the same language makes it easier to bring those tools to bear on implementing and improving the system.
\nIf you enjoyed this and want to run your own simulations, please consider subscribing to one of our plans. I've prepared an archive with the code and data used in this post, ready to run all the simulations in this article. I'll be continuing this series with more processes and control systems, so let me know your thoughts — or how you'd have approached this differently.
\n