ChinaAutoRegs｜GB/T 34590.1-2022英文版翻译English 道路车辆 功能安全 第1部分：术语（英语版）
Road Vehicles—Functional Safety—Part 1: Vocabulary
CONTENTS
Foreword
Introduction
1 Scope
2 Normative References
3 Terms and Definitions
4 Abbreviated Terms
Bibliography
Index
1 范围
水文件界定了 GB/T 34590 应用的术语和定义 ，以及缩略语 。 本文件适用于安装在除轻便摩托车外的 量产道路车辆上的包含 一个或多个电气／电子系统的与安全相关的系统 。
本文件不适用于特殊用途车辆上特定的电气 ／电子系统，例如，为残疾驾驶者设计的车辆系统 。
注 ：其他专用的安全标准可作为本文件的补充 ，反之亦然 。 已经完成生产发布的系统及其组件或在本文件发布日期前正在开发的系统及其组件不适用于本文
件 。对于在本文件发布前完成生产发布的系统及其组件进行变更时 ，本文件基于这些变 更对安全生命 周期的活动进行裁剪 。米按照本文件开发的系统与按照本文件开发的系统进行集成时，需要按照本文 件进行安全生命周期的裁剪 。
本文件针对由安全相关的 电气／电子系统的功能异常表现而引起的可能的危害，包括这些系统相互 作用而引起的可能的危害 。本文件不针对与触电 、火灾、烟雾 、热、辐射 、毒性、易燃性、反应性 、腐蚀性 、 能量释放等相关的危害和类似的危 害，除非危害是直接由安全相关的电 气／电子系统的功能异常表现而 引起的。
本文件提出了安全相关的电气／电子系统进行功能安全开发的框架，该框架旨在将功能安全活动 整 合到企业特定的开发框架中 。本文件规定了为实现 产品功能安全的技术开发要求，也规定了组织具备 相应功能安全能力的开发流程要求 。
3 术语和定义
下列术语和定义适用于本文件。
架构 architecture
相关项(3.84)或要素(3.41)的结构的表征，用于识别结构模块及其边界和接口，并包括将要求分配 给结构模块。
ASIL 等级能力 ASIL capability
相关项(3.84)或要素(3.41)满足假定的、被分配了给定ASIL（3.6）等级的安全（3.132）要求的能 力。
注：作为硬件安全要求的一部分，如果需要，还包括实现分配给要素（3.41）的相应随机硬件故障度量目标值（见
GB/T 34590.5-XXXX，第8章和第9章）。
ASIL 等级分解 ASIL decomposition
为有助于实现同一安全目标(3.139)，将冗余的安全(3.132)要求分配给具有充分独立性(3.78)的要 素(3.41)，以降低分配给相关要素(3.41)的冗余的安全(3.132)要求的ASIL(3.6)等级。
注1：ASIL等级分解是设计过程中ASIL(3.6)等级剪裁方法的基础(GB/T 34590.9中定义为关于ASIL(3.6)等级剪裁的 要求分解)。
注2：根据GB/T 34590.9，ASIL等级分解不适用于随机硬件失效要求。 注3：冗余安全(3.132)要求的ASIL(3.6)等级降低也存在一些例外，如，认可措施(3.23)保持与安全目标(3.139)相
同的等级。
评估 assessment
对相关项(3.84)或要素(3.41)的特性是否实现GB/T 34590目标的检查。
审核 audit
针对过程目标对已实施过程的检查。
汽车安全完整性等级 Automotive Safety Integrity Level；ASIL
四个等级中的一个等级，用于定义相关项(3.84)或要素(3.41)需要满足的GB/T 34590中的要求和
安全措施(3.141)，以避免不合理的风险(3.176)，其中，D代表最高严格等级，A代表最低严格等级。
注：QM(3.117)不是一个ASIL等级。
可用性 availability
在定义的生命周期内，产品在给定条件下按照要求提供规定功能的能力。
基础失效率 base failure rate；BFR
在给定用例中作为安全（3.132）分析输入的硬件要素（3.41）失效率（3.53）。
基础车辆 base vehicle 在安装车辆上装设备（3.12）之前，原始设备制造商（OEM）的T&B车辆配置（3.175）。 注：车辆上装设备（3.12）可安装在包括所有驾驶相关系统（3.163）（发动机、传动系、底盘、转向、制动、驾驶
室和驾驶员信息）的基础车辆上。
示例：带有动力系统和驾驶室的卡车（3.174）底盘、带动力系统的滚动底盘。
基线 baseline
已批准的可作为变更基础的一组单一或多个工作成果（3.185）、相关项（3.84）或要素（3.41） 的版本。
注1：见GB/T 34590.8，第8章。 注2：基线通常置于配置管理之下。
注3：在生命周期（3.86）中，通过变更管理流程，基线被用作进一步开发的基础 。
车辆上装制造商 body builder；BB
将卡车（3.174）、客车（3.14）、挂车（3.171）和半挂车（3.151）（T&B）的车身、 货运工具 或设备增加到基础车辆（3.9）上的组织。
注1：T&B车身包括卡车（3.174）驾驶室、客车（3.14）车身、步入式车厢等。 注2：货运工具包括货箱、平板床、汽车运输架等。 注3：设备包括作业设备和机械，如水泥搅拌机、倾卸床、雪铲、升降机等。
车辆上装设备 body builder equipment
安装在T&B基础车辆（3.9）上的机械、车身或货运工具。
分支覆盖率 branch coverage 在测试中，已执行计算机程序的控制流分支所占的比率。 注1：100%分支覆盖率意味着100%语句覆盖率(3.160)。 注2：一个if语句总有两个分支，即条件为true和条件为false，不依赖于else语句是否存在。
客车 bus
在设计和技术特性上用于载运乘客及其随身行李的商用车辆，包括驾驶员座位在内座位数超过9座。 客车有单层的或双层的，也可牵引一挂车（3.171）。
[来源：GB/T 3730.1—2001，2.1.2.1 ]
标定数据 calibration data
在开发过程中，软件构建后将用作软件参数值的数据。
示例：参数（例如，低怠速值、发动机万有特性图）、车辆特定参数（适应值，例如，节气门限位）、变量编码（例 如，国家代码、左舵/右舵）。
注：标定数据不包含可执行代码或注释代码。
候选项 candidate
与已经发布并在运行的相关项(3.84)或要素（3.41）的定义和使用条件相同、或具有高度通用性的
相关项(3.84)或要素（3.41）。
注：该定义适用于在用证明（3.115）中使用的候选项。
级联失效 cascading failure
由一个根本原因（来自要素（3.41）内部或外部）导致某个相关项（3.84）的要素（3.41）的失效
（3.50），进而引起相同或不同相关项（3.84）的另一个要素（3.41）或多个要素（3.41）的失效（3.50）。
注：级联失效是相关失效（3.29），其可能是导致共因失效（3.18）的根本原因之一。见图2。
图2 级联失效
共因失效 common cause failure；CCF
由单一特定事件或根本原因直接导致一个相关项（3.84）中两个或多个要素（3.41）的失效(3.50)， 该事件或根本原因可来自所有这些要素(3.41)的内部或外部。
注：共因失效是非级联失效（3.17）的相关失效（3.29），见图3。
图3 共因失效
共模失效 common mode failure；CMF 多个要素(3.41)以相同方式失效的一种共因失效（3.18）。 注：以相同方式失效(3.50)并不意味着这些失效必须是完全一样的。失效模式 (3.51)接近到什么程度才能归为共
模失效，需要根据实际情况而定。
示例1：某系统(3.163)具有两个互为比较的温度传感器。如果两个温度传感器之间的温差大于或等于 5℃时，将其 作为故障（3.54）处理，系统(3.163)进入安全状态（3.131）。某个共模失效使得两个温度传感器以两者之间温差小于 5℃的形式失效，从而无法探测到。
示例2：在 CPU 锁步架构（3.1）中，两个 CPU 的输出将会进行周期性的比较，两个 CPU 需要以完全相同的方式失效 才会导致失效（3.50）不被探测到。在这种情况下，共模失效使两个 CPU 以完全相同方式失效。
示例3：由于多个元器件不符合其过电压规范而导致的过压失效（3.50）是一种共模失效。
完整车辆 complete vehicle 完全组装的具有车辆上装设备（3.12）的T&B基础车辆（3.9）。 示例：垃圾收集车、自卸卡车（3.174）。
组件 component
由一个以上硬件元器件(3.71)或一个到多个软件单元(3.159)组成的逻辑上或技术上可分的非系统 层面的要素(3.41)。
示例：微控制器。 注：组件是系统(3.163)的一部分。
配置数据 configuration data 在要素构建过程中分配的且控制要素构建过程的数据。 示例1：预处理器变量设置，用于从源代码导出出编译时间变量。 示例2：用于控制构建工具或工具链的 XML 文件。
注1：配置数据控制软件构建。配置数据用于从代码库已经定义的现有代码变量中选择代码；被选取代码变量的功能 将包含在执行代码中。
注2：由于配置数据仅仅用于选择代码变量，因此配置数据不包含相关项（3.84）使用时的执行代码和注释代码。
认可措施 confirmation measure
与功能安全(3.67)相关的认可评审(3.24)、审核(3.5)或评估(3.4)。
认可评审 confirmation review
确认工作成果（3.185）能够提供充分且具有说服力的证据，证明其促成了考虑GB/T 34590相关目 的和要求的功能安全 (3.67) 的实现。
注1：GB/T 34590.2提供了一份完整的认可评审清单。 注2：认可评审的目的是确保符合GB/T 34590。
可控性 controllability
通过所涉及人员的及时反应（可能具备外部措施(3.49)的支持）避免特定的伤害(3.74)或者损伤的 能力。
注1：所涉及人员可包括驾驶员、乘客或车辆外部的邻近人员。 注2：危害分析和风险评估(3.76)中的参数C表示可控性的可能性。
耦合系数 coupling factors
多个要素（3.41）间的共同特征或关系，这种共同特征或关系会导致这些要素失效（3.50）的相关 性。
专用措施 dedicated measure 在评估违背安全目标(3.139)的可能性的过程中，用于确保所声明的失效率(3.53)的措施。 示例：设计特性，诸如硬件元器件(3.71)过设计（例如，电应力或热应力分级）或者物理分隔（例如，印刷电路板
上的触点间隔）；对来料进行专门的抽样测试，以降低与违背安全目标(3.139)有关的失效模式(3.51)的发生风险(3.128)； 老化测试；专用的控制计划。
降级 degradation
相关项（3.84）或要素（3.41）的功能缩减、性能降低或两者均有的状态，或向该状态的过渡。
相关失效 dependent failures
不具有统计独立性的失效（3.50），即失效（3.50）组合发生的概率不等于所有考虑的独立失效（3.50） 发生概率的乘积。
注1：相关失效可以同时或在足够短的时间间隔内发生，从而产生同时失效（3.50）的影响。 注2：相关失效包括共因失效(3.18)和级联失效(3.17)。
注4：给定的失效（3.50）是级联失效（3.17）还是共因失效（3.18），可取决于要素（3.41）的时序行为。 注5：相关失效可包括软件失效（3.50），即使其失效（3.50）概率不被计算。
相关失效引发源 dependent failure initiator；DFI 通过耦合系数（3.26），导致多个要素（3.41）失效的单一根本原因。 注1：在DFA过程中，识别出作为相关性候选项的耦合系数（3.26）。 注2：要素（3.41）的失效（3.50）可以同时或有序发生。
示例1：耦合系数(3.26)：使用同一 RAM 的两个软件单元。根本原因：一个软件单元非预期地损坏了第二个软件单元 使用的数据。
示例2：耦合系数(3.26)：在车辆同一舱室内工作的两个 ECU。根本原因：不需要的/不期望的水侵入该特定的舱室 内，导致浸泡并引发两个 ECU 的失效（3.50）。
示例3：耦合系数(3.26)：使用同一 3.3V 电源的两个微控制器。根本原因：3.3V 电源的过压，损坏了两个微控制器。
可探测的故障 detected fault 在规定时间内通过安全机制（3.142）可以探测到的故障（3.54）。 注：规定的时间可以是故障探测时间间隔（3.55）或多点故障探测时间间隔（3.98）。
开发接口协议 development interface agreement；DIA
客户与供应商之间的协议，该协议规定了与相关项（3.84）或要素（3.41）开发相关的各方在待开 展的活动、待评审的证据或待交换的工作成果（3.185）方面所承担的责任。
注：DIA适用于开发阶段，而供应协议（3.162）适用于生产阶段。
诊断覆盖率 diagnostic coverage；DC
由实施的安全机制(3.142)探测或控制的失效率占硬件要素(3.41)失效率(3.53)或硬件要素(3.41) 某一失效模式(3.51)失效率(3.53)的百分比。
注1：诊断覆盖率可通过在硬件要素（3.41）中可能发生的残余故障(3.125)或潜伏的多点故障(3.97)进行评估。 注2：可考虑在架构（3.1）中不同层级实施的安全机制（3.142）。 注3：除非明确提及，否则在确定安全机制（3.142）的诊断覆盖率时，不会考虑安全相关硬件要素（3.41）的安全
故障（3.130）的比例。
诊断点 diagnostic points 要素（3.41）的输出信号，用来观察故障（3.54）的探测或校正。 注：诊断点也称为“警报”或“错误（3.46）标志”或“校正标志”。 示例：回读信息。
诊断测试时间间隔 diagnostic test time interval 安全机制(3.142)执行在线诊断测试之间的时间间隔，包括在线诊断测试的执行时间。 注：见图5。
分布式开发 distributed development
在某个相关项（3.84）或要素（3.41）开发中，分配客户和供应商在整个相关项（3.84）或要素（3.41） 的开发责任。
注：客户和供应商是合作方中的角色。
多样性 diversity 以实现独立性(3.78)为目标，满足相同要求的不同解决方案。 注1：多样性不保证独立性，但是可避免某些类型的共因失效（3.18）。
注2：多样性可以是应用的技术解决方案 （例如：多样的硬件组件 (3.21)，多样的软件组件(3.21) ）或技术手段
（例如：多样的编译器）。 注3：多样性是实现冗余（3.122）的一种方式。 示例：多样的程序；多样的硬件。
双点失效 dual-point failure 由两个独立硬件故障(3.54)的组合引起，且直接导致违背安全目标(3.139)的失效(3.50)。 注1：双点失效是2阶的多点失效(3.96)。
注2：GB/T 34590中提到的双点失效包括这些失效，即：有一个故障影响到安全相关要素(3.144)，而另一个故障影 响到相应的用来达到或保持安全状态(3.131)的安全机制(3.142)而导致的失效。
双点故障 dual-point fault 与另一个非相关故障(3.54)组合而导致双点失效（3.38）的一个故障(3.54)。 注1：一个双点故障只有在一个双点失效明确后才能被识别，例如，通过故障树的割集分析。 注2：见多点故障(3.97)。
电气/电子系统 electrical and/or electronic system ；E/E 由电气和/或电子要素（3.41），包括可编程电子要素所构成的系统（3.163） 注：电气/电子系统的一个要素(3.41)可能是另一个电气/电子系统。 示例：电源、传感器或其他输入设备、通讯路径、执行器或其他输出设备。
要素 element 系统（3.163）、组件（3.21）(硬件或软件)、硬件元器件（3.71）或软件单元（3.159）。 注1：当使用“软件要素”或“硬件要素”时，分别表示仅是软件的要素或仅是硬件的要素。 注2：要素也可以是一个独立于环境的安全要素(3.138)。
嵌入式软件 embedded software
在一个处理要素（3.113）上运行的充分集成的软件。
紧急运行 emergency operation
相关项（3.84）的一种运行模式（3.102），用于对故障（3.54）作出反应后提供安全（3.132）， 直到过渡到安全状态（3.131）。
注1：见图4和图5。 注2：在探测到故障（3.54）后，如果不能直接或及时地进入安全状态（3.131），又或安全状态（3.131）不能被保
持时，安全机制（3.142）可以将相关项（3.84）过渡到紧急运行模式以提供安全（3.132），直到过渡并保持 在安全状态（3.131）。
注3：报警和降级策略（3.183）中描述了紧急运行和相关紧急运行容错时间间隔（3.45）。 注4：降级（3.28）可以是紧急运行概念的一部分。 示例：紧急运行可以被定义为故障容错相关项（3.84）的错误（3.46）响应的一部分。
紧急运行时间间隔 emergency operation time interval；EOTI
保持紧急运行（3.43）的时间间隔。
注1：见图4和图5。 注2：报警和降级策略（3.183）中描述了紧急运行和相关紧急运行容错时间间隔（3.45）。 注3：暂时保持紧急运行（3.43）以提供安全（3.132），直到过渡到安全状态（3.131）。
紧急运行容错时间间隔 emergency operation tolerance time interval；EOTTI 在无不合理风险（3.128）的情况下，能够维持紧急运行（3.43）的特定时间间隔。 注1：见图4。
注2：紧急运行容错时间间隔是紧急运行时间间隔（3.44）的最大值。 注3：基于紧急运行容错时间间隔中规定的有限运行时间，紧急运行（3.43）能被认为是安全的。
图4 紧急运行容错时间间隔
错误 error 计算的、观测的、测量的值或条件与真实的、规定的、理论上正确的值或条件之间的差异。 注：错误可由所考虑的系统（3.163）或组件（3.21）内的故障（3.54）引起。
专业摩托车驾驶员 expert rider 由能够根据对实际摩托车（3.93）的操作评估可控性（3.25）分级的人员担任的角色。 注1：专业摩托车驾驶员要求具备：
——评估可控性的技能（3.25），包括评估的知识；
——实施摩托车试验的能力；及
——基于具有代表性的摩托车驾驶员的驾驶能力来评估摩托车（3.93）可控性（3.25）特性的知识。 注2：有关使用专业摩托车驾驶员的信息，见GB/T 34590.12-XXXX，附录C。
暴露 exposure
处于某运行场景(3.104)的状态，在该运行情况下，如果发生所分析的失效模式(3.51)，可能导致 危害。
注：危害分析和风险评估（3.76）中的参数E代表运行场景(3.104)的潜在暴露度。
外部措施 external measure
独立于且不同于相关项（3.84）的措施，以降低或减轻由相关项（3.84）导致的风险（3.128）。
失效 failure 由于故障（3.54）出现导致要素（3.41）或相关项（3.84）预期行为的终止。 注：终止可能是永久或暂时的。
失效模式 failure mode
要素（3.41）或相关项（3.84）未能提供预期行为的方式。
失效模式覆盖率 failure mode coverage；FMC
硬件要素（3.41）某一失效模式（3.51）的失效率（3.53）中被实施的安全机制探测或控制的比例。
失效率 failure rate 硬件要素（3.41）的失效（3.50）概率密度除以幸存概率（可靠度）。 注：失效率被假设为常数且通常用“λ”表示。
故障 fault 能够引起要素(3.41)或相关项(3.84)失效的异常情况。 注1：考虑永久性故障、间歇性故障和瞬态故障(3.173)（尤其是软错误）。 注2：当子系统处于错误（3.46）状态时，可能导致系统（3.163）发生故障。
注3：间歇性故障时而发生，然后又消失。这种故障可能发生在一个组件(3.21)濒临损坏时，或者例如开关内部功能 异常导致其发生。某些系统性故障(3.165)（例如时序紊乱）也可能导致间歇性故障。
故障探测时间间隔 fault detection time interval；FDTI
从故障(3.54)发生到被探测到的时间间隔。 注1：见图5。 注2：故障探测时间间隔的确定独立于诊断测试时间间隔(3.35)。
示例：由于使用了错误(3.46)计数器的原因（即：故障(3.54)必须被该诊断测试探测到多于一次，才会触发错误
(3.46)响应），某一诊断测试的故障探测时间间隔可能会长于诊断测试时间间隔(3.35)。
注3：故障探测时间间隔、诊断测试时间间隔(3.35)和故障响应时间间隔(3.59)是基于故障(3.54)探测的安全机制
(3.142)的相关特性。
注4：如果故障探测时间间隔加上故障响应时间间隔(3.59)短于相应的故障容错时间间隔(3.61)，则该故障(3.54)
可以被相应的安全机制(3.142)及时处理。
故障处理时间间隔 fault handling time interval；FHTI 故障探测时间间隔(3.55)和故障响应时间间隔(3.59)的总和。 注1：FHTI是安全机制(3.142)的一种属性。
注2：见图5。
故障注入 fault injection
评估要素(3.41)内故障(3.54)影响的方法，该方法通过注入故障(3.54)、错误(3.46)、或失效(3.50)
从而通过观测点(3.101)对注入后的响应进行观测。
注：故障注入可以在不同的抽象层面进行，包括相关项(3.84)层面或要素(3.41)层面，这取决于范围、可行性、可
观测性和所需细节的层面。取决于目的，可以在安全生命周期的不同阶段，考虑不同的故障模型(3.58)，进行 故障注入。
示例1：在运行期间注入故障(3.54)，以验证作为探测潜伏故障(3.85)策略一部分的某个安全机制(3.142)正在正常 工作。
示例2：在进行集成测试时，通过硬件调试端口或专用软件命令注入故障(3.54)来测试软硬件接口(HSI)。 示例3：在硬件组件层面对卡滞故障(3.54)或瞬态故障进行仿真，以验证安全机制(3.142)的诊断覆盖率(3.33)，或
识别出可引起错误(3.46)或失效(3.50)的故障(3.54)。
故障模型 fault model 由故障(3.54)导致的失效模式(3.51)的表现。 注：故障模型用于评估特定故障(3.54)的后果。
故障响应时间间隔 fault reaction time interval；FRTI 从探测到故障(3.54)到进入安全状态(3.131)或进入紧急运行(3.43)的时间间隔。 注：见图4和图5。
故障容错 fault tolerance 在一个或多个特定故障(3.54)存在的情况下，实现特定功能的能力。 注：特定功能可能是预期功能(3.83)。
故障容错时间间隔 fault tolerant time interval ；FTTI
在安全机制（3.142）未被激活情况下，从相关项（3.84）内部故障（3.54）发生到可能发生危害 事件（3.77）的最短时间间隔。
注1：安全相关的时间间隔见图5。 注2：该最短时间间隔是通过评估所有危害事件（3.77）得到的，其可以取决于危害（3.75）的特征。 注3：FTTI与相关项（3.84）的功能异常表现（3.88）而引起的危害（3.75）有关。FTTI是源于该危害（3.75）的安
全目标（3.139）的一个相关属性。 注4：在故障容错时间间隔内，如果相关项（3.84）保持在安全状态（3.131）或过渡到安全状态（3.131）或过渡到
紧急运行（3.43），则表明安全机制（3.142）及时对故障（3.54）进行了处理。 注5：危害事件(3.77)的发生取决于存在的故障(3.54)并且车辆处于故障(3.54)可影响车辆行为的场景中。 示例：制动系统(3.163)中的失效（3.50）在实施制动之前可能不会导致危害事件 (3.77)。 注6：虽然仅在相关项(3.84)层面定义FTTI，但在要素(3.41)层面可以定义最长故障处理时间间隔(3.56)和故障处
理后要求达到的状态，以支持功能安全概念(3.68)。
注7：当诊断测试时间间隔(3.35)比故障探测时间间隔(3.55)足够短时，故障探测时间间隔(3.55)可包括多个诊断 测试时间间隔(3.35)用于消除错误(3.46)抖动。
图5 安全相关时间间隔
现场数据 field data
从相关项(3.84)或要素(3.41)的使用中获得的数据，包含累积运行时间、所有的失效(3.50)和服务 中的安全异常(3.134)。
注：现场数据通常来自客户的使用。
形式记法 formal notation
语法和语义上完整定义的描述方法。
示例：Z 记法（Zed）、符号模型检查（NuSMV）、工程样机验证系统（PVS）、Vienna 开发方法（VDM）、数学公式。
形式验证 formal verification
基于形式记法(3.63)针对相关项(3.84)或要素（3.41）的功能或属性的定义，验证其正确性的方法。
免于干扰 freedom from interference 两个或两个以上的要素（3.41）之间，不存在可能导致违背安全（3.132）要求的级联失效(3.17)。 示例1：如果要素（3.41）2 的失效(3.50)不会导致要素（3.41）1 失效,则要素（3.41）1 免于要素（3.41）2 的干
扰。
示例2：如果要素（3.41）3 的失效导致要素（3.41）4 失效，则要素（3.41）3 干扰要素（3.41）4。
功能概念 functional concept
实现预期表现所需的各预期功能及其交互的定义。
注：功能概念是在概念阶段(3.110)开发的。
功能安全 functional safety
不存在由电气/电子系统（3.40）的功能异常表现(3.88)引起的危害(3.75)而导致不合理的风险
(3.176)。
功能安全概念 functional safety concept
为了实现安全目标(3.139)，定义功能安全要求（3.69）及相关信息，并将要求分配到架构（3.1） 中的要素（3.41）上，以及定义要素之间的必要交互。
功能安全要求 functional safety requirement
定义了独立于具体实现方式的安全（3.132）行为，或独立于具体实现方式的安全措施（3.141）， 包括安全相关的属性。
注1：功能安全要求可以是由安全相关的电气/电子系统（3.40）或基于其他技术(3.105)的安全相关系统（3.163） 所执行的安全要求，目的是通过考虑确定的危害事件（3.77），使相关项（3.84）达到或保持在安全状态（3.131）。
注2：功能安全要求的定义可独立于产品开发概念阶段（3.110）中使用的技术。 注3：安全相关的属性包括ASIL等级（3.6）信息。
硬件架构度量 hardware architectural metrics 用于评估硬件架构（3.1）安全（3.132）有效性的度量。 注：单点故障（3.156）度量和潜伏故障（3.85）度量都是硬件架构度量。
硬件元器件 hardware part 硬件组件(3.21)在第一层级分解时的一部分。 示例：微控制器的 CPU、电阻、微控制器的闪存阵列。
硬件基础子元器件 hardware elementary subpart 安全（3.132）分析中考虑的硬件子元器件（3.73）的最小部分。 示例：ALU 的触发器及其逻辑锥、寄存器。
硬件子元器件 hardware subpart 硬件元器件(3.71)中可按逻辑分割的，且代表第二层级或更高层级分解的一部分。 示例：微控制器中的 CPU 的 ALU，CPU 的寄存器组。
伤害 harm
对人身健康的物理损害或破坏。
危害 hazard 由相关项(3.84)的功能异常表现(3.88)而导致的伤害(3.74)的潜在来源。 注：该定义仅限于GB/T 34590；危害的一个更通常定义是伤害(3.74)的潜在来源。
危害分析和风险评估 hazard analysis and risk assessment；HARA
为了避免不合理的风险(3.176)，对相关项(3.84)的危害事件(3.77)进行识别和归类的方法以及定 义防止和减轻相关危害（3.75）的安全目标(3.139)和ASIL等级(3.6)的方法。
危害事件 hazardous event
危害(3.75)和运行场景(3.104)的组合。
独立性 Independence
两个或者多个要素(3.41)间不存在会导致违背安全(3.132)要求的相关失效(3.29),或从组织上分 隔执行某一活动的各方。
注：ASIL等级分解(3.3)或认可措施(3.23)包括对独立性的要求。
非相关失效 independent failures 同时或相继失效的概率可表示为无条件失效概率的简单乘积的失效（3.50）。 注：非相关失效可以包括软件失效（3.50）即使其失效概率未被计算。
非形式记法 informal notation 非完整语法定义的描述方法。 注：不完整的语法定义意指语义也没有完整的定义。
继承 inheritance
在开发过程中，某些要求的属性以一种未改变的方式传递到下一细节层面。
检查 inspection 为发现安全异常（3.134）而依据一个正式的流程对工作成果（3.185）进行的考查。 注1：检查是验证（3.180）的一种方式。 注2：检查不同于测试（3.169），检查通常不包括对相关项（3.84）或要素（3.41）的操作。
注3：一项正式的检查流程通常包括预先定义的步骤、检查列表、核对人员及对结果的评审（3.127）。
预期功能 intended functionality 针对相关项（3.84）定义的除安全机制（3.142）外的行为。 注：上述行为是在整车层面定义的。
相关项 item
适用于GB/T 34590，实现整车层面功能或部分功能的系统（3.163）或系统组合。
注：见整车功能（3.178）。
潜伏故障 latent fault
在多点故障探测时间间隔（3.98）内，未被安全机制（3.142）探测到且未被驾驶员感知到的多点 故障（3.97）。
生命周期 lifecycle
相关项(3.84)从概念到报废的全部阶段(3.110)。
管理体系 management system
一个组织用来实现其目标的政策、程序及流程。
功能异常表现 malfunctioning behaviour
失效(3.50)或与设计意图相悖的相关项(3.84)非预期表现。
最长修复时间间隔 maximum time to repair time interval 可以维持在安全状态（3.131）的特定时间间隔。 注1：当安全状态(3.131)无法保持到车辆剩余使用寿命结束时，最长待修复时间是一个相关特性。
注2：从安全状态（3.131）中恢复的条件在报警和降级策略（3.183）中进行描述。 注3：若相关，则最长待修复时间间隔在报警和降级策略（3.183）中进行描述。
基于模型的开发 model-based development；MBD 一种使用模型来描述待开发要素（3.41）行为或属性的开发。 注：根据模型使用的抽象层次，该模型可用于仿真或代码生成或二者均可。
修改 modification
以现有相关项（3.84）为基础创建新相关项（3.84）。
注：在GB/T 34590中，为剪裁生命周期（3.86）对复用的部分使用“修改”。变更用于相关项（3.84）的生命周期
（3.86）过程中，而修改用于由已有的相关项生成新的相关项（3.84）。
修改条件/判定覆盖率 modified condition/decision coverage；MC/DC 在控制流中已执行的、可以独立影响判定结果的全部单一条件结果的百分比。 注：MC/DC是一种建立在分支覆盖率（3.13）之上的代码覆盖率分析。因此，它也要求所有的代码块和所有的执行路
径都经过测试。
摩托车 motorcycle
由动力装置驱动的具有两个或三个车轮的道路车辆，其最高设计车速大于50 km/h，或满足以下条 件之一：
——若使用内燃机，其排量大于 50 ml;
——若使用电力驱动，其电机的最大连续额定功率总和大于 4 kW。
——但不包括如下类别：
——最大设计车速、整车整备质量、外廓尺寸等指标符合相关国家标准和规定的，专供残疾人驾 驶的机动轮椅车；
[来源：GB/T 5359.1—2019，2.1]
摩托车安全完整性等级 motorcycle safety integrity level；MSIL
四个等级中的一个等级，用于定义相关项(3.84)或要素(3.41)需要满足的GB/T 34590中的风险降 低要求以及转换为ASIL（3.6）等级后的安全措施（3.141），以避免摩托车特定应用的相关项（3.84） 或要素（3.41）的不合理的残余风险（3.126），D代表最高严格等级，A代表最低严格等级。
多核 multi-core
包括两个或多个能彼此独立运行的硬件处理要素（3.113）的硬件组件（3.21）。
多点失效 multiple-point failure
由几个独立的硬件故障（3.54）组合引发，直接导致违背安全目标（3.139）的失效（3.50）。
多点故障 multiple-point fault
在未被探测且未被感知到的情况下，与其他独立故障（3.54）组合可能导致一个多点失效(3.96)的 一个故障（3.54）。
注：一个多点故障仅在识别出(例如，通过故障树的割集分析)多点失效(3.96)后才能被辨认出来。
多点故障探测时间间隔 multiple-point fault detection time interval
在可导致一个多点失效（3.96）前，将多点故障（3.97）探测出来的时间间隔。
新开发 new development
开发一个具有先前未定义功能的相关项（3.84）或要素（3.41）的过程，或开发一个现有功能的新 的实现方式的过程，或两者都有。
非功能性危害 non-functional hazard
由电气/电子系统（3.40）、基于其他技术(3.105)的安全相关系统（3.163）或外部措施（3.49） 的功能异常表现（3.88）以外的因素导致的危害（3.75）。
观测点 observation points 用来观察故障（3.54）潜在影响的要素（3.41）的输出信号。 示例：存储器的输出。
运行模式 operating mode 源自相关项（3.84）或要素（3.41）的使用和应用中功能状态的一些条件。 示例：系统（3.163）关闭；系统（3.163）激活；系统（3.163）非激活；降级运行；紧急运行（3.43）；安全状态
（3.131）。
运行时间 operating time
相关项（3.84）或要素（3.41）工作（包括降级模式）的累积时间。
运行场景 operational situation 在车辆生命周期中可能发生的场景。 示例：高速行驶、斜坡驻车、维护。
其他技术 other technology
不同于GB/T 34590规定范围内的电气/电子技术的技术。
示例：机械技术、液压技术。
注：其他技术可在安全（3.132）要求（见GB/T 34590.3-XXXX和GB/T 34590.4-XXXX）分配过程中、在功能安全概念
（3.68）（见GB/T 34590.3-XXXX，第7章和图2）的定义中被考虑，或作为外部措施（3.49）被考虑。
分区 partitioning
为实现某种设计，而对功能或要素（3.41）的分隔。
注：分区可用于抑制故障（3.54）以避免级联失效（3.17）。为实现分区设计要素（3.41）间的免于干扰（3.65）， 可引入额外的非功能性要求。
乘用车 passenger car
设计和制造上主要用于载运乘客及其随身行李和/或临时物品的汽车，包括驾驶人座位在内最多不 超过9个座位。它也可以牵引一辆中置轴挂车。
[来源：GB/T 3730.1—2001，2.1.1 ]
可感知故障 perceived fault
可间接感知到的故障（3.54）（通过整车层面的异常行为）。
永久性故障 permanent fault 发生并持续直到被移除或修复的故障(3.54)。 注：直流(DC)故障(3.54),例如卡滞故障和桥接故障(3.54)是永久性故障。
阶段 phase
GB/T34590.3、GB/T34590.4、GB/T34590.5、GB/T34590.6和GB/T34590.7中定义的安全(3.132)生命
周期(3.86)的阶段。
注：GB/T34590.3、GB/T34590.4、GB/T34590.5、GB/T34590.6和GB/T34590.7分别定义了阶段：
——概念；
——系统(3.163)层面产品开发；
——硬件层面产品开发；
——软件层面产品开发；
——生产、运行、服务和报废。
失效物理学 physics of failure ；PoF 基于失效(3.50)机制研究可靠性的科学方法。 注1：PoF通常应用于计算机辅助工程(CAE)环境中的耐久性模拟。
注2：在评估新技术和设计的可靠性时，失效物理学分析可能有优势，因为不需要多年的现场失效(3.50)历史来进行 可靠性预测。
动力输出装置 power take-off；PTO 卡车(3.174)或牵引车(3.170)为操作设备提供动力源的接口。 示例：操作液压泵、真空泵、举升机、翻斗车、水泥搅拌机的接口。
处理要素 processing element ；PE
提供一系列数据处理功能的硬件元器件(3.71)，通常包括一个寄存器集、一个执行单元和一个控制 单元。
示例1：由 4 个核组成的硬件组件(3.21)可以被描述为具有 4 个处理要素。
示例2：可以将 GPU 中的流多处理器视为处理要素。
可编程逻辑器件 programmable logic device；PLD
在制造时具有未定义的电路功能，并在集成到更高级别的要素(3.41)时进行配置的硬件组件(3.21) 或硬件元器件(3.71)。
在用证明 proven in use argument
基于对候选项(3.16)应用的现场数据(3.62)的分析，证明该候选项(3.16)的任何失效(3.50)可能损 害相关项(3.84)安全目标(3.139)的可能性符合适用ASIL(3.6)等级要求的证据。
在用证明可信度 proven in use credit
通过在用证明(3.115)对一组给定的生命周期(3.86)子阶段(3.161)及相应工作成果(3.185)的替代。
质量管理 quality management；QM 用来指导和控制组织的针对质量的协调活动。 注：QM不是一个ASIL(3.6)等级，但可以在危害分析和风险评估(3.76)中定义。
随机硬件失效 random hardware failure 在硬件要素(3.41)的生命周期中,发生的服从概率分布的不可预测的失效(3.50)。 注1：可在合理的精度内预测随机硬件失效率。
注2：对于本文件准而言，失效物理学(3.111)方法论(SAE J1211、JEDEC JEP122等）定义的物理硬件失效(3.50)可 视为随机硬件失效。
随机硬件故障 random hardware fault
服从概率分布的硬件故障(3.54)
合理可预见的 reasonably foreseeable 技术上可能的、且具有可信或可测量发生率的。 注：预期的误用可以理解为合理可预见事件的子类。
重建 rebuilding 改变T&B的原始配置，以便执行不同的任务。 注：重建可以包括 T&B 车辆配置(3.175)的修改(3.91)。
冗余 redundancy
除了足以实施所需功能或足以表达信息的方法外，还存在其他方法。
注1：GB/T 34590中使用了冗余，以实现安全目标(3.139)或特定安全(3.132)要求、或者表达安全相关信息。 注2：冗余可以同质实现，也可以多样性实现。 示例1：重复的功能组件(3.21)是冗余的一个实例，其目的是增加可用性(3.7)或用于故障(3.54)探测。 示例2：对表示安全相关信息的数据增加奇偶检验位，为故障(3.54)探测提供了冗余。
回归策略 regression strategy
用于验证相关项(3.84)或要素（3.41）中一个已实施的变更不会影响到未变更的、已存在的和先前 验证过的部分或特性的策略。
再制造 remanufacturing
按照原始规范，用新的或修复后的零件对已使用一段时间的T&B车辆进行拆卸和翻修。
残余故障 residual fault
发生在硬件要素（3.41）中，可导致违背安全目标（3.139）的随机硬件故障（3.119）中未被安全 机制（3.142）覆盖的部分。
注：此处假设硬件要素（3.41）的安全机制(3.142)仅覆盖了其故障(3.54)的一部分。 示例：如果一系列与安全相关且不安全的故障(3.54)，有 60%的子集被覆盖，那么该组故障(3.54)剩余的 40%称为
残余故障。
残余风险 residual risk
实施安全措施（3.141）后剩余的风险（3.128）。
评审 review 按照评审目的，为实现预期的工作成果（3.185）目标而对工作成果（3.185）进行的检查。 注：从开发阶段（3.110）的角度看，包括验证评审（3.181）和认可评审（3.24）。
风险 risk
伤害（3.74）发生的概率及其严重度（3.154）的组合。
鲁棒性设计 robust design 在无效的输入或有压力的环境条件下，具有正确工作的能力的设计。 注：对鲁棒性可作如下理解：
——对于软件，鲁棒性是指应对异常输入和条件的能力；
——对于硬件，鲁棒性是指在设计范围和使用寿命内对环境压力的承受能力和稳定能力；及
——在GB/T 34590上下文中，鲁棒性是在边界处提供安全行为的能力。
安全故障 safe fault
不会显著增加违背安全目标（3.139）的概率的故障（3.54）。
注1：如GB/T 34590.5-XXXX附录B所示，非安全相关和安全相关要素（3.144）都可能有安全故障。 注2：单点故障（3.156）、残余故障（3.125）和双点故障(3.39)不视为安全故障。 注3：除非在安全（3.132）概念中表明具有相关性，否则，大于2阶的多点故障（3.97）可被认为是安全故障。
安全状态 safe state 相关项（3.84）在失效（3.50）的情况下，没有不合理风险（3.128）的运行模式（3.102）。 注1：见图5。
注2：虽然可将正常运行视为安全，但GB/T 34590中仅针对失效（3.50）情况定义安全状态。 示例：示例：关闭模式（对于非容错性的系统（3.163））。
安全 safety
没有不合理的风险（3.176）。
安全活动 safety activity
在安全（3.132）生命周期（3.86）的一个或多个阶段（3.110）或子阶段（3.161）进行的活动。
安全异常 safety anomaly
偏离预期并可能导致伤害（3.74）的情况。
注：安全异常可在评审（3.127）、测试（3.169）、分析、编译、组件（3.21）的使用、或适用文档的使用等过程 中被发现。
示例：偏差可以是在需求、规范、设计文档、用户文档、标准或经验方面。
安全架构 safety architecture
用来实现安全（3.132）要求的一系列要素（3.41）以及它们之间的交互。
安全档案 safety case
实现相关项（3.84）或要素（3.41）功能安全（3.67）、收集整理开发过程中安全活动的工作成果
（3.185）证据来满足功能安全（3.67）的论据。
注：安全档案可被扩展，以涵盖GB/T 34590范围外的安全（3.132）问题。
安全文化 safety culture
组织中持久的价值观、态度、动机和认知，即：在决策和行为中，安全（3.132）优先于与之冲突 的目标。
注：见 GB/T 34590.2-XXXX，附录B。
独立于环境的安全要素 safety element out of context；SEooC 不是在特定的相关项（3.84）定义下开发的安全相关要素（3.144）。 注：一个SEooC的安全要素可以是一个系统（3.163），系统（3.163）组合，一个软件组件（3.157），一个软件单
元（3.159），一个硬件组件（3.21），或一个硬件元器件（3.71）。 示例：可集成到不同 OEM 系统（3.163）中的基于假设安全要求的通用雨刮系统（3.163）。
安全目标 safety goal 作为整车层面危害分析和风险评估（3.76）结果的最高层面的安全（3.132）要求。 注：一个安全目标可能与几种危害（3.75）有关，几个安全目标可能与一种单一的危害（3.75）有关。
安全经理 safety manager 对实现功能安全（3.67）所必需的活动，负责监督和确保其开展的人员或组织。 注：在相关项（3.84）开发的不同层面，每个涉及的公司可按照内部矩阵组织对任务的划分，指派一个或多个不同
人员。
安全措施 safety measure
用来避免或控制系统性失效(3.164)，探测或控制随机硬件失效(3.118)，或减轻它们有害影响的活 动或技术解决方案。
注：安全措施包括安全机制(3.142)。 示例：FMEA 或未使用全局变量的软件。
安全机制 safety mechanism
为了保持预期功能(3.83)或者达到/保持某种安全状态，由电气/电子系统的功能/要素(3.41)或者
其他技术(3.105)来实施的技术解决方案，以探测并减轻/容许故障(3.54)、或者控制/避免失效(3.50)。
注1：在相关项(3.84)中实施安全机制以避免故障(3.54)导致单点失效(3.155)和防止故障(3.54)成为潜伏故障
(3.85)。
注2：安全机制也可是：
a) 能够使相关项(3.84)过渡到或保持在安全状态(3.131)；或
b) 如同在功能安全概念(3.68)中定义的，能够向驾驶员发出提醒以控制失效(3.50)的影响。
安全计划 safety plan
管理和指导开展项目安全活动(3.133)的计划，包括日期、里程碑节点、任务、可交付成果、职责 和资源。
安全相关要素 safety-related element
有潜在可能导致违背安全目标或有助于实现安全目标(3.139)的要素(3.41)。
注：如果失效-安全要素(3.41)可能违背至少一个安全目标，那么该失效-安全要素被认为是与安全相关的。
安全相关功能 safety-related function
有潜在可能导致违背安全目标或有助于实现安全目标(3.139)的功能。
安全相关事件 safety-related incident
安全相关失效（3.50）的发生。
安全相关的特殊特性 safety-related special characteristic
相关项（3.84）、要素（3.41）自身或其生产过程的特性，这些特性的合理可预见偏差可能影响、 促使或造成任何潜在的功能安全（3.67）降低。
注1：GB/T 18305中定义了特殊特性的术语。 注2：安全相关的特殊特性在相关项（3.84）或要素（3.41）的开发阶段（3.110）中得出。 注3：安全相关的特殊特性不同于安全机制，也不宜和安全机制（3.142）混淆。 示例：温度范围、有效期限、紧固力矩、生产公差、配置。
安全确认 safety validation
基于检查和测试，确保安全目标 (3.139) 是充分的，并已达到且具有足够的完整性等级。
注：GB/T 34590.4-XXXX提供了合适的安全确认方法。
半形式记法 semi-formal notation 语法定义是完整的，但语义定义可以是不完整的描述方法。 示例：结构化分析与设计技术（SADT）、统一建模语言（UML）。
半形式验证 semi-formal verification 基于半形式记法（3.149）的验证(3.180)。 示例：使用由半形式模型生成的测试向量来测试系统（3.163）表现与模型是否匹配。
半挂车 semi-trailer
设计为通过连接到牵引车（3.170）上的主销（对牵引车辆施加了很大的垂直载荷）而被牵引的挂 车（3.171）。
量产道路车辆 series production road vehicle 旨在用于公共道路且不是原型机的道路车辆。 注：车辆类型分类可能因地区而异。 示例1：普通消费者使用车辆。
示例2：公共用途车辆。
服务说明 service note 在执行相关项(3.84)的维护流程时所考虑的安全(3.132)信息文档。 示例：安全相关的特殊特性（3.147）；所需的安全（3.132）操作。
严重度 severity 对潜在危害事件（3.77）中可能发生的一个或多个人员的伤害（3.74）程度的预估。 注：在危害分析和风险评估（3.7）中参数“S”代表伤害的潜在严重程度。
单点失效 single-point failure
由单点故障(3.156)引起的失效(3.50)。
单点故障 single-point fault
要素(3.41)中直接导致违背安全目标(3.139)的硬件故障(3.54)，且该要素(3.41)中的故障(3.54)
未被任何安全机制(3.142)覆盖。
注1：见单点失效(3.155)。 注2：如果为一个硬件要素(3.41)定义了至少一个安全机制(3.142)(例如，微控制器的看门狗)，那么，该硬件要素
(3.41)的故障(3.54)均不是单点故障。
软件组件 software component
一个或多个软件单元(3.159)。
软件工具 software tool
在开发相关项(3.84)或要素(3.41)中所用到的计算机程序。
软件单元 software unit
软件架构(3.1)中的最低层级且可被独立测试(3.169)的软件组件(3.157)。
语句覆盖率 statement coverage
软件中已执行语句所占的百分比。
子阶段 subphase
GB/T 34590章节中定义的、安全(3.132)生命周期(3.86)中阶段（3.110）的细分。
示例：危害分析和风险评估(3.76)是安全(3.132)生命周期(3.96)的子阶段，在 GB/T 34590.3-XXXX 第 6 章中进行 了定义。
供应协议 supply agreement
客户和供应商之间的协议，其中规定了各项活动的责任划分，以及各方要执行或交换的与相关项
（3.84）和要素（3.41）生产相关的证据或工作成果（3.185）。
注：DIA适用于开发阶段，供应协议适用于生产。
系统 system 一组至少与一个传感器、一个控制器和一个执行器相关联的组件(3.21)或子系统。 注：相关的传感器或执行器可包含在系统中，也可存在于系统之外。
系统性失效 systematic failure
以确定的方式与某个原因相关的失效(3.50)，只有对设计或生产流程、操作规程、文档或其他相关 因素进行变更后才可能排除这种失效。
系统性故障 systematic fault
以确定的方式显现失效(3.50)的故障(3.54)，只有通过流程或设计措施的应用才能防止其发生。
目标环境 target environment
用于执行特定软件的环境。
注：对于应用软件，其目标环境是带有基础软件和操作系统的微控制器。对于嵌入式软件（3.42），其目标环境是 系统（3.163）中的ECU。
技术安全概念 technical safety concept
技术安全要求（3.168）的定义，技术安全要求（3.168）在系统（3.163）要素（3.41）间的分配， 以及为系统（3.163）层面功能安全（3.67）提供依据的相关信息。
技术安全要求 technical safety requirement 为实现相关的功能安全要求（3.69）而得出的要求。 注：得出的要求包括减轻危害所需的要求。
测试 testing
为验证相关项（3.84）或要素（3.41）满足定义的要求、探测其安全异常（3.134）、确认要求适 用于给定的环境和对其行为建立信心，而进行计划、准备、运行或演练的过程。
牵引车 tractor
用来牵引半挂车（3.151）的卡车（3.174）。
挂车 trailer 设计上需被牵引且总质量的大部分不由牵引车辆承担的道路车辆。 注：挂车可设计用于运输货物、设备或人员。
转换器 transducer
瞬态故障 transient fault
发生一次且随后消失的故障(3.54)。
注：瞬态故障可由电磁干扰引起，其可导致位翻转。软错误(3.46)，如单粒子翻转 (SEU)和单粒子瞬态(SET)，均为 瞬态故障。
卡车 truck 设计用于运输货物或在底盘上装有设备的机动车。 注：卡车也可以牵引一辆挂车(3.171)。
T&B 车辆配置 T&B vehicle configuration T&B的基础车辆（3.9）和车辆上装设备（3.12）的技术特性，这些特性在运行期间不会发生改变。 注：在重建（3.121）时可能发生改变。 示例：轴距，轴荷分布，车轮（车轴数量、驱动轴数量、转向轴数量）。
不合理的风险 unreasonable risk
按照现行的安全观念，被判断为在某种环境下不可接受的风险（3.128）。
T&B 车辆使用的变化 variance in T&B vehicle operation 在车辆寿命期内受货物或牵引的影响，使用的T&B车辆具有不同的动态特性。 示例：有载荷或无载荷的 T＆B，载荷分布变化的 T＆B，带或不带挂车（3.171）的卡车（3.174），带或不带半挂车
（3.151）的牵引车（3.170）（单独的牵引车（3.170））。
整车功能 vehicle function 用户可观察到的、预期通过一个或多个相关项（3.84）来实现的车辆行为。 示例：“自动巡航控制”是一种可以使用不同的 ECU 和各种传感器技术（例如雷达、激光雷达、摄像头）实现的车
辆功能。
车辆运行状态 vehicle operating state
与运行场景（3.104）结合的运行模式（3.102）。
注：车辆的运行状态是由当前行驶情况下(例如以120km/h行驶在高速公路上)特定功能(例如高度自动驾驶)提供的 性能所决定的。危害事件（3.77）的ASIL（3.6）等级（例如特定功能的突然丧失）取决于当前的车辆运行状态
（例如高度自动驾驶能力的突然丧失，在高速行驶时就比在低速行驶时更为危险）。如果系统（3.163）不在运 行中，即当驾驶员在操控车辆时系统（3.163）发生失效，则在高速情况下突然丧失高度自动驾驶能力并不是问 题。
验证 verification 确定检查对象是否满足其特定要求。 示例：示例：典型的验证活动可以分为以下几类：
——验证评审（3.181），走查（3.182），检查（3.82）；
——验证测试（3.169）；
——仿真模拟；
——原型样机；及
——分析（安全（3.132）分析、控制流分析、数据流分析等）。
验证评审 verification review 确保开发活动结果满足项目要求和/或技术要求的验证（3.180）活动。 注1：验证评审的单独要求在GB/T 34590的单独部分中的特定章条中给出。
注2：验证评审的目标是确认相关项（3.84）或要素（3.41）的技术正确性和完整性。 示例：验证评审类型可以是技术评审（3.127）、走查（3.182）、检查（3.82）。
走查 walk-through 为了发现安全异常（3.134），对工作成果（3.185）的系统性检查。 注1：走查是验证（3.180）的一种方法。 注2：走查和测试（3.169）的区别在于，走查通常不涉及相关项（3.84）或要素（3.41）的运行。
注3：被发现的任何异常通常通过重做来处理，并对重做的工作成果（3.185）进行走查。 示例：在走查过程中，开发者向一个或多个评审员逐步的阐述工作成果（3.185）。其目的是建立对工作成果的共同
理解和识别工作成果（3.185）中的任何安全异常（3.134）。检查（3.82）和走查均属于同级评审（3.127），其中走查 的严格性弱于检查（3.82）。
报警和降级策略 warning and degradation strategy 如何将潜在降低的功能向驾驶员报警及如何提供降低的功能以达到安全状态（3.131）的定义。 注：报警和降级策略包括：
——触觉、声音或视觉提示的说明，以提醒驾驶员即将发生的降级（3.28）；
——与相应的安全目标（3.139）相关的一个或多个安全状态（3.131）的描述；
——向安全状态（3.131）过渡的条件；
——从安全状态（3.131）恢复的条件，以及如果适用，相应的最长待修复时间间隔（3.89）；及
——如果适用，紧急运行（3.43）和相应的紧急运行容错时间间隔（3.45）；
值得信赖的 well-trusted 此前在类似的应用中使用过，且没有已知的安全异常（3.134）。 示例：值得信赖的设计原则、值得信赖的工具、值得信赖的硬件组件（3.21）。
工作成果 work product
由GB/T 34590中一个或多个相关要求得出的文档。
注：文档可以是包含工作成果完整信息的单个文档，也可以是包含工作成果完整信息的一系列文档。
预期功能安全 safety of the intended functionality；SOTIF
不存在由预期功能的不足引起的危害而导致不合理的风险。
接受准则 acceptance criteria
表征不存在不合理风险水平的准则。
注：接受准则包括两个层面，即危害行为事件接受准则和总体安全风险接受准则。接受准则可以是定性的，也可以 是定量的，例如物理参数，即当某特定行为被视为危害行为时，表征该危害行为的参数值，或每小时的最大数，
或最低合理可行（ALARP）原则等。
示例：根据交通统计数据得出每 Xkm 发生一次事故的合理风险水平。
安全度量 safety metric
为符合安全目标而给定的具体技术参数的量化值（安全度量并非ASIL等级）。
现成译文，到款即发。
任取样页验证译文质量。
提供正规增值税电子发票。
请联系手机/微信: 133-0649-6964/Email: standardtrans@foxmail.com 购买完整译文。
专业源于专注|ChinaAutoRegs 始终专注于汽车标准翻译领域！迄今为止已翻译上千个国内外汽车标准法规！独家打造千万级汽车专业术语库和记忆库。
Note:
This document in English is readily available, and delivered immediately upon payment.
You may request for sample pages to your preference to verify the quality of translation.
Please contact standardtrans@foxmail.com for the complete PDF in English.