功能安全基础：ASIL等级定义、安全目标、安全需求与硬件指标的关系
在ISO 26262框架下，ASIL（Automotive Safety Integrity Level，汽车安全完整性等级）是贯穿整个开发流程的核心决策变量。它不仅是风险分类的标签，更是从系统级安全目标到硬件级量化指标（如SPFM、LFM、PMHF）之间层层传递的“安全契约”。理解ASIL的确定逻辑、安全目标与安全需求的分解路径，以及它们如何最终映射为硬件设计的可计算指标，是进行FMEDA分析和硬件架构设计的前提。本章将系统梳理这一从“抽象风险”到“具体数字”的转化链路。
2.1 ASIL等级的定义与确定方法
核心原理：风险三要素与ASIL分级
ASIL等级源自ISO 26262-3的危害分析与风险评估（HARA）流程。其核心逻辑是：对车辆运行场景中可能发生的危害事件，从三个维度进行量化评估——严重度（Severity, S）、暴露概率（Exposure, E）和可控性（Controllability, C）。三个维度的等级组合决定了ASIL等级（A、B、C、D），其中ASIL D要求最高，ASIL A要求最低；若组合结果低于ASIL A，则归类为QM（Quality Management），表示仅需按常规质量管理流程处理，无需额外功能安全措施。
严重度S评估乘员或其他交通参与者受伤害的程度，分为S0（无伤害）到S3（危及生命）四级；暴露概率E评估车辆处于该运行场景的时间占比，分为E0（几乎不可能）到E4（高概率）五级；可控性C评估驾驶员或其他人员避免伤害的能力，分为C0（完全可控）到C3（难以控制）四级。三者组合查表得到ASIL等级。例如，某电动助力转向系统在高速行驶中发生非预期转向助力丧失，若评估为S2（严重伤害）、E4（高暴露）、C2（通常可控但存在风险），则对应ASIL C。
判断方法：HARA执行流程
- 场景定义：列出车辆运行的所有合理可预见的场景（如高速巡航、城市拥堵、停车、充电等）。
- 危害识别：分析系统或功能失效后可能导致的车辆级危害（如非预期加速、转向锁死、制动失效）。
- 三要素评级：对每个危害事件分别评定S、E、C等级。
- ASIL查表：依据ISO 26262-3的表1（ASIL组合表）确定ASIL等级。
- 安全目标定义：为每个危害事件定义一条安全目标，并赋予对应的ASIL等级。
案例拆解：动力电池热失控的ASIL确定
以某纯电动汽车的动力电池管理系统（BMS）为例。危害事件为“电池过充导致热失控并引发火灾”。评估过程如下：严重度S3（可能造成死亡）；暴露率E4（车辆每次充电均处于该场景）；可控性C2（乘员可逃离但时间有限）。查表得ASIL D。由此定义安全目标：“避免电池在充电过程中发生过充导致的热失控”，ASIL D。该安全目标将作为后续BMS硬件设计（电压采样、电流采样、温度监控、充电切断回路）的最高安全约束。
2.2 安全目标与安全需求的层级分解
核心原理：从“避免危害”到“可实现的工程约束”
安全目标（Safety Goal）是系统层面最高级别的安全要求，描述“避免什么危害”，通常不涉及具体实现技术。而安全需求（Safety Requirements）是将安全目标逐步细化为可设计、可验证的工程要求。ISO 26262将安全需求分为三个层级：功能安全需求（Functional Safety Requirements, FSR）、技术安全需求（Technical Safety Requirements, TSR）和硬件安全需求（Hardware Safety Requirements, HSR）。每一层都继承上一层的ASIL等级，且允许在满足特定条件时进行ASIL分解（如ASIL D分解为ASIL B(D)+ASIL B(D)）。
ASIL分解是实践中常用的降低开发难度的方法。其原理是：如果一个安全目标由两个相互独立的要素共同实现，且每个要素都能独立检测对方故障并进入安全状态，则可以将原ASIL等级分解到两个要素上。例如，ASIL D的安全目标可以分解为两个ASIL B(D)的独立通道，每个通道只需按ASIL B流程开发，但必须证明其独立性（如供电隔离、时钟独立、通信冗余）。
操作流程：安全需求分解步骤
| 层级 | 输入 | 输出 | ASIL处理 |
|---|---|---|---|
| 功能安全需求（FSR） | 安全目标 + 系统定义 | 系统级功能要求（如“检测过充并切断充电” ） | 继承安全目标ASIL |
| 技术安全需求（TSR） | FSR + 系统架构设计 | 软硬件技术实现要求（如“电压采样周期≤10ms，精度±1%” ） | 可进行ASIL分解 |
| 硬件安全需求（HSR） | TSR + 硬件架构设计 | 电路级要求（如“过压比较器阈值3.65V±0.05V，响应时间<5ms” ） | 继承TSR的ASIL |
实战场景：BMS过充保护的ASIL分解
某BMS的“避免过充”安全目标为ASIL D。为降低单一电压采样芯片的开发难度，设计采用双通道架构：通道A使用主MCU内置ADC进行电压采样，通道B使用独立比较器电路。两个通道均能独立触发充电切断。根据ASIL分解规则，该安全目标可分解为：通道A承担ASIL B(D)，通道B承担ASIL B(D)。但需满足：两通道供电独立（使用不同LDO）、时钟独立（MCU内部时钟与外部晶振）、通信独立（通道A通过CAN上报，通道B通过硬线直接驱动切断继电器）。
2.3 硬件指标与ASIL等级的量化映射
核心原理：三个关键硬件度量指标
ISO 26262-5（硬件层面）定义了三个核心量化指标，用于评估硬件设计在随机硬件失效方面的安全性：
- SPFM（Single-Point Fault Metric，单点故障度量）：衡量硬件架构对单点故障（直接导致安全目标违背的故障）的覆盖能力。SPFM = 1 - (单点故障失效率 + 残余故障失效率) / 总失效率。ASIL D要求SPFM ≥ 99%，ASIL B要求≥ 90%。
- LFM（Latent Fault Metric，潜伏故障度量）：衡量对潜伏故障（未被安全机制检测且与其它故障组合后导致安全目标违背的故障）的覆盖能力。LFM = 1 - 潜伏故障失效率 / (潜伏故障失效率 + 安全机制可检测的故障失效率)。ASIL D要求LFM ≥ 90%，ASIL B要求≥ 60%。
- PMHF（Probabilistic Metric for Random Hardware Failures，随机硬件失效概率度量）：评估硬件在运行寿命内发生导致安全目标违背的随机硬件失效的概率。通常以FIT（Failures In Time，每10^9小时失效次数）为单位。ASIL D要求PMHF < 10 FIT，ASIL B要求< 100 FIT。
判断方法：FMEDA如何计算这些指标
FMEDA（Failure Modes, Effects and Diagnostic Analysis）是计算上述指标的标准方法。其流程为：
- 硬件架构分解：将系统拆分为元器件级（电阻、电容、IC、连接器等）。
- 失效率分配：依据IEC 62380、SN 29500或供应商数据，为每个元器件分配基础失效率λ。
- 故障模式分布：定义每个元器件的故障模式（如开路、短路、漂移）及其占比。
- 安全机制映射：识别每个故障模式是否被安全机制覆盖（检测/控制），并分类为：安全故障、单点故障、残余故障、潜伏故障、可检测故障。
- 指标计算：按公式汇总各分类的失效率，计算SPFM、LFM、PMHF。
案例拆解：BMS电压采样电路的FMEDA简化分析
以BMS中一个电压采样通道为例，包含：分压电阻R1（100kΩ）、R2（10kΩ）、滤波电容C1（100nF）、ADC芯片U1。假设该通道承担ASIL B(D)的安全目标（来自前述分解）。关键参数如下：
| 元器件 | 失效率(FIT) | 主要故障模式 | 安全机制 | 故障分类 |
|---|---|---|---|---|
| R1 | 5 | 开路(50%)、漂移(50%) | ADC自检(检测开路) | 开路→可检测；漂移→残余 |
| R2 | 5 | 开路(50%)、短路(50%) | ADC自检(检测开路) | 开路→可检测；短路→单点 |
| C1 | 2 | 短路(100%) | 无 | 单点 |
| U1 | 20 | 输出卡死(30%)、偏移(70%) | 双通道冗余比较 | 卡死→可检测；偏移→潜伏 |
计算SPFM：总失效率=32 FIT。单点故障失效率 = R2短路(2.5 FIT) + C1短路(2 FIT) = 4.5 FIT。残余故障失效率 = R1漂移(2.5 FIT) = 2.5 FIT。SPFM = 1 - (4.5+2.5)/32 = 78.1%。该值低于ASIL B要求的90%，因此需要增加安全机制（如增加RC滤波后的第二级比较器）来覆盖R2短路和C1短路故障。
2.4 常见误区与总结复盘
误区一：将ASIL等级直接等同于硬件指标
ASIL等级是“流程和措施”的等级，而SPFM/LFM/PMHF是“量化结果”。ASIL D要求SPFM≥99%，但即使SPFM达到99.5%，也不代表自动满足ASIL D——仍需满足LFM、PMHF、安全机制有效性、开发流程合规性等全部要求。
误区二：忽略安全机制自身的失效率
安全机制（如比较器、看门狗、诊断软件）本身也是硬件，也会失效。在FMEDA中，安全机制的失效率必须计入“安全机制失效率”类别，且其自身的单点故障也会影响SPFM。例如，用于检测过压的比较器如果自身失效，可能导致安全目标被违背。
误区三：ASIL分解后各通道独立开发，不做交叉验证
ASIL分解的前提是“独立性”。如果两个通道共享同一个晶振或同一个电源域，则独立性不成立，分解无效。实践中，必须通过故障注入测试（如短路一个通道的电源，验证另一通道仍能工作）来证明独立性。
总结复盘：从ASIL到硬件指标的完整链路
本章的核心逻辑可归纳为：HARA确定ASIL → ASIL赋予安全目标 → 安全目标分解为FSR/TSR/HSR → HSR驱动硬件架构设计 → FMEDA计算SPFM/LFM/PMHF → 对比ASIL要求验证达标。这条链路中，任何一环的断裂（如安全需求遗漏、失效率数据错误、安全机制覆盖不足）都会导致最终硬件指标不达标。工程师应在项目早期就建立这条映射关系，并在硬件设计迭代中持续更新FMEDA模型，而非在流片前才进行“补算”。