ISO 26262

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 the required activities and work products ( "work products" ) and methods to be used in development and production.

The implementation of the standard is to ensure the functional safety of a system with electric / electronic components in the vehicle. Thus, the standard is an adaptation of IEC 61508 to the specific conditions in the automotive industry. The focus of the standard are vehicles up to 3500 kg permissible total mass, but not prototypes or special vehicles such as conversions for the disabled. The standard is not applicable to systems that were developed before it was enacted. The application of the standard is voluntary, but in practice require more and more automotive manufacturers require their suppliers to use in new projects.

After a longer lead ( parts 1-9 in April 2011, published as a Final Draft International Standard ( FDIS )) is the standard with the exception of Part 10 came into force on November 14, 2011. The ISO 26262 is processed by the ISO working group "ISO TC22/SC3/WG16 ". Since the creation of part 10 ( informative guideline ) took a long time, it was only later, published August 1, 2012.

A German -language version is planned. It can be assumed that is started within three years, with the first revision of ISO 26262, so that can be expected with the " Second Edition " from 2017/2018.

Scope and Background

With the ever growing complexity of electronic components in vehicles also increases the possibility of malfunction. If a safety-related component of such a malfunction affected, people can be injured in the worst case. If, for example, unjustified trigger an ESP control unit in a motor vehicle with speedy ride on the brakes, this could lead to a pile-up. To minimize the risk of hazard- malfunction of safety related electronic systems, these should be developed taking into account relevant standards. In the past, was the recommendation, electrical / electronic systems that perform a safety-related function in automobiles and their failure means a grave risk to humans or the environment to develop on the basis of IEC 61508. This standard is generic security-related products, such as a safety relay for emergency shutdown applicable. Since this standard is not sufficient for modern automotive applications or not specific enough, a new standard was created.

Among the users of this standard include car manufacturers, automotive suppliers and institutes. Wants to develop, for example, an automobile manufacturer or suppliers a safety-related system or component must be based on a security standard such as ISO 26262 this. To ensure the functional safety of the product is required by the ISO 26262 standard from an appropriate level of security that an organizationally independent from the development site (eg, an external test institute, but may also take an internal QM site) consulted will. An examination by an ISO 26262 according to EN ISO / IEC 17025 accredited laboratory may then be used in the legal sense in addition to the proof of safety and the reduction of risks in the area of product liability.

The ISO 26262 is to be considered as a contribution to the state of science and technology in relation to the functional safety of road vehicles functional safety the unanimous view of the German experts (consensus at the last symposium on functional safety ).

Content

ISO 26262 consists of ten parts covering the following content:

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

Part 2 includes the required management activities during different phases of the safety life cycle of a system I / E subsystems includes ( electrical / electronic subsystems). Furthermore, the organizational conditions are mentioned that must be met in order to the required system to be developed ASIL (automotive safety integrity level ) can be developed.

Part 3 contains requirements for the implementation of hazard analysis and risk assessment (hazard analysis and risk assessment ). Must first be identified to the potential hazards ( hazards ) of the system. This is done by consideration of malfunction of the system studied, in specific driving situations. Then each hazard is classified with a safety integrity level from A to D or classified as non-safety- relevant ( quality management - QM). Unlike, for example, in IEC 61508 the risk analysis done in the ISO 26262 using a specified, qualitative methodology., The frequency of the driving situation ( exposure - E) and the controllability of the malfunction in the current driving situation, for example by the driver ( controllability - C) - given the severity of the effect (S severity ) shall, for each identified hazard individually be estimated. For a given table, then the classification QM or ASIL A to D can be read off for each hazard.

With increasing ASIL, the demands on security, which are specified in subsequent parts. At threats to the class QM no demands are made that go beyond the usual quality management system manufacturer, and their control can therefore by a successful implementation of a quality management standard, such as ISO 9001 or ISO / TS 16949 demonstrated.

Parts 4, 5 and 6 deal with the development processes at the system level, hardware level and software level in line with nested V models and define for each section procedures and results. Methods are listed for the requirements to be implemented, which are classified depending on the ASIL as optional, recommended (recommended) or highly recommended ( highly recommended). However, it can also be used other than as referred to methods if their effectiveness to meet the particular requirement can be justified.

Part 7 contains the basic steps when creating a production and installation plan for safety-related systems to ensure the requirements of functional safety in the manufacturing and installation process, as well as the requirements that the operation, maintenance, repair and decommissioning under the compliance all safety aspects to ensure.

Part 8 includes both the description and assignment of responsibilities within a distributed development environment, as well as the correct specification of the requirements for the overall safety life cycle. Furthermore, the configuration and change management as well as the proper performing of verification and documentation explained. This part of the standard also includes two parts, one for the reduction of risks arising of software tools and software as well as hardware components. This includes, for example, risks arising from errors in the compiler used.

Part 9 contains the rules of the ASIL decomposition and the criticality analysis. Furthermore, part 9 contains a section that explains the implementation of analyzes dependent failures to identify common cause failure or cascading errors, and a section that shows the different methods of analysis for the detection of safety-critical faults and failures within an E / E - system.

Part 10 includes application examples, explanations and other information to some areas of the standards.

Key concepts of the standard

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

• System in terms of the standard may be the vehicle as a whole or a component. Since vehicles of many components from other companies ( suppliers) exist, each of these suppliers has a system ( in the standard referred to as Component) as part of the total system which must be developed.

• ASIL: The already mentioned ASIL is used in different parts of the standard to recommend action. Especially in Part 5 (hardware) and Part 6 (software), there are numerous tables with methods and recommendations, which are of the ASIL -dependent.

• Safe State, Safe state: When a system by its self-diagnosis function detects a fault, it will change to a state in which pose no more danger from system. This safe state is dependent on the nature of the overall system. In an engine control of an automobile, this could be the state of "motor off", wherein the motor control of a small airplane (not the focus of the ISO, only as an example), it would be "full throttle".
• Fault Tolerant Time Interval Error tolerance time: If an error by the system is detected by self-diagnosis, the safe state must be reached before a system can fail dangerously.

• Freedom of Interference, absence of feedback: The aim here is that in a system can not be always resorted to components which have been developed according to the standard. Such components include, for example COTS products such as microcontrollers, memory chips, operating systems (eg after AUTOSAR standard) or drivers for special components. In contrast to components that are involved in security functions are protected especially against the other components. A software module that performs a security-related computation and stores the value, must ensure the recall of stored data that they have been not been changed, for example by it stores the data in multiple copies or to any read / write checksums compares / created.
• Architectural Metrics hardware, hardware metrics: When the metrics, it is important that the system (if each electronic component in the system) is examined for its failure modes out. It is important to evaluate how often a random failure of a component could bring the whole system in an unsafe state. From this analysis should then be derived, at which points the system reliability can be improved and whether a certain level is reached.

• Proven - in -use, proven in use: If components of a system are to be reused or some time have been successful and error-free use before the entry into force of the standard of customer, you can reduce the development effort for reuse with this experience. Depending on the importance can be omitted required by the standard of proof or measures. The prerequisite is a product monitoring and analysis of the failures that have occurred in the customer's hand. Components can be hardware components and software modules, but also parts of the earlier comprehensive report, which only serves to prove a secure development itself.