MISRA C:2012 Compliance Information Summary Tables

MathWorks^® evaluates C code generated by Embedded Coder^® from Simulink^® models and Stateflow^® charts against the MISRA C:2012 coding standards. The results from this effort are available in these compliance summary tables. These tables identify:

Methods used to obtain compliance:
- Compliant: Compliance to the rule/directive is achieved through adherence to the code generation process, modeling guidelines, or Model Advisor checks. When applicable, there are explanatory notes that provide information relevant to compliance methods or actions that you can perform to satisfy the directive or rule.
- Deviation: The rule or directive is not compliant.
Whether the Polyspace^® MISRA C:2012 Checker supports the rule or directive.

You can use these tables when preparing the MISRA C:2012 compliance statement for your project as required per section 5.3 of the MISRA C:2012 Guidelines for the Use of C Language in Critical Systems document. These tables align with the published MISRA C:2012 rule and directives tables. The categories in the table are based on Appendix E of the MISRA guidelines identified for automatically generated code. They can be used for Mandatory and Required categories only (not for Advisory and Readability categories).

MISRA C:2012 Main Document

"Implementation" MISRA C:2012 Directives

Directive	Category	Compliance	Polyspace Support?
1.1	Required	Compliant: hisl_0060 hisl_0016: Usage of blocks that compute relational operators Explanatory Note for Directive 1.1	Yes, partially supported

Directive

Category

Compliance

Polyspace Support?

1.1

Required

Compliant:

Yes, partially supported

"Compilation and Build" MISRA C:2012 Directives

Directive	Category	Compliance	Polyspace Support?
2.1	Required	Compliant	Yes

"Requirements Traceability" MISRA C:2012 Directives

Directive	Category	Compliance	Polyspace Support?
3.1	Required	Compliant: Explanatory Note for MISRA Directive 3.1	No

Directive

Category

Compliance

Polyspace Support?

3.1

Required

Compliant:

Explanatory Note for MISRA Directive 3.1

"Code Design" MISRA C:2012 Directives

Directive	Category	Compliance	Polyspace Support?
4.1	Required	Compliant: hisl_0001 hisl_0002 hisl_0003 hisl_0004 hisl_0005 hisl_0006 hisl_0007 hisl_0008 hisl_0010 hisl_0011 hisl_0028 hisl_0053 hisl_0054 hisl_0067 Explanatory Note for Directive 4.1	Yes
4.3	Required	Compliant: Explanatory Note for Directive 4.3	No
4.6	Advisory	Not Applicable. See Explanatory Note for Directive 4.6	N/A
4.7	Required	Compliant: Check for missing error ports for AUTOSAR receiver interfaces Check for blocks not recommended for MISRA C:2012 (Simulink Check) Deviation: Deviation for AUTOSAR target-based code generator - sender ports. See MISRA C:2012 Directive 4.7 Deviation Rationale	Yes^a
4.10	Required	Compliant	Yes
4.11	Required	Compliant: Explanatory Note for Directive 4.11	Yes
4.12	Required	Compliant: hisl_0060	No
^a The Polyspace MISRA C:2012 Checker might flag Directive 4.7 as a Rule 17.7 violation (Polyspace Bug Finder) for user-defined functions when there is no knowledge about whether the return value contains error information.

"Standard C Environment" MISRA C:2012 Rules

Rule	Category	Compliance	Polyspace Support?
1.1	Required	Compliant	Yes
1.3	Required	Compliant	Yes

"Unused Code" MISRA C:2012 Rules

Rule	Category	Compliance	Polyspace Support?
2.1	Required	Compliant: hisl_0053 hisl_0101 hisl_0060 Explanatory Note for Rule 2.1	Yes
2.2	Required	Compliant	Yes

Rule

Category

Compliance

Polyspace Support?

2.1

Required

Compliant:

Yes

2.2

Required

Compliant

Yes

"Comments" MISRA C:2012 Rules

Rule	Category	Compliance	Polyspace Support?
3.1	Required	Compliant: Check for unsupported block names	Yes
3.2	Required	Compliant	Yes

Rule

Category

Compliance

Polyspace Support?

3.1

Required

Compliant:

Check for unsupported block names

Yes

3.2

Required

Compliant

Yes

"Character Sets and Lexical Conventions" MISRA C:2012 Rules

Rule	Category	Compliance	Polyspace Support?
4.1	Required	Compliant	Yes

"Identifiers" MISRA C:2012 Rules

