Hardware-in-the-Loop Testing: An Introduction

If you do a search for “Hardware-in-the-Loop” testing, you will frequently find examples of complex, real-time systems. This article from National Instruments, for example, gives a nice explanation and background on what hardware-in-the-loop (HIL) is, and provides an example of testing electronic control units within an automobile. In this article, we will be focusing on a smaller, more bite-sized version of HIL testing concepts.

What is Hardware-in-the-Loop Testing?

For the purposes of this article, we will define hardware-in-the-loop testing a little differently than the way it is presented conventionally (e.g. within automobile applications). Let us observe three different layers of complexity when it comes to testing a product.

Test Format 1: Basic Manual Testing

In this form of testing, an engineer will manually test the device. This can consist of probing test points on a board with a digital multimeter, observing waveforms on an oscilloscope, or manually parsing through a telemetry readout on a computer screen. The engineer will test the product via manual design verification testing.

Test Format 2: Automated Testing

This test setup runs the same measurements and verification normally done by an engineer, but is performed by a computer in an automated fashion. The host computer would speak directly to the instruments (e.g. multimeters, oscilloscopes, etc.), parse the telemetry from the device, and then verify the test set based on criteria laid out by the engineer.

Test Format 3: Hardware-in-the-Loop Testing

Hardware-in-the-loop testing takes automated testing to a new level by adding extra stimuli to simulate a real-world application. For example, the device under test (DUT) may have a series of sensors that require excitation. The test equipment would simulate the other end of those sensors to excite the sensor side of the DUT. Another example could be something as simple as driving RS-422 traffic into an RS-422 receiver on the DUT. The idea is that we are able to drive new stimulus into the DUT, read back the telemetry from the host computer, and adjust our tests appropriately if needed (e.g. drive faster and greater RS-422 traffic after passing an initial test).

The Benefits of Adopting Hardware-in-the-Loop

Based on the application, it can be clear why one would choose to adopt hardware-in-the-loop testing over automated testing (and certainly manual testing). If one is trying to integrate a complex system or (systems of systems), with lots of required external stimulus, a basic automated checkout test will not suffice. Consider a basic battery charger. While you could simulate a power source, load, and battery to test your controller circuit (either physically or through software) it would be more realistic to use an actual power supply, battery, and load to test the design. Furthermore, if you can automate this process, your engineers can now spend their time on development over-testing.

Cost Analysis: Is it Worth it?

When deciding on whether to adopt hardware-in-the-loop testing one should consider the following factors:

1. Test time: How much time will you be spending testing the device? Will it be a basic checkout and then you’re done or will it require months of testing?
2. Test recurrence: How often will you be running the same test? Can this test setup (i.e. equipment and automation scripts) be used on future designs?
3. Test equipment: How costly is it to get the necessary equipment for automated testing versus manual testing?

Once you’ve considered these and other factors, you can start to make a decision on whether to stick with manual testing or to invest in automated/hardware-in-the-loop testing.

Getting Started

Based on my experience I have found that, hands down, the easiest entry into hardware-in-the-loop testing would be using an all-inclusive test framework such as one provided by National Instruments (NI). NI has an all-inclusive hardware/software platform that is plug and play. Here are a few pros and cons to consider when considering an all-inclusive framework:

For the time I spent working on complex systems, LabVIEW was my go-to for automated testing—including building a full Continuous Integration and Continuous Deployment pipeline for LabVIEW projects and VIs. As I transitioned into smaller systems that required simpler hard-in-the-loop support I started to migrate towards custom or commercial off the shelf (COTS) hardware and Python scripts (using the pytest framework). Again, this all depends on the application and, as stated before, test time, test recurrence, and test equipment are the major factors that drive this decision.

Conclusion

In this article, we reviewed the concept of hardware-in-the-loop testing and how it differs from both the manual and automated testing. We also reviewed the benefits of adopting hardware-in-the-loop testing and how to assess whether it’s really what the user needs. Finally, we discussed some ways to get started. While hardware-in-the-loop testing may not be for everyone it is clear that for the right application the investment will pay dividends very quickly.

Would you like to find out more about how Altium can help you with your next PCB design? Talk to an expert at Altium or discover more about the top DFM problems and their solutions.