MISRA C 2012

Summary: MISRA C is probably the most popular firmware standard extant. Now there's an upgraded version.

MISRA C is probably the most popular of all firmware standards. Originally aimed at the automotive market its audience now includes pretty much every industry that builds embedded systems.

The new version is huge, at 236 pages about double the size of the previous standard. A few more rules were added, and the wording of many of the others changed. MISRA 2012 has better explanations of the rationale behind each rule.

Now there are rules as well as directives. The latter are guidelines which may require access to other resources to prove compliance. An example is Directive 3.1: "All code shall be traceable to documented requirements." Rules can be tested just by examining the code.

The CERT standard took a strong stand against code that can have unwanted side-effects (like careless use of the increment and decrement operators). MISRA 2004 had some rules about these issues, but the new version is much more explicit.

But some of the rules and directives leave me scratching my head. Directive 4.1 says "Run-time failures shall be minimized." What does that mean? How can one measure it? What does "minimize" mean, quantitatively? This rule almost leaves one thinking that it's an advisory against the use of C, which places the burden of taking care of runtime problems entirely in the programmer's lap. The guidelines suggest adding code to deal with problems and using static analyzers, both great ideas. But I can't see how one can claim conformance with the Directive without making some sort of formal argument rather like a safety case. And that's quite an expensive proposition.

5.2.1 goes further, and says, among other things, that developers have to demonstrate that run-time errors have been avoided. "Run-time error" is not defined, though examples (like arithmetic overflow) are given. Is code that doesn't implement a requirement properly a run-time error? Absent a proof-checking language like SPARK this seems more a wish than a command.

5.5 is probably wise but will be problematic for non-greenfield projects that require adherence to MISRA. To claim compliance one must assure, among other things, that all of the C code in the project meets MISRA 2012. Using Linux? Forget putting a MISRA badge on the project. Is there legacy code (and most projects use lots)? Well, I'd advise using MISRA for the new code, but you won't get compliance points.

I'm a strong advocate of MISRA. No one (well, with the possible exception of those who crafted the standard) likes all of the rules, but most of them make a lot of sense. MISRA is one way to get a firmware standard in place fast, one that has plenty of street cred. If you don't have regulatory compliance issues, overcome objections to the few rules you don't like by subsetting it.

Happily a lot of automatic compliance checkers exist, and LDRA has already announced support for the 2012 version. And, their tool lets you pick and chose which rules to check.

There's more info here: http://misra.org.uk/. You can get a .PDF for just œ15.

Published March 18, 2013