FDA Tool Validation Checklist

MISRA and ISO 26262 explained

on Dec 3, 14 • by Roy Sarkar • with No Comments

MISRA and ISO 26262 play a big role in automotive software development today. Here's a brief explanation of what they mean and how static code analysis can help...

Home » Software Compliance, Static Analysis » MISRA and ISO 26262 explained

Two standards are playing a big role in automotive software development today, MISRA and ISO 26262. 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 becoming mandatory for almost any automotive supplier, it’s important to understand the intent behind them – and how static code analysis fits them easily 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 most in 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 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 19.1: All #include directives in a file shall only be preceded by other preprocessor directives or comments.<br />
MISRA C rule 2.2: You should only use /*…*/ style comments.

to checks for potentially dangerous issues:

MISRA C rule 9.1: Unintialized variables.

Klocwork static code analysis provides automated detection of potential MISRA rule violations on-the-fly, as developers are writing code. This means violations are found at the earliest possible point, when they’re the 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 here (C) and here (C++).

ISO 26262

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 Rish 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.

Learn more:
• Watch how static code analysis and a certified RTOS contribute to functional safety and ISO 26262 compliance in this webinar
• See the complete list of Klocwork MISRA checkers here (C) and here (C++)

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top