Susanne Köhl

How to Do Hardware-in-the-Loop Simulation Right

Not only is the number of electronic control units (ECUs) in modern vehicles constantly increasing, the software of the ECUs is also becoming more complex. Both make testing a central task within the development of automotive electronics. Testing ECUs in real vehicles is time-consuming and costly, and comes very late in the automotive development process. It is therefore increasingly being replaced by laboratory tests using hardware-in-the-loop (HIL) simulation. While new software functions are still being developed or optimized, other functions are already undergoing certain tests, mostly on module level but also on system and integration level. To achieve the highest quality, testing must be done as early as possible within the development process. This paper describes the various test phases during the development of automotive electronics (from single function testing to network testing of all the ECUs of a vehicle). The requirements for the test system and corresponding concepts are described. The paper also focuses on test methods and technology, and on the options for anchoring HIL simulation into the development process. HARDWARE-IN-THE-LOOP SIMULATION: AN ESTABLISHED PART OF THE CONTROL DEVELOPMENT PROCESS Time to market is speeding up, especially in automotive electronics. 90% of automotive innovations are currently connected with new electronics. Test drives can scarcely cope with the volume of systematic testing needed, especially just before start of production. The growing number of recall campaigns is a clear indication of this. It is little wonder that testing and error finding have become key tasks in the development process. [5] ECU testing typically is done using hardware-in-the-loop simulation. The ECU (prototype) is connected to a realtime simulation system simulating the plant (engine, vehicle dynamics, transmission, etc.) or even the whole vehicle. One means of reducing development times is to schedule early availability of the test system, which can be achieved by integrating HIL into the development process and involving the HIL system supplier as soon as ECU specification is available. This allows the simulator to be up and running shortly after receipt of A-, B-, and C-sample ECUs. Automated tests increase test coverage and shorten testing times by running complete test suites and overnight tests. HIL systems testing 24 hours, 7 days per week are not fiction but reality. Another measure taken by the OEMs is to transfer testing responsibility to the suppliers. Nowadays suppliers are more and more forced to perform early HIL tests. This not only includes function tests during function design but also complete integration and acceptance tests. The need for suppliers and OEMs to exchange tests, test results, models, etc., is important in this context. DIFFERENT USERS DIFFERENT NEEDS As HIL has become a standard method for testing ECUs and control strategies during the whole development cycle (i.e., not only after availability of the final ECUs), different needs of different users have to be addressed by the various test systems. Figure 1 shows the various HIL applications and the resulting test contents of the different phases. Figure 1.: Usage of HIL during the development process. FUNCTION DEVELOPER AT ECU SUPPLIER (OR AT OEM) Typically, only prototype ECUs are available during function development. Microscopic tests on a function are essential at this stage. The control strategy itself needs to be validated. Flexible, interactive operation needs to be possible. The simulator hardware also needs to be flexible for easy adaptation to changes in the ECUs or its peripherals. Low automation is typically required. During this development phase, test scripts are often set up in parallel to ECU/function development, or even after ECU/function development has finished. Even though the diagnostics procedure must also be tested, it might be necessary to deactivate some diagnostics of the ECU during function testing. The diagnostics depend on signal values that have to be calibrated. Often the calibration of the ECU functions is done prior to calibrating the diagnostics, which necessitates deactivation.. The typical objective of this phase is function acceptance testing. Ideally, this is automated by running the test scripts for all modules. Reusing control functions for different OEMs requires flexible HIL systems that can be adapted to the different ECU variants. Administration of the HIL software components, such as partial models and test scripts, is also needed. To avoid redundancy, tests successfully performed during function development should not have to be repeated during integration testing. While at this stage, functions are verified by HIL tests, it is important to test the proper interaction of all functions during integration testing. Close cooperation between supplier and OEM is therefore desirable, to exchange test protocols on the one hand and models (which are typically available at the OEM) on the other. In the case of function development at the OEMs (which typically still requires function integration into the final ECU provided by a supplier), the test process is quite similar to the process described above. Exchanging models and tests is far easier, however, as the exchanged data remains under the same roof. ECU PROJECT MANAGER AT THE OEM (OR SUPPLIER) – RELEASE AND ACCEPTANCE TEST Once all the functions have been integrated together with the lower software levels (operating system, I/O drivers), macroscopic testing of the complete ECU and/or its functions needs to be performed. This includes tests on overlapping administration layers (handling of diagnostic memory). Either the manufacturer or supplier performs an ECU release test. Automated tests are indispensable at this stage. The HIL should only be used interactively to find the cause in the event of an unexpected error. Manufacturers definitely need to repeat tests on ECUs that are provided by different suppliers (second source). Flexible systems that can be adapted to various ECU types are required at this stage. However, the administration of the simulator’s software components (partial models, test scripts, etc.) is even more important. Experiment software layouts represent the functionality of the test system. The objective is to release the complete ECU as errorfree including diagnostics. VEHICLE ELECTRONICS SYSTEM MANAGER AT THE OEM As already mentioned, tests that were already finished on component level should not be repeated when networked systems are tested, for efficiency reasons. In an examination of release tests for the complete vehicle electronics, the focus lies explicitly on testing distributed functions and testing bus communication. Network management is also one function under test in this context. Another important issue comes into play at this stage, if it has not already done so: variant handling. Countryspecific variants for a worldwide market presence, as well as different equipment variants and frequent revisions in model cycles, make it necessary to handle different configurations. As a result, combinatorial tests for the various ECU/vehicle variants are required. This again requires a flexible system based on hardware and software that support different variants in plant models, I/O channels, and bus communication. Automated tests are indispensable here. Tests designed for the system can easily be replayed for all ECU/vehicle variants. The higher the degree of automation, the higher the test coverage. Only a few of the tests established on function level should be reused here. Another important aspect of automated tests is that tests, which verified performance during the development phase, can also be used to investigate warranty issues after series production has started. The complete system must be error-free including diagnostics. WHAT NEEDS TO BE CONSIDERED WHEN CONFIGURING/SELECTING A SIMULATOR? Instead of being connected to an actual vehicle, the electronic control unit(s) to be tested are connected to a hardware-in-the-loop simulation system. Software and hardware models simulate the behavior of the vehicle and related sensors and actuators. The models were typically developed with a suitable modeling tool, such as MATLAB®/Simulink®. C code is generated automatically and downloaded to real-time processors for execution. I/O boards, together with signal conditioning for level adaptation to the automotive voltages required by the ECU, provide the interface to the ECU pins. Figure 2 shows a typical hardware-in-the-loop system architecture [1]. The most important components of an HIL system are described below. Figure 2.: Typical hardware-in-the-loop system architecture.

