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

好，咱们进入第二章。这一章讲的是危害识别的方法论。说白了，就是怎么把潜在的危险一个个揪出来。

很多新手工程师上来就做HARA，结果漏了一堆危害。为什么？因为边界没划清楚，场景没想全。我刚开始带项目时就吃过这个亏，后来才明白——没有清晰的方法论，HARA就是瞎蒙。

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

做危害识别之前，第一件事是什么？定义系统边界。你得知道你的系统管什么、不管什么。

我个人习惯用系统边界图来干这事。画一个方框，里面是你的系统，外面是相关项、环境、其他系统。然后标清楚：

• 输入接口：传感器信号、CAN/LIN总线消息、用户操作
• 输出接口：执行器指令、显示信息、通信报文
• 外部依赖：供电、通信、机械连接

举个例子。我在做EPS（电动助力转向）项目时，一开始只把转向控制器当作系统。后来发现，转向管柱的机械特性、方向盘的角度传感器、甚至轮胎的摩擦系数都会影响危害。于是我把边界扩大到包含整个转向系统。

你想想看，如果边界画小了，危害分析就会漏掉关键因素。比如转向助力突然消失，原因可能是控制器故障，也可能是传感器信号丢失。边界没包含传感器，你就分析不到这个失效模式。

2.2 功能失效模式分析——把功能拆开看

边界画好了，接下来分析功能失效模式。这里我推荐用功能树 + 失效模式表的组合拳。

先列出系统的所有功能。比如一个ACC（自适应巡航）系统，功能包括：

• 目标车辆检测
• 跟车距离控制
• 车速调节
• 驾驶员接管提示

然后对每个功能，分析它的失效模式。常用的分类是：

失效类别	说明	示例（ACC跟车功能）
功能丧失	功能完全不工作	无法检测到前车
功能异常	功能工作但输出错误	跟车距离计算错误
功能误触发	不该工作时却工作	前方无车却突然减速
功能时序错误	功能执行顺序或时机不对	减速指令发出太晚

嗯，这里要注意。很多工程师只分析“功能丧失”和“功能异常”，忽略了“误触发”和“时序错误”。我在项目中遇到过，一个误触发的危害等级往往比功能丧失还高。比如ACC突然刹车，后车追尾的风险比ACC不工作大多了。

2.3 运行场景与操作模式识别——把车开上路

功能失效模式分析完了，接下来要问：这些失效在什么情况下会发生？会造成什么后果？

这就是运行场景分析。ISO 26262要求我们考虑：

• 运行模式：车辆处于什么状态？启动、行驶、停车、充电？
• 环境条件：天气、路况、光照、温度？
• 用户行为：驾驶员在做什么？加速、刹车、转向、分心？
• 系统状态：系统处于正常模式、降级模式、诊断模式？

我建议用场景矩阵来系统化分析。把运行模式、环境条件、用户行为组合起来，形成一个个具体的场景。

运行模式	环境条件	用户行为	场景描述
高速行驶	夜间、雨天	驾驶员正常驾驶	ACC在夜间雨天高速跟车
城市低速	白天、拥堵	驾驶员频繁启停	ACC在城市拥堵路况跟停
弯道行驶	干燥、良好	驾驶员转向中	ACC在弯道中检测目标

为什么会这样？因为同一个失效在不同场景下，危害等级完全不同。比如ACC跟车距离计算错误，在高速上可能导致追尾，在拥堵路况可能只是轻微碰撞。所以场景分析直接影响危害等级的判定。

2.4 方法论总结——三步走

好了，把这一章的内容串起来。做危害识别，我建议按这个流程走：

1. 画边界：定义系统范围，明确输入输出和外部依赖
2. 拆功能：列出所有功能，分析每个功能的失效模式
3. 定场景：组合运行模式、环境条件、用户行为，形成具体场景

这三步走完，你就能得到一份完整的危害清单。每个危害都对应一个具体的功能失效和一个具体的运行场景。后面做风险评估和ASIL等级判定，就靠这份清单了。

我个人习惯把这三步的结果整理成一个表格，叫危害识别工作表。每一行就是一个危害，包含：功能、失效模式、场景、潜在后果。这样后续分析起来一目了然。

下一章，咱们讲危害评估与ASIL等级判定。到时候你会看到，同样的危害，在不同场景下ASIL等级可能差好几个级别。嗯，那才是真正考验功力的时候。