Building better automotive applications with MIL testing

Article By : Manu Kumar and Vaibhav Anand, Embitel

Model-in-loop (MIL) test creates mathematical models that represent the design 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’s 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.

The primary reason is that model-in-loop (MIL) tests can be performed very early in a model-based development process. The requirements list for performing an MIL test is limited. You need only non-physical resources, including the model, software requirements and a simulation environment, preferably SIMULINK/MATLAB. Hence, MIL tests can be performed well before the software is generated or hardware is available. Early test execution and failure detection result in cost reduction and improvement in quality.

What’s model-in-loop testing?

Testing an embedded system on MIL level means that the model and its environment are simulated (interpreted) in the modelling framework without any physical hardware components. This allows testing at early stages of the development cycle.

These models are designed to meet the requirements from a software engineering standpoint. Aspects such as encapsulation, abstraction, robustness, performance, fixed-point scaling, and reuse are treated in implementation models.

MIL testing is a technique to represent the behavior 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 MIL level is the first step in the process of verification and validation (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, so 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 electronic control unit (ECU).

MIL test proves to be very effective when it’s 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 MIL 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. Next, the much-needed traceability is provided by these tools, and hence, they are also recommended in standards such as ISO 26262 for functional safety and ISO 21434 for cybersecurity.

MIL: Automotive engineers’ perspective

The term ‘model-in-loop testing’ is widely used today in different industries and has assumed distinctive meanings. From the lenses of the automotive industry, it’s commonly used to describe the V&V activities in the context of model-based development projects. Automotive model-based development has certain distinctive characteristics that warrant the use of dedicated model-based testing approaches.

MIL testing would start with models that virtually represent each unit-under-test. As a result, 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.

Automotive systems are built to interact with a real-world environment. It’s made possible by a complex set of modules that comprises software, hardware, and electrical, mechanical and hydraulic components. The iterative nature of such development projects demands testing each interim release with the same test cases. So, test automation is the only plausible solution to reduce time and cost incurred in such iterative testing, not to mention the bugs that may be missed due to human error.

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. Now, let’s take a deep dive into understanding the MIL test setup for testing a real-world automotive application.

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 articulate 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.

The inputs to be considered while performing the MIL test for this automotive lighting solution are ignition, switch, and intensity.

Figure 1 The snapshot of signal builder block shows different input signals for testing. Source: Embitel

The outputs are left lamp and right lamp.

The requirement is that if the ignition is ‘on’ and if switch is ‘on’, the lamp must be turned on. Intensity of 0 to 100% is 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.

Step 1

  • Initially, the switch is ‘off’.
  • It’s now turned on and 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 generate 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’ scenarios. As it takes 100 seconds for the test 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, 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 waveform.

For the current test, we get three waveform graphs:

  • Time and ignition status
  • Time and intensity status
  • 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 for 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 the data inspector tool, we can compare both results. An HTML report is generated upon comparing that clearly shows the pass/fail status.

Figure 2 The snapshot of data inspection tool shows left lamp output. Source: Embitel

Figure 3 The snapshot of data inspection tool shows right lamp output. Source: Embitel

Beating the clock

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 unique selling points (USPs) in an industry as competitive as automotive.

The model-based design approach, along with MIL testing, plays a crucial role in enhancing the efficiency of automotive software development and validation.

 

This article was originally published on EDN.

Manu Kumar, a senior software engineer at Embitel, focuses on model-based design paradigm.

Vaibhav Anand is a digital-marketing professional at Embitel with a deep-rooted interest in everything automotive.

 

Leave a comment