标准编号:	GB/T 34590.9-2017
中文名称:	道路车辆 功能安全 第9部分：以汽车安全完整性等级为导向和以安全为导向的分析
英文名称:	Road vehicles-Functional safety-Part 9: Automotive Safety Integrity Level (ASI L) -oriented and safety-oriented analyses
中标分类:	T35    车用电子、电气设备与仪表综合
行业分类:	GB    国家标准
ICS分类:	43.040 43.040    道路车辆装置 43.040
发布机构:	中华人民共和国国家质量监督检验检疫总局 中国国家标准化管理委员会
发布日期:	2017-10-14
实施日期:	2018-5-1
标准状态:	被替代
被新标准替代:	GB/T 34590.9-2022 道路车辆 功能安全 第9部分：以汽车安全完整性等级为导向和以安全为导向的分析
被替代日期:	2023-7-1
翻译语言:	英文
文件格式:	PDF
中文字符数:	17000 字
翻译价格(元):	330.00 元
交付时间:	付款后 1 个工作日

Codeofchina.com is in charge of this English translation. In case of any doubt about the 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 9 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 in relation to ISO 26262-9:2011 Road Vehicles - Functional Safety - Part 9: Automotive Safety Integrity Level (ASIL)-oriented and Safety-oriented Analyses.



There are technical deviations between this part and ISO 26262-9:2011. The technical deviations, together with their justifications, are as follows:



——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 500kg" to "This standard 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.";



——in order to adapt to the technical conditions in China, adjustment on technical deviations has been made in "Normative References" of this part, which is mainly reflected in Chapter 2 "Normative References" and detailed as follows:



 ISO 26262-1:2011 is replaced with GB/T 34590.1-2017 which is modified in relation to international standard;



 ISO 26262-2:2011 is replaced with GB/T 34590.2-2017 which is modified in relation to international standard;



 ISO 26262-3:2011 is replaced with GB/T 34590.3-2017 which is modified in relation to international standard;



 ISO 26262-4:2011 is replaced with GB/T 34590.4-2017 which is modified in relation to international standard;



 ISO 26262-5:2011 is replaced with GB/T 34590.5-2017 which is modified in relation to international standard;



 ISO 26262-6:2011 is replaced with GB/T 34590.6-2017 which is modified in relation to international standard;



 ISO 26262-8:2011 is replaced with GB/T 34590.8-2017 which is modified in relation to international standard;



The following editorial changes present in this part:



——the introduction and its expression as well as Figure 1 of international standard are modified.



This part was proposed by and is under the jurisdiction of National Technical Committee on Automobiles of Standardization Administration of China (SAC/TC 114).





Introduction



ISO 26262 is prepared based on 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 is the adaptation of ISO 26262 and 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 chapter within that part.



Example: "2-6" represents Chapter 6 of GB/T 34590.2-2017.



Figure 1 Overview of GB/T 34590-2017



Road Vehicles - Functional Safety -

Part 9: Automotive Safety Integrity Level (ASIL)-oriented and Safety-oriented Analyses



1 Scope



This part of GB/T 34590 specifies the requirements for automotive safety integrity level (ASIL)-oriented and safety-oriented analyses, including the following:



——requirements decomposition with respect to ASIL tailoring;



——criteria for coexistence of elements;



——analysis of dependent failures, and



——safety analyses.



This standard 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.



This standard does not address 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 behavior 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 behavior 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).



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/T 34590.2-2017 Road Vehicles - Functional Safety - Part 2: Management of Functional Safety (ISO 26262-2:2011, MOD)

GB/T 34590.3-2017 Road Vehicles - Functional Safety - Part 3: Concept Phase (ISO 26262-3:2011, MOD)

GB/T 34590.4-2017 Road Vehicles - Functional Safety - Part 4: Product Development at the System Level (ISO 26262-4:2011, MOD)

GB/T 34590.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)



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 Requirements



4.1 General Requirements



When claiming compliance with GB/T 34590-2017, each requirement shall be complied with, unless one of the following applies:



a) tailoring of the safety activities in accordance with GB/T 34590.2-2017 has been planned and shows that the requirement does not apply;



b) a rationale is available that the non-compliance is acceptable and the rationale has been assessed in accordance with GB/T 34590.2-2017.



Information marked as a “Note” or “Example” is only for guidance in understanding, or for clarification of the associated requirement, and shall not be interpreted as a requirement itself or as complete or exhaustive.



