Author| Guo Jian Distinguished Expert of Shanghai Kongan Trusted Software Innovation Research Institute
Section| Jianyuan Forum · View model
Abstract: Safety is one of the key elements in automobile research and development. The research and development and integration of functions such as assisted driving and vehicle dynamic control need to strengthen the research and development of safety systems. At the same time, it is necessary to provide evidence to meet all expected safety goals. As system complexity increases, software and electromechanical devices are used, the risks from system failures and random hardware failures also increase. The ISO 26262 standard enables a better understanding of safety-related functions and explains them as clearly as possible, while providing feasible requirements and processes for avoiding these risks.
We will introduce the international standard of ISO 26262:2018 in 2 tweets.
ISO 26262 is derived from the basic standard for functional safety of electronics, electrical and programmable devices IEC 61508. It is mainly positioned in the automotive industry for specific electrical devices, electronic equipment, programmable electronic devices and other components specially used in the automotive field. Improve the international standards for the functional safety of automotive electronics and electrical products.
ISO 26262 was formally formulated in November 2005. After about 6 years, it was officially promulgated in November 2011 and became an international standard. China also promulgated corresponding standards in 2017. In 2018, the new ISO 26262:2018 international standard was promulgated, adding specifications for semiconductors and motorcycles.
ISO 26262 provides a life cycle (management, development, production, operation, service, end-of-life) concept for automotive safety and provides the necessary support in these life cycle stages. The standard covers the overall development process in terms of functional safety (including requirements planning, design, implementation, integration, verification, validation and configuration).
ISO 26262:2018 international standard is divided into 12 parts, they are:
Part 1: Terminology
Part II: Functional Safety Management
Part III: Concept Phase
Part IV: Product Development: System Level
Part V: Product Development: Hardware Level
PART VI: PRODUCT DEVELOPMENT: THE SOFTWARE LAYER
Part VII: Production, Operations, Service and Decommissioning
Part VIII: Support Process
Part 9: Automotive Safety Integrity Level-Oriented and Safety-Oriented Analysis
Part 10: Guidelines for ISO 26262
Part 11: Guidelines for the application of ISO 26262 to semiconductors
Part 12: Adaptation of ISO 26262 to Motorcycles
The structure of the ISO 26262:2018 international standard is shown in Figure 1:
Figure 1 The overall architecture of ISO 26262
In this tweet, I will give a brief introduction to the first part to the fifth part of the ISO 26262:2018 international standard.
Part 1
the term
In Part1, explanations of 185 terms are given, 43 more than the 2011 version, and the explanations of related terms are more accurate, clear and easy to understand. Due to the development of technology, explanations of some new terms have been added. And it gave 107 explanations about abbreviations, 56 more than the 2011 edition, making the 2018 edition more complete.
Part 2
Functional Safety Management
Part2 gives a detailed introduction to the General Administration of Functional Safety Management, the review process and requirements of functional safety, to ensure that participation in the safety life cycle establishes and maintains a safety culture to support and encourage effective achievements, and promotes functional safety with other related disciplines develop and maintain appropriate organizational rules and processes for functional safety; develop and maintain processes to ensure that identified safety anomalies are adequately addressed; establish and maintain a competency management system to ensure that relevant personnel are commensurate with their responsibilities; establish and maintain Maintain a quality management system to support functional safety.
In functional safety management, it includes the safety management of dependent items and the safety management of production, operation, service and scrapping. Security management for dependent items ensures that organizations involved in the concept phase or development phase require the definition and assignment of roles and responsibilities for security activities at the system, hardware, or software level; perform an impact analysis on dependent items to identify them as new dependent items , whether to modify an existing dependency, or to modify an existing dependency of the environment. In the case where one or more modifications are required, analyze the impact of the modification on functional safety; conduct an impact analysis at the element level, if an element is reused, it is necessary to evaluate whether the reused element can comply with the safety requirements assigned to the element, and at the same time The operating environment in which elements are reused needs to be considered; for tailored security activities, justifications are provided and justifications provided are reviewed; security activities need to be planned; progress of security activities is coordinated and tracked to comply with the security plan; planning is required Distributed development; ensure that safety activities can be carried out correctly throughout the safety life cycle; can create an understandable safety case to provide arguments for the realization of functional safety; judge whether the design achieves functional safety (ie, functional safety evaluation), or judge the Implementing whether an element achieves functional safety or judging the functional safety of a work product; at the end of development, based on supporting evidence of the achieved functional safety, deciding whether the item or element can be released for production.
The goal of safety management for production, operation, service and end-of-life is the need to define the responsibilities of organizations and persons responsible for achieving and maintaining functional safety for production, operation, service and end-of-life.
Figure 2 illustrates management activities related to the security lifecycle.
Figure 2 Management activities related to the security life cycle
In Figure 2, the specific clauses of each part of ISO 26262:2018 are as follows: "mn", where "m" indicates the number of the part, and "n" indicates the number of the clause, for example, "3-6" indicates ISO 26262 -3: 2018 Article 6.
Part 3
concept stage
The definition of the relevant items, hazard analysis and risk assessment, as well as the concept of functional safety are given in the concept phase.
In the definition of the relevant item, define and describe the relevant item, the function of the relevant item, the dependence of the relevant item on the driver, and the interaction with other relevant items at the driver, environment and vehicle level; support an accurate understanding of the relevant item, In order to implement the activities of the subsequent phases can be carried out.
During hazard analysis and risk assessment, be able to identify and classify hazardous events caused by the fault behavior of related items; formulate safety objectives related to the prevention or mitigation of hazardous events and their corresponding ASIL levels to avoid unreasonable risks.
For hazard analysis and risk assessment, it can be described by a function (F), which has three parameters: the frequency of occurrence of hazardous events ( f ), the controllability (C), that is, the ability to avoid a specific hazard or damage through the timely response of relevant personnel Capabilities, and the potential severity(s) of resulting hazard or damage:
The frequency of occurrence f is again influenced by two factors, in terms of the frequency and duration of the likely occurrence of the hazardous event. In ISO 26262, it is simplified as the probability (exposure, E) that a hazardous event may occur. Another factor is the incidence of failures in the item, which is not considered in the hazard analysis and risk assessment process. Therefore, in hazard analysis and risk assessment, the classification of E, S, and C will form the minimum requirement set for ASIL (automotive safety integrity level, automotive safety integrity level) to determine the relevant items to control or reduce the probability of random hardware failures, and avoid system failures. The failure rate of an item cannot be considered deduced because unreasonable residual risks can be avoided by achieving the resulting safety requirements.
The hazard analysis and risk assessment subphase consists of three steps:
Step 1: Scenario Analysis and Hazard Identification: The goal of scenario analysis and hazard identification is to identify potential unintended behavior of related items that could lead to a hazardous event. Scenario analysis and hazard identification activities require a clear definition of the item of interest, its function and its boundaries. It is based on the behavior of the dependent item; therefore, the detailed design of the dependent item does not necessarily need to be known.
Step 2: Classification of hazardous events: The hazard classification scheme includes determining the severity, exposure probability, and controllability of hazardous events of related items. Severity represents an estimate of the potential hazard in a particular driving situation, the probability of exposure is determined by the corresponding situation, and controllability measures the difficulty of a driver or other road traffic participant in avoiding the considered accident in the considered operating scenario. ease. For each hazard, classification will result in one or more combinations of severity, probability of exposure, and controllability, depending on the number of associated hazard events.
Step 3: ASIL determination: Determine the required automotive safety integrity level.
The concept of functional safety stipulates the behavior of the function or degraded function of the relevant item according to its safety goal; according to its safety goal, it specifies the constraints on the detection and control of relevant faults; it specifies the strategy or measures at the level of the relevant item to obtain the required fault tolerance , or fully mitigate the impact of related failures through related items themselves, drivers or external measures; assign functional safety requirements to system architecture design or external judgments; verify functional safety concepts and specify safety verification standards.
Part 4
Product Development: System Level
The system development process includes necessary activities such as technical security concept, product development at the hardware level, product development at the software level, integration and testing of the system and related items, and safety confirmation, as shown in Figure 3. During the iterative process, a technical security concept is developed and the technical security requirements are integrated with the system architecture design. Establishes the system architecture, assigns technical security requirements to elements of the system, and, if applicable, other technologies to the system. In addition, the technical security requirements are refined, and the requirements generated by the system architecture are added, including the hardware and software interface (HSI). Depending on the complexity of the architecture, the requirements of the subsystems can be derived iteratively.
After development is complete, hardware and software elements are integrated and tested to form a project, which is then integrated into the vehicle. Once integrated at the vehicle level, safety validation is performed to provide evidence of functional safety in relation to safety goals.
Figure 3 Reference phase model for the development of safety related items
In the technical security concept sub-stage, it is necessary to specify the technical security requirements for the functions, dependencies, constraints and attributes of the system elements and the interfaces required to realize them; to specify the technical security requirements for the security mechanisms implemented in the system elements and interfaces; Functional safety requirements of the system and its elements during operation, service and decommissioning; verification that the technical safety requirements are suitable for achieving functional safety at the system level and consistent with the functional safety requirements. Develop system architecture designs and technical safety concepts that meet safety requirements and do not conflict with non-safety-related requirements; analyze system architecture designs to prevent failures and derive safety-related specific properties required for production and service; to validate systems Whether the architectural design and technical safety concept meet the safety requirements of their respective ASIL levels.
In the integration and testing phase of the system and related items, it is necessary to define the integration steps and integrate the system elements until the system is fully integrated; verify whether the security measures defined by the security analysis at the system architecture level can be properly implemented; design according to the system architecture , providing evidence that the integrated system elements meet their safety requirements.
In the safety confirmation stage, it is necessary to provide evidence to prove that the related item is integrated into the corresponding vehicle to achieve the safety goal; and provide evidence to prove that the functional safety concept and technical safety concept are suitable for realizing the functional safety of the related item.
ISO 26262-4 applies to the development of systems, and ISO 26262-5 and ISO 26262-6 describe the development requirements for hardware and software, respectively. Figure 4 is an example of a system with multi-level integration illustrating the application of the ISO 26262-4, ISO 26262-5 and ISO 26262-6 standards.
Figure 4 An example of system-level product development
Part 5
Product Development: Hardware Level
Hardware-level product development process steps, including obtaining the general issues of product development at the hardware development level according to the technical security concept of ISO 2626-4, and then obtaining the hardware security requirements specification, followed by hardware design, evaluation of hardware architecture metrics, random hardware Faults lead to violations of safety goals for evaluation, and finally hardware integration and verification. The development process is shown in Figure 5.
Figure 5 Reference phase model of hardware layer product development
The activities and processes required for product development at the hardware level include: hardware implementation of technical safety concepts; analysis of potential hardware failures and their effects; and coordination with software development.
Hardware security requirements are specified in the hardware security requirements specification sub-stage. They are derived from technical security concepts and system architecture design specifications; improve the hardware and software interface (HSI) specification proposed in ISO 26262-4:2018, 6.4.7; and verify whether the hardware security requirements and the hardware and software interface (HSI) specification meet the technical requirements Security concepts and system architecture design specifications.
In the hardware design phase, create a hardware design that supports safety-oriented analysis; safety-oriented analysis results; meet hardware safety requirements; hardware-software interface (HSI) specifications; meet system architecture design specifications; and meet required Hardware design attributes.
This phase specifies and provides information on the functional safety requirements of the hardware during production, operation, service and end-of-life.
During and after hardware development, it is necessary to verify that the hardware design can meet the hardware safety requirements and hardware-software interface (HSI) specifications; the validity of each SEooC assumption used for development integration in the developed hardware; safety-related special attributes in production and Suitability of functional safety implemented during service.
In the evaluation subphase of hardware architecture metrics, based on hardware architecture metrics. Provide evidence of the applicability of the hardware architectural design of relevant items for detection and control of safety-related random hardware failures.
In the assessment sub-phase where random hardware failures lead to violations of safety goals, evidence can be provided that the residual risk of safety goal violations due to random hardware failures of the item is sufficiently low.
In the sub-phase of hardware integration and verification, ensure that the developed hardware meets the hardware safety requirements.
This article gives a brief introduction to the content of the first part to the fifth part of the ISO 26262:2018 international standard, and we will introduce the second half of it in the next tweet.