Rule	Category	Compliance	Polyspace Support?
5.1	Required	Compliant: hisl_0060 hisl_0063 Explanatory Note for Rules 5.1, 5.2, 5.4, 5.5, 5.6, 5.7, and 5.8	Yes
5.2	Required	Compliant: hisl_0060 hisl_0063 Explanatory Note for Rules 5.1, 5.2, 5.4, 5.5, 5.6, 5.7, and 5.8	Yes
5.4	Required	Compliant: hisl_0060 hisl_0063 Explanatory Note for Rules 5.1, 5.2, 5.4, 5.5, 5.6, 5.7, and 5.8	Yes
5.5	Required	Compliant: hisl_0060 hisl_0063 Explanatory Note for Rules 5.1, 5.2, 5.4, 5.5, 5.6, 5.7, and 5.8	Yes
5.6	Required	Compliant: hisl_0060 Explanatory Note for Rules 5.1, 5.2, 5.4, 5.5, 5.6, 5.7, and 5.8	Yes
5.7	Required	Compliant: hisl_0060 Explanatory Note for Rules 5.1, 5.2, 5.4, 5.5, 5.6, 5.7, and 5.8	Yes
5.8	Required	Compliant: hisl_0060 Explanatory Note for Rules 5.1, 5.2, 5.4, 5.5, 5.6, 5.7, and 5.8	Yes

"Types" MISRA C:2012 Rules

Rule	Category	Compliance	Polyspace Support?
6.1	Required	Compliant: hisl_0060	Yes
6.2	Required	Compliant: hisl_0060	Yes

Rule

Category

Compliance

Polyspace Support?

6.1

Required

Compliant:

hisl_0060

Yes

6.2

Required

Compliant:

hisl_0060

Yes

"Literals and Constants" MISRA C:2012 Rules

Rule	Category^a	Compliance	Polyspace Support?
7.1	Advisory	Compliant	Yes
7.2	Readability	Compliant	Yes
7.4	Required	Compliant	Yes
^a Guideline suggests Rule 7.1 and 7.2 as Required for manually generated code.

"Declarations and Definitions" MISRA C:2012 Rules

Rule	Category^a	Compliance	Polyspace Support?
8.1	Required	Compliant	Yes
8.2	Required	Compliant	Yes
8.3	Required	Compliant	Yes
8.6	Required	Compliant	Yes
8.8	Required	Compliant	Yes
8.10	Required	Compliant	Yes
8.12	Required	Compliant: Explanatory Note for Rule 8.12	Yes
8.14	Advisory	Compliant	Yes
^a Guideline suggests Rule 8.14 as Required for manually generated code.

"Initialization" MISRA C:2012 Rules

Rule	Category^a	Compliance	Polyspace Support?
9.1	Mandatory	Compliant: hisl_0029 Check usage of Assignment blocks (Simulink Check)	Yes
9.4	Required	Compliant	Yes
9.5	Readability	Compliant	Yes
^a Guideline suggests Rule 9.5 as Required for manually generated code.

"The Essential Type Model" MISRA C:2012 Rules

Rule	Category^a	Compliance	Polyspace Support?
10.2	Advisory	Compliant	Yes
10.3	Advisory	Compliant	Yes
^a Guideline suggests Rule 10.2 and 10.3 as Required for manually generated code.

"Pointer Type Conversion" MISRA C:2012 Rules

Rule	Category	Compliance	Polyspace Support?
11.1	Required	Compliant	Yes
11.2	Required	Compliant	Yes
11.3	Required	Compliant: hisl_0020	Yes
11.6	Required	Compliant	Yes
11.7	Required	Compliant	Yes
11.8	Required	Compliant: hisl_0020 Explanatory Note for Rule 11.8	Yes

"Expressions" MISRA C:2012 Rules

Rule	Category	Compliance	Polyspace Support?
12.2	Required	Compliant	Yes

"Side Effects" MISRA C:2012 Rules

Rule	Category	Compliance	Polyspace Support?
13.1	Required	Compliant	Yes
13.2	Required	Compliant: hisl_0062	Yes
13.5	Required	Compliant: hisl_0062 Deviation: MISRA C:2012 Rule 13.5 Deviation Rationale	Yes
13.6	Mandatory	Compliant	Yes

"Control Statement Expressions" MISRA C:2012 Rules

Rule	Category^a	Compliance	Polyspace Support?
14.2	Readability	Compliant: hisl_0006 hisl_0007 hisl_0008 hisl_0010 hisl_0011 hisl_0101	Yes
14.3	Required	Compliant: hisl_0101 hisl_0060	Yes
^a Guideline suggests Rule 14.2 as Required for manually generated code.

Rule

Category^a

Compliance

Polyspace Support?

14.2

Readability

Compliant:

Yes

14.3

Required

Compliant:

Yes

^a Guideline suggests Rule 14.2 as Required for manually generated code.

