📚 课程目录第4章关键术语与定义

关键术语与定义：ASIL、安全目标、安全需求、安全机制、故障、失效、错误、冗余等核心术语

在ISO 26262《道路车辆—功能安全》标准中，术语体系是整个标准大厦的基石。无论是进行危害分析与风险评估（HARA）、制定安全目标，还是设计安全机制、开展安全确认，都离不开对这些核心术语的精确理解。实践中，工程师常将“故障”“失效”“错误”混为一谈，或将“安全目标”与“安全需求”等同使用，这些概念混淆轻则导致文档评审返工，重则使安全架构设计偏离正确方向，埋下系统性安全隐患。本章将围绕ASIL、安全目标、安全需求、安全机制、故障、失效、错误、冗余这八大核心术语，从定义、判定方法、工程应用到常见误区进行系统解析。

4.1 ASIL：汽车安全完整性等级

核心原理：ASIL（Automotive Safety Integrity Level，汽车安全完整性等级）是ISO 26262中用于定义安全要求等级的核心概念，分为ASIL A、ASIL B、ASIL C、ASIL D四个等级，其中ASIL D为最高等级，要求最严苛。此外，QM（Quality Management，质量管理）表示无需按功能安全流程开发，仅需满足一般质量管理要求。ASIL等级由三个参数共同决定：严重度（Severity, S）——对驾驶员、乘客或其他道路使用者造成伤害的程度；暴露概率（Exposure, E）——车辆处于可能发生危害的场景中的概率；可控性（Controllability, C）——驾驶员或其他人员能够避免伤害的能力。三者组合查表得到ASIL等级。

判断方法或操作流程：在项目早期，功能安全经理需组织HARA（Hazard Analysis and Risk Assessment，危害分析与风险评估）会议，按以下流程确定ASIL等级：

场景定义：列出车辆运行场景（如高速行驶、城市拥堵、停车等）和运行模式（如正常驾驶、维修模式、充电模式等）。
危害识别：分析系统功能异常时可能导致的危害事件（如“车辆非预期加速”）。
参数评估：对每个危害事件分别评估S、E、C参数，每个参数分为0-3级。
等级查表：根据ISO 26262-3:2018 表1，将S、E、C组合映射为ASIL等级或QM。
安全目标导出：为每个危害事件定义安全目标，并继承对应的ASIL等级。

严重度 S	暴露概率 E	可控性 C	ASIL 等级
S1（轻伤）	E1（极低）	C1（简单可控）	QM 或 ASIL A
S2（重伤）	E2（低）	C2（一般可控）	ASIL B 或 C
S3（致命）	E3（高）	C3（难以控制）	ASIL D

经验提醒：ASIL等级不是越高越好。ASIL D虽然安全性最高，但开发成本、验证难度和复杂度也急剧上升。合理的做法是：在满足安全目标的前提下，通过架构设计（如安全机制、冗余）尽量降低单个组件的ASIL等级要求，实现安全与成本的平衡。

4.2 安全目标与安全需求

核心原理：安全目标（Safety Goal）是系统层面最高层级的安全要求，描述“为避免特定危害事件而必须满足的行为或状态”，通常以“避免……发生”的句式表达，例如“避免车辆在行驶过程中非预期加速”。安全目标继承自HARA，并分配ASIL等级。安全需求（Safety Requirements）则是从安全目标细化而来的、可实施、可验证的具体技术要求，分为功能安全需求（Functional Safety Requirements, FSR）、技术安全需求（Technical Safety Requirements, TSR）和软件安全需求（Software Safety Requirements, SSR）三个层级。

判断方法或操作流程：从安全目标到安全需求的分解遵循“自上而下、逐层细化”的原则：

安全目标→功能安全需求：定义系统层面的功能行为，不涉及具体硬件或软件实现。例如安全目标“避免非预期加速”，对应的FSR为“当驾驶员未踩加速踏板时，系统应禁止输出驱动扭矩”。
功能安全需求→技术安全需求：将FSR分配到具体架构元素（如传感器、控制器、执行器），定义技术实现方案。例如TSR为“MCU应在10ms内检测到加速踏板位置传感器信号异常，并进入安全状态”。
技术安全需求→软件安全需求：在软件层面进一步细化，包括算法逻辑、时序要求、内存保护等。

  案例拆解：EPS（电动助力转向）系统安全目标分解

  背景：某EPS控制器在开发过程中，HARA识别出“转向助力突然丧失”危害事件，评估为S2、E3、C2，对应ASIL C。

  安全目标：避免转向助力在行驶过程中突然丧失。

  功能安全需求（FSR-01）：当系统检测到助力电机过流时，应在50ms内降低助力输出至安全水平，并点亮仪表盘警告灯。

  技术安全需求（TSR-01）：电流采样电路应能在5ms内检测到电机相电流超过30A阈值，并触发中断信号给MCU。

  软件安全需求（SSR-01）：MCU中断服务程序应在收到过流中断后10ms内，将PWM占空比降至10%以下。

  复盘：该分解过程确保了每个层级的需求都具备可验证性，且ASIL C等级贯穿始终，任何一层降级都需要重新评估。

4.3 安全机制与冗余

核心原理：安全机制（Safety Mechanism）是为实现或保持安全目标而设计的技术手段，用于检测故障、防止错误传播、或使系统进入安全状态。常见的安全机制包括：自检（Self-Test）、监控（Monitoring）、看门狗（Watchdog）、错误校正码（ECC）、循环冗余校验（CRC）、安全状态控制（Safe State Control）等。冗余（Redundancy）是安全机制的一种重要实现方式，通过重复配置关键组件或信息，使得部分组件失效时系统仍能维持安全功能。冗余分为硬件冗余（如双MCU、双传感器）、信息冗余（如CRC、奇偶校验）、时间冗余（如重复执行计算任务）和软件冗余（如不同算法实现同一功能）。

