第1章：ASIL等级确定——HARA方法、等级定义与分解、安全目标制定
各位工程师朋友，咱们开始聊功能安全落地中最关键的一步——怎么确定ASIL等级。
说实话，我见过太多项目，一上来就拍脑袋说“这个功能要ASIL D”。结果呢？开发成本翻倍，周期拉长，最后发现根本没必要。所以，这一章咱们把HARA（危害分析与风险评估）的方法、ASIL等级的定义与分解、还有安全目标的制定，掰开揉碎了讲清楚。
1.1 危害分析与风险评估（HARA）方法
HARA，说白了就是回答三个问题：
- 车子出了什么故障？
- 这个故障会导致什么危险？
- 这个危险有多严重？
我个人习惯，做HARA之前先画一张系统框图。把ECU的输入、输出、通信接口都标清楚。然后针对每个功能，问自己：“如果这个功能失效了，会发生什么？”
举个例子，我在做EPS（电动助力转向）项目时，分析“转向扭矩传感器失效”这个场景。你想想看，传感器输出一个错误值，ECU以为驾驶员在猛打方向，结果电机突然输出大扭矩——嗯，这车可能瞬间失控。
HARA的标准步骤，我总结为四步：
- 功能定义：明确ECU要实现什么功能
- 失效模式分析：每个功能可能怎么坏
- 危害识别：失效后对车辆、人员造成什么危害
- 风险评估：用三个参数量化风险
这里有个避坑指南：千万不要只分析“最坏情况”。我曾经有个项目，只盯着“完全失效”分析，结果忽略了“间歇性故障”导致的危险。后来测试时发现，传感器偶尔跳变一下，比完全坏掉更可怕——因为驾驶员根本来不及反应。
1.2 ASIL等级的定义与分解
ASIL等级，全称是Automotive Safety Integrity Level，汽车安全完整性等级。分四个级别：A、B、C、D。D是最严格的，A是最宽松的。
怎么定级？看三个参数：
| 参数 | 含义 | 等级范围 |
|---|---|---|
| S（Severity） | 危害的严重度 | S0~S3 |
| E（Exposure） | 暴露概率 | E0~E4 |
| C（Controllability） | 驾驶员可控性 | C0~C3 |
然后查表：
| S | E | C | ASIL |
|---|---|---|---|
| S1 | E1 | C1 | A |
| S2 | E2 | C2 | B |
| S3 | E3 | C3 | C |
| S3 | E4 | C3 | D |
注意，如果三个参数中有一个是0，那这个功能就是QM（质量管理级），不需要按ASIL开发。
关键点：ASIL等级不是一成不变的。你可以通过架构设计来分解它。
ASIL分解，是ISO 26262里一个非常实用的技巧。比如，一个ASIL D的功能，你可以把它拆成两个独立的ASIL C(D)的子系统。什么意思？就是每个子系统按ASIL C的要求开发，但组合起来要满足ASIL D的安全目标。
我举个例子。一个刹车系统的ASIL D要求，你可以分解成：
- 主控制器：ASIL C(D)
- 监控控制器：ASIL C(D)
两个控制器互相监控，任何一个失效，另一个都能接管。这样，每个控制器只需要按ASIL C开发，成本降低不少。
注意：ASIL分解不是简单的“1+1=2”。你必须保证两个通道是相互独立的。如果它们共享了同一个电源、同一个时钟、甚至同一块PCB板上的相邻走线，那这个分解就无效了。
我记得有一次评审，一个团队把ASIL D分解成两个ASIL B，理由是“两个B加起来就是D”。我当时就问了三个问题：
- 两个通道的供电是否独立？
- 两个通道的软件是否由不同团队开发？
- 两个通道的失效模式是否正交？
结果他们一个都答不上来。嗯，这个分解方案直接被驳回了。
1.3 安全目标（Safety Goal）的制定
安全目标，是HARA的输出，也是后续所有安全活动的起点。它描述的是：系统要避免什么危害。
一个好的安全目标，应该满足三个条件：
- 具体：不能写“系统要安全”，要写“转向系统在传感器失效时，输出扭矩不得超过5Nm”
- 可验证：能不能通过测试来证明它实现了？
- 可追溯：每个安全目标都能追溯到HARA中的某个危害
我给大家看一个实际项目的安全目标示例：
安全目标编号：SG-001
关联危害：转向扭矩传感器失效导致非预期转向
ASIL等级：ASIL D
安全目标描述：在转向扭矩传感器发生单点故障时，系统必须在100ms内检测到故障，并将转向助力降至0，同时点亮仪表盘警告灯。
验收标准：故障注入测试中，从故障发生到助力降为0的时间 ≤ 100ms这里有个细节：安全目标里要写清楚故障容错时间间隔（FTTI）。100ms是我根据车辆动力学仿真算出来的。如果时间太长，驾驶员可能已经失控了。
个人经验：制定安全目标时，一定要拉上系统工程师和测试工程师一起讨论。我曾经自己闷头写了一份安全目标，结果测试团队说“这个指标我们测不了”——因为需要特殊的故障注入设备。后来我们重新调整了验收标准，用更实际的测试方法替代。
最后，安全目标要形成文档，并且每个目标都要有唯一的编号。后续的硬件设计、软件设计、测试用例，都要引用这个编号。这样，评审时才能快速追溯。
好了，这一章的内容就到这里。下一章咱们聊聊功能安全需求怎么从安全目标往下分解。记住，HARA做扎实了，后面的路就好走了。