Standard No.:	GB/T 34590.10-2017
English Name:	Road vehicles―Functional safety―Part 10:Guideline
Chinese Name:	道路车辆 功能安全 第10部分：指南
Chinese Classification:	T35    Electronic/electrical equipment and instruments for vehicle in general
Professional Classification:	GB    National Standard
Issued by:	AQSIQ; SAC
Issued on:	2017-10-14
Implemented on:	2018-5-1
Status:	superseded
Superseded by:	GB/T 34590.10-2022 Road vehicles—Functional safety—Part 10: Guideline
Superseded on:	2023-7-1
Language:	English
File Format:	PDF
Word Count:	37000 words
Price(USD):	490.0
Delivery:	via email in 1 business day

Codeofchina.com is in charge of this English translation. In case of any doubt about the contents of English translation, the Chinese original shall be considered authoritative. GB/T 34590 consists of the following parts, under the general title Road Vehicles — Functional Safety: — Part 1: Vocabulary; — Part 2: Management of Functional Safety; — Part 3: Concept Phase; — Part 4: Product Development at the System Level; — Part 5: Product Development at the Hardware Level; — Part 6: Product Development at the Software Level; — Part 7: Production and Operation; — Part 8: Supporting processes; — Part 9: Automotive Safety Integrity Level (ASIL)-oriented and Safety-oriented Analyses; — Part 10: Guideline. This part is Part 10 of GB/T 34590. This part is developed in accordance with the rules given in GB/T 1.1-2009. This part has been redrafted and modified adoption of International Standard ISO 26262-10:2012 Road Vehicles — Functional Safety — Part 10: Guideline on ISO 26262. The technical deviations between this part and the International Standard ISO 26262-10:2012, together with their justifications, is given below: — The application scope of this part is modified from "ISO 26262 is intended to be applied to safety-related systems that include one or more electrical and/or electronic (E/E) systems and that are installed in series production passenger cars with a maximum gross vehicle mass up to 3 500 kg" to "This standard is applicable to safety-related systems that include one or more electrical and/or electronic (E/E) systems and that are installed in series production passenger cars"; — Adjustment on technical deviations has been made in "Normative References" of this part so that the technical conditions in China are met; the adjustment is concentratedly reflected in Chapter 2 "Normative References", see the followings for details:  GB/T 34590.1-2017, which is modified in relation to the international standard, replaces ISO 26262-1:2011;  GB/T 34590.2-2017, which is modified in relation to the international standard, replaces ISO 26262-2:2011;  GB/T 34590.3-2017, which is modified in relation to the international standard, replaces ISO 26262-3:2011;  GB/T 34590.4-2017, which is modified in relation to the international standard, replaces ISO 26262-4:2011;  GB/T 34590.5-2017, which is modified in relation to the international standard, replaces ISO 26262-5:2011;  GB/T 34590.6-2017, which is modified in relation to the international standard, replaces ISO 26262-6:2011;  GB/T 34590.8-2017, which is modified in relation to the international standard, replaces ISO 26262-8:2011;  GB/T 34590.9-2017, which is modified in relation to the international standard, replaces ISO 26262-9:2011; For the purposes of this part, the following editorial changes have also been made: — The introduction and the expression of the introduction in the international standard, as well as the content of Figure 1 are modified. This standard was proposed and prepared by SAC/TC 114 (National Technical Committee 114 on Automobiles of Standardization Administration of China).   Introduction ISO 26262 is the adaptation of IEC 61508 to comply with needs specific to the application sector of electrical and/or electronic (E/E) systems within road vehicles. GB/T 34590, has been modified adoption of ISO 26262-10:2012, applies to all activities during the safety lifecycle of safety-related systems comprised of electrical, electronic and software components. Safety is one of the key issues of future automobile development. New functionalities not only in areas such as driver assistance, propulsion, in vehicle dynamics control and active and passive safety systems increasingly touch the domain of system safety engineering. Development and integration of these functionalities will strengthen the need for safe system development processes and the need to provide evidence that all reasonable system safety objectives are satisfied. With the trend of increasing technological complexity, software content and mechatronic implementation, there are increasing risks from systematic failures and random hardware failures. GB/T 34590 includes guidance to avoid these risks by providing appropriate requirements and processes. System safety is achieved through a number of safety measures, which are implemented in a variety of technologies (e.g. mechanical, hydraulic, pneumatic, electrical, electronic, programmable electronic) and applied at the various levels of the development process. Although GB/T 34590 is concerned with functional safety of E/E systems, it provides a framework within which safety-related systems based on other technologies can be considered. GB/T 34590: a) provides an automotive safety lifecycle (management, development, production, operation, service, decommissioning) and supports tailoring the necessary activities during these lifecycle phases; b) provides an automotive-specific risk-based approach to determine integrity levels [Automotive Safety Integrity Levels (ASIL)]; c) uses ASILs to specify applicable requirements of GB/T 34590 so as to avoid unreasonable residual risk; d) provides requirements for validation and confirmation measures to ensure a sufficient and acceptable level of safety being achieved; e) provides requirements for relations with suppliers. Functional safety is influenced by the development process (including such activities as requirements specification, design, implementation, integration, verification, validation and configuration), the production and service processes and by the management processes. Safety issues are intertwined with common function-oriented and quality-oriented development activities and work products. GB/T 34590 addresses the safety-related aspects of development activities and work products. Figure 1 shows the overall structure of this edition of GB/T 34590. GB/T 34590 is based upon a V-model as a reference process model for the different phases of product development. Within the figure: — the shaded “V”s represent the interconnection between GB/T 34590.3-2017, GB/T 34590.4-2017, GB/T 34590.5-2017, GB/T 34590.6-2017 and GB/T 34590.7-2017; — the specific clauses are indicated in the following manner: “m-n”, where “m” represents the number of the particular part and “n” indicates the number of the clause within that part. Example: “2-6” represents Clause 6 of GB/T 34590.2-2017. Figure 1 Overview of GB/T 34590.2-2017017 Road Vehicles — Functional Safety — Part 10: Guideline 1 Scope This part of GB/T 34590 provides an overview of GB/T 34590, as well as giving additional explanations, and is intended to enhance the understanding of the other parts. It has an informative character only and describes the general concepts of GB/T 34590 in order to facilitate comprehension. The explanation expands from general concepts to specific contents. This standard is applicable to safety-related systems that include one or more electrical and/or electronic (E/E) systems and that are installed in series production passenger cars It is not applicable to unique E/E systems in special purpose vehicles such as vehicles designed for drivers with disabilities. Systems and their components released for production, or systems and their components already under development prior to the publication date of this standard, are exempted from the scope. For further development or alterations based on systems and their components released for production prior to the publication of this standard, only the modifications will be developed in accordance with this standard. This 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 of energy and similar hazards, unless directly caused by malfunctioning behaviour of E/E safety-related systems. This standard does not address the nominal performance of E/E systems, even if dedicated functional performance standards exist for these systems (e.g. active and passive safety systems, brake systems, Adaptive Cruise Control). In the case of inconsistencies between this part and another part of this standard, the requirements, recommendations and information specified in the other part of this standard apply. 2 Normative References The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. GB/T 34590.1-2017 Road Vehicles — Functional Safety — Part 1: Vocabulary (ISO 26262-1:2011, MOD) GB/T34590.2-2017 Road Vehicles — Functional Safety — Part 2: Management of Functional Safety (ISO 26262-2:2011, MOD) GB/T34590.3-2017 Road Vehicles — Functional Safety — Part 3: Concept Phase (ISO 26262-3:2011, MOD) GB/T34590.4-2017 Road Vehicles — Functional Safety — Part 4: Product Development at the System Level (ISO 26262-4:2011, MOD) GB/T34590.5-2017 Road Vehicles — Functional Safety — Part 5: Product Development at the Hardware Level (ISO 26262-5:2011, MOD) GB/T 34590.6-2017 Road Vehicles — Functional Safety — Part 6: Product Development at the Software Level (ISO 26262-6:2011, MOD) GB/T 34590.8-2017 Road Vehicles — Functional Safety — Part 8: Supporting processes (ISO 26262-8:2011, MOD) GB/T 34590.9-2017 Road Vehicles — Functional Safety — Part 9: Automotive Safety Integrity Level (ASIL)-oriented and Safety-oriented Analyses (ISO 26262-9:2011, MOD) 3 Terms, Definitions and Abbreviated Terms For the purposes of this document, the terms, definitions and abbreviated terms given in GB/T 34590.1-2017 apply. 4 Key Concepts of GB/T 34590 4.1 Functional Safety for Automotive Systems (Relationship with GB/T 20438) GB/T 20438, Functional safety of electrical/electronic/programmable electronic safety-related systems, is designated by IEC as a generic standard and a basic safety publication. This means that industry sectors will base their own standards for functional safety on the requirements of GB/T 20438. In the automotive industry, there are a number of issues with applying GB/T 20438 directly. Some of these issues and corresponding differences in GB/T 34590 are described below. GB/T 20438 is based upon the model of “equipment under control”, for example an industrial plant that has an associated control system as follows: a) A hazard analysis identifies the hazards associated with the equipment under control (including the equipment control system), to which risk reduction measures will be applied. This can be achieved through E/E/PE systems, or other technology safety-related systems (e.g. a safety valve), or external measures (e.g. a physical containment of the plant). GB/T 34590 contains a normative automotive scheme for hazard classification based on severity, probability of exposure and controllability. b) Risk reduction allocated to E/E/PE systems is achieved through safety functions, which are designated as such. These safety functions are either part of a separate protection system or can be incorporated into the plant control. It is not always possible to make this distinction in automotive systems. The safety of a vehicle depends on the behaviour of the control systems themselves. GB/T 34590 uses the concept of safety goals and a safety concept as follows: — a hazard analysis and risk assessment identifies hazards and hazardous events that need to be prevented, mitigated or controlled; — a safety goal is formulated for each hazardous event; — an Automotive Safety Integrity Level (ASIL) is associated with each safety goal; — the functional safety concept is a statement of the functionality to achieve the safety goal(s); — the technical safety concept is a statement of how this functionality is implemented on the system level by hardware and software; and — software safety requirements and hardware safety requirements state the specific safety requirements which will be implemented as part of the software and hardware design. Example: — The airbag system: one of the hazards is unintended deployment. — An associated safety goal is that the airbag does not deploy unless a crash occurs that requires the deployment. — The functional safety concept can specify a redundant function to detect whether the vehicle is in a collision. — The technical safety concept can specify the implementation of two independent accelerometers with different axial orientations and two independent firing circuits. The squib deploys if both are closed. GB/T 20438 is aimed at singular or low volume systems. The system is built and tested, then installed on the plant, and then safety validation is performed. For mass-market systems such as road vehicles, safety validation is performed before the release for volume (series) production. Therefore, the order of lifecycle activities in GB/T 34590 is different. Related to this, GB/T 34590.7-2017 addresses requirements for production. These are not covered in GB/T 20438. GB/T 20438 does not address specific requirements for managing development across multiple organizations and supply chains, whereas GB/T 34590 addresses explicitly the issue, including the Development Interface Agreement (DIA) [see GB/T 34590.8-2017, Clause 5 (Interfaces within distributed developments)], because automotive systems are produced by one or more suppliers of the customer, e.g. the vehicle manufacturer, the supplier of the customer, or the customer. GB/T 20438 does not contain normative requirements for hazard classification. GB/T 34590 contains an automotive scheme for hazard classification. This scheme recognizes that a hazard in an automotive system does not necessarily lead to an accident. The outcome will depend on whether the persons at risk are actually exposed to the hazard in the situation in which it occurs, and whether they are able to take steps to control the outcome of the hazard. An example of this concept applied to a failure which affects the controllability of a moving vehicle is given in Figure 2. Note: This concept is intended only to demonstrate that there is not necessarily a direct correlation between a failure occurring and the accident. It is not a representation of the hazard analysis and risk assessment process, although the parameters evaluated in this process are related to the probabilities of the state transitions shown in the figure. Figure 2 State Machine Model of Automotive Risk The requirements for hardware development (GB/T 34590.5-2017) and software development (GB/T 34590.6-2017) are adapted for the state-of-the-art in the automotive industry. Specifically, GB/T 34590.6-2017 contains requirements concerned with model-based development; GB/T 20438 prescribes the application of specific methods. A detailed rationale for the use of any alternative method has to be provided. For the methods listed in GB/T 34590, specific goals are provided. To achieve these goals, the provided methods can be applied, or a rationale that alternative methods can also achieve the goal is provided. Safety requirements in GB/T 34590 are assigned an ASIL (Automotive Safety Integrity Level) rather than a SIL (Safety Integrity Level). The main motivation for this is that the SIL in GB/T 20438 is stated in probabilistic terms (see GB/T 20438.1-2006, Table 3). GB/T 20438 states: "It is accepted that only with respect to the hardware safety integrity will it be possible to quantify and apply reliability prediction techniques in assessing whether the target failure measures have been met. Qualitative techniques and judgements have to be made with respect to the precautions necessary to meet the target failure measures with respect to the systematic safety integrity." An ASIL is not based on this probabilistic requirement concerning the occurrence of the hazard; however, there are probabilistic targets associated with compliance to the requirements of an ASIL. 4.2 Item, System, Element, Component, Hardware Part and Software Unit The terms item, system, element, component, hardware part, and software unit are defined in GB/T 34590.1-2017. Figure 3 shows the relationship of item, system, component, hardware part and software unit. Figure 4 shows an example of item dissolution. A divisible element can be labelled as a system, a subsystem or a component. A divisible element that meets the criteria of a system can be labelled as a system or subsystem. The term subsystem is used when it is important to emphasize that the element is part of a larger system. A component is a non-system-level, logically and technically separable element. Often the term component is applied to an element that is only comprised of parts and units, but can also be applied to an element comprised of lower-level elements from a specific technology area, e.g. electrical/electronic technology (see Figure 4). Example: In the case of a microcontroller or ASIC, the following partitioning can be used: the whole microcontroller is a component, the processing unit (e.g. a CPU) is a part, the registers inside the processing unit (e.g. the CPU register bank) is a sub-part. In the case of microcontroller (MCU) analyses, a higher level of detail in the partitioning could be needed; to aid in this purpose, it is possible to partition a part into sub-parts which can be further divided into basic/elementary sub-parts. Note 1: Depending on the context, the term “element” can apply to the entities “system”, “component”, “hardware part” and “software unit” in this chart according to GB/T 34590.1-2017, Clause 2.3.2. Note 2: The system as it is defined in GB/T 34590.1-2017 is at least a sensor, controller and an actuator, e.g. at least 3 related elements. Note 3: * means N elements are possible. Figure 3 Relationship of Item, System, Component, Hardware Part and Software Unit Figure 4 Example Item Dissolution 4.3 Relationship between Faults, Errors and Failures The terms fault, error and failure are defined in GB/T 34590.1-2017. Figure 5 depicts the progression of faults to errors to failures from three different types of causes: systematic software issues, random hardware issues and systematic hardware issues. Systematic faults (see GB/T 34590.1-2017) are due to design or specifications issues; software faults and a subset of hardware faults are systematic. Random hardware faults (see GB/T 34590.1-2017) are due to physical processes such as wear-out, physical degradation or environmental stress. At the component level, each different type of fault can lead to different failures. However, failures at the component level are faults at the item level. Note that in this example, at the vehicle level, faults from different causes can lead to the same failure. A subset of failures at the item level will be hazards (see GB/T 34590.1-2017) if additional environmental factors permit the failure to contribute to an accident scenario. Example: If unexpected behaviour of the vehicle occurs while the vehicle is starting to cross an intersection, a crash can occur, e.g. the risk of the hazardous event “vehicle bucking when starting to cross intersection” is assessed for severity, exposure and controllability ("bucking" refers to making sudden jerky movements). Figure 5 Example of Faults Leading to Failures 5 Selected Topics Regarding Safety Management 5.1 Work Product This subclause describes the term "work product". A work product is the result of meeting the corresponding requirements of GB/T 34590 (see GB/T 34590.1-2017). Therefore, a documented work product can provide evidence of compliance with these safety requirements. Example: A requirements specification is a work product that can be documented by means of a requirements database or a text file. An executable model is a work product that can be represented by modelling language files that can be executed, e.g. for simulation purposes by using a software tool. The documentation of a work product [see GB/T 34590.8-2017, Clause 10 (Documentation)] serves as a record of the executed safety activities, safety requirements or of related information. Such documentation is not restricted to any form or medium. Example: The documentation of a work product can be represented by electronic or paper files, by a single document or a set of documents. It can be combined with the documentation of other work products or with documentation not directly dedicated to functional safety. To avoid the duplication of information, cross-references within or between documentation can be used. 5.2 Confirmation Measures 5.2.1 General In GB/T 34590, specified work products are evaluated during subsequent activities, either as part of the confirmation measures or as part of the verification activities. This subclause describes the difference between verification and confirmation measures. On the one hand, the verification activities are performed to determine the completeness and correct specification, or implementation, of safety requirements. The verification of work products can include: — verification reviews to verify the specification, or implementation, of derived safety requirements against the safety requirements at a higher level, regarding completeness and correctness; or — the execution of test cases or the examination of test results to provide evidence of the fulfilment of specified safety requirements, by exercising the item or its element(s). The verification activities are specified in GB/T 34590.3-2017, GB/T 34590.4-2017, GB/T 34590.5-2017 and GB/T 34590.6-2017. Furthermore, generic requirements regarding the verification activities in GB/T 34590 are specified in GB/T 34590.8-2017, Clause 9 (Verification), and further details specific to the verification of safety requirements are specified in GB/T 34590.8-2017, Clause 6 (Specification and management of safety requirements). On the other hand, the confirmation measures are performed to evaluate the item's achievement of functional safety, including a confirmation of: — the proper definition, tailoring and execution of the safety activities performed during the item development and of the implemented safety processes, with regard to the GB/T 34590 requirements; and — the proper content of the work products with regard to the corresponding GB/T 34590 requirements. The confirmation measures are specified in GB/T 34590.2-2017, Clause 6 (Safety management during the concept phase and the product development). Example: If an ASIL decomposition is applied during the system design phase: — the verification of the resulting system design is performed against the technical safety concept (see GB/T 34590.4-2017, 7.4.8); and — the confirmation of the correct application of the ASIL decomposition can be performed as part of a functional safety assessment, with regard to GB/T 34590.9-2017, Clause 5 (Requirements decomposition with respect to ASIL tailoring), including the confirmation that a dependent failure analysis has been performed and justifies the claim of sufficient independence between the elements that implement the corresponding redundant safety requirements. 5.2.2 Functional safety assessment If the highest ASIL of the item's safety goals is ASIL C or D, a functional safety assessment is performed to evaluate an item's achievement of functional safety. In GB/T 34590.2-2017, certain aspects of a functional safety assessment are described separately, i.e. the functional safety audit and the confirmation reviews. A functional safety assessment includes: a) a review of the appropriateness and effectiveness of the implemented safety measures that can be assessed during the item development; b) an evaluation of the work products that are required by the safety plan. The review of selected work products is emphasised. These are coined as confirmation reviews and aim to confirm the compliance of such work products with the corresponding requirements of GB/T 34590; and c) one or more functional safety audits to evaluate the implementation of the processes required for functional safety. A functional safety assessment can be repeated or updated. Example 1: A functional safety assessment update because of a change of the item, or element(s) of the item, that is identified by the change management as having an impact on the functional safety of the item [see GB/T 34590.8-2017, Clause 8 (Change management)]. Example 2: An iteration of a functional safety assessment triggered by the follow-up of a functional safety assessment report that included a recommendation for a conditional acceptance or rejection of the item's functional safety. In this case, the iteration includes a follow-up of the recommendations resulting from the previous functional safety assessment(s), including an evaluation of the performed corrective actions, if applicable. If the highest ASIL of the item's safety goals is ASIL B, a functional safety assessment can be omitted or performed less rigorously. However, even if the functional safety assessment is not performed, other confirmation measures are still performed, i.e. the confirmation reviews of the hazard analysis and risk assessment, the safety plan, the item integration and testing plan, the validation plan, the applicable safety analyses, the proven in use arguments (if applicable), and the completeness of the safety case (see GB/T 34590.2-2017, Table 1). If the highest ASIL of the item's safety goals is ASIL A, there is no requirement or recommendation in GB/T 34590 for or against performing a functional safety assessment. However, confirmation reviews of the hazard analysis and risk assessment and of the applicable safety analyses are still performed. In the case of a distributed development, the scope of a functional assessment includes the work products generated, and the processes and safety measures implemented, by a vehicle manufacturer and the suppliers in the item's supply chain [see GB/T 34590.2-2017 and GB/T 34590.8-2017, Clause 5 (Interfaces within distributed developments)]. The purpose of a functional safety assessment is to evaluate an item's achievement of functional safety, which is only possible at the item level. Therefore, a functional safety assessment at the premises of a supplier (that develops elements of the item) refers only to an assessment with a limited scope, which essentially serves as an input for the subsequent functional safety assessment activities (at the customer level). As the final customer in the item development, the vehicle manufacturer appoints person(s) to perform a functional safety assessment in its full scope, so as to judge an item's achievement of functional safety. This judgement includes providing a recommendation for acceptance, conditional acceptance, or rejection of the item's functional safety. Note 1: For the case where a Tier 1 supplier is responsible for the item development including vehicle integration, this supplier takes over the aforementioned role of the vehicle manufacturer. In a practical manner, a functional safety assessment in the case of a distributed development can thus be broken down into: — functional safety assessments with a limited scope at the supplier's premises, concerning the suppliers in the supply chain. The applicable ASIL is the highest inherited ASIL (of the item's safety goals) across the elements, of the item, that are developed by the supplier (see also GB/T 34590.8-2017, 5.4.5); and — a final functional safety assessment that includes a judgement of the functional safety achieved by the integrated item, e.g. performed by the vehicle manufacturer. The applicable ASIL is the highest ASIL of the item's safety goals (see also GB/T 34590.2-2017). Example: A vehicle manufacturer develops an item with an ASIL D Safety Goal (SG1) and an ASIL A Safety Goal (SG2), and will perform a functional safety assessment regarding this item. It is possible that, for example, a Tier 2 or Tier 3 supplier only develops ASIL A elements of the item, i.e. only elements that inherit the ASIL of SG2 [however, refer to GB/T 34590.9-2017, Clause 6 (Criteria for coexistence of elements), if applicable]. There is no requirement or recommendation (for or against) in GB/T 34590 to perform a functional safety assessment at this supplier's premises regarding this item development. The scope, procedure (e.g. work products to be made available by the supplier, work products to be reviewed by the customer) and execution of a functional safety assessment concerning the interface between a customer and a supplier are specified in the corresponding Development Interface Agreement [see GB/T 34590.8-2017, Clause 5 (Interfaces within distributed developments)]. Example: DIA between a vehicle manufacturer (customer) and a Tier 1 supplier. DIA between a Tier 1 supplier (customer) and a Tier 2 supplier. A possible manner to perform a functional safety assessment in the case of a distributed development is that the vehicle manufacturer and the suppliers in the supply chain each address those aspects of the assessment activities [see bullets a), b) and c) above] for which the respective party is responsible for, as follows: — a supplier reviews the safety measures implemented in the developed elements including their appropriateness and effectiveness to comply with the corresponding safety goals or safety requirements (provided by the customer or developed by the supplier), and evaluates its implemented processes and the applicable work products. A supplier also evaluates the potential impacts of the developed elements on the item's functional safety, e.g. identifies whether implemented safety measures can lead to new hazards; and — the vehicle manufacturer evaluates the functional safety of the integrated item. A part of the evaluation can be based on the work products or information provided by one or more suppliers, including reports of the functional safety assessments performed at supplier's premises. Note 2: A customer can evaluate the safety measures implemented by a supplier and the work products made available by a supplier. A customer can also evaluate the processes implemented by a supplier at the supplier's premises (see GB/T 34590.8-2017, 5.4.4.8)   5.3 Understanding of Safety Cases 5.3.1 Interpretation of safety cases The purpose of a safety case is to provide a clear, comprehensive and defensible argument, supported by evidence, that an item is free from unreasonable risk when operated in an intended context. The guidance given here focuses on the scope of GB/T 34590. There are three principal elements of a safety case, namely: — the requirements; — the argument; and — the evidence, i.e. GB/T 34590 work products. The relationship between these three elements, in the context of GB/T 34590, is depicted in Figure 6. Figure 6 Key Elements of a Safety Case (See [2]) The safety argument communicates the relationship between the evidence and the objectives. The role of the safety argument is often neglected. It is possible to present many pages of supporting evidence without clearly explaining how this evidence relates to the safety objectives. Both the argument and the evidence are crucial elements of the safety case and go hand-in-hand. An argument without supporting evidence is unfounded, and therefore unconvincing. Evidence without an argument is unexplained, resulting in a lack of clarity as to how the safety objectives have been satisfied. Safety cases are communicated through the development and presentation of safety case reports. The role of a safety case report is to summarize the safety argument and then reference the reports capturing the supporting safety evidence (e.g. test reports). Safety arguments used to date in other industries have often been communicated in safety case reports through narrative text. Narrative text can describe how a safety objective has been interpreted, allocated and decomposed, ultimately leading to references to evidence that demonstrate fulfilment of lower-level safety claims. Alternatively, it is becoming increasingly popular to use graphical argument notations (such as Claims–Argument–Evidence and the Goal Structuring Notation [2]) to visually and explicitly represent the individual elements of a safety argument (requirements, claims, evidence and context) and the relationships that exist between these elements (i.e. how individual requirements are supported by specific claims, how claims are supported by evidence and the assumed context that is defined for the argument). A safety argument that argues safety through direct appeal to features of the implemented item (e.g. the behaviour of a timing watchdog) is often termed a product argument. A safety argument that argues safety through appeal to features of the development and assessment process (e.g. the design notation adopted) is often termed a process argument. Both types of argument can be used to achieve a sound argument for the safety of the item where a process argument can be seen as providing the confidence in the evidences used in the product argument. 5.3.2 Safety case development lifecycle The development of a safety case can be treated as an incremental activity that is integrated with the rest of the development phases of the safety lifecycle. Note: The safety plan can include the planning for incremental steps and the preliminary versions of the safety case. Such an approach allows intermediate versions of the safety case at given milestones of the product development. For example, a preliminary version of the safety case can be created after the verification of the technical safety requirements; an interim version of the safety case can be created after the verification of the system design; and the final version can be created just prior to the functional safety assessment. The safety case is subject to a confirmation review as given in GB/T 34590.2-2017, 6.4.7 (Confirmation measures: types, independency and authority). If the item is modified, the impact on the safety case is evaluated and, if necessary, the safety case is updated considering modifications.   6 Concept Phase and System Development 6.1 General This section provides an overview of the principles behind the hazard analysis and risk classification using simplified examples to the concepts. 6.2 Example of Hazard Analysis and Risk Assessment 6.2.1 General Consider the example of an item controlling an energy storage device embedded in the vehicle. For the purpose of this example, the stored energy is intended to be released only if the vehicle is running greater than or equal to 15 km/h. The release of the stored energy at less than 15 km/h can lead to the overheating and consequent explosion of the device. 6.2.2 Analysis 1 a) Hazard identification — failure leading to an unwanted release of energy of the device that can result in an explosion b) Hazardous event For the purpose of this example, the driving situation considered for the hazard analysis and risk assessment is: — driving less than 15 km/h in a traffic congestion An unwanted release of energy due to a failure in the item occurs. The energy storage device explodes, causing severe harm to the occupants of the vehicle. c) Classification of the identified hazardous event The explosion leads to life-threatening injuries for the passengers of the vehicle, with survival uncertain, so the severity is estimated as S3. The vehicle is travelling in traffic congestion, below the speed of 15 km/h. Based on traffic statistic for the target market of the vehicle, the exposure of this situation could be estimated as E3 (occurring between 1% and 10% of the driving time). The ability of the driver or the passengers of the vehicles to control the item failure and the explosion of the device is considered as implausible: this controllability could be estimated as C3 (difficult to control or uncontrollable). The application of GB/T 34590.3-2017, Table 4: ASIL determination leads to an ASIL C. 6.2.3 Analysis 2 a) Hazard identification — failure does not lead to the release of energy b) Hazardous event — any driving situation A failure in the item occurs but does not lead to the release of any energy from the storage device, so it leads to no harm. c) Classification of the identified hazardous event Since the item failure does not lead to harm, the severity is classified as S0 and controllability does not need to be determined. Therefore a safety goal does not need to be defined. 6.3 An Observation Regarding Controllability Classification As explained in GB/T 34590.3-2017, Clause 7 (Hazard analysis and risk assessment), the controllability represents an estimation of the probability that the driver or other traffic participant is able to avoid the specific harm. In the simplest case, only one outcome is considered for a given hazardous event, and the controllability represents an estimation of the probability that this outcome is avoided. However, there can be other cases. For example, a severe outcome (e.g. severity class S2) can be possible but relatively easy to avoid (e.g. controllability C1), while a less severe outcome (e.g. S1) is more difficult to avoid (e.g. C3). Assuming that the exposure class is E4, the following set of values can be the result, which illustrates that it is not necessarily the highest severity that leads to the highest ASIL: — E4, S2, C1 => ASIL A — E4, S1, C3 => ASIL B In this example, ASIL B is an appropriate classification of the hazardous event. 6.4 External Measures 6.4.1 General An external measure is a measure separate and distinct from the item that reduces or mitigates the risks resulting from a failure of the item. 6.4.2 Example of vehicle-dependent external measures 1 Vehicle A is equipped with a manually operated transmission gear box which can be left in any gear, including neutral, upon key off. Vehicle B is equipped with an automated gear box which, at key off, maintains one gear engaged and a normally closed clutch. Both vehicles have the added item, Electrical Parking Brake (EPB). A scenario is analyzed for both vehicles which includes: — The vehicle is parked (key off, driver not present). — Parked surface is kerbside and sloped, located in a populated urban area. — A failure involving a sudden loss of EPB occurs. In this scenario, Vehicle A, when left in neutral at key off (a situation that corresponds to a reasonably foreseeable misuse), will potentially move if left unattended. This can result in an assessed controllability rating of C3, a severity rating of S2 or higher depending on the presence of nearby vulnerable persons, and an exposure ranking greater than E0. Depending on the exposure rating actually assigned, the ratings proposed result in an assigned ASIL classification between QM and C. Vehicle B however always engages a gear so does not move, thus there is no resulting hazard. The vehicle-dependent external measures included in this design contribute to the elimination of risk for this scenario, but only if the robotized gear box and the EPB can be shown to be sufficiently independent. 6.4.3 Example of vehicle-dependent external measures 2 Vehicle A is equipped with dynamic stability control in addition to a Stop & Start feature. Vehicle B is only equipped with the Stop & Start feature. A scenario is analyzed for both vehicles which includes: — The vehicle is being driven at medium-high speed [50 km/h

