功能安全基础：ASIL等级定义、安全目标、安全需求、硬件安全需求与软件安全需求的关联
在ISO 26262功能安全标准体系中，ASIL（Automotive Safety Integrity Level，汽车安全完整性等级）是贯穿整个开发流程的核心度量标尺。它不仅是风险分类的工具，更是从系统级到硬件级、软件级需求分解与验证的“契约基线”。本章将围绕ASIL等级的确定方法、安全目标（Safety Goal）的制定逻辑，以及硬件安全需求（Hardware Safety Requirements, HWSR）与软件安全需求（Software Safety Requirements, SWSR）之间的映射关系展开深度解析，帮助学员建立从“抽象风险”到“具体实现”的完整认知链条。
上图展示了从危害事件到软硬件需求的核心链路。在实际项目中，这条链路并非简单的线性传递，而是包含多次迭代、细化和验证的闭环过程。ASIL等级决定了安全目标所需的严格程度，而安全目标又进一步分解为功能安全需求，最终在硬件和软件层面落地为可量化、可验证的技术指标。下面我们将逐一拆解每个环节的关键要点。
核心原理：ASIL等级的定义与确定逻辑
ASIL等级基于三个风险参数的综合评估：严重度（Severity, S）、暴露概率（Exposure, E）和可控性（Controllability, C）。ISO 26262-3:2018 第6章给出了详细的分类表格，每个参数分为0-3四个等级（其中S0、E0、C0表示无风险或可忽略）。最终ASIL等级通过查表确定：
| 严重度 S | 暴露概率 E | 可控性 C | ASIL等级 |
|---|---|---|---|
| S1（轻伤） | E1（极低） | C1（简单可控） | QM（质量管理） |
| S2（重伤） | E2（低） | C2（一般可控） | ASIL A |
| S3（致命） | E3（中） | C3（难以控制） | ASIL B / C / D |
| S3（致命） | E4（高） | C3（难以控制） | ASIL D |
需要特别强调的是，ASIL等级不是“算出来”的，而是“论证出来”的。每个参数的选择必须基于实际场景的工程判断，并记录在危害分析与风险评估（HARA）报告中。例如，对于电动助力转向系统（EPS），如果电机意外施加力矩导致车辆偏离车道，严重度通常为S3（可能致命），暴露概率取决于车辆使用频率（E4），可控性则取决于驾驶员反应时间（C2或C3）。这种组合往往落在ASIL C或ASIL D。
判断方法：从安全目标到功能安全需求的分解流程
安全目标（SG）是顶层安全要求，通常以“避免XX危害事件”的否定句式描述，并明确ASIL等级和安全状态（Safe State）。例如：
- SG1：避免因电池过充导致的热失控，ASIL D，安全状态为“断开充电接触器并进入故障模式”。
- SG2：避免因车速传感器失效导致意外加速，ASIL C，安全状态为“限制电机扭矩至安全阈值”。
从SG到功能安全需求（FSR）的分解，需要遵循以下步骤：
- 识别功能场景：明确SG对应的系统功能、运行模式、环境条件。
- 定义检测机制：确定如何检测故障（例如：传感器合理性检查、信号超时监控）。
- 制定响应策略：明确故障发生后的降级路径（例如：进入跛行模式、关闭子系统）。
- 分配ASIL属性：每个FSR继承SG的ASIL等级，或根据分解规则进行合理降级（需满足独立性）。
例如，对于SG1（电池过充保护），FSR可能包括：FSR1（电压监测，ASIL D）、FSR2（电流监测，ASIL D）、FSR3（温度监测，ASIL C，因为温度变化较慢，可接受较低等级）。这种分解必须通过安全分析（如FTA）验证其充分性。
案例拆解：硬件安全需求与软件安全需求的关联实战
以车载域控制器中的电源管理芯片（PMIC）为例，展示HWSR与SWSR的关联。假设系统级安全目标为：“避免因电源失效导致MCU意外复位，造成车辆行驶中动力中断”，ASIL B。
硬件安全需求（HWSR）示例：
- HWSR-1：PMIC的欠压检测阈值设定为3.0V ± 2%，响应时间小于100μs，诊断覆盖率≥90%。
- HWSR-2：PMIC的看门狗（Watchdog）功能必须在MCU时钟失效后50ms内触发复位信号。
- HWSR-3：PMIC的电源输出纹波在负载突变时不超过±5%，避免影响MCU工作。
软件安全需求（SWSR）示例：
- SWSR-1：MCU软件每10ms读取一次PMIC状态寄存器，若检测到欠压标志，则执行安全状态（存储关键数据并进入复位流程）。
- SWSR-2：软件看门狗（WWDG）刷新周期为20ms，若PMIC看门狗未被及时刷新，则触发系统复位。
- SWSR-3：软件需在启动时执行PMIC自检（BIST），验证其诊断功能是否正常。
两者的关联体现在：硬件提供诊断能力，软件负责诊断执行与响应。如果硬件诊断覆盖率不足（例如欠压检测只有80%），则软件必须增加额外的冗余检测（例如通过ADC采样电压进行交叉验证），以满足整体ASIL B的指标要求。这种“硬件+软件”协同设计是FMEDA分析的基础。
常见误区与总结复盘
在实际项目中，以下误区经常导致安全需求定义不完整或过度设计：
- 误区1：将ASIL等级直接分配给所有需求。实际上，ASIL分解允许将高等级需求分解为多个低等级子需求，但必须满足“冗余且独立”的条件。例如，ASIL D可以分解为ASIL C(D) + ASIL A(D)，但两条路径不能共享同一失效模式。
- 误区2：硬件需求与软件需求脱节。硬件定义了诊断机制，但软件未实现对应处理逻辑，导致安全机制形同虚设。必须建立双向追溯矩阵（HWSR ↔ SWSR）。
- 误区3：忽略安全状态的可行性。安全状态必须是系统可达到的物理状态。例如，对于高压电池系统，安全状态是“断开接触器”，但如果接触器本身失效，则需要额外的冗余路径。
- 误区4：过度依赖软件诊断弥补硬件缺陷。软件诊断的响应时间通常比硬件慢（毫秒级 vs 微秒级），对于快速失效场景（如短路），必须由硬件直接响应。
总结复盘：ASIL等级是功能安全的“锚点”，安全目标是“方向”，功能安全需求是“桥梁”，而硬件与软件安全需求则是“落地”。在项目开发中，建议采用以下流程：
- 完成HARA，确定SG及ASIL等级。
- 进行系统级FTA（故障树分析），识别关键失效模式。
- 将SG分解为FSR，并分配ASIL属性。
- 将FSR细化为HWSR和SWSR，建立追溯矩阵。
- 通过FMEDA验证硬件指标（SPFM、LFM、PMHF），通过软件安全分析验证诊断覆盖率。
- 迭代优化，直到所有指标满足ASIL要求。