Simulation and HIL Testing for Rapid Development

Hardware-in-the-loop (HIL) testing is a necessary tool for any automotive manufacturer or supplier in this era of software-defined vehicles. One reason for this is that, compared to the software in vehicles of even a generation or two ago, a modern vehicle presents challenges because of its software’s complexity, the quantity of its software, and the interconnected nature of its systems. The number of embedded controllers, and the quantity of the code installed on them, are both increasing every year. Powerplants of every kind, their power transmitting components, and sensors to monitor events inside and outside of the vehicle, are all connected to embedded controllers. Any time the software is updated on any of these, a new round of tests must be initiated.

Simulation testing is a valuable tool for performing regression testing (the repetitive “iterative” testing required to confirm that a change in code is working properly and hasn’t adversely affected any desired existing function, or adjacent component). These are often performed in an environment where test loops are required but also the timeframe is quite compressed. Does this sound like an automotive manufacturing scenario, especially with the verification and validation demands of functional safety? It absolutely does. HIL simulation and testing is the way to prove code quickly and accurately. Historically, as the controller software was written, it could be taken out to a test vehicle and proven to work in-situ. With the millions of lines of code now present in a modern vehicle, this is no longer practical, especially within the time constraints of manufacturing. There is added difficulty presented by the need to test components or systems that are adjacent or connected to the one for which the code was written – for example, a brake controller that is also linked to the operation of smart cruise control, which can use the brakes in emergencies. If the code for one of those changes, both of these systems need to be verified correct. This is where HIL testing comes in.


New call-to-action

What is HIL testing?

Hardware in the Loop, in general, is a testing discipline for developing and improving embedded software systems. The usefulness of HIL is not limited to motor controls, by any means. Many if not all of the electronic control units (ECUs) found on a modern vehicle can be tested with HIL, including controllers in anti-lock brakes, multimedia and navigation systems, and controllers for the various advanced driver assist systems (ADAS). This is absolutely necessary for proving out thousands (or more) of lines of code at a time embedded in a single controller, which must be tested against multiple use cases in a compressed time frame.

As stated, HIL can be effective and is invaluable in testing any embedded electronic control unit (ECU), but it is especially useful in testing controllers for hybrid and electric vehicle (EV) motors. HIL testing can help to prevent accidents, for example, by decreasing the exposure of test technicians, engineers, and valuable controller hardware to environments with live batteries and motors until it’s completely necessary. While live testing is also useful and necessary, any opportunity to lessen the inherent risks is likely worthwhile. At the power levels modern EV batteries produce, arc flashing (electric current traveling through the air between two conductors) is possible, depending on proximity and other factors. This could cause injury or component damage. Arc flash and other risks make decreasing exposure through simulation desirable. Also, part of testing is to discover errors in code, and it’s far more efficient to find these in a simulated environment than with a live motor or in a vehicle on a test track, no matter if the controller is for a traction motor, or windshield wipers.

HIL for automotive motor controllers is a way of simulating the hardware (whether an ADAS component, a motor, or even a single battery cell) that the embedded controller is designed and intended to control. This is done by connecting the controller to a test system that includes a computing platform with modeling (or simulation) software, and specific test equipment with analog and/or digital connectors for the controller. Connecting the controller electrically to the rack of test equipment, and correctly modeling the component it is intended to control (an electric motor, in this case) fulfills the requirements for the controller to behave exactly as if it were installed in a vehicle with all systems working. Every input and output that the controller interacts with is accounted for and simulated. This allows test personnel to place the controller in any situation required (for example multiple simulated motor loads and input scenarios), to fulfill the use case test requirements.

Special skills for HIL motor control testing

Test engineers and technicians certainly need familiarity with the job to be done, the familiar “V” model of verification and validation. They must know the components to be tested, and also the test equipment, which currently at LHP includes hardware sourced from partner organization National Instruments (NI) and also from the Swedish test systems company, Aliaro.

For the modeling or “plant” simulation side, if the testing will be done in NI’s VeriStand test application software, there may not be much strict programming required. VeriStand is a more “finished product” dedicated to this type of testing. Therefore the learning curve can be easier overall, and the setups for individual tests are generally more rapid.

If a given test will be conducted using NI’s LabView systems engineering software, there will likely be programming involved since LabView is rather much like its own programming language with a wide variety of plug-in libraries. This makes it more versatile, able to control anything from a chemical reaction to, well, a motor for an electric vehicle. However, its setup time can be longer due to its complexity, variability, and the need to program it for individual specific tasks.

Once the HIL test bench is set-up and operating, extensive additional programming will be involved in order to automate the testing; however, this can bring your test setup to a multi-thread state in which the bench can simultaneously process multiple tests. This function serves to greatly speed development, once the setup is complete.

New call-to-action

What components are used in HIL testing?

