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 4 of GB/T 34590.
It is developed in accordance with the rules given in GB/T 1.1-2009
It has been redrafted and modified in relation to ISO 26262-4:2011 Road Vehicles - Functional Safety - Part 4: Product Development at the System Level.
There are technical deviations between this part and ISO 26262-4:2011. The technical deviations, together with their justifications, are as follows:
——the application scope of this part is modified from "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 "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-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-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 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 Chapter 6 of GB/T 34590.2-2017.
Figure 1 Overview of GB/T 34590-2017
Road Vehicles - Functional Safely – Part 4: Product Development at the System Level
1 Scope
This part of GB/T 34590 specifies the requirements for product development at the system level for automotive applications, including the following:
——requirements for the initiation of product development at the system level;
——specification of the technical safety requirements;
——the technical safety concept;
——system design;
—— item integration and testing;
——safety validation;
——functional safety assessment;
——product release.
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.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.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 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.
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-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 Initiation of Product Development at the System Level
5.1 Objectives
The objective of the initiation of the product development at the system level is to determine and plan the functional safety activities during the individual subphases of system development. This also includes the necessary supporting processes described in GB/T 34590.8-2017.
This planning of system-level safety activities will be included in the safety plan
5.2 General
The necessary activities during the development of a system are given in Figure 2. After the initiation of product development and the specification of the technical safety requirements, the system design is performed. During system design the system architecture is established, the technical safety requirements are allocated to hardware and software, and, if applicable, on other technologies. In addition, the technical safety requirements are refined and requirements arising from the system architecture are added, including the hardware-software interface (HSI). Depending on the complexity of the architecture, the requirements for subsystems can be derived iteratively. After their development, the hardware and software elements are integrated and tested to form an item that is then integrated into a vehicle. Once integrated at the vehicle level, safety validation is performed to provide evidence of functional safety with respect to the safety goals.
GB/T 34590.5-2017 and GB/T 34590.6-2017 describe the development requirements for hardware and software. This part applies to both the development of systems and subsystems. Figure 3 is an example of a system with multiple levels of integration, illustrating the application of this part, GB/T 34590.5-2017 and GB/T 34590.6-2017.
Note: Table A.1 of Annex A provides an overview of objectives, prerequisites and work products of the particular subphases of product development at the system level.
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 System 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 the Technical Safety Requirements
6.1 Objectives
6.2 General
6.3 Inputs to this Chapter
6.4 Requirements and Recommendations
6.5 Work Products
7 System Design
7.1 Objectives
7.2 General
7.3 Inputs to this Chapter
7.4 Requirements and Recommendations
7.5 Work Products
8 Item Integration and Testing
8.1 Objectives
8.2 General
8.3 Inputs to this Chapter
8.4 Requirements and Recommendations
8.5 Work Products
9 Safety Validation
9.1 Objectives
9.2 General
9.3 Inputs to this Chapter
9.4 Requirements and Recommendations
9.5 Work Products
10 Functional Safety Assessment
10.1 Objectives
10.2 General
10.3 Inputs to this Chapter
10.4 Requirements and Recommendations
10.5 Work Products
11 Release for Production
11.1 Objectives
11.2 General
11.3 Inputs to this Chapter
11.4 Requirements and Recommendations
11.5 Work products
Annex A (Informative） Overview and Document Flow of Product Development at the System Level
Annex B (informative） Example Contents of Hardware-software Interface
Bibliography
道路车辆功能安全
第4部分：产品开发：系统层面
1范围
GB/T 34590的本部分规定了车辆在系统层面产品开发的要求，包括：
——启动系统层面产品开发；
——技术安全要求的定义；
——技术安全概念；
——系统设计；
——相关项集成和测试；
——安全确认；
——功能安全评估；及
——生产发布。
本标准适用于安装在量产乘用车上的包含一个或多个电子电气系统的与安全相关的系统。
本标准不适用于特殊用途车辆上特定的电子电气系统，例如，为残疾驾驶者设计的车辆。
本标准不适用于已经完成生产发布的系统及其组件或在本标准发布日期前开发的系统及其组件。对于在本标准发布前完成生产发布的系统及其组件进行进一步的开发或变更时，仅修改的部分需要按照本标准开发。
本标准针对由电子电气安全相关系统的故障行为而引起的可能的危害，包括这些系统相互作用而 引起的可能的危害。本标准不针对与触电、火灾、烟雾、热、辐射、毒性、易燃性、反应性、腐蚀性、能量释放等相关的危害和类似的危害，除非危害是直接由电子电气安全相关系统的故障行为而引起的。
本标准不针对电子电气系统的标称性能，即使这些系统(例如，主动和被动安全系统、制动系统、自 适应巡航系统)有专用的功能性能标准。
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.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.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等级，推荐该方法；
——“〇”表示对于指定的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启动系统层面产品开发
5.1目的
启动系统层面产品开发的目的是确定并计划系统开发各子阶段过程中的功能安全活动，也包括在 GB/T 34590.8—2017中所描述的必要的支持过程。
系统层面安全活动的计划包含在安全计划中。
5.2总则
图2给出了在系统开发过程中的必要活动。在启动产品开发和定义技术安全要求后，进行系统设 计。在系统设计过程中建立系统架构，将技术安全要求分配给硬件和软件，并且，如果适用，也可分配给其他技术。同时，细化技术安全要求，并添加来自系统架构的要求，包括软硬件接口的要求。根据架构的复杂性，可以逐步得出子系统的要求。完成相关开发后，集成硬件和软件要素并测试以形成一个相关项，然后，将该相关项集成在整车上。一旦在整车层面完成了系统集成，进行安全确认以提供与安全目标相关的功能安全证据。
GB/T 34590.5—2017和GB/T 34590.6—2017描述了软硬件的开发要求。本部分适用于系统和 子系统的开发。图3是具有多层集成的系统示例，阐明了如何应用本部分及GB/T 34590.5—2017和 GB/T 34590.6—2017。
注：附录A中表A.1提供了对系统层面产品开发特定子阶段的目的、前提条件和工作成果的概览。
注：在图中，GB/T 34590的各部分具体条款用以下方式来表示：“m-n”，其中“m”代表“部分”的编号和“n”表示“章”的编号，例如，“4-5”表示GB/T 34590第4部分的第5章。
图2安全相关的相关项开发参考阶段模型
注：在图中，GB/T 34590的各部分具体条款用以下方式来表明：“m-n”，其中“m”代表“部分”的编号和“n”表示 “章”的编号，例如，“4-5”表示GB/T 34590的第4部分的第5章。
图3系统层面产品开发示例
5.3本章的输入
5.3.1前提条件
应具备下列信息：
——项目计划（细化的），按照GB/T 34590.2—2017的6.5.2；
——安全计划，按照GB/T 34590.3—2017的6.5.2；
——功能安全评估计划，按照GB/T 34590.2—2017的6.5.4；及
——功能安全概念，按照GB/T 34590.3—2017的8.5.1。
5.3.2支持信息
可考虑下列信息：
——初步架构设想(来自外部）；及
——相关项定义(参见GB/T 34590.3—2017的5.5)。
5.4要求和建议
5.4.1应制定系统层面产品开发的安全活动计划，包括确定设计和集成过程中适当的方法和措施。
注：按照6.4.6C验证和确认)和7.4.8C系统设计的验证）的要求，设计过程中对验证活动所做计划的结果是安全计 划的组成部分，而按照8.4.2(软硬件集成和测试）、8.4.3(系统集成和测试)和8.4.4(整车集成和测试）制定的相关项集成和测试计划在一个单独相关项集成和测试计划(按照8.4.1.3的要求）中进行描述。
5.4.2应制定确认活动的计划。
5.4.3应制定系统层面产品开发的功能安全评估活动计划(参见GB/T 34590.2—2017)。
注：GB/T 34590.2—2017附录E提供了一个功能安全评估安排的示例。
5.4.4应按照GB/T 34590.2—2017的要求并基于图2给出的参考阶段模型，进行系统层面产品开发的生命周期剪裁。
注：项目计划可用于提供系统层面产品开发各子阶段和软硬件开发阶段的关系。这包括每个层面的集成步骤。
5.5工作成果
5.5.1项目计划（细化的），由5.4.4的要求得出。
5.5.2安全计划（细化的），由5.4.1〜5.4.4的要求得出。
5.5.3相关项集成和测试计划，由5.4.1的要求得出。
5.5.4确认计划，由5.4.2的要求得出。
5.5.5功能安全评估计划（细化的），由5.4.3的要求得出。
6技术安全要求的定义
6.1目的
该子阶段的第一个目的是制定技术安全要求。技术安全需求规范同时考虑功能概念和初步的架构设想(参见GB/T 34590.3—2017)，从而进一步细化功能安全概念。
第二个目的是通过分析来验证技术安全要求是否符合功能安全要求。
6.2总则
在整个开发生命周期中，技术安全要求是实现功能安全概念必要的技术要求，目的是将相关项层面 的功能安全要求细化到系统层面的技术安全要求。
注：避免潜伏故障的要求，可在第一轮系统设计子阶段之后引出。
6.3本章的输入
6.3.1前提条件
应具备下列信息：
——功能安全概念，按照GB/T 34590.3—2017的8.5.1；及
——确认计划，按照5.5.4。
6.3.2支持信息
可考虑下列信息：
——安全目标(参见GB/T 34590.3—2017的7.5.2)；
——功能概念(来自外部，参见GB/T 34590.3—2017的5.4.1)；及
——初步架构设想（来自外部，参见GB/T 34590.3—2017的8.3.2)。
6.4要求和建议
6.4.1技术安全要求的定义
6.4.1.1技术安全要求应根据功能安全概念、相关项的初步架构设想和如下系统特性来定义：
a) 外部接口，如通讯和用户接口，如果适用；
b) 限制条件，例如环境条件或者功能限制；
c) 系统配置要求。
注：具有为选择性用途而重新配置系统的能力是重复使用已有系统的一种策略。
示例：标定数据(参见GB/T 34590.6—2017附录C)常用于定制不同车辆的发动机电子控制单元。
6.4.1.2应确保GB/T 34590.3—2017的8.3.2中的初步架构设想和本子阶段中的初步架构设想的一致性。
6.4.1.3除按照6.4.1定义技术安全要求的那些功能外，如果其他功能或要求也由系统或其要素实现，则应定义这些功能或要求，或者标明其参考规范。
示例：其他要求来源于欧洲经济委员会(ECE)法规，美国联邦机动车安全标准(FMVSS)或者企业平台策略。
6.4.1.4技术安全要求应定义系统间或相关项要素间，及相关项和其他系统间的安全相关的关联性。
6.4.2安全机制
6.4.2.1技术安全要求应定义系统或要素对于影响实现安全目标的激励的响应。这包括失效和相关的激励组合，并与每个相关运行模式及规定的系统状态进行组合。
示例：如果自适应巡航(ACC)的电控单元从制动系统电控单元收到车辆稳定性控制功能不可用的通知，它将会关闭ACC功能。
6.4.2.2技术安全要求应定义必要的安全机制（参见GB/T 34590.8—2017的第6章)包括：
a) 与系统自身故障相关的探测、指示和控制措施；
注1：包括系统或者要素的自身监控，用于探测随机硬件故障，以及，如果适用，探测系统性失效。
注2：包括对通讯通道(例如：数据接口、通讯总线、无线射频链接)失效模式的探测和控制的措施。
b) 涉及探测、指示和控制与本系统有相互影响的外部设备中所发生故障的措施；
示例：外部设备包括其他的电控单元、电源或者通讯设备。
c) 使系统实现或者维持在安全状态下的措施；
注3：包括在安全机制冲突时的优先和仲裁逻辑。
d) 细化和执行报警和降级概念的措施；以及
e) 防止故障潜伏的措施[参见6.4.4(潜伏故障的避免)]。
注3：这些如同a)〜d)的措施，通常与上电过程(运行前检查），运行中，下电过程（运行后检查）及作为维护的一部 分实施的测试相关。
6.4.2.3对于每个使相关项实现安全状态或维持安全状态的安全机制，应定义下列内容：
a) 向安全状态的过渡；
注1：包括执行器的控制要求。
b) 故障容错时间间隔；
注2：整车测试和试验能够用于确定故障容错时间间隔。
c) 如果不能立即进入安全状态时的紧急运行时间间隔；及
注3：整车测试和试验能够用于确定紧急运行时间间隔。
示例1：关闭系统可以是一种紧急运行。
d) 维持安全状态的措施。
示例2： —个依赖于电源的线控制动应用的安全机制，可以包括定义备用电源或储能设备（容量、启动和运行时间等)。
6.4.3 ASIL 分解
如果在定义技术安全要求时进行ASIL分解，应根据GB/T 34590.9—2017第5章进行（与ASIL 剪裁相关的要求分解）。
6.4.4潜伏故障的避免
6.4.4.1按照4.3，此要求适用于ASIL(A)、（B)、C和D等级：如果适用，应定义防止故障潜伏的安全机制。
注1：就随机故障而言，只有多点故障可能包含潜伏故障。
示例：车载测试是用于检测潜伏故障的安全机制，它验证在不同运行模式(例如上电、下电、运行或一个额外的测试模式)下组件的状态。阀、继电器或灯在上电时做的功能测试就是这类车载测试的例子。
注2：识别是否需要防止故障潜伏的安全措施的评估标准来源于好的工程实践。GB/T 34590.5—2017第8章给出的潜伏故障度量，提供了评估的标准。
6.4.4.2按照4.3，此要求适用于ASIL(A)、（B)、C和D等级：为了避免多点失效，应为每个按照6.4.4 (潜伏故障的避免)执行的安全机制定义多点失效探测时间间隔。
6.4.4.3按照4.3，此要求适用于ASIL(A)、（B)、C和D等级：为确定多点故障探测时间间隔，宜考虑下列参数：
a) 硬件组件的可靠性，并考虑其在架构中的角色；
b) 相关危害事件的暴露概率；
c) 定义的量化目标值，表征由于硬件随机失效而违背各安全目标的最大可能性(参见要求7.4.4.3)；及
d) 相关安全目标分配的ASIL等级。
注：下列措施的使用依赖于时间限制：
——系统或要素在运行过程中的周期性测试；
——要素在上下电时的车载测试；及
——系统或要素在维护时的测试。
6.4.4.4按照4.3，此要求适用于ASIL(A)、（B)、C和D等级：用于防止双点故障变成潜伏故障的安全 机制的开发应符合：
a) ASIL B(对于分配为ASIL D的技术安全要求）；
b) ASIL A(对于分配为ASIL B和ASIL C的技术安全要求）；及
c) 工程判断(对于分配为ASIL A的技术安全要求）。
6.4.5生产、运行、维护和报废
应定义在GB/T 34590.7—2017中所表述的生产、运行、维护、维修和报废期间的关于相关项或其 要素的功能安全的技术安全要求。
注：有两个方面确保了生产、运行、维护、维修和报废期间的安全。第一个方面涉及到在6.4.5和7.4.7的要求（对 生产、运行、服务和报废的要求）中所给出的开发阶段期间执行的那些活动，而第二个方面涉及到在 GB/T 34590.7—2017中描述的生产和运行阶段期间执行的那些活动。
6.4.6验证和确认
6.4.6.1技术安全要求应按照GB/T 34590.8—2017第9章来验证，以提供证据证明它们：
a) 与功能安全概念的符合性和一致性；及
b) 与初步架构设计设想的符合性。
6.4.6.2应基于技术安全要求细化相关项的安全确认标准。
注：系统确认计划和系统确认规范是与技术安全要求并行开发的(参见第9章）。
6.5工作成果
6.5.1技术安全需求规范，由6.4.1〜6.4.5的要求得出。
6.5.2系统验证报告，由6.4.6的要求得出。
6.5.3确认计划（细化的），由6.4.6.2的要求得出。
7系统设计
7.1目的
该子阶段的第一个目的是进行系统设计和技术安全概念开发，以满足相关项的功能要求和技术安全需求规范。
该子阶段的第二个目的是验证系统设计和技术安全概念满足技术安全需求规范。
7.2总则
系统设计和技术安全概念的开发是基于功能安全概念的技术安全需求规范。如果系统由子系统构成，这个子阶段可以迭代使用。
进行系统架构的开发以实现功能安全要求、技术安全要求和非安全相关要求。因此，在该子阶段，用同一个开发流程来处理安全相关和非安全相关的要求。
7.3本章的输入
7.3.1前提条件
应具备下列信息：
——相关项集成和测试计划，按照5.5.3；及
——技术安全需求规范，按照6.5.1。
7.3.2支持信息
可考虑下列信息：
——初步架构设想（来自外部，参见GB/T 34590.3—2017的8.3.2)；
——功能概念(来自外部）；及
——功能安全概念(参见GB/T 34590.3—2017的8.5.1)。
7.4要求和建议
7.4.1系统设计规范和技术安全概念
7.4.1.1系统设计应基于功能概念、初步架构设想和技术安全要求。应保证在GB/T 34590.3—2017 的8.3.2中的初步架构设想和这个子阶段中的初步架构设想的一致性。
7.4.1.2技术安全要求应分配给系统设计要素。
7.4.1.3系统设计应实现技术安全要求。
7.4.1.4与实现技术安全要求相关，在系统设计中应考虑：
a)验证系统设计的能力；
b)与实现功能安全相关的预期的软硬件设计的技术能力；及
c)系统集成中执行测试的能力。
7.4.2系统架构约束条件
7.2.1系统和子系统架构应满足它们各自ASIL等级的技术安全要求。
7.4.2.2每个要素应继承来自它所执行的技术安全要求的最高ASIL等级。
7.4.2.3如果一个要素由指应为不同ASIL等级的子要素组成，或由非安全相关子要素和安全相关子要素组成，则它们中的每个应按照最高的ASIL等级来处理，除非它们满足按照GB/T 34590.9—2017第6章所定义的共存标准。
7.4.2.4应定义安全相关要素的内部和外部接口，以避免其他素对安全相关要素有不利于安全的影响。
7.4.2.5如果在系统设计期间对安全要求应用了ASIL等级分解，应按照GB/T 34590.9—2017第5章进行。
7.4.3避免系统性失效的指施
7.4.3.1对系统设计进行安全分析以识别系统性失效的原因和系统性故障的影响，应按照表1和GB/T 34590.9—2017第8章进行。
表1 系统设计分析
方法 ASIL等级
A B C D
1 演绎分析a o ＋ ＋＋ ＋＋
2 归纳分析b ＋＋ ＋＋ ＋＋ ＋＋
a 演绎分析方法包括故障树分析（FTA）、可靠性框图、鱼骨图。
b 归纳分析方法包括失效模式与影响分析(FMEA)、事件树分析（ETA）、马尔科夫（Markov）模型。
注1:这些分析的目的是帮助设计。因此在该阶段，定性分析可能是足够的。如果有必要，可以采用定量分析。
注2:在足以识别或排除系统性失效的原因和影响的细节层面上进行分析。
7.4.3.2应消除已识别出的引起系统性失效的内部原因，或减轻它们的影响。
7.4.3.3应消除已识别出的引起系统性失效的外部原因，或减轻它们的影响。
7.4.3.4为减少系统性失效，宜应用值得信赖的汽车系统设计原则。这些原则可能包括:
a)值得信赖的技术安全概念的再利用；
b)值得信赖的要素设计的再利用，包括硬件和软件组件；
c)值得信赖的探测和控制失效的机制的再利用；
d)值得信赖的或标准化接口的再利用。
7.4.3.5为了确保值得信赖的设计原则或要素在新相关项中的适用性，应分析其应用结果，以及应在再利用之前检查其基本设想。
注:影响分析包括确定的诊断、环境限制、时序限制的能力和可行性，确定资源的兼容性，以及系统设计的鲁棒性。
