Simple HIL example

Even smallest embedded projects may benefit from HIL approach, as demonstrated in this article.

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).

The control unit installed inside of the locomotive consists of AVR microcontroller, RFM12 radio module, H-bridge driver for motor, step-down regulator for logic voltage, and interfaces for sensors. The module can accept 9..32 VDC, full bridge rectified power from track.

Block diagram of the locomotive control unit.

Power to the drive motor is controlled by H-bridge with pulse-width modulation (PWM). Tachometer attached to the motor provides square-wave kind of feedback signal. In addition to the tachometer, there is also a odometer in place. The odometer counts track ties with infra-red reflections sensor. The measured signal from odometer is pretty much equal to sinusoidal wave.

Functional principle of the odometer.

Odometer signal is hard to generate mechanically in a testbench, and if driving the train around the railway, it's hard to do any measurements simultaneously. Simulation environment of some sort is definitely needed for software development. National Instruments provides myDAQ and myRIO products for educational purposes. I happened to have a myDAQ box available, thus decided to use that one for my "HIL simulation" environment.

HIL setup with target hardware, NI myDAQ and ISP programming device.

By replacing sensors of the locomotive by analog and digital outputs and delivering the motor drive PWM signal back to myDAQ inputs, I had a full HIL-simulation setup in place. With In-circuit Serial Programming device and RF USB dongle in addition, I had a complete development environment in place.

 

Software development environment.

Now there is no need to drive the train around railroad for software development. I can do everything on my desk with the given setup. Only fine-tuning of PID co-efficients requires testing in real target in final deployment phase.

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.