2. 功能安全基础
在 ISO 26262 的语境中，“功能安全”并不是指系统功能本身是否好用，而是指避免由电子电气系统功能异常所导致的不可接受风险。它关注的是当系统发生随机硬件失效、系统性失效或共因失效时，车辆能否进入安全状态，或至少把风险控制在可接受范围内。理解功能安全，必须同时掌握四个基础概念：功能安全、安全生命周期、ASIL 等级、危害分析与风险评估。
一、功能安全的核心原理
功能安全的核心逻辑可以概括为：从危害出发，定义安全目标，再逐层分配到系统、硬件和软件。它不追求“零失效”，而是追求“失效可容忍”。例如，电子驻车制动系统若发生意外释放，可能导致车辆溜车；对应的安全目标可能是“避免行车中非预期释放驻车制动”，并规定相应的安全状态与故障容错时间。
功能安全与预期功能安全（SOTIF）不同：前者主要处理系统故障引发的风险，后者处理功能不足或可预见误用引发的风险。在软硬件协同工程中，功能安全要求软硬件共同承担安全机制，例如看门狗、锁步核、ECC、CRC、冗余采样、安全状态切换等。
二、安全生命周期：从概念到报废
ISO 26262 定义了完整的安全生命周期，覆盖概念阶段、开发阶段、生产运行阶段和报废阶段。其主线是：相关项定义 → 危害分析与风险评估 → 安全目标 → 功能安全概念 → 技术安全概念 → 硬件/软件开发 → 集成与验证 → 安全确认 → 生产运行与报废。
在软硬件协同中，安全生命周期强调“追溯性”：每一个安全目标都能追溯到危害事件，每一项安全机制都能追溯到技术安全需求，每一条测试用例都能追溯到安全需求。没有追溯性，安全论证就会断裂。
三、ASIL 等级：风险量化与开发约束
ASIL（Automotive Safety Integrity Level）是 ISO 26262 用于表达安全完整性等级的分级，分为 A、B、C、D 四个等级，D 最高。ASIL 由三个维度决定：严重度 S、暴露率 E、可控性 C。三者组合后通过查表得到 ASIL 等级，若风险过高则可能被判定为 QM（仅需质量管理）或 ASIL A～D。
| 维度 | 含义 | 典型分级 |
|---|---|---|
| S（Severity） | 危害对人员伤害的严重程度 | S0～S3 |
| E（Exposure） | 运行场景中危害发生的暴露概率 | E0～E4 |
| C（Controllability） | 驾驶员或其他人员控制危害的能力 | C0～C3 |
| ASIL | 由 S/E/C 组合确定的安全完整性等级 | QM、A、B、C、D |
ASIL 等级直接影响开发约束：ASIL D 要求更高的硬件诊断覆盖率、更严格的软件架构、更完整的验证与确认活动。例如，ASIL D 的随机硬件失效指标要求 SPFM ≥ 99%、LFM ≥ 90%；而 ASIL B 的要求相对宽松。软硬件协同的关键在于：硬件提供诊断能力，软件执行诊断并响应故障，二者共同满足安全目标。
四、危害分析与风险评估（HARA）
HARA 是安全生命周期的起点，也是功能安全最核心的分析活动。其基本流程为：识别危害事件 → 确定 S/E/C → 查表得到 ASIL → 定义安全目标 → 分配 ASIL 到安全目标。
以“行车中非预期释放电子驻车制动”为例：
危害事件：行车中 EPB 非预期释放
S：S3（可能导致严重碰撞伤害）
E：E4（行车中高暴露）
C：C2（驾驶员较难控制）
ASIL：D
安全目标：避免行车中非预期释放 EPB
安全状态：保持驻车制动或进入安全停车
故障容错时间：≤ 100 msHARA 的输出不是一份“风险清单”，而是一组可追溯的安全目标。每个安全目标都必须分配 ASIL，并进一步分解为功能安全需求和技术安全需求。软硬件团队在此基础上分别定义安全机制、诊断策略和测试用例。
五、案例与复盘：软硬件协同中的典型问题
某车型在开发电子驻车制动时，硬件团队设计了电流采样冗余，软件团队却未实现冗余通道的交叉校验，导致单点故障无法被诊断。复盘发现：HARA 已识别出 ASIL D 安全目标，但技术安全概念未把“冗余采样校验”分配到软件需求，追溯链断裂。
改进措施包括：在技术安全概念中明确软硬件接口（HSI），把诊断覆盖率目标写入软件需求，并在集成测试中增加故障注入用例。这个案例说明：功能安全不是硬件或软件单方面的任务，而是从危害到安全目标、再到软硬件安全机制的闭环协同。
掌握功能安全、安全生命周期、ASIL 等级和 HARA，是后续软硬件协同安全设计、安全机制实现与安全论证的基础。只有把危害、风险、安全目标和软硬件需求串成一条可追溯的链条，功能安全才能真正落地。