MISRA 2012 Compliance

Following a standard like the Motor Industry Software Reliability Association (MISRA) C is a great step towards writing safer, better and less buggy code. If a development team is taking the steps to implement code to meet the MISRA C standard it may make sense to take the extra step of fully complying with the standard. The advantage of this is that then the project can be declared to meet MISRA C. There are a number of steps that need to be performed in order to show compliance.

There are three prerequisites processes that need to be in place for compliance. The first, is a documented software development process. The purpose of this is to ensure that a consistent method of developing and testing software is place. The second is that a software style guide exists and is conformed to. The reason for this is that a clear and documented style makes the software clearer and easier for other developers to understand. Finally a rules deviation process needs to exist to justify non-compliance with the rules listed in a compliance matrix.

The pre-requisite processes are a great starting point to showing compliance but the real nuts and bolts of compliance is the compliance matrix. The compliance matrix is a list of each mandatory, required and advisory guideline. Each rule is listed in addition to whether or not it was complied with, how it was complied with and tested in addition to a reference to deviation explanations. An example compliance matrix provided by MISRA in the standard can be found in Table 1. A comprehensive compliance matrix can be downloaded from Beningo Engineering.

Many of the guidelines within the MISRA C standard can be checked by using automated tools. MISRA requires that for each tool used be documented. The documentation required must show the tools version number, the options used when running the tool and any configuration data that was required in order to the run the tool. This allows for a 3rd party or even other developers on the team to verify compliance. The tool that needs to be documented even includes the compiler! It is important to note whether the project is being compiled for C90 or C99 standard.

At the end of the day, the MISRA C standard requires these things to show that the project software is in full compliance. Interestingly enough, they also list that the developers need to be “suitably skilled and have a sufficient range of experience”. For being so detailed in how to setup tools and develop a compliance matrix and deviation process, they are relatively silent on this interesting and relatively vague compliance requirement. Either way, showing compliance for a project can go a long way in showing quality and robustness of the software.