Hardware-in-the-Loop Testing for Hybrid Vehicles

By Amanjot Dhaliwal, Shreyas Nagaraj, and Santhosh Jogi, dSPACE, November 2009 Rising fuel prices over the past few years and the urgent need to reduce the carbon footprint related to transportation have triggered an increased demand for fuel-efficient hybrid electric vehicles (HEVs). These vehicles provide greater efficiencies than their conventional counterparts and offer similar, if not improved, performance. The growing demand for hybrid and electrified vehicles in general is a topic at the forefront in the automotive market, with pressure to drastically alter the lineup of OEM vehicles coming from all angles: consumers, government, and environmentalists. To meet this demand and challenge, OEMs are designing various new vehicle architectures ranging from advanced hybrids to extendedrange plug-in electric vehicles. The desire to see these vehicles released is driving very aggressive design and development time lines; however, such architectures also involve very complex systems, all of which have to be developed, integrated, and validated. HEVs are categorized into series, parallel, series-parallel, and complex hybrid configurations. A newer addition to the hybrid vehicle family is the plug-in hybrid electric vehicle (PHEV) in which an infrastructure-based electric power source is used to charge the batteries. Since an HEV can have two or more propulsion sources, the control system for such a powertrain becomes much more complex than that of a conventional vehicle. This makes developing and testing hybrid controllers and their algorithms more challenging and a critical task in the development phase. Electronic control units (ECUs) that manage the energy flow through a hybrid powertrain have played a major role in the success of this technology. Due to the complexity of these systems, ECUs need to go through extensive testing before installation in a prototype vehicle for on-road testing.

Hardware-in-the-loop (HIL) simulation, an industry-standard testing process for ECU verification and validation, is being applied in hybrid vehicle applications across the globe. It is being used in multiple phases of electrified vehicle development as a means to test and verify ECUs and as a virtual real-time platform for control strategy analysis. HIL can reduce the time between system modeling and implementation of prototype hardware. By working in a virtual environment, you can simulate test conditions and vehicle behavior, providing a method to validate control strategy without needing the physical vehicle or, in many cases, the actual vehicle components. One benefit of this simulation approach is in emulating a key component: the battery. A battery in an HEV is one of the most expensive components. ECU software under development needs to be reliable and robust before it can be used with real hardware such as batteries so it has to undergo significant validation. For this reason, it is very advantageous to use HIL simulation with necessary hardware and software to simulate the battery operation and high current not only to reduce costs of development, but also to avoid the use of high voltage and current during the development phase in the laboratory.
Electric Machine Simulation

Another component in a hybrid vehicle powertrain is the electric machine. There could be one or more electric machines in a typical HEV functioning as a motor or a generator. Motors used to provide propulsion to the vehicle also are known as traction motors. With the need for higher fuel economy and stricter emission requirements, automobile manufacturers are starting to use electric motors to drive other components such as the AC compressor, electric steering assist, or the transmission oil pump. As a result, it is very important to be able to accurately simulate the dynamic response of electric machines within the HIL environment. An electric machine can be simulated at three different interface levels to the HIL system, depending on how an end user describes the system under test (SUT). Different interface levels between an ECU and an HIL system can be established as signal, electrical, and mechanical (Figure 1).

Figure 1. Three Types of Interfaces Between the ECU and the HIL Simulator In the signal interface level, the only real component is the electric motor controller. Components including the inverter, electric motor-generator unit (MGU), battery, vehicle dynamics, and other powertrain components such as the engine and the transmission are simulated as mathematical models. In this case, the SUT is the motor controller. In the electrical interface level, the SUT will include the power stages along with the motor controller. The actual electric motor will not be used but will be simulated by means of electrical loads such as inductors and resistors. In the mechanical interface level, the SUT will include the motor controller, power stages, and the electric machine. The electric machine will be loaded by means of load motors or dynamometers controlled by inputs from the HIL simulator which, in turn, are a result of the computation of the vehicle model. Table 1 summarizes the three different interface levels between the ECU and the HIL simulator.