"Control Flow" MISRA C:2012 Rules

Rule	Category^a	Compliance	Polyspace Support?
15.2	Advisory	Compliant	Yes
15.3	Advisory	Compliant	Yes
15.6	Required	Compliant	Yes
15.7	Readability	Compliant	Yes
^a Guideline suggests Rule 15.2, 15.3 and 15.7 as Required for manually generated code.

"Switch statements" MISRA C:2012 Rules

Rule	Category^a	Compliance	Polyspace Support?
16.2	Advisory	Compliant	Yes
16.3	Advisory	Compliant	Yes
16.4	Advisory	Compliant: hisl_0006 hisl_0007 hisl_0008 hisl_0010 hisl_0011	Yes
16.5	Advisory	Compliant	Yes
16.6	Advisory	Compliant	Yes
16.7	Advisory	Compliant	Yes
^a Guideline suggests Rule 16.2, 16.3, 16.4, 16.5, 16.6 and 16.7 as Required for manually generated code.

"Functions" MISRA C:2012 Rules

Rule	Category	Compliance	Polyspace Support?
17.1	Required	Compliant	Yes
17.2	Required	Compliant: hisl_0060 hisf_0004	Yes
17.3	Mandatory	Compliant	Yes
17.4	Mandatory	Compliant	Yes
17.6	Mandatory	Compliant	Yes

"Pointers and Arrays" MISRA C:2012 Rules

Rule	Category	Compliance	Polyspace Support?
18.1	Required	Compliant	Yes
18.2	Required	Compliant	Yes
18.3	Required	Compliant	Yes
18.6	Required	Compliant	Yes
18.7	Required	Compliant	Yes
18.8	Required	Compliant	Yes

"Overlapping Storage" MISRA C:2012 Rules

Rule	Category	Compliance	Polyspace Support?
19.1	Mandatory	Compliant	Yes

"Preprocessing Directives" MISRA C:2012 Rules

Rule	Category	Compliance	Polyspace Support?
20.2	Required	Compliant	Yes
20.3	Required	Compliant	Yes
20.4	Required	Compliant	Yes
20.6	Required	Compliant	Yes
20.7	Required	Compliant	Yes
20.9	Required	Compliant	Yes
20.11	Required	Compliant	Yes
20.12	Required	Compliant	Yes
20.13	Required	Compliant	Yes
20.14	Required	Compliant	Yes

"Standard Libraries" MISRA C:2012 Rules

Rule	Category	Compliance	Polyspace Support?
21.1	Required	Compliant	Yes
21.2	Required	Compliant: hisl_0032	Yes
21.3	Required	Compliant: hisl_0060	Yes
21.4	Required	Compliant	Yes
21.5	Required	Compliant	Yes
21.6	Required	Compliant: hisl_0060 Check for blocks not recommended for MISRA C:2012 (Simulink Check)	Yes
21.7	Required	Compliant	Yes
21.8	Required	Compliant	Yes
21.9	Required	Compliant	Yes
21.10	Required	Compliant	Yes
21.11	Required	Compliant	Yes
21.12	Required	Compliant	Yes

"Resources" MISRA C:2012 Rules

Rule	Category	Compliance	Polyspace Support?
22.1	Required	Compliant	Yes
22.2	Mandatory	Compliant	Yes
22.3	Required	Compliant	Yes
22.4	Mandatory	Compliant	Yes
22.5	Mandatory	Compliant	Yes
22.6	Mandatory	Compliant	Yes

MISRA C:2012 Amendment 1

"Code Design" MISRA C:2012 Amendment 1 Directives

Directive	Category	Compliance	Polyspace Support?
4.14	Required	Compliant	Yes

"Expressions" MISRA C:2012 Amendment 1 Rules

Directive	Category	Compliance	Polyspace Support?
12.5	Mandatory	Compliant	Yes

"Standard Libraries" MISRA C:2012 Amendment 1 Rules

Directive	Category	Compliance	Polyspace Support?
21.13	Mandatory	Compliant	Yes
21.14	Required	Compliant	Yes
21.15	Required	Compliant	Yes
21.16	Required	Compliant	Yes
21.17	Mandatory	Compliant	Yes
21.18	Mandatory	Compliant	Yes
21.19	Mandatory	Compliant	Yes
21.20	Mandatory	Compliant	Yes

"Resources" MISRA C:2012 Amendment 1 Rules

Directive	Category	Compliance	Polyspace Support?
22.7	Required	Compliant	Yes
22.8	Required	Compliant	Yes
22.9	Required	Compliant	Yes
22.10	Required	Compliant	Yes

MISRA C:2012 Amendment 2

