MISRA C is a set of software development guidelines for the C programming language developed by MISRA (Motor Industry Software Reliability Association). 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. MISRA 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.
MISRA C is now in its third edition.
In spring 1997 software engineers at the Austin Rover Group (ARG) sent a draft C coding standard to Programming Research Ltd (PRL) for review. The review was performed by PRL's then senior consultant, David Blyth, who proposed replacing the draft with an appreciably stronger set of coding rules. Those rules, with minor changes, formed the basis of 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.
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".
In 2013, MISRA C:2012 was announced. 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.
In April 2016, MISRA published (as free downloads) Amendment 1 to MISRA C:2012 which added fourteen new security guidelines, together with Addendum 2 to MISRA C:2012, which outlines the coverage of MISRA C:2012 against ISO/IEC TS 17961:2013 - C secure coding rules.
In April 2016, MISRA published MISRA Compliance:2016, which provides enhanced guidance on achieving compliance to MISRA C and MISRA C++.
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.
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.
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.
The rules can be divided logically into a number of categories:
- Avoiding possible compiler differences, for example, the size of a C integer may vary but an INT16 is always 16 bits. (C99 standardized on
- Avoiding using functions and constructs that are prone to failure, for example,
- Produce maintainable and debuggable code, for example, naming conventions and commenting.
- Best practice rules.
- Complexity limits.
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.
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 to proof 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.
While there exist many software tools that claim to check code for "MISRA conformance", there is no MISRA certification process.
An exemplar suite for MISRA-C:2004 is available from the MISRA Forum, which 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 Rules within MISRA-C:2004.
- Tools that check code for MISRA conformance are
- Astrée by AbsInt
- Coverity by Synopsys - Static Analysis
- ECLAIR by BUGSENG
- Goanna by Red Lizard Software – A software analysis tool for C/C++.
- Rational Test RealTime by IBM - A cross-platform solution for component testing, static and runtime analysis
- Klocwork by Rogue Wave Software
- LDRA Testbed by Liverpool Data Research Associates
- Parasoft C/C++test by Parasoft
- PC-Lint by Gimpel Software. MISRA C:1998, C:2004, C:2012, C++:2008.
- Polyspace by MathWorks
- QA-C by Programming Research
- RESORT for C and C++ by Soft4Soft
- 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 are
- Green Hills Software
- IAR Systems - MISRA C:1998, C:2004, C:2012, C++:2008.
- TASKING - MISRA C:1998, C:2004, C:2012.
- TI Compilers
- "MISRA C and MISRA C++ Compliance". Programmingresearch.com. Retrieved 2014-06-30.
- "MISRA checker". Cosmic Software. Retrieved 2014-06-30.
- "Misra C/C++". Ldra. Retrieved 2014-06-30.
- "Buying MISRA C". MISRA. Retrieved 10 June 2013.
- "A brief history of MISRA C". MISRA. 2013-03-18. Retrieved 2014-06-30.
- "MISRA C:2012 release date announced". MISRA. 26 February 2013. Retrieved 10 June 2013.
- "MISRA C:2012 Amendment 1 (PDF)". MISRA. Retrieved 9 June 2016.
- "MISRA C:2012 Addendum 2 (PDF)". MISRA. Retrieved 18 June 2016.
- "MISRA Compliance:2016 (PDF)". MISRA. Retrieved 22 July 2016.
- MISRA publications
- "Fact Sheet: MISRA C:2012 (PDF)" (PDF). programmingresearch.com. Retrieved 10 June 2013.
- Achieving MISRA C:2012 Compliance Achieving MISRA C:2012 Compliance
- "MISRA C FAQ list." MISRA Consortium
- MISRA conformance checking, PC-lint/FlexeLint, Gimpel Software.
- Languages and Standards; iar.com
- Official website
- "Introduction to MISRA C". embedded.com.
- "MISRA C: Safer Is Better". Electronic Design magazine.
- "MISRA C — Some key rules to make embedded systems safer". IAR. Retrieved 2013-08-01.
- "Commentary on the first edition of the MISRA C guidelines". knosof.co.uk.
- "Automating Compliance to MISRA C/C++ Standards". johndayautomotivelectronics.com.
- "New Version of MISRA C: Why Should You Care?". Electronic Design magazine.
- "MISRA C:2012: Plenty Of Good Reasons To Change". Electronic Design magazine.
- "MISRA C:2012 fact sheet" (PDF). programmingresearch.com.
- "MISRA C:2012 ensures automotive software safety". EE Times magazine.
- "Compliance to MISRA C: Code Generation". Mathworks.