Stock view of a Rover electric vehicle driving a muddy track.

Analysis: safe-code revision grapples with automated checking

The Motor Industry Software Reliability Association (MISRA), a group that developed one of the most widely-used coding standards for safe, reliable software, launched at Embedded World, Nuremberg this week, marking the first major update to the standard for almost a decade.

The Motor Industry Software Reliability Association (MISRA), a group that developed one of the most widely-used coding standards for safe, reliable software, launched at the Embedded World show in Nuremberg this week the first major update to the standard for almost a decade.

The process has, however, questioned the nature of coding standards and the ability to verify that code follows them. The MISRA-C standard provides programmers with a set of coding rules that prevent the use of coding constructs that are more likely to lead to errors. Chris Hills, MISRA-C team member and CTO of tools vendor Phaedrus Systems, said the shortcomings of C were realised early on with one of its creators Dennis Ritchie calling a number of its constructs “legal but dubious”.

To try to make C safer for use in their systems, engineers from car manufacturers Ford and Rover developed the initial MISRA guidelines that have now not just been adopted across the automotive industry but sectors that include military, aerospace, and the nuclear industry.

The first revision of the standard took place in the early 2000s, resulting in MISRA-C:2004. The forthcoming update follows a complete overhaul of the standard by a close-knit team of around ten UK-based engineers, initially to add rules that covered the most recent version of the C language.

“The driving force was the C99 standard,” said Mark Pitchford, field applications engineer at code-analysis tool vendor LDRA, “but the process used the feedback from MISRA C:2004 to address peoples’ concerns and dislikes.”

Paul Burden, technical consultant at Programming Research, another supplier of static code analysis software, agreed: “We could see there were improvements to be made.”

For the new version of the standard, the committee has implemented the concept of 'decidability' to determine which rules can be checked automatically by a static-analysis tool versus those that identify good practice but which do not have clear-cut distinctions and are difficult or impossible to verify without human involvement.

“One of the troubles for the big motor manufacturers is that they have suppliers shipping in software that are supposed to be MISRA C-compliant – but how do they verify it?” said Programming Research’s Paul Burden. “If rules are not well-defined, it makes life very difficult. How do you audit compliance?”

Pitchford added: “With decidable rules, if the rule says it’s wrong then it’s wrong”.

Undecidable rules, on the other hand, rely on interpretation. For example, one rule demands that no code be put into comments – largely to prevent developers from commenting-out segments of code to disable it. However, it is very difficult for a tool to determine whether a comment contains potentially executable code.

“This work has exposed the limitations of coding rules, which are often swept under the carpet when devising coding standards,” Paul Burden believes. “So the whole concept of compliance has been exposed as a debatable area. If you are claiming compliance the best you can do is say: ‘I am testing compliance with these tools’. It’s not black and white. It’s a best-effort process.”

Despite the problem of verifiability, much of the effort in developing MISRA C:2012 was aimed at reducing the level of doubt in static code analysis. “The other key coding standard is Cert C, which is more oriented towards the security industry rather than the safety-critical market,” Paul Burden at Programming Research said. “One of the key contrasts between the two, apart from Cert C being three times the size, its ratio of decidability is far, far lower than MISRA C. Although it contains very good advice, it’s very difficult to enforce… One of the reasons why MISRA C is being used is because it fits in very closely with the use of tool-based enforcement.”

An analysis from 2011 by market watcher VDC Research found that, after in-house coding standards, MISRA C was the one most commonly in use. Burden said: “What I would say is that if you look at most in-house coding standards, generally speaking, they tend to pick up MISRA C and modify it,” said Paul Burden at Programming Research. “I would say that MISRA C today is largely dominant even though it isn’t the biggest bar on the VDC graph.”

Pitchford argued that rewriting the rules to be more descriptive is likely to propel MISRA C further into mainstream programming: “This narrowing and focusing of the standard has also seen changes in terms of the English so that’s much more descriptive. It has become an educational document and not just ‘do as you’re told’. Although MISRA C has been used widely across the safety-critical sectors, it did tend to be something that people had to use because they were being certified to it – but the change in emphasis towards ‘use this rule because it’s a good idea’ opens it out to people who just want software to work.”

A number of changes reflect the growing diversity of systems being built in the embedded space. Some of the rules are considered mandatory by the new standard for the first time. “There are a few rules that we consider to be so common-sense and uncontroversial that there can be no sensible reason to deviate from them,” argues Paul Burden at Programming Research.

Other situations are more complex. “When you can implement critical systems on anything from an 8bit [Microchip Technology] PIC to a 64bit processor, it’s hard to find a rule that’s universal,” said Phaedrus Systems’ Chris Hills. “You can’t have 100 per cent MISRA-C compliance without deviation. It’s highly impractical for embedded systems because of the different architectures of the processors.”

Some industries cannot apply some of the rules because of the way their systems operate. “Originally we banned C unions. The trouble is that if you are doing communications systems, you normally need to use unions to get things in and out of the packet stream. For the most part, you should not use unions but if you deviate from that rule in one or two functions, that’s fine,” Hills concludes.

More information:

Sign up to the E&T News e-mail to get great stories like this delivered to your inbox every day.

Recent articles