Bench Talk

Today’s systems have become so complicated that, in many cases, the only way to verify hardware and software functionality and “correctness” is by using Hardware in the Loop (HITL, or sometimes HIL). But what is HITL? The answer is simple: It depends. Most discussions of HITL describe it as a software-driven system with analog and digital I/O, spanning basic switch closures to RF, that attempts to replicate the system with which your design must work.

The most common examples of HITL use are with the automobile, which makes sense, since everyone knows what an automobile is, understands the complex and diverse nature of its various subsystems, and has at least a basic sense of the challenges of testing auto electronics. In a common auto-related HITL scenario, the designers must evaluate the hardware and software of their new engine control unit (ECU)—a situation that seems to require connecting it to a real engine.

A Software Modeling Approach

But connecting an ECU to a real engine is not actually necessary. By using the HITL approach, the ECU under evaluation is instead connected to a rack of electronics that contains engine-related connectors, so the engine itself is now represented by software in that rack, which emulates a real engine, as shown in this schematic from National Instruments (Figure 1). This is obviously easier to deal with than using a real engine in terms of changes, test scenarios, noise and inducing sensors, interface, and engine “corner conditions” and failures. HITL is also well-suited for testing motor controllers and anything related to the electronic control of mechanical performance.

Figure 1: In the classic HITL setup, the system to be managed is replaced by hardware and software with real-world I/O that faithfully models and emulates that real system, which could be an automobile (shown), rocket, motor, or other sophisticated product. (Source: National Instruments)

But the HITL rendition doesn’t come quickly or easily. Developing the rack of electronics and software that replaces the real engine is a major project. Via equations and functional blocks, it must faithfully model a real engine’s performance and subtle nuances, starting with basic functions and then adding the critical layers, sublayers, and sub-sublayers of reality. A model-development team can actually become bigger than a product-development team.

Then there’s the eternal test question: How do you validate a model? Any simplifications, oversights, misassumptions, or glossed-over aspects in the HITL model of the real engine mean that the ECU’s test will not be as valid as when using a real engine, of course, but that’s a simplistic view. (The well-known phrase “garbage in, garbage out” comes to mind here.) Yet the reality of this situation is that any single real engine does not represent all engines, so even if a real engine were used, the tests would only be valid for that particular engine type. The HITL approach is much better because it’s easier to modify to simulate different engines.

A Scale-Modeling Approach

There’s another, very different approach to HITL that involves real hardware rather than a software-based representation. Instead of full-size hardware, however, what is used is a scaled-down version with large objects and systems replaced by much-smaller ones, for example. The classic wind-tunnel is the best-known example of this approach, but it’s also used for functions such as vehicles and their motors; Keysight Technologies’ Application Note 5991-2873EN is a good example of the second approach.

The advantage of this approach is that you don’t have to create a detailed and, hopefully, faithful model of the real engine or aircraft. But it, too, raises some difficult issues: How do you scale down your motor, engine, or aircraft control analysis to match the characteristics of a physically smaller model? After all, so many things are different: Time constants, thermal performance, momentum, inertia, transient response… (It’s a very long list, that’s for sure!) Adding to the challenge is that some factors scale linearly, some exponentially, some with discontinuities, and some with hard-to-figure relationships.

Choosing a HITL Approach

Which HITL scenario makes sense? Again, it depends on the specific application, available time, cost, and depth of understanding of the system itself. From what I’ve seen, except for simpler, well-defined, tightly constrained systems, using HITL to simulate the actual system via a detailed, largely software-based model of that system seems to be the preferred approach.

The reasons for this are many: Flexibility in being able to represent different variations of similar hardware, such as engines; credibility of the results; cost and convenience in operations (when using real motors, car engines, and rockets versus a rack of electronics); ease of setting up simulated fault scenarios; and ease of setting up more than one system so tests can be done in parallel, thereby saving time and allowing for teams to learn from each other.

Regardless of which way you go, HITL is needed for motion- and power-related design overall, not just for cars or rockets. If you’re testing a photovoltaic, wind power, or battery controller, it’s much easier to deal with a rack than an actual array of solar panels, wind turbines, or battery stacks. Even better, for these types of products, you can buy an off-the-shelf, fully programmable simulator from various T&M system vendors, such as Keysight Technologies, thus turning a big problem into a small one (Figure 2). And that’s what product-development engineers like to hear!

Figure 2: Standard test and measurement products are available for many common applications that benefit from HITL, such as this kilowatt source/sink unit. It can be used to test control of rechargeable batteries, supercapacitors, motor-generators, bidirectional DC/DC converters, battery-management systems, regenerative braking systems, and photovoltaic arrays. (Source: Keysight Technologies)