Hello Readers,
My name is Aravind, and I work as a junior software engineer at Luxoft India. I'm happy to share this post, in which I relate my previous experience with HIL testing. This is the fundamental concept of HIL (Hardware-in-the-Loop) testing.
Introduction
Hardware-in-the-Loop (HiL) methods verify and validate the software implemented in the physical target Electronic Control Units (ECUs). Therefore, HiL test benches need to provide realistic real-time stimuli and load simulation to the ECUs to let them perform as if they were built into a real vehicle. Multiple ECUs are tested additionally in system and integration tests, e.g. network HiL setups. Thereby, tests of the complete electrical setup of a vehicle including its bus systems, sensors and actuators are possible. The more recent approach of Vehicle-in-the-Loop (ViL) replaces the vehicle simulation (and therewith most of the virtual ECUs, too) by a physical car. These testing methods enable short feedback cycles and figure 1 visualizes their usage along the V-Model
Hardware In the Loop (HIL) Test
Unit Model Testing or Component testing in a non-model based development procedure would identify noncompliance within individual components of the module under development. Integration Testing is used to analyze the behavior of modules in a simulated environment. Typically this is accomplished by running application source code on a simulated PC environment. Module requirements are tested by analyzing the accuracy of the interfaces between architectural components; this is accomplished with what Lear calls ECU Module Testing or where we introduce hardware-in-the-loop or HIL testing. The final testing to be completed in embedded system is determining the compliance to customer requirements or in the case of automotive modules, vehicle testing. Each of these testing levels is a succession of the previous; that is, they are built on the previous test cases. As you ascend the different levels of testing, the tests themselves become far less numerous. This is because as you move the scope of your testing out further; less control is available at the next abstraction. To that end, HIL testing is the next step after the integration and unit model testing steps in presented model.
Concept and Aspects of Virtual Testing
The fundamental idea of virtual testing is to perform development, verification and validation tasks much earlier in the V-cycle than usual. This includes a smooth transition from virtual testing to HIL testing. In addition, the dependency on the availability of ECU prototypes is significantly reduced. Prototypes are expensive and cannot be multiplied at will or used in several projects simultaneously. Overall, virtual testing answers the need for early simulation that the aerospace industry is currently experiencing, as well as the automotive industry. The concept of virtual testing makes use of software-based emulations of real ECUs. The required simulation depth (i.e., how close it is to reality) depends on the application case. In order to simulate solely the functional behavior of an ECU, so-called soft ECUs or ECU behavior models are used. These soft ECUs are usually constructed in Simulink and provide representations of the functional behavior of a missing ECU. More complex models comprise components from the application and the basic software, & provide functionalities comparable to those of a real ECU. These are referred to as virtual ECUs. There is no strict dividing line between a soft ECU and a virtual ECU, but a virtual ECU generally represents the real ECU more realistically.
Virtual testing has three main aspects: (1) Running PC-based offline simulations, (2) preparing HIL tests on a PC, and (3) using emulated ECUs in HIL simulation if the real ECU is not available.
(1) Running PC-based offline Simulation
PC-based offline simulations (also referred to as offline simulations) are mostly non-real-time simulations. One purpose for offline simulation is to validate, verify and test ECU software in the form of virtual ECUs without additional hardware. It enables the test and validation of software components as well as the interactions between them. The latter is important for today's networked ECUs, since the number of software components in large ECU networks is usually shared by different departments or different suppliers. Another purpose for offline simulation is to mimic the functional behavior of systems or subsystems by using soft ECUs. Offline simulation can also be conducted at any stage of the development process.
(2) Preparation of HIL Tests
Preparation of HIL tests by means of virtual testing means to apply PC-based simulation in order to set up, parameterize and test plant models, and run automated tests, without actually using a HIL system. This enables maximizing HIL testing time, while model validation and test development can be done in parallel on a PC. HIL test engineers can use the same tools, models, tests, layouts, data, etc. as those used for real ECU testing. They can either reuse existing layouts that were previously created for the HIL system, or create new ones that can be reused on it later. Either way, models, layouts and tests are created only once and can be reused across the different development stages to save time and effort.
(3) Emulated ECUs in HIL Simulation
Using emulated ECUs in HIL simulation with or even without other items is the logical next step. In today's HIL scenarios, if tests on one ECU require other ECUs to be present, but these are not yet available when the tests are run, so-called soft ECUs or ECU behavior models are already used. Using virtual ECUs for more realistic simulations of the ECU behavior enables
additional tests without having the real ECU available. Of course, these emulated ECUs need to be easy exchangeable with real ECUs as soon as they become available.
Figure of emulated ECUs and real ECUs for HIL testing of an ECU network.
Tool Chain for Virtual Testing and HIL Testing
HIL testing requires a tool chain that enables users to configure and control tests, perform tests automatically, parameterize tests and visualize test results. In addition, a tool for test data management is required on top of these tools. Figure 2 visualizes these software tools together with the other hardware and software components that are part of a HIL system.
The same functionalities that these tools provide are also required for virtual validation. There are of course exceptions, such as there is no need for hardware configuration for offline simulation. Regardless of this, an efficient use of virtual testing and a seamless transition from virtual testing to HIL testing requires tools that are applicable for both use cases:, i.e., the tool chain for virtual testing should be the same as for HIL testing (Figure 3).
Figure 3 Tool chain for virtual testing and HIL testing.
The advantages are obvious: virtual testing is economical, and requires less training and maintenance. Other benefit is that it harnesses the knowledge of the company's test experts, since know-how can be transferred from virtual testing to HIL testing.
This will be continued in the next article alone, with examples.
Do let me know if you have any queries in the comments below.
Thanks for reading.
Top comments (0)