Functional Safety: ISO26262 Seminar Paper Embedded systems group Aniket Kolhapurkar, University of Kaiserslautern, Germany kolhapur@rhrk.uni kl.de September 8, 2015 1
Abstract Functions in car, such as adaptive cruise control, crash protection systems, active body control and electronic stability program are increasing in complexity and taking an ever more active role in controlling the car [6]. The pace of innovation in automotive industry today results in increasing complexities. A modern automobile contains more than 100 million lines of code[8]. Compare that to the Boeing 777, with only 3 million lines of code. Code in an automobile is used in up to 100 electronic control units, or ECUs, to control dozens of functions, including brake and cruise control and entertainment systems. These systems are also built to work together. With this complexity should only drivers be blamed for the car accidents? Safety is a key issue in automotive development.it is a challenge of the automotive industry to test and validate these components. The goal of ISO 26262 is to provide a unifying safety standard for all E/E 1 systems specific to the automotive industry. This paper provides description of ISO 26262 so as to understand how this standard helps in achieving the desired safety. 1 Introduction 1.1 Background Functional safety is the part of the overall safety that depends on a system or equipment operating correctly in response to its inputs i.e. freedom from unacceptable risk of physical injury or of damage to the health of people, either directly, or indirectly as a result of damage to property or to the environment[2]. E/E 1 systems, IEC 61508[1] is the parent standard that covers all aspects of safety. It covers all industries, and includes risk analysis, and a safety lifecycle. However, 61508 is a generic standard. Other industries, such as nuclear, and railway, have developed their own standards based on 61508. ISO 26262 is the adaptation of IEC 61508 that addresses the safety needs of the automotive industry for E/E components. It includes an automotive safety life cycle, automotive-specific risk analysis, and verification and validation (or V & V) so that systems achieve an acceptable level of safety. 1.2 Scope ISSO 26262 is intended to be applied to safety-related systems that include one or more E/E systems that are installed in series production passenger cars with a maximum gross weight up to 3500kg [3]. The standard does not address E/E systems designed for special 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 1 electrical and electronic 1
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. 2 Overview of ISO 26262 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 chapters are: 1.Vocabulary 2.Management of functional safety 3.Concept phase 4.Product development at the system level 5. development at the hardware level 6.Product development at the software level 7. Production and operation 8.Supporting processes 9.Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyses 10.Guideline on ISO 26262. Figure 1: Overview of ISO 26262 *img: [7] ISO 26262 outlines an automotive safety life-cycle which describes the entire production lifecycle from management through to decommissioning. The overview of the life-cycle is as follows: A 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. System architecture is defined to ensure the safety goals are met. The safety goals are redefined into lower- 2
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. 3 Structure of ISO 26262 This section gives the details of all the chapters mentioned in Section2, which will help to understand the ISO 26262 standard. 3.1 Chapter 1. Vocabulary ISO 26262-1:2011 specifies the terms, definitions and abbreviated terms for application in all parts of ISO 26262[3].Vocabulary is synonymous to a Project Glossary and these terms serve as a key to standards definition of functional safety processes and helps in avoiding ambiguity in understanding of the processes. Some example terms in this chapter are as below: Item: system or array of systems or a function to which ISO 26262 is applied; Fault: Abnormal condition that can cause an element or an item to fail. Error: Discrepancy between a computed, observed or measured value or condition, and the true, specified or theoretically correct value or condition. Failure: Termination of the ability of an element to perform a function as required. Note: Since an element s specification defines its required function, the standard recognizes incorrect specification as a potential a source of failure. 3.2 Chapter 2. Management of Functional Safety ISO 26262-2:2011 specifies the requirements for functional safety management for automotive applications with regards to the organizations involved (overall safety management), with regards to management activities in the safety life-cycle,see Fig 2 (i.e. management during the concept phase and product development, and after the release for production)[3]. refer Fig 1 The outcomes of the 2-5 Overall Safety Management are a set of organizationspecific rules and processes for functional safety, evidence for the competence and qualification of the persons in charge of carrying out the activities and evidence of a proper quality management system. During 2-6 item development the objectives are the definition of safety management roles and responsibilities, and the definition of the requirements on the safety management, regarding the development phases E.g. appointment of safety manager who is responsible for the safety management during item development and involved development phases[5]. The safety plan shall include the planning of: strategies, and activities for achieving functional safety; Hazard analysis and risk assessment; Development of the safety requirements; Analysis of dependent failures, and the safety analysis; Verification and validation activities. The safety management 2-7 after release for production involve activities for ensuring the functional safety of the item after release for production and this shall be planned, initiated during system development. The organization shall institute processes and appoint persons for maintaining the functional safety of the item in the life-cycle phases after release. 3
Figure 2: Safety Lifecycle *img: [7] 3.3 Chapter 3. Concept Phase ISO 26262-3:2011 specifies the requirements for the concept phase for automotive applications, including the following[3] refer Fig 1 3-5 Item definition: It defines and describes the item and supports an adequate understanding so that each activity of the safety life-cycle can be performed. The functional requirements of the item, as well its dependencies, shall be available. The outcome is the Item definition. 3-6 Initiation of the safety lifecycle: it makes the distinction between a new development and a modification of a previously existing item. Safety Life-cycle for given item is adapted based on: New development: consider all safety lifecycle steps relevant, Modification of an existing component/system: tailor safety lifecycle following an impact analysis of the modifications. Impact analysis considers the proven in use argument (see Chapter 8) if original component/system was not developed based on ISO 26262. 3-7 Hazard analysis and risk assessment: it identifies potential unintended behaviours of the item that could lead to a hazardous event. The hazards of the item shall be systematically determined, with techniques such as brainstorming, check-lists, FMEA 2 and field studies, in terms of the conditions or events that can be observed at the vehicle level. For each identified hazardous scenario, an ASIL 3 is determined. ASIL is classified with respect to severity, probability of exposure or controllability see Fig 3a. The severity, exposure, controllability is further classified as in Fig 3b. The ASIL asks the question, If a failure arises,what 2 Failure mode and effects analysis 3 Automotive Safety Integrity Level 4
(a) ASIL (b) Severity,exposure,controllability (c) ASIL table Figure 3: ASIL calcualtion *img: [7] will happen to the driver and associated road users? [4] e.g. Lets assume hazard i.e. An airbag explodes when infant is sitting in front seat has following severity (s3), controllability (C3), exposure (E2), then it results in ASIL B refer Fig 3c A safety goal shall be determined for each hazard, and expressed in terms of functional objectives. 3-8 Functional safety concepts: it derives the functional safety requirements, from the safety goals, and allocates them to the preliminary architectural elements so as to ensure required safety Fig 4.The outcome of concept phase is Item definition, Impact Analysis, Hazard analysis and risk assessment, Safety goals Review of hazard analysis, risk assessment and the safety goals, Functional safety concept Review of the functional safety requirements. 3.4 Chapter 4. Product Development: System Level ISO 26262-4:2011 specifies the requirements for product development at the system level for automotive applications, including the following[3]: refer Fig 1 4-5 Requirements for the initiation of product development at the system level: Identify and plan the functional safety activities for each sub-phase of system development It includes supporting processes activities, methods to be used, tailoring of the lifecycle. 4-6 Specification of the technical safety requirements: Its Objective is to develop the technical safety requirements, refinement of the functional safety requirements considering the preliminary architectural assumptions from Functional safety requirements. 4-7 System design: Objective is to develop the system design and the technical safety concept, verify that the system design and technical safety concept comply with the technical safety requirements specification. 4-8 Item integration and testing: Objective is to integrate the elements of an item and test 5
Figure 4: Functional Safety Concept *img: [7] the integrated item for compliance with each safety requirement and Verify that the system design is correctly implemented by the entire item. 4-9 Safety validation: Evidence that the safety goals are correct, complete, and fully achieved at the vehicle level. It Includes: E/E system, software (if applicable), hardware, and elements of other technologies, external measures. 4-10 Functional safety assessment: Objective is to assess the functional safety achieved by the item. It is initiated by the entity with responsibility for functional safety e.g., the vehicle manufacturer. 4-11 Product release: It specifies the criteria for the release for production at the completion of item development i.e ready for series-production and operation. It requires appropriate documentation of functional safety for release for production e.g. Name and signature of person in charge of release, Version of released item, etc. 3.5 Chapter 5. Product Development: Hardware Level ISO 26262-5:2011 specifies the requirements for product development at the hardware level for automotive applications, including the following[3]: refer Fig 1 5-5 initiation of product development at the hardware level : The scope is to determine and plan the functional safety activities during the individual sub phases of hardware development, which is included in the safety plan. 5-6 specification of the hardware safety requirements : The scope is to make available a consistent and complete hardware specification that will be applied to the hardware of the item or element under consideration, and to verify that the hardware safety requirements are consistent with the technical safety concept. The outcomes are Hardware safety requirements specification and verification report, hardware architectural metrics requirements, and refined Hardware software interface specification. 5-7 hardware design: The objective is to design the hardware with respect to the system design specification and hardware safety requirements, and to verify such a design against the system design specification and hardware safety requirements. The outcomes are Hardware design specifications, Hardware safety analysis report, Hardware design verification report and Requirements for production and operation. 5-8 Hardware architectural metrics: objective is to 6
evaluate the hardware architecture of the item against the requirements for fault handling as represented by the hardware architectural metrics. The considered metrics are: diagnostic coverage, single point faults metric, latent fault metric. The outcomes are Assessment of the effectiveness of the system architecture to cope with hardware random failures and its review. 5-9 Evaluation of violation of the safety goal due to random hardware failures and hardware: The scope is to infer if the residual risk of safety goal violation, due to random hardware failures of the item, is sufficiently low. The used methods evaluate the residual risk of safety goal violation due to single point faults, residual faults, and plausible dual point faults, by also considering coverage of safety mechanisms and exposure duration in case of a dual point fault: Use of a probabilistic metric to evaluate the violation (e.g., quantifies FTA 4 ), and comparison with a target value; Individual evaluation of each residual and single point fault, and of each dual point failure. The outcomes are Evaluation of random hardware failures, Specification of dedicated measures and review report of evaluation of violation of the safety goal due to random HW failures. 5-10 Integration and testing: The scope is to ensure the compliance of the developed hardware with its requirements. Tests shall be planned and specified w.r.t. the safety plan, and executed w.r.t. the item integration and testing plan. The outcome is Hardware integration and verification report. 3.6 Chapter 6. Product Development Software Level ISO 26262-6:2011 specifies the requirements for product development at the software level for automotive applications, including the following[3]: refer Fig 1 6-5 initiation of product development at the software level: The scope is to plan and initiate the functional safety activities for the following subphases of the software development. Specifically, appropriate methods, and relative tools shall be determined to achieve the requirements of the assigned ASIL. The outcomes are a refined Safety plan, Software verification plan, Design and coding guidelines for modeling and programming languages, and Software tool application guidelines. 6-6 Specification of the software safety requirements: The goal is to specify the software safety requirements, derived from the technical safety concept and system design specification, to detail the HIS 5 requirements, and to verify that the software requirements are consistent with the technical safety concept and the system design specification. The outcomes are Software safety requirements specification, refined HIS specification, refined Software verification plans and report. 6-7 Software architectural design: The objective is to develop a software architectural design that realizes the software safety requirements and to verify the software architectural design. The software architectural design shall exhibit modularity, encapsulation and minimal complexity. The outcomes are Software Architectural design Specification, refined Safety plan, refined Software safety requirements specification, Safety analysis report, Dependent failures analysis report and refined Software verification report. 6-8 Software unit design and implementation: The goal is to specify the software units in accordance with the software architectural design and the associated software safety requirements, to implement the software units as specified and to verify the design of the software units and their implementation. Outcomes are Software unit design specification and implementation and a refined software verification report. 6-9 Software units testing: A procedure for testing the software unit against its specification is established. The following testing methods can be used for proving compliance with specification and HIS, correct implementation, absence of unintended functionality, robustness, and 4 Fault tree analysis 5 Hardware software interface specification 7
sufficiency of the resources e.g. requirements based test, interface test, fault injection test. The outcomes are refined Software verification plan, Software verification specification, and the refined Software verification report. 6-10 Software integration and testing: The scope is to integrate the software components and demonstrate that the software architecture is correctly realized. Integration levels are tested against the architectural design. The integration test methods shall prove that the software is compliant with software architectural design, and the specification of HIS, correct implementation of the functionalities, robustness and sufficiency of resources. The outcomes are refined software verification plan and specification, software verification report. 6-11 Verification of software safety requirements: The goal is to demonstrate that the embedded software fulfils the software safety requirements. Test shall be conducted in the test environments and on the target hardware e.g. Hardware in loop, Vehicles. Outcomes are refined software verification plan, specification and report. 3.7 Chapter 7. Production and Operation ISO 26262-7:2011 Specifies requirements on production, operation, service, and decommissioning[3] refer Fig 1 7-5 Production objectives: Develop a production plan for safety-related products, Ensure that the required functional safety is achieved during the production process e.g. considers requirements for production, conditions for storage, transport, and handling of hardware elements, approved configurations. 7-5 Operation, service (maintenance and repair), and decommissioning objectives: Define the scope of customer information, and maintenance and repair instructions regarding the safety-related products in order to maintain the required functional safety during operation of the vehicle, before disassembly. E.g. considers requirements for operation, the warning and degradation concept, measures for field data collection and analysis, maintenance plan describes methods required for maintenance including steps, intervals, means of maintenance, and tools. 3.8 Chapter 8. Supporting Processes ISO 26262-8:2011 consolidates common requirements to maintain consistency with processes like [3] refer Fig 1 8-5 Interfaces in case of distributed development: It describes procedures and allocates responsibilities within distributed developments (e.g., vehicle manufacturer and supplier) for items and elements by specifying DIA 6. Outcomes are Supplier selection report, Development Interface Agreement, Safety Assessment Report Supply agreement. 8-6 Specification Management of Safety Requirements: Ensure correct specification of safety requirements with respect to attributes and characteristics (unambiguous, comprehensible, atomic, hierarchical, traceable etc.) Outcome is Safety Plan (refined) 8-7 Configuration Management: Ensure traceability of relationships and differences between earlier and current versions with unique identification and reproducibility of products. Outcome is configuration management plan. 8-8 Change Management: The analysis and management of changes to safety-related work products occurring throughout the safety lifecycle. It involves systematically planning, controlling, monitoring, implementing, and documenting changes, while maintaining consistency of all work products. Outcomes are change management plan, change request, change report. 8-9 Verification: Ensure that all work products are correct, complete, and consistent; and meet the requirements of ISO 26262. Outcomes are verification 6 Development Interface Agreement 8
plan, specification of Verification, report. 8-10 Documentation: Develop a documentation management strategy so that every phase of the entire safety lifecycle can be executed effectively and can be reproduced Outcome is document management plan. 8-11 Qualification of Software Tools: It provides evidence of SW tool suitability for use in developing a safety-related item or element. A SW tool is classified based on Tool impact(ti) i.e. possible violation of safety requirement if tool is malfunctioning or producing erroneous output (TI0 no possibility, TI1 possibility) Tool detection(td) i.e possibility of preventing or detecting that the software tool is malfunctioning or producing erroneous output (TD1 TD4) Tool confidence level(tcl) i.e. based on tool impact and tool detection determinations (TCL1 TCL4). Outcomes are software tool classification analysis, software tool documentation, and software tool qualification report. 8-12 Qualification of Software Component: The goal is to enable the re-use of existing software components as part of items, systems, or elements developed in compliance with ISO 26262 without completely re-engineering the software components. Outcomes are software component documentations, qualification report. 8-13 Qualification of Hardware Components: To show the suitability of intermediate level hardware components and parts for their use as part of items, systems, or elements, developed in compliance with ISO 26262 and provide relevant information regarding Failure modes and their distribution Diagnostic capability with regard to the safety concept for the item. Outcomes are Qualification plan Hardware component testing plan, Qualification report. 8-14 Argumentation of the Proven in use: Provides guidance for proven in use argument as Alternate means of compliance with ISO 26262 requirements i.e. used in case of reuse of existing items or elements when field data is available. Outcomes are Proven in use credit, Definition of candidate for proven in use argument, Proven in use analysis reports 3.9 Chapter 9. ASIL oriented and safety oriented analyses. ISO 26262-9:2011 specifies requirements for ASIL oriented and Safety oriented analyses[3]. It includes following refer Fig 1 9-5 Requirement decomposition w.r.t ASIL tailoring: It provides guidance for decomposing safety requirement into redundant safety requirements to allow ASIL tailoring at the next level of detail. 9-6 Criteria for co-existence of elements: (i.e. within the same element of safety-related sub-elements with non-safety-related ones and sub-elements with different ASILs).A non-safety-related sub-element coexisting with safety-related sub-element(s) shall be treated as QM 7 also refer Fig 3c if there is no functional dependency, and there is no interference with any other safety-related sub-elements. Otherwise, it will receive the highest ASIL of the coexisting safety-related elements with which there may be interference. A safety-related sub-element shall receive the lower ASIL if it does not interfere with any other element with higher ASIL, for each safety requirement allocated to the element. Otherwise, it will have the highest ASIL. 9-7 Analyses of dependent failures: The objective is to identify any event that could invalidate the independence between elements of an item required to comply with its safety goals. 9-8 Safety analyses: The objective is to examine the consequences of faults and failures on items considering their functions, behaviour and design. It also provides information on conditions and causes that could bring violations to a safety goals or requirement. Last, it could indicate new hazards not found during the hazard analysis and risk assessment. 7 quality management 9
3.10 Chapter 10. Guideline on ISO 26262 ISO 26262-10:2011 provides an overview of ISO 26262, as well as giving additional explanations, and is intended to enhance the understanding of the other parts of ISO 26262[3]. It describes the general concepts of ISO 26262 in order to facilitate comprehension. The explanation expands from general concepts to specific contents. In the case of inconsistencies between ISO 26262-10:2012 and another part of ISO 26262, the requirements, recommendations and information specified in the other part of ISO 26262 apply. 4 Conclusion ISO 26262 provides a standard and supports Functional safety throughout automotive life-cycle. It is used to certify the electrical and electronic components of passenger cars and light utility vehicles and treated as published state by lawyers. However the automotive companies have encountered problems in implementing this standard as it adds many process related activities to companies e.g. (QM) 6 development processes (ASIL dependent). Also finding competent personnel with both specific engineering skill and functional safety expertise can be challenging. Published estimates have ranged from additional 15% - 30% of impact to overall project man-months. (ASIL B) [9]. The ISO 26262 working group is working on improvements to the existing version. Following are some steps that would be taken in the next version [9] Improvement of Assessment and Audit, Extension of scope e.g. Commercial vehicles, Specific requirements and recommendations for functional safety for motorcycles, detailed requirement for Security and Semiconductor devices, Software safety analysis. With safety criticality in automotive systems increasing, newer technologies like car to car communication and internet of things we would need such standards and corresponding improvements to achieve Functional safety in Automotive domain. References [1] The 61508 association http://www.61508.org. [2] An introduction to functional safety and the iec 61508 series. [3] Iso26262: Automotive functional safety, iso http://www.iso.org. [4] National instruments:what is the iso 26262 functional safety standard. [5] Ireri Ibarra David D Ward. Development phase in accordance with iso 26262. [6] C Ebert. Introducing automotive e/e safety engineering: challenges and solution. [7] Barbara J. Gm : Iso 26262 functional safety draft international standard for road vehicles. [8] Robert N. Ieee spectrum: This car runs on code. [9] Hakan Sivencrona. Iso 26262 iso-initiatives, challenges and future need. 10