"Standard C Environment" MISRA C:2012 Amendment 2 Rules

Directive	Category	Compliance	Polyspace Support?
1.4	Required	Compliant	Yes

"Standard Libraries" MISRA C:2012 Amendment 2 Rules

Directive	Category	Compliance	Polyspace Support?
21.21	Required	Compliant	Yes

Explanatory Notes

These explanatory notes are referenced from the MISRA C:2012 Compliance Information Summary Tables.

Explanatory Note for Directive 1.1

Information about the implementation-defined behavior for Embedded Coder is available in Configure Run-Time Environment Options . Compiler documentation is out of scope.

Character set encoding is managed by using the SavedCharacterEncoding model parameter. For additional information, see slCharacterEncoding.

Configure the integer division method in the Model Configuration Parameters dialog box, on the Hardware Implementation pane. For additional information, see Configure Run-Time Environment Options

Embedded Coder generates #pragma when the user:

In both instances, you are responsible for documenting the intended use of the #pragma. For more information, see Control Data and Function Placement in Memory by Inserting Pragmas.

To enable the generation of bitfields:

Select at least one of these model configuration parameters:
- Pack Boolean data into bitfields. This parameter is available only for ERT-based system target files.
- Use bitsets for storing state configuration
- Use bitsets for storing Boolean data.
Create a custom storage class with defined bitfields. See Create Storage Classes by Using the Custom Storage Class Designer for more information.

If your model uses conversion of one datatype to another, Polyspace Checker shows violation of Dir 1.1 from the generated code of the model. In this case, the violation coming from the model is not an issue if you document this explicit conversion according to the MISRA guidelines.

Explanatory Note for MISRA Directive 3.1

You can link requirements model elements. These links are included in the generated C code to provide traceability from a requirements document, to the model elements, and to the generated code. For additional information, see View Requirements Toolbox Links Associated with Model Elements and Link Blocks and Requirements (Requirements Toolbox).

Explanatory Note for Directive 4.1

You can use Polyspace Bug Finder™ to identify run-time errors and Polyspace Code Prover™ to prove the absence of run-time errors. For information, see:

Configure and Run Analysis (Polyspace Code Prover)
Configure and Run Analysis (Polyspace Bug Finder)

Simulink Design Verifier can be used to detect design errors at the model level. For more information, see Analyze Models for Design Errors (Simulink Design Verifier).

To handle the overflow violations, see Handle Overflows in Simulink Models (Fixed-Point Designer).

Explanatory Note for Directive 4.3

Embedded Coder does not directly call assembly language code. You can add calls to assembly language functions through S-functions, code replacement libraries, Stateflow, and in MATLAB^® blocks. These calls are documented as calls to External C Functions. In these cases, you are responsible for encapsulation.

For additional information, see:

Explanatory Note for Directive 4.6

Embedded Coder replaces basic data types with typedefs types, which are compatible with Directive 4.6. A guideline is not required because this behavior is default behavior in Embedded Coder. For additional information, see Replace and Rename Simulink Coder Data Types to Conform to Coding Standards and Typedefs.

Explanatory Note for Directive 4.11

The requirements of this directive are satisfied by:

“Demonstrate statically that the input parameters can never take invalid values”.

You can use Polyspace Code Prover to analyze parameter ranges and prove the absence of run-time errors caused by out-of-range values. For additional information, see Run Polyspace Analysis on Code Generated with Embedded Coder (Polyspace Code Prover).

Explanatory Note for Rule 2.1

Embedded Coder does not check user defined code from the Stateflow. You must take care of the violations reported.

Explanatory Note for Rules 5.1, 5.2, 5.4, 5.5, 5.6, 5.7, and 5.8

Embedded Coder is configurable to limit the number of characters imposed by the implementation. For additional information, see Maximum identifier length.

To ensure unique names for different types of variables (local scope variables, global scope variables, macros, and so on), implement a naming convention. For additional information, see Model Configuration Parameters: Code Generation Symbols.

In case of long identifiers, it is recommended to use shared utilities. For more information, see Generate Shared Utility Code

Explanatory Note for Rule 8.12

Embedded Coder supports the use of enumerated data. The file used to define the enumeration can be either manually or automatically generated. Files defining enumerations generated by Embedded Coder are compliant with MISRA C:2012 Rule 8.12 by design. If you manually create the definition file, you are responsible for ensuring compliance. For additional information, see Use Enumerated Data in Simulink Models.

Explanatory Note for Rule 11.8

If your model uses Simulink.Signal or Simulink.Parameter that has storage class with Const or Volatile qualifiers, Polyspace Checker may show violation of Rule 11.8 from the generated code of the model.