ISO 26262

from Wikipedia, the free encyclopedia

The ISO 26262 ( " Road vehicles - Functional safety ") is an ISO standard for safety-related electrical / electronic systems in motor vehicles . ISO 26262 defines a process model together with required activities and work products as well as methods to be used in development and production.

The implementation of the standard is intended to ensure the functional safety of a system with electrical / electronic components in the motor vehicle. The standard is thus an adaptation of IEC 61508 to the specific conditions in the automotive sector . The focus of the standard is on vehicles with a gross vehicle weight of up to 3500 kg, but not on prototypes or special vehicles such as conversions for the disabled. The standard is not applicable to systems that were developed before it was put into effect. The application of the standard is voluntary, but in practice more and more automobile manufacturers require their suppliers to use it in new projects.

After a long lead time (parts 1–9 published in April 2011 as Final Draft International Standard (FDIS)), the standard came into force on November 14, 2011 with the exception of part 10. ISO 26262 is being processed by the ISO working group “ISO TC22 / SC3 / WG16”. As part 10 ("informative guideline") took a long time to be drawn up, it was only published later, on August 1, 2012. A German-language version is not planned.

The "Second Edition" has been available since December 2018 and is referred to as ISO 26262: 2018 when citing. The new version has been revised and also contains parts 11 and 12 (see section Contents ). Training and material for the new version is provided by various providers in various formats (webinar, seminar, fact sheets, etc.) and a. also offered free of charge.

It is currently being discussed whether the current standard for artificial intelligence , which will find increasing application in the automobile of the future (e.g. autonomous vehicle ), is also valid or how it can be applied. However, the security of artificial intelligence is itself an independent research area.

Scope and background

With the steadily growing complexity of electronic components in vehicles, the possibility of malfunctions also increases. If a safety-relevant component is affected by such a malfunction, in the worst case scenario people can be harmed. Would z. If, for example, an ESP control unit in a motor vehicle unexpectedly triggers full braking when driving briskly, this could lead to a rear-end collision. In order to minimize the risk of dangerous malfunctions in safety-relevant electronic systems, these should be developed taking the relevant standards into account.

In the past, the recommendation was to develop electrical / electronic systems based on IEC 61508 that perform a safety-relevant function in automobiles and whose failure represents a significant risk for people or the environment . This standard can be applied generically to safety-relevant products, such as a safety switching relay for an emergency power shutdown. Since this standard is not sufficient or not specific enough for modern automotive applications, a new standard was created.

The users of ISO 26262 include automobile manufacturers, automotive suppliers and testing institutes. For example, if an automobile manufacturer or supplier wishes to develop a safety-relevant system or component, the client will usually require the application of a safety standard such as ISO 26262. In order to ensure the functional safety of the product, ISO 26262 requires from a corresponding safety level that a body that is organizationally independent of the development is involved. Here, too, the client often makes specifications, so that, for example, ASIL D requires testing by an external testing institute.

A test by a test center accredited for ISO 26262 in accordance with EN ISO / IEC 17025 is intended not only to provide evidence of safety but also to reduce the risks in the area of ​​product liability in the legal sense, although experience shows that this reduction cannot be measured in practice.

Process in development

(Standard terms in [brackets])

The start of a development according to ISO 26262 can be described in the following steps:

  1. The vehicle manufacturer who brings his product onto the market (= sells to end users) examines the circumstances and situations in which the vehicle could injure or kill people.
  2. Definition of safety goals that describe the undesired behavior, e.g. B. " Avoid unintentional starting of the vehicle ."
  3. Determine and assess risk, e.g. B.
    1. harmless (e.g. air conditioning control unit),
    2. low dangers [QM], which can do without special measures of the standard, or which
    3. Classification from [ASIL] (Automotive Safety Integrity Level) A to ASIL D for which the standard is to be applied.
  4. Identify components (the supplier) that could contribute, e.g. B. " Motor accelerates unintentionally " or " Automatic transmission leaves P or N by itself "
  5. Inform the component suppliers of the required function as a safety requirement, the ASIL and some other information in order to include them in the safety-oriented development.

