芯耀
1448
文字过多,建议收藏,欢迎点赞和转发哈
一、标准核心定位与基本信息
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 系列标准，形成本土化标准闭环
三、术语与解读（101-185）
3.101 观测点（observation points）
英文：observation points
原定义：用来观察故障 (3.54) 潜在影响的要素 (3.41) 的输出信号。示例：存储器的输出。
解读：观察故障潜在影响的要素输出信号。示例：存储器输出、传感器数据接口。
3.102 运行模式（operating mode）
英文：operating mode
原定义：源自相关项 (3.84) 或要素 (3.41) 的使用和应用中功能状态的一些条件。示例：系统 (3.163) 关闭；系统 (3.163) 激活；系统 (3.163) 非激活；降级运行；紧急运行 (3.43)；安全状态 (3.131)。
解读：相关项 / 要素的功能状态条件。示例：系统激活 / 关闭、降级运行、紧急运行、安全状态。
3.103 运行时间（operating time）
英文:operating time
原定义：相关项 (3.84) 或要素 (3.41) 工作（包括降级模式）的累积时间。
解读：相关项 / 要素工作的累积时间，含降级模式下的运行时间。
3.104 运行场景（operational situation）
英文：operational situation
原定义：在车辆生命周期中可能发生的场景。示例：高速行驶、斜坡驻车、维护。
解读：车辆生命周期中可能发生的场景。示例：高速行驶、斜坡驻车、维护保养。
3.105 其他技术（other technology）
英文：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) 被考虑。
解读
- 非电气 / 电子技术，可在安全要求分配中考虑。示例：机械技术、液压技术。
3.106 分区（partitioning）
英文：partitioning
原定义
-
- 为实现某种设计，而对功能或要素 (3.41) 的分隔。注：分区可用于抑制故障 (3.54) 以避免级联失效 (3.17)。为实现分区设计要素 (3.41) 间的免于干扰 (3.65)，可引入额外的非功能性要求。
解读
- 功能或要素的分隔设计，用于抑制级联失效，需引入非功能性要求保障免于干扰。
3.107 乘用车（passenger car）
英文：passenger car
原定义
- 设计和制造上主要用于载运乘客及其随身行李和 / 或临时物品的汽车，包括驾驶人座位在内最多不超过 9 个座位。它也可以牵引一辆中置轴挂车。[来源：GB/T 3730.1-200
接着106解读
3.107 乘用车（passenger car）
英文：passenger car
原定义
-
- 设计和制造上主要用于载运乘客及其随身行李和 / 或临时物品的汽车，包括驾驶人座位在内最多不超过 9 个座位。它也可以牵引一辆中置轴挂车。[来源：GB/T 3730.1-2001，2.1.1]
解读
- 核心定位是 “小型载客汽车”，座位数（含驾驶员）≤9 个，兼顾随身行李和临时物品运输，支持牵引中置轴挂车，与国标车辆分类定义保持一致。示例：家用轿车、7 座 SUV。
3.108 可感知故障（perceived fault）
英文：perceived fault
原定义
-
- 可间接感知到的故障 (3.54)（通过整车层面的异常行为）。
解读
- 无法直接探测但可通过车辆整体异常表现间接判断的故障，无需专业设备即可感知。示例：车辆行驶抖动、动力输出不稳定，可间接感知为发动机控制系统故障。
3.109 永久性故障（permanent fault）
英文：permanent fault
原定义
-
- 发生并持续直到被移除或修复的故障 (3.54)。注：直流 (DC) 故障 (3.54)，例如卡滞故障和桥接故障 (3.54) 是永久性故障。
解读
- 故障发生后持续存在，必须通过维修、更换部件等方式才能消除，区别于间歇故障和瞬态故障。示例：传感器内部元件烧毁、制动踏板卡滞。
3.110 阶段（phase）
英文：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) 层面产品开发；硬件层面产品开发；软件层面产品开发；生产、运行、服务和报废。
解读
- 安全生命周期的核心划分单元，明确了功能安全开发的关键流程节点，各阶段前后衔接，覆盖从概念到报废的全流程。
3.111 失效物理学（physics of failure；PoF）
英文：physics of failure；PoF
原定义
-
- 基于失效 (3.50) 机制研究可靠性的科学方法。注 1:PoF 通常应用于计算机辅助工程 (CAE) 环境中的耐久性模拟。注 2: 在评估新技术和设计的可靠性时，失效物理学分析可能有优势，因为不需要多年的现场失效 (3.50) 历史来进行可靠性预测。
解读
- 通过研究失效的物理机制（如材料疲劳、电应力损伤）来预测可靠性的方法，无需长期现场数据，适用于 CAE 模拟和新技术可靠性评估。示例：通过 PoF 分析预测芯片在高温环境下的老化失效时间。
3.112 动力输出装置（power take-off；PTO）
英文：power take-off；PTO
原定义
-
- 卡车 (3.174) 或牵引车 (3.170) 为操作设备提供动力源的接口。示例：操作液压泵、真空泵、举升机、翻斗车、水泥搅拌机的接口。
解读
- 商用车专用的动力输出接口，用于为外部作业设备提供动力，是专用汽车实现作业功能的核心部件。示例：水泥搅拌车通过 PTO 接口为搅拌筒提供旋转动力。
3.113 处理要素（processing element；PE）
英文：processing element；PE
原定义
解读
- 硬件中的独立数据处理单元，具备寄存器集、执行单元和控制单元，是多核硬件的核心组成部分。示例：CPU 的单个核心、GPU 的流多处理器。
3.114 可编程逻辑器件（programmable logic device；PLD）
英文：programmable logic device；PLD
原定义
-
- 在制造时具有未定义的电路功能，并在集成到更高级别的要素 (3.41) 时进行配置的硬件组件 (3.21) 或硬件元器件 (3.71)。
解读
3.115 在用证明（proven in use argument）
英文：proven in use argument
原定义
-
- 基于对候选项 (3.16) 应用的现场数据 (3.62) 的分析，证明该候选项 (3.16) 的任何失效 (3.50) 可能损害相关项 (3.84) 安全目标 (3.139) 的可能性符合适用 ASIL (3.6) 等级要求的证据。
解读
- 通过成熟产品的现场运行数据，证明其安全性符合目标 ASIL 等级，可用于简化新车型中同类组件的验证流程。示例：某成熟车载 ECU 的现场失效数据显示风险低于 ASIL B 要求，可通过在用证明直接应用于新车型。
3.116 在用证明可信度（proven in use credit）
英文：proven in use credit
原定义
-
- 通过在用证明 (3.115) 对一组给定的生命周期 (3.86) 子阶段 (3.161) 及相应工作成果 (3.185) 的替代。
解读
- 在用证明可替代的生命周期子阶段和工作成果，核心是通过历史数据减免部分重复验证工作，提升开发效率。
3.117 质量管理（quality management；QM）
英文：quality management；QM
原定义
-
- 用来指导和控制组织的针对质量的协调活动。注：QM 不是一个 ASIL (3.6) 等级，但可以在危害分析和风险评估 (3.76) 中定义。
解读
- 组织层面的质量协调活动，聚焦通用质量控制，不属于 ASIL 安全等级，但可作为低风险功能的安全保障方式（如车窗控制功能可采用 QM 要求）。
3.118 随机硬件失效（random hardware failure）
英文：random hardware failure
原定义
-
- 在硬件要素 (3.41) 的生命周期中，发生的服从概率分布的不可预测的失效 (3.50)。注 1: 可在合理的精度内预测随机硬件失效率。注 2: 对于本文件而言，失效物理学 (3.111) 方法论 (SAE J1211、JEDEC JEP122 等) 定义的物理硬件失效 (3.50) 可视为随机硬件失效。
解读
3.119 随机硬件故障（random hardware fault）
英文：random hardware fault
原定义
-
- 服从概率分布的硬件故障 (3.54)。
解读
- 导致随机硬件失效的故障，其发生概率服从统计分布，是功能安全中需通过诊断覆盖率、冗余设计等措施防控的对象。
3.120 合理可预见的（reasonably foreseeable）
英文：reasonably foreseeable
原定义
-
- 技术上可能的、且具有可信或可测量发生率的。注：预期的误用可以理解为合理可预见事件的子类。
解读
- 从技术角度判断可能发生，且发生率可验证或可信的情况，包括预期的误用场景。示例：驾驶员误触自动驾驶激活按钮、车辆行驶中遇到暴雨天气，均属于合理可预见场景。
3.121 重建（rebuilding）
英文：rebuilding
原定义
-
- 改变 T&B 的原始配置，以便执行不同的任务。注：重建可以包括 T&B 车辆配置 (3.175) 的修改 (3.91)。
解读
- 通过修改 T&B 车辆原始配置，使其适配新的作业任务，区别于常规维护，涉及配置变更。示例：将普通货运卡车的货箱改为冷藏箱，用于冷链运输。
3.122 冗余（redundancy）
英文：redundancy
原定义
-
- 除了足以实施所需功能或足以表达信息的方法外，还存在其他方法。注 1:GB/T 34590 中使用了冗余，以实现安全目标 (3.139) 或特定安全 (3.132) 要求、或者表达安全相关信息。注 2: 冗余可以同质实现，也可以多样性实现。示例 1: 重复的功能组件 (3.21) 是冗余的一个实例，其目的是增加可用性 (3.7) 或用于故障 (3.54) 探测。示例 2: 对表示安全相关信息的数据增加奇偶检验位，为故障 (3.54) 探测提供了冗余。
解读
3.123 回归策略（regression strategy）
英文：regression strategy
原定义
-
- 用于验证相关项 (3.84) 或要素 (3.41) 中一个已实施的变更不会影响到未变更的、已存在的和先前验证过的部分或特性的策略。
解读
- 变更后的验证策略，核心是确保新变更不会引入新风险，也不会破坏原有已验证的功能和安全特性。示例：软件迭代升级后，通过回归测试验证原有制动控制功能不受影响。
3.124 再制造（remanufacturing）
英文：remanufacturing
原定义
-
- 按照原始规范，用新的或修复后的零件对已使用一段时间的 T&B 车辆进行拆卸和翻修。
解读
- 对在用 T&B 车辆的专业化翻修，需遵循原始规范，更换或修复老化零件，恢复车辆性能，区别于普通维修。示例：对二手垃圾收集车进行拆卸，更换损坏的液压系统零件后重新组装。
3.125 残余故障（residual fault）
英文：residual fault
原定义
-
- 发生在硬件要素 (3.41) 中，可导致违背安全目标 (3.139) 的随机硬件故障 (3.119) 中未被安全机制 (3.142) 覆盖的部分。注：此处假设硬件要素 (3.41) 的安全机制 (3.142) 仅覆盖了其故障 (3.54) 的一部分。示例：如果一系列与安全相关且不安全的故障 (3.54)，有 60% 的子集被覆盖，那么该组故障 (3.54) 剩余的 40% 称为残余故障。
解读
- 硬件中未被安全机制探测或控制的、可能违背安全目标的随机故障，是残余风险的重要来源。示例：安全机制覆盖了 70% 的传感器故障，剩余 30% 未被覆盖的故障为残余故障。
3.126 残余风险（residual risk）
英文：residual risk
原定义
-
- 实施安全措施 (3.141) 后剩余的风险 (3.128)。
解读
- 经过安全措施防控后仍未消除的风险，需控制在 “合理可接受” 范围内，是功能安全评估的核心输出之一。示例：制动系统通过冗余设计降低了 99% 的失效风险，剩余 1% 的风险为残余风险。
3.127 评审（review）
英文：review
原定义
-
- 按照评审目的，为实现预期的工作成果 (3.185) 目标而对工作成果 (3.185) 进行的检查。注：从开发阶段 (3.110) 的角度看，包括验证评审 (3.181) 和认可评审 (3.24)。
解读
- 针对工作成果的目的性检查，核心是确保成果符合预期目标，涵盖技术验证和标准符合性认可两类评审。示例：设计方案评审、测试报告认可评审。
3.128 风险（risk）
英文：risk
原定义
-
- 伤害 (3.74) 发生的概率及其严重度 (3.154) 的组合。
解读
- 功能安全的核心防控对象，由 “发生概率” 和 “伤害严重度” 两个维度决定，需通过风险评估确定防控优先级。示例：高速行驶中制动失效的风险（高严重度 + 低概率）高于低速场景。
3.129 鲁棒性设计（robust design）
英文：robust design
原定义
-
- 在无效的输入或有压力的环境条件下，具有正确工作的能力的设计。注：对鲁棒性可作如下理解：-- 对于软件，鲁棒性是指应对异常输入和条件的能力；-- 对于硬件，鲁棒性是指在设计范围和使用寿命内对环境压力的承受能力和稳定能力；及 -- 在 GB/T 34590 上下文中，鲁棒性是在边界处提供安全行为的能力。
解读
- 产品在极端条件下的稳定工作能力，软件聚焦异常输入应对，硬件聚焦环境压力承受，核心是边界条件下的安全行为。示例：软件拒绝无效的控制指令、硬件在 - 40℃~85℃环境下正常工作。
3.130 安全故障（safe fault）
英文：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) 可被认为是安全故障。
解读
- 对安全目标影响极小的故障，不会显著增加失效风险，单点、残余、双点故障不属于此类。示例：车载娱乐系统的按键故障，不影响制动、转向等安全功能，属于安全故障。
3.131 安全状态（safe state）
英文：safe state
原定义
-
- 相关项 (3.84) 在失效 (3.50) 的情况下，没有不合理风险 (3.128) 的运行模式 (3.102)。注 1: 见图 5。注 2: 虽然可将正常运行视为安全，但 GB/T 34590 中仅针对失效 (3.50) 情况定义安全状态。示例：关闭模式 (对于非容错性的系统 (3.163))。
解读
- 仅针对失效场景定义的无不合理风险的运行模式，是故障后需过渡到的最终状态。示例：发动机控制系统失效后停止供油、自动驾驶系统失效后切换为人工驾驶。
3.132 安全（safety）
英文：safety
原定义
-
- 没有不合理的风险 (3.176)。
解读
- 功能安全的终极目标，核心是 “风险可控”，而非绝对无风险，需通过技术和流程将风险降低至合理可接受水平。
3.133 安全活动（safety activity）
英文：safety activity
原定义
-
- 在安全 (3.132) 生命周期 (3.86) 的一个或多个阶段 (3.110) 或子阶段 (3.161) 进行的活动。
解读
- 贯穿安全生命周期的具体工作，是实现功能安全的基础，涵盖开发、测试、评审、维护等全流程活动。示例：危害分析和风险评估、安全机制设计、安全测试。
3.134 安全异常（safety anomaly）
英文:safety anomaly
原定义
-
- 偏离预期并可能导致伤害 (3.74) 的情况。注：安全异常可在评审 (3.127)、测试 (3.169)、分析、编译、组件 (3.21) 的使用、或适用文档的使用等过程中被发现。示例：偏差可以是在需求、规范、设计文档、用户文档、标准或经验方面。
解读
- 偏离预期且可能引发伤害的偏差，可在开发、测试、使用等全流程发现，需及时排查整改。示例：需求文档中安全目标描述模糊、测试中发现的制动响应延迟。
3.135 安全架构（safety architecture）
英文：safety architecture
原定义
-
- 用来实现安全 (3.132) 要求的一系列要素 (3.41) 以及它们之间的交互。
解读
- 为实现安全要求设计的要素组合及交互逻辑，是安全功能落地的硬件 / 软件载体。示例：自动驾驶系统的 “传感器冗余 + 双 CPU 决策 + 多通道执行” 安全架构。
3.136 安全档案（safety case）
英文：safety case
原定义
-
- 实现相关项 (3.84) 或要素 (3.41) 功能安全 (3.67)、收集整理开发过程中安全活动的工作成果 (3.185) 证据来满足功能安全 (3.67) 的论据。注：安全档案可被扩展，以涵盖 GB/T 34590 范围外的安全 (3.132) 问题。
解读
- 证明功能安全达成的 “证据包”，包含安全活动的所有工作成果，是向监管机构、客户证明合规性的核心文档。
3.137 安全文化（safety culture）
英文：safety culture
原定义
-
- 组织中持久的价值观、态度、动机和认知，即：在决策和行为中，安全 (3.132) 优先于与之冲突的目标。注：见 GB/T 34590.2-XXXX, 附录 B。
解读
- 组织层面的安全导向价值观，核心是 “安全优先”，是功能安全落地的组织保障，影响全员决策和行为。示例：开发过程中为保障安全目标延迟项目进度、拒绝牺牲安全的成本优化方案。
3.138 独立于环境的安全要素（safety element out of context；SEooC）
英文：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)。
解读
- 不绑定特定相关项的通用安全要素，基于假设的安全要求开发，可复用至多个车型或系统。示例：通用型车载雷达安全模块、标准化的故障诊断软件组件。
3.139 安全目标（safety goal）
英文：safety goal
原定义
-
- 作为整车层面危害分析和风险评估 (3.76) 结果的最高层面的安全 (3.132) 要求。注：一个安全目标可能与几种危害 (3.75) 有关，几个安全目标可能与一种单一的危害 (3.75) 有关。
解读
- 整车层面的最高安全要求，由危害分析和风险评估得出，是功能安全开发的核心依据，可对应单个或多个危害。示例：“避免车辆非预期加速”“确保制动系统失效时车辆可控”。
3.140 安全经理（safety manager）
英文：safety manager
原定义
-
- 对实现功能安全 (3.67) 所必需的活动，负责监督和确保其开展的人员或组织。注：在相关项 (3.84) 开发的不同层面，每个涉及的公司可按照内部矩阵组织对任务的划分，指派一个或多个不同人员。
解读
- 功能安全活动的监督者和推动者，可按开发层级（系统、硬件、软件）指派，确保全流程安全活动落地。示例：项目级安全经理、硬件层面安全经理。
3.141 安全措施（safety measure）
英文：safety measure
原定义
-
- 用来避免或控制系统性失效 (3.164), 探测或控制随机硬件失效 (3.118), 或减轻它们有害影响的活动或技术解决方案。注：安全措施包括安全机制 (3.142)。示例：FMEA 或未使用全局变量的软件。
解读
- 防控失效的活动或技术方案，涵盖系统性失效防控（如 FMEA 分析）、随机硬件失效探测（如诊断算法），安全机制是其核心组成部分。
3.142 安全机制（safety mechanism）
英文：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) 的影响。
解读
- 具体的技术解决方案，核心是探测故障、控制失效、过渡到安全状态或提醒驾驶员，是安全措施的落地形式。示例：看门狗（故障探测）、双传感器冗余（失效控制）、报警提示（驾驶员提醒）。
3.143 安全计划（safety plan）
英文：safety plan
原定义
-
- 管理和指导开展项目安全活动 (3.133) 的计划，包括日期､里程碑节点､任务､可交付成果､职责和资源。
解读
- 功能安全项目的执行蓝图，明确安全活动的时间节点、责任分工、交付物和资源配置，确保活动有序开展。示例：项目安全计划中明确 “第 3 个月完成危害分析和风险评估，输出安全目标文档”。
3.144 安全相关要素（safety-related element）
英文：safety-related element
原定义
-
- 有潜在可能导致违背安全目标或有助于实现安全目标 (3.139) 的要素 (3.41)。注：如果失效 - 安全要素 (3.41) 可能违背至少一个安全目标，那么该失效 - 安全要素被认为是与安全相关的。
解读
- 对安全目标有直接影响的要素，包括可能导致安全目标违背（如制动执行器）或有助于实现安全目标（如故障诊断模块）的要素。
3.145 安全相关功能（safety-related function）
英文：safety-related function
原定义
-
- 有潜在可能导致违背安全目标或有助于实现安全目标 (3.139) 的功能。
解读
- 与安全目标直接相关的功能，区别于非安全相关功能（如车载娱乐），是功能安全开发的重点对象。示例：制动控制功能、车道保持辅助功能。
3.146 安全相关事件（safety-related incident）
英文：safety-related incident
原定义
-
- 安全相关失效 (3.50) 的发生。
解读
- 安全相关要素或功能发生失效的事件，需记录、分析并采取纠正措施，是持续改进的重要输入。示例：制动传感器失效导致的制动响应延迟事件。
3.147 安全相关的特殊特性（safety-related special characteristic）
英文：safety-related special characteristic
原定义
-
- 相关项 (3.84)､要素 (3.41) 自身或其生产过程的特性，这些特性的合理可预见偏差可能影响､促使或造成功能安全 (3.67) 的潜在降低。注 1:GB/T 18305 中定义了特殊特性的术语。注 2: 安全相关的特殊特性在相关项 (3.84) 或要素 (3.41) 的开发阶段 (3.110) 中得出。注 3: 安全相关的特殊特性不同于安全机制，也不宜和安全机制 (3.142) 混淆。示例：温度范围､有效期限､紧固力矩､生产公差､配置。
解读
- 影响功能安全的产品或生产过程特性，其偏差可能降低安全水平，需在开发和生产中严格控制。示例：传感器的工作温度范围、螺栓的紧固力矩、软件配置参数。
3.148 安全确认（safety validation）
英文：safety validation
原定义
-
- 基于检查和测试，确保安全目标 (3.139) 是充分的，并已达到且具有足够的完整性等级。注：GB/T 34590.4-XXXX 提供了合适的安全确认方法。
解读
- 最终验证活动，核心是确认安全目标的充分性、达成度和完整性，确保产品整体安全符合要求。示例：整车级制动失效场景测试、自动驾驶安全目标达成验证。
3.149 半形式记法（semi-formal notation）
英文：semi-formal notation
原定义
-
- 语法定义是完整的，但语义定义可以是不完整的描述方法。示例：结构化分析与设计技术 (SADT)､统一建模语言 (UML)。
解读
- 语法完整但语义可不完全定义的描述方法，兼顾精准性和灵活性，适用于系统设计和建模。示例：用 UML 类图描述系统组件关系、SADT 图描述功能流程。
3.150 半形式验证（semi-formal verification）
英文：semi-formal verification
原定义
-
- 基于半形式记法 (3.149) 的验证 (3.180)。示例：使用由半形式模型生成的测试向量来测试系统 (3.163) 表现与模型是否匹配。
解读
- 基于半形式记法的验证方法，通过模型生成测试用例等方式验证系统表现，平衡验证精度和效率。示例：基于 UML 模型生成测试向量，验证软件功能与模型一致性。
3.151 半挂车（semi-trailer）
英文：semi-trailer
原定义
-
- 设计为通过连接到牵引车 (3.170) 上的主销 (对牵引车辆施加了很大的垂直载荷) 而被牵引的挂车 (3.171)。
解读
- 通过主销与牵引车连接的挂车，主销传递较大垂直载荷，是商用车运输的常用车型。示例：长途货运的集装箱半挂车、油罐半挂车。
3.152 量产道路车辆（series production road vehicle）
英文：series production road vehicle
原定义
-
- 旨在用于公共道路且不是原型机的道路车辆。注：车辆类型分类可能因地区而异。示例 1: 普通消费者使用车辆。示例 2: 公共用途车辆。
解读
- 批量生产的、用于公共道路的非原型车辆，涵盖私家车、公交、货运等各类量产车型，是本标准的主要适用对象。
3.153 服务说明（service note）
英文：service note
原定义
-
- 在执行相关项 (3.84) 的维护流程时所考虑的安全 (3.132) 信息文档。示例：安全相关的特殊特性 (3.147); 所需的安全 (3.132) 操作。
解读
- 维护阶段的安全指导文档，明确维护过程中需关注的安全特性和操作要求，避免维护不当引发安全风险。示例：制动系统维护时的螺栓紧固力矩要求、传感器校准流程。
3.154 严重度（severity）
英文：severity
原定义
-
- 对潜在危害事件 (3.77) 中可能发生的一个或多个人员的伤害 (3.74) 程度的预估。注：在危害分析和风险评估 (3.76) 中参数 “S” 代表伤害的潜在严重程度。
解读
- 危害事件可能造成的伤害程度，是风险评估的核心参数之一，通常分为轻微、中等、严重、致命等等级。示例：车辆碰撞导致轻伤（低严重度）、致命伤（高严重度）。
3.155 单点失效（single-point failure）
英文：single-point failure
原定义
-
- 由单点故障 (3.156) 引起的失效 (3.50)。
解读
- 无安全机制防护的单点故障导致的失效，直接违背安全目标，是功能安全设计需重点避免的情况。示例：无冗余设计的制动主缸故障导致制动失效。
3.156 单点故障（single-point fault）
英文：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) 均不是单点故障。
解读
- 未被任何安全机制覆盖、直接导致安全目标违背的硬件故障，是单点失效的根源，需通过安全机制（如冗余、诊断）消除。
3.157 软件组件（software component）
英文：software component
原定义
-
- 一个或多个软件单元 (3.159)。
解读
- 软件的组成模块，由一个或多个可独立测试的软件单元构成，是软件架构设计的基本单元。示例：自动驾驶软件中的感知组件、决策组件。
3.158 软件工具（software tool）
英文：software tool
原定义
-
- 在开发相关项 (3.84) 或要素 (3.41) 中所用到的计算机程序。
解读
- 功能安全开发过程中使用的各类软件工具，需评估其置信度以确保开发成果的安全性。示例：编译器、仿真工具、代码静态分析工具、测试工具。
3.159 软件单元（software unit）
英文：software unit
原定义
-
- 软件架构 (3.1) 中的最低层级且可被独立测试 (3.169) 的软件组件 (3.157)。
解读
- 软件架构的最底层单元，具备独立测试能力，是软件开发和验证的最小颗粒度。示例：软件中的一个函数、一个数据处理模块。
3.160 语句覆盖率（statement coverage）
英文：statement coverage
原定义
-
- 软件中已执行语句所占的百分比。
解读
- 软件测试的基础覆盖率指标，衡量已执行代码语句的比例，是验证软件是否被充分测试的基本依据。示例：某软件共 100 行代码，测试执行了 95 行，语句覆盖率为 95%。
3.161 子阶段（subphase）
英文：subphase
原定义
-
- GB/T 34590 章节中定义的､安全 (3.132) 生命周期 (3.86) 中阶段 (3.110) 的细分。示例：危害分析和风险评估 (3.76) 是安全 (3.132) 生命周期 (3.86) 的子阶段 (3.161), 在 GB/T 34590.3-XXXX 第 6 章中进行了定义。
解读
- 安全生命周期阶段的进一步细分，明确每个阶段的具体工作步骤，使开发流程更清晰可执行。示例：概念阶段的子阶段包括相关项定义、危害分析和风险评估、功能安全概念。
3.162 供应协议（supply agreement）
英文：supply agreement
原定义
-
- 客户和供应商之间的协议，其中规定了各项活动的责任划分，以及各方要执行或交换的与相关项 (3.84) 和要素 (3.41) 生产相关的证据或工作成果 (3.185)。注：DIA 适用于开发阶段，供应协议适用于生产阶段。
解读
- 客户与供应商间针对生产阶段的责任协议，明确生产过程中的责任划分、证据交换要求，与开发阶段的 DIA 区分。
3.163 系统（system）
英文：system
原定义
-
- 一组至少与一个传感器､一个控制器和一个执行器相关联的组件 (3.21) 或子系统。注：相关的传感器或执行器可包含在系统中，也可存在于系统之外。
解读
- 由传感器、控制器、执行器（或其组合）组成的功能单元，是实现特定车辆功能的核心载体。示例：制动系统（传感器 + ECU + 制动执行器）、自动驾驶系统。
3.164 系统性失效（systematic failure）
英文：systematic failure
原定义
-
- 以确定的方式与某个原因相关的失效 (3.50), 只有对设计或生产流程､操作规程､文档或其他相关因素进行变更后才可能排除这种失效。
解读
- 由设计、流程、文档等确定性原因导致的失效，不可通过统计方法预测，需通过优化设计、改进流程等方式消除。示例：软件逻辑错误导致的制动指令延迟、生产工艺缺陷导致的传感器精度不足。
3.165 系统性故障（systematic fault）
英文：systematic fault
原定义
-
- 以确定的方式显现失效 (3.50) 的故障 (3.54), 只有通过流程或设计措施的应用才能防止其发生。
解读
- 导致系统性失效的确定性故障，根源在于设计、流程等环节，需通过设计优化、流程管控等措施预防。示例：软件需求定义错误导致的功能逻辑故障、生产过程中焊接工艺不当导致的电路故障。
3.166 目标环境（target environment）
英文：target environment
原定义
-
- 用于执行特定软件的环境。注：对于应用软件，其目标环境是带有基础软件和操作系统的微控制器。对于嵌入式软件 (3.42), 其目标环境是系统 (3.163) 中的 ECU。
解读
- 软件运行的硬件和软件环境，明确目标环境是软件设计和验证的前提。示例：嵌入式软件的目标环境为车载 ECU（含硬件芯片和实时操作系统）。
3.167 技术安全概念（technical safety concept）
英文
-
- technical safety concept
原定义
-
- 技术安全要求 (3.168) 的定义，技术安全要求 (3.168) 在系统 (3.163) 要素 (3.41) 间的分配，以及为系统 (3.163) 层面功能安全 (3.67) 提供依据的相关信息。
解读
- 将功能安全要求转化为系统层面的技术要求，并分配至各要素，是连接功能安全概念与系统设计的桥梁。示例：将 “制动失效可控” 的功能安全要求，转化为 “双回路制动设计”“故障诊断算法” 等技术安全要求。
3.168 技术安全要求（technical safety requirement）
英文
-
- technical safety requirement
原定义
-
- 为实现相关的功能安全要求 (3.69) 而得出的要求。注：得出的要求包括减轻危害所需的要求。
解读
- 功能安全要求的技术落地形式，明确系统、硬件、软件需满足的具体技术指标，是产品开发的直接依据。示例：“传感器故障诊断覆盖率≥95%”“制动响应时间≤0.2 秒”。
3.169 测试（testing）
英文
-
- testing
原定义
-
- 为验证相关项 (3.84) 或要素 (3.41) 满足定义的要求､探测其安全异常 (3.134)､确认要求适用于给定的环境和对其行为建立信心，而进行计划､准备､运行或演练的过程。
解读
- 通过运行相关项或要素，验证要求达成、探测安全异常的过程，是功能安全验证的核心手段。示例：硬件环境应力测试、软件单元测试、整车安全场景测试。
3.170 牵引车（tractor）
英文
-
- tractor
原定义
-
- 用来牵引半挂车 (3.151) 的卡车 (3.174)。
解读
- 专门用于牵引半挂车的卡车，具备牵引半挂车的专用接口和动力性能，是半挂运输系统的动力核心。示例：牵引集装箱半挂车的重型牵引车。
3.171 挂车（trailer）
英文
-
- trailer
原定义
-
- 设计上需被牵引且总质量的大部分不由牵引车辆承担的道路车辆。注：挂车可设计用于运输货物､设备或人员。
解读
- 需被牵引行驶、自身不承担大部分质量的车辆，分为全挂车、半挂车等，用于扩展运输能力。示例：货运全挂车、旅居挂车。
3.172 转换器（transducer）
英文
-
- transducer
原定义
-
- 将一种形式的能量转换成另一种形式的能量的硬件元器件 (3.71), 其灵敏度决定了其输出能量形式的大小相对于其输入能量形式的大小。
解读
- 能量转换类硬件元器件，核心是实现不同能量形式的转换，灵敏度是其关键性能指标。示例：传感器（物理量→电信号）、执行器（电信号→机械运动）。
3.173 瞬态故障（transient fault）
英文
-
- transient fault
原定义
-
- 发生一次且随后消失的故障 (3.54)。注：瞬态故障可由电磁干扰引起，其可导致位翻转｡软错误 (3.46), 如单粒子翻转 (SEU) 和单粒子瞬态 (SET), 均为瞬态故障。
解读
- 短暂发生后自行消失的故障，多由电磁干扰、粒子辐射等引起，可能导致数据错误但不损坏硬件。示例：电磁干扰导致的传感器数据位翻转、单粒子翻转导致的寄存器数据错误。
3.174 卡车（truck）
英文
-
- truck
原定义
-
- 设计用于运输货物或在底盘上装有设备的机动车。注：卡车也可以牵引一辆挂车 (3.171)。
解读
- 核心用途为货物运输或搭载作业设备的机动车，可牵引挂车，涵盖轻、中、重型货运车辆。示例：轻型皮卡、重型货运卡车、消防车（搭载作业设备的卡车）。
3.175 T&B 车辆配置（T&B vehicle configuration）
英文
-
- T&B vehicle configuration
原定义
-
- T&B 的基础车辆 (3.9) 和车辆上装设备 (3.12) 的技术特性，这些特性在运行期间不会发生改变。注：在重建 (3.121) 时可能发生改变。示例：轴距，轴荷分布，车轮 (车轴数量､驱动轴数量､转向轴数量)。
解读
- T&B 车辆（卡车、客车、挂车、半挂车）的基础车辆与上装设备的固定技术特性，运行中保持不变，重建时可修改。示例：货车的轴距、轴荷分布、驱动轴数量。
3.176 不合理的风险（unreasonable risk）
英文
-
- unreasonable risk
原定义
-
- 按照现行的安全观念，被判断为在某种环境下不可接受的风险 (3.128)。
解读
- 基于当前安全认知和技术水平，被判定为不可接受的风险，是功能安全需通过技术和流程重点防控的对象。示例：高速行驶中制动系统突然失效的风险，属于不合理风险。
3.177 T&B 车辆使用的变化（variance in T&B vehicle operation）
英文
-
- variance in T&B vehicle operation
原定义
-
- 在车辆寿命期内受货物或牵引的影响，使用的 T&B 车辆具有不同的动态特性。示例：有载荷或无载荷的 T&B, 载荷分布变化的 T&B, 带或不带挂车 (3.171) 的卡车 (3.174), 带或不带半挂车 (3.151) 的牵引车 (3.170)(单独的牵引车 (3.170))。
解读
- T&B 车辆在使用过程中，因载荷、牵引状态变化导致的动态特性差异，需在安全设计中考虑。示例：满载与空载货车的制动距离差异、带挂车与单独牵引车的操控特性差异。
3.178 整车功能（vehicle function）
英文
-
- vehicle function
原定义
解读
- 用户可感知的车辆整体行为，由一个或多个相关项协同实现，是功能安全的最终保护对象。示例：自动巡航控制、自动紧急制动、转向辅助。
3.179 车辆运行状态（vehicle operating state）
英文
-
- vehicle operating state
原定义
-
- 与运行场景 (3.104) 结合的运行模式 (3.102)。注：车辆的运行状态是由当前行驶情况下 (例如以 120km/h 行驶在高速公路上) 特定功能 (例如高度自动驾驶) 提供的性能所决定的｡危害事件 (3.77) 的 ASIL (3.6) 等级 (例如特定功能的突然丧失) 取决于当前的车辆运行状态 (例如高度自动驾驶能力的突然丧失，在高速行驶时就比在低速行驶时更为危险)。如果系统 (3.163) 不在运行中，即当驾驶员在操控车辆时系统 (3.163) 发生失效，则在高速情况下突然丧失高度自动驾驶能力并不是问题。
解读
- 运行模式与运行场景的组合，直接影响危害事件的风险等级，是 ASIL 等级确定的重要依据。示例：“高速行驶（场景）+ 高度自动驾驶（模式）” 的运行状态，ASIL 等级高于 “低速行驶 + 高度自动驾驶”。
3.180 验证（verification）
英文
-
- verification
原定义
-
- 确定检查对象是否满足其特定要求。示例：典型的验证活动可以分为以下几类: -- 验证评审 (3.181), 走查 (3.182), 检查 (3.82); -- 验证测试 (3.169);-- 仿真模拟；-- 原型样机；及 -- 分析 (安全 (3.132) 分析､控制流分析､数据流分析等)。
解读
- 通过评审、测试、分析等方式，确认对象满足特定要求的过程，核心是 “是否做对了”。示例：软件单元验证（是否满足单元要求）、硬件设计验证（是否满足硬件安全要求）。
3.181 验证评审（verification review）
英文
-
- verification review
原定义
-
- 确保开发活动结果满足项目要求和 / 或技术要求的验证 (3.180) 活动。注 1: 验证评审的单独要求在 GB/T 34590 的单独部分中的特定章条中给出。注 2: 验证评审的目标是确认相关项 (3.84) 或要素 (3.41) 的技术正确性和完整性。示例：验证评审类型可以是技术评审 (3.127)､走查 (3.182)､检查 (3.82)。
解读
- 聚焦技术正确性和完整性的评审活动，是验证的重要形式，确保开发成果满足项目和技术要求。示例：软件架构技术评审、硬件设计走查、测试方案检查。
3.182 走查（walk-through）
英文
-
- 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)。
解读
- 由开发者主导的、非运行式的工作成果检查，旨在建立共同理解并发现安全异常，严格性低于正式检查。示例：软件代码走查、需求文档走查。
3.183 报警和降级策略（warning and degradation strategy）
英文
-
- warning and degradation strategy
原定义
-
- 如何将潜在降低的功能向驾驶员报警及如何提供降低的功能以达到安全状态 (3.131) 的定义。注：报警和降级策略包括:-- 触觉､声音或视觉提示的说明，以提醒驾驶员即将发生的降级 (3.28);-- 与相应的安全目标 (3.139) 相关的一个或多个安全状态 (3.131) 的描述；-- 向安全状态 (3.131) 过渡的条件；-- 从安全状态 (3.131) 恢复的条件，以及如果适用，相应的最长待修复时间间隔 (3.89); 及 -- 如果适用，紧急运行 (3.43) 和相应的紧急运行容错时间间隔 (3.45);
解读
- 故障后的安全响应策略，明确报警方式（声光 / 触觉）、降级规则、安全状态过渡条件及恢复机制，是故障处理的核心依据。示例：传感器故障后，通过仪表报警（视觉提示），自动驾驶系统从 L3 降级为 L2，直至车辆静止（安全状态）。
3.184 值得信赖的（well-trusted）
英文
-
- well-trusted
原定义
-
- 此前在类似的应用中使用过，且没有已知的安全异常 (3.134)。示例：值得信赖的设计原则､值得信赖的工具､值得信赖的硬件组件 (3.21)。
解读
- 在类似应用中经实践验证、无安全异常记录的设计、工具或组件，可降低开发风险。示例：在多款车型中使用且无安全问题的 MCU 芯片、成熟的故障诊断算法。
3.185 工作成果（work product）
英文
-
- work product
原定义
-
- 由 GB/T 34590 中一个或多个相关要求得出的文档。注：文档可以是包含工作成果完整信息的单个文档，也可以是包含工作成果完整信息的一系列文档。
解读
- 功能安全活动的输出文档，是安全档案的组成部分，需完整记录安全活动的过程和结果。示例：安全目标文档、风险评估报告、测试报告、安全确认报告。
欢迎关注、点赞与转发
阅读全文
