Overview of MISRA C++ (2008)

Introduction

Software to Control Autonomous Car

MISRA C ++ is a software development standard for C and C++ programming language that aims to facilitate code portability and reliability in the context of embedded systems, specifically those systems programming in ANSI C. Its mission is:

 “ To provide assistance to the automotive industry in the application and creation within vehicle systems of safe and reliable software”

MISRA - A Brief History

In 1998 MISRA targeted only the automotive industry but later released it focus on generic rules for developing safety-critical applications such as: anti-lock braking system (ABS), and auto-pilot software system etc. No major changes have been made to the MISRA C++ standard after the version released in the year 2008.

Every autonomous vehicle developed can only be allowed for commercial or industrial use if each of its hardware and software component adheres to the required standards. In case of the software used or developed for such systems its components and structure all should adhere to the MISRA standard:

• The standard is not intended to be used as an introduction or training aid to the subjects
• The standard assumes that the readers are familiar with ISO C++ programming language standards
• In case of automatic code generation tools used for the development of a safety-critical system for automotive industry the code developed by an automatic code generation tool fully satisfies the full set of MISRA C++ rules

Steps to Developing a Software System Adhering to MISRA Standard

Step # 1: Compliance Matrix

MISRA guidelines and IEC 61508 requires the use of standardized structured language for critical systems defined by ISO/IEC 14882:2003. The standard emphasis on the use of static checking tools. The objective is to enforce compliance with the subset while hoping it to become a common practice by the developers of the critical systems.

Sample Compliance Matrix

• Rule that cannot be checked using static checking tools are reviewed manually
• Any additional restrictions used by the developers are also added to this matrix
• The matrix shows the rule checked along with how it is checked
• Where restrictions are omitted a full justification is required
• MISRA compliance is for the project and not for the company

Step # 2: Deviation Plan

In some instances it may be necessary to deviate from the rules given stated by MISRA standards e.g. we may need to use proprietary extensions to the language in order to write a code to interface with the hardware i.e. micro-controller. This requires a formal deviation plan. The use of this deviation must be justified on the basis of both the necessity and safety. 

Sample Deviation Plan

The deviation plans can be divided into 2 types:

Types of Deviation Plan

Both types of deviation requests should include the following: 

• Details of the deviation i.e. Rule being violated
• Circumstances in which the need for the deviation arises (not required for Specific Deviation Request)
• Potential consequences which may result from the deviation
• Justification for deviation
• A demonstration of how safety is assured

The circumstances usually occur as a result breaking rules concerned with the input/output operations. Thus is recommended that the input/output concerns are kept separate from other parts of the software.

Step # 3: Formalization within Quality System

Following formal documentation of are subjected to internal and external audits associated with the quality systems to help ensure their consistent use:

• Subsets
• Static checking tools
• Deviation procedures

Claiming Compliance

Claiming the compliance of a software developed requires audit proofs of the following:

• Compliance matrix has been completed showing how compliance has been enforced
• All of the C++ code in the product is compliant with the rules of MISRA or are subjected to the documented deviations
• A list of all instances of the rules not being followed is being maintained, and for each of these instances, there is an appropriately signed-off deviation
• The standard requires the documentation of the issues related to the language to be selected for the development of a safety critical system adhering to MISRA standard along with the decisions made as these may be used as safety justification. Following issues have been addressed:

1. Training
2. Style guide
3. Compiler selection and validation
4. Checking tool validation
5. Metrics
6. Test coverage

MISRA Rules

The developed software for automotive systems should adhere to the 12 rules of MISRA that can be classified into 3 categories:

Required rules:

These rules are mandatory requirements placed on the developer. Any software developed in C++ should conform to these rules of MISRA C++. Formal deviations must be raised where this is not the case.

Advisory rules:

These requirements are placed on the developer that should normally be followed i.e. these rules are not mandatory but should also be not ignored. Formal deviations are not necessary for such rules by may be raised if it is considered appropriate.

Document rules:

These rules are mandatory requirements placed on the developer whenever the associated feature is used within code. Deviations are not permitted against this category of rules.

There are some rules that have an exceptional condition under which are not required to be followed. Rules of MISRA are mainly classified based on aspect of the programming language discussed:

References

Guidelines for the Use of the C++ Language in Critical Systems, ISBN 978-906400-03-3 (paperback), ISBN 978-906400-04-0 (PDF), June 2008.