activities

So that no errors creep in during development, the standard starts with the development of the components:

  • Risks are assessed according to their importance with an ASIL rating. The aim is to minimize the risks of a vehicle or one of its components to a "socially acceptable level".
  • Different methods are proposed to avoid systematic errors . The recommendations depend on the ASIL, and the higher the ASIL, the greater the requirements. For risks that were assessed with QM, the standard does not propose any specific measures, but refers to the measures that are already specified by the quality management system of the developing company.
  • In order to avoid random errors , the standard from ASIL B expects a quantitative evaluation of the electronic components (hardware). The product is examined according to the probability of failure, type of failure and environmental conditions with an FMEDA (according to Part 5, Annex D of the standard) or a fault tree analysis. From this investigation, diagnoses are derived which are intended to recognize and prevent dangerous states in good time - if necessary by switching off the product.

Demarcation

The ISO focuses on safety, hence functional safety . The "normal" function can be restricted or switched off in the interests of safety (system reaction).

This excludes various other points from consideration and treatment in the sense of this standard:

  • What does not belong to the specified function is not in the focus of the standard. The risk of burns on the engine is not part of the function (heating is not an engine function, but a "waste product"). Risk minimization in the case of non-functional hazards is part of general product safety and remains the responsibility of every manufacturer, but the measures of ISO 26262 do not have to be used for this.
Counterexample : The main function of seat heating is to warm up, so burns would be the result of an error in the main function.
  • The standard has focused on the development of series vehicles , including trucks, buses and motorcycles since the second edition.
  • The ISO affects both the vehicle as a whole and components from suppliers. In the standard text, however, no distinction is made between suppliers and vehicle manufacturers (OEMs).
  • The standard does not suggest any methods for mechanical, hydraulic and pneumatic components. The standard is limited to electrical, electronic and programmable components.

It is not enough that the function has been carried out correctly; the goal of development must also be that it has been carried out in the correct context or that it is not requested in the wrong situation. If, for example, the airbag is triggered in an accident situation, the function is perfect. If, on the other hand, it trips during normal driving, it could be a functional safety problem. However, the consequences for the driver's head are the same in both cases: in one case the desired function was carried out, in the other case the airbag was triggered by an error. The severity of an unintentional deployment was determined and assessed, for example in the case of an airbag.

The ISO is therefore to be seen as a guideline for safeguarding specifically in the function, which makes the scope of the safeguarding dependent on the risk and controllability of the malfunction.

content

ISO 26262: 2011 had ten items. The currently valid ISO 26262: 2018 now has twelve parts that cover the following content:

  1. vocabulary
  2. Functional safety management
  3. Concept phase
  4. Product development: system level
  5. Product development: hardware level
  6. Product development: software level
  7. Production, operation and decommissioning
  8. supporting processes
  9. ASIL and safety-oriented analyzes
  10. Guideline (only informative)
  11. Guidelines for the application of ISO 26262 to semiconductors
  12. Application of ISO 26262 for motorcycles

Part 1 explains the terms and abbreviations that are used in the series of standards.

Part 2 contains the required management activities during the different phases of the safety lifecycle of a system that includes E / E subsystems (electrical / electronic subsystems). Furthermore, the organizational requirements are mentioned that must be met so that the system to be developed can be developed according to the required ASIL ( automotive safety integrity level ).

Part 3 with respect containing requirements of the implementation of a risk analysis and risk assessment ( hazard analysis and risk assessment ). To do this, the potential hazards of the system must first be identified. This is done by considering the malfunctions of the system under investigation in specific driving situations. Then each hazard is classified with a safety requirement level from A to D or classified as not safety-relevant ( quality management - QM ). Unlike, for example, in IEC 61508 , the risk analysis in ISO 26262 is carried out using a fixed, qualitative method. For each identified hazard, the severity of the impact ( severity - S ), the frequency of the driving situation ( exposure - E ) and the controllability of the malfunction in the respective driving situation, e.g. B. can be estimated by the driver ( controllability - C ). The QM or ASIL A to D classification for each hazard can then be read from a given table.

