Car safety: History and Requirements of ISO 26262
E/E systems in vehicles are becoming ever more complex and are increasingly being used for critical functions such as advanced driver assistance systems. The average modern car now contains up to 20 million lines of code, and uses up to 100 ECU units to control various functions throughout the vehicle. In order to manage the complexity and to master functional safety aspects, OEM's and Manufacturers are placing their faith in a standard published in 2011 by the International Standards Organisation (ISO) that has had significant input from safety experts at carmakers such as Jaguar Land Rover. ISO 26262 is rare among safety standards in that no government has demanded its implementation. But vehicle manufacturers were swift to adopt it.
ISO 26262 was first published in 2011 to address this increase, to provide a framework that enables the identification of potential risks of software and hardware failure, and to apply a standard to ensure the functional safety of automotive E/E systems. ISO 26262 is an adaptation of IEC 61508 ‘Functional safety of electrical/electronic/programmable electronic safety-related systems’, applied to the specific requirements of passenger cars and light utility vehicles. The standard can be used for all activities applying to the lifecycle of safety-related systems involving electrical, electronic software during the development, production, management and service processes. In general, ISO 26262:
- Provides and supports an automotive lifecycle (management, development, production, operation, service, decommissioning)
- Outlines an automotive-specific risk-based approach (through Automotive Safety Integrity Levels)
- Helps avoid unreasonable residual risk
- Can be used to validate and confirm safety levels
- Provides requirements for relations with suppliers
The standard consists of ten parts, nine of which were published in 2011; the tenth part consists of guidelines to ISO 26262 and was subsequently published in 2012. The ten sections are:
- Part 1: Vocabulary
- Part 2: Management of functional safety
- Part 3: Concept phase
- Part 4: Product development at the system level
- Part 5: Product development at the hardware level
- Part 6: Product development at the software level
- Part 7: Production and operation
- Part 8: Supporting processes
- Part 9: Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyses
- Part 10: Guideline on ISO 26262
Image: ISO 26262 scope
ISSO 26262 is intended to be applied to safety-related systems that include one or more electrical and/or electronic E/E systems that are installed in series production passenger cars with a maximum gross weight up to 3500kg. The standard does not address E/E systems designed for specialist vehicles such as those designed for drivers with disabilities.
The standard only relates to systems and components under development after the publication date of ISO 26262, while those released for production or under development prior to publication are considered exempt. If any such systems undergo further development or alterations, only the modifications are required to be developed in accordance with ISO 26262.
The standard addresses possible hazards caused by malfunctioning behaviour of E/E safety-related systems, including interaction of these systems. It does not address hazards related to electric shock, fire, smoke, heat, radiation, toxicity, flammability, reactivity, corrosion, release of energy and similar hazards, unless directly caused by the malfunctioning of E/E safety-related systems; nor does the standard address the nominal performance of E/E systems, even if dedicated functional performance standards exist for these systems.
Automotive Safety Lifecycle
Image: ISO 26262 Lifecycle
ISO 26262 outlines an automotive safety lifecycle which describes the entire production lifecycle from management through to decommissioning. The processes within the lifecycle identify and assess hazards, establish specific safety requirements to reduce risks to an acceptable level, and manage and track those safety requirements to ensure that risk reduction is realised in the final product. The processes run parallel with, and can be integrated into an existing lifecycle of a quality management system. Essentially, the lifecycle requires that:
- Each product is identified and its functional requirements defined
- A comprehensive set of hazardous events are identified for the product
- An ASIL is assigned to each potential hazardous event
- A safety goal is determined for each hazardous event, inheriting the ASIL of the hazard
- A system architecture is defined to ensure the safety goals are met
- The safety goals are redefined into lower-level safety requirements
- These safety requirements are allocated to architectural components (subsystems, hardware and software components)
- The architectural components are developed and validated in accordance with the allocated safety requirements.
Automotive Safety Integrity Levels (ASILs)
Automotive Safety Integrity Levels (ASILs) are an extension of the Safety Integrity Levels (SILs) of IEC 61508. Upon hazard analysis and risk assessment at the beginning of the lifecycle, each safety requirement is allocated an ASIL ranging from A to D, with D having the most safety critical processes and the strictest testing requirements.
To determine ASILs, each hazard is assessed by exposure (the likelihood of a hazardous event occurring), by the severity of potential injury if the hazard occurs, and by the controllability of the driver to prevent or mitigate the injury. ISO 26262 classifies the criteria as follows:
- S0 – No injuries
- S1 – Light to moderate injuries
- S2 – Severe to life-threatening (survival probable) injuries
- S3 – Life-threatening (survival uncertain) and fatal injuries
- E0 – Incredibly unlikely
- E1 – Very low probability (injuries could happen only in rare operating conditions)
- E2 – Low probability
- E3 – medium probability
- E4 – High probability (injuries could happen under most operating conditions)
- C0 – Controllable in general
- C1 – Simply controllable
- C2 – Normally controllable (most drivers could act to prevent injury)
- C3 – Difficult to control or uncontrollable
These classifications enable the determination of an ASIL for each given component or system. An ASIL D constitutes the classifications S3, E4, C3; that life-threatening injuries have a high probability of occurring and the driver would have little chance of controlling the incident to prevent injury. For each single reduction in any one category (except from C1 to C0), there is a single reduction in the ASIL. Therefore a life-threatening injury (S3), that is uncontrollable (C3), could be classed as ASIL A if the hazard has a very low probability (E1) of occurring.
Qualification and Tooling
The qualification of hardware has two main objectives – to show how the part fits into the system, and to assess failure modes. Standard qualification is sufficient for some basic hardware components, but more complex parts require evaluation through ASIL decomposition and testing. They are typically qualified through testing in in a range of environmental and operating conditions.
Software qualification involves defining functional requirements, resource usage, and predicting software behaviour in failure and overload situations. To qualify a software component, the standard requires testing under normal operating conditions, and the insertion of faults into the system to determine how it reacts to abnormal inputs.
Testing is a critical part of achieving ISO 26262 compliance, and the standard details qualification for the tools used in testing. A Tool Confidence Level (TCL) is allocated to a tool, and this TCL along with the ASIL will determine the level of qualification required for the software tool. Two specific areas are evaluated to determine tool confidence level:
- The possibility of a malfunctioning software tool and its erroneous output can lead to the violation of any safety-related requirement allocated to the safety-related item or element to be developed
- The probability of preventing or detecting such errors in its output
The tool confidence level ranges from TCL1 to TCL4, with TCL4 achieving the highest level of confidence and TCL1 the lowest.
A Software Tool Qualification Plan (STQP) should be set out early on in the development lifecycle, and should focus on planning the qualification of the tool, and listing the use-cases that demonstrate the tool is classified with the required level of confidence. The two main elements that determine the TCL are Tool Impact (TI) and Tool Error Detection (TD).
Tool Impact is defined in two classifications:
- TI1 is selected where there is no possibility that the malfunctioning software tool can violate a safety requirement
- TI2 is selected in all other cases
Tool Error Detection has three classifications:
- TD1 for a high degree of confidence in the tool’s ability to detect an error
- TD2 for a medium degree of confidence
- TD3 for a low degree of confidence
The combination of Tool Impact and Tool Error Detection determines the Tool Confidence Level, and establishes the level of verification required.
To achieve ISO 26262 certification, the ‘designer’ must be convinced of the safety of the system/component, and present such evidence to an auditor. Part 2 of ISO 26262 outlines the need for a safety case, and Part 10 details its three main elements:
- A clear statement of what is claimed about the system
- The argument that the claim has been met
- The evidence that supports the argument
It is therefore essential that each step of ISO 26262 is adhered to, and that the correct procedures and tooling are used, and the analysis and evidence can be readily presented.