4. 危害分析与风险评估
概念阶段，说白了就是回答三个问题：我们要做什么？会出什么危险？怎么才算安全？
很多新手一上来就急着写代码、画板子，结果做到一半发现安全需求没定义清楚，回头改架构，那叫一个痛苦。我个人习惯，在这个阶段宁可多花一周把定义做扎实，后面至少省一个月。
4.1 项目定义——先把边界画清楚
项目定义不是写个产品名称就完事了。你得把系统的功能、边界、外部接口、运行环境、人员交互全列出来。
- 系统名称与版本：比如“EPS 电动助力转向 v2.1”
- 主要功能：列表描述，每条一句话
- 系统边界：哪些是系统内的，哪些是外部的
- 外部接口：CAN/LIN/以太网/传感器/执行器
- 运行模式：正常模式、故障模式、维护模式
- 使用场景：高速、城市、停车、充电等
- 人员角色：驾驶员、乘客、维修人员、行人
- 法规与标准：ISO 26262、GB/T 34590、ASPICE 等级
举个例子。我之前做过一个线控制动系统的项目定义。一开始团队只写了“实现电子刹车”，结果HARA时发现——等等，这车有没有自动驾驶模式？有没有冗余电源？这些不写清楚，后面的分析全是空中楼阁。
4.2 HARA——危害分析与风险评估
HARA 是概念阶段的核心。它的目标就一个：找出所有可能造成人身伤害的系统故障，然后给每个危害定个等级。
4.2.1 HARA 三步走
- 识别危害事件：系统级功能失效会引发什么危险？
- 评估风险等级：用 ASIL 三个参数——Severity（严重度）、Exposure（暴露率）、Controllability（可控性）
- 确定安全目标：每个危害事件对应一个安全目标
我见过最典型的错误，是把 HARA 做成了“头脑风暴”。大家坐在一起瞎猜，没有场景、没有数据支撑。结果评审时被客户怼回来——你这个暴露率凭什么给 E4？有统计数据吗？
4.2.2 ASIL 等级确定
ASIL 分四个等级：A、B、C、D。D 是最严格的（比如刹车、转向），A 是最宽松的。还有 QM（Quality Management），意思是按普通质量管理就行，不需要额外安全措施。
| 参数 | 等级 | 说明 |
|---|---|---|
| Severity (S) | S0~S3 | S3 = 致命伤害 |
| Exposure (E) | E0~E4 | E4 = 高暴露率（几乎每次驾驶都会遇到） |
| Controllability (C) | C0~C3 | C3 = 驾驶员几乎无法控制 |
ASIL 等级 = f(S, E, C)。具体查 ISO 26262-3 的表格就行。嗯，这里要注意：ASIL 分解是后面系统设计的事，概念阶段先别想太多，老老实实定原始等级。
4.2.3 一个真实的 HARA 例子
拿电动尾门来说。危害事件：尾门在关闭过程中，因传感器故障导致夹到人。
- S：夹伤可能造成骨折，S2
- E：每次使用尾门都可能发生，E4
- C：驾驶员可以通过紧急按钮停止，C2
- ASIL：查表得 B
你看，一个看似简单的尾门，安全等级也能到 B。千万别觉得“不就是个门嘛”。
4.3 安全目标定义——把危害翻译成需求
安全目标，就是把 HARA 里每个危害事件，翻译成一条可验证、可测试的系统级安全需求。
SG-001：当系统检测到尾门夹持力超过阈值时，
必须在 100ms 内停止关门动作并反转，
以避免对人员造成挤压伤害。
ASIL：B
来源：HARA-003（尾门夹人）写安全目标时，我有个习惯：每个目标都要包含“什么条件下、什么行为、什么时间、什么结果”。缺一个，后面验证时就扯皮。
4.4 概念阶段知识体系
下面这张图，是我自己讲课用的。它把概念阶段的三个核心活动串起来了。
4.5 常见问题与避坑
- 项目定义太粗：比如只写“电动车窗”，没写“是否有防夹功能”。结果 HARA 时发现防夹是安全关键，但定义里没提，导致返工。
- HARA 场景不全：只考虑了正常驾驶，没考虑维修模式、充电模式、拖车模式。我曾经有个项目，HARA 漏了“充电时车辆移动”的场景，后来被客户审计发现，补了三个安全目标。
- 安全目标写得太模糊：比如“系统应保证安全”。这种目标没法验证，等于没写。每个目标都要有可量化的指标（时间、阈值、状态）。
- ASIL 等级给得太高或太低：给太高，成本爆炸；给太低，安全不达标。我的建议是：拿不准时，先给高一级，后面通过 ASIL 分解来优化。
概念阶段做扎实了，后面的系统设计、硬件设计、软件设计才有根。别急着往前冲，把地基打牢，比什么都重要。