In civilized societies, rules are developed to protect lives and possessions. Any time exceptions to the rules are granted, the rest of society can find their own safety and security impacted. This holds true for software as well. Standards and guidelines such as MISRA C establish an accepted set of rules that are designed to help developers write high-quality code, using proven best practices to create software that is measurably safer as well as more secure, understandable, and maintainable.

Of course, there can be circumstances under which it is impracticable or unreasonable to follow every software coding requirement to a T. This has led to a system in which certain violations of MISRA rules are approved, allowing developers to claim compliance even though there are known deviations to the standard. But any time a system of exceptions is established, those exceptions can be taken advantage of to the detriment of the safety the rules were designed to protect. In the case of MISRA exceptions, a myriad of approaches have evolved, ranging from a “no deviations allowed” policy to a liberal use of deviations simply to document non-compliance. Over time, this approach has left both OEMs and end users vulnerable, despite their justified expectations for safe and secure software.

One result is increased risk and liability for software developers.

Jack Ganssle—an embedded systems engineer, author, and speaker—is often called upon as an expert witness in cases that involve embedded systems, including software. He is increasingly seeing compliance to MISRA guidelines being accepted as a metric of software quality by the courts.

“When I’m testifying on a subject as complex as embedded software, I have to make the concept of software quality understandable and quantifiable in order for the court to establish liability,” says Ganssle. “People understand the use of accepted rules and standards. I can explain how compliance to the MISRA rules would have prevented a software fault and I can categorically state the number of MISRA violations in the software that is the basis of the case. Even a non-technical judge and jury can immediately understand where the liability falls. Developers of embedded software need to seriously consider their risk if they’re not maintaining compliance to the MISRA standard.”

But the news isn’t all bad. Increased recognition of MISRA’s role in assuring software quality also provides new opportunities for competitive advantage. Software developers who fully understand the MISRA rules and how to prove compliance may find themselves in a much better position when large OEM customers are comparing potential suppliers. In fact, large OEMs—especially those from the automotive market where non-compliance to safe coding practices has resulted in well-publicized system failures—provided strong encouragement for the MISRA committee to develop new MISRA compliance guidance.

The just-released MISRA Compliance 2016 document is designed to help developers achieve and show compliance with MISRA coding rules. The new document provides clear guidance on the use of deviations and defines what is meant by MISRA compliance. It also provides a mechanism for establishing pre-approved permits for deviation and for tailoring the classification of guidelines.

While MISRA C was originally designed to promote the use of the C language in safety-critical embedded applications within the motor industry, it has gained widespread acceptance in many other industries for any application with high-integrity or high-reliability requirements. Development teams that must provide assurance that their code meets high quality standards for both safety and security need to understand these new rules as well as the risks of non-compliance.