2、安全目标定义：危害分析与风险评估(HARA)、安全目标的导出、安全状态的定义
好，咱们进入第二章。这一章是整个功能安全开发的基石。说白了，你连车会出什么危险、后果多严重都没搞清楚，后面的设计全是瞎忙活。
我个人习惯，接手一个新项目，第一件事不是看代码，而是拉上系统、软件、测试的兄弟，关起门来做一轮 HARA。为什么？因为这是唯一能让你「提前知道雷在哪」的机会。
2.1 危害分析与风险评估（HARA）
HARA 的全称是 Hazard Analysis and Risk Assessment。它的目标就一个：找出所有与功能相关的危害事件，然后评估每个危害的风险等级。
在 OTA 场景下，HARA 的难点在于——危害往往不是直接由 OTA 引起的，而是由 OTA 触发的。比如，你升级了一个制动控制器的固件，升级过程中网络断了，ECU 里同时存在新旧两版代码……嗯，后果你自己想。
2.1.1 HARA 的三要素
做 HARA 时，我们通常从三个维度去评估一个危害事件：
| 维度 | 含义 | OTA 场景举例 |
|---|---|---|
| 严重度（Severity, S） | 危害对人员造成的伤害程度 | 升级后制动失效 → S3（致命） |
| 暴露率（Exposure, E） | 车辆处于危害场景的概率 | 高速行驶中触发升级 → E4（高概率） |
| 可控性（Controllability, C） | 驾驶员能否避免危害 | 升级时方向盘锁死 → C3（难以控制） |
这三个维度组合起来，就得到了 ASIL 等级（A、B、C、D）。D 是最严格的，A 相对宽松，QM 则意味着不需要功能安全措施。
关键点：OTA 升级场景下，E 值的评估往往比传统功能要高。因为 OTA 是远程触发的，你无法控制用户是在车库、市区还是高速上点那个「升级」按钮。
2.1.2 OTA 场景下的典型危害
我在项目中遇到过最典型的 OTA 危害，列出来给大家参考：
- 升级中断导致系统不可用：比如网关升级到一半断电，整车网络瘫痪。
- 版本兼容性错误：新固件与旧硬件不匹配，导致传感器输出异常。
- 回滚失败：升级失败后无法恢复到上一个可用版本，车辆趴窝。
- 安全降级逻辑被覆盖：OTA 包意外修改了安全监控模块的配置。
你想想看，这些危害如果发生在时速 120km/h 的车辆上，后果是什么？所以 HARA 不是走形式，是真的要命。
2.2 安全目标的导出
做完 HARA，我们手里有了一堆危害事件和对应的 ASIL 等级。下一步，就是为每个危害事件定义安全目标（Safety Goal）。
安全目标说白了就是一句话：「系统必须保证不发生 XXX 危害」。它是顶层安全需求，所有后续的安全机制都要围绕它来设计。
2.2.1 安全目标的格式
我习惯用这样的模板来写安全目标：
SG-XXX：[系统/功能] 必须 [避免/防止/确保] [具体危害]，在 [条件] 下，
达到 [ASIL 等级] 要求。举个例子，针对「OTA 升级中断导致制动系统失效」这个危害：
SG-001：OTA 升级过程中，制动系统必须保持完整功能，
即使升级中断或失败，制动系统也不得进入失效状态。
ASIL D。我的经验：安全目标不要写得太具体，不要直接写「要用双备份校验」。安全目标是「什么」，不是「怎么做」。具体的技术方案留给后面的安全需求去定义。
2.2.2 安全目标的层级关系
一个危害事件可能对应多个安全目标，一个安全目标也可能覆盖多个危害。我一般会画一张图来理清关系：
2.3 安全状态的定义
安全目标定好了，接下来要回答一个问题：当系统检测到违反安全目标的情况时，它应该怎么办？
答案就是——进入安全状态（Safe State）。
2.3.1 什么是安全状态？
安全状态是系统在检测到故障后，能够将风险降低到可接受水平的一种系统状态。它不一定是「停机」，也可能是「降级运行」或「维持当前状态」。
在 OTA 场景下，常见的安全状态有：
- 维持当前状态：升级失败后，继续运行旧版本固件。
- 降级模式：关闭 OTA 功能，但保证基础驾驶功能正常。
- 安全停机：将车辆置于安全位置后，完全关闭升级流程。
注意：我曾经在一个项目里踩过坑——安全状态定义得太模糊。只写了「进入安全状态」，但没说明具体怎么做。结果测试团队问：安全状态是啥？是亮故障灯？还是限制车速？还是直接熄火？所以，安全状态必须可执行、可验证。
2.3.2 安全状态的属性
定义安全状态时，我建议至少明确以下三个属性：
| 属性 | 说明 | OTA 示例 |
|---|---|---|
| 触发条件 | 什么情况下进入安全状态 | 升级包校验失败、升级超时、通信中断 |
| 状态行为 | 进入后系统做什么 | 停止升级、回滚到旧版本、保持当前功能 |
| 退出条件 | 什么情况下可以退出安全状态 | 故障消除、重新上电、人工确认 |
2.3.3 安全状态的时间维度
这里有个容易被忽略的点：安全状态是有时间属性的。我把它分为三类：
- 瞬时安全状态：故障发生后立即进入，比如切断升级电源。持续时间很短。
- 过渡安全状态：系统正在从故障状态恢复到正常状态，比如正在回滚固件。
- 持久安全状态：系统无法恢复，长期停留在降级模式，比如永久禁用 OTA 功能。
嗯，这里要注意：过渡安全状态往往是最危险的。因为系统正在执行恢复操作，如果此时又发生二次故障，后果可能更严重。所以过渡安全状态也要有监控和保护机制。
2.4 本章小结
这一章我们走完了功能安全开发的起点：从 HARA 识别危害，到导出安全目标，再到定义安全状态。这三步走扎实了，后面的安全架构设计、安全机制实现才有依据。
我个人建议，每做完一轮 HARA，一定要拉上不同角色的人做一次评审。因为一个人看问题总有盲区。我曾经在评审会上被测试同事一句话点醒：「你这个危害场景，如果用户是在隧道里升级呢？」——好问题，我确实没考虑到。