MISRA C:2012 ensures automotive software safety
First published in 1998, MISRA C provided some badly needed guidance to engineers, who often had limited experience in software engineering, at a time when software reliability was becoming a critical issue. In the beginning it was a modest initiative within the UK motor industry, but it rapidly developed into a de-facto standard in software quality.
Today, MISRA C:2004 is in use in nearly every area of the automotive industry where software is being developed. It is also present in safety critical applications in almost every industry throughout the world; defence, aerospace, railways, nuclear and process industries as well as commercial applications. In fact everywhere robust code is a critical necessity.
So, with MISRA C now the most widely used coding standard for the C language, why did MISRA decide to develop a new version? There were several reasons: support for C99, responding to user feedback and an acknowledgement that improvements could be made.
So what are the key differences compared to the previous version?
- The language: C has continued to evolve and support is now provided for C99 as well as the C90 standard.
- Rule classification: The addition of a new Mandatory rule class
- Rule compliance and enforceability: enhancements to ensure, that wherever possible, rules are amenable to automatic enforcement.
- Improved rule definition: More rigorous definitions with comprehensive explanations and rationales.
Support for C99
The C language shows no signs of relinquishing its popularity and continues to be heavily used in safety critical software development where reliability is a prime concern.
Back in 2004 there were few compilers and tools that supported C99 and therefore a decision was made to retain a commitment to C90, albeit a conservative approach.
Today the world has moved on, and despite reservations about the wisdom of certain developments in C99, it was decided at the outset of the project, that MISRA C:2012 should no longer stipulate conformance to C90.
The C99 language standard added some useful new features to the language, such as inline functions and type _Bool, but unfortunately it also introduced a range of new hazards. So 11 new rules have been introduced to curtail the usage of some potentially dangerous C99 language features.
Rule Classification
Rules in previous versions of MISRA C were divided into two categories: Required Rules and Advisory Rules. If code was to be MISRA C compliant it had to comply with every Required Rule unless a formal deviation could be raised. Deviations had to have a comprehensively documented reason for the non-compliance. Advisory Rules were by definition more flexible and did not require a formal deviation.
MISRA C:2012 has added a NEW third category – Mandatory Rules. These are non-negotiable rules whereby deviations are simply not permitted – because it is difficult to envisage a situation whereby non-compliance could ever be justified.
Rule compliance and enforceability
As the use of coding standards in general and MISRA C in particular has become widespread, the problem of how to define “compliance” has been brought into sharp focus. There is an acute need for coding rules, wherever possible:
a) to be clearly and unambiguously defined
b) to be statically enforceable
c) to be decidable
These are some of the guiding principles that have driven the development of MISRA C and they are the principles that have encouraged the development of widespread tool support for enforcement of the rules.
The capability of static analysis tools to provide reliable and accurate rule enforcement varies widely and in the absence of independent tool certification, claims of compliance with MISRA C need to be careful scrutinized.
Therefore, care needs to be taken in any tool selection because a characteristic of prime importance for any coding rule is the extent to which it can be enforced using static analysis tools. Automatic rule enforcement is a highly significant issue for several reasons:
a) It saves a lot of time
b) It is immediate, reliable, repeatable and consistent
c) It reduces dependence on manual code reviews and the attendant potential for embarrassment and argument
Image: Old vs. New: MISRA C:2012 incorporates a more differentiated approach towards software engineering. For full resolution click here.
MISRA C Guidelines have always emphasised the importance of static analysis and one of the notable features of MISRA C has been that so many of the rules are amenable to automatic enforcement. The enforceability issue has been enhanced in MISRA C:2012 in a number of ways.
- A distinction has been drawn between rules and directives; MISRA C:2012 contains 143 rules and 16 directives. Rules are requirements that are precisely defined and can be enforced solely by analysis of the source code. Directives may not be precisely defined and compliance may require reference to design documentation, functional requirements or some degree of subjective judgement or interpretation. Examples of directives include:
- “Sections of code should not be commented out”
- Assembly language shall be encapsulated and isolated”
- “Precautions shall be taken in order to prevent the contents of a header file being included more than once.”
- Rules are classified as “single translation unit” or “system” rules – reflecting the scope of the analysis which will be necessary in order to claim compliance. Compliance with some rules can be determined from analysis of a single translation unit – often from a small section of code. Other rules may require a much more extensive analysis of the entire code base.
- It is now explicitly recognized that compliance with some rules can never be guaranteed, however well defined the rule may be and however sophisticated the available tool support. This property of a coding rule is known as “decidability”. A decidable rule is one where, in theory, an analysis tool can always decide unequivocally whether the rule has been violated. In the case of an undecidable rule, there will be situations where no amount of analysis can provide a definite diagnosis.
Rule Definitions
Widespread use of the guidelines over a number of years has clearly provided valuable feedback that has contributed to a range of amendments and improvements. Rules are now better defined, explained and justified and there should be much less scope for different tools to provide divergent interpretation. Each rule now has several sections:
1. Amplification – an expanded explanation of the rule requirements
2. Rationale – an explanation of why the rule is necessary
3. Exceptions – specific situations where the requirements of a rule do not apply
4. Examples – compliant and non-compliant code examples
What does this mean for legacy code that is already MISRA C:2004 compliant?
The new version of MISRA C is larger than the last but the number of rules has not increased greatly. Some new rules have been added – mainly for C99, and a few have been removed or redrafted; but the increase in size is mainly a consequence of many improvements to the explanation and definition of rules.
While there are new requirements, these are relatively few, and code which complies with MISRA C:2004 is likely to comply with MISRA C:2012 with relatively little modification.
Conclusions
The ever increasing reliance on software within the automotive industry focuses more and more attention on the critical importance of ensuring reliability, and MISRA C has an important part to play. With support for C99, a range of improvements and detailed explanation of the rationale behind individual rules, MISRA C:2012 is a another step forward and an indispensable resource for anyone developing automotive systems in C who cares about software quality.
PRQA have set up a resource area dedicated to MISRA C:2012 containing white papers, fact sheets and videos designed to help developers find out valuable information about the new standard. It is located at www.programmingresearch.com/mc3
The MISRA C:2012 standard is available at www.misra.org.uk/shop.
About the author:
Paul Burden is a senior member of PRQA’s Technical Consulting Group and has served as a prominent member of the MISRA C Working Group for more than ten years. He has worked with clients around the world and has contributed to the development of MISRA C from his considerable experience in providing training and advice in the area of coding standards enforcement and the use of static analysis tools.
If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :
