Two standards play a big role in automotive software development today, MISRA and ISO 26262, with another one gaining ground: AUTOSAR. Even though most developers recognize the names, they’re often reluctant to build these standards into their day-to-day lives, hoping someone else will worry about them. Since these standards are mandatory for many automotive suppliers, it’s important to understand the intent behind them – and how static code analysis fits compliance testing into day-to-day development activities.
Some would say MISRA stands for More Irrelevant Software Requirements Again but, since it’s release in 1998, this C/C++ coding standard has been embraced by the automotive software development industry. Originally intended to provide guidance to facilitate safe and reliable software coding practices for the automotive industry, MISRA standards have been adopted by many other industries developing safety-critical embedded software including telecom, aerospace, defense, and medical. The guidelines consist of over 140 rules and 16 directives for MISRA–C and over 220 rules for MISRA–C++, covering code safety, portability, and reliability issues that plague embedded systems developers. They range from very simple checks for coding style:
MISRA C rule 20.1: #include directives should only be preceded by preprocessor directives or comments
MISRA C rule 2.7: There should be no unused parameters in functions
to checks for potentially dangerous issues:
MISRA C rule 9.1: The value of an object with automatic storage duration shall not be read before it has been set
MISRA C:2012 Amendment 1 introduced new security guidelines, with the intent to cover code security concerns highlighted by the ISO C Secure Guidelines, ranging from input validation to memory overflows.
Klocwork static code analysis provides automated detection of potential MISRA rule violations on-the-fly, as developers are writing code, or as part of continuous integration (CI) builds. This means violations are found at the earliest possible points, when they’re easiest to fix.
The breadth and depth of coverage is best illustrated by a cautionary example: when taking an existing software code base and applying the entire MISRA rule set right away, it’s guaranteed to throw many errors. In fact, running a MISRA check on the zlib project, which is obviously not MISRA compliant, throws over 5000 issues – nearly one issue for every line of code and not something to take on right away.
Instead, its good practice to select the most critical (or likely to be audited) components first and build up from there. Of course, when writing code from scratch, on-the-fly analysis will report issues on a much smaller scale and well before code ever leaves the desktop.
You can see the complete mapping of Klocwork MISRA checkers to MISRA rules:
ISO 26262 is a functional safety standard that applies to production passenger vehicles up to 3500 kilograms (7716 pounds) and is designed to address possible hazards caused by malfunctioning electronic and electrical systems. Examples of these systems include anti-lock brakes, advanced driver assistance systems (ADAS), engine control units, and digital instrument clusters. The standard is an adaptation of the higher-level IEC 61508 standard which sets out requirements for ensuring that systems are designed, implemented, operated, and maintained to provide the required safety integrity level (SIL). Both standards take into account the increasing use of tools for software application development and explicitly require that development tools be qualified.
Unlike MISRA, which is a coding standard, ISO 26262 defines methods and measures to ensure that development lifecycle processes and tools avoid or control systematic and random failures in automotive systems. It uses measures such as Automotive Safety Integrity Levels (ASIL) and artifacts such as Hazard Analysis and Risk Assessments to ensure a sufficient and acceptable level of safety is being achieved.
When it comes to software verification tools, they cannot, on their own, ensure compliance to ISO 26262 as they’re a small part of the overall processes, tools, and strategy used to deliver automotive systems. They can be used by developer teams seeking to demonstrate compliance, by partially or fully addressing many of the requirements found in Part 6 of the standard, covering “Product Development at the Software Level.” This section examines the correctness of software design and implementation.
Klocwork is ISO 26262 and IEC 61508 certified, allowing developers to use a certified set checkers to find and fix security vulnerabilities and critical defects with confidence, knowing that they have been designed, developed, tested, and released in an audited and certified manner. Klocwork also provides guidance to ensure that developers use static code analysis in a functionally safe way that supports eventual ISO 26262 certification.
The rise of AUTOSAR
The AUTOSAR partnership has set out to create an open and standardized automotive software architecture, and defined guidelines for the use of C++14 for safety-related and critical environments. The standard is designed to pick up where MISRA C++:2008 left off and specifies over 340 rules – 154 of which are adopted without modification from MISRA, 131 derived from existing C++ standards, and the rest based on industry research.
This video, which we presented at Embedded World 2018, explains the standard and how static code analysis can help achieve compliance.
If you’re a current Klocwork user, you can obtain the Klocwork AUTOSAR C++14 taxonomy here to report on violations of the standard.