4.6.2. MISRA® Compliance Checking Guide

4.6.2.1. Checking MISRA® compliance with Axivion Suite

The Axivion Suite can be used to check compliance of your code with MISRA® rules. These checks are implemented as stylechecks.

MISRA and MISRA C are registered trademarks of HORIBA MIRA Ltd., held on behalf of the MISRA Consortium. MISRA, MISRA C and the rule texts are reproduced here under license.

Configuration

MISRA® checks implemented as stylechecks can be selected and configured like other stylechecks, see Stylechecks. For example, to check against the full set of MISRA-C:2025 rules and directives, select the rulegroup MisraC2025 in the graphical user interface.

Many of the MISRA® checks have individual configuration options as shown in the GUI in order to fine-tune them to your needs or your preferred interpretation of the standard.

A few MISRA® checks require special configuration:

  • Rule MisraC-3.6: All libraries used in production code shall be written to comply with the provisions of this document, and shall have been subject to appropriate validation.
    To check libraries used in your project, simply apply all the rules to the source code of these libraries. (We do not support binary analysis).

  • Rule MisraC++-17.0.4: All library code shall conform to MISRA C++.
    To check libraries used in your project, simply apply all the rules to the source code of these libraries. (We do not support binary analysis).

Software Development and MISRA® Deviation Workflow

Nomenclature

In the following sections,

  • A violation is a breach of resp. an issue for a MISRA® rule in the code

  • A permit is the formal description of an exception to a MISRA® rule (including preconditions and reason)

  • A justification is a comment in MISRA® context with (optional) reference to a permit

  • A violation can be relaxed to a DEVIATION, if the violation is is annotated with a justification. Violations can be relaxed to a deviation globally by de-activating the rule check. However, there will be no more violations and as a consequence no more justifications in source code.

For a report it is required to make explicit

  • Which rules were checked?

  • Which rules were executed

    • without violations

    • with deviations

    • with violations

Workflow

The deviation workflow in MISRA® can be implemented as depicted in Figure Figure  The basic MISRA® deviation workflow and its realisation in Axivion Suite.

The basic MISRA® deviation workflow and its realisation in |bauhaussuite|

The basic MISRA® deviation workflow and its realisation in Axivion Suite

When development starts in the respective developer’s workspace, users commit new code or changes to existing code to the version control system. The continuous integration then picks up the changes from the version control system, analyses the code, and reports issues (i.e., violations of the MISRA® programming guidelines). The lists of violations are reported in the user interface of Axivion Suite . All user interfaces provide means for annotating and tagging individual issues to facilitate reviews and discussions amongst developers how to solve the issues.

If, for technical reasons, issues cannot be resolved, developers will ask for approval and acceptance of the issue — thus turning violations into deviations. In order to permanently and properly document the approval of violations, control comments (see Justifications and Suppressions with Code Annotations) are added to the source code. This way, the rationale and the permission of the deviation is documented in line with the source code in question. Control comment formats can be defined by the user and checks can be added to ensure that each and every violation refers to a permit.

Dealing with violations: Support for deviations

The Axivion Suite supports handling of deviations in several ways.

See section Exclude files from the Analysis on how to exclude code parts for all rules or for selected MISRA® rules only. That section also describes an approach to apply different rules to different parts of the code, e.g. if you want to run only a subset of MISRA® checks on generated code.

By means of excludes no more issues are reported or logged in any way. The same is true if you turn off individual rules completely. Such an excluded rule will then not be executed. If you require a justification for deactivating some rules, you can first activate all MISRA® rules in one configuration file, then deactivate the selected ones in a more local configuration layer. In this way you have got explicit deactivations that you can comment on, and they are all grouped together in a single file for easier reviews.

Deviations and Suppressing Violations

If you want to suppress certain findings in your code, you can use code annotations to mark these code parts with special comments (see Justifications and Suppressions with Code Annotations). The syntax and scope of these comments can be freely configured to your desired format.

By default, accepted violations marked in this way will not be reported. But for a complete MISRA® audit report, you will have to import the suppressed issues into the database, because otherwise the information is not kept. This can be done by setting option /Results/Database/import_suppressed_issues to True in the graphical configuration interface. With this option, suppressed issues are imported into the database, shown in the dashboard and available for reports.

The code annotation comments can also be used to attach a justification to suppressed (and even to unsuppressed) issues, for example to refer to a MISRA® permit. The option justification_checker of the rule can then be set to a Python function that ensure a suppressed issue refers to an appropriate permit (see section Checking justifications and Referring to Permits).