The results of safety activities are given as work products. “Prerequisites” are information which shall be available as work products of a previous phase. Given that certain requirements of a clause are ASIL-dependent or may be tailored, certain work products may not be needed as prerequisites.



"Further supporting information" is information that can be considered, but which in some cases is not required by GB/T 34590-2017 as a work product of a previous phase and which may be made available by external sources that are different from the persons or organizations responsible for the functional safety activities.



4.2 Interpretations of Tables



Tables are normative or informative depending on their context. The different methods listed in a table contribute to the level of confidence in achieving compliance with the corresponding requirement. Each method in a table is either



a) a consecutive entry (marked by a sequence number in the leftmost column, e.g. 1, 2, 3), or



b) an alternative entry (marked by a number followed by a letter in the leftmost column, e.g. 2a, 2b, 2c).



For consecutive entries, all methods shall be applied as recommended in accordance with the ASIL. If methods other than those listed are to be applied, a rationale shall be given that these fulfil the corresponding requirement.



For alternative entries, an appropriate combination of methods shall be applied in accordance with the ASIL indicated, independent of whether they are listed in the table or not. If methods are listed with different degrees of recommendation for an ASIL, the methods with the higher recommendation should be preferred. A rationale shall be given that the selected combination of methods complies with the corresponding requirement.



A rationale based on the methods listed in the table is sufficient. However, this does not imply a bias for or against methods not listed in the table.



For each method, the degree of recommendation to use the corresponding method depends on the ASIL and is categorized as follows:



——"++" indicates that the method is highly recommended for the identified ASIL;



——"+" indicates that the method is recommended for the identified ASIL;



——"o" indicates that the method has no recommendation for or against its usage for the identified ASIL.



4.3 ASIL-dependent Requirements and Recommendations



The requirements or recommendations of each subclause shall be complied with for ASIL A, B, C and D, if not stated otherwise. These requirements and recommendations refer to the ASIL of the safety goal. If ASIL decomposition has been performed at an earlier stage of development, in accordance with GB/T 34590.9-2017, Chapter 5, the ASIL resulting from the decomposition shall be complied with.



If an ASIL is given in parentheses in GB/T 34590-2017, the corresponding subclause shall be considered as a recommendation rather than a requirement for this ASIL. This has no link with the parenthesis notation related to ASIL decomposition.



5 Requirements Decomposition with Respect to ASIL Tailoring



5.1 Objectives



This chapter provides rules and guidance for decomposing safety requirements into redundant safety requirements to allow ASIL tailoring at the next level of detail.



5.2 General



The ASIL of the safety goals of an item under development is propagated throughout the item's development process. Starting from safety goals, the safety requirements are derived and refined during the development phases. The ASIL, as an attribute of the safety goal, is inherited by each subsequent safety requirement. The functional and technical safety requirements are allocated to architectural elements, starting with preliminary architectural assumptions and ending with the hardware and software elements.



The method of ASIL tailoring during the design process is called "ASIL decomposition". During the allocation process, benefit can be obtained from architectural decisions including the existence of sufficiently independent architectural elements. This offers the opportunity:



——to implement safety requirements redundantly by these independent architectural elements, and



——to assign a potentially lower ASIL to these decomposed safety requirements.



If the architectural elements are not sufficiently independent, then the redundant requirements and the architectural elements inherit the initial ASIL.



Note 1: ASIL decomposition is an ASIL tailoring measure that can be applied to the functional, technical, hardware or software safety requirements of the item or element.





Note 2: as a basic rule, the application of ASIL decomposition requires redundancy of safety requirements allocated to architectural elements that are sufficiently independent.



Note 3: in the case of use of homogenous redundancy (e.g. by duplicated device or duplicated software) and with respect to systematic failures of hardware and software, the ASIL cannot be reduced unless an analysis of dependent failures provides evidence that sufficient independence exists or that the potential common causes lead to a safe state. Therefore, homogenous redundancy is in general not sufficient for reducing the ASIL due to the lack of independence between the elements.



Note 4: in general, ASIL decomposition does not apply to elements ensuring the channel selection or switching in multi-channel architectural designs.



In general, ASIL decomposition allows the apportioning of the ASIL of a safety requirement between several elements that ensure compliance with the same safety requirement addressing the same safety goal. ASIL decomposition between an intended functionality and its corresponding safety mechanism is allowed under certain conditions (see 5.4.7).