As the ASIL increases, so do the safety requirements, which are specified in the following sections. There are no requirements placed on hazards of the QM class that go beyond the usual quality management of the system manufacturer, and their control can therefore be proven by successfully implementing a quality management standard such as ISO 9001 or ISO / TS 16949 .

Parts 4, 5 and 6 deal with the development processes on system level , hardware level and software level based on nested V-models and define procedures and work results for the individual sections. For the requirements to be implemented, methods are listed which, depending on the ASIL, are classified as optional , recommended or highly recommended . However, other methods not mentioned can also be used if their effectiveness in fulfilling the respective requirement can be justified.

Part 7 contains the basic procedure for creating a production and installation plan for safety-relevant systems in order to ensure the requirements for functional safety in the production and installation process, as well as the requirements for operation, maintenance, repair and decommissioning in compliance to ensure all safety aspects.

Part 8 includes both the description and assignment of responsibilities within a distributed development environment and the correct specification of the requirements for the entire safety lifecycle. In addition, the configuration and change management as well as the correct implementation of verifications and documentation are explained. This part of the standard also contains a section for reducing risks arising from software tools and software and hardware components. This includes, for example, risks that arise from errors in the compiler used.

Part 9 contains the rules of ASIL decomposition and criticality analysis. Part 9 also contains a section that explains how to carry out analyzes of dependent failures in order to identify "common cause" errors or cascading errors, as well as a section that describes the different analysis methods for detecting safety-critical errors and failures within an E / E- System.

Part 10 contains application examples, explanations and further information on some areas of the standard.

Part 11 deals with guidelines for the application of the standard for semiconductors. This part is especially relevant for many semiconductor manufacturers .

Part 12 deals with motorcycles.

Key terms of the standard

The following terms are usually not an exclusive creation of ISO 26262, but they mark the focus of this standard. According to the only language version of the standard, these terms are given in English and the usual German usage:

  • System in the sense of the standard can be the vehicle as a whole or also a component. Since vehicles consist of many components from external companies (suppliers), each of these suppliers has a system (also referred to as a component in the standard ) as part of the overall system that has to be developed.
A system consists of at least one sensor, logic (control, regulator) and one actuator.
  • ASIL : The ASIL mentioned above is used in the various parts of the standard to recommend measures. Especially in Part 5 (Hardware) and Part 6 (Software) there are numerous tables with methods and recommendations that depend on the ASIL.
For example, a deductive analysis as the FTA (Fault Tree Analysis is fault tree analysis ) until ASIL C and D particularly recommended.
The classification is the result of a hazard and risk analysis and ranges from QM (no application of the measures recommended by the standard necessary) to the highest requirements with ASIL D.
  • Safe State , Safe state : When a system detects its self-diagnosis malfunction, it will change to a state in which no danger emanates more from the system. This safe state depends on the type of overall system. In the case of an engine control of a car, this could be the "engine off" state, in the case of the engine control of a small aircraft (not in the focus of ISO, just as an example) it would be "full throttle".
  • Fault Tolerant Time Interval , fault tolerance time : If an error by the system is detected by self-diagnosis, has the safe state attained before a system can fail dangerously.
Example : If a transmission control needs 50 ms to open the clutch, change gear and close the clutch again, then the error " Unintentional gear shift from idling / standstill without driver intervention " could occur after 50 ms at the earliest because the vehicle could not start until the clutch was closed. The control's microprocessor must therefore check at least once every 50 ms and recognize whether the power output stage for the clutch control motor could have become independent due to an error and would be able to shift into gear by itself.
  • Freedom from Interference , absence of reaction : Here it comes, that can not always be resorted to components in a system designed according to the standard. Such components are, for example, COTS products such as microcontrollers , memory modules, operating systems (e.g. according to the AUTOSAR standard) or drivers for special components. In contrast to this, components that are involved in safety functions must be protected against the other components. A software module that carries out a safety-relevant calculation and saves the value must ensure when the stored data is recalled that it has not been changed in the meantime, for example by storing the data in several copies or comparing or creating checksums every time it is read and written.
  • Hardware Architectural Metrics , Hardware metrics : The metrics it comes to the system to be studied (if any electronic component in the system) to its failure potentiallity. It is important to assess how often an accidental failure of a component could bring the entire system into an unsafe state. From this analysis it should then be deduced at which points the reliability of the system can be improved and whether a certain level is reached.
