第3章危害识别方法

第3章：危害识别方法

危害识别，说白了就是回答一个问题：这玩意儿到底会怎么出问题？

我做了这么多年功能安全，见过太多团队一上来就拍脑袋想危害。结果呢？漏掉关键场景，后期返工改得想哭。所以这一章，咱们把方法论掰开揉碎，讲清楚。

3.1 系统边界定义

你想想看，连系统边界都没画清楚，你怎么知道哪些东西归你管？

我个人习惯，第一步先画一张系统上下文图。这张图里要标清楚：

系统本身（比如一个EPS控制器）
外部实体（驾驶员、其他ECU、传感器、执行器）
交互的信号流（CAN信号、硬线信号、电源）

举个例子。我之前做电动助力转向系统（EPS）时，边界图长这样：

+------------------+       CAN信号       +------------------+
|   驾驶员输入      | <----------------> |   EPS控制器       |
| (方向盘扭矩)      |                    | (ECU + 电机驱动)  |
+------------------+                    +------------------+
        |                                        |
        | 扭矩传感器信号                          | PWM控制
        v                                        v
+------------------+                    +------------------+
|   扭矩传感器      |                    |   助力电机       |
+------------------+                    +------------------+

边界定义有个坑，我提醒一下：别把供电系统漏了。有一次项目，大家只关注信号交互，结果12V电源波动导致电机误动作，危害分析里根本没覆盖到。嗯，后来补的。

我的小技巧：边界图里用虚线框标出「系统内部」，实线框标出「外部环境」。这样开会时大家一眼就能分清责任范围。

3.2 功能定义

边界画好了，接下来要问：这系统到底要干什么？

功能定义不是写说明书，而是把每个功能拆到原子级。我习惯用功能列表+功能描述表的方式：

功能ID	功能名称	功能描述	触发条件	系统响应
F01	基础助力	根据驾驶员扭矩输入，提供相应助力	驾驶员转动方向盘	电机输出扭矩
F02	回正控制	车辆转弯后，主动将方向盘回正	车速>0，方向盘偏离中心	电机反向扭矩
F03	故障降级	检测到系统故障时，降低或关闭助力	故障标志位置位	限制电机输出

这里有个关键点：每个功能都要写清楚「正常行为」和「异常行为」。比如基础助力，正常是「扭矩随角度线性增加」，异常可能是「扭矩突然消失」或「扭矩反向输出」。

注意：功能定义不要写得太抽象。我曾经见过一个团队写「系统应保证安全」，这种话等于没写。要具体到「当车速超过80km/h时，助力增益降低50%」这种程度。

3.3 运行场景分析

功能定义完了，接下来要问：这功能在什么情况下会出问题？

运行场景分析，说白了就是给系统找茬。我一般从三个维度来拆：

车辆状态：静止、低速、高速、倒车、转弯
环境条件：白天/黑夜、晴天/雨天/雪天、高温/低温
驾驶员行为：正常驾驶、紧急避让、疲劳驾驶、误操作

举个例子。对于EPS的「基础助力」功能，我可能会列出这些场景：

车辆在高速公路上直线行驶，驾驶员轻微修正方向
车辆在冰雪路面低速转弯，轮胎打滑
车辆在停车场倒车入库，驾驶员快速打方向
车辆在暴雨中行驶，路面有积水

你可能会问：为什么要分析这么多场景？

因为同一个故障，在不同场景下造成的后果完全不同。比如助力突然消失，在高速上可能只是手感变重，但在停车场倒车时可能直接撞墙。

  我的经验：运行场景分析至少要做20-30个场景。别嫌多，漏掉一个场景，后期可能要多花两周补危害分析。

3.4 危害识别技术

好了，边界、功能、场景都准备好了。现在进入核心环节：怎么找出危害？

我常用的方法有三种，各有各的适用场景。

3.4.1 头脑风暴

头脑风暴，说白了就是一群人坐在一起，天马行空地想「这玩意儿会怎么坏」。

我个人习惯，头脑风暴要遵守几个规则：

不批评：任何想法都先记下来，哪怕听起来很离谱
数量优先：先求多，再求好
跨职能参与：系统工程师、软件工程师、硬件工程师、测试工程师都要来

我记得有一次做ADAS的HARA，头脑风暴时一个硬件工程师说「如果摄像头被泥巴糊住了呢？」。当时大家都笑了，觉得这概率太低。结果后来路试时，还真遇到了泥水飞溅导致摄像头遮挡的情况。嗯，从那以后我再也不敢小看任何「离谱」的想法。

3.4.2 检查表

检查表，就是把你以前踩过的坑、行业里常见的危害，整理成一张清单。每次做新项目时，对着清单一项一项过。

我自己的检查表里，长期保留这些条目：

检查项	典型危害	示例
传感器失效	信号丢失、信号漂移、信号卡滞	扭矩传感器输出固定值
执行器失效	卡死、空转、响应延迟	电机堵转不输出扭矩
通信故障	丢帧、延迟、数据错误	CAN总线负载过高导致丢帧
电源异常	欠压、过压、掉电	蓄电池老化导致电压波动
软件逻辑错误	状态机跑飞、时序错乱、溢出	看门狗超时未喂狗

建议：检查表要持续更新。每做完一个项目，把新发现的危害加进去。三年下来，你的检查表就是最值钱的资产。

3.4.3 HAZOP

HAZOP，全称是Hazard and Operability Study。这方法听起来高大上，其实核心就一句话：用引导词去挑战每个功能。

常用的引导词包括：

无：功能完全不执行
多：功能执行过度
少：功能执行不足
反向：功能反向执行
早/晚：功能执行时机错误
错误：功能执行了不该执行的动作

拿EPS的「基础助力」功能举例，用HAZOP走一遍：

引导词	偏差描述	潜在危害
无	驾驶员转动方向盘，但电机不输出助力	转向沉重，驾驶员可能无法完成避让
多	电机输出助力过大，超过驾驶员预期	车辆过度转向，驾驶员失去控制
少	电机输出助力不足，转向手感变重	驾驶员疲劳，紧急情况下反应变慢
反向	驾驶员向左转，电机向右输出助力	车辆转向与驾驶员意图相反，严重事故
早	驾驶员还没打方向，电机就开始助力	方向盘自行转动，驾驶员措手不及
晚	驾驶员打方向后，助力延迟输出	转向响应迟钝，影响操控

你看，用HAZOP走一遍，基本上所有可能的危害都覆盖到了。我特别喜欢这个方法，因为它系统性强，不容易漏项。

避坑指南：我曾经见过一个团队，HAZOP分析时只用了「无」和「多」两个引导词，结果漏掉了「反向」这个关键危害。后来实车测试时发现了反向助力的问题，差点导致项目延期。所以，所有引导词都要过一遍，一个都不能少。

3.5 三种方法的搭配使用

你可能会问：这三种方法，到底用哪个？

我的建议是：组合使用。

第一步：头脑风暴，快速产出大量候选危害，别管质量，先求数量
第二步：检查表，用历史经验查漏补缺，看看有没有遗漏的常见危害
第三步：HAZOP，系统性地过一遍所有功能，确保每个偏差都被覆盖

这样走下来，基本上不会漏掉什么。我这些年做过的项目，用这套组合拳，HARA评审都是一次过。

  最后说一句：危害识别不是一次性工作。随着项目推进，你会发现新的场景、新的故障模式。所以，保持迭代，别想着一步到位。

好了，这一章就到这里。下一章咱们讲危害评估与ASIL等级确定，到时候我会分享一个让我印象深刻的案例——一个看起来人畜无害的故障，最后评出了ASIL D。

📚 课程目录