芯耀
65
文字过多,建议收藏,欢迎点赞和转发哈
一、标准核心定位与基 本信息
1. 标准身份与权威性
核心属性
-
- GB/T 34590《道路车辆 功能安全》系列的第 1 部分，是整个功能安全体系的 “语言基础”，界定全系列标准通用的术语、定义及缩略语。
替代关系
-
- 2022 年 12 月 30 日发布，2023 年 7 月 1 日实施，全面替代 GB/T 34590.1-2017，技术上修改采用 ISO 26262-1:2018（MOD），适配中国道路车辆场景。
归口与起草
-
- 由全国汽车标准化技术委员会（SAC/TC 114）归口，中汽研、上汽大众、蔚来等 40 余家车企、零部件商及科技公司联合起草，覆盖全产业链视角，确保实用性与权威性。
2. 适用范围与边界
适用对象
安装在除轻便摩托车外的量产道路车辆（含乘用车、客车、载货汽车、专用汽车等）上，包含一个及以上电气 / 电子系统的安全相关系统。
排除场景
-
- 特殊用途车辆的特定电气 / 电子系统（如残疾驾驶者专用车辆系统）；本标准发布前已量产或正开发的系统（变更时需裁剪安全生命周期活动）。
核心聚焦
-
- 仅针对 “电气 / 电子系统功能异常” 引发的危害，不涵盖触电、火灾、毒性等非功能异常直接导致的危害。
二、核心技术变化（相较于 2017 版）
1. 适用范围的关键扩展
- 从 “量产乘用车” 扩展至 “除轻便摩托车外的量产道路车辆”，顺应商用车、专用车等车型的功能安全需求，覆盖更多道路交通参与者安全。
2. 术语体系的全面优化
修改 92 个术语
-
- 包括架构、ASIL 等级分解、共因失效、功能安全概念等核心术语，使其定义更精准、适配技术发展（如嵌入式软件、基于模型的开发等术语的细化）。
新增 51 个术语
-
- 填补新技术、新场景空白，如 ASIL 等级能力、多核、故障注入、摩托车安全完整性等级（MSIL）、专用汽车等，适配自动驾驶、多核硬件、摩托车专项安全等需求。
删除 6 个术语
- 移除分配、同构冗余、特殊用途车辆等不再适用的表述，精简术语体系。
3. 缩略语的动态调整
4. 与相关国标的一致性衔接
- 客车、半挂车、载货汽车等术语定义与 GB/T 3730.1-2022（车辆分类）保持一致；摩托车定义与 GB/T 5359.1-2019 对齐；替换 ISO 26262 系列引用为对应的 GB/T 34590 系列标准，形成本土化标准闭环
三、术语与解读（1-100）
3.1 架构（architecture）
英文
-
- architecture
原定义
-
- 相关项 (3.84) 或要素 (3.41) 的结构的表征，用于识别结构模块及其边界和接口，并包括将要求分配给结构模块。
解读
- 核心是 “结构表征 + 要求分配”，需明确相关项 / 要素的模块边界、接口，同时将安全及功能要求分配到各模块。比如自动驾驶域控制器的架构，要划分感知、决策、执行模块，明确模块间数据交互接口，并将 “故障探测” 要求分配给感知模块。
3.2 ASIL 等级能力（ASIL capability）
英文：ASIL capability
原定义
-
- 相关项 (3.84) 或要素 (3.41) 满足假定的、被分配了给定 ASIL (3.6) 等级的安全 (3.132) 要求的能力。注：作为硬件安全要求的一部分，如果需要，还包括实现分配给要素 (3.41) 的相应随机硬件故障度量目标值 (见 GB/T34590.5-2022 的第 8 章和第 9 章)。
解读
- 指相关项 / 要素满足特定 ASIL 等级安全要求的能力，硬件层面还需包含随机硬件故障度量目标的实现能力（如 GB/T 34590.5 要求的失效率指标）。例如某传感器需具备 ASIL B 等级能力，意味着其设计、测试需满足 ASIL B 的严苛要求，且硬件故障度量达标。
3.3 ASIL 等级分解（ASIL decomposition）
英文：ASIL decomposition
原定义
-
- 为有助于实现同一安全目标 (3.139)，将冗余的安全 (3.132) 要求分配给具有充分独立性 (3.78) 的要素 (3.41)，以降低分配给相关要素 (3.41) 的冗余的安全 (3.132) 要求的 ASIL (3.6) 等级。注 1:ASIL 等级分解是设计过程中 ASIL (3.6) 等级剪裁方法的基础 [GB/T34590.9-2022 中定义为关于 ASIL (3.6) 等级剪裁的要求分解]。注 2: 根据 GB/T 34590.9-2022，ASIL 等级分解不适用于随机硬件失效要求。注 3: 冗余安全 (3.132) 要求的 ASIL (3.6) 等级降低也存在一些例外，如，认可措施 (3.23) 保持与安全目标 (3.139) 相同的等级。
解读
- 核心是 “冗余 + 独立性”，为实现同一安全目标，将高 ASIL 等级的冗余要求分配给多个独立要素，降低单个要素的 ASIL 等级。需满足充分独立性，且不适用于随机硬件失效要求；认可措施需保持原 ASIL 等级。例如 ASIL D 要求可分解为两个独立的 ASIL B 要素，降低开发难度。
3.4 评估（assessment）
英文：assessment
原定义
-
- 对相关项 (3.84) 或要素 (3.41) 的特性是否实现 GB/T 34590 目标的检查。
解读
- 对相关项 / 要素是否达成 GB/T 34590 目标的检查，聚焦 “结果达标性”。比如评估某 ECU 的诊断覆盖率是否满足设计目标，属于评估活动。
3.5 审核（audit）
英文：audit
原定义
-
- 针对过程目标对已实施过程的检查。
解读
- 针对 “过程目标” 的检查，关注开发、生产等过程是否符合预设流程。例如审核功能安全开发流程是否按 GB/T 34590.2 要求执行，属于审核活动。
3.6 汽车安全完整性等级（automotive safety integrity level；ASIL）
英文：automotive safety integrity level；ASIL
原定义
-
- 四个等级中的一个等级，用于定义相关项 (3.84) 或要素 (3.41) 需要满足的 GB/T 34590 的要求和安全措施 (3.141)，以避免不合理的风险 (3.176)，其中，D 代表最高严格等级，A 代表最低严格等级。注：QM (3.117) 不是一个 ASIL 等级。
解读
- 4 级安全等级（A 最低→D 最高），定义安全要求和措施的严苛程度，核心是 “风险导向”，避免不合理残余风险。QM（质量管理）不属于 ASIL 等级。例如制动系统通常需 ASIL D，而车窗控制功能可能仅需 QM。
3.7 可用性（availability）
英文：availability
原定义
-
- 在定义的生命周期内，产品在给定条件下按照要求提供规定功能的能力。
解读
- 生命周期内，产品在给定条件下按要求提供功能的能力，强调 “持续满足功能”。例如某车载雷达在 - 40℃~85℃环境下，99.9% 的时间能正常输出探测数据，体现其可用性。
3.8 基础失效率（base failure rate；BFR）
英文：base failure rate；BFR
原定义
-
- 在给定用例中作为安全 (3.132) 分析输入的硬件要素 (3.41) 的失效率 (3.53)。
解读
- 安全分析的输入参数，指特定用例下硬件要素的失效率基准值。例如在安全分析中，假设某电阻的 BFR 为 10⁻⁶/ 小时，作为风险评估的基础数据。
3.9 基础车辆（base vehicle）
英文：base vehicle
原定义
-
- 在安装车辆上装设备 (3.12) 之前，原始设备制造商 (OEM) 的 T&B 车辆配置 (3.175)。注：车辆上装设备 (3.12) 可安装在包括所有驾驶相关系统 (3.163)（发动机、传动系、底盘、转向、制动、驾驶室和驾驶员信息）的基础车辆上。示例：带有动力系统和驾驶室的载货汽车 (3.174) 底盘、带动力系统的滚动底盘。
解读
- 安装车辆上装设备前的 OEM T&B 车辆配置，包含发动机、底盘、制动等核心驾驶系统。示例：带动力系统的载货汽车底盘、滚动底盘。
3.10 基线（baseline）
英文：baseline
原定义
-
- 已批准的可作为变更基础的一组单一或多个工作成果 (3.185)、相关项 (3.84) 或要素 (3.41) 的版本。注 1: 见 GB/T 34590.8-2022 的第 8 章。注 2: 基线通常置于配置管理之下。注 3: 在生命周期 (3.86) 中，通过变更管理流程，基线被用作进一步开发的基础。
解读
- 已批准的工作成果 / 相关项 / 要素版本，是变更的基础，需纳入配置管理。例如某阶段的软件代码版本、系统设计方案，批准后作为基线，后续变更需基于此开展。
3.11 车辆上装制造商（body builder；BB）
英文：body builder；BB
原定义
-
- 将载货汽车 (3.174)、客车 (3.14)、专用汽车 (3.186)、挂车 (3.171)（T&B） 的车身、货运工具或设备增加到基础车辆 (3.9) 上的组织。注 1:T&B 车身包括载货汽车 (3.174) 驾驶室、客车 (3.14) 车身、步入式车厢等。注 2: 货运工具包括货箱、平板床、汽车运输架等。注 3: 设备包括作业设备和机械，如水泥搅拌机、倾卸床、雪铲、升降机等。
解读
- 为基础车辆加装车身、货运工具或作业设备的组织，涵盖客车车身、水泥搅拌机、雪铲等设备加装。例如为载货汽车底盘加装垃圾收集车厢的企业，属于车辆上装制造商。
3.12 车辆上装设备（body builder equipment）
英文：body builder equipment
原定义
-
- 安装在 T&B 基础车辆 (3.9) 上的机械、车身或货运工具。
解读
- 安装在基础车辆上的机械、车身或货运工具，是基础车辆的附加部分。示例：货箱、平板床、步入式车厢。
3.13 分支覆盖率（branch coverage）
英文：branch coverage
原定义
-
- 在测试中，已执行计算机程序的控制流分支所占的比率。注 1:100% 分支覆盖率意味着 100% 语句覆盖率 (3.160)。注 2: 一个 if 语句总有两个分支，即条件为 true 和条件为 false，不依赖于 else 语句是否存在。
解读
- 软件测试中已执行的控制流分支占比，100% 分支覆盖率意味着 100% 语句覆盖率。需注意 if 语句默认包含 true/false 两个分支，无论是否有 else 语句。例如某代码含 “if (a>0)”，需测试 a>0 和 a≤0 两种情况，才算覆盖该分支。
3.14 客车（bus）
英文：bus
原定义
-
- 设计、制造和技术特性上用于载运乘客及其随身行李，包括驾驶员座位在内的座位数超过 9 个的汽车。注：客车可能牵引挂车 (3.171)。[来源：GB/T 3730.1-2022，3.3.2]
解读
- 设计用于载运乘客及随身行李，含驾驶员座位在内座位数 > 9 个，可牵引挂车，与 GB/T 3730.1-2022 定义一致。
3.15 标定数据（calibration data）
英文：calibration data
原定义
-
- 在开发过程中，软件构建后将用作软件参数值的数据。示例：参数（例如，低怠速值、发动机万有特性图）、车辆特定参数（适应值，例如节气门限位）、变量编码（例如，国家代码、左舵 / 右舵）注：标定数据不包含可执行代码或注释代码。
解读
- 软件构建后使用的参数值，不包含可执行代码或注释代码。示例：发动机低怠速值、国家代码、左舵 / 右舵适配值。
3.16 候选项（candidate）
英文：candidate
原定义
-
- 与已经发布并在运行的相关项 (3.84) 或要素 (3.41) 的定义和使用条件相同，或具有高度通用性的相关项 (3.84) 或要素 (3.41)。注：该定义适用于在用证明 (3.115) 中使用的候选项。
解读
- 与已运行相关项 / 要素定义、使用条件一致或高度通用的对象，用于 “在用证明”。例如某成熟的车载 ECU，可作为新车型同类 ECU 的候选项，通过在用证明简化验证。
3.17 级联失效（cascading failure）
英文：cascading failure
原定义
-
- 由一个根本原因 [来自要素 (3.41) 内部或外部] 导致某个相关项 (3.84) 的要素 (3.41) 的失效 (3.50)，进而引起相同或不同相关项 (3.84) 的另一个要素 (3.41) 或多个要素 (3.41) 的失效 (3.50)。注：级联失效是相关失效 (3.29)，其可能是导致共因失效 (3.18) 的根本原因之一，见图 2。
解读
- 由单一根本原因引发的连锁失效，属于相关失效，可能导致共因失效。示例：传感器故障（根本原因）导致控制器误判，进而引发执行器错误动作，形成 “传感器→控制器→执行器” 的级联失效。
3.18 共因失效（common cause failure；CCF）
英文：common cause failure；CCF
原定义
-
- 由单一特定事件或根本原因直接导致一个相关项 (3.84) 中两个或多个要素 (3.41) 的失效 (3.50)，该事件或根本原因可来自所有这些要素 (3.41) 的内部或外部。注：共因失效是非级联失效 (3.17) 的相关失效 (3.29)，见图 3。
解读
- 单一事件 / 根本原因直接导致两个及以上要素失效，原因可来自要素内部或外部，是非级联的相关失效。示例：同一电源过压（根本原因）导致多个 ECU 同时损坏。
3.19 共模失效（common mode failure；CMF）
英文：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) 是一种共模失效。
解读
- 多个要素以相同方式失效的共因失效，失效模式接近即可，无需完全一致。示例：两个温度传感器因共模失效，温差始终 < 5℃，导致系统无法探测故障；CPU 锁步架构中两 CPU 完全相同方式失效。
3.20 完整车辆（complete vehicle）
英文：complete vehicle
原定义
-
- 完全组装的具有车辆上装设备 (3.12) 的 T&B 基础车辆 (3.9)。示例：垃圾收集车、自卸载货汽车 (3.174)。
解读
- 加装车辆上装设备后的完整 T&B 车辆。示例：垃圾收集车、自卸载货汽车。
3.21 组件（component）
英文：component
原定义
-
- 由一个以上硬件元器件 (3.71) 或一个到多个软件单元 (3.159) 组成的逻辑上或技术上可分的非系统层面的要素 (3.41)。示例：微控制器。注：组件是系统 (3.163) 的一部分。
解读
- 由多个硬件元器件或软件单元组成的非系统层面要素，逻辑 / 技术上可分割。示例：微控制器、雷达传感器模块。
3.22 配置数据（configuration data）
英文：configuration data
原定义
解读
- 控制要素构建过程的数据，用于选择代码变量（不包含执行代码）。示例：预处理器变量设置、控制工具链的 XML 文件。
3.23 认可措施（confirmation measure）
英文：confirmation measure
原定义
-
- 与功能安全 (3.67) 相关的认可评审 (3.24)、审核 (3.5) 或评估 (3.4)。
解读
- 与功能安全相关的认可评审、审核或评估，是验证标准符合性的关键手段。
3.24 认可评审（confirmation review）
英文：confirmation review
原定义
-
- 确认工作成果 (3.185) 能够提供充分且具有说服力的证据，证明其促成了考虑 GB/T 34590 相关目的和要求的功能安全 (3.67) 的实现。注 1:GB/T 34590.2-2022 提供了一份完整的认可评审清单。注 2: 认可评审的目的是确保符合 GB/T 34590。
解读
- 确认工作成果能提供充分证据，证明满足 GB/T 34590 功能安全要求，GB/T 34590.2 有完整评审清单。例如对软件安全测试报告的认可评审，确保测试满足要求。
3.25 可控性（controllability）
英文：controllability
原定义
-
- 通过所涉及人员的及时反应 [可能具备外部措施 (3.49) 的支持] 避免特定的伤害 (3.74) 或者损伤的能力。注 1: 所涉及人员可包括驾驶员、乘客或车辆外部的邻近人员。注 2: 危害分析和风险评估 (3.76) 中的参数 C 表示可控性的可能性。
解读
- 通过人员及时反应（可结合外部措施）避免伤害的能力，涉及驾驶员、乘客及道路邻近人员。危害分析和风险评估中用参数 C 表示，例如高速行驶中车辆跑偏的可控性低于低速场景。
3.26 耦合系数（coupling factors）
英文：coupling factors
原定义
-
- 多个要素 (3.41) 间的共同特征或关系，这种共同特征或关系会导致这些要素失效 (3.50) 的相关性。
解读
- 多个要素间导致失效相关性的共同特征 / 关系，是相关失效的关键影响因素。示例：使用同一 RAM 的两个软件单元、同一舱室的两个 ECU。
3.27 专用措施（dedicated measure）
英文：dedicated measure
原定义
-
- 在评估违背安全目标 (3.139) 的可能性的过程中，用于确保所声明的失效率 (3.53) 的措施。示例：设计特性，诸如硬件元器件 (3.71) 过设计（例如，电应力或热应力分级）或者物理分隔（例如，印刷电路板上的触点间隔）；对来料进行专门的抽样测试，以降低与违背安全目标 (3.139) 有关的失效模式 (3.51) 的发生风险 (3.128)；老化测试；专用的控制计划。
解读
- 确保声明失效率的措施，用于降低违背安全目标的风险。示例：硬件过设计（电应力分级）、物理分隔（PCB 触点间隔）、来料抽样测试、老化测试。
3.28 降级（degradation）
英文：degradation
原定义
-
- 相关项 (3.84) 或要素 (3.41) 的功能缩减、性能降低或两者均有的状态，或向该状态的过渡。
解读
- 相关项 / 要素的功能缩减、性能降低，或向该状态的过渡。例如自动驾驶系统探测到传感器故障后，从 L3 级降级为 L2 级，属于降级运行。
3.29 相关失效（dependent failures）
英文:dependent failures
原定义
-
- 不具有统计独立性的失效 (3.50)，即失效 (3.50) 组合发生的概率不等于所有考虑的独立失效 (3.50) 发生概率的乘积。注 1: 相关失效可以同时或在足够短的时间间隔内发生，从而产生同时失效 (3.50) 的影响。注 2: 相关失效包括共因失效 (3.18) 和级联失效 (3.17)。注 3: 给定的失效 (3.50) 是级联失效 (3.17) 还是共因失效 (3.18)，可取决于要素 (3.41) 的层次结构。注 4: 给定的失效 (3.50) 是级联失效 (3.17) 还是共因失效 (3.18)，可取决于要素 (3.41) 的时序行为。注 5: 相关失效可包括软件失效 (3.50)，即使其失效 (3.50) 概率不被计算。
解读
- 不满足统计独立性的失效，组合概率≠独立概率乘积，包括共因失效和级联失效，可同时或短时间内发生。软件失效即使未计算概率，也可能属于相关失效。
3.30 相关失效引发源（dependent failure initiator；DFI）
英文: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.3 V 电源的两个微控制器。根本原因：3.3 V 电源的过压，损坏了两个微控制器。
解读
- 通过耦合系数导致多个要素失效的单一根本原因。示例：软件单元损坏共享 RAM 的数据、水侵入导致同一舱室 ECU 失效、电源过压损坏多个微控制器。
3.31 可探测的故障（detected fault）
英文：detected fault
原定义
-
- 在规定时间内通过安全机制 (3.142) 可以探测到的故障 (3.54)。注：规定的时间可以是故障探测时间间隔 (3.55) 或多点故障探测时间间隔 (3.98)。
解读
- 规定时间内可通过安全机制探测到的故障，规定时间可为故障探测时间间隔或多点故障探测时间间隔。例如通过看门狗机制探测到的 CPU 死机故障。
3.32 开发接口协议（development interface agreement；DIA）
英文：development interface agreement；DIA
原定义
-
- 客户与供应商之间的协议，该协议规定了与相关项 (3.84) 或要素 (3.41) 开发相关的各方在待开展的活动、待评审的证据或待交换的工作成果 (3.185) 方面所承担的责任。注：DIA 适用于开发阶段，而供应协议 (3.162) 适用于生产阶段。
解读
- 客户与供应商间约定开发阶段责任的协议，明确活动、证据及工作成果交换要求，与生产阶段的供应协议区分。
3.33 诊断覆盖率（diagnostic coverage；DC）
英文：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) 的比例。
解读
- 安全机制探测 / 控制的失效率占比，核心是 “故障探测能力量化”，可通过残余故障或潜伏多点故障评估，不考虑安全故障比例。例如某系统 DC=95%，表示 95% 的失效率可被探测 / 控制。
3.34 诊断点（diagnostic points）
英文：diagnostic points
原定义
-
- 要素 (3.41) 的输出信号，用来观察故障 (3.54) 的探测或校正。注：诊断点也称为 “警报”“错误 (3.46) 标志” 或 “校正标志”。示例：回读信息。
解读
- 要素的输出信号，用于观察故障探测或校正，又称 “警报”“错误标志”。示例：传感器回读信息、ECU 状态反馈信号。
3.35 诊断测试时间间隔（diagnostic test time interval）
英文：diagnostic test time interval
原定义
-
- 安全机制 (3.142) 执行在线诊断测试之间的时间间隔，包括在线诊断测试的执行时间。注：见图 5。
解读
- 安全机制执行在线诊断测试的时间间隔，包含测试执行时间，需结合图 5 理解时序关系。
3.36 分布式开发（distributed development）
英文：distributed development
原定义
-
- 在某个相关项 (3.84) 或要素 (3.41) 开发中，分配客户和供应商在整个相关项 (3.84) 或要素 (3.41) 的开发责任。注：客户和供应商是合作方中的角色。
解读
- 客户与供应商共同承担相关项 / 要素的开发责任，明确合作方角色分工。例如车企与供应商联合开发自动驾驶系统，属于分布式开发。
3.37 多样性（diversity）
英文：diversity
原定义
-
- 以实现独立性 (3.78) 为目标，满足相同要求的不同解决方案。注 1: 多样性不保证独立性，但是可避免某些类型的共因失效 (3.18)。注 2: 多样性可以是应用的技术解决方案（例如：多样的硬件组件 (3.21)、多样的软件组件 (3.21)）或技术手段（例如：多样的编译器）。注 3: 多样性是实现冗余 (3.122) 的一种方式。示例：多样的程序、多样的硬件。
解读
- 实现独立性的不同解决方案，可避免部分共因失效，是冗余的一种方式，包括硬件 / 软件多样性、技术手段多样性。示例：双 CPU 采用不同架构、软件用不同编译器开发。
3.38 双点失效（dual-point failure）
英文：dual-point failure
原定义
-
- 由两个独立硬件故障 (3.54) 的组合引起，且直接导致违背安全目标 (3.139) 的失效 (3.50)。注 1: 双点失效是二阶的多点失效 (3.96)。注 2:GB/T 34590 中提到的双点失效包括这些失效，即：有一个故障影响到安全相关要素 (3.144)，而另一个故障影响到相应的用来达到或保持安全状态 (3.131) 的安全机制 (3.142) 而导致的失效。
解读
- 两个独立硬件故障组合导致的安全目标违背，属于二阶多点失效，包括 “安全相关要素故障 + 安全机制故障” 的组合失效。
3.39 双点故障（dual-point fault）
英文：dual-point fault
原定义
-
- 与另一个非相关故障 (3.54) 组合而导致双点失效 (3.38) 的一个故障 (3.54)。注 1: 一个双点故障只有在一个双点失效明确后才能被识别，例如，通过故障树的割集分析。注 2: 见多点故障 (3.97)。
解读
- 与另一个非相关故障组合后导致双点失效的单个故障，需通过故障树割集分析识别。
3.40 电气 / 电子系统（electrical and/or electronic system；E/E）
英文：electrical and/or electronic system；E/E
原定义
-
- 由电气和 / 或电子要素 (3.41)，包括可编程电子要素所构成的系统 (3.163)。注：电气 / 电子系统的一个要素 (3.41) 可能是另一个电气 / 电子系统。示例：电源、传感器或其他输入设备、通讯路径、执行器或其他输出设备。
解读
- 由电气 / 电子要素（含可编程要素）构成的系统，要素可嵌套（一个 E/E 系统可包含另一个）。示例：电源系统、传感器、通讯路径、执行器。
3.41 要素（element）
英文：element
原定义
-
- 系统 (3.163)、组件 (3.21)（硬件或软件）、硬件元器件 (3.71) 或软件单元 (3.159)。注 1: 当使用 “软件要素” 或 “硬件要素” 时，分别表示仅是软件的要素或仅是硬件的要素。注 2: 要素也可以是一个独立于环境的安全要素 (3.138)。
解读
- 系统、组件（硬件 / 软件）、硬件元器件或软件单元的统称，可分为软件要素、硬件要素，也可作为独立于环境的安全要素。
3.42 嵌入式软件（embedded software）
英文：embedded software
原定义
-
- 在一个处理要素 (3.113) 上运行的充分集成的软件。
解读
- 在处理要素上运行的充分集成软件，与硬件深度绑定。示例：ECU 中的控制软件、自动驾驶域控制器的嵌入式算法软件。
3.43 紧急运行（emergency operation）
英文：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) 响应的一部分。
解读
- 故障后为提供安全而过渡的运行模式，直至进入安全状态，可包含降级，需结合报警和降级策略。示例：制动系统故障后，车辆维持低速行驶至安全停车，属于紧急运行。
3.44 紧急运行时间间隔（emergency operation time interval；EOTI）
英文：emergency operation time interval；EOTI
原定义
-
- 保持紧急运行 (3.43) 的时间间隔。注 1: 见图 4 和图 5。注 2: 报警和降级策略 (3.183) 中描述了紧急运行和相关紧急运行容错时间间隔 (3.45)。注 3: 暂时保持紧急运行 (3.43) 以提供安全 (3.132)，直到过渡到安全状态 (3.131)。
解读
- 保持紧急运行的时间间隔，需与紧急运行容错时间间隔区分（后者是最大值）。
3.45 紧急运行容错时间间隔（emergency operation tolerance time interval；EOTTI）
英文：emergency operation tolerance time interval；EOTTI
原定义
-
- 在无不合理风险 (3.128) 的情况下，能够维持紧急运行 (3.43) 的特定时间间隔。注 1: 见图 4。注 2: 紧急运行容错时间间隔是紧急运行时间间隔 (3.44) 的最大值。注 3: 基于紧急运行容错时间间隔中规定的有限运行时间，紧急运行 (3.43) 能被认为是安全的。
解读
- 无不合理风险的紧急运行最长时间，是 EOTI 的最大值，基于此可判定紧急运行的安全性。
3.46 错误（error）
英文：error
原定义
-
- 计算的、观测的、测量的值或条件与真实的、规定的、理论上正确的值或条件之间的差异。注：错误可由所考虑的系统 (3.163) 或组件 (3.21) 内的故障 (3.54) 引起。
解读
- 测量 / 观测值与真实 / 规定值的差异，由系统 / 组件内的故障引起。示例：传感器受电磁干扰输出错误数据、软件计算结果偏差。
3.47 专业摩托车驾驶员（expert rider）
英文：expert rider
原定义
-
- 由能够根据对实际摩托车 (3.93) 的操作评估可控性 (3.25) 分级的人员担任的角色。注 1: 专业摩托车驾驶员要求具备：评估可控性 (3.25) 的技能，包括评估的知识；实施摩托车试验的能力；基于具有代表性的摩托车驾驶员的驾驶能力来评估摩托车 (3.93) 可控性 (3.25) 特性的知识。注 2: 有关使用专业摩托车驾驶员的信息，见 GB/T34590.12-2022 的附录 C。
解读
- 具备摩托车可控性评估技能、试验能力及驾驶特性知识的人员，用于摩托车功能安全测试评估，详见 GB/T 34590.12 附录 C。
3.48 暴露（exposure）
英文exposure
原定义
-
- 处于某运行场景 (3.104) 的状态，在该运行情况下，如果发生所分析的失效模式 (3.51)，可能导致危害。注：危害分析和风险评估 (3.76) 中的参数 E 代表运行场景 (3.104) 的潜在暴露度。
解读
- 处于某运行场景，且该场景下失效模式可能导致危害，危害分析和风险评估中用参数 E 表示暴露度。例如车辆在高速公路行驶（场景），制动失效模式可能导致碰撞，体现暴露状态。
3.49 外部措施（external measure）
英文external measure
原定义
-
- 独立于且不同于相关项 (3.84) 的措施，以降低或减轻由相关项 (3.84) 导致的风险 (3.128)。
解读
- 独立于相关项的风险降低 / 减轻措施。示例：道路护栏、驾驶员安全带（非车辆自身安全机制的措施）。
3.50 失效（failure）
英文failure
原定义
-
- 由于故障 (3.54) 出现导致要素 (3.41) 或相关项 (3.84) 预期行为的终止。注：终止可能是永久或暂时的。
解读
- 故障导致要素 / 相关项预期行为终止，可永久或暂时。核心是 “行为终止”，是故障的结果。示例：传感器损坏（故障）导致数据输出终止（失效）。
3.51 失效模式（failure mode）
英文failure mode
原定义
-
- 要素 (3.41) 或相关项 (3.84) 未能提供预期行为的方式。
解读
- 要素 / 相关项未能提供预期行为的具体方式。示例：传感器无输出、执行器卡滞、软件崩溃。
3.52 失效模式覆盖率（failure mode coverage；FMC）
英文failure mode coverage；FMC
原定义
-
- 硬件要素 (3.41) 某一失效模式 (3.51) 的失效率 (3.53) 中被实施的安全机制探测或控制的比例。
解读
- 某一失效模式的失效率中，被安全机制探测 / 控制的比例，聚焦单一失效模式的防护能力。
3.53 失效率（failure rate）
英文failure rate
原定义
-
- 硬件要素 (3.41) 的失效 (3.50) 概率密度除以幸存概率（可靠度）。注：失效率被假设为常数且通常用 “λ” 表示。
解读
- 硬件要素失效概率密度除以幸存概率，假设为常数，用 “λ” 表示，是可靠性分析的核心参数。
3.54 故障（fault）
英文fault
原定义
-
- 能够引起要素 (3.41) 或相关项 (3.84) 失效的异常情况。注 1: 考虑永久性故障、间歇性故障和瞬态故障 (3.173)（尤其是软错误）。注 2: 当子系统处于错误 (3.46) 状态时，可能导致系统 (3.163) 发生故障。注 3: 间歇性故障时而发生，然后又消失。这种故障可能发生在一个组件 (3.21) 濒临损坏时，或者例如开关内部功能异常导致其发生。某些系统性故障 (3.165)（例如时序紊乱）也可能导致间歇性故障。
解读
- 引发失效的异常情况，包括永久故障（元件烧毁）、间歇故障（接触不良）、瞬态故障（电磁干扰），是失效的原因。子系统错误状态可能引发系统故障。
3.55 故障探测时间间隔（fault detection time interval；FDTI）
英文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) 及时处理。
解读
- 从故障发生到探测到的时间，独立于诊断测试时间间隔，可能因错误计数器需多次探测而长于诊断测试间隔。
3.56 故障处理时间间隔（fault handling time interval；FHTI）
英文fault handling time interval；FHTI
原定义
-
- 故障探测时间间隔 (3.55) 和故障响应时间间隔 (3.59) 的总和。注 1:FHTI 是安全机制 (3.142) 的一种属性。注 2: 见图 5。
解读
- 故障探测时间间隔与故障响应时间间隔的总和，是安全机制的核心属性。
3.57 故障注入（fault injection）
英文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)。
解读
- 评估故障影响的方法，通过注入故障 / 错误 / 失效，观测响应，可在不同抽象层面（相关项 / 要素）、不同生命周期阶段实施。示例：硬件调试端口注入故障测试接口、运行中注入瞬态故障验证安全机制。
3.58 故障模型（fault model）
英文fault model
原定义
-
- 由故障 (3.54) 导致的失效模式 (3.51) 的表现。注：故障模型用于评估特定故障 (3.54) 的后果。
解读
- 故障导致的失效模式表现，用于评估特定故障的后果。示例：单粒子翻转（故障）导致的寄存器数据错误（失效模式），对应故障模型为 “位翻转模型”。
3.59 故障响应时间间隔（fault reaction time interval；FRTI）
英文fault reaction time interval；FRTI
原定义
-
- 从探测到故障 (3.54) 到进入安全状态 (3.131) 或进入紧急运行 (3.43) 的时间间隔。注：见图 4 和图 5。
解读
- 从探测到故障到进入安全状态 / 紧急运行的时间，需结合图 4、图 5 理解时序。
3.60 故障容错（fault tolerance）
英文fault tolerance
原定义
-
- 在一个或多个特定故障 (3.54) 存在的情况下，实现特定功能的能力。注：特定功能可能是预期功能 (3.83)。
解读
- 存在一个或多个特定故障时，仍能实现预期功能的能力。示例：双传感器冗余设计，单个传感器故障时仍能正常输出数据，体现故障容错能力。
3.61 故障容错时间间隔（fault tolerant time interval；FTTI）
英文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) 抖动。
解读
- 安全机制未激活时，从故障发生到可能引发危害事件的最短时间，是安全目标的关键属性。例如制动系统 FTTI=0.3 秒，意味着故障后需在 0.3 秒内激活安全机制。
3.62 现场数据（field data）
英文field data
原定义
-
- 从相关项 (3.84) 或要素 (3.41) 的使用中获得的数据，包含累积运行时间、所有的失效 (3.50) 和服务中的安全异常 (3.134)。注：现场数据通常来自客户的使用。
解读
- 从相关项 / 要素使用中获取的数据，含累积运行时间、失效记录、安全异常，通常来自客户使用反馈。
3.63 形式记法（formal notation）
英文formal notation
原定义
-
- 语法和语义上完整定义的描述方法。示例：Z 记法 (Zed)、符号模型检查 (NuSMV)、工程样机验证系统 (PVS)、Vienna 开发方法 (VDM)、数学公式。
解读
- 语法和语义完整定义的描述方法，用于精准表达功能 / 属性。示例：Z 记法、数学公式、符号模型检查（NuSMV）。
3.64 形式验证（formal verification）
英文formal verification
原定义
-
- 基于形式记法 (3.63) 针对相关项 (3.84) 或要素 (3.41) 的功能或属性的定义，验证其正确性的方法。
解读
- 基于形式记法验证相关项 / 要素功能 / 属性的正确性，是高精度验证方法。
3.65 免于干扰（freedom from interference）
英文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。
解读
- 要素间无导致安全要求违背的级联失效。示例：要素 A 失效不会导致要素 B 失效，则要素 B 免于要素 A 的干扰。
3.66 功能概念（functional concept）
英文functional concept
原定义
-
- 实现预期表现所需的各预期功能及其交互的定义。注：功能概念是在概念阶段 (3.110) 开发的。
解读
- 实现预期表现所需的各预期功能及交互定义，在概念阶段开发。例如自动驾驶功能概念，需定义感知、决策、执行功能的交互逻辑。
3.67 功能安全（functional safety）
英文functional safety
原定义
-
- 不存在由电气 / 电子系统 (3.40) 的功能异常表现 (3.88) 引起的危害 (3.75) 而导致不合理的风险 (3.176)。
解读
- 核心是 “无电气 / 电子系统功能异常引发的不合理风险”，是整个标准体系的目标，聚焦电气 / 电子系统的安全防护。
3.68 功能安全概念（functional safety concept）
英文functional safety concept
原定义
-
- 为了实现安全目标 (3.139)，定义功能安全要求 (3.69) 及相关信息，并将要求分配到架构 (3.1) 中的要素 (3.41) 上，以及定义要素之间的必要交互。
解读
- 为实现安全目标，定义功能安全要求、分配至要素、明确要素交互，是功能安全落地的核心环节。
3.69 功能安全要求（functional safety requirement）
英文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) 等级信息。
解读
- 独立于具体实现的安全行为 / 措施，含 ASIL 等级等安全属性，目的是使相关项达到 / 保持安全状态。
3.70 硬件架构度量（hardware architectural metrics）
英文hardware architectural metrics
原定义
-
- 用于评估硬件架构 (3.1) 安全 (3.132) 有效性的度量。注：单点故障 (3.156) 度量和潜伏故障 (3.85) 度量都是硬件架构度量。
解读
- 评估硬件架构安全有效性的度量，核心是单点故障度量和潜伏故障度量。
3.71 硬件元器件（hardware part）
英文hardware part
原定义
-
- 硬件组件 (3.21) 在第一层级分解时的一部分。示例：微控制器的 CPU、电阻、微控制器的闪存阵列。
解读
- 硬件组件第一层级分解的部分。示例：微控制器的 CPU、电阻、闪存阵列。
3.72 硬件基础子元器件（hardware elementary subpart）
英文hardware elementary subpart
原定义
-
- 安全 (3.132) 分析中考虑的硬件子元器件 (3.73) 的最小部分。示例：ALU 的触发器及其逻辑锥、寄存器。
解读
- 安全分析中考虑的硬件子元器件最小部分。示例：ALU 的触发器及其逻辑锥、寄存器。
3.73 硬件子元器件（hardware subpart）
英文hardware subpart
原定义
-
- 硬件元器件 (3.71) 中可按逻辑分割的，且代表第二层级或更高层级分解的一部分。示例：微控制器中的 CPU 的 ALU、CPU 的寄存器组。
解读
- 硬件元器件第二层级及以上分解的部分。示例：CPU 的 ALU、寄存器组。
3.74 伤害（harm）
英文harm
原定义
-
- 对人身健康的物理损害或破坏。
解读
- 对人身健康的物理损害或破坏，是功能安全需防控的最终后果。
3.75 危害（hazard）
英文hazard
原定义
-
- 由相关项 (3.84) 的功能异常表现 (3.88) 而导致的伤害 (3.74) 的潜在来源。注：该定义仅限于 GB/T 34590；危害的一个更通常定义是伤害 (3.74) 的潜在来源。
解读
- 由相关项功能异常导致的伤害潜在来源，仅针对 GB/T 34590 范畴内的风险源头。
3.76 危害分析和风险评估（hazard analysis and risk assessment；HARA）
英文hazard analysis and risk assessment；HARA
原定义
-
- 为了避免不合理的风险 (3.176)，对相关项 (3.84) 的危害事件 (3.77) 进行识别和归类的方法以及定义防止和减轻相关危害 (3.75) 的安全目标 (3.139) 和 ASIL (3.6) 等级的方法。
解读
- 识别危害事件、定义安全目标和 ASIL 等级的方法，核心是 “风险导向的安全目标制定”。
3.77 危害事件（hazardous event）
英文hazardous event
原定义
-
- 危害 (3.75) 和运行场景 (3.104) 的组合。
解读
- 危害与运行场景的组合，是风险评估的具体对象。示例：“制动失效”（危害）+“高速公路行驶”（场景）= 危害事件。
3.78 独立性（Independence）
英文Independence
原定义
-
- 两个或者多个要素 (3.41) 间不存在会导致违背安全 (3.132) 要求的相关失效 (3.29)，或从组织上分隔执行某一活动的各方。注：ASIL 等级分解 (3.3) 或认可措施 (3.23) 包括对独立性的要求。
解读
- 要素间无导致安全要求违背的相关失效，或组织上分隔活动执行方，是 ASIL 等级分解和认可措施的关键要求。
3.79 非相关失效（independent failures）
英文independent failures
原定义
-
- 同时或相继失效的概率可表示为无条件失效概率的简单乘积的失效 (3.50)。注：非相关失效可以包括软件失效 (3.50) 即使其失效概率未被计算。
解读
- 失效组合概率 = 独立失效概率乘积，满足统计独立性，可包含软件失效。
3.80 非形式记法（informal notation）
英文informal notation
原定义
-
- 非完整语法定义的描述方法。注：不完整的语法定义意指语义也没有完整的定义。
解读
- 语法和语义未完整定义的描述方法。示例：自然语言描述、简单流程图。
3.81 继承（inheritance）
英文inheritance
原定义
-
- 在开发过程中，某些要求的属性以一种未改变的方式传递到下一细节层面。
解读
- 开发过程中，要求属性未改变地传递到下一细节层面。例如 ASIL 等级从系统级继承至组件级。
3.82 检查（inspection）
英文inspection
原定义
-
- 为发现安全异常 (3.134) 而依据一个正式的流程对工作成果 (3.185) 进行的考查。注 1: 检查是验证 (3.180) 的一种方式。注 2: 检查不同于测试 (3.169)，检查通常不包括对相关项 (3.84) 或要素 (3.41) 的操作。注 3: 一项正式的检查流程通常包括预先定义的步骤、检查列表、核对人员及对结果的评审 (3.127)。
解读
- 按正式流程考查工作成果以发现安全异常，属于验证方式，不涉及相关项 / 要素操作。示例：文档审查、代码走查。
3.83 预期功能（intended functionality）
英文intended functionality
原定义
-
- 针对相关项 (3.84) 定义的除安全机制 (3.142) 外的行为。注：上述行为是在整车层面定义的。
解读
- 整车层面定义的除安全机制外的行为，是相关项的核心功能目标。示例：自动巡航控制、车道保持功能。
3.84 相关项（item）
英文item
原定义
-
- 适用于 GB/T 34590，实现整车层面功能或部分功能的系统 (3.163) 或系统组合。注：见整车功能 (3.178)。
解读
- 实现整车部分 / 全部功能的系统或系统组合，是功能安全开发的基本单元。示例：发动机管理系统、自动驾驶域控制器。
3.85 潜伏故障（latent fault）
英文latent fault
原定义
-
- 在多点故障探测时间间隔 (3.98) 内，未被安全机制 (3.142) 探测到且未被驾驶员感知到的多点故障 (3.97)。
解读
- 多点故障探测时间间隔内，未被安全机制探测且未被驾驶员感知的多点故障，是隐藏的风险点。
3.86 生命周期（lifecycle）
英文lifecycle
原定义
-
- 相关项 (3.84) 从概念到报废的全部阶段 (3.110)。
解读
- 相关项从概念到报废的全部阶段，涵盖开发、生产、运行、服务、报废。
3.87 管理体系（management system）
英文management system
原定义
-
- 一个组织用来实现其目标的政策、程序及流程。
解读
- 组织实现目标的政策、程序及流程，是功能安全落地的组织保障。
3.88 功能异常表现（malfunctioning behaviour）
英文malfunctioning behaviour
原定义
-
- 失效 (3.50) 或与设计意图相悖的相关项 (3.84) 非预期表现。
解读
- 失效或相关项的非预期表现（违背设计意图）。示例：加速踏板卡滞导致车辆非预期加速。
3.89 最长待修复时间间隔（maximum time to repair time interval）
英文maximum time to repair time interval
原定义
-
- 可以维持在安全状态 (3.131) 的特定时间间隔。注 1: 当安全状态 (3.131) 无法保持到车辆剩余使用寿命结束时，最长待修复时间是一个相关特性。注 2: 从安全状态 (3.131) 中恢复的条件在报警和降级策略 (3.183) 中进行描述。注 3: 若相关，则最长待修复时间间隔在报警和降级策略 (3.183) 中进行描述。
解读
- 可维持安全状态的最长时间，安全状态无法持续至车辆寿命时需明确，详见报警和降级策略。
3.90 基于模型的开发（model-based development；MBD）
英文model-based development；MBD
原定义
-
- 一种使用模型来描述待开发要素 (3.41) 行为或属性的开发。注：根据模型使用的抽象层次，该模型可用于仿真或代码生成或二者均可。
解读
- 用模型描述要素行为 / 属性的开发方法，支持仿真和代码生成，是复杂系统开发的主流方式。
3.91 修改（modification）
英文modification
原定义
-
- 以现有相关项 (3.84) 为基础创建新相关项 (3.84)。注：在 GB/T 34590 中，为剪裁生命周期 (3.86) 对复用的部分使用 “修改”。变更用于相关项 (3.84) 的生命周期 (3.86) 过程中，而修改用于由已有的相关项生成新的相关项 (3.84)。
解读
- 基于现有相关项创建新相关项，用于剪裁生命周期（复用部分），与 “变更”（生命周期内调整）区分。
3.92 修改条件 / 判定覆盖率（modified condition/decision coverage；MC/DC）
英文modified condition/decision coverage；MC/DC
原定义
-
- 在控制流中已执行的、可以独立影响判定结果的全部单一条件结果的百分比。注：MC/DC 是一种建立在分支覆盖率 (3.13) 之上的代码覆盖率分析。因此，它也要求所有的代码块和所有的执行路径都经过测试。
解读
- 控制流中可独立影响判定结果的单一条件执行占比，基于分支覆盖率，要求覆盖所有代码块和执行路径，是软件测试的严苛覆盖率指标。
3.93 摩托车（motorcycle）
英文motorcycle
原定义
-
- 由动力装置驱动的具有两个或三个车轮的道路车辆，其最高设计车速大于 50 km/h， 或满足以下条件之一：-- 若使用内燃机，其排量大于 50 mL；若使用电力驱动，其电机的最大连续额定功率总和大于 4 kW。但不包括如下类别：最大设计车速、整车整备质量、外廓尺寸等指标符合相关国家标准和规定的，专供残疾人驾驶的机动轮椅车。[来源：GB/T 5359.1-2019，2.1]
解读
- 动力驱动、2-3 个车轮，最高车速 > 50km/h，或内燃机排量 > 50mL / 电机功率 > 4kW，不含残疾人机动轮椅车，与 GB/T 5359.1-2019 一致。
3.94 摩托车安全完整性等级（motorcycle safety integrity level；MSIL）
英文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 代表最低严格等级。
解读
- 摩托车领域的 4 级安全等级（A 最低→D 最高），基于 ASIL 等级转换，适配摩托车场景的风险降低要求。
3.95 多核（multi-core）
英文multi-core
原定义
-
- 包括两个或多个能彼此独立运行的硬件处理要素 (3.113) 的硬件组件 (3.21)。
解读
- 含两个及以上独立运行处理要素的硬件组件。示例：4 核微控制器、多核 GPU。
3.96 多点失效（multiple-point failure）
英文multiple-point failure
原定义
-
- 由几个独立的硬件故障 (3.54) 组合引发，直接导致违背安全目标 (3.139) 的失效 (3.50)。
解读
- 多个独立硬件故障组合导致的安全目标违背，双点失效是其二阶形式。
3.97 多点故障（multiple-point fault）
英文multiple-point fault
原定义
-
- 在未被探测且未被感知到的情况下，与其他独立故障 (3.54) 组合可能导致一个多点失效 (3.96) 的一个故障 (3.54)。注：一个多点故障仅在识别出（例如，通过故障树的割集分析）多点失效 (3.96) 后才能被辨认出来。
解读
- 未被探测且未被感知，与其他独立故障组合可导致多点失效的单个故障，需通过故障树分析识别。
3.98 多点故障探测时间间隔（multiple-point fault detection time interval）
英文multiple-point fault detection time interval
原定义
-
- 在可导致一个多点失效 (3.96) 前，将多点故障 (3.97) 探测出来的时间间隔。
解读
- 多点失效发生前，探测到多点故障的时间间隔。
3.99 新开发（new development）
英文new development
原定义
-
- 开发一个具有先前未定义功能的相关项 (3.84) 或要素 (3.41) 的过程，或开发一个现有功能的新的实现方式的过程，或两者都有。
解读
- 开发新功能或现有功能新实现方式的过程。
3.100 非功能性危害（non-functional hazard）
英文non-functional hazard
原定义
-
-
- 由电气 / 电子系统 (3.40)、基于其他技术 (3.105) 的安全相关系统 (3.163) 或外部措施 (3.49) 的功能异常表现 (3.88) 以外的因素导致的危害 (3.75)。
-
解读
-
- 由电气 / 电子系统功能异常外因素导致的危害，不在本标准核心防控范围内。
欢迎关注、点赞与转发,后续持续更新
阅读全文
