3. 危害分析与风险评估（HARA）
好，咱们进入功能安全里最核心的一步——HARA。
说实话，我见过不少项目，前期设计做得挺漂亮，一到HARA就开始糊弄。结果呢？后期测试发现漏了关键危害，整个架构推倒重来。嗯，这滋味可不好受。
HARA说白了就三件事：找出危害、评估风险、定ASIL等级。咱们一个一个来拆。
3.1 HARA方法论：别急着上手，先搭框架
我个人习惯，做HARA之前先画一张图。把系统边界、输入输出、人机交互接口全标清楚。你想想看，连边界都没定，你怎么知道哪些危害归你管？
HARA的标准流程，我总结成四步：
- 场景分析：车辆在什么工况下运行？驾驶、停车、充电？
- 功能识别：座舱系统在做什么？显示车速、控制空调、触发告警？
- 危害识别：功能失效会怎样？车速显示错误？告警没响？
- 风险评估：这个危害有多严重？发生的概率多大？可控吗？
我在项目中遇到过一种情况：团队把HARA做成了“头脑风暴”，想到哪写到哪。结果评审时发现，同一个危害在不同场景下评估结果完全不一样。所以我的建议是——先定义场景库，再逐条过。
3.2 危害识别：别漏掉那些“不可能”的事
危害识别，很多人觉得就是“屏幕黑了”、“声音没了”。其实远不止这些。
举个例子。智能座舱里有个功能叫“驾驶员状态监测”。如果它把“正常驾驶”误判成“疲劳驾驶”，然后触发了紧急制动——你说这是不是危害？
危害识别要覆盖三类：
- 功能失效：该做的事没做。比如碰撞预警没报警。
- 功能误触发：不该做的事做了。比如误开车门。
- 功能降级不当：做得不够或做过头。比如音量调节延迟太大。
我曾经在一个项目中，漏掉了“语音助手误唤醒”这个危害。结果测试时，车内聊天说了一句“关闭车窗”，语音助手真把车窗关了。还好当时是台架测试，不然后果不堪设想。
3.3 风险评估：三个参数定生死
风险评估，ISO 26262给了三个参数：
| 参数 | 含义 | 等级范围 |
|---|---|---|
| S（Severity） | 危害对人员的伤害严重度 | S0（无伤害）~ S3（致命） |
| E（Exposure） | 危害场景发生的概率 | E0（几乎不）~ E4（非常高） |
| C（Controllability） | 驾驶员或其他人员能否控制住局面 | C0（完全可控）~ C3（不可控） |
这三个参数一组合，ASIL等级就出来了。具体怎么查？标准里有个矩阵表。我直接给你看常用的：
| S | E | C | ASIL |
|---|---|---|---|
| S2 | E3 | C2 | ASIL C |
| S3 | E2 | C1 | ASIL B |
| S1 | E4 | C2 | ASIL A |
| S3 | E4 | C3 | ASIL D |
为什么会这样？你想想看，一个危害如果严重度是S3（致命），但驾驶员完全能控制（C1），那ASIL等级反而不会太高。反过来，如果严重度只有S1（轻伤），但几乎每次开车都会遇到（E4），而且驾驶员控制不了（C3），那ASIL等级也可能冲到B甚至C。
我刚开始做HARA时，总喜欢把S估得很高。后来被审核老师怼了一次：“你这不是风险评估，是风险恐吓。” 嗯，从那以后我学会了——客观评估，别带感情。
3.4 ASIL等级确定：不是越高越好
ASIL等级从A到D，D最高。很多人觉得“ASIL D最安全，那我全上D不就行了？” 我告诉你，千万别这么干。
ASIL等级越高，开发成本越高。ASIL D的软件，光测试覆盖率就要达到90%以上。你想想看，一个车窗升降功能，有必要上ASIL D吗？
我的经验是：
- ASIL D：留给那些“失效即致命”的功能。比如制动、转向、碰撞预警。
- ASIL B/C：留给“失效可能导致重伤”的功能。比如车速显示、驾驶员监测。
- ASIL A / QM：留给“失效影响舒适性但不影响安全”的功能。比如空调、娱乐系统。
我曾经接手过一个项目，客户要求所有座舱功能都上ASIL B。结果开发周期翻了一倍，成本暴涨。后来我们重新做了HARA，把大部分功能降到了QM或ASIL A，只保留了几个关键功能在ASIL B。项目才顺利交付。
3.5 避坑指南：我踩过的那些坑
最后，分享几个我亲身踩过的坑，希望能帮你少走弯路。
- 坑一：忽略组合危害。单个功能失效可能没事，但两个功能同时失效呢？比如车速显示错误 + 碰撞预警失效。这种组合危害，HARA里一定要考虑。
- 坑二：场景定义太宽泛。“车辆行驶中”这个场景太笼统。要细化到“高速行驶”、“城市拥堵”、“夜间行驶”等。不同场景下，E和C的评估结果可能完全不同。
- 坑三：依赖个人经验。HARA最好由团队完成，包括系统工程师、软件工程师、测试工程师，甚至安全专家。一个人拍脑袋，很容易漏掉关键点。
我曾经在一个项目中，因为场景定义太宽泛，导致一个危害的E等级被低估了。结果测试时发现，这个场景其实每天都会发生。最后不得不返工，重新评估ASIL等级，整个架构都改了。嗯，那次教训挺深刻的。
好了，HARA的内容就这些。记住，HARA不是一次性的工作。随着设计深入，你会发现新的危害，或者发现原来的评估不合理。所以，HARA要持续迭代，直到项目结束。