Simulation Hardware-In-the-Loop: New approach for test automation in real and simulated environments Marcos Cardoso Lima Costa Business Development Manager at National Instruments
ABSTRACT The role of the test engineer is to find all possible failures in a device before it releases. In the domain of electronic control module testing, this role has been diluted into a combination of test scenario creation, evaluation and test scenario implementation. Using traditional tools, the test engineer had to be competent in both test case creation, evaluation as well as the engineering of the test scripts necessary to implement those scenarios. In this presentation we’ll look at new technologies that are enabling the test engineer to spend more time thinking of and evaluating test scenarios without the added burden of engineering and debugging complex test scripts. We’ll also examine the impact of these technologies in recent projects.
INTRODUCTION Every year consumers demand more from the products they use and the services provided to them. For the auto industry this means smarter, more fuel efficient cars to compensate for rising fuel costs. Pushed by these challenges, cars have evolved into intelligent platforms that include complex electronics and software algorithms implemented on embedded control devices called electronic control units (ECUs).
BODY The techniques and tools that engineers use to develop automobiles have evolved as well. A result of this evolution, Hardware-in-the-Loop (HIL) simulation is a test technique that helps reduce development cost, reduce time to market, and increase the quality of automobiles. This article describes HIL simulation and explains how it is being used to build better cars, and it provides guidance on considerations that should be made when selecting a HIL system.
Figure 1: An automobile can have hundreds of ECUs, and HIL simulation can be used to test the proper operation of all of them. What is HIL Simulation? HIL simulation is a real-time testing technique used to test embedded control devices more efficiently. When testing embedded control devices, safety, availability, or cost considerations can make it impractical to perform all of the necessary testing using the complete system. During HIL testing, the physical system that interfaces to an embedded control device is simulated on real-time hardware, and the outputs of the simulator mimic the actual output of the physical system. The embedded controller “thinks” it is in a real system. HIL simulation allows for thorough testing of the embedded control device in a virtual environment before proceeding to real-world tests of the complete system. How Does HIL Simulation Work? In a closed-loop control system, the current state of the system being controlled is fed back to the controller through sensor measurements. In the case of an automobile, an ECU uses these measurements to determine the appropriate actuator values to attain a desired operating condition. For example,
the engine control ECU receives information regarding throttle position, engine speed, and exhaust oxygen levels to determine the appropriate actuator commands for fuel injector position, spark plug timing, and air intake to maintain maximum engine performance and minimize harmful emissions. Physical testing of the complete system is ultimately required; however, engineers can thoroughly test the ECU without a vehicle or even an engine using HIL simulation. A HIL test system performs two main functions: it simulates the physical system with which the ECU will interact, and it performs test executive functions such as stimulus generation and test result data logging. Stimulus generation of an engine ECU might entail creating a series of desired engine speeds (to simulate pushing the gas pedal) and a series of vehicle loads (which may represent a variety of different road conditions). The entire system would be observed to ensure that all components operate correctly and the test results would be logged for comparison to ideal system response.
Figure 3: An HIL user interface that includes commands to send to the ECU as well data received from the simulated system. Increasing Efficiency with HIL Simulation HIL simulation is a way to efficiently test embedded control devices such as ECUs. While HIL simulation does not replace the need for physical testing, it does help engineers accomplish the following by enabling tests earlier in the development cycle and eliminating the need for a physical system during test: Test earlier in the development process – identify design errors earlier when they are less expensive to correct and have a smaller impact on time to market
Reduce testing cost – reduce capital, repair, and maintenance expenses for test fixtures without the need for a physical system
Increase test coverage – test ECUs under extreme conditions that might not be practical for physical testing due to safety or equipment damage concerns
Increase test flexibility – simulate winter road conditions for a vehicle under test even in the heat of summer
Increase test repeatability – isolate deficiencies in an ECU even if they occur only under certain circumstances
Figure 2: An example diagram of a common HIL test system. The other primary function of an HIL test system is to simulate the components that interact with the ECU. To understand how this is accomplished, let’s first consider what an ECU “knows” about the world around it. A typical ECU consists of an embedded controller with integrated electronics for sensor signal conditioning and digital communications. From the ECU’s perspective, an accurate simulation of the characteristics of the physical system being controlled is indistinguishable from the actual system. Simulation models are commonly used to represent the behavior of this physical system. It is critical that an HIL simulator be able to generate and acquire signals at the same amplitude and rate that a physical system would produce to accurately test the ECU’s response to real-world conditions. A real-time operating system is commonly used to ensure that these timing requirements are met. Depending on the complexity of a system being simulated, parallel processing techniques such as FPGAs and multi-core processors may be necessary to complete output response calculations while maintaining timing accuracy.
HIL Test System Architectures Components of an HIL Test System An HIL test system consists of three primary components: a real-time processor, I/O interfaces, and an operator interface. The real-time processor is the core of the HIL test system. It provides deterministic execution of most of the HIL test system components such as hardware I/O communication, data logging, stimulus generation, and model execution. A real-time system is typically necessary to provide an accurate
simulation of the parts of the system that are not physically present as part of the test. The I/O interfaces are analog, digital, and bus signals that interact with the unit under test. You can use them to produce stimulus signals, acquire data for logging and analysis, and provide the sensor/actuator interactions between the electronic control unit (ECU) being tested and the virtual environment being simulated by the model. The operator interface communicates with the realtime processor to provide test commands and visualization. Often, this component also provides configuration management, test automation, analysis, and reporting tasks.
Figure 6. Automobiles, aircraft, and wind farms use multiple ECUs. When testing a multi-ECU control system (and even some single ECU control systems), two needs often arise: additional processing power and simplified wiring.
Figure 4. An HIL test system consists of three primary components: an operator interface, a real-time processor, and I/O interfaces.
Hardware Fault Insertion Many HIL test systems use hardware fault insertion to create signal faults between the ECU and the rest of the system to test, characterize, or validate the behavior of the device under these conditions. To accomplish this, you can insert fault insertion units (FIUs) between the I/O interfaces and the ECU to allow the HIL test system to switch the interface signals between normal operation and fault conditions such as a shortto-ground or open circuit.
Additional Processing Power – Distributed Processing Even with the latest multicore processing power, some systems require more processing power than what is available in a single chassis. To address this challenge, you can use distributed processing techniques to meet the performance requirements of these systems. In very high-channel-count systems, the need is more than simply additional processing power, additional I/O is also necessary. In contrast, systems using large, processor-hungry models often use additional chassis only for the extra processing power, allowing those processors to remain dedicated to a single task for greater efficiency. Depending on how the simulator tasks are distributed, it may be necessary to provide shared trigger and timing signals between the chassis as well as deterministic data mirroring to allow them to operate cohesively.
Figure 5. You can use hardware fault insertion to test the behavior of the ECU during signal faults.
Testing Multi-ECU Systems Some embedded control systems, such as an automobile, aircraft, or wind farm, use multiple ECUs that are often networked together to function cohesively. Although each of these ECUs may initially be tested independently, a system’s integration HIL test system, such as a full vehicle simulator or iron bird simulator, is often used to provide more complete virtual testing.
Figure 7. When using multiple chassis for additional processing power, it is often necessary to provide timing and data synchronization interfaces between them.
Simplified Wiring – Distributed I/O Implementing and maintaining wiring for high-channel-count systems can pose costly and time-consuming challenges. These systems can require hundreds to thousands of signals be
connected between the ECU and the HIL test system, often spanning many meters to compensate for space requirements. Fortunately, deterministic distributed I/O technologies can help you tame these wiring complexities and provide modular connectivity to ECUs, which allows for efficient system configuration modifications. Instead of routing all connections back to a single rack containing one or more real-time processing chassis instrumented with I/O interfaces, you can use deterministic distributed I/O to provide modular I/O interfaces located in close proximity to each ECU without sacrificing the high-speed determinism necessary for accurate simulation of the virtual parts of the system. This approach greatly reduces HIL test system wiring cost and complexity by making it possible for the connections between the ECU and the I/O interfaces to be made locally (spanning less than a meter) while a single bus cable is used to span the additional distance to the real-time processing chassis. Additionally, with the modular nature of this approach, HIL test systems can easily scale, incrementally, from a multi-ECU test system in which all but one of the ECUs are simulated to a complete systems integration HIL test system where none of the ECUs are simulated.
SUMMARY/CONCLUSIONS Business and technical challenges will continue to grow in the automotive industry. By enabling tests earlier in the development cycle and removing the limitations of physical test, HIL simulation is helping to reduce development cost and increase the quality of vehicles in the face of these challenges.
CONTACT INFORMATION Name: Marcos Cardoso Email: marcos.cardoso@ni.com Cell phone: +55 11 8603 0683
DEFINITIONS/ABBREVIATIONS HIL: Hardware-In-the-Loop ECU: Electronic Control Unit I/O: Input/Output FIU: Fault Insertion Unit
Figure 8. Deterministic distributed I/O interfaces greatly reduce HIL test system wiring cost and complexity because the connections between the ECU and the I/O interfaces can be made locally.
The Importance of HIL Test System Flexibility There are many options for implementing HIL simulation as part of your test system. To ensure the short- and long-term success of your investment, it must be both flexible and open. With the drive to continually reduce the cost of test, a flexible solution is essential to making HIL simulation practical in your development process. An effective HIL simulation solution should be able to rapidly adapt to changes encountered during and between development cycles. A small change in the test process or configuration should not require a major renovation of your HIL simulator. An open HIL simulation solution ensures that you will always be able to integrate the technologies required to test your ECU.