Table 1. Three Interface Levels Between the ECU and the HIL Simulator The motor controller, which usually is a part of the hybrid supervisory controller, outputs 3-phase pulse width modulated (PWM) signals that drive the insulated gate bipolar transistors (IGBTs) in the inverter. The inverter drives the MGU. The controller has built-in current transducers to measure the current in each of the three power lines. In the signal level interface, the HIL simulator must have the capability to capture the PWM pulses from the controller at high speed and compute the mean duty cycles. The duty cycles are input to the motor model, and the output of the motor model is a 3-phase current signal. Then these 3-phase current signals are fed back to the controller. This loop also is known as the current loop. In the signal level interface, there are no high voltages or currents, and the 3phase current signals from the HIL simulator are fed directly to the controller PCB by bypassing the current transducers. The 3-phase current usually is in the range of 0 to 5 V, which could represent current in the range of -1,000 A to +1,000 A. The current feedback is accomplished by a high-speed DAC board. For accurate and reliable performance over all operating ranges, the settling time of each DAC channel must be as small as possible. Another key component of motor control is the speed sensors used to measure the rotational speed of the MGUs. The most commonly used types of rotational

speed sensors in the hybrid vehicle are resolvers and encoders. The HIL simulator hardware must be able to simulate a typical resolver or encoder. The plant model consists of an electric machine and an inverter model. The electric machine is a dynamic model, and the inverter, in most cases, is a static model. The two real-time interface (RTI) blocks in Figure 2 are the drivers for the dSPACE I/O cards in a Simulink model, also known as RTI. The PWM- capture, DAC, and speed-sensor blocks represent I/O boards that are part of the simulator's hardware. The solid lines indicate the electrical wiring harness from the simulator to the controller.

Figure 2. The Components Required for High-Speed Simulation of the Electric Machine
Model Preparation

The dSPACE HIL simulation strategy for electric machines requires mean-value models. These models are much better adapted to real-time execution and can be readily merged with the mean-value measurements provided by the I/O. For proper allocation of processing resources, the electric machine models have to be set up as multirate models. The whole model needs to be partitioned into subsystems that are executed at different rates according to their dynamics.

The current loop captures the electrical behavior of the machine and runs at a faster rate than the remaining components. Typically, this loop can be triggered in three different modes depending on the type of application: external interruptdriven, PWM interrupt-driven, or software oversampled. External Interrupt-Driven The external interrupt-driven mode requires an external master PWM pulse. This pulse is used internally in the ECU to synchronize the three phases of the PWM input to the inverter. In this mode, the electric machine model has to be triggered at the center of the 3-phase PWM pulses. This usually happens to be the rising or the falling edge of the master pulse. An interrupt triggered by the master pulse can be used in this case to execute the model. PWM Interrupt-Driven If an external interrupt source is not available, it is possible to calculate and predict the PWM pulse-centers on an FPGA and send an interrupt to the main processor. The first two pulses of the PWM signal are used to calculate the PWM period. Knowing the period, the center of the third pulse can be predicted. Once the third pulse has passed, the actual time period is used to update the calculated time period. This ensures that the PWM pulse-center prediction mechanism does not drift away from the actual pulse centers. An interruptgeneration mechanism then sends interrupts to the real-time processor at the predicted pulse centers. Like the external interrupt-driven mode, the PWM interrupt-driven mode can provide stable simulation only up to a certain rpm. Beyond this rpm, you need to use an oversampling mechanism. A PWM pulse oversampling mode in the dSPACE PWM capture setup allows generation of multiple interrupts between two successive PWM pulse centers. Interrupts can be generated at 2x, 4x, or 8x the PWM switching rate to achieve stable simulation at higher rpm values. The current-control loop consists of a motor model, an inverter model, a PWM capture RTI block, and the analog output RTI blocks. It is placed inside the function-call-triggered subsystem. The function-call subsystem is driven by the interrupt block of the PWM capture board. Software Oversampled The software oversampled method relies on a fast, asynchronous execution of

the electric motor model. The recommended rate is at least 10x the PWM switching frequency. At this rate, the simulation is quasicontinuous and does not have any delays in the current response time. The only disadvantage to this mode is the high computational requirement, which sometimes can be hard to achieve on real-time processors. The DS5202 PWM solution is used to capture the PWM pulses from the controller at a high sampling frequency and can be configured to perform in any of the triggering modes. The board has the capability to capture the PWM pulses for up to four independent electric machines. It is based on FPGA technology, which permits capturing signals at a resolution as low as 25 ns.
Rotor Position/Velocity Feedback

The position and angular speed of the electric machine must be fed back to the controller. In the real world, this is achieved by means of encoders or resolvers. In the simulation environment, the HIL simulator must be able to electrically simulate the encoder or resolver signals.

Figure 3. Typical Output Signals of the

