标准编号:	GB/T 34590.5-2017
中文名称:	道路车辆 功能安全 第5部分：产品开发：硬件层面
英文名称:	Road vehicles―Functional safety―Part 5:Product development at the hardware level
中标分类:	T35    车用电子、电气设备与仪表综合
行业分类:	GB    国家标准
ICS分类:	43.040 43.040    道路车辆装置 43.040
发布机构:	中华人民共和国国家质量监督检验检疫总局 中国国家标准化管理委员会
发布日期:	2017-10-14
实施日期:	2018-5-1
标准状态:	被替代
被新标准替代:	GB/T 34590.5-2022 道路车辆 功能安全 第5部分：产品开发：硬件层面
被替代日期:	2023-7-1
翻译语言:	英文
文件格式:	PDF
中文字符数:	62000 字
翻译价格(元):	750.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 5 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-5:2011 Road Vehicles - Functional Safety - Part 5: Product Development at the Hardware Level.



There are technical deviations between this part and ISO 26262-5: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-6:2011 is replaced with GB/T 34590.6-2017 which is modified in relation to international standard;



 ISO 26262-7:2011 is replaced with GB/T 34590.7-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;



 ISO 26262-9:2011 is replaced with GB/T 34590.9-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 may 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 Chapter 6 of GB/T 34590.2-2017.







Figure 1 Overview of GB/T 34590-2017



Road Vehicles - Functional Safety –

Part 5: Product Development at the Hardware Level



1 Scope



This part of GB/T 34590 specifies the requirements for product development at the hardware level for automotive applications, including the following:



——requirements for the initiation of product development at the hardware level,



——specification of the hardware safety requirements,



——hardware design,



——hardware architectural metrics, and



——evaluation of violation of the safety goal due to random hardware failures and hardware integration and testing.



