An ISO 26262 Workflow for Automated Driving Applications Using MATLAB: Guidelines and Best Practices
By Lars Rosqvist, MathWorks
The use of Simulink® and Stateflow® for ISO® 26262 software development is well established for automotive ECUs. There is a growing trend, particularly in automated driving applications, toward implementing software designs using MATLAB® functions as well as Simulink blocks and Stateflow charts. This article offers best practices for using a MATLAB-centric workflow to verify compliance with ISO 26262 software standards [1]. These best practices complement the ISO 26262 Reference Workflow using Model-Based Design illustrated in IEC Certification Kit.
Recommended Modeling Pattern
In this article, we use a software development pattern in which a Simulink model incorporates a MATLAB Function block (Figure 1). The top layer Simulink model carries all the configuration settings for code generation. The MATLAB Function block calls external MATLAB functions.
Figure 1. Modeling pattern using external MATLAB code.
This modeling pattern takes advantage of all the verification and validation tools available for Simulink models while enabling functionality to be implemented using the MATLAB language [2]. It also takes advantage of the extensive capabilities available in MATLAB. For example, ADAS development is typically implemented using MATLAB because complex mathematical functionality can be expressed in a concise, elegant way.
There are alternative ways to use MATLAB [3] in a safety-critical product development environment, which is not mentioned in this article.
MATLAB ISO 26262 Reference Workflow: Overview
As mentioned earlier, the workflow described in this article is based on the ISO 26262 Reference Workflow in IEC Certification Kit (Figure 2).
Figure 2. Verification and validation activities specified in IEC Certification Kit.
The MATLAB-based workflow includes additional recommendations for the following verification and validation activities:
- Requirements authoring and architecture verification
- Static model analysis
- MIL testing and SIL or PIL back-to-back testing
- Static code analysis
- Documentation
Requirements Authoring and Architecture Verification
ISO 26262 requires evidence that all requirements have been implemented and tested. In the ISO 26262 Reference Workflow, the Architecture Verification and Requirements Authoring activities highlighted in Figure 3 provide this evidence.
Figure 3. Requirement linking activities.
Linking Requirements to MATLAB Code
Using Requirements Toolbox™, you can link requirements to lines of code in MATLAB functions in the same way that you link requirements to Simulink blocks. The difference is that the existing check for missing requirements does not check external MATLAB code. The recommendation is that you implement a Model Advisor check that looks for MATLAB containers not linked to a requirement. A container is typically the external MATLAB file or a MATLAB function, depending on the size of the file.
Static Model Analysis
Each component in the implementation model must be checked for readability, understandability, and testability (Figure 4). Simulink Check™ is used to assess the compliance of model to ISO 26262 and MathWorks high-integrity guidelines.
Figure 4. Static model analysis activities specified in IEC Certification Kit.
Language Subset
Programming in MATLAB can involve the use of functions from several different toolboxes. Since MATLAB is a powerful language with a high degree of abstraction, you can develop complicated functionality with a few lines of code. In some cases, a single line of MATLAB code can result in many lines of C code, making the generated code hard to verify with full coverage. You need to know that the functionality you are implementing is testable. ISO 26262 stipulates the use of a language subset (Table 1 in ISO 26262) based on the type of functions you are using.
We recommend that you take the following steps to meet the language subset requirement:
- Assess used MATLAB functions to ensure that none of them require high verification effort. Model Advisor can be used to identify usage of non-recommended functions due to code complexity.
- Replace non-recommended MATLAB functions with simpler implementations. These simpler functions will be easier to trace and test.
If the functions cannot be replaced, they need to be tested separately.
- Verify the function by having separate unit tests with high coverage. When coverage has been achieved, justify the usage of these functions by referencing the external unit tests.
Strong Data Typing
ISO 26262 requires all variables to be strongly typed. Model Advisor checks Simulink models for strongly typed blocks, including the interface to the MATLAB Function block, but it does not check external MATLAB functions. To overcome this hurdle, write a check to verify that all the MATLAB functions are strongly typed. It is particularly important to check data type and data dimension.
MIL Testing and SIL or PIL Back-to-Back Testing
Back-to-back (equivalence) tests enable you to prove that the generated code behaves in the same way as the model, as recommended by ISO 26262 Table 7, Methods for software unit verification. For the object code, use processor-in-the-loop (PIL) tests and for generated C code, use software-in-the-loop (SIL) (Figure 5). Test cases should be the same as those used in model-in-the-loop (MIL) tests. For unit verification, use SIL. For integration tests, it is recommended to also execute on target hardware to verify the entire development toolchain.
Figure 5. Model verification activities specified in IEC Certification Kit.
Prevention of Unintended Functionality
To prove that no unintended functionality was added during code generation, measure test coverage during both model and code tests. Test coverage is typically done using back-to-back tests with Simulink Coverage™. Coverage is used, according to ISO 26262, to evaluate the completeness of verification and provide evidence that the objectives for the unit testing are achieved.
According to ISO 26262, code with missing coverage needs to be reviewed and justified. When developing using Simulink blocks, the justifications can be connected to the model, which means that the justifications are kept between verification runs. This option is not available for external MATLAB functions. To justify missing coverage for a MATLAB function, add a coverage filter to the code and then connect it to either the test harness or the test file in Simulink Test™. Our recommendation is to connect the coverage filter file to the test file (Figure 6).
Figure 6. Coverage filter connected to the test file.
Static Code Analysis
As stated in the ISO 26262 standard, static analyses include activities such as searching the source code text or the model for patterns matching known faults or for compliance with modeling or coding guidelines. Static code analyses are performed on the generated code (Figure 7).
Figure 7. Static code analysis activities specified in IEC Certification Kit.
MISRA C Compliance
To assess MISRA® C compliance for code generated from MATLAB, use a static code analyzer tool such as Polyspace Bug Finder™ to detect non–MISRA C compliant code and investigate the results manually. If the noncompliant code comes from a built-in MATLAB function, you have two options:
- Replace the built-in MATLAB function with a rewritten function
- Write a justification for the MISRA C warning
Our recommendation is to replace the function, if possible. To ensure that the replaced function is not used by other developers, implement a Model Advisor check for non-recommended functions.
Documentation
In the final safety case that provides evidence of ISO 26262 conformance, you need to document each step in the verification process, from requirements to verification. The documentation should include design descriptions of the functionality. Figure 8 highlights some of the activities that must be included in the design description.
Figure 8. Activities to include in the design documentation.
System Design Description
Simulink Report Generator™ includes a predefined system design report template. This template is usually adequate for documenting a component developed in Simulink, but not for documenting external MATLAB functions because they are not included in the default System Design Description. We therefore recommend customizing the template to include the external MATLAB code.
SOTIF Considerations
In complex systems such as ADAS, a function may behave as intended but still cause hazardous behavior. Under guidance from the ISO 21448 safety of the intended functionality (SOTIF) standard, you can address this issue by integrating additional verification and validation activities into Model-Based Design. We recommend adding randomized operation condition tests to expand the tests and include unknown use cases. These random tests should verify the behavior of the implementation model and integrated object code compared with the system requirements.
IEC Certification Kit includes support for SOTIF. When it comes to SOTIF, there are no major differences between Simulink and MATLAB workflows. The updated IEC Certification Kit includes information about use of Automated Driving Toolbox™ for system testing.
Summary
In ISO-compliant software development, the differences between full Simulink-based development and a more MATLAB-centric workflow are not great. The main difference is the need to avoid the use of non-recommended functions. There are specific checks to identify such MATLAB functions in the ISO 26262 checks in Simulink Check, ensuring that the MATLAB implementation generates code suitable for high-integrity applications. The other challenges in using a MATLAB-centric workflow for ISO 26262 can be handled by simple workarounds such as using justification filters or connecting requirements to multiple levels in the model.
[1] The recommendations in this article are based on MATLAB R2024a. If you are using a different release, contact your MathWorks representative to learn about its capabilities for using MATLAB and Simulink for ISO 26262.
[2] Developers sometimes choose MATLAB over Simulink because they believe that Simulink does not support diff and merge. If you are working in Simulink, you can use the built-in tools to handle diff and merge. If your team uses a distributed version control system like Git, you can do a three-way merge, should a conflict occur.
[3] In MATLAB R2023a, MATLAB Test™ was released. MATLAB Test provides tools for developing, executing, measuring, and managing dynamic tests of MATLAB code. This gives the developers a possibility to stay within the MATLAB environment when developing high-integrity software. MATLAB Test enables you to meet specifications in regulated applications and is part of IEC Certification Kit.
Published 2024