The requirements specific to the random hardware failures, including the evaluation of the hardware architectural metrics and the evaluation of safety goal violations due to random hardware failures (see GB/T 34590.5-2017) remain unchanged by ASIL decomposition.



Note: Table A.1 in Annex A provides an overview on objectives, prerequisites and work products of the automotive safety integrity level (ASIL)-oriented and safety-oriented analyses.



5.3 Inputs to this Chapter



5.3.1 Prerequisites



The following information shall be available:



——the safety requirements at the level at which the ASIL decomposition is to be applied: system, or hardware, or software in accordance with GB/T 34590.3-2017, 8.5.1, GB/T 34590.4-2017, 6.5.1 and GB/T 34590.5-2017, 6.5.1 or 34590.6-2017, 6.5.1; and



——the architectural information at the level at which the ASIL decomposition is to be applied: system, or hardware, or software in accordance with GB/T 34590.4-2017, 7.5.2, GB/T 34590.5-2017, 7.5.1 or GB/T 34590.6-2017, 7.5.1;



5.3.2 Further supporting information



The following information can be considered:



——item definition (see GB/T 34590.3-2017, 5.5); and



——safety goals (see GB/T 34590.3-2017, 7.5.2).



5.4 Requirements and Recommendations



5.4.1 If ASIL decomposition is applied, all the requirements within this chapter shall be complied with.



5.4.2 ASIL decomposition shall be performed by considering each initial safety requirement individually.



Note: several safety requirements can be allocated to the same independent elements as the result of ASIL decompositions of different initial safety requirements.



5.4.3 The initial safety requirement shall be decomposed to redundant safety requirements implemented by sufficiently independent elements.



5.4.4 Each decomposed safety requirement shall comply with the initial safety requirement by itself.



Note: this requirement provides redundancy by definition.



5.4.5 The requirements on the evaluation of the hardware architectural metrics and the evaluation of safety goal violations due to random hardware failures shall remain unchanged by ASIL decomposition in accordance with GB/T 34590.5-2017.



5.4.6 If ASIL decomposition is applied at the software level, sufficient independence between the elements implementing the decomposed requirements shall be checked at the system level and appropriate measures shall be taken at the software level, or hardware level, or system level to achieve sufficient independence.



5.4.7 If ASIL decomposition of an initial safety requirement results in the allocation of decomposed requirements to the intended functionality and an associated safety mechanism, then:



a) the associated safety mechanism should be assigned the highest decomposed ASIL;



Note: in general, the safety mechanisms have a lower complexity and lower size than the intended functionality.



b) a safety requirement shall be allocated to the intended functionality and implemented applying the corresponding decomposed ASIL.



Note: if the decomposition scheme ASIL x(x) + QM(x) is chosen, then QM(x) means that the quality management system can be sufficient to develop element(s) that implement the safety requirement allocated to the intended functionality. QM(x) also means that the quality management system can support the rationale for the independence between the intended functionality and the safety mechanism.



5.4.8 If the violation of an initial safety requirement cannot be prevented by switching off the element, then adequate availability of the sufficiently independent elements implementing the decomposed safety requirements shall be shown.

Foreword i
Introduction iii
1 Scope
2 Normative References
3 Terms, Definitions and Abbreviated Terms
4 Requirements
4.1 General Requirements
4.2 Interpretations of Tables
4.3 ASIL-dependent Requirements and Recommendations
5 Requirements Decomposition with Respect to ASIL Tailoring
5.1 Objectives
5.2 General
5.3 Inputs to this Chapter
5.4 Requirements and Recommendations
5.5 Work Products
6 Criteria for Coexistence of Elements
6.1 Objectives
6.2 General
6.3 Input to this Chapter
6.4 Requirements and Recommendations
6.5 Work Products
7 Analysis of Dependent Failures
7.1 Objectives
7.2 General
7.3 Inputs to this Chapter
7.4 Requirements and Recommendations
7.5 Work Products
8 Safety Analyses
8.1 Objectives
8.2 General
8.3 Inputs to this Chapter
8.4 Requirements and Recommendations
8.5 Work Products
Annex A (Informative) Overview on and Document Flow of Automotive Safety Integrity Level (ASIL)-oriented and Safety-oriented Analyses
Bibliography