The requirements of this part for hardware elements are applicable both to non-programmable and programmable elements, such as ASIC, FPGA and PLD. Furthermore, for programmable electronic elements, requirements in GB/T 34590.6-2017 and GB/T 34590.8-2017, Chapter 11 and Chapter 12, are applicable.



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 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).



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.4-2017 Road Vehicles - Functional Safety - Part 4: Product Development at the System Level (ISO 26262-4: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.7-2017 Road Vehicles - Functional Safety - Part 7: Production and operation (GB/T 34590 -7: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 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, or



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 may 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.



Note: 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, 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.

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 Initiation of Product Development at the Hardware Level
5.1 Objectives
5.2 General
5.3 Inputs to This Chapter
5.4 Requirements and Recommendations
5.5 Work Products
6 Specification of Hardware Safety Requirements
6.1 Objectives
6.2 General
6.3 Inputs to this Clause
6.4 Requirements and Recommendations
6.5 Work Products
7 Hardware Design
7.1 Objectives
7.2 General
7.3 Inputs to This Clause
7.4 Requirements and Recommendations
7.5 Work Products
8 Evaluation of the Hardware Architectural Metrics
8.1 Objectives
8.2 General
8.3 Inputs of This Clause
8.4 Requirements and Recommendations
8.5 Work Products
9 Evaluation of Safety Goal Violations Due to Random Hardware Failures
9.1 Objectives
9.2 General
9.3 Inputs to This Clause
9.4 Requirements and Recommendations
9.5 Work Products
10 Hardware Integration and Testing
10.1 Objectives
10.2 General
10.3 Inputs of This Clause
10.4 Requirements and Recommendations
10.5 Work Products
Annex A (Informative) Overview of and Workflow of Product Development at the Hardware Level
Annex B (Informative) Failure Mode Classification of A Hardware Element
Annex C (normative) Hardware Architectural Metrics
Annex D (Informative) Evaluation of the Diagnostic Coverage
Annex E (Informative) Example Calculation of Hardware Architectural Metrics: “Single-point Fault Metric” and “Latent-fault Metric”
Annex F (Informative) Application of Scaling Factors
Bibliography

道路车辆功能安全
第5部分：产品开发：硬件层面
1 范围
GB/T 34590的本部分规定了车辆在硬件层面产品开发的要求，包括：
——启动硬件层面产品开发的要求；
——硬件安全要求的定义；
——硬件设计；
——硬件架构度量；及
——因随机硬件失效导致违背安全目标的评估，硬件集成及测试。
本部分对于硬件要素的要求适用于非可编程要素和可编程要素，如ASIC、FPGA和PLD。并且，GB/T 34590.6—2017、GB/T 34590.8—2017的第11章和12章中的要求对于可编程电子要素是适用的。
本标准适用于安装在量产乘用车上的包含一个或多个电子电气系统的与安全相关的系统。
本标准不适用于特殊用途车辆上特定的电子电气系统，例如，为残疾驾驶者设计的车辆。
本标准不适用于已经完成生产发布的系统及其组件或在本标准发布日期前开发的系统及其组件。对于在本标准发布前完成生产发布的系统及其组件进行进一步的开发或变更时，仅修改的部分需要按照本标准开发。
本标准针对由电子电气安全相关系统的故障行为而引起的可能的危害，包括这些系统相互作用而引起的可能的危害。本标准不针对与触电、火灾、烟雾、热、辐射、毒性、易燃性、反应性、腐蚀性、能量释放等相关的危害和类似的危害，除非危害是直接由电子电气安全相关系统的故障行为而引起的。
本标准不针对电子电气系统的标称性能，即使这些系统(例如，主动和被动安全系统、制动系统、自适应巡航系统)有专用的功能性能标准。
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.4-2017 Road vehicles-Functional safety- Part 4:Product development at the system level (ISO 26262-4: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.7-2017 Road vehicles-Functional safety- Part 7:Production and operation (ISO 26262-7: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 术语、定义和缩略语
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中ASIL等级在括号中给出，则对于该ASIL等级，相应的子章条应被认为是推荐而非要求。这里的括号与ASIL等级分解无关。
5 启动硬件层面产品开发
5.1目的
启动硬件层面产品开发的目的是确定并计划硬件开发各子阶段过程中的功能安全活动，也包括在GB/T 34590.8?017中所描述的必要的支持过程。
硬件特定的安全活动的计划包含在安全计划中（参见GB/T 34590.2—2017的6.4.3和GB/T 34590.4—2017 的5.4）。
5.2 总则
制定满足安全要求的硬件开发所需的活动和流程的计划。图2阐明了为满足本部分要求的硬件层面产品开发的流程步骤，以及在GB/T 34590框架内这些步骤的集成。
硬件层面产品开发的必要活动和流程包括：
——技术安全概念的硬件实现；
——分析潜在硬件故障及其影响；及
——与软件开发的协调。




GB/T 34590.5-2017：产品开发：硬件层面
4.7 系统设计
GB/T 34590.5-2017范围
5.5 启动硬件层面产品开发
5.6 硬件安全要求的定义
5.7 硬件设计
7.5 生产
7.6 运行、服务（维护与维修）和报废
8.13 硬件组件的鉴定
5.8 硬件架构度量的评估
5.9 随机硬件失效导致违背安全目标的评估
5.10硬件集成与测试
4.8 相关项的集成与测试
注：在图中，GB/T 34590的各部分具体条款用以下列方式来表明：“m-n”，其中”m”代表“部分”的编号和”n”表示 “章”的编号，例如，”4-5”表示GB/T 34590的第4部分的第5章。
图2 硬件层面产品开发参考阶段模型
与软件开发子阶段相比，本部分包含两个章节来描述相关项整体硬件架构的定量评估。
第8章描述了两个度量，以评估相关项硬件架构和实施的安全机制应对随机硬件失效的有效性。
作为对第8章的补充，第9章描述了两个可选的方法以评估违背安全目标的残余风险是否足够低，或者应用一种全局概率方法，或者应用一种割集分析方法，来研究硬件要素中所识别出的每个故障对违背安全目标的影响。
注：附录A中表A.1提供了对硬件层面产品开发特定子阶段的目的、前提条件和工作成果的概览。
5.3本章的输入
5.3.1前提条件
应具备下列信息：
——项目计划（细化的），按照GB/T 34590.4—2017的5.5.1；
——安全计划（细化的），按照GB/T 34590.4?2017的5.5.2；及
——相关项集成和测试计划（细化的），按照GB/T 34590.4—2017的5.5.3。
5.3.2支持信息
可考虑下列信息：
——鉴定报告（硬件组件或元器件），如果适用（见GB/T 34590.8—2017 的13.5.3）。
5.4要求和建议
5.4.1应细化按照GB/T 34590.2—2017所制定的安全计划，包括确定硬件层面产品开发活动的适当方法和措施，并与GB/T 34590.6—2017中活动的计划保持一致。
5.4.2相关项硬件的开发流程，包括方法和工具，应在硬件开发的所有子阶段内保持一致，并与系统和软件子阶段保持一致，以便在硬件开发过程中保持要求流的精确性和一致性。
5.4.3硬件层面产品开发的安全生命周期活动的剪裁应按照GB/T 34590.2—2017的6.4.5实施，并基于图2给出的参考阶段模型。
5.4.4应识别出对硬件组件的复用，或对经过鉴定的硬件组件或元器件的使用，并且应描述由此产生的对安全活动的剪裁。
5.5工作成果
安全计划（细化的），由5.4.1〜5.4.4的要求得出。
6 硬件安全要求的定义
6.1目的
本章的第一个目的是定义硬件安全要求，这些要求由技术安全概念和系统设计规范导出。
第二个目的是验证硬件安全要求与技术安全概念及系统设计规范的一致性。
本阶段另一目的是细化最初在GB/T 34590.4—2017第7章定义的软硬件接口（HSI）规范。
6.2 总则
将技术安全要求分配给硬件和软件。既分配给硬件又分配给软件的要求被进一步划分出仅对硬件的安全要求。考虑设计限制和这些限制对硬件的影响，对硬件安全要求进行进一步的细化。
6.3本章的输入
6.3.1前提条件
应具备如下信息：
——安全计划（细化的），按照5.5的要求；
——技术安全概念，按照GB/T 34590.4—2017的7.5.1；
——系统设计规范，按照GB/T 34590.4—2017的7.5.2；及
——软硬件接口规范，按照GB/T 34590.4—2017的7.5.3。
6.3.2支持信息
可考虑如下信息：
——软件安全需求规范（见GB/T 34590.6 — 2017的6.5.1）。
6.4要求和建议
6.4.1相关项硬件要素的硬件安全需求规范应从分配给硬件的技术安全要求中导出。
6.4.2硬件安全需求规范应包括与安全相关的每一条硬件要求，包括以下：
注1: a）、b）、c）或d）中描述的硬件安全要求包括确保其安全机制有效性所需的属性。
a） 为控制要素硬件内部失效的硬件安全要求和安全机制的相关属性，这包括用来覆盖相关瞬态故障（例如，由于所使用的技术而产生的瞬态故障）的内部安全机制；
示例1:属性可包括看门狗的定时和探测能力。
b） 为确保要素对外部失效容错的硬件安全要求和安全机制的相关属性；
示例2:当外部失效发生时，如ECU的输入开路时，要求ECU应具备的功能表现。
c） 为符合其他要素的安全要求的硬件安全要求和安全机制的相关属性；
示例3:对传感器或执行器的诊断。
d） 为探测内外部失效和发送失效信息的硬件安全要求和安全机制的相关属性；及
注2: d）项中描述的硬件安全要求包括防止故障潜伏的安全机制。
示例4:安全机制中定义的硬件元器件的故障响应时间，要符合故障容错时间间隔。
e） 不定义安全机制的硬件安全要求。
示例5:举例如下：
——为满足6.4.3和6.4.4所描述的随机硬件失效目标值的硬件要素要求；
——为避免特定行为的要求（例如，“一个特定的传感器不应有一个不稳定的输出”）；
——分配给执行预期功能的硬件要素的要求；及
——定义线束或接插件的设计措施的要求。
6.4.3此要求适用于等级为ASIL （B）、C和D的安全目标。当为相关项硬件要素推导目标值时，应考虑按照GB/T 34590.4—2017第7章的要求，为本部分第8章定义的度量设定目标值。
注：在GB/T 34590.8—2017第5章定义的分布式开发情况下，此活动可包括目标值的拆分。
6.4.4此要求适用于等级为ASIL （B）、C和D的安全目标。当为相关项硬件要素推导目标值时，应考虑按照GB/T 34590.4—2017第7章的要求，为本部分第9章定义的过程设定目标值。
注：在GB/T 34590.8—2017第5章定义的分布式开发情况下，此活动可包括目标值的拆分。
6.4.5硬件安全要求应按照GB/T 34590.8—2017第6章的要求进行定义。
6.4.6应定义相关项或要素的硬件设计验证准则，包括环境条件（温度、振动、EMI等）、特定的运行环境（供电电压、任务概述等）以及特定于组件的要求：
a） 对于中等复杂性的硬件组件或元器件的鉴定验证，其准则应满足GB/T 34590.8—2017第13章的要求；及
b） 通过测试进行的验证，其准则应满足第10章的要求。
6.4.7硬件安全要求应符合GB/T 34590.4—2017中6.4.2.3要求制定的安全机制的故障容错时间间隔。
6.4.8硬件安全要求应符合GB/T 34590.4—2017中6.4.4.2要求制定的多点故障探测时间间隔。
注1:对于ASIL等级为C和D的安全目标来说，如果对应的安全概念没有描述明确的量值，多点故障探测时间间隔可以定义为等于或小于该相关项从上电到下电的周期。
注2:合适的多点故障探测时间间隔也可以通过对随机硬件失效的发生概率的定量分析来确定。
6.4.9硬件安全要求应按照GB/T 34590.8—2017第6章和第9章的要求进行验证，以提供证据证明其：
a） 与技术安全概念、系统设计规范以及硬件规范的一致性；
b） 关于技术安全要求分配给硬件要素的完整性；
c） 与相关软件安全要求的一致性；及 d）正确性与精确性。
6.4.10在GB/T 34590.4—2017第7章中最初定义的软硬件接口（HSI）应被充分细化，以允许硬件被软件正确的控制和使用，并且应描述出硬件和软件之间的每一项安全相关的关联性。
6.4.11软硬件开发人员应共同负责验证细化后的软硬件接口（HSI）规范的充分性。
6.5工作成果
6.5.1硬件安全需求规范（包括测试和认可准则），由6.4.1〜〜6.4.8的要求得出。
6.5.2软硬件接口规范（细化的），由6.4.10和6.4.11的要求得出。
注：此工作成果可以参考GB/T 34590.6—2017中6.5.2给出的相同的工作成果。
6.5.3硬件安全要求验证报告，由6.4.9的要求得出。
7 硬件设计
7.1目的
本章的第一个目的是按照系统设计规范和硬件安全要求设计硬件。
本章的第二个目的是验证硬件设计是否违背系统设计规范和硬件安全要求。
7.2 总则
硬件设计包括硬件架构设计和硬件详细设计。硬件架构设计表示所有的硬件组件以及它们彼此的相互关系。硬件详细设计是在电气原理图级别上，表示构成硬件组件的元器件间的相互连接。
为开发同时符合硬件安全要求及所有的非安全要求的唯一的硬件设计，在此子阶段，应在同一开发过程中处理安全和非安全性要求。
7.3本章的输入
7.3.1前提条件
应具备下列信息：
——硬件安全需求规范，按照6.5.1；
——软硬件接口规范（细化的），按照6.5.2；
——系统设计规范，按照GB/T 34590.4—2017的7.5.2；及
——安全计划（细化的），按照5.5。
7.3.2支持信息
可考虑下列信息：
——软件安全需求规范（参见GB/T 34590.6—2017的6.5.1）。
7.4要求和建议
7.4.1硬件架构设计
7.4.1.1 硬件架构应实现第6章定义的硬件安全要求。
7.4.1.2每个硬件组件应继承其所执行的硬件安全要求中最高的ASIL等级。
注：硬件组件的各个特征将继承该组件所执行的硬件安全要求中最高的ASIL等级。
7.4.1.3 如果在硬件架构设计中对硬件安全要求应用了ASIL分解，ASIL分解应按照GB/T 34590.9—2017第5章的要求进行。
7.4.1.4 如果一个硬件要素由指定为不同ASIL等级的子要素组成，或由没有指定ASIL等级的子要素与安全相关的子要素组成。除非满足按照GB/T 34590.9—2017的共存准则，否则应按照最高的ASIL等级处理每个子要素。
7.4.1.5 对硬件安全要求和其实施之间的可追溯性，应保持到硬件组件的最底层。
注：可追溯性不要求深入到硬件详细设计，而且不需要为硬件元器件指定ASIL等级。
7.4.1.6 为避免高复杂性导致的失效，应通过使用表1中列出的原则，使硬件架构设计具有下述特性：
a） 模块化；
b） 适当的粒度水平；及
c） 简单性。
表1模块化的硬件设计原则

原 则 ASIL等级
A B C D
1 分层设计 + + + +
2 安全相关硬件组件的精确定义接口 + + + + + + + +
3 避免不必要的接口复杂性 + + + +
4 避免不必要的硬件组件复杂性 + + + +
5 可维护性（服务） + + + + + +
6 可测试性a + + + + + +
a可测试性包括开发和运行过程中的测试。

7.4.1.7 在硬件架构设计时，应考虑安全相关硬件组件失效的非功能性原因，如果适用，可包括以下的影响因素：温度、振动、水、灰尘、电磁干扰、来自硬件架构的其他硬件组件或其所在环境的串扰。
7.4.2硬件详细设计
7.4.2.1 为了避免常见的设计缺陷，按照GB/T 34590.2—2017的5.4.2.7，应运用相关的经验总结。 7.4.2.2 在硬件详细设计时，应考虑安全相关硬件元器件失效的非功能性原因，如果适用，可包括以下的影响因素.温度、振动、水、灰尘、电磁干扰、噪声因素、来自硬件组件的其他硬件元器件或其所在环境的串扰。
7.4.2.3 硬件详细设计中，硬件元器件的运行条件应符合它们的环境和运行限制规范。
7.4.2.4 应考虑鲁棒性设计原则。
注：鲁棒性设计原则可利用基于质量管理方法的核对表来展示。
示例：保守的组件规范。
7.4.3安全分析
7.4.3.1 硬件设计的安全分析，应按照表2和GB/T 34590.9—2017第8章进行，以识别失效的原因和故障的影响。
注1:安全分析的最初目的是支持硬件设计的定义，其后，安全分析可用于硬件设计验证（见7.4.4）。
注2:就安全分析支持硬件设计定义的目的来说，定性分析可能是适当且充分的。
表2硬件设计的安全分析

方 法 ASIL等级
A B C D
1 演绎分析a 0 + + + + +
2 归纳分析b + + + + + + + +
注：分析的详细程度与设计的详细程度相对应。在某些情况下，两种方法都可在不同的细节层面上执行。
a一个典型的演绎分析方法是FTA。
b一个典型的归纳分析法是FMEA

7.4.3.2 此要求适用于等级为ASIL （B）、C和D的安全目标。对于每个安全相关的硬件组件或元器件，针对所考虑的安全目标，安全分析应识别以下内容：
a） 安全故障；
b） 单点故障或残余故障；及
c） 多点故障（无论是可感知的、可探测的或潜伏的）。
注1:在大多数情况下，分析可以限制到双点故障。但有时阶次高于2的多点故障可能显示与技术安全概念有关（例如，当执行冗余安全机制时）。
注2:识别双点故障的目的，并不要求对每一种可能的两个硬件故障的组合进行系统性的分析，但至少要考虑从技术安全概念得出的组合（例如两个故障的组合：一个故障影响了安全相关的要素，另一个故障影响了相应的为达到或维持安全状态所需的安全机制）。
7.4.3.3此要求适用于等级为ASIL（B）、C和D的安全目标。应具备安全机制对避免单点故障的有效性的证据。
为了这个目的：
a）应具备证据以证明安全机制具有保持安全状态或安全的切换到安全状态的能力（特别是在容错时间间隔内适当的失效减轻能力及
b）应评估残余故障的诊断覆盖率。
注1: 一个可在任何时间（例如不仅在上电时）发生的故障，如果诊断测试时间间隔加上相应安全机制的故障响应时间，大于相应的容错时间间隔，则不能认为此故障被有效覆盖。
注2:如果可以证明故障仅发生在上电时，并且在车辆行驶期间发生的概率是可以忽略的，则对这些故障仅在上电后执行启动测试是可以接受的。
注3:可用例如FMEA或FTA分析来构建理由。
注4:根据对硬件要素失效模式和它们对更高层面的影响的认知，这种评估可以是硬件要素的全局诊断覆盖率，或更详细的失效模式的覆盖率评估。
注5:附录D可作为诊断覆盖率（I）C）的起始点，此起点是声明的有合适理由支持的诊断覆盖率。
7.4.3.4 此要求适用于等级为ASIL （B）、C和D的安全目标。应具备安全机制对避免潜伏故障的有效性的证据。
为了这个目的：
a）应具备证据以证明在可接受的多点故障探测时间间隔内完成潜伏故障的失效探测及警示驾驶员的能力，以确定哪些故障保持潜伏，哪些故障不再保持潜伏；及
b）应评估潜伏故障的诊断覆盖率。
注1:如果一个故障的诊断测试时间间隔加上相应安全机制的故障响应时间大于相应的潜伏故障的多点故障探测时间间隔，则不能认为此故障被有效覆盖。
注2:可用例如FMEA或FTA分析来构建理由。
注3:附录D可作为诊断覆盖率（DC）的起始点，此起点是声明的有合适理由支持的诊断覆盖率。
注4:根据对硬件要素失效模式和它们对更高层面的影响的认知，这种评估可以是硬件要素的全局诊断覆盖率，或更详细的失效模式的覆盖率评估。
7.4.3.5 如果适用，应按照GB/T 34590.9—2017第7章进行相关失效分析，提供证据证明硬件设计与它们的独立性要求相符合。
7.4.3.6 如果硬件设计引入了新危害，且这个危害没有被现有的安全目标覆盖，则应按照GB/T 34590.8—2017中的变更管理流程对它们进行危害分析和风险评估。
注：新识别出的、没有被现有安全目标覆盖的危害，通常是非功能性的危害。非功能性的危害在GB/T 34590范围之外，但在危害分析和风险评估中可对它们添加如下注释：“由于不在GB/T 34590的范围内，所以没有对该危害指定ASIL等级”。然而，也可以指定一个ASIL等级作参考。
7.4.4硬件设计的验证
7.4.4.1 应按照GB/T 34590.8—2017第9章来验证硬件设计与硬件安全要求的一致性和完整性。为达到这一目的，应考虑表3中列出的方法。
表3 硬件设计验证

方 法 ASIL等级
A B C D
la 硬件设计走查a + + + + O O
lb 硬件设计检查a + + + + + +
2 安全分析 依照7.4.3
3a 仿真b O + + +
3b 通过硬件原型的开发b O + + +
注：该验证评审的范围是硬件设计的技术正确性。

a方法la和lb检查硬件设计中硬件安全要求是否得到完整和正确的执行。
b当认为分析方法1和2不充分时，利用方法3a和3b检查硬件设计的特定点（例如故障注入技术）。
7.4.4.2 在硬件设计过程中，如果发现任何硬件安全要求的实施是不可行的，应按照GB/T 34590.8—2017中的变更管理流程提出变更请求。
7.4.5生产、运行、服务和报废
7.4.5.1 如果安全分析表明生产、运行、服务和报废与安全相关，则应定义其安全相关的特殊特性，这些特殊特性应包括如下属性：
a） 生产和运行的验证措施；及
b） 这些措施的接受准则。
示例：对一种依赖于新的传感器技术的硬件设计的安全分析（例如，影像或雷达传感器），可揭示出这些传感器与特殊安装流程的关系。这种情况下，在生产阶段对这些组件的额外验证措施可能是必要的。
7.4.5.2 如果对安全相关硬件要素的组装、拆卸和报废可能影响技术安全概念，则应定义这些操作的指导说明。
7.4.5.3 应按照GB/T 34590.7—2017的5.4.1.2确保安全相关硬件要素的可追溯性。
注：这可以包括适当的标签或其他的硬件要素识别方法，来表示它们是与安全相关的。
7.4.5.4 如果维护可能影响技术安全概念，应定义安全相关硬件要素的维护说明。
7.5工作成果
7.5.1硬件设计规范，由7.4.1和7.4.2的要求得出。
7.5.2硬件安全分析报告，由7.4.3的要求得出。
7.5.3硬件设计验证报告，由7.4.4的要求得出。
7.5.4与生产、运行、服务和报废相关的需求规范，由7.4.5的要求得出。
8 硬件架构度量的评估
8.1目的
本章的目的是用表征故障处理要求的硬件架构度量来评估相关项的硬件架构。
8.2 总则
本章描述了两种硬件架构的度量，用于评估相关项架构应对随机硬件失效的有效性。
这些度量和关联的目标值适用于相关项的整体硬件，并与第9章描述的对随机硬件失效导致违背安全目标的评估互为补充。
这些度量所针对的随机硬件失效仅限于相关项中某些安全相关电子和电气硬件元器件，即那些能对安全目标的违背或实现有显著影响的元器件，并限于这些元器件的单点故障、残余故障和潜伏故障。对于机电硬件元器件，则仅考虑电气失效模式和失效率。
注：计算中可忽略阶次高于2的多点故障硬件要素，除非它们与技术安全概念相关。
硬件架构度量可在硬件架构设计和硬件详细设计过程中迭代使用。
硬件架构度量取决于相关项的整体硬件。对相关项涉及的每个安全目标，都应符合规定的硬件架构度量的目标值。
定义这些硬件架构度量以实现下列目标：
——客观上可评估：度量是可核实的，并且足够精确以区分不同的架构；
——支持最终设计的评估（基于详细的硬件设计完成精确计算）；
——为硬件架构提供基于ASIL等级的合格/不合格准则；
——显示用于防止硬件架构中单点或残余故障风险的安全机制的覆盖率是否足够（单点故障度量）；
——显示用于防止硬件架构中潜伏故障风险的安全机制的覆盖率是否足够（潜伏故障度量）；
——处理单点故障、残余故障和潜伏故障；
——考虑到硬件失效率的不确定性，确保硬件架构的鲁棒性；
——仅限于安全相关要素；及
——支持不同要素层面的应用，例如，可以为供应商的硬件要素分配目标值。
示例：为方便分布式开发，可为微控制器或者ECU分配目标值。
8.3本章的输入
8.3.1前提条件
应具备下列信息：
——硬件安全需求规范，按照6.5.1；
——硬件设计规范，按照7.5.1；及
——硬件安全分析报告，按照7.5.2。
8.3.2支持信息
可考虑下列信息：
——技术安全概念(参见GB/T 34590.4—2017的7.5.1)；及
——系统设计规范(参见GB/T 34590.4—2017的7.5.2)。
8.4要求和建议
8.4.1此要求适用于等级为ASIL (B)、C和D的安全目标。应将符合附录C的诊断覆盖率、单点故障度量和潜伏故障度量的概念用于8.4.2〜8.4.9的要求。
8.4.2此要求适用于等级为ASIL (B)、C和D的安全目标。应结合残余故障和相关的潜伏故障来预估安全机制所实现的安全相关硬件要素的诊断覆盖率。
注1:为此目的，可使用表D.1〜表D.14作为起点，此起点是声明的有合适理由支持的诊断覆盖率。
注2:根据对硬件要素失效模式和它们对更高层面影响的认知，这种评估可以是一个硬件要素的全局诊断覆盖率评估，或更详细的失效模式的覆盖率评估。
8.4.3此要求适用于等级为ASIL (B)、C和D的安全目标。分析中用到的硬件元器件预估失效率的确定，应使用以下方法：
a) 使用业界公认的硬件元器件失效率数据；或
示例：用于确定硬件元器件失效率和失效模式分布的业界公认的来源包括IEC/TR 62380、IEC 617O9,MIL HDBK 217 F notice 2、RIAC HDBK 217 Plus,UTE C80-811、NPRD 95、EN 50129:2003 Annex C IEC 62061:2005 Annex D、RI-AC FMD97 和 MIL HDBK 338。
注1:这些数据库给出的失效率数据一般都比较保守。
b) 使用现场反馈或测试的统计数据，这种情况下，预估的失效率宜有合适的置信度；或
c）使用工程方法形成的专家判断，该工程方法基于定量和定性的论证。应依据结构化准则进行专家判断，这些准则是判断的基础，应在失效率预估前进行设定。
注2:专家判断准则可包括现场经验、测试、可靠性分析和设计的新颖性。
8.4.4此要求适用于等级为ASIL (B)、C和D的安全目标。如果没有充分的证据证明计算出的单点故障或潜伏故障的失效率的可靠性，应提出替代方案(例如，增加安全机制来探测和控制此故障)。
注：例如，充分的证据可以指失效率是通过8.4.3中列出的方法得到的。
8.4.5此要求适用于等级为ASIL (B)、C和D的安全目标。对于每一个安全目标，由GB/T 34590.4—2017中7.4.4.2要求的“单点故障度量”的定量目标值应基于下列参考目标值来源之一：
a）来自应用于值得信赖的相似设计原则中，对硬件架构度量的计算；或
注1:两个相似的设计有相似的功能和分配了相同ASIL等级的相似安全目标。
b)来自表4。
表4 “单点故障度量”目标值的可能推导来源

ASIL B ASIL C ASIL D
单点故障度量 ≥90% ≥97% ≥99%

注2:此定量目标的目的是提供：
——设计指南；及
——设计符合安全目标的证据。
8.4.6此要求适用于等级为ASIL (B)、C和D的安全目标。对于每一个安全目标，由GB/T 34590.4—2017中7.4.4.2要求的“潜伏故障度量”的定量目标值应基于下列参考目标值来源之一：
a）来自应用于值得信赖的相似设计原则中，对硬件架构度量的计算；或注1:两个相似的没计有相似的功能和分配了相同ASIL等级的相似安全目标。
b） 来自表5。
表5 “潜伏故障度量”目标值的可能推导来源

ASIL B ASIL C ASIL D
潜伏故障度量 ≥60% ≥80% ≥90%

注2:此定量目标的目的是提供：
——设计指南；及
——设计符合安全目标标的证据。
8.4.7此要求适用于等级为ASIL （B）、C和D的安全目标。对于每个安全目标，相关项的整体硬件应符合下列两者之一：
a） 满足8.4.5中描述的“单点故障度量”目标值；或
b） 满足在硬件要素层规定的合适目标，这些目标足以符合分配给相关项整体硬件的单点故障度量的目标值（在8.4.5中给出），并有理由说明在硬件要素层符合这些目标。
注1:如果相关项包含失效率等级有显著差异的不同种类的硬件要素，就会存在这样的风险，即为了满足硬件架构度量时仅关注具有最高等级失效率的那些硬件要素（一个可能发生此情况的例子是，只考虑线束/保险丝/接插件的失效率，而忽略失效率显著较低的硬件元器件的失效率，就以为实现了对单点故障度量的符合性）。为每一类硬件规定合适的度量目标值有助于规避这种不良影响。
注2:当瞬态故障与所用技术相关时，要考虑这些瞬态故障。可以通过给它们指定并确认一个特定的“单点故障度量”目标值（如注1中所解释的），或通过一个基于对内部安全机制有效性验证的定性理由来处理这类瞬态故障。
注3:如果不满足目标，将按4.1所述评估如何实现安全目标的理由。
注4:可以结合考虑多个或所有适用的安全目标来确定单点故障度量；但在这种情况下，采用最高ASIL等级的安全目标的度量目标。
8.4.8此要求适用于等级为ASIL （B）、C和D的安全目标。对于每个安全目标，相关项的整体硬件应符合下列之一：
a）满足8.4.6中描述的“潜伏故障度量”目标值；或
b）满足在硬件要素层规定的合适目标，这些目标足以符合分配给相关项整体硬件的潜伏故障度量的目标值（在8.4.6中给出），并有理由说明在硬件要素层符合这些目标；或
c）对于其故障可导致安全机制（防止故障违背安全目标）无效的每个硬件要素，满足相关潜伏故障的诊断覆盖率目标值，该值与8.4.6中给出的潜伏故障度量目标值一致（被当做诊断覆盖率），当每个安全机制都是基于故障探测且其无效可导致违背安全目标时，适用此选项。
注1:选项c）仅限于在每个相关安全机制是基于故障探测的情况。在此情况下，通过这些安全机制的探测来警示目标功能的可能潜伏故障。在其他情况下，则只有选项a）和b）适用。
注2:在选项c）情况下，不计算度量，只评估安全机制对于硬件要素的潜伏故障的覆盖率。
注3:如果相关项包含失效率等级显著差异的不同种类的硬件要素，就会存在这样的风险，即为了满足硬件架构度量时仅考虑具有最高等级失效率的那些硬件要素（一个可能发生此情况的例子是，只考虑线束/保险丝/接插件的失效率，而忽略失效率显著较低的硬件元器件的失效率，就认为实现了对单点故障度量的符合性）。为每一类硬件规定合适的度量目标值有助于规避这种不良影响。
注4:如果不满足目标，将按4.1所述评估如何实现安全目标的理由。
注5:可以结合考虑多个或所有适用的安全目标来确定潜伏故障度量；但在这种情况下，采用最高ASIL等级的安全目标的度量目标。
8.4.9此要求适用于等级为ASIL （B）、C和D的安全目标。应按照GB/T 34590.8—2017第9章的要求，对应用8.4.7和8.4.8中的方法得出的结果进行验证评审，以提供其技术正确性和完整性的证据。
注：仔细验证单点故障度量，确保只考虑了安全相关硬件要素的失效率，这样度量才不会受到不具备单点故障或残余故障可能性的、不必要的安全相关硬件要素的影响（例如，向安全机制添加了不必要的硬件要素）。
8.5工作成果
8.5.1相关项架构应对随机硬件失效的有效性的分析，由8.4.1〜8.4.8的要求得出。
8.5.2相关项架构应对随机硬件失效的有效性评估的评审报告，由8.4.9的要求得出。
9 随机硬件失效导致违背安全目标的评估
9.1目的
本章中要求的目的是制定可用的准则，用于表明相关项随机硬件失效导致违背安全目标的残余风险足够低。
注：“足够低”指“与已经在使用的相关项的残余风险相当”。
9.2 总则
推荐用两个可选的方法（见9.4）以评估违背安全目标的残余风险是否足够低。
两个方法都评估由单点故障、残余故障和可能的双点故障导致的违背安全目标的残余风险。如果显示为与安全概念相关，也可考虑多点故障。在分析中，对残余和双点故障，将考虑安全机制的覆盖率，并且，对双点故障也将考虑暴露持续时间。
第一个方法包括使用概率的度量，即“随机硬件失效概率度量”（PMHF），通过使用例如定量故障树分析（FTA）及将此计算结果与目标值相比较的方法，评估是否违背所考虑的安全目标。
第二个方法包括独立的评估每个残余和单点故障，及每个双点失效是否导致违背所考虑的安全目标。此分析方法也可被考虑为割集分析。
注：在可靠性分析中，故障树中的一个割集是一组基本事件，其发生导致顶层事件的发生。
所选用的方法在硬件架构设计和硬件详细设计中可以被迭代应用。
本章的范围限于相关项的随机硬件失效。分析中所考虑的是电子电气硬件元器件。对于机电硬件元器件，仅考虑电气失效模式和失效率。
9.3本章的输入
9.3.1前提条件
应具备下列信息：
——硬件安全需求规范，按照6.5.1；
——硬件设计规范，按照7.5.1；及
——硬件安全分析报告，按照7.5.2。
9.3.2支持信息
可考虑下列信息：
——技术安全概念（参见GB/T 34590.4—2017的7.5.1）；及
——系统设计规范（参见GB/T 34590.4—2017的7.5.2）。
9.4要求和建议
9.4.1总则
此要求适用于等级为ASIL（B）、C和D的安全目标。相关项应符合9.4.2或9.4.3中的一个。
9.4.2随机硬件失效概率度量（PMHF）的评估
9.4.2.1 此要求适用于等级为ASIL（B）、C和D的安全目标。应按照GB/T 34590.4—2017中7.4.4.3的要求，为随机硬件失效导致违背每个安全目标的最大可能性定义定量目标值，使用来源a）、b）或c）的参考目标值，如下所列：
a） 来自表6；或
b） 来自值得信赖的相似设计原则的现场数据；或
c） 来自应用于值得信赖的相似设计原则中的定量分析技术（使用按照8.4.3的失效率）。
注1:这些来源于a）、b）或c）的定量目标值没有任何绝对的意义，仅有助于将一个新的设计与已有设计相比较。其目的是生成按照9.1描述的可用的设计指导，并获得设计符合安全目标的可用证据。
注2:两个相似的设计拥有相似的功能和分配了相同ASIL等级的相似安全目标。
表6 得出随机硬件失效目标值的可能来源

ASIL等级 随机硬件失效目标值
D <10-8h-1
C <107 h-1
B <10-7h-1
注：此表中描述的定量目标值可按照4.1的规定进行剪裁以适应相关项的特定使用（例如：若相关项能在比一部乘用车典型使用时间更久的持续时间内才违背安全目标）。

9.4.2.2 此要求适用于等级为ASIL（B）、C和D的安全目标。9.4.2.1要求的定量目标值应表述为相关项整个运行生命周期中每小时的平均概率。
9.4.2.3 此要求适用于等级为ASIL（B）、C和D的安全目标。针对单点、残余和双点故障的硬件架构定量分析，应提供证据证明9.4.2.1要求的目标值已达到。此定量分析应考虑：
a） 相关项的架构；
b） 每个可导致单点故障或残余故障的硬件元器件的失效模式的估计失效率；
c） 每个可导致双点故障的硬件元器件的失效模式的估计失效率；
d） 安全机制对安全相关的硬件要素的诊断覆盖率；及
e） 双点故障情况下的暴露持续时间。
注1:在定量分析中，考虑可导致一个安全相关的硬件要素及其安全机制同时失效的硬件要素失效模式。它们可以是单点故障、残余故障或多点故障。
注2:暴露持续时间从故障可能发生时开始，包括：
a） 与每个安全机制有关的多点故障探测时间间隔，或者当故障不对驾驶员显示（潜伏故障）时的车辆生命周期；
b） 单次行程的最长持续时间（对于驾驶员被要求以一种安全方式停车的情况）；及
c） 直到车辆进入车间维修前的平均时间间隔（对于驾驶员被警示要去维修车辆的情况）。
因此，暴露持续时间取决于涉及的监控类型（例如：连续监控、周期性自检、驾驶员监控、无监控）和探测到故障后的反应种类。对于连续监控触发向安全状态转移的情况，它可以短至几毫秒。当没有监控时，它可以长到车辆的生命周期。
对车辆去维修的平均时间的假设示例，取决于故障的类型：
——对舒适性功能的降级，200次车辆行程；
——对驾驶辅助功能的降级，50次车辆行程；
——对黄色警告灯或影响驾驶表现时，20次车辆行程；
——对红色警告灯，1次车辆行程。
通常不考虑维修所需要的时间（除了评估能暴露给维护人员的危害）。
一次车辆行程的平均时间间隔可以被认为是等于1h。
注3:在大部分情况下，阶次高于二的多点失效对定量目标值的影响可以忽略。然而，在一些特定情况下（极高的失效率或差的诊断覆盖率），提供两个冗余的安全机制以达到目标可能是必要的。当技术安全概念是基于冗余的安全机制时，在分析中考虑阶次高于二的多点失效。
注4:对使用集成诊断的安全机制，可用表D.1〜表D.14作为出发点，用声明的有合适理由支持的诊断覆盖率去评估这些安全机制的诊断覆盖率。
注5:相关项处于下电模式的情况不包含在每小时平均概率的计算中，由此防止人为的降低每小时的平均概率。因此，对于每天仅运行1h的相关项，剩余的23h不在此运行目标值的计算中考虑。
注6:如果目标没有被满足，应按4.1对给出的如何达到安全目标的理由进行评估。
注7:基于对硬件要素失效模式及其在更高层面上后果的认知，评估可以是硬件要素的全局诊断覆盖率，或者更详细失效模式覆盖率的评估。
9.4.2.4 此要求适用于等级为ASILC和D的安全目标。仅在已采取专用措施的情况下，才应认为硬件元器件发生的单点故障是可接受的。
注：专用措施可包括：
a） 设计特征，如硬件元器件过设计（例如，电气或热压力等级）或者物理隔离（例如，印刷电路板上的触点间隔）；
b） 专门的来料抽样测试，以降低此失效模式发生的风险；
c） 老化测试；
d） 作为控制计划一部分的专用控制设备；及
e） 安全相关的特殊特性的分配。
9.4.2.5 此要求适用于等级为ASILC和D的安全目标。如果一个硬件元器件的诊断覆盖率（针对残余故障）低于90%，应对其使用专用措施（9.4.2.4中的注，列举了专用措施的示例）。
注：当确定安全机制的覆盖率时，可考虑硬件元器件安全故障的比例。在这种情况下，覆盖率的计算与单点故障度量的计算类似，但仅在硬件元器件层面，而不在相关项层面。
9.4.2.6 此要求适用于等级为ASIL（B）、C和D的安全目标。应按照8.4.3来估计在分析中用到的硬件元器件的失效率。
9.4.2.7 此要求适用于等级为ASIL（B）、C和D的安全目标。为了避免对量值有倾向性，如果对多个来源中的失效率进行组合，它们应按一个比例因子进行换算以保持一致。如果两个失效率来源间的比例因子存在根据，则换算是可行的。
注：附录F给出了应用比例因子的指导。
9.4.3对违背安全目标的每个原因进行评估
9.4.3.1 对随机硬件失效导致违背安全目标的每个原因进行评估的方法，在图3和图4的流程图中予以了阐明。使用故障发生准则对每个单点故障进行评估。使用综合了故障发生和安全机制有效性的准则对每个残余故障进行评估。




开始
单点故障？
否残余故障？否双点失效评估流程
是满足针对单点故障的失效率等级（表7）是结束是
否增加安全以减轻故障
是满足针对残余故障的失效率等级及论断覆盖率（表8）否改善安全机制
图3 对单点和残余故障的评估流程
用于双点失效的流程在图4的流程图中进行了阐明。每个双点失效首先评估其可能性。如果两个故障同时导致的失效在足够短的时间内、以足够的覆盖率被探测或感知到，则认为这个双点失效不可能。如果双点失效是可能的，则将使用综合了故障发生和安全机制覆盖率的准则对导致其发生的故障进行评估。图3和图4中描述的评估流程适用于硬件元器件（晶体管等）层面。