Steuergeräte-Verbundtests mittels Hardware-in-the-Loop-Simulation

Die fur Innenraumkomfort und passive Sicherheit zustandige Elektronik des neuen Opel Vectra zeichnet sich durch ein Netzwerk zahlreicher Steuergerate unterschiedlicher Hersteller aus. Der Test dieses Steuergerate-Verbunds ist besonders aufwandig. Bisherige Testmethoden stosen schnell an ihre Grenzen. Durch den Einsatz von Hardware-in-the-Loop-Simulation erreicht Opel eine grose Testfallabdeckung und Testtiefe. Der Nutzen des eingesetzten Hardware-in-the-Loop-Simulators wird durch die Automatisierung der Tests deutlich erhoht. Zukunftig sollen automatisierte Tests auch auf fruhere Phasen der Steuergerate- Entwicklung ausgedehnt werden.

ECU network testing by hardware-in-the-loop simulation

The electronics responsible for the comfort and passive safety systems in the new Opel Vectra involve a network of numerous electronic control units (ECU) from different manufacturers. Testing the ECU network is a particular challenge. Existing test methods soon come up against their limits. By using hardware-in-the-loop simulation, Opel achieves extensive test coverage and depth. Test automation considerably enhances the benefit of using the hardware-in-the-loop simulator. In future, test automation will also be extended to earlier phases of ECU development.