第2章：功能安全基础概念
各位同学好，我是老张。今天咱们聊聊功能安全里最基础、也最容易混淆的几个概念。说实话，我见过不少工程师干了三五年，对「故障」和「失效」的区别还是模棱两可。这章咱们就把这些概念掰开揉碎了讲清楚。
2.1 功能安全到底是什么？
功能安全，说白了就是「系统出错了也不会害人」。你想想看，一辆车在高速上跑着，刹车系统突然失灵——这不是小事。功能安全要做的，就是确保即使系统内部出了毛病，它也能安全地停下来，或者至少不会造成人员伤亡。
我个人习惯把功能安全理解成「系统的最后一道防线」。它不是让系统不出错，而是让系统在出错时，后果可控。
核心定义：功能安全是指不存在由电子电气系统故障行为引起的、不合理的风险。
2.2 安全目标
安全目标，是功能安全设计的「北极星」。每个系统都要先问自己：我最怕什么？
举个例子，电动助力转向系统。它的安全目标可能是：「转向系统不能在没有驾驶员指令的情况下自行转动」。听起来很简单对吧？但为了实现这个目标，你可能需要双路传感器、冗余控制器、故障诊断逻辑……
我在项目中遇到过，有些团队一上来就画架构图、写代码，结果评审时才发现安全目标根本没定义清楚。嗯，这就像盖房子没图纸，后面全是坑。
我的建议：安全目标一定要用「不能」句式来写。比如「不能非预期加速」「不能丢失制动能力」。这样后续的验证才有明确的通过标准。
2.3 安全状态
安全状态，就是系统「认怂」之后的样子。当系统检测到故障，它要主动进入一个不会造成伤害的状态。
常见的几种安全状态：
- 切断动力：比如电机控制器检测到过流，直接关断功率管
- 降级运行：比如雷达失效，ADAS系统退回到仅限摄像头工作的模式
- 保持最后有效状态：比如电子油门卡在当前位置，不再响应新指令
这里有个容易踩的坑——安全状态本身也要安全。我曾经见过一个设计，系统故障后进入「紧急制动」状态，结果在高速上直接刹停，反而造成了追尾。所以安全状态的选择，一定要结合具体的场景来评估。
注意：安全状态不是万能的。有些故障发生后，系统可能无法进入安全状态（比如转向柱卡死）。这时候就需要其他安全机制，比如冗余备份。
2.4 故障、错误、失效——三兄弟的区别
这三个词，我敢说80%的工程师都混着用。咱们今天一次性理清楚。
| 术语 | 定义 | 打个比方 |
|---|---|---|
| 故障 | 物理层面的异常，比如电阻短路、芯片引脚虚焊 | 就像水管上有个砂眼 |
| 错误 | 信息层面的偏差，比如计算结果是错的 | 水从砂眼里漏出来了 |
| 失效 | 功能层面的丧失，比如系统不工作了 | 整个水管系统瘫痪了 |
它们的关系是：故障 → 错误 → 失效。故障是原因，错误是表现，失效是结果。
你想想看，一个电阻短路（故障），导致ADC采样值错误（错误），最终让电机失控（失效）。这就是一条完整的因果链。
我记得有一次做FMEA分析，有个同事把「软件跑飞」直接归类为故障。我说不对，软件跑飞是错误，它的故障可能是看门狗没喂好，或者堆栈溢出了。搞清楚这个层次，你才能找到真正的根因。
2.5 危险事件
危险事件，就是「故障 + 场景」的组合。同一个故障，在不同场景下，危险程度天差地别。
举个例子：
- 场景A：车辆静止时，刹车突然失效 → 危险程度低
- 场景B：车辆以120km/h行驶时，刹车突然失效 → 危险程度极高
所以ISO 26262里评估风险，不是只看故障本身，而是要看「故障发生在什么场景下」。这就是为什么我们要做危害分析与风险评估（HARA）。
关键点：危险事件 = 危害 + 运行场景 + 操作模式。三个要素缺一不可。
我个人习惯在做HARA时，先列出所有可能的运行场景，再逐一分析每个场景下系统故障会带来什么后果。这样不容易遗漏。
2.6 几个容易混淆的点
最后，我给大家总结几个我经常被问到的问题：
- 「安全目标」和「功能需求」有什么区别？
安全目标关注的是「不能发生什么」，功能需求关注的是「系统要做什么」。前者是约束，后者是能力。 - 「安全状态」一定是停机吗？
不一定。有些系统需要保持运行，比如转向系统如果停机，反而更危险。安全状态可以是降级运行。 - 「故障」和「失效」能互换使用吗？
不能。在ISO 26262里，这两个词有严格区分。写文档时用错了，评审专家一眼就能看出来。
避坑指南：我曾经在项目文档里把「故障」和「失效」混着写，结果被客户审核时打了回来。从那以后，我每次写文档都会专门检查一遍术语的使用。建议你也养成这个习惯。
好了，这一章的内容就到这里。下一章咱们聊聊ASIL等级是怎么确定的，那才是真正烧脑的部分。