道路车辆 功能安全 第9部分
以汽车安全完整性等级为导向和以安全为导向的分析
1 范围
GB/T 34590的本部分规定了以汽车安全完整性等级为导向和以安全为导向的分析的要求，包括：
——关于ASIL剪裁的要求分解；
——要素共存的准则；
——相关失效分析；及
——安全分析。
本标准适用于安装在量产乘用车上的包含一个或多个电子电气系统的与安全相关的系统。
本标准不适用于特殊用途车辆上特定的电子电气系统，例如，为残疾驾驶者设计的车辆。
本标准不适用于已经完成生产发布的系统及其组件或在本标准发布日期前开发的系统及其组件。对于在本标准发布前完成生产发布的系统及其组件进行进一步的开发或变更时，仅修改的部分需要按照本标准开发。
本标准针对由电子电气安全相关系统的故障行为而引起的可能的危害，包括这些系统相互作用而引起的可能的危害。本标准不针对与触电、火灾、烟雾、热、辐射、毒性、易燃性、反应性、腐蚀性、能量释放等相关的危害和类似的危害，除非危害是直接由电子电气安全相关系统的故障行为而引起的。
本标准不针对电子电气系统的标称性能，即使这些系统（例如主动和被动安全系统、制动系统、自适应巡航系统）有专用的功能性标准。
2 规范性引用文件
下列文件对于本文件的应用时必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。