Foreword II Introduction IV 1 Scope 2 Normative References 3 Terms, Definitions and Abbreviated Terms 4 Key Concepts of GB/T 3 4.1 Functional Safety for Automotive Systems (Relationship with GB/T 20438) 4.2 Item, System, Element, Component, Hardware Part and Software Unit 4.3 Relationship between Faults, Errors and Failures 5 Selected Topics Regarding Safety Management 5.1 Work Product 5.2 Confirmation Measures 5.3 Understanding of Safety Cases 6 Concept Phase and System Development 6.1 General 6.2 Example of Hazard Analysis and Risk Assessment 6.3 An Observation Regarding Controllability Classification 6.4 External Measures 6.5 Example of Combining Safety Goals 7 Safety Process Requirement Structure — Flow and Sequence of Safety Requirements 8 Concerning Hardware Development 8.1 The Classification of Random Hardware Faults 8.2 Example of Residual Failure Rate and Local Single-point Fault Metric Evaluation 8.3 Further Explanation Concerning Hardware 9 Safety Element out of Context 9.1 Safety Element out of Context Development 9.2 Use Cases 10 An Example of Proven in Use Argument 10.1 General 10.2 Item Definition and Definition of the Proven in Use Candidate 10.3 Change Analysis 10.4 Target Values for Proven in Use 11 Concerning ASIL Decomposition 11.1 Objective of ASIL Decomposition 11.2 Description of ASIL Decomposition 11.3 An example of ASIL Decomposition Annex A (Informative) GB/T 34590 and Microcontrollers Annex B (Informative) Fault Tree Construction and Applications Bibliography