Three headaches with MISRA compliance
Software bugs are frustrating, inconvenient and expensive in any industry. But, in safety-critical, mission-critical or security-critical sectors, the consequences are not only disruptive to business. A single, subtle bug can be catastrophic to people’s lives.
In the car industry, for example, the number of safety recalls linked to software failures has risen by 30% a year since 2012. Toyota recently recalled more than 2.4 million hybrid vehicles worldwide because of a fault in their systems that could cause them to lose power.
Manufacturers and component suppliers must ensure the code safety, security and reliability of embedded systems. This is increasingly seen as the benchmark across all safety-critical industries. The courts are not lenient with manufacturers who fail to ensure such software compliance and consumer protection.
We frequently talk to companies across safety-critical sectors, such as motor, aerospace, railway and medical devices. They all have to comply with industry standards, such as ISO 26262 in the automotive industry or RTCA DO-178B/C for the aerospace sector, when developing safety-critical embedded software. Such standards mandate programming language sub-setting and MISRA C/C++ are very often the subsets of choice. Nearly all our interlocutors describe their three main headaches as:
1. Why is it so complex?
There are around 170 MISRA guidelines (directives and rules) specifically for the C programming language. Further complexity arises because this language has been around since the 1960s and is not really one language. In reality, it’s more like a huge family with thousands of dialects that can be implemented across everything from small hearing aids to supercomputers: there are around one thousand C compilers in existence, and most of them support many C dialects that are selectable by non-standard, compiler-specific options.
There are now millions of lines of code in every car. It’s plainly impossible for humans to analyze and signal all the instances where the code violates MISRA. So tools are needed, but tools need to be adapted to the tool-chain that is being used and to the way it is used, as well as to the entire build process.
Given the complexity, it’s not surprising this process is also highly error-prone. Configuration requires an in-depth knowledge of C and C++, and even then, it is easy to make mistakes. Particularly because of pre-processing features (such as predefined macros and conditional inclusion) and the hundreds of implementation-defined aspects of the languages. In one company we talked to, one person spent two months trying to configure their own software verification tool. Another fared even worse; they spent three months working on this and even then did not succeed.
Because of misconfiguration, you could be wasting time chasing non-existent MISRA violations or risk being exposed by undetected ones. But, there is worse.
2. How do we know we’re verifying the right code?
This is the big, contentious issue with MISRA compliance and software verification. How can manufacturers prove that the software verified is the software actually embedded in the end system? In other words, when you’re running your MISRA compliance process, are you sure you’re verifying the right code?
As a manager, you will have to put your signature to the declaration that the code has been verified. If something wasn’t configured correctly, or if one line of code has been edited, your team could be analyzing code that is not the code actually running in the car or airplane. This gives a false sense of security.
3. How do we provide evidence?
If the worst happens and disaster strikes, could you prove your software compliance in court? To do that, your verification needs direct interaction with the compiler tool-chain and built-in forensics to prove that the code you have analyzed is the code that is actually embedded.
If you would like to learn more about how BUGSENG can help smooth your path to MISRA compliance you can contact us here. We can help you address coding standard issues and enforce MISRA C and MISRA C++ rules with our ECLAIR verification platform.
Roberto Bagnara, Ph.D is CTO of BUGSENG, a leading provider of solutions and services for static code analysis. He is also a member of the ISO/IEC JTC1/SC22/WG14 - C Standardization Working Group and the MISRA C Working Group.
Meet us at the Embedded World Conference in Nuremberg
BUGSENG's CTO Roberto Bagnara is giving a presentation: "The MISRA C Coding Standard: A Key Enabler for the Development of Safety- and Security-Critical Embedded Software" on Tuesday 26 February 2019, 10:30AM at the Embedded World Conference in Nuremberg, Germany.
You can also visit the BUGSENG team on stand 4-545 at any time during the conference (which runs from 26 to 28 February 2019). We will be happy to answer any questions you may have about our blogs or related topics.
For more details visit https://www.embedded-world.eu/home.html