MISRA C

The MISRA C and MISRA C++ standards are a set of coding guidelines for the C and C++ programming languages that promote safety, security, and reliability in embedded system software. These guidelines are published by the MISRA Consortium, a collaboration between vehicle manufacturers, component suppliers, and engineering consultancies. MISRA C guidelines, which originally targeted only the automotive industry, are now widely accepted and used in other industries such as aerospace and defense, industrial automation, and medical devices.

Most engineering organizations originally applied MISRA C and C++ standards to their hand-written C and C++ code. The MISRA standards have since been refined to accommodate the use of code generated from tools such as  MATLAB^® and Simulink^®.

Why Is MISRA C Important for Embedded Systems?

The C programming language is one of the most popular languages for embedded systems because of its intrinsic capabilities, such as performance, portability across hardware, and direct control on memory. However, certain C language constructs can lead to programming errors, undefined behavior, or implementation-defined behavior.

The MISRA C guidelines define a “safe-subset” of the C language to protect against language aspects that can compromise the safety and security of embedded systems.

For example, C99 allows the use of initializer lists with expressions that can be evaluated only at run-time. However, the order in which the elements of the list are evaluated is not defined. Take this simple case:

1   int x=0;
2   int y=1;
3   volatile int v;
4
5   void func()   {
6        int arr[2] = {x+y, x-y};
7        int arr2[2] = {x++, x+y};
8        int arr3[2] = {v, v};
9   }

On lines 7 and 8, an element of the list modifies the value of a variable that is used in another element. The ambiguity in the evaluation order can cause unexpected values.  For instance, depending on the evaluation order, arr2 can be initialized with values derived from either the original or incremented value of x. Accordingly, MISRA C:2023 Rule 13.1 restricts initializer expressions from having persistent side effects, reducing the risk that unspecified evaluation order will produce unexpected results.

The Evolution of MISRA C

The first edition, MISRA C:1998, established guidelines for using C in vehicle-based software. MISRA C:2004 expanded and refined those guidelines. MISRA C:2012 introduced a more comprehensive framework, including directives, decidability classifications, the essential type model, and improved guidance for compliance and deviation management.

MISRA subsequently published technical corrigenda and amendments to address clarifications, security considerations, and newer C language features. MISRA C:2023 consolidates MISRA C:2012, Technical Corrigenda 1 and 2, and Amendments 1 through 4 into a single edition. It includes support for relevant C11 and C18 language features.

MISRA publishes supporting documents that map MISRA C guidelines to other editions and security-oriented standards. Supporting publications relevant to MISRA C:2023 include mappings to secure-C guidance and language-vulnerability guidance. For example, MISRA C:2023 Addendum 2 addresses coverage against C Secure, while Addendum 4 addresses coverage against ISO/IEC 24772 language-vulnerability guidance.

To address the growing use of modeling and automatic code generation tools such as Simulink, Stateflow, and Embedded Coder, MISRA published MISRA AC AGC in November of 2007.

MISRA provides guidance for applying its guidelines to automatically generated code. MISRA C:2023 identifies guideline categories for generated code, recognizing that the applicability or enforcement priority of some guidelines differs from handwritten code. MathWorks uses this categorization when assessing code generated by Embedded Coder.

How Do I Ensure Compliance with MISRA C:2023?

MISRA C:2023 guidelines are written as rules or directives. A guideline is labeled as a:

• Rule if the information provided can be leveraged to unambiguously check the source code for compliance. A rule is further classified as decidable if it can be conclusively verified using a static code analysis tool such as Polyspace. For instance, MISRA C:2023 Rule 11.1 (“Conversions shall not be performed between a pointer to a function and any other type”) is a decidable rule.
• Directive if the information provided is open to interpretation or relates to software development processes. For instance, MISRA C:2023 Dir 1.1 (“Any implementation-defined behavior on which the output of the program depends shall be documented and understood”) is a directive.

Each guideline is also labeled as Advisory, Required, or Mandatory. To ensure compliance with MISRA C:2023, the project source code must meet:

• All mandatory guidelines
• All required guidelines unless subject to formal deviation
• Advisory guidelines where practical

MISRA has provided additional compliance guidance through publications such as MISRA Compliance:2016 and MISRA Compliance:2020.

What Are Some Important Considerations for MISRA C:2023 Adoption?

Integrate MISRA C Within Software Development Processes

MISRA recommends that the MISRA C guidelines be integrated within a project's software development processes. MISRA C does not define a software development process but suggests using processes that can be found in functional safety standards such as ISO 26262, DO 178C, IEC 62304, and IEC 61508.

Generate Compliance Matrix

Each project should create a compliance matrix that documents all guidelines and the corresponding enforcement methods. Manual review is required for guidelines that cannot be fully enforced using a tool such as a static code analyzer.

Document Deviations

MISRA allows deviations from guidelines in situations where those guidelines might be impractical or unreasonable to follow.  Deviations should be managed as controlled project records and linked to the applicable analysis result, source location, or approved deviation permit. A deviation should document its scope, rationale, risk assessment, authorization, and any conditions under which it remains valid.

Using Generated Code

Code generation simplifies the MISRA C compliance process.  MISRA C:2023 provides a guideline categorization intended for automatically generated code. Under this categorization, the obligation level or applicability of selected guidelines can differ from that for handwritten code, and an additional readability category is used. This does not mean that readability is generally unimportant; projects should apply the generated-code categorization defined by MISRA and document the code generator, configuration, modeling practices, verification activities, and any deviations used to establish compliance.

Using Handwritten Code

The MISRA C rules can be checked manually, but looking at hundreds of thousands, or sometimes millions of lines of code for rule violations is not practical. Therefore, MISRA C recommends the use of static code analysis tools to ensure compliance. MISRA C also recommends that software developers check for compliance as soon as code is written and before code review or unit testing. Addressing violations earlier in the development lifecycle is much less expensive and far more efficient than delaying until later stages.

Key Products for Developing MISRA C Compliant Applications

• Simulink
• Stateflow
• Embedded Coder
• Polyspace code verification products
• Simulink Check

Engineers can use Simulink, Stateflow, Simulink Check, and Embedded Coder as part of a workflow for developing models and generating code that supports MISRA C:2023 compliance. The workflow includes selecting the MISRA C:2023 code-generation objective, applying applicable modeling checks, generating code, performing static analysis, and reviewing and documenting the results.

MathWorks publishes MISRA C:2023 compliance summary tables for C code generated by Embedded Coder. The tables describe guideline compliance status, applicable modeling recommendations, Model Advisor checks, code-generation considerations, and circumstances that can require additional action or documented deviation.

Polyspace^® code verification products are used to analyze handwritten or generated code for MISRA C compliance. Polyspace Bug Finder supports the detection of coding rules in MISRA-C:2004, MISRA C:2012, MISRA C:2023, MISRA C:2025, MISRA AC AGC, and MISRA-C++:2008, AUTOSAR C++14. This tool can be used to check generated code and obtain an independent confirmation that the code indeed complies to MISRA C. Engineers can also trace Polyspace results back to the model and annotate at the model level to justify deviations.