GB/T 34590.1-2017 Road vehicles-Functional safety- Part 1:Vocabulary (ISO 26262-1:2011, MOD)
GB/T 34590.2-2017 Road vehicles-Functional safety- Part 2:Management of functional safety (ISO 26262-2:2011, MOD)
GB/T 34590.3-2017 Road vehicles-Functional safety-Part 3:Concept phase (ISO 26262-3:2011, MOD)
GB/T 34590.4-2017 Road vehicles-Functional safety- Part 4:Product development at the system level (ISO 26262-4:2011, MOD)
GB/T 34590.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)
3术语、定义和你缩略语
GB/T 34590.1——2017界定的术语、定义和你缩略语适用于本文件。
4要求
4.1 一般要求
如声明满足GB/T 34590——2017的要求时，应满足每一个要求，除非有下列情况之一：
a) 按照GB/T 34590.2——2017的要求，已经计划了安全活动的剪裁并表明这些要求不适用；或
b）不满足要求的理由存在且是可接受的，并且按照GB/T 34590.2——2017对该理由进行了评估。
标有“注”或“示例”的信息仅用于辅助理解或阐明相关要求，不应作为要求本身且不具备完整性。
将安全活动的结果作为工作成果。应具备一阶段工作成果作为“前提条件”的信息。如果章条的某些要求是按照ASIL定义的或可剪裁的，某些工作成果可不作为前提条件。
“支持信息”是可供参考的信息，但在某些情况下，GB/T 34590——2017不要求其作为上一阶段的工作成果，并且可以是由不同于负责功能安全活动的人员或组织等外部资源提供的信息。
4.2 表的诠释
表属于规范性表还是资料性表取决于上下文。在实现满足相关要求时，表中列出的不同方法有助于置信度水平。表中的每个方法是：
a） 一个连续的条目（在最左侧列以顺序号标明，如1、2、3）；
b） 一个连续的条目（在最左侧列以数字后加字母标明，如2a、2b、2c）。
对于连续的条目，全部方法应按照ASIL等级推荐予以使用。除了所列出的方法外，如果应用所列出方法以外的其他方法，应给出满足相关要求的理由。
对于选择性的条目，应按照指定的ASIL等级，对这些方法进行适当的组合，不依赖于这些方法是否在表中列出。如果所列出的方法对于一个ASIL等级来说具有不同的推荐等级，宜采用具有较高推荐等级的方法。应给出所选的方法组合满足相关要求的理由。
表中所列出的方法的理由是充分的。但是，这并不意味着有倾向性或对未列到表中的方法表示反对。
对于每种方法，应用相关方法的推荐等级取决于ASIL等级，分类如下：
——“++”表示对于指定的ASIL等级，高度推荐该方法；
——“+” 表示对于指定的ASIL等级，推荐该方法；
——“o” 表示对于指定的ASIL等级，不推荐也不反对该方法。
4.3 基于ASIL等级的要求和建议
若无其他说明，对于ASIL A、B、C、D等级，应满足每一子章条的要求或建议。这些要求和建议参照安全目标的ASIL等级。如果在项目开发的早期对ASIL等级完成了分解，按照GB/T 34590.9——2017第5章，应遵循分解后的ASIL等级。
如果GB/T 34590——2017中ASIL等级在括号中给出，则对于该ASIL等级，相应的子章条应被认为是推荐而非要求。这里的括号与ASIL等级分解无关。
5 关于ASIL剪裁的要求分解
5.1 目的
本章提供了将安全要求分解为冗余安全要求的规则和指导，以允许早更细节层面的ASIL剪裁。
5.2 总则
所开发相关项的安全目标的ASIL等级贯穿整个相关项的开发过程。从安全目标开始，安全要求在开发阶段得出并细化。ASIL等级作为安全目标的一个属性，由后续每个安全要求继承。功能和技术安全要求向每个架构要素的分配，开始于初步的架构设想，结束于硬件和软件要素。
设计过程中的ASIL剪裁方法称为“ASIL分解”。在分配过程中，可从包括存在充分独立的架构要素等架构决策中获得益处，这提供了一下机会：
——通过这些独立的架构要素冗余实现安全要求；及
——分配一个可能更低的ASIL等级给这些分解后的安全要求。
如果架构要素不是充分独立的，则冗余要求和架构要素继承初始的ASIL等级。
注1：ASIL分解是一种ASIL剪裁方法，可用于相关项或要素的功能安全要求、技术安全要求、硬件或软件安全要求。
注2：作为一项基本原则，ASIL分解需要安全要求且具有冗余性，且分配给充分独立的架构要素。
注3：使用同构冗余（例如：通过复制设备或复制软件）的情况下，考虑到硬件和软件的系统性失效，不能降低ASIL等级，除非相关失效的分析提供了存在充分独立性或潜在共因指向安全状态的证据。因此同构冗余因缺少要素间的独立性，通常不足以降低ASIL等级。
注4：通常，ASIL分解不适用于在多通道架构设计中用来确保通道选择的要素或切换的要素。
通常，ASIL分解允许将安全要求的ASIL等级在几个用来确保同一安全目标的同一安全要求的要素间进行分配。在特定条件下，允许在预期功能及其相应的安全机制间进行ASIL分解（参见5.4.7）
针对随机硬件失效的要求，包括硬件架构度量的评估和由于随机硬件失效导致违背安全目标的评估（参见GB/T 34590.5——2017），在ASIL分解后仍保持不变。
注：附录A中表A..1提供了以汽车安全完整性等级为导向和以完全为导向的分析的目的、前提条件和工作成果的概览。
5.3 本章的输入
5.3.1 前提条件
应具备下列信息：
——ASIL分解所在系统、硬件或软件层面的安全要求，按照GB/T 34590.3——2017的8.5.1、GB/T 34590.4——2017的6.5.1、GB/T 34590.5——2017的6.5.1或GB/T 34590.6——2017的6.5.1；及
——ASIL分解所在系统、硬件或软件层面的架构信息，按照GB/T 34590.4——2017的7.5.2、GB/T 34590.5——2017的7.5.1、或GB/T 34590.6——2017的7.5.1。
5.3.2 支持信息
可考虑以下信息：
——相关项定义（参见GB/T 34590.3——2017的5.5）；及
——安全目标（GB/T 34590.3——2017的7.5.2）。
5.4 要求和建议
5.4.1如果应用 ASIL分解，应满足本章的所有要求。
5.4.2进行ASIL分解时,应分別考虑每一个初始的安全要求。
注：对不同初始安全要求的ASIL分解，可将几个安全要求分配给同一独立要素。
5.4.3应将初始安全要求分解为由充分独立要素执行的冗余安全要求。
5.4.4每个分解后的安全要求自身应符合初始安全要求。
注：此要求通过定义提供了冗余。
5.4.5按照GB/T34590.5--2017，对硬件架构度量的评估要求和对由于随机硬件失效导致违背安全目标的评估要求应在ASIL分解后保持不变。
5.4.6如果在软件层面应用ASIL分解，应在系统层面检查执行分解后要求的要素间的充分独立性，且应在软件层面、硬件层面或系统层面采取适当的指施来获得充分的独立性。
5.4.7如果对初始安全要求的ASIL分解导致将分解后的要求分配给预期功能及相关安全机制，则：
a)相关安全机制宜被赋予分解后的最高ASIL等级；
注：通常，与预期功能相比，安全机制具备更低的复杂度和更小的规模。
b) 安全要求应被分配给预期功能，并按照相应分解后的ASIL等级实现。
注：如果选择了分解方案ASILx(x) + QM(x)，则QM(x)意味着对于实现分配给预期功能的安全要求的要素开发，质量管理体系是充分的。QM(x)也意味着质量管理体系可为预期功能和安全机制间独立性的依据提供支持。
5.4.8如果不能通过将要素关闭来阻止对初始安全要求的违背，则应展示执行分解后安全要求的充分独立要素具备足够的可用性。
5.4.9对安全要求应用ASIL分解时：
a）应按照5.4.10应用ASIL分解；
b）ASIL分解的应用可能多于一次；
c）应通过在括号中给出安全目标的ASIL等级，对每个分解后的ASIL等级做标注。
示例：如果一个ASID的要求分解成一个ASIL C的要求和一个ASIL A的要求，则应标注成“ASL C(D)”和“ASIL A(D)”。如果ASIL C(D)的要求进一步分解成一个 ASIL B的要求和-一个ASIL A的要求，.则应使用安全目标的ASI等级将其标注为“ASIL B(D)”和“ASIL A(D)”。
5.4.10应按照分解前的ASIL等级选择下列分解方案中的一种（如图2所示），或使用可得出更高ASIL等级的方案。
注：从所选分解方案的一个层面到相邻更低层面的步骤定义ASIL等级的一个分解。
a）应按照下列之一对一个ASIL D的要求进行分解：
1）一个 ASIL C(D)的要求和一个ASIL A(D)的要求；或
2）一个ASL B(D)的要求和一个ASIL B(D)的要求；或
3）一个 ASIL D(D)的要求和一个QM(D)的要求。
b）应按照下列之一对一个ASIL C的要求进行分解：
1）一个 ASIL B(C)的要求和一个ASIL A(C)的要求；或
2）一个ASILC(C)的要求和一个QM(C)的要求。
c）应按照下列之一对一个ASILB的要求进行分解：
1）一个ASIL A(B)的要求和一个ASIL A(B)的要求；或
2） 一个ASIL B(B)的要求和一个QM(B)的要求。
d） 一个ASIL A的要求不应被进一步分解，除非需要分解成一个ASIL A(A)的要求和一个
QM(A)的要求。

