Software development with Hardware In the Loop

Hardware In the Loop (HIL) Simulation has been used in development of complex embedded systems. However, it does not need to be limited to complex systems only but development of simple embedded systems may benefit from the approach as well.

In traditional HIL Simulation, the physical system "plant" is modeled mathematically "plant model". The system under development (SUT) then communicates with the model instead of the real physical system, which may be expensive, dangerous or hard to reach during development time.

The challenge in HIL simulation is the effort and time required (costs) to create and maintain a model that simulates the real world physical process with any degree of accuracy. Because of that, HIL has traditionally been limited to most complex and safety critical systems only, like automotive and aviation domains.

HIL is not only for verification on complete system, but it can be utilized already in early phase of the hardware/software co-design process. In pure software development, methods like unit testing and integration testing have been in use for long. Why not to introduce Hardware In the Loop already in the unit test phase of the embedded software development? Then the whole plant model does not need to exists, only tiny parts of it, and over the time the model gets more and more complete piece by piece.

The Wikipedia says: "An HIL simulation must include electrical emulation of sensors and actuators. These electrical emulations act as the interface between the plant simulation and the embedded system under test."  

HIL Interfacing

In the illustration above, I'm referring to sensors as Stimulus, and actuators as Response. I prefer those expression, as we may introduce HIL already when the target hardware does not exists. Then we not only simulate the plant model outside of the SUT via sensors and actuators, but also simulate the missing hardware subsystems inside the SUT. Software development and HIL testing can begin with plain CPU/MCU evaluation board only, and there is no need to wait for the first prototype of the target hardware to exists.

In order to execute software unit and integration testing in the target hardware or evaluation board, some sort of communication and software instrumentation is needed in the target to enable execution of individual functions upon request and collect feedback. Then we have three feedback cycles as illustrated:

1. Provide physical stimulus and inspect what actions it causes in the software
2. Execute software function and inspect the physical response
3. Let the software run and inspected what kind of physical response is cause by physical stimulus

Now we have full control over the whole process, including physics, electronics, and software phenomena. My suggestion is to start with baby steps, by introducing HIL at earliest phase possible in software development. Then we start gaining savings in expenses, reduced project risks and improved safety, especially by expanding the test coverage.

HIL is essential part of embedded systems regression test automation, and now we're talking about the money!

Edit Jan 28th:
Clarification: What I mean by "talking about the money". I mean that manual regression testing is awfully expensive, and that's the motivation for automated regression testing.