Hardware In the Loop (HIL) simulation, the way it is described in Wikipedia, is considered as an expensive and time consuming method only applied in development of most complex and safety critical applications, like in automotive or aviation domains. Equipment needed for testing an ECU is expensive for sure, but there is also possibility for more lightweight approach in case of more conventional embedded systems development.
Here is an example from my hobby project. Last Christmas I got my interest to model trains to rise again after 25 years, as told in earlier posting Fully automated model train control. As a part of that, I have implemented a RF control for locomotives with two-way communication, using 868 MHz radio.
|Model train, RaspberryPi with Sug-GHz RF dongle and train control unit (green antenna).|
|Block diagram of the locomotive control unit.|
|Functional principle of the odometer.|
|HIL setup with target hardware, NI myDAQ and ISP programming device.|
|Software development environment.|
Now the questions is only how good the plant (physical process) simulation model is? In my case, I just had some delay in feedback from PWM to tachometer. That was good enough for the simple problem given. I didn't had to simulate all the physical phenomena like mass, inertia, friction, etc. The drawback is that testing in real physical environment can not be completely avoided.
What is the lesson here? Even smallest embedded projects can benefit from HIL simulation approach, even if no complete plant model exists. In the case of this example, I claim I got benefits in software development, even if I had to learn LabVIEW programming first. A developer already familiar with the given simulation tool can get benefits much faster.