MISRA C checker for safety-critical systems
 
 
Code quality is particularly important in mission- or safety-critical systems. Since IAR Embedded Workbench performs type checking during the linking process and also runs extensive diagnostics, the generated code is very reliable. With the introduction of the MISRA C checker, also the software safety requirements of the automotive industry are supported.
 
What is MISRA C?
 
The Motor Industry Software Reliability Association (MISRA) is an organization in the UK that promotes safety in automotive software.

In 1998, MISRA published its “Guidelines for the Use of the C Language in Vehicle Based Software”. The guidelines address the ambiguities of the C language and establish coding rules for the automotive industry.

MISRA C includes 127 rules. 93 of these are required and the remaining 34 are advisory. All rules apply to the source code and not to the object code generated by the compiler.
 
Who should use MISRA C?
 
Compliance with the MISRA C guidelines is a requirement in many automotive companies but could be beneficial in any development organization. The guidelines enforce sound coding practices and address the ambiguities of C; they help developers write code in a consistent manner and avoid confusing constructions.
 
How does it work?
 
The MISRA C checker is completely integrated with the IAR C Compiler. From IAR Embedded Workbench, you can control which MISRA C rules are checked; the settings will be used for both the compiler and the linker.

A message is generated for every deviation from a required or advisory rule, unless you have disabled it. Each message contains a reference to the MISRA C rule deviated from, for example:

Error[Pm088]: pointer arithmetic should not be used (MISRA C rule 101)
 
MISRA C compliance
 
To claim compliance with the MISRA C guidelines for your product, you must demonstrate that:

• A compliance matrix has been completed demonstrating how each rule is enforced.

• All C code in the product is compliant with the MISRA C rules or subject to documented deviations.

• A list of all instances where rules are not being followed is maintained, and for each instance there is an appropriately signed-off documented deviation.

• You have taken appropriate measures in the areas of training, style guide, compiler selection and validation, checking tool validation, metrics, and test coverage, as described in section 5.2 of “Guidelines for the Use of the C Language in Vehicle Based Software”.