To flesh out software and verify that it works as intended, the test equipment has to provide all the same interfaces that the end product or application would provide (an EV motor, in our case). This includes sensor type interfaces, actuator type interfaces, whatever is needed to provide the full-function virtual model of the end product.

LHP has been partnered with National Instruments Corp (NI) for some time. NI produces the VeriStand and LabView software, as well as a full line of test equipment to connect components to the main computing platform. NI’s partner corporation, Aliaro, also produces extremely useful test bench hardware. We can break out components by supplier for convenience.


These software components are two options for interfaces which reside in the software side and are fed through the test bench to the controller. In the best scenario, simulation parameters might be available for a component via manufacturer’s data sheet, or directly from the manufacturer in a model file. In other scenarios, a model may have to be constructed from known parameters and specs. Once this model is constructed, it needs to be run on software that can simulate its behavior in communication with the controller during testing


LabView is a lab test software development environment. It’s incredibly flexible and adaptable to numerous kinds of laboratory tests, definitely not limited to automotive. LabView has been used to run models of nearly every imaginable end application for LHP.


NI also developed VeriStand, and this software takes some of the programming out of using LabView for HIL testing. VeriStand is dedicated real-time HIL test software. It’s been specifically designed to facilitate the configuration and deployment of end-product models, and to make mapping the interfaces through test bench hardware rapid, accurate, and as streamlined a process as possible, making for shorter setups overall, so test personnel can commence validating their embedded controllers that much faster.


So we have now touched on two required components, the controller to be tested and the software to simulate its end application. What remains? The test bench in the middle, mating the electronic controller to a software model via electrical connections.

In addition to its software testing environments, NI also supplies hardware to build the test bench itself. One example is their “workhorse” PXI system. This system is the mainstay of many test labs. The PXI is essentially a PCI (peripheral component interconnect) backplane, or a circuit board with parallel-wired pin connectors. The pin of each connector is linked to the same relative pin of all the other connectors, forming a bus, the basic computer mechanism to transfer data between components. In NI’s PXI system, this specialty backplane is fitted with specialty cards and with slots for additional components, all in a compact chassis. This bench component can be customized heavily to tailor its operation to any testing needs.



NI’s partner Aliaro also offers unique and innovative hardware which works quite well with NI test software. Some of the most interesting ones are their multifunction cards allowing analog and digital input and output from, for example another NI component, on the same card. The Aliaro X Move Configurator comes with its own graphic interface, allowing rapid signal mapping of individual pins and cables from the hardware side into the software side. The Aliaro interface then exports a map file to VeriStand. This makes setting up for each test much faster, and also changing from one setup to another can be quite rapid. Aliaro offers an array of hardware solutions, but these are two pieces which could save immense time and expense in testing and developing embedded software on ECUs throughout a vehicle, vastly speeding development. These components have much to offer in not only their own innovative technology, but in the fact that they work so well with the other components already in the field.

New call-to-action


When performing vital hardware-in-the-loop tests for verifying and validating embedded controllers, the correct test bench components and software can place an organization miles ahead of competitors in the market. A complete understanding of HIL testing is one way to ensure end products are not only functional safety compliant, but that they have not been held up in development for too long.

Automated HIL is a necessity for rapidly bringing high-quality modern automotive embedded controllers to market. There is no way to test every required scenario without automation, especially when considering the pressure of functional safety-based controls on verification and design. LHP’s expertise in both functional safety and hardware-in-the-loop testing will help your organization meet development deadlines with high-quality embedded controls.

Adam Saenz

Written by Adam Saenz

Adam joined LHP in 2018 bringing over 15 years of engineering experience in many areas of product lifecycle development. He specializes in embedded system design and has held positions as a software engineer, electrical engineer and systems engineer. As a software engineer, he has worked on control algorithm development and device driver level software. His hardware experience includes analog and digital circuit design, PCB layout, and FPGA firmware development. His system engineering experience includes developing architectures, writing requirements, and test case/procedure development and execution. Over the years, Adam has gained extensive experience in board bring up, hardware/software integration, and troubleshooting at the PCB, system and system-of-systems levels. He utilizes his experience in both hardware and software to determine the root causes of problems and apply the appropriate solution at the right level. Adam has also designed Automated Test Equipment (ATE) systems for verification and validation of safety-critical applications. His design approach utilizes as much off-the-shelf hardware as possible with a common software architecture to minimize costs and development time between projects. His ATE designs have been used in testing high input/output (I/O) products for military, aerospace, and industrial applications. Adam is a Functional Safety Certified Automotive Engineer (FSCAE) and has spent most of his career working on safety-critical projects. He has developed software for Aerospace DO178 Level A products, and hardware and FPGA designs for safety-critical products in the rail and industrial machine tooling industries. Adam attended California Polytechnic University Pomona and has a Bachelor’s of Science in Electrical and Computer Engineering. He also has an Embedded System Engineering Certificate from the University of Irvine.