Fast Precision DAC Application: Hardware in the Loop (HiL)

In the previous blog post, we covered several applications where Fast Precision DACs add value. In today’s post we will focus on Hardware in the Loop, a new application that has found an opportunity with the increasing electrification of vehicles.

Closed-loop applications are becoming widely spread in many of today’s emerging technologies. Basically, a sensor determines how an actuator must operate to achieve the desired result, adapting continuously to changes in the environment. A good example is a car’s cruise control, where a sensor measures speed and other parameters and a driver acts on the throttle following the algorithms in one of the many Electronic Control Units (ECU).

Now think of how cruise control adapts to changes in inclination, wind shear, and re-arming. Many familiar concepts come into play here: reaction time, latency, step response, slew rate, overshoot, load regulation. Yes, we all want the cruise control to keep a steady speed when the slope changes and to reach the cruise speed gently when re-armed. It ultimately depends on closed loop latency, the time elapsed since measuring a change and acting to compensate. Closed loop latency involves propagation speed, conversion time and processing time. A high latency, like a low phase margin, can make the speed oscillate.

A potential driving scenario for a cruise control is depicted in Figure 1. As seen in the speed plot, the cruise control responds nicely to re-arming (step response) and slope change (load regulation) but it reacts too late to wind shear. The power plot shows what the cruise control is doing to adapt to changing conditions.

Figure 1. Speed and power versus time in a cruise speed control scenario

Let us consider the manufacturer’s side. Suppose you have to test the Electronic Control Unit and the cruise control SW on 7 different engines with hundreds of test cases. It’s impractical to have real cars touring a circuit around the clock. So why not interface the ECU to a device that emulates the behaviour of the car? This emulator can run 24/7 without human intervention to validate every small change in the SW.

This is what we call Hardware in the Loop (HiL). This technique consists in replacing a part of a system with an emulator capable of interfacing the signals used for sensing and control, with the purpose of validating the other part under multiple conditions.

The electrification of many components of the car facilitates the automation of this process since many interactions between the ECU and the emulator can take place at the electrical level.

Figure 2. Using HiL to replace field testing with automated lab testing

Signals captured from sensors and signals driving actuators can be digital or analog, therefore the emulator must include fast and precise A/D and D/A converters. Latency from the capture point to the drive point must be as small as possible to maximize the range of applications where the emulator can be used. High resolution and precision is required to emulate the large dynamic range of some sensors and actuators.

The emulator may also include a DSP or FPGA to process the input and generate the output on a continuous stream. The latency of this device adds to the total figure and can be significant, especially if FIR filters are used.

Figure 3. Conceptual diagram of a HiL system testing an ECU

The total latency comprises the conversion time of the ADC and DAC, the time to transfer digital to and from the FPGA, the processing time in the FPGA and the settling time of the DAC output. Let us see an example using real devices:

Figure 4. Implementation of a HiL system using ADAQ23876 and AD3552R

Table 1. Data rate and latency of each element of the HiL system

Some operations can be overlapped to increase the update rate of the signal chain, which gives higher signal bandwidth. However, closed-loop bandwidth is still limited by the total latency. In other words, the device cannot compensate changes that last less than the signal chain latency. For example, acquisition, data transfer and data processing take place during the settling time of the DAC which allows achieving a sampling rate of 10 MSPS.

Hardware in the Loop emulators are used in multiple technology fields:

• ECU validation and testing. The HiL system emulates the behaviour of the car, producing the signals that the ECU reads and checking the responses it produces. Interfacing can be fully electrical or through actuators (the DAC drivers the sensor that produces the signal).
• Combustion / Electric / Hybrid powertrain emulation. Emulation can take place at two levels:
  • Power level. The electric motor is emulated using an electronic load and the HiL system synthesizes rotational speed and position signals.
  • Mechanical level. The HiL system controls an electrical brake and synthesizes rotational speed, torque and position signals.
• Battery Management System (BMS) testing or Battery Pack emulation. The HiL system emulates the voltage of each battery cell and delivers the current expected from it. It can also provide health signals such as temperature.
• EV / PV Inverter validation and test. The HiL system controls an electronic load and synthesizes current and voltage measurements at the load.

HiL systems are mandatory when testing devices with short response time. Beyond that, the use of HiL platforms allows automating the validation of these devices in multiple scenarios, with extensive test plans and ensuring that stringent requirements are met in all conditions. This level of coverage is impractical in field tests.

A key part of HiL is signal interface, in particular analog I/O that must be fast and accurate, requiring a new breadth of precision ADCs and DACs.

Additional Information

• https://www.analog.com/en/applications/markets/instrumentation-and-measurement-pavilion-home/automotive-testing-solutions/hardware-in-the-loop.html
• https://www.dspace.com/en/ltd/home/products/hw/simulator_hardware/scalexio/scalexio_ds6101.cfm
• https://www.dspace.com/shared/data/pdf/2017/09_Electrifying%20Emulations_en.pdf
• https://www.speedgoat.com/solutions/testing-workflows/hardware-in-the-loop