3、ASIL等级确定：ASIL定义、危害分析与风险评估（HARA）方法
好，咱们进入正题。这一章聊的是功能安全里最核心、也最让人头疼的一步——ASIL等级怎么定。
很多刚入行的工程师问我：“ASIL不就是ABCD四个等级吗？查表不就行了？”
嗯，查表确实能出结果。但你要是真这么干，项目后期大概率要返工。我踩过这个坑，所以今天跟你好好掰扯掰扯。
3.1 什么是ASIL？
ASIL，全称Automotive Safety Integrity Level，汽车安全完整性等级。
说白了，它就是衡量一个功能失效后，后果有多严重的“尺子”。
ASIL有四个等级：A、B、C、D。
ASIL D最严格，比如刹车、转向这类“失效就要命”的功能。
ASIL A相对宽松，比如车窗升降、座椅调节。
还有一个特殊情况——QM（Quality Management）。
意思是：这个功能失效了，不会造成人身伤害，按普通质量管理就行，不用上功能安全流程。
重要概念：ASIL不是给整个ECU定的，而是给每一个安全目标定的。
同一个ECU里，可能有ASIL D的功能，也有QM的功能。别搞混了。
3.2 危害分析与风险评估（HARA）
ASIL怎么来的？不是拍脑袋，也不是客户说了算。
它来自一套系统的方法——HARA（Hazard Analysis and Risk Assessment）。
HARA的流程，我习惯分三步走：
- 场景分析——这车在什么情况下会出事？
- 危害识别——哪个功能失效会导致什么危害？
- 风险评级——这个危害有多严重？发生的概率多大？可控吗？
听起来简单吧？但实际做起来，每一步都有坑。
3.2.1 场景分析
你得先想清楚：这个ECU在车上怎么用？
比如一个电子转向柱锁，什么时候会锁止？什么时候会解锁？
如果车辆行驶中突然锁死——嗯，那画面太美我不敢看。
我建议你列一个运行场景清单：
- 正常驾驶（高速、市区、乡村）
- 停车/启动
- 维修模式
- 极端天气（雨、雪、高温）
- 故障模式（其他ECU失效了怎么办？）
我曾经在一个项目里漏掉了“车辆涉水”这个场景，结果客户审核时被揪出来，补了整整两周的文档。教训深刻啊。
3.2.2 危害识别
这一步要回答：功能失效了，会怎样？
举个例子，ACC（自适应巡航）的“目标丢失”失效：
- 危害：车辆突然加速或减速
- 后果：追尾、乘客受伤
注意，这里要区分功能失效和系统失效。
功能失效是“该干活没干”，系统失效是“干了不该干的活”。
两者都要分析。
我的小技巧：做危害识别时，拉上系统工程师、软件工程师、测试工程师一起开脑暴会。
一个人想不全的，真的。我试过自己闷头写，结果漏了三个关键危害。
3.2.3 风险评级
这是HARA的核心，也是ASIL等级的直接来源。
ISO 26262给了三个参数：
| 参数 | 全称 | 含义 | 等级 |
|---|---|---|---|
| S | Severity | 伤害的严重程度 | S0~S3 |
| E | Exposure | 暴露在危险场景中的概率 | E0~E4 |
| C | Controllability | 驾驶员或其他人员能否控制住局面 | C0~C3 |
然后查表：
| S | E | C | ASIL |
|---|---|---|---|
| S1 | E1 | C1 | QM |
| S2 | E2 | C2 | ASIL B |
| S3 | E3 | C3 | ASIL D |
| （完整表格见ISO 26262-3:2018 Table 1） | |||
举个例子：
ACC目标丢失导致追尾——
S=3（可能致命），E=2（偶尔发生），C=2（驾驶员能反应但很难完全避免）
查表得：ASIL C。
注意：这个评级不是数学公式，而是工程判断。
同一个危害，不同公司、不同项目，评出来的ASIL可能不一样。
我见过一个项目，客户坚持把S2改成S3，就为了多要一个ASIL D的“面子”。
说实话，这没必要。ASIL越高，开发成本越高，别自己给自己找麻烦。
3.3 HARA文档怎么写？
HARA做完，要输出一份文档，叫HARA报告。
我习惯的模板是这样的：
1. 功能描述
2. 运行场景列表
3. 危害识别表（危害ID、危害描述、失效模式）
4. 风险评级表（S、E、C、ASIL）
5. 安全目标（每个危害对应一个安全目标）
6. 评审记录每个安全目标要写清楚：
“避免XXX危害，达到ASIL X等级”。
比如：
“避免ACC在目标丢失时非预期加速，达到ASIL C。”
这份文档是后续所有安全活动的输入。
安全架构、安全机制、测试用例，全都要对着它来。
所以，HARA报告一定要写清楚、写完整。
避坑指南：我曾经在一个项目里，HARA报告写得太简略，安全目标只有一句话。
结果到了功能安全审核时，审核员问：“你这个安全目标怎么来的？场景呢？假设呢？”
我当场就懵了。后来补了整整一周的文档。
所以，HARA报告一定要可追溯、可复现。
3.4 常见问题与经验
最后，分享几个我常被问到的问题：
- Q：同一个功能，不同场景下ASIL不一样怎么办？
A：取最高等级。比如ACC在高速上失效是ASIL C，在市区是ASIL B，那就按ASIL C做。 - Q：ASIL可以分解吗？
A：可以。ASIL D可以分解成ASIL C(D)+ASIL C(D)，或者ASIL B(D)+ASIL B(D)。
但要注意，分解后每个部分都要独立满足对应的ASIL要求。 - Q：HARA做一次就够了？
A：不够。需求变了、架构改了、场景新增了，都要重新做HARA。
我建议每个里程碑都回顾一下HARA，别等到最后才发现漏了。
好了，这一章就聊到这儿。
下一章我们讲安全目标与安全状态，看看HARA的结果怎么落地到系统设计里。
记住一句话：ASIL不是终点，是起点。