Automotive software can be thought in terms of three distinct dimensions. The first dimension is the length and complexity of the code. Consider the startling fact that the average automobile has more lines of code than a fighter jet. Further with increasing sophistication of the software modules, software and time to market is often the differentiating factor – the speed of bringing new innovative features to the market establishes the OEM/supplier as the thought leader.

The second dimension can be thought of as the safety criticality of the software under development. Even a relatively minor software defect could lead to questions on the overall safety of the vehicle. A defect in software that necessitates recall of cars or causes a major hazard to the safe handling of the car could result in huge financial liabilities and loss of brand image.

The third dimension is the standards that the software needs to adhere to. This needs to be thought of as a separate dimension because not only do companies have to adhere to the various safety standards but they also have to clearly demonstrate this adherence. These standards are so widely prevalent among the industry that they have become by common consensus, regulations that all OEM/suppliers need to adhere to. These include standards like Motor Industry Software Reliability Association (MISRA), Software Process Improvement and Capability Determination (SPICE), AUTomotive Open System Architecture (AUTOSAR). Companies are now gearing up to adhere to the functional safety standard ISO 26262. Understanding ISO26262 and how it affects their software development process is a critical issue facing companies that develop automotive software.

What is ISO 26262?

ISO 26262 is a functional safety standard that is similar to IEC 61508 and addresses possible hazards caused by the malfunctioning of electric / electronic systems. ISO 26262 is intended to be applied to one or more electric / electronic systems that are installed in series production of passenger vehicles with a maximum gross weight of up to 3.5 tons. The standard:

• Covers the management and technical aspects of the complete safety development lifecycle
• Takes a risk-based approach for determining risk classes -Automotive Safety Integrity Levels (ASIL)
• Defines optional, recommended and highly recommended methods for development activities within system- hardware and software development depending on defined ASIL

There are 10 parts to the specification- Vocabulary, Management of functional safety, Concept phase, Product development on system level, Hardware development, Software development, Production and operation, Supporting processes, ASIL-oriented and safety-oriented analysis and Guideline on ISO 26262 (informative).

To illustrate some of the clauses, let us take a few important cases. The standard requires that the information pertaining to functional safety is identifiable, that requirements are logically grouped together and clear notations are used. Modifying the current documentation to add an attribute that describes the ASIL and using a tool that supports logical grouping and usage of informal or semi-formal notations would address these specifications. ISO26262 states that there should be requirements management tool and that three specific attributes be captured for each requirement– the ID (unique identification), the state (maturity level among the specified levels) and ASIL (safety rating). Further configuration management of requirements is mandated. In this context, usage of a tool that supports base lining would help both in traceability and configuration/product version management.

The IBM Rational software solution for automotive systems supports meeting ISO26262 norms. It accelerates successful adoption of ISO 26262 standards, streamlines the development process and helps reduce costs. Further it helps automate requirements tracking and documentation across integrated work flows. There are specific tools for each phase: Requirements (DOORS), Systems Modeling, Simulation, and Auto-Code Generation (Rhapsody), Configuration and Change Management (Rational Team Concert), Process (Rational Team Concert and Method Composer) & Verification and verification planning (Test Conductor and Rational Quality Manager).

For more information on ISO 26262 and IBM solution, please refer to the white paper by Prometo ,the solution brief and the YouTube video below.