Verification of MBD-based Controller using xIL (MIL, SIL, PIL and HIL)

So, you are an ASW (automotive software) engineer at an automotive company. You have developed a new function and would like to test it against the given requirements. Of course, you can straight forward flash this new piece of code in the test vehicle, take it out for a spin. Tweak the controller model, tune the calibrations and once you are satisfied, freeze the software and calibration set. However, if you’ve done this in the past, you know that this isn’t as simple as it sounds. You might find that the test vehicle is not ready! Its battery could be discharged, fuel might be low, a part might have been removed for inspection by test vehicle owner or ECU might have been removed by hardware team for some test. I remember a case when I connected INCA (measurement and calibration tool) and couldn’t connect to the ECU. Upon some debugging, I found that the ECU was disconnected from power supply!

More appropriate and far better rewarding alternatives here are bench level tests like HIL. And even before that you can perform PIL/SIL/MIL! What is the scope for each and when to use what?

A product passes through the following large stages during its development cycle:

1. Proposal and project plan
2. Requirements gathering and analysis
3. Design and Development
4. Verification and Validation
5. Field testing
6. PPAP and other audits

And some more

MIL, SIL, PIL and HIL tests are part of verification stage specifically when a product is produced using Model Based Design (MBD) approach. Historically, critical as well as complex and nowadays even relatively less complex automotive products are developed using MBD environment. A lot of companies are porting their legacy products developed using embedded C to MBD (e.g. MATALB Simulink and Stateflow) environment due to the proven benefits. Verification happens before validation. Verification comprises mostly of software-based tests (i.e. simulation based testing) and is target independent. Whereas validation comprises of target hardware-based tests where the final software and hardware are vetted against all the requirements.

Model in the loop (MIL) simulation

A controller in the form of Simulink and Stateflow blocks is tested against an emulated plant model. A plant model could be as simple as series of breakpoints mimicking physical signal or a dataset or a digital twin or it can be a model developed using Simulink and Stateflow or Simscape blocks. The simulation testing can be 0D or 1D based on the requirements, availability of 1D plant models, etc. It is called MIL because “model” of the controller is tested with the plant (model, data, code, doesn’t matter in which form this is as far as it is compatible for MIL). Controller is at the center since that is our product. At this step, idea is to detect and resolve any functional and logical errors. Until the controller functions as expected, there is no point in converting it in C/C++, right? ?

Software in the loop (SIL) simulation

Now, in the above case, if the “model” of the controller is replaced by “software” of the model, the simulation testing is called SIL. Since now the software (C/C++ code) of the controller is in loop with the plant (again the form of the plant is immaterial as far as it is compatible for SIL). This is one step higher than MIL since here code-generation errors are detected and resolved. This step also verifies whether the controller model is compatible with MATLAB’s automatic Codegen tool or not. Unless target hardware compiler compatible code can be generated using our controller model, there it no point in compiling it!

Processor in the loop (PIL) simulation

Now, in the above case, if the “software” of the controller is replaced by “a processor with compiled and flashed controller”. There are some variations where one can either use a RCP processors or use the target microcontroller on a development board especially developed for PIL. It is called PIL since now the processor (with compiled and flashed controller) is in the loop with the plant (again the form of the plant doesn’t matter as long as the data flow is compatible with processor. This step requires appropriate interfaces, data communication channel and protocol for data exchange between the controller (on HW) and plant (in SW). This step verifies that generated code compiles (along with other binaries, libraries and legacy code, if any) and works on a generic or target processor. This step vets our developed controller against memory and compute requirements. It is the most important step since this is make-or-break step for choosing MCUs. Unless the controller compiles and works on a proven general processor architecture, no point testing it on a specific hardware with a lot of unknown peripheral circuits and (sometimes) new microcontroller architecture, right?

Hardware in the loop (HIL) simulation

Now, in the above case, if we were to replace the “processor with controller” by the actual hardware on which we intend to run our controller in real time, it becomes hardware in the loop. Since our “hardware controller” is tested against plant model (here the plant is in software form). If the actual physical system is used for testing the hardware controller, it becomes final validation. If there is an intermediate step where the final controller software is flashed on an RCP (rapid control prototyping) board, it becomes RCP test. And then there are many variations depending on the intent of the software simulation testing or hardware testing. This step helps resolve hardware circuits and chip related issues since software plant models are not very accurate (more fidelity costs more time, energy and money). Another advantage of HIL is low-cost testing of safety-critical and expensive tests. Strategy is to refine the product as much as possible before the final validation or regulatory tests e.g. vehicle crash test. ??

This concludes a basic overview of various verification tools available to an ASW engineer. I hope this article brought more clarity to what each test is and how each can add value to your MBD-based product development process. If you liked reading this article, do hit the like button, this serves as your feedback to me for this post and inspires me to continue writing about similar topics from technology and engineering. Please feel free to share your suggestions and feedbacks in comments section.

Thank you and I'll see you soon!

-Sanjay