Technical Articles

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.

MATLAB screenshot of a modeling pattern using external MATLAB code.

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

A diagram showing a system requirements workflow with requirements authoring, architecture development, modeling, code generation, and compiler with the products used for each process.

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.

The same diagram as Figure 2 highlighting requirement linking activities: architecture verification and requirements authoring.

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.


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.

The same diagram as Figure 2 highlighting static model analysis activities.

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.


When reviewing models, look for MATLAB operations or functions that are flagged by Model Advisor check himl_0013. If possible, replace them with other functions.

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, it is recommended to also execute on target hardware to verify the entire development toolchain.

The same diagram as Figure 2 highlighting model verification activities: MIL testing, PIL back-to-back testing, and SIL back-to-back testing.

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

A screenshot of the Test Browser highlighting the coverage filter filename.

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

The same diagram as Figure 2 highlighting static code analysis with Polyspace.

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.

The same diagram as Figure 2 highlighting requirements authoring, architecture development, and modeling.

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

About the Author

Lars Rosqvist is a senior team lead in the Automotive area 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 2024