MISRA C

MISRA C is a set of software development guidelines for the C programming language developed by The MISRA Consortium. Its aims are to facilitate code safety, security, portability and reliability in the context of embedded systems, specifically those systems programmed in ISO C / C90 / C99.

There is also a set of guidelines for MISRA C++ not covered by this article.

History

* Draft: 1997
* First edition: 1998 (rules, required/advisory)
* Second edition: 2004 (rules, required/advisory)
* Third edition: 2012 (directives; rules, Decidable/Undecidable)
* MISRA compliance: 2016, updated 2020

For the first two editions of MISRA-C (1998 and 2004) all Guidelines were considered as Rules. With the publication of MISRA C:2012 a new category of Guideline was introduced - the ''Directive'' whose compliance is more open to interpretation, or relates to process or procedural matters.

Adoption

Although originally specifically targeted at the automotive industry, MISRA C has evolved as a widely accepted model for best practices by leading developers in sectors including automotive, aerospace, telecom, medical devices, defense, railway, and others.
For example:

* The Joint Strike Fighter project C++ Coding Standards are based on MISRA-C:1998.
* The NASA Jet Propulsion Laboratory C Coding Standards are based on MISRA-C:2004.
* ISO 26262 ''Functional Safety - Road Vehicles'' cites MISRA C as being an appropriate sub-set of the C language:
** ISO 26262-6:2011 ''Part 6: Product development at the software level'' cites MISRA-C:2004 and MISRA AC AGC.
** ISO 26262-6:2018 ''Part 6: Product development at the software level'' cites MISRA C:2012.
* The AUTOSAR General Software Specification (SRS_BSW_00007) likewise cites MISRA C:
** The AUTOSAR 4.2 General Software Specification requires that ''If the BSW Module implementation is written in C language, then it shall conform to the MISRA C:2004 Standard.''
** The AUTOSAR 4.3 General Software Specification requires that ''If the BSW Module implementation is written in C language, then it shall conform to the MISRA C:2012 Standard.''

Guideline classification and categorization

When a new software project is started, the latest MISRA standard should be used. Previous standards are still available for use with legacy software projects that need to refer to it.MISRA publications
/ref>

Classification

Each Guideline is classified as ''Mandatory'' (new for MISRA C:2012), ''Required'' or ''Advisory''. Furthermore, the MISRA Compliance document permits ''Advisory'' guidelines to be ''Disapplied''.

* ''Mandatory'' guidelines shall always be complied with
* ''Required'' guidelines shall be complied with, unless subject to a ''Deviation''
* ''Advisory'' guidelines are considered good practice, but compliance is less formal.

Categorization

The rules can be divided logically into a number of categories:

* Avoiding possible compiler differences, for example, the size of C's int type may vary but int16_t (standardized in C99) is always 16 bits.
* Avoiding using functions and constructs that are prone to failure, for example, malloc may fail.
* Produce maintainable and debuggable code, for example, naming conventions and commenting.
* Best practice rules.
* Complexity limits.

Scope

MISRA C:2012 separately classifies each guideline as either ''Single Translation Unit'' or ''System''.

Decidability

MISRA C:2012 classifies the ''rules'' (but not the ''directives'') as ''Decidable'' or ''Undecidable''.

Achieving compliance

MISRA compliance

MISRA published documents to provide additional guidance to understand and achieve MISRA compliance.
* ''MISRA Compliance:2016'', was released by MISRA in April 2016.
* ''MISRA Compliance:2020'', revised edition, was released in February 2020.

Compliance

In order for a piece of software to claim to be compliant to the MISRA C Guidelines, all ''mandatory'' rules shall be met and all ''required'' rules and directives shall either be met or subject to a formal deviation. ''Advisory'' rules may be disapplied without a formal deviation, but this should still be recorded in the project documentation.

Note: For compliance purposes, there is no distinction between ''rules'' and ''directives''.

Deviations

Many MISRA C ''rules'' can be characterized as ''guidelines'' because under certain condition software engineers may deviate from rules and still be considered compliant with the standard. Deviations must be documented either in the code or in a file. In addition; proof must be provided that the software engineer has considered the safety of the system and that deviating from the rule will not have a negative impact, requirements for deviations also include:

* The rule deviated from.
* Rationale for deviation.

Published documents

MISRA C:1998

The first edition of MISRA C, "Guidelines for the use of the C language in vehicle based software", which was published in 1998 and is officially known as ''MISRA-C:1998''.

MISRA-C:1998 has 127 rules, of which 93 are required and 34 are advisory; the rules are numbered in sequence from 1 to 127.

MISRA C:2004

In 2004, a second edition "Guidelines for the use of the C language in ''critical systems''", or ''MISRA-C:2004'' was produced, with many substantial changes to the guidelines, including a complete renumbering of the rules.