判断方法或操作流程：选择安全机制和冗余策略时，需遵循以下步骤：

失效模式分析：对每个安全相关组件进行FMEA（失效模式与影响分析），识别可能的故障模式及其影响。
安全机制选型：根据故障模式选择合适的安全机制。例如，针对传感器漂移故障，可采用“合理性检查+双传感器交叉校验”；针对MCU程序跑飞，可采用“看门狗+程序流监控”。
冗余策略确定：当单一安全机制无法达到目标ASIL等级时，引入冗余。例如，ASIL D系统通常要求“单点故障指标（SPFM）≥99%”和“潜伏故障指标（LFM）≥90%”，这往往需要硬件冗余配合诊断机制。
安全状态定义：明确系统检测到故障后应进入的安全状态（如关闭输出、降级运行、切换到备用通道）。

安全机制类型	典型实现	适用故障	ASIL 等级
监控机制	看门狗、程序流监控	MCU死机、程序跑飞	ASIL B-D
信息冗余	CRC、ECC、奇偶校验	数据传输错误、存储位翻转	ASIL A-D
硬件冗余	双MCU锁步、双传感器	硬件永久故障、随机硬件失效	ASIL C-D
时间冗余	重复计算、多周期采样	瞬时干扰、软错误	ASIL A-C

风险说明：冗余并非越多越好。过度冗余会带来成本上升、重量增加、系统复杂度提高，反而可能引入新的故障模式。例如，双传感器交叉校验时，若两个传感器同时受共因因素（如温度漂移）影响，则冗余失效。因此，冗余设计必须考虑共因失效（Common Cause Failure）和级联失效（Cascading Failure）的防护。

4.4 故障、错误与失效

核心原理：这三个术语构成了功能安全中最基本的因果链。故障（Fault）是导致系统行为异常的原因，可以是硬件缺陷（如电阻短路）、软件缺陷（如数组越界）或设计缺陷（如时序冲突）。错误（Error）是故障被激活后系统内部出现的异常状态，例如由于内存位翻转导致计算变量值错误。失效（Failure）是错误传播到系统边界后，系统行为偏离设计意图的结果，例如输出扭矩异常导致车辆非预期加速。理解这一因果链是设计安全机制的基础——安全机制的目标就是在故障发生后、失效发生前，检测并阻断错误传播。

判断方法或操作流程：在工程实践中，区分这三者有助于精准定位问题：

故障分类：按性质分为系统性故障（设计缺陷，如软件bug）和随机硬件故障（如芯片老化、电磁干扰）；按持续时间分为永久故障（如断路）、间歇故障（如接触不良）和瞬时故障（如辐射引起的位翻转）。
错误检测：通过安全机制（如ECC、CRC、范围检查）在错误产生后立即捕获，防止其传播。
失效响应：当错误无法完全避免时，系统应进入安全状态（如降级、停机），确保失效后果可控。

  实战场景：BMS（电池管理系统）电流采样故障链

  初始现象：某BMS在整车测试中偶发“过流保护误触发”，导致车辆行驶中突然切断动力。

  分析过程：

  ① 故障定位：检查电流传感器供电电路，发现电源纹波过大（Vpp=120mV），导致传感器输出信号叠加噪声——这是故障（硬件设计缺陷）。

  ② 错误产生：噪声信号被ADC采样后，电流值在真实值±15A范围内波动——这是错误（异常数据状态）。

  ③ 失效结果：MCU检测到电流超过过流阈值（200A），触发保护逻辑，切断动力——这是失效（系统行为偏离设计意图）。

  解决措施：在传感器供电端增加LC滤波电路（将纹波降至30mV以下），并在软件中增加“连续3次采样均超阈值才触发保护”的确认机制。

  复盘：该案例展示了故障→错误→失效的完整链条。若仅在软件层面增加滤波算法，而不解决硬件电源纹波问题，故障源依然存在，错误仍会以其他形式出现。

4.5 常见误区与总结复盘

误区一：将ASIL等级等同于安全等级。ASIL只反映“需要降低的风险程度”，并不直接衡量系统实际安全性。一个ASIL B系统如果安全机制设计得当，可能比一个ASIL D但安全机制失效的系统更安全。

误区二：安全目标与安全需求混用。安全目标是“做什么”（What），安全需求是“怎么做”（How）。在文档评审中，若安全目标写成了具体实现方案，或安全需求缺失了ASIL继承，都会导致追溯性断裂。

误区三：认为冗余等于双份硬件。冗余的本质是“独立的多条路径”，可以是硬件、软件、信息或时间的冗余。例如，用CRC校验保护CAN报文，虽然只传输一份数据，但通过附加校验信息实现了信息冗余。

误区四：忽视故障、错误、失效的时序关系。安全机制的设计必须考虑“检测时间”与“故障传播时间”的赛跑。如果故障发生后，错误在1ms内就传播为失效，而安全机制需要5ms才能响应，则安全机制无效。

总结复盘：本章八大术语构成了ISO 26262的“语法体系”。ASIL定义了安全等级，安全目标与安全需求定义了“要做什么”，安全机制与冗余定义了“怎么做”，故障、错误、失效定义了“为什么做”。在项目实践中，建议团队建立术语对照表，统一沟通语言；在架构设计阶段，使用本章的术语关系图作为讨论框架，确保每个安全相关决策都能追溯到具体术语和ASIL等级。