2. 危害识别方法论：系统边界定义、功能清单梳理、运行场景分析、危害识别技术
好，咱们进入第二章。这一章，说白了就是教你「怎么把危害找出来」。
很多人一上来就拿着HAZOP表猛填，结果填到一半发现——咦？这个功能到底算不算系统的？那个场景我到底要不要分析？
嗯，我刚开始做HARA时也犯过这毛病。后来带我的老工程师跟我说了一句话，我记到现在：「边界没画清楚，后面全是糊涂账。」
所以这一章，咱们就老老实实把方法论捋一遍。你跟着我的节奏走，保证不绕路。
2.1 系统边界定义：先把「我的地盘」画清楚
系统边界，就是你分析的对象到底管到哪。
举个例子。你分析一个电动助力转向系统（EPS）。那方向盘算不算系统的一部分？转向管柱呢？电机呢？ECU呢？
我个人习惯，先画一张系统上下文图。把系统放在中间，外面画上它跟谁交互——传感器、执行器、人、其他ECU、环境。
为什么要画这个？
因为危害分析只分析「系统内部」的事。外部的东西，比如驾驶员误操作、路面结冰，那是「外部事件」，不是危害本身。但外部事件会触发系统内部的危害。
我在项目中遇到过一件事：一个团队分析ADAS摄像头，把「镜头起雾」当成危害来写。结果评审时被专家怼了——镜头起雾是环境条件，不是系统功能失效。你系统内部能控制起雾吗？不能。那它就不该出现在危害清单里。
所以，定义边界时记住三条：
- 物理边界： 硬件接口在哪？线束、机械连接、通信总线。
- 功能边界： 哪些功能是系统自己实现的？哪些是外部系统提供的？
- 时间边界： 分析哪个运行阶段？上电、运行、下电、故障模式？
画完边界图，你心里就有底了。接下来，咱们梳理功能清单。
2.2 功能清单梳理：别漏掉任何一个「会出事」的功能
功能清单，就是把你系统要干的事，一条一条列出来。
注意，这里说的「功能」不是「功能安全需求」，而是系统级功能。比如：
- 「根据方向盘转角计算目标扭矩」
- 「根据车速调节助力比」
- 「检测转向管柱扭矩传感器信号」
我建议你按功能层级来列：
| 层级 | 说明 | 示例 |
|---|---|---|
| L1 系统级功能 | 用户能感知到的 | 「提供转向助力」 |
| L2 子系统功能 | 内部模块实现的 | 「计算助力扭矩」 |
| L3 组件功能 | 具体硬件/软件做的 | 「读取扭矩传感器ADC值」 |
你想想看，如果你只列了L1的功能，那危害分析就会很粗糙。比如「转向助力失效」——这太笼统了。到底是扭矩计算错了？还是电机没响应？还是传感器坏了？
反过来，如果你只列L3的功能，那清单会爆炸，而且你很难看出系统级的危害。
我个人习惯，至少列到L2。L1用来做场景分析，L2用来做HAZOP，L3留到后面做详细FMEA时再用。
2.3 运行场景分析：在什么情况下会出事？
功能清单有了，接下来要问：这些功能在什么场景下运行？
场景分析，说白了就是「谁、在什么时候、在哪、干什么」。
ISO 26262里把场景分成三类：
- 运行模式： 正常驾驶、泊车、巡航、紧急制动……
- 环境条件： 白天/黑夜、晴天/雨天/雪天、城市/高速/乡村……
- 用户行为： 正常操作、误操作、恶意操作、系统故障时的操作……
我见过最典型的翻车案例：一个团队分析自动紧急制动（AEB）系统，只考虑了「直行场景」。结果量产之后，有用户在弯道上触发AEB，系统直接刹停——后车追尾了。
为什么？因为场景没覆盖「弯道」。弯道时，AEB的触发条件、制动策略都应该不一样。
所以，我建议你做一个场景矩阵：
| 运行模式 | 环境条件 | 用户行为 | 是否分析 |
|---|---|---|---|
| 高速巡航 | 白天、干燥 | 正常驾驶 | 是 |
| 高速巡航 | 夜间、大雨 | 正常驾驶 | 是 |
| 城市拥堵 | 白天、干燥 | 频繁启停 | 是 |
| 泊车 | 地下车库 | 倒车入库 | 是 |
你不需要穷举所有场景。但高风险场景一个都不能漏。怎么判断高风险？看三点：
- 这个场景下，功能失效会不会导致严重伤害？
- 这个场景出现的频率高不高？
- 这个场景下，驾驶员有没有机会补救？
嗯，这里要注意：场景分析不是一次性的。随着项目推进，你会发现新的场景。所以，保持场景清单的「活文档」状态。
2.4 危害识别技术：HAZOP 和 Brainstorming
好，前面都是准备工作。现在咱们进入正题——怎么把危害找出来。
常用的技术有两种：HAZOP 和 Brainstorming。我两个都讲，你根据项目情况选。
2.4.1 HAZOP：结构化、系统化、不留死角
HAZOP，全称 Hazard and Operability Study。它起源于化工行业，后来被汽车行业拿过来用。
核心思想很简单：对每个功能，用一组「引导词」去问「如果……会怎样？」。
常用的引导词有：
| 引导词 | 含义 | 示例（转向助力功能） |
|---|---|---|
| 无 | 功能完全丧失 | 转向助力完全失效 |
| 多 | 输出过多/过大 | 助力扭矩过大，方向盘突然打偏 |
| 少 | 输出过少/过小 | 助力不足，方向盘沉重 |
| 相反 | 输出方向相反 | 左转时提供右转助力 |
| 早/晚 | 时序错误 | 助力响应延迟，驾驶员感觉「卡顿」 |
| 误 | 非预期的输出 | 未打方向盘时突然提供助力 |
怎么用？我举个例子。
功能：「根据方向盘转角计算目标扭矩」
引导词「无」→ 危害：扭矩计算失效，助力为0 → 后果：方向盘沉重，驾驶员可能无法转向 → 严重度：S3
引导词「多」→ 危害：扭矩计算值过大 → 后果：方向盘突然打偏，车辆失控 → 严重度：S3
引导词「相反」→ 危害：扭矩方向计算错误 → 后果：车辆转向与驾驶员意图相反 → 严重度：S3
你看，一个功能就能分析出好几个危害。而且每个危害都有明确的「引导词」作为来源，评审时别人一看就懂。
2.4.2 Brainstorming：灵活、发散、适合创新
Brainstorming，就是头脑风暴。一群人坐在一起，天马行空地想「可能会出什么事」。
听起来不靠谱？其实不是。Brainstorming 有它独特的价值：
- 适合新功能、新架构——没有历史数据可以参考时，靠人的经验来补。
- 适合跨领域问题——比如机械、电子、软件、人机交互交叉的地方。
- 适合发现「未知的未知」——HAZOP 有引导词，但引导词覆盖不了所有情况。
但 Brainstorming 有个大坑：容易跑偏。我见过一个团队，Brainstorming 开了三个小时，从「刹车失效」聊到了「外星人入侵」……
所以，我建议你定几条规则：
- 限定范围： 每次只分析一个功能或一个场景。
- 限定时间： 每个功能最多30分钟。
- 先发散、后收敛： 前15分钟随便说，不评判。后15分钟筛选、归类。
- 必须有记录： 每条危害都要写清楚「谁提出的、基于什么场景、可能的后果」。
2.5 两种技术怎么选？
我直接给你一个判断标准：
| 项目阶段 | 推荐技术 | 理由 |
|---|---|---|
| 概念阶段 | Brainstorming | 功能还不确定，需要发散 |
| 系统设计阶段 | HAZOP | 功能已定义，需要结构化分析 |
| 变更管理 | HAZOP + 针对性Brainstorming | 既要覆盖变更影响，又要发现新风险 |
但说实话，我大部分项目都是两者结合。先用 Brainstorming 快速扫一遍，再用 HAZOP 逐条过。这样既不会漏，也不会太死板。
2.6 本章小结
好，这一章的内容就这些。咱们回顾一下：
- 系统边界定义： 画上下文图，明确「管到哪」。
- 功能清单梳理： 按层级列，至少到L2。
- 运行场景分析： 做场景矩阵，覆盖高风险场景。
- 危害识别技术： HAZOP 结构化、Brainstorming 灵活，两者结合效果最好。
下一章，咱们讲「ASIL 等级评定：严重度、暴露率、可控性」。到时候我会告诉你，怎么给每个危害「打分」——这个分，直接决定了你要花多少钱做安全设计。
嗯，今天就到这。你回去可以拿自己手头的项目练练手，画个边界图，列个功能清单，再挑一个功能做HAZOP。做完你会发现——原来危害分析没那么玄乎。