What is ISO 26262 and why should I care?

ISO 26262 is a functional safety standard intended to be applied to the development of software for electrical and/or electronic (E/E) systems in automobiles. It is aimed at reducing risks associated with software for safety functions to a tolerable level by providing feasible requirements and processes, such as:

• Functional safety management for automotive applications
• The concept phase for automotive applications
• Product development at the system level for automotive applications
• Software architectural design
• Product development at the hardware level for automotive applications
• Software unit testing
• Product development at the software level for automotive applications
• Production, operation, service, and decommissioning
• Supporting processes: interfaces within distributed developments, safety management requirements, change and configuration management, verification, documentation, use of software tools, qualification of software components, qualification of hardware components, and proven-in-use argument
• Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyses

To be clear, ISO 26262 isn’t mandatory (though it may become mandatory given all the recent headlines surrounding automotive safety defects). The laws simply state that you should develop software according to the current best practices – which in the automotive world is ISO 26262. What ISO 26262 brings to the table is an operational guide to software development best practices based on years of research by some of the most experienced people in the field.

The beauty of ISO 26262 is that although it is intended for safety-critical functions, it can be applied in principle to any software component that you care about. If you consider your integrated infotainment system a business differentiator in the market, develop it according to ISO 26262 and ensure that it’s the state-of-the-art system worth the upgrade to the premium model.

What about MISRA?

ISO 26262 is akin to saying that if you want to live longer, you should exercise and eat right. But what if your knowledge of exercise is limited to simply lifting heavy things, or if your knowledge of what constitutes good food is a raw egg in the morning?

This is where the MISRA standard comes in. The family of MISRA standards for C and C++, which include editions for 1998, 2004, and most recently 2012, tell software engineers what is good practice when writing code and what is bad practice. To return to our metaphor, MISRA tells you what foods are good for you and what constitutes safe, reliable exercise.

How do I implement ISO 26262 and MISRA?

Achieving compliance with ISO 26262 and MISRA starts with a commitment to best practices in the form of policy. To be clear, a policy is not a guideline, which suggests or recommends behavior. A policy is an automatically enforceable statement prescribing in plain language how software should be developed – and why it should be developed in this way. The policy must explicitly state that:

• Software must be developed according to the software development lifecycle (SDLC) as defined by ISO 26262
• Code will not be accepted from downstream subcontractors that don’t provide adequate traceability proving compliance with the standard

Your development policy should have similar language specifying compliance with MISRA coding guidelines. This gives a manufacturer another form of acceptance test they can perform to certify software received from downstream vendors.

(Click graphic to zoom)

Functionally speaking, this means applying development testing activities, such as static code analysis, unit testing, peer review, and runtime error detection to ensure that code is being developed according to these policies. There are several tools on the market that implement MISRA guidelines in the form of static analysis rules (full disclosure, we work for a company that sells these tools). Every tool has its own methodology for enforcing coding standards, so you will need to research the best tool for your environment, budget, and so on.

Static analysis

This practice has been around for a long time and continues to be a cheap (in terms of dedicating development resources) way to pick the low hanging fruit in your code. Unit testing is considerably more expensive in terms of resources despite many auto-test generation solutions due to the maintenance, parameterizations, corner cases, and other aspects of the activity that require human intelligence. That said, the cost of failure still outweighs the cost of testing by a wide margin.

Peer Code Review

This procedure requires software engineers to submit their code for review as a regular part of the development process, and is known to be the most effective activity for ensuring software quality. As with unit testing, this activity requires you to expend resources, but the cost is negligible if it prevents a defect that would have required a recall.

Runtime error detection (RED)

RED monitors code execution in order to tease out constructs that only emerge at runtime, and should be implemented as a validation and verification process. RED helps you find code that results in race conditions, exceptions, resource and memory leaks, security vulnerabilities, and other hard-to-find defects. Put simply, it’s instrumentation for the software in the same way that gauges and recorders are instrumentation for the hardware.

Coverage analysis

Without a measurement of how much code is covered by tests, you cannot know if you’ve done enough testing. By itself, coverage analysis does very little, but when paired with an activity such as unit testing, coverage analysis provides invaluable information about your software.

Conclusion

Software is everywhere and will continue to play a greater role as our once simple products become “smarter.” This is especially true in automotive development, which presents a unique challenge in terms of ensuring the safety, security, and reliability of the embedded applications. Automotive blends safety-critical software with business-differentiating software, all of which is developed in a highly distributed manner.

The bottom line is that end-to-end testing for automotive applications is too expensive and too complex. On the other hand, the cost of software failure should serve as motivation for finding a way to mitigate risks. By applying automotive software development standards, such as ISO 26262 and MISRA, automakers put themselves in the best position to avoid the risks associated with faulty software.

Arthur Hicken is Chief Evangelist at Parasoft.

Adam Trujillo is a technical writer at Parasoft.

Parasoft

Website: www.parasoft.com

@Parasoft: https://twitter.com/Parasoft

LinkedIn: https://www.linkedin.com/company/parasoft

Facebook: https://www.facebook.com/parasoftcorporation?ref=s

Google+: https://plus.google.com/+Parasoft/posts

YouTube: https://www.youtube.com/user/ParasoftCorp