Developing software is an art. Developing safe and secure software is not only an art, but requires a mindset that anticipates potential bugs, security vulnerabilities, and system failures. Both quality and security are hard to add to a product after its inception. It simply isn’t practical to add on to a product as quality and security are deep and pervasive characteristics. As such, it is advisable to start with solid architecture and robust code from the start.
Coding guidelines can help in developing robust code that is portable, safe to be run in high-assurance systems, and secure against common code exploits. Motivated by these insights, the Motor Industry Software Reliability Association (MISRA) published a range of reports, recommendations, and guidelines to ensure the development of safe and secure software. Most prominently are MISRA’s guidelines for the development of C and C++ projects. These include their MISRA C 2004, MISRA C++ 2008, and MISRA C 2012 standards.
Starting out in the automotive space, MISRA is now accepted across a range of domains. These include embedded, IoT, and industrial control systems. As such, it is not uncommon for medical devices, power plants, or aviation systems to comply, at least in part, with MISRA guidelines. Additionally, this has prevented countless critical failures.
MISRA defines much more than just coding guidelines. In fact, MISRA compliance is a well-defined concept that describes how to meet safety and security requirements along the supply chain. In other words, it defines acceptance criteria for software quality from a supplier to an acquirer of software. The compliance process is both rigorous (based on the aforementioned coding standards) and practical, explaining how to deal with exceptions to the rule(s) when necessary. However, this all deals with embedded in the context of typical contractual constraints, as well as common sense.
Let’s go into a bit more detail. We’ll now examine what MISRA compliance means, how to achieve it, and how to reap the benefits.
The MISRA coding guidelines are comprised of rules that are specific to C/C++ coding and directives. These are more general and might include, for instance, architectural considerations. These guidelines are further categorized by importance and are denoted as Mandatory, Required, or Advisory. MISRA compliance expects that no Mandatory guidelines are violated. However, for Required guidelines MISRA allows exceptional violations, as long as reasonable justifications are given. These justifications, called Deviations, aren’t given on the grounds of convenience. They’re allowed only on reasonable grounds when safety and security are not impacted and there is no acceptable workaround. Deviations are acceptable, for example, because of context. This can include hardware optimization constraints, third-party code that cannot be altered, or runtime performance without any easy way around it.
MISRA understands that each project is different and that supply chain contracts can vary the compliance requirements. It explicitly allows some level or re-categorization of rules, more general permits for deviations, or to slightly shift the notion of compliance with respect to the aforementioned categories. As such, MISRA compliance should always be closely negotiated with all parties in the supply chain.
In order to deliver a MISRA-compliant product, we advise you to follow a number of steps. These include a plan on how each MISRA guideline will be enforced. This could be through:
Moreover, be sure to document each change to default categorizations and the allowable deviation permits. The same holds true for all tool configurations, outcomes, and individual deviations (as well as who made each decision, why they made them, and who authorized these decisions). Essentially, all steps are good engineering practices and should not come as a surprise to many organizations. A final outcome would be a compliance summary that lists the results and references the decisions made along the way.
Without a doubt, achieving MISRA compliance requires a certain level of expertise, as well as proper planning and execution. Fortunately, there exists high-quality tool support for automating many of these steps. Thus, making MISRA compliance a much easier process. For instance, the Coverity static analysis solution fully supports all active MISRA standards, from MISRA 2004 to MISRA 2012, including its latest addendum. As such, MISRA checking can directly integrate as automatic scans in the software development life cycle (SDLC). Thus, supporting classical setups as well as modern Agile and CI/CD processes. This means that your development teams can be MISRA clean all the time while also dramatically improving both code quality and effort to achieve full MISRA compliance.
MISRA compliance doesn’t guarantee that a piece of software doesn’t contain any quality or security issues. However, by putting safety and security restrictions in software code, MISRA compliance code is more robust, easier to maintain, and more portable. Thus, additional testing and design efforts can focus more on high-level functional requirements. This frees up experts to deliver real value where it’s needed most.
Achieving MISRA compliance also sends a strong quality signal to acquirers of those products and enhances the trust in the delivering organization. This is particularly true in the absence of other widely recognized software quality metrics that aren’t superficial, but really require deep inspection. As a result, MISRA has rightfully gained its place in the highly safety-driven automotive industry. It is now being picked up in many adjacent quality conscious domains.
With the ever-increasing popularity of MISRA, it is worthwhile to explore how you can lift the quality of your own projects and products. Even if you are new to the code compliance concept, and just want to improve your overall product quality and security, the Synopsys team can help you get started. Let us guide you along your journey to achieving full compliance.