ASIL C 分解 其他分解 分解之前 分解之后
示例：5.4.7中描述的案例，即：QM分配给预期功能、与初始ASIL等级相同的ASIL等级分配给相关安全机制，如最右列所示。
注：每个分解步骤最上面阴影框内的值代表分解的的ASIL等级。
图2 ASIL 分解方案
5.4.11当使用 5.4.10中给出的任何分解方案时，则：
a）应按照安全目标的ASIL等级实施符合GB/T34590.2——2017的6.4.7的认可措施；;
b）应具备分解后要素充分独立性的证据。
注：如果相关失效分析（参见本部分第7章）未发现可导致违背分解前安全要求的相关失效来源，或识别出的每个相关失效的来源都按照安全目标的ASIL等级被安全措施充分控制，则要素是充分独立的。
5.4.12 当使用5.1.10 a) 2)中给出的ASIL D分解方案时，则：
a）应按照GB/T 34590.8-——2017 第6章ASIL C的要求来定义分解后的安全要求；
注：与ASIL B相比，ASIL C要求更正式的标记法，从而更有效的避免系统性失效，并降低两个ASIL B(D)实施间的相关性。
b）如果用相同的软件工具开发分解后的要素，则这些软件工具应考虑为开发ASIL D相关项或要素的软件，并符合GB/T 34590.8——2017中软件工具使用的置信度。
5.4.13 应至少按照GB/T 34590.4-——2017和GB/T 34590.6——2017中（分解后的）ASIL等级要，,在系统层面和软件层面开发分解后的要素，应至少按照GB/T 34590.5——2017中（分解后的）ASIL等级要求，在硬件层面开发分解后的要素，但硬件架构度量的评估和因随机硬件失效导致违背安全目标的评估除外（参见5.4.5）。
5.4.14 在应用了分解的设计过程的每个层面，应按照分解前的ASIL等级的要求开展对分解后的要素的相关集成活动及后续活动。
5.5 工作成果
5.5.1 架构信息的更新，由5.4得出。
5.5.2 作为安全要求和要素的属性的ASIL等级更新，由5.4得出。
6 要素共存的准则
6.4 目的
本章提供了以下子要素在同一要素内共存的准则：
——安全相关的子要素与没有分配ASIL等级的子要素；及
——分配了不同ASIL等级的安全相关子要素。
6.2 总则
通常，当某个要素由几个子要素组成时，依照适用于该要素的最高ASIL等级（即：分配给要素的安全要求的最高ASIL等级）的相应措施开发每个子要素（参见GB/T 34590.4——2017 的7.4.2.3）。
在分配了不同ASIL等级的子要素共存情况下，或未分配ASIL等级的子要素与安全相关的子要素共存情况下，避免将某些子要素的ASIL等级提高到要素的ASIL等级可能是有益的。为达到该目的，本章为确定要素中子要素的ASIL等级提供了指导。本章以要素中某个子要素与其余子要素间的干扰分析为基础。
干扰是由未分配ASIL等级的子要素或分配了较低ASIL等级的子要素，到分配了较高ASIL等级的子要素发生了级联失效，从而导致违背了要素的安全要求（参见GB/T 34590.1-——2017 中2.13和2.49的定义）。
当确定要素中子要素的ASIL等级时，关注级联失效的相关失效分析（参见本部分第7章）支持了免于干扰的理由。
6.3 本章的输入
6.3.1 前提条件
应具备下列信息：
——开展分析所在系统、硬件或软件层面的安全要求，按照GB/T 34590.3——2017的8.5.1、GB/T 34590.4——2017的6.5.1、GB/T 34590.5——2017的6.5.1或GB/T 34590.6——2017的6.5.1；及
——开展分析所在系统、硬件或软件层面的要素架构信息，按照GB/T 34590.4——2017的7.5.2、GB/T 34590.5——2017的7.5.1或GB/T 34590.6——2017的7.5.1。
6.3.1 支持信息
无
6.4 要求和建议
6.4.1本章可平行于架构要素和子要素的安全要求分配，用于设计过程的任意细化步骤，典型的应用是在系统设计、硬件设计或软件架构设计的子阶段，按照GB/T 34590.4——2017或GB/T 34590.6——2017.
6.4.2 应用本章之前应将安全要求分配给要素的子要素。
注：安全要求向子要素的分配生成了安全相关子要素和为未分配ASIL等级的子要素。
6.4.3 分析要素时应考虑下列内容：
a）分配到要素的每个安全要求：及
b）要素的每个子要素。
6.4.4 如果未分配ASIL等级的子要素和安全相关子要素共同存在于同一要素中，如果内容能证明未分配ASIL等级的子要素不直接或间接地违背分配给该要素的任何安全要求，即：它不干扰要素中安全相关的任何子要素，则应仅视其为QM的子要素。
注1：这意味着从该子要素到安全相关要素的级联失效时不存在的。
注2：这能通过设计预防措施获得，诸如考虑软件的数据流和控制流，或硬件的I/O端口及控制线。
否则，在不具备免干扰证据的情况下。应将共存安全相关子要素的最高ASIL等级分配给该子要素。
6.4.5 如果同一要素中存在不同ASIL等级，包括QM（x）（参见5.4.10）的安全相关子要素，若能证明对分配给要素的每个安全要求，某个子要素不会干扰任何分配了较高ASIL等级的其他子要素，则应仅视该子要素为较低ASIL等级的子要素。否则，应将不具备免干扰证据的共存安全相关子要素的最高ASIL等级分配给该子要素。
6.5 工作成果
作为要素中子要素属性的ASIL等级的更新，由6.4得出。
7 相关失效分析
7.1 目的
相关失效分析旨在识别出可绕开给定要素间所要求的独立性、绕开免干扰、使独立性无效或使免于干扰无效，并违背安全要求或安全目标的单一事件或原因。
7.2 总则
相关失效分析考虑架构特征，例如：
——相似的和不相似的冗余要素；
——由相同的软件或硬件要素实现的不同功能；
——功能及其相关安全机制；
——功能的分割或软件要素的分隔；
——硬件要素间的物理距离，有隔离或无隔离；
——共同的外部资源。
根据GB/T 34590.1——2017的定义，独立性受到共因失效和级联失效的威胁，而免于干扰仅受级联失效的威胁。
示例1：引发不同电子设备以一种基于设计方式失效或使用的方式失效的高强度电磁场，是共因失效的一个例子；影响车辆功能表现的有偏差的车速信息，是级联失效的例子。
相关失效可同时显现，或在足够短的时间间隔内产生同时失效的效果。
示例2：如果用于探测功能异常表现的监控和被监控的功能受相同的事件或原因影响，则在被监控功能失效前的某个时刻，可使监控无效。
7.3 本章的输入
7.3.1 前提条件
应具备下列信息：
——所应用系统、硬件或软件层面的独立性要求，按照GB/T 34590.3——2017的8.5.1、GB/T 34590.4——2017的6.5.1、GB/T 34590.5——2017的6.5.1或GB/T 34590.6——2017的6.5.1；
——所应用系统、硬件或软件层面的免于干扰要求，按照GB/T 34590.3——2017的8.5.1、GB/T 34590.4——2017的6.5.1、GB/T 34590.5——2017的6.5.1或GB/T 34590.6——2017的6.5.1；及
——独立性或免于干扰的要求所应用系统、硬件或软件层面的架构信息，按GB/T 34590.4——2017的7.5.2、GB/T 34590.5——2017的7.5.1或GB/T 34590.6——2017的7.5.1。
注：架构信息用于确定相关失效分析的范围。
7.3.2 支持信息
无
7.4 要求和建议
7.4.1 应按照第8章安全分析的结果识别粗相关失效的潜在可能性。
注1：系统性失效和随机硬件失效都有可能成为相关失效。
注2：对相关失效的潜在可能性的识别可基于演绎分析法：割集检查或者FTA中重复的相同事件可表明相关失效的潜在可能性。
注3：归纳分析法也可支持识别：在FMEA中多次出现具有相似模式的相似元器件或组件可提供相关失效潜在可能性的额外信息。
7.4.2 应评估每个识别出的相关失效的潜在可能性，以判定其合理性，即：是否存在导致相关失效并违背给定要素间所要求的独立性或免于干扰的合理可预见理由。
注：为进行随机硬件失效导致违背安全目标的评估，而需要对随机硬件失效进行量化时（参见GB/T 34590.5——2017），因不存在通用且充分可靠的量化方法，共因失效的影响是在定性基础上评估的。
7.4.3 此评估应考虑所分析相关项或要素的运行工况，也应考虑其各种运行模式。
7.4.4 此评估应考虑以下适用的内容：
注1：合适的检查清单（例如：基于现场经验的检查清单）可支持对潜在相关失效合理性的评估。检查清单为分析员提供了根本原因和耦合因素（例如：相同的设计、相同的过程、相同的组件、相同的接口、近似度）的代表性示例。GB/T 20438中提供的信息可作为建立此类检查清单的基础。
注2：也可由是否遵守了旨在防止引入可导致相关失效的根本原因和耦合因素的过程指南来支持此评估。
a) 随机硬件失效；
示例：共用模块[例如：大规模集成电路（微控制器、ASIC等）的时钟、测试逻辑和内部电压调节器]的失效。
b) 开发错误；
示例：要求错误、设计错误、实施错误、因使用新技术导致的错误和做更改时引入的错误。
c） 生产错误
示例：过程、流程和培训相关的错误；控制计划和特殊性监控中的错误；软件刷新和下线刷新相关的错误。
d） 安装错误；
示例：线束布置相关的错误；元器件间互换性相关的错误；相邻的相关项或要素的失效。
e） 维修错误；
示例：过程、流程和培训相关的错误；问题处理相关的错误；元器件间互换性相关的错误和由于反向的不兼容性导致的错我。
f） 环境因素；
示例：温度、振动、压力、湿度/冷凝、污染、腐蚀、毒害、电磁兼容性。
g） 共同外部资源失效；及
示例：供电、输入数据、系统间数据总线和通信。
h） 特定工况下的压力。
示例：磨损和老化。
7.4.5 应具备相关失效及其影响的合理性依据。
注：合理的相关失效是那些按照7.4.2的评估发现了合理可预见原因的失效。
7.4.6 应按照GB/T 34590.8——2017变更管理在开发阶段为合理的相关失效定义解决措施。
7.4.7 用于解决合理相关失效的措施应包括用于预防其根本原因的措施、控制其影响的措施或减少耦合因素的措施。
示例：多样性是可用于预防、降低或探测共因失效的一种措施。
7.5 工作成果
相关失效的分析，由7.4得出。