“In a highly competitive and time-sensitive market like automotive, it is crucial to test new solutions before they are fully realized. Model-in-loop test makes this possible by creating mathematical models that represent the solution in a part-real and part-virtual manner.”
It’s a busy day for the automotive team of a tier-1 company. Engineers are rushing to complete the modules assigned to them so that the unit testing can be performed. The engineers are worried about multiple testing iterations that would follow the module development. The deadline is fast approaching. It is a moment of calm before the project manager goes into a tizzy and starts questioning the team about the delay. Oh.. that’s a messy situation to be in!
One good decision at the beginning of the project and all of this could have been avoided. If the automotive team had taken the model-based design approach, the situation would be much different.
Model-in-loop testing would start with models that would virtually represent each unit under test. Early detection of bugs and errors would be possible to ensure a bug-free solution and developers would be spared from the pains of manual coding, a win-win for all stakeholders.
What is Model-in-Loop Testing?
Model-in-loop testing is a technique to represent the behaviour of an embedded system in the form of mathematical models. These models are used to verify the system or the sub-system.
Testing automotive embedded software at the model-in-loop level is the first step in the process of V&V. It implies that the controller and the hardware are simulated using models in a simulation environment. And that the controller model is able to control the plant model (hardware) as per the specified requirements.
Such testing helps in verifying the software very early and bugs can be identified before they creep into the program. Needless to mention that rectifying errors at a model level is inexpensive compared to a fully realized ECU.
MIL test proves to be very effective when it is performed along with the process of model creation or shortly after that. Since MIL is a requirement-based test, the test cases are derived directly from the requirements for the automotive software under test.
One of the reasons why model in loop test has been adopted so widely in the automotive industry is the availability of simulation tools and environment such as SIMULINK. Designing the plant model, controller model and the complete test harness have been simplified to a large extent. The much-needed traceability is provided by these tools and hence, they are also recommended by standards such as ISO 26262 and ISO 21434 (cybersecurity).
No amount of theoretical explanation can actually get you the real picture of how MIL testing is performed and what impact it does have on the development lifecycle. So, lets take a deep dive into understanding the MIL test setup for testing a real-world automotive application.
Model-in-Loop in Action- MIL Test Setup for an Automotive Lighting Module
Automotive lighting modules are used for safety-critical applications to display faults or failure. This requires lighting systems to be fail-safe as well. Therefore, model-based approach works best for development of such modules.
We will try to understand the MIL test setup for the development of an automotive lighting module. Right from requirement elicitation and test case creation to building the test harness and executing the tests, let’s witness MIL test in action.
Solution Under Development- An Automotive Lighting Module for a Headlamp
Inputs to be considered while performing MIL test for this automotive lighting solution is ignition, switch, and intensity.
The outputs are left lamp and right lamp.
Requirement– If the ignition is ‘on’ and if switch is ‘on’, the lamp has to be turned on.
Step-1
Intensity 0 to 100% based on the input given by the user using a button or through infotainment system.
Based on these requirements, the test strategy will be designed. Let’s understand the test strategy for the requirements mentioned above.
- Initially, the switch is ‘off’.
- It is now turned-> on; now we check the intensity of the lamp for a duration of 100 seconds (can be changed)
- Now, in order to test the intensity for 0-100 seconds, we have to give the inputs from 0-100 seconds.
- In the test description, the pre-conditions and the expected results are already logged. Since, we are required to test both the true and false condition, we will test with both ignition ‘on’ and ignition ‘off’ scenario. As have taken 100 seconds as the testing time, we will keep the ignition ‘on’ for first 50 seconds and ignition ‘off’ for the next 50 seconds.
Step-2
The entire testing pre-conditions and inputs that we described above are achieved by a signal builder block.
This block creates the corresponding test data usually from an excel sheet (test vector sheet) containing all the relevant data. The data points required for the current MIL test are- time, ignition status, switch status and intensity.
Step-3
There is one more column in the test vector sheet which is the expected result. During the test, the output result will be compared to the expected result and hence, test pass/fail will be evaluated.
Step-4
The data from the test vector sheet can be imported to the signal builder block with the help of a few clicks on SIMILINK tool. After the import, the data from the test vector sheet is displayed as a wave form.
For the current test, we get three wave form graphs-
- Time and ignition status
- Time and intensity
- Time and switch status
Step-5
Now that the signal builder block is ready, we need to connect it to the control model which virtually represents the automotive ECU with the lighting module application.
But before we get ready to test the signals, we must first log the expected result to which the actual output will be compared.
We will use signal logging option in the SIMULINK tool to log the expected results. To do so, we must carry on one simulation using the same inputs and log the expected result. Logging for expected result will now be stopped and logging for model signals will begin. The simulation will be done once again. The point to be noted here is that logging of both expected result and actual result from the model must be in the same name.
Step-6
Now that we have both expected results and the actual output from the model, we can now compare and inspect whether the test failed or passed.
Using data inspector tool, we can compare both results. An html report is generated upon comparing that clearly shows the pass/fail status.
Conclusion
Automotive OEMs and tier-1s are always looking to beat the clock when it comes to building innovative automotive solutions. After all, these solutions become the USPs in an industry as competitive as automotive.
Model based design approach, along with Model-in-Loop testing, play a crucial role in enhancing the efficiency of automotive software development and validation.