Resolver Obtained by Two Transformers Placed at 90 Degrees to Each Other Encoders are quite popular and do not require a detailed description; however, resolvers are commonly used in hybrid application because of their inherent robustness. In theory, a resolver is an analog multiplier that takes in an excitation signal from the motor controller and generates two signals that are 90 degrees out-of-phase. This is accomplished by two transformers mounted on the resolver rotor that are placed at a separation of 90 degrees with respect to each other. The transformers are excited by the sinusoidal excitation from the controller. Typically, this excitation signal is in the frequency range of 10 to 20 kHz (Figure 3). The DS5202 position sensor simulation (PSS) board is used to simulate the encoder or resolver signals in the HIL simulator. It is an FPGA-based board that has two independent angular processing units (APU); that is, it can simulate two independent shafts. This board operates by incrementing the internal APUs based on the simulated angular speed coming from the motor model. It computes the simulated resolver output signals every 100 ns, providing a position signal at a high refresh rate. In addition to simulating the encoder and resolver signals, the PSS board gives the current rotor position that can be used by the motor model. This is necessary to maintain position synchronization between the simulator and the controller.
Sensor-Based Fault Simulation

Failure mode testing is a two-fold process. First, the HIL system needs to generate a fault. This can be triggered by a user, an automation script, or detection of a faulty signal from the ECU. Faulty signals from ECUs that might need to be detected by the HIL can be: Dead-Time Violations: An interrupt is triggered if the dead time between the high and low legs of an inverter falls below a specified level. PWM Period Violations: An interrupt is triggered if the PWM period falls below a specified level. Once the fault is detected, the HIL system needs to trigger specific diagnostics that normally would be sent out by an inverter. These diagnostics can be as simple as a digital high or low signal or watchdog timers synchronized with the PWM signal. Depending on the nature of the diagnostic signal, appropriate signal conditioning might be required. Inserting faults on the resolver signal for position sensor simulation is a common test performed during ECU software validation. Following are three of

the most important tests performed during runtime: Loss of Signal (LOS): This fault is performed by disconnecting either the sine or cosine signals or both from the controller. Degradation of Signal (DOS): This fault can be generated by changing the amplitude of the sine and cosine waveforms above or below the thresholds defined in the controller software. Loss of Tracking (LOT): This fault occurs when there is phase shift between the sine and cosine waveforms; that is, the phase difference between the sine and cosine waveform is no longer 90 degrees (Figure 4).

Figure 4. Amplitude and Angle Deviation of the Sine and Cosine Waveforms for Resolver Failures
Technical Challenges and New Solutions

One of the biggest challenges in the HIL simulation of electric machines is successfully running the current loop at a high sampling rate. The higher the sampling rate the more accurate the simulation. However, higher sampling rates require higher processing capabilities. A solution to this problem is using an FPGA board that not only computes the electric machine, but also has the capability to capture the gate drive signals from the controller at high speed and provide high-speed analog to output the motor current signals. Consequently, the current control loop can be run at very high sampling times on the FPGA, freeing up computational time on the main processor to run other critical tasks. The DS5202 electric motor simulation (EMS) provides the opportunity to simulate the motor model and aspects like inverter dynamics at the switching frequency of the PWM, which yields the highest accuracy behavior replication.

Summary

An area of advancement in HIL technology is the offering of real-time models for simulating electric drive components. The number of OEMs and component suppliers involved in HEV-oriented work is growing dramatically, and the availability of component models with a parameterization interface to simulate electric drive elements is proving very useful. HIL simulation tools will continue to address the rapid growth of technology in hybrid and full electric vehicles. While traditionally a validation tool, HIL simulation now is used throughout the development process as a platform on which to invent control strategy, get a head start on ECU calibration, reduce vehicle prototype stages, and, in the end, ensure a better performing, safer, and more content-rich product for the consumer.
About the Authors

Amanjot Dhaliwal is a senior applications engineer at dSPACE North America. He holds an M.S. in mechanical engineering. 248-295-4649, email:adhaliwal@dspaceinc.com Shreyas Nagaraj is an applications engineer at dSPACE. He earned a master's degree in mechanical engineering. 248-295-4663, email:snagaraj@dspaceinc.com Santhosh Jogi is the director of engineering at dSPACE. He is in charge of engineering operations in the company's North American market. 248-2954700, e-mail:sjogi@dspaceinc.com dSPACE, 50131 Pontiac Trail, Wixom, MI 48393 FOR MORE INFORMATION on HIL testing www.rsleads.com/911ee-176