The standard suggests two ways of calculating these failure probabilities. The most important tools are error models that describe the types of failure of component types (such as transistors, capacitors, resistors) and failure rates from other standards (e.g. Siemens standard SN 29500, see also Failure in Time ). The summary takes place in an FMEDA or an FTA.
  • Proven-in-use , operational reliability : If components of a system are to be reused or if they were used successfully and without errors by customers some time before the standard came into force, this experience can reduce the development effort when reusing them. Depending on the significance, the evidence or measures required by the standard may be omitted. The prerequisite is product observation and the analysis of the failures that have occurred in the customer's hands. Components can be hardware components and software modules, but also parts of the documentation prepared earlier, which itself only serves as evidence of a secure development. However, depending on the depth of the available data, only one argument of operational reliability can usually be applied to the overall device in a certain context. The crash of Ariane 5 showed that even components with evidence that were used in one proven system can lead to unsafe conditions in another system. The "proven-in-use" argumentation can only be used as evidence in very specific cases with clear diagnostic data.

Individual evidence

  1. See ISO 26262-1: 2011 (E), section "Scope".
  2. www.iso.org .
  3. Update to ISO 26262 - Functional safety for road vehicles. Retrieved August 16, 2019 .
  4. ISO 26262: The most important information about the second edition and SOTIF. Retrieved August 16, 2019 .
  5. ISO 26262: 2018 - Road Vehicles Functional Safety Standards - ANSI Blog. In: The ANSI Blog. February 15, 2019, Retrieved August 16, 2019 (American English).
  6. Fact Sheet Functional Safety / ISO 26262 | Vector Consulting. Retrieved August 16, 2019 .
  7. Functional Safety with ISO 26262 | Vector Consulting. Retrieved August 16, 2019 .
  8. ISO 26262 update. Retrieved on August 16, 2019 .
  9. ISO 26262 Functional Safety - Road Vehicles: Focus on Second Edition Changes. Retrieved August 16, 2019 .
  10. ^ Functional Safety and Artificial Intelligence. Retrieved on August 16, 2019 .
  11. “ISO 26262 is not perfectly designed for Artificial Intelligence”. May 28, 2019, accessed on August 16, 2019 .
  12. Krzysztof Czarnecki, Rodrigo Queiroz, Rick Salay: An Analysis of ISO 26262: Using Machine Learning Safely in Automotive Software . September 7, 2017, arxiv : 1709.02435v1 .
  13. DeepMind's plan to make AI systems robust, why it's a core design issue, and how to succeed in ML. Retrieved August 16, 2019 (American English).
  14. ^ AI safety resources. In: Victoria Krakovna. August 18, 2017, accessed on August 16, 2019 .
  15. ^ Understanding artificial intelligence ethics and safety. Retrieved on August 16, 2019 .
  16. Why AI Safety? Retrieved August 16, 2019 (American English).
  17. ^ Federal Court of Justice, judgment of June 16, 2009, file number VI ZR 107/08; This judgment also required the state of the art in science and technology for the development of the airbag.
  18. 14: 00-17: 00: ISO 26262-11: 2018. Retrieved on August 16, 2019 .
  19. The New ISO 26262 part 11. Retrieved on August 16, 2019 (English).
  20. 14: 00-17: 00: ISO 26262-12: 2018. Retrieved on August 16, 2019 .
  21. ISO 26262-1: 2011 1.129 system.
  22. For example in ISO 26262-4: 2011 section "7.4.3 Measures for the avoidance of systematic failures" Tab. 1.
  23. The standard does not use the term FMEDA, but sample calculations can be found in ISO 26262-5: 2011 Annex E.
  24. ISO 26262-8: 2011 Clause 14 “Proven in use argument”.

literature

Web links