If you don’t currently use MISRA C or MISRA C++ checks in your C/C++ development process, you may have assumed that it was only used for automotive applications. That wouldn’t be surprising, given that the standard comes from the Motor Industry Software Reliability Association (MISRA).
MISRA is a coding standard specification that includes a large number of rules, most of which can be checked automatically by a static analysis tool. Static analysis tools can significantly reduce the number of errors in code, but few use these effectively (if at all). The Barr Group’s 2017 Embedded Systems Safety & Security Survey notes that only 9% of developers in critical application areas use full automated tools (see figure).
The Barr Group’s 2017 Embedded Systems Safety & Security Survey notes that only 9% of developers in critical application areas use full automated tools like static analysis.
According to Barr Group CTO Michael Barr, “Regardless of your end application, an important step to having a safer, more secure embedded system is to have a written coding standard that all code in the project must conform to. Coding standards, such as MISRA-C/C++ Guidelines and Barr Group’s Embedded C Coding Standard, are designed specifically to reduce the number of potential bugs. However, simply using a coding standard is not enough. They must be enforced. Ideally, conformance with every one of the rules would be automatically checked via a tool like a static analyzer. Unfortunately, compliance with some types of good coding standard rules cannot be enforced with a tool. In that case, a human-powered code review is the best supplement.”
Process-related operations like code reviews are useful, but they often miss minute or obscure problems that can be just as catastrophic as architectural problems. A proper development process would include multiple coding standard aspects.
MISRA standards include a set of rules that often limit the use of the language, thereby eliminating many of the common errors that programmers tend to make (often by mistyping the code). For example, Rule 5.2 indicates that Identifiers in an inner scope shall not use the same name as an identifier in an outer scope, and therefore hide that identifier. This means that a common variable name like reset should not be used as a global and as a local in a function.
Rule 12.4 is Do not use expressions with side effects. This catches actions such as assignments within an expression. A common error is using the assignment operator (=) instead of a comparison (==).
Most C and C++ compilers have compile time flags that tell the compiler to check for some of these rules, although the flags are usually not described with respect to static analysis standards like MISRA or the Barr Group’s free Embedded C Coding Standard.
Software vendors are becoming more aware of the need for delivering code that has been checked using automatic tools. For example, HCC Embedded released its MISRA-compliant CryptoCore embedded-cryptography suite. The CryptoCore software libraries are managed through HCC’s Embedded Encryption Manager (EEM), which is also checked in a similar fashion. HCC’s Extensible Authentication Protocol (EAP) framework is part of the mix, as well. Its MISRA-compliant network stack is designed to support secure wireless connections for embedded devices, only some of which might wind up being in a car. Does your network stack meet these requirements?
HCC is not alone. NXP’s Kinetis SDK v2 for Kinetis microcontrollers also falls into this growing amount of code that has been checked using static analysis tools. “All drivers and startup code are MISRA-C:2004 compliant and checked with Coverity static analysis tools.” Synopsys Coverity is one of a number of vendors with extensive static analysis tools that exceed the scope of MISRA. Other tool vendors in this space include LDRA, Grammatech, Klockwork, Parasoft, and Programming Research. Synopsys does offer a free service called Coverity Scan that is available for open source projects.
One reason why MISRA C/C++ is needed is that the languages and compilers do not provide the support necessary to eliminate many of the common errors that plague developers. The language specifications simply do not allow for that. There are programming languages that do, however, such as SPARK and Ada. These are often used in space and avionic applications that have even stricter requirements than automotive applications. SPARK takes the analysis process to the extreme—to the point where an application meeting a set of requirements is provable.
Regardless of what tools are used, it is clear that more automated checking will only benefit companies that utilize these tools. Correct code is a requirement for safe and secure applications. It is also more cost-effective in the long run, because finding and fixing bugs greats progressively more difficult and costly as applications move to beta, and then out in the field.
