2、危害识别方法：系统边界定义、功能失效分析、运行场景与模式识别

好，咱们进入第二章。这一章讲的是危害识别，说白了就是回答一个问题：我的系统到底会怎么出问题？

我刚开始做HARA时，最头疼的就是这一步。系统那么大，功能那么多，从哪下手？后来我发现，只要把三件事做扎实了，危害识别就不会漏：边界定义、功能失效分析、场景与模式识别。咱们一个一个来。

2.1 系统边界定义：先画个圈

你想想看，一个嵌入式系统，尤其是汽车电子里的ECU，它从来不是孤立的。它连着传感器、执行器、总线网络，甚至还有云端。如果不先画清楚边界，分析起来就像在迷雾里开车——根本不知道哪些东西归你管。

我个人习惯，第一步先画一张系统框图。这张图要明确三样东西：

• 系统内部：我们正在开发的硬件、软件、算法
• 外部接口：电源、CAN/LIN/以太网、传感器输入、执行器输出
• 交互对象：驾驶员、其他ECU、云端服务器、诊断工具

举个例子，我做过一个电动尾门控制器。它的边界怎么定义？

边界类型	具体内容
物理边界	控制器外壳、连接器引脚
电气边界	12V电源、GND、CAN总线、霍尔传感器信号
功能边界	尾门开启/关闭、防夹、位置记忆
时间边界	上电初始化时间、响应时间、休眠唤醒周期

2.2 功能失效分析：从“正常”到“不正常”

边界画好了，接下来就要看每个功能如果失效了会怎样。这里我推荐用功能失效树的思路，但不用画得太复杂。

核心就三个问题：

1. 这个功能如果不工作了，会怎样？（功能丧失）
2. 这个功能如果乱工作，会怎样？（功能异常）
3. 这个功能如果部分工作，会怎样？（功能降级）

我在项目中遇到过一个典型的例子：刹车灯控制。正常功能是踩刹车时灯亮。我们分析它的失效模式：

• 功能丧失：踩刹车灯不亮 → 后车追尾风险
• 功能异常：没踩刹车灯却亮了 → 后车误判，急刹导致追尾
• 功能降级：亮度只有正常的一半 → 白天可能看不清，夜间勉强可用

你看，同一个功能，三种失效模式，对应的危害等级完全不同。功能异常往往比功能丧失更危险——因为它是误导性的。

2.3 运行场景与模式识别：别在实验室里想问题

这是很多人容易忽略的一步。你想想看，一个功能在实验室里跑得好好的，到了实际场景中可能完全不是那么回事。

运行场景包括：

• 环境条件：高温、低温、雨雪、强电磁干扰
• 车辆状态：静止、低速、高速、转弯、颠簸路面
• 用户行为：正常操作、误操作、恶意操作

运行模式则是指系统自身的工作状态：

• 上电模式、正常运行模式、休眠模式、诊断模式、故障降级模式

我给你们看一个实际案例。还是那个电动尾门控制器，它的运行模式表：

模式	触发条件	关键行为	危害关注点
上电模式	车辆解锁	自检、初始化	误动作导致尾门突然打开
正常运行	用户按键	电机驱动、防夹检测	防夹失效、夹伤手指
休眠模式	车辆锁车后5分钟	低功耗、CAN唤醒	无法唤醒、尾门打不开
故障模式	电机过流	停止动作、上报故障码	停止后尾门悬在半空

我曾经犯过一个错：只分析了正常运行模式下的危害，忽略了上电模式。结果有客户反馈，车辆解锁瞬间尾门自己弹开了——还好当时没人站在后面。从那以后，我每个模式都会单独过一遍。

2.4 三者如何联动？

好，现在我们把三件事串起来。我的做法是：

1. 先定义边界：知道哪些东西归我管，哪些是外部依赖
2. 再分析失效：对边界内的每个功能，列出三种失效模式
3. 最后套场景：把每个失效模式放到不同的运行场景和模式里，看它会不会变得更危险

举个例子，还是刹车灯：

• 边界定义：刹车灯控制器、刹车踏板传感器、CAN总线
• 失效分析：灯常亮（功能异常）
• 场景套用：夜间高速行驶 + 灯常亮 → 后车误判为刹车，追尾风险极高

你看，同一个失效，在白天低速场景下可能只是“有点烦”，到了夜间高速就成了“致命危害”。这就是为什么场景识别这么重要。

好了，这一章的内容就这些。下一章我们会讲危害等级评定——也就是怎么给这些危害打分，决定哪些需要优先处理。到时候见。