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.

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 Simulink Requirements™, 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.


Implement Model Advisor checks to search for MATLAB containers not linked to requirements.

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. A Model Advisor check can be added that checks for usage of non-recommended functions.
  • Replace non-recommended MATLAB functions with simpler implementations. These simpler functions will be easier to trace and test.


When reviewing models, look for MATLAB operations or functions that generate a lot of C code. If possible, replace them with other functions. Add a Model Advisor Check that warns if non-recommended functions are used.

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.


If MATLAB operations or functions that generate a lot of C code are identified and cannot be replaced, test the functions externally with unit tests. Write justifications connected to where the functions are used and link to where tests results are stored.

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.


Add a Model Advisor check to ensure that all variables in your MATLAB code are strongly typed.

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, you must use PIL 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.


Track justifications of missing coverage in external MATLAB code via a justification 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.


When reviewing static code analysis reports, check if MISRA warnings come from built-in MATLAB functions. If these functions can be replaced, then add a Model Advisor check that warns when non-recommended functions are used. If not, justify the issue in the static code analysis report.


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.


Customize the System Design Description template to include 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/PAS 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.


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 by implementing custom Model Advisor checks. These additional checks, together with the existing ISO 26262 checks in Simulink Check, ensure 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 like using justification filters or connecting requirements to multiple levels in the model.

[1] The recommendations in this article are based on MATLAB R2020a. 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.

About the Author

Lars Rosqvist is a senior technical consultant at MathWorks. He supports customers using Model-Based Design and MATLAB across different industries. He is certified as a Functional Safety Professional by TÜV SÜD and has supported clients with ISO 26262 certification for several years. Prior to joining MathWorks, Lars worked as software developer within the automotive industry, developing climate control systems. Lars received his master’s degree in applied physics and electrical engineering from Linköping University of Technology, Sweden.

Published 2020