2、ASIL等级确定：危害分析与风险评估（HARA）方法论、ASIL（A/B/C/D）等级定义、ASIL分解与冗余策略
各位工程师，咱们直接进入正题。上一章聊了功能安全的基本概念，这一章要啃的，是整个ISO26262流程中最关键的一步——危害分析与风险评估（HARA）。
说白了，HARA就是回答三个问题：系统会不会出危险？出了危险有多严重？我们该怎么防？ 我做了这么多年项目，见过不少团队在HARA阶段草草了事，结果后期改架构改到崩溃。嗯，这里咱们得把每一步踩实了。
2.1 HARA方法论：从场景到风险
HARA不是拍脑袋，它有一套标准流程。我个人习惯把它拆成四个步骤：
- 场景定义：列出车辆所有可能的运行场景（高速、城市、泊车、充电等）。
- 危害识别：分析系统功能失效后，会导致什么危害（比如刹车失灵、转向卡死）。
- 风险评估：用三个参数——严重度（S）、暴露概率（E）、可控性（C）——给每个危害打分。
- ASIL等级确定：根据S、E、C的组合，查表得出ASIL等级。
核心原则：HARA必须基于整车层面的失效后果，而不是某个ECU或软件模块的失效。你想想看，一个传感器坏了，如果整车还能安全停车，那风险等级就低；但如果传感器坏了导致刹车误触发，那可能就是ASIL D了。
我在项目中遇到过最典型的坑：团队只分析了“正常驾驶”场景，忽略了“充电时高压接触器粘连”这种场景。结果后期补HARA，整个安全目标都得重写。所以，场景覆盖一定要全。
2.2 ASIL等级定义：A、B、C、D到底差在哪？
ASIL全称是Automotive Safety Integrity Level，分四个等级：A、B、C、D。D是最严格的，A是最宽松的。怎么区分？看下面这张表：
| ASIL等级 | 典型场景 | 失效后果 | 开发要求 |
|---|---|---|---|
| ASIL A | 尾灯故障 | 轻微不适，无安全威胁 | 基本流程 |
| ASIL B | 雨刮器失控 | 驾驶员分心，可能引发事故 | 中等严格 |
| ASIL C | 转向助力突然消失 | 驾驶员需费力控制，有碰撞风险 | 较严格 |
| ASIL D | 制动主缸失效 | 车辆完全失去制动力，致命风险 | 最严格 |
你可能会问：ASIL等级是怎么算出来的？ 其实ISO26262给了一张3D矩阵表。我直接给你一个简化版的计算逻辑：
- S（Severity）：0-3级，S0无伤害，S1轻伤，S2重伤，S3致命。
- E（Exposure）：0-4级，E0几乎不暴露，E1很少，E2偶尔，E3经常，E4几乎每次驾驶都遇到。
- C（Controllability）：0-3级，C0完全可控，C1简单可控，C2一般可控，C3难以控制。
然后查表：
| S | E | C | ASIL |
|---|---|---|---|
| 3 | 4 | 3 | D |
| 3 | 3 | 3 | D |
| 2 | 4 | 3 | C |
| 1 | 4 | 2 | B |
| 0 | 任意 | 任意 | QM |
个人经验：我建议你在做HARA时，先别急着定S、E、C的数值。先把所有可能的危害场景列出来，然后团队一起评审。我曾经见过一个项目，工程师把“制动踏板卡滞”的S定为2（重伤），但实际分析发现，如果发生在高速上，S应该是3（致命）。这种偏差会导致安全目标定低了，后期改架构成本极高。
2.3 ASIL分解与冗余策略
好，现在你确定了某个功能是ASIL D。但问题来了：ASIL D要求单点故障度量（SPFM）≥99%，潜伏故障度量（LFM）≥90%。你一个普通的MCU加一个传感器，根本达不到这个指标。怎么办？
答案就是ASIL分解。
ASIL分解的核心思想是：把一个高ASIL要求的功能，拆成两个或多个独立的、低ASIL要求的子功能。只要这些子功能之间是相互独立的（没有共因失效），那么整体就能满足原来的ASIL等级。
举个例子：
- 原始要求：制动控制功能 → ASIL D
- 分解后：
- 路径A（主控制器）→ ASIL C
- 路径B（冗余控制器）→ ASIL C
- 整体：ASIL C + ASIL C = ASIL D（满足）
你可能会问：为什么C+C能等于D？ 因为ISO26262允许通过冗余来降低对单个组件的可靠性要求。两个独立的ASIL C通道，只要它们互相监控、互相备份，整体失效概率就能降到ASIL D的水平。
注意：ASIL分解不是随便拆的。它必须满足两个前提：
- 独立性：两个通道不能共享同一个电源、同一个时钟、同一个软件栈。我曾经见过一个项目，两个控制器用了同一个CAN总线，结果总线短路两个通道同时失效——分解白做了。
- 安全机制：每个通道内部必须有诊断机制，能检测自身故障并通知对方。
下面这张图展示了ASIL分解在冗余制动系统中的典型架构：
在实际项目中，ASIL分解还有几种常见模式：
| 分解模式 | 原始ASIL | 分解后 | 典型应用 |
|---|---|---|---|
| 对称冗余 | D | C + C | 制动、转向 |
| 非对称冗余 | D | D + B | 主控+监控 |
| 功能分解 | C | B + A | 传感器融合 |
避坑指南：我曾经在一个项目中，团队把ASIL D分解成了两个ASIL B。结果一算，两个B加起来只能覆盖到C，达不到D。为什么？因为ISO26262规定，分解后的子ASIL等级之和必须大于等于原始等级。具体来说：
- D = D + A, D + B, C + C, C + D, B + D, A + D
- C = C + A, B + B, A + C
- B = B + A, A + B
所以，B + B = C，而不是D。这个公式一定要记牢。
2.4 冗余策略的工程实现
光有ASIL分解还不够，你还得在硬件和软件层面真正实现冗余。常见的冗余策略包括：
- 硬件冗余：双MCU、双传感器、双执行器。每个通道独立供电、独立通信。
- 软件冗余：两个通道运行不同的算法（比如一个用PID，一个用滑模控制），避免软件共因失效。
- 时间冗余：同一个计算任务在两个不同的时间窗口执行，比较结果是否一致。
- 信息冗余：用不同的传感器测量同一个物理量（比如轮速和车速），互相校验。
我建议你在做冗余设计时，先画一张失效模式与影响分析（FMEA）表，把每个组件的失效模式列出来，然后看冗余策略能不能覆盖。如果发现某个失效模式两个通道都会受影响（比如共用一个电源），那就得加隔离措施。
重要提醒：冗余不是万能的。如果两个通道的软件是同一个团队写的、用了同一个编译器、同一个库，那它们很可能有共因失效。ISO26262要求冗余通道之间必须满足独立性，包括：
- 供电独立
- 时钟独立
- 软件独立（不同开发团队、不同算法）
- 通信独立（不同总线或不同报文ID）
做不到这些，你的ASIL分解就是纸上谈兵。