Anatomy of a Successful MBD Implementation for ECU Software

Model-based software development allows for the simulation of models on the host PC at an early stage and shorter development times. There are some preconditions that need to be met to generate a successful project. First of all, a clear and complete set of specifications of the desired behavior of the result needs to be present. This can be either informal or formal requirements. Also, a workflow needs to exist in place to detect any errors, as early as possible.

The BTC Embedded Specifier can be used for the translation of informal requirements into semi-formal or formal requirements. The Requirements Management Interface (of the Simulink Verification and Validation Toolbox) can be used to specify references from the model to the requirements. The dSPACE TargetLink code generator can then generate code with requirement traceability.

The next step would be to design models based on the above requirements. In this case, it is essential to design well-structured models by following guidelines like the MAAB guidelines, MISRA modelling guidelines for TargetLink, and the TargetLink Modeling Guidelines. It is possible to verify that the above mentioned guidelines are strictly adhered to, including any company specific guidelines that may exist, using third party tools like the MES Model Examiner or the Schaeffler Engineering StyleChecker.

It is crucial to perform functional verification on the model level, which can be done using several different tools. Model coverage tests can be performed using the Simulink Verification and Validation toolbox to verify that all parts of the model are stimulated. It is also possible to run the TargetLink models in a prototyping environment using the TargetLink stand-alone Blockset. Third party tools like the BTC Embedded Validator can be used to verify the model against the formal requirement specifications.

Once code is generated, static code checks to prove the absence of run-time errors like division by zero, exceeding array range limits etc., can be verified using third party tools like Astree (AbsInt), Polyspace (The Mathworks). Code review can be done using the HTML code files that can be generated by TargetLink containing variables and other elements with hyperlinks to the model or DataDictionary.

Back-to-back testing between the model and the generated code can be done using the MIL and SIL simulation comparison, which is available in TargetLink. This can provide verification that the floating-point Simulink model is correctly translated into fixed-point code. Automatic test execution and evaluation can be performed using third party tools like the BTC Embedded Tester and PikeTec TPT. Code coverage testing can be done using the built-in functionality of TargetLink or third-party tools.

It is essential to run simulations with inputs of all use cases for successful testing. TargetLink provides both statement coverage, as well as decision coverage. BTC Embedded Tester can help create and manage the test vectors. It can also link test cases to requirements and generate code coverage reports for requirements, model and code.

For Functional verification on the code level, the TargetLink stand-alone model manager can be used to generate the production code, wrap it in an s-function frame, and run it on dSPACE prototyping hardware like MicroAutobox or DS1005. TRC file entries will be generated for global variables, which can be used in a tool like ControlDesk for measuring. dSPACE VEOS can be used to run virtual ECU simulations on a PC or evaluation board. BTC Embedded Tester can be used to check formal requirements during the above simulations.

Thus, the complete software development process − which starts with the requirements, then model designing, model verification, code verification and the testing process − can be achieved using TargetLink and other third-party tools for the different stages, as applicable.