MISRA-C:2004 contains 142 rules, of which 122 are "required" and 20 are "advisory"; they are divided into 21 topical categories, from "Environment" to "Run-time failures".

MISRA C:2012

Main document

In 2013, the third edition, MISRA C:2012, was published. MISRA C:2012 extends support to the C99 version of the C language (while maintaining guidelines for C90), in addition to including a number of improvements that can reduce the cost and complexity of compliance, whilst aiding consistent, safe use of C in critical systems.

MISRA-C:2012 contains 143 rules and 16 "directives" (that is, rules whose compliance is more open to interpretation, or relates to process or procedural matters); each of which is classified as ''mandatory'', ''required'', or ''advisory''. They are separately classified as either ''Single Translation Unit'' or ''System''. Additionally, the rules are classified as ''Decidable'' or ''Undecidable''.

Amendment 1

In April 2016, MISRA published (as a free download) ''MISRA C:2012 - Amendment 1: Additional Security Guidelines'' which added fourteen new security guidelines.

Amendment 2

In February 2020, MISRA published (as a free download) ''MISRA C:2012 - Amendment 2: Updates for ISO/IEC 9899:2011/18 Core functionality'' which adds mapping for the undefined, unspecified and implementation defined behaviours within C11/C18.

Supporting documents

MISRA have published the following addenda to support MISRA C:2012:

* ''MISRA C:2012 - Addendum 1: Rule Mappings'', which contains bi-directional rule mappings between MISRA C:2004 and the new version. It is intended to assist users in migration.
* ''MISRA C:2012 - Addendum 2: Coverage of MISRA C:2012 against ISO/IEC TS 17961:2013 "C Secure"''
* ''MISRA C:2012 - Addendum 3: Coverage of MISRA C:2012 against CERT C''

Example suite

An exemplar suite (for MISRA-C:2004 and MISRA C:2012) is available from the MISRA GitLab repository (login required). This allows tool-users to evaluate and compare the checking support provided by the various MISRA tools; additionally, it gives tool-implementers some guidance as to the intent of the MISRA Guidelines.

Tools

While there exist many software tools that claim to check code for "MISRA conformance", there is no MISRA certification process.

Most of the guidelines can be checked using tools that perform static code analysis. The remaining guidelines require the use of dynamic code analysis.

Tools that check code for MISRA conformance include:
* Astrée by AbsInt
* Axivion Bauhaus Suite by Axivion GmbH. ''MISRA C:2004, C:2012, C:2012 Amendment 1, C++:2008, Compliance:2016''.
* CodeSonar by GrammaTech
* Coverity by Synopsys - Static Analysis
* Cppcheck - Open source Static Analysis tool for C/C++
* ECLAIR by BUGSENG srl. ''MISRA C:2004, C:2012, C:2012 Amendment 1, C++:2008''.
* Helix QAC by Perforce Software. ''MISRA C:1998, C:2004, C:2012, C++:2008''.
* Klocwork by Rogue Wave Software (now owned by Perforce Software). ''MISRA C:2012, C:2012 Amendment 1, C++:2008''.
* LDRA Testbed by Liverpool Data Research Associates
* Parasoft C/C++test by Parasoft
* PC-Lint by Gimpel Software (now owned by Vector Informatik GmbH). ''MISRA C:1998, C:2004, C:2012, C++:2008''.
* Polyspace by MathWorks
* PVS-Studio by Program Verification Systems
* SonarQube by SonarSource ( Open Source with some commercial plug-in components)
* SQuORE by Squoring Technologies
* Understand by SciTools

C/C++ compilers that support MISRA conformance include:
* Green Hills Software
* IAR Systems - ''MISRA C:1998, C:2004, C:2012, C++:2008''.
* TASKING - ''MISRA C:1998, C:2004, C:2012''.

Criticism

Some research results question the effectiveness of MISRA C 2004.

In a paper that compares earlier work on MISRA C:1998 with MISRA C:2004, Les Hatton comes to the conclusion that:Language subsetting in an industrial context: a comparison of MISRA C 1998 and MISRA C; Les Hatton; University of Kingston; 2004.
/ref>

He goes on to state:

A study at the TU Delft, by Cathal Boogerd and Leon Moonen, empirically assesses the value of MISRA C:2004. It comes to similar results:Assessing the Value of Coding Standards: An Empirical Study; C.J. Boogerd and L. Moonen; Delft University of Technology; 2008.
/ref>

See also

* Programming style

References

External links

*
*
*
*
*
*
*
*
*

{{Embedded systems

C (programming language)
C programming language family
Embedded systems
Hinckley and Bosworth
History of computing in the United Kingdom
Programming language standards
Science and technology in Leicestershire