Understand the new MISRA compliance and deviations guidance

May 16, 2016

Blog

Understand the new MISRA compliance and deviations guidance

In civilized societies, rules are developed to protect lives and possessions. Any time exceptions to the rules are granted, the rest of society can fi...

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’s measurably safer and more secure, understandable, and maintainable.

Of course, there can be circumstances under which it’s impracticable or unreasonable to follow every software coding requirement to a T. This has led to a system in which certain MISRA rule violations are approved, which lets developers 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, myriad 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 internationally recognized 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 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 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’s 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’s 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.

Chris Tapp is a Field Applications Engineer at LDRA, with more than 20 years of experience in embedded software development. He graduated from the University of Durham in 1987 and has spent most of his career working within the automotive, industrial control, and information technology industries. He serves in the MISRA C working group, and is currently chairman of the MISRA C++ working group.

Jay Thomas is a Technical Development Manager for LDRA Technology, and has been working on embedded software applications in aerospace systems since the year 2000. He specializes in embedded verification implementation and has helped clients on projects including the Lockheed Martin JSF, Boeing 787, as well as medical and industrial applications.

Chris Tapp, LDRA Technology
Categories
Software & OS