Advertisement

Five practical tips for MISRA compliance

June 18, 2019

MarkPitchford-June 18, 2019

Dozens of tools are designed to tell you whether your C or C++ code violates MISRA rules. But whilst identifying and addressing violations flagged by an analysis tool may well be a significant challenge for individual developers, it represents only one part of the compliance process for the development team as a whole.

In fact, it comes as a surprise to many that the MISRA C:2012 document contains six chapters of guidance before the guidelines themselves are defined!

Stepping back from the detailed analysis of violations, it is easy to see bigger questions about the process as a whole. MISRA’s document “MISRA Compliance:2016” receives much less press coverage than the language subsets themselves, but it is invaluable in understanding how the information highlighted by your static analysis tool of choice relates to the bigger picture of a MISRA compliant application.

It would be easy to misunderstand the nature of MISRA compliance, and to assume that a minimized violation count ensures optimized application safety and security. But to be effective, MISRA Guidelines need to be applied within a framework that leverages the advantages of the compliant code and manages any necessary deviations for the concept of compliance to have credibility.

The MISRA Compliance:2016 document is 33 pages long, and a short article like this one cannot touch upon everything it discusses. It can, though, give some insight into how a compliant project might look. These tips are derived from principles outlined in the MISRA Compliance document itself, and they reflect a little technical wisdom and a lot of common sense.

Tip 1. MISRA Compliance requires a documented software development process

MISRA Guidelines are intended for use within the framework of a formal software development process (as shown in Figure 1). Such a process will ensure complete, unambiguous and correct software requirements, and that all and only those requirements are reflected by the artefacts created at each phase of the development lifecycle.

click for larger image

Figure 1: Structured development lifecycle is essential to MISRA compliance, as illustrated by the “Uniview” in the TBmanager component of the LDRA tool suite. (Source: LDRA)

If your code exbibits no violations but doesn’t fulfil its required function, then it remains poor code.

Tip 2. Not all MISRA Guidelines can be checked by analysis tools

The MISRA C:2012 Guidelines introduced a system under which each guideline is classified as either a rule or a directive.

Typically, rules are sufficiently well defined to be checked by an automated tool, whereas directives are likely to be a little more subjective. For example, Directive 1.1 of MISRA C:2012 requires that “Any implementation-defined behaviour on which the output of the program depends shall be documented and understood”.

In MISRA C:2012, some rules are labelled “Undecidable,” meaning that it is fundamentally impossible to have a method that can, in general, say for sure whether a violation is present or not. A tool might warn of the potential for a problem, or it may not. Either way, some level of manual intervention is required.

Not all tools are the same. Some will claim more coverage of the rules than others, and some will be incapable of more subtle infringements. A tool showing “no violations” may really be saying "no violations, except the ones I've not spotted".

One Oxford Dictionary definition of “tool” is “A thing used to help perform a job”. Tools help – they don’t do the job for you.

Tip 3. Guidelines are only useful if there is a plan for their enforcement

For most guidelines, the easiest, most reliable, and most cost-effective means for enforcement is to use a static analysis tool, the compiler, or a combination of the two (see Figure 2).

click for larger image

Figure 2: Using an LDRA static analysis tool to enforce compliance to MISRA C:2012 (Source: LDRA)

For these guidelines it is important to ensure that the tool(s) to be used has been proven to be appropriate, and that its type and version are specified and fixed.

There must also be enforcement plans in place for those guidelines that require some manual verification.

Tip 4. “Deviation” is not a dirty word

For any real-life embedded application, it is very likely that some violations will be unavoidable. The management of these violations must be authorized through a clearly defined process and supported by appropriate “deviation record” documentation if any claim of compliance for the resulting application is to be credible.

These deviation records need to include the guideline(s) violated, the justification for this/these violation(s), the circumstances under which the deviation applies, and where in the code base it applies.

Tip 5. Adopted code can’t be ignored

Much of the documentation and many of the standards relating to functionally safe and secure embedded software starts from an assumption of a “green field” project. In real life, developers will be required to leverage in-house legacy code or third-party code such as device drivers, mathematical libraries, or graphical libraries.

Although it is clearly impractical to retrospectively apply MISRA guidelines to such code, for MISRA compliance to be claimed it is important to ensure that this co-called “adopted code” cannot compromise the safety and security of the system as a whole.

It is no coincidence that many functionally safe systems developed in accordance with standards including ISO 26262, IEC 61508 and DO-178C leverage the MISRA language subsets, and it would be easy to assume that MISRA compliance belongs only to those environments.

But that would be fallacy. It is equally true that aside from the guidelines in the language subsets themselves, many of the underlying requirements to be met before MISRA compliance can be justifiably claimed boil down to a common sense approach, and a dedication to “doing it right”. That cannot be the exclusive prerogative of the critical systems community, because a system does not have to be critical before there is motivation for it to work reliably.


Mark Pitchford has over 30 years’ experience in software development for engineering applications. He has worked on many significant industrial and commercial projects in development and management, both in the UK and internationally. Since 2001, he has worked with development teams looking to achieve compliant software development in safety and security critical environments, working with standards such as DO-178, IEC 61508, ISO 26262, IIRA and RAMI 4.0. Mark earned his Bachelor of Science degree at Nottingham Trent University, and he has been a Chartered Engineer for over 20 years. He now works as Technical Specialist with LDRA Software Technology.

Loading comments...