2. 功能安全基础概念：危险、风险、安全目标、安全状态、安全机制、故障与失效模式

各位同学，今天我们聊点真正的基础。功能安全里有一堆术语，听起来很像，但差一个字意思就全变了。我刚开始接触ISO 26262时，也经常把“故障”和“失效”混着用，结果被评审老师当场纠正，挺尴尬的。

这一节，我们就把这些概念一个一个掰开揉碎。你搞懂了它们，后面的ASIL等级、安全分析、验证测试，才能站得住脚。

2.1 危险（Hazard）与风险（Risk）

先说危险。危险是潜在伤害的源头。在汽车里，危险通常由系统的功能异常引发。比如：

• 车辆意外加速
• 制动助力突然失效
• 转向角度信号错误

这些都是危险事件。注意，危险本身不是事故，它是“可能导致事故的条件”。

那风险呢？风险 = 危险的严重度 × 发生概率。说白了，就是“这事儿有多坏”乘以“这事儿多容易发生”。

我做过一个项目，客户说“这个功能有风险”，我追问“什么风险？严重度多少？概率多高？”他答不上来。嗯，这就是把概念混了。风险必须能度量，否则没法管理。

2.2 安全目标（Safety Goal）

安全目标，是ISO 26262的核心输出之一。它是对每个危险事件提出的最高层级安全要求。

举个例子：

• 危险事件：车辆在高速行驶时，非预期的动力中断导致追尾
• 安全目标：防止非预期的动力中断（ASIL D）

每个安全目标都带一个ASIL等级（A、B、C、D）。这个等级决定了后续开发工作的严格程度。

2.3 安全状态（Safe State）

安全状态，是系统在检测到故障后，进入的一个不会导致危害的状态。

常见的例子：

• 电机控制器检测到过流 → 进入“关断输出”状态
• 制动系统检测到传感器失效 → 进入“机械备份制动”模式
• ADAS摄像头被遮挡 → 进入“降级模式”，提示驾驶员接管

安全状态不一定是“停机”。有时候是“降级运行”，有时候是“切换到冗余通道”。

2.4 安全机制（Safety Mechanism）

安全机制，是实现安全目标、达到或维持安全状态的技术手段。它是功能安全设计的“落地层”。

常见的安全机制包括：

安全机制类型	示例	说明
故障检测	看门狗定时器、ECC校验	发现故障的存在
故障响应	故障指示灯、降级模式切换	对故障做出反应
故障避免	冗余设计、物理隔离	从设计上防止故障发生
故障容错	双通道比较、三模冗余	即使有故障，系统仍能正常工作

安全机制不是越多越好。每加一个机制，都会增加成本和复杂度。我见过一个项目，为了安全加了五个看门狗，结果系统反而因为看门狗之间的冲突频繁复位。嗯，过度设计也是问题。

2.5 故障（Fault）与失效模式（Failure Mode）

这两个词最容易混淆。我直接说清楚：

• 故障：异常状态。比如电阻短路、软件跑飞、传感器漂移。故障是“因”。
• 失效：功能丧失。比如刹车踩不下去、转向没反应。失效是“果”。
• 失效模式：失效的具体表现形式。比如“输出卡在高电平”、“输出无响应”、“输出超时”。

举个例子：

• 故障：MCU内部RAM的某一位 stuck-at-0
• 失效：安全气囊控制单元无法计算点火逻辑
• 失效模式：安全气囊在碰撞时未展开

在FMEA（失效模式与影响分析）中，我们分析的就是“失效模式”及其影响。在FMEDA（失效模式影响与诊断分析）中，我们进一步量化每种失效模式的概率和诊断覆盖率。

2.6 概念关系图

下面这张图，把上面这些概念串起来了。你顺着箭头看，就能理解功能安全设计的完整逻辑链。

2.7 避坑指南

最后，分享几个我踩过的坑：

• 别把“故障”当“失效”写进安全目标。安全目标应该描述“防止什么失效”，而不是“检测什么故障”。故障是手段，失效才是结果。
• 安全状态要可验证。我曾经写过一个安全状态叫“系统进入安全模式”，但没定义“安全模式”是什么。评审时被问“你怎么测试这个状态？”我答不上来。
• 安全机制不是越多越好。每加一个机制，都要做额外的诊断和测试。过度设计反而引入新的故障模式。
• 失效模式要写具体。“输出异常”这种描述太笼统。要写“输出卡在高电平”、“输出在100ms内无响应”这种可测量的描述。