第2章：OTA系统危害分析与风险评估（HARA）

各位工程师朋友，咱们接着聊。上一章我们把OTA系统的功能安全框架搭起来了，这一章要动真格的了——HARA，也就是危害分析与风险评估。

说实话，HARA这活儿看着像纸上谈兵，但我在项目里吃过亏。有一次，我们团队赶进度，HARA做得比较潦草，结果测试阶段发现一个严重的安全漏洞，不得不返工。嗯，从那以后，我再也不敢轻视这一步了。

2.1 HARA方法论：从“可能出什么事”开始

HARA的核心就一句话：找出系统在什么情况下会出危险，然后评估这个危险有多严重。

我个人习惯把HARA分成三步走：

1. 场景定义——车在什么环境下运行？
2. 危害识别——系统故障会导致什么后果？
3. 风险评估——这个后果有多大概率发生？有多严重？

你想想看，OTA系统跟传统ECU不一样。传统ECU的故障通常是硬件坏了，OTA的故障可能是软件刷错了、通信断了、版本不匹配。这些故障的后果，有时候比硬件故障还可怕。

2.2 运行场景定义：车在什么状态下升级？

运行场景，说白了就是“车在干什么的时候，OTA系统在工作”。我建议至少定义以下三类场景：

场景类别	具体描述	典型例子
行驶中升级	车辆在道路上行驶，OTA后台下载或安装	高速公路上，ECU固件静默升级
停车时升级	车辆熄火或驻车，用户触发升级	车主在停车场，点击“立即升级”
维护模式升级	4S店或产线，使用专用工具升级	售后刷写新版本软件

这里有个坑，我必须要提醒你：行驶中升级是最危险的场景。为什么？因为这时候车辆动态变化，任何软件故障都可能直接影响驾驶安全。

2.3 危害事件识别：OTA系统会怎么“闯祸”？

危害事件，就是“系统故障导致的人身伤害或财产损失”。对于OTA系统，我总结了几类典型危害：

• 升级中断导致ECU变砖——车辆失去关键功能，比如刹车助力消失
• 版本不匹配导致功能异常——比如ADAS系统升级后，感知算法失效
• 通信故障导致升级失败——车辆停在半路，无法启动
• 安全攻击导致恶意升级——黑客注入恶意代码，控制车辆

识别危害事件时，我习惯用“故障树”的思路。先想最严重的后果，比如“车辆失控”，然后倒推是什么故障导致的。举个例子：

危害事件：车辆在高速行驶中，制动系统ECU升级失败，导致制动功能丧失

故障链：
1. OTA主控在行驶中发起升级请求
2. 制动ECU进入刷写模式，停止响应制动指令
3. 升级过程中通信中断，ECU停留在刷写模式
4. 驾驶员踩刹车，ECU无响应
5. 车辆无法减速，发生碰撞

你看，一个看似简单的升级失败，背后可能是一连串的连锁反应。这就是为什么HARA不能只盯着单一故障，要看系统级的交互。

2.4 安全状态定义：出事了怎么办？

安全状态，就是“系统出故障后，车辆应该进入什么状态才能保证安全”。对于OTA系统，我常用的安全状态有：

• 回滚到上一版本——升级失败后，自动恢复旧版本软件
• 进入安全模式——禁用升级功能，保持当前功能正常运行
• 请求驾驶员干预——提示驾驶员靠边停车，再处理升级问题
• 保持当前状态不变——如果升级还没开始，就取消升级

举个例子，对于上面那个制动ECU升级失败的案例，安全状态可以这样定义：

故障场景	立即安全状态	最终安全状态
制动ECU升级中断	立即停止升级，恢复制动ECU正常运行	回滚到升级前的版本，确保制动功能完整
OTA主控通信故障	保持当前ECU状态不变，不执行任何升级操作	等待通信恢复后，重新评估升级条件

嗯，这里要注意：安全状态不是随便定义的。它必须满足两个条件：可验证（你能测试这个状态是否生效）和可达到（系统确实能进入这个状态）。

2.5 HARA的输出：ASIL等级怎么定？

HARA做完后，要输出每个危害事件的ASIL等级。ASIL分四个等级：A、B、C、D，D是最严格的。等级由三个因素决定：

• 严重度（S）——伤害有多重？轻伤还是致命？
• 暴露率（E）——这个场景发生的频率高不高？
• 可控性（C）——驾驶员能不能避免伤害？

我记得有一次评审，团队对一个OTA升级失败的ASIL等级争论不休。有人说应该定C，有人说D。最后我们做了个实验：让驾驶员在模拟器上体验升级失败后的制动失效，结果大部分驾驶员无法在3秒内做出正确反应。嗯，最后定了D级。

好了，这一章的内容就到这里。HARA做得好不好，直接决定了后续安全设计的质量。下一章，我们会聊安全需求的定义和分解，到时候见。