Overview on ISO 26262

Let us introduce you to the formal structure of “ISO 26262 Road vehicles – Functional safety”. The up to date second edition of the standard consists of 12 parts. We’ll explain how you can achieve the functional safety of your product by using these parts together.

Part 1 defines the vocabulary to achieve a common language and interpretation of the content in the other parts. Here you’ll hear terms such as hazard analysis and risk assessment, safe state, and freedom from interference for the very first time.

Part 2 addresses the management of functional safety. According to ISO 26262, you have to work in a structured and controlled manner in order to achieve functional safety. This includes that you have defined and actually applied development procedures. You also need a trained safety manager. This person is in charge of planning and controlling the safety activities.

You have to create a so-called “safety case”. This includes a well-founded argumentation why your system is safe. Do not underestimate this task: You need an independent person who confirms your argumentation. This principle is mandatory to prevent misinterpretation and fraud.

Video functional safety management

Parts 3 through 7 of ISO 26262 give guidance for different phases and technical disciplines from the early concept stage to the junkyard. The structure of the parts follows the V-shape of the system development lifecycle.

Part 3 is called “concept phase”. This early stage of a vehicle and feature development is typically performed by the car maker. Development starts with defining the scope, which is called the “item” in ISO 26262.

Then we come directly to your first real functional safety activity. Perform a so called “hazard analysis and risk assessment (HARA)”. With the HARA you judge the risk to human life when your item is faulty. Based on the risk, you define a set of so-called “safety goals” for your item. These goals are high level safety requirements to be met. They all get an “Automotive Safety Integrity Level”: ASIL A, ASIL B, ASIL C or ASIL D. Classify your item to ASIL D when the risk is highest. Take the adaptive cruise control for instance: This item would typically be assessed ASIL D. An electric window lift where you just risk pinching your fingers would probably be ASIL A.

The determined automotive safety integrity level accompanies you for the rest of the lifecycle: A bulk of necessary safety activities for your item depend on the ASIL assigned. In fact, in ISO 26262 there is more or less rigor in what you have to do and how systematically to do it, corresponding to the identified risks.

What follows now is that safety goals must be addressed as one important aspect along with development. At the vehicle level, this means that, based on the safety goals, a “functional safety concept” and “functional safety requirements” must be developed. The purpose of that concept is to describe the principles of detecting faulty situations and how to react in such situations. For example, the airbag should be deactivated as soon as a safety mechanism detects that it is no longer working correctly.

If the functional safety concept is developed by the carmaker, the various suppliers now come into play with the system development on the next level (part 4). Typically, the suppliers create a “technical safety concept” for their area of responsibility, which includes “technical safety requirements”. “Safety mechanisms” implement these safety requirements and are often an interaction of hardware that detects errors, software that determines the response, and then again hardware that performs the response, such as to de-energize a circuit.

What you require on system level has to be implemented on hardware and software level. These are parts 5 and 6 of ISO 26262. Detail your safety requirements for both engineering domains hardware and software development. Remember the V-model: don’t forget to consider testing on all levels.

Especially test and validate the safety mechanisms and the functioning of your safety concept at system and vehicle level before you switch on the assembly line.

You must therefore note that ISO 26262 contains a number of requirements and methods that influence the usual development process at system, hardware and software level in detail.

Accompanying the development, safety analyses (according to part 9) must be carried out, which serve to have a precise understanding of the causes and effects of faults and thus to ensure the design.

Your responsibility doesn’t end with finished development. That’s why we come to part 7, Production, operation, service and decommissioning. It is often necessary to check that the electronics have been produced and installed safely. Repairs in workshops must not pose a safety risk. ISO 26262 requires planning accordingly. The field observation process is intended to ensure that defective parts are examined to determine whether there are deviations from the safety concepts and whether software needs to be updated or hardware replaced.

This completes the parts regarding the vehicle’s lifecycle. However, there are more parts in ISO 26262, so let’s have a look at those.

Part 8 is labelled "Supporting processes". In fact, you’ll find here a number of very different topics which have to be taken into account at various points throughout the lifecycle. That’s for example configuration management. Configuration management is similar to that required by Automotive SPICE.

Part 10 of the standard contains explanations for better understanding. This part is just informative but helpful.

Part 11 gives very detailed help on the use of semiconductors and microcontrollers in safety-related systems.

Finally, part 12 has been added especially for motorcycles. It essentially contains information on how the hazard analysis and risk assessment is sensibly carried out for bikes.

This concludes a quick overview of ISO 26262.