📚 课程目录第3章功能安全与预期功能安全

3. 功能安全与预期功能安全

在自动驾驶冗余计算与故障切换工程中，功能安全与预期功能安全是两条并行的安全主线。ISO 26262 关注的是“系统发生故障时是否仍然安全”，即由电子电气系统失效、随机硬件失效、系统性失效所引发的风险；ISO 21448 关注的是“系统没有故障，但性能局限或场景理解不足时是否仍然安全”，即预期功能安全（SOTIF）。两者共同构成自动驾驶安全论证的底座，而 ASIL 等级与安全目标则是把抽象安全理念落到工程约束的关键桥梁。

核心区别：ISO 26262 处理“故障导致的不安全”，ISO 21448 处理“无故障但功能不足导致的不安全”。冗余计算与故障切换主要服务于前者，但必须同时考虑后者对切换策略和降级策略的影响。

一、ISO 26262 的核心思想：从危害到安全目标

ISO 26262 的核心是“以风险为导向”的闭环流程。它要求先识别整车层面的危害事件，再通过危害分析与风险评估（HARA）确定 ASIL 等级，随后为每个危害事件定义安全目标（Safety Goal），并进一步分解为功能安全需求（FSR）和技术安全需求（TSR）。在冗余计算架构中，安全目标通常表现为“在指定故障条件下，系统应进入安全状态”或“在单点故障下，仍能维持最低限度的控制能力”。

HARA 的三个关键参数是严重度（S）、暴露率（E）和可控性（C）。三者组合决定 ASIL 等级，从 QM、ASIL A 到 ASIL D，ASIL D 要求最严苛。ASIL 等级不是对某个模块的“标签”，而是对危害事件的安全目标属性；同一系统中不同功能可以有不同 ASIL，但高 ASIL 需求会向下游传导，影响冗余设计、诊断覆盖率、开发流程和验证深度。

二、ISO 21448 的核心思想：场景不足与性能局限

ISO 21448 针对的是“没有故障，但系统能力不够”的风险。例如摄像头在逆光下识别失败、毫米波雷达对静止物体误判、感知算法对罕见场景泛化不足。这些不属于传统功能安全范畴，却可能直接导致事故。SOTIF 的核心工作是识别已知不安全场景、未知不安全场景，并通过场景库、仿真、封闭场地和道路测试，把未知不安全场景逐步转化为已知安全场景。

在冗余计算与故障切换中，SOTIF 的影响体现在：切换逻辑不能只依赖“故障信号”，还要考虑“性能退化信号”。例如当主通道置信度持续下降但未报故障时，系统应主动降级或请求接管，而不是等到硬故障发生才切换。

三、ASIL 等级划分与安全目标定义

ASIL 等级由 S、E、C 三个维度综合评定。下表给出典型组合与工程含义，便于在冗余架构设计中快速定位安全目标强度。

ASIL	典型 S/E/C 组合	冗余与诊断要求	故障切换策略
QM	低严重度、低暴露、易可控	常规质量管理	无需专门安全机制
ASIL A	S1/E2/C1 等	基础诊断覆盖	可接受降级运行
ASIL B	S2/E2/C2 等	较高诊断覆盖率	快速切换至备用通道
ASIL C	S2/E3/C2 等	高诊断覆盖率、双通道	无缝切换，保持控制
ASIL D	S3/E3/C3 等	最高完整性、锁步/三模冗余	故障后仍维持安全状态

安全目标定义应遵循“可验证、可分解、可追溯”原则。例如：“防止车辆在高速行驶中因计算通道失效而失去横向控制”，对应 ASIL D，则需分解为：主通道与备用通道独立供电、独立时钟、交叉校验、故障检测时间小于 100ms、切换时间小于 50ms 等具体指标。安全目标不是一句口号，而是后续架构设计、测试用例和证据链的源头。

四、冗余计算中的安全目标落地：一个故障切换场景

假设自动驾驶域控制器采用双 SoC 冗余架构，主 SoC 运行感知与规划，备用 SoC 热备份。当主 SoC 发生锁步比较错误或看门狗超时，安全机制需在故障容错时间间隔（FTTI）内完成切换。FTTI 由“故障发生—检测—反应—进入安全状态”四段时间组成，任何一段超时都可能导致安全目标失效。

安全目标 SG-01：防止因主计算通道失效导致车辆失去纵向控制
ASIL：D
FTTI：200 ms
分解：
  - 故障检测时间 ≤ 80 ms
  - 切换决策时间 ≤ 40 ms
  - 执行器接管时间 ≤ 60 ms
  - 安全状态：减速至 0.3g 以下并靠边停车
诊断覆盖：
  - 锁步比较错误：99%
  - 看门狗超时：99%
  - 电源监控：99%

该场景中，ISO 26262 提供故障检测与切换的流程约束，ISO 21448 则要求评估“切换后备用通道是否具备足够场景理解能力”。如果备用通道仅维持车道保持，而当前场景是施工区锥桶绕行，则切换后仍可能不安全。因此，冗余设计必须把 SOTIF 场景覆盖纳入切换策略，必要时触发最小风险策略（MRM）。

五、常见误区与复盘要点

误区一：把 ASIL 等级当成模块属性。ASIL 是危害事件的安全目标属性，同一模块在不同危害事件中可能承担不同 ASIL 需求，不能简单给模块贴“ASIL D”标签。
误区二：只做 ISO 26262，忽略 SOTIF。冗余切换能解决故障，但解决不了“无故障但感知不足”。切换后备用通道若场景理解能力不足，仍会触发不安全行为。
误区三：安全目标不可验证。“保证安全”不是安全目标。必须量化 FTTI、诊断覆盖率、切换时间、安全状态定义，才能形成可测试、可追溯的证据链。
误区四：FTTI 估算过于乐观。故障检测、仲裁、执行器响应均存在最坏情况，必须按最坏情况累加，并留出余量。

工程建议：在冗余计算架构设计早期，先建立“危害事件—ASIL—安全目标—安全机制—测试用例”的追溯矩阵。每一行都必须能回答：故障是什么、检测手段是什么、切换时间是多少、安全状态是什么、验证证据在哪里。

注意：ISO 26262 与 ISO 21448 不是二选一，而是互补。自动驾驶系统中，ASIL D 的故障切换设计必须同时接受 SOTIF 场景覆盖的检验，否则“切换成功”不等于“运行安全”。

综上，ISO 26262 提供了从危害到安全目标的故障安全框架，ISO 21448 补足了无故障场景下的预期功能安全盲区，ASIL 等级则把风险强度转化为可执行的开发约束。在冗余计算与故障切换工程中，只有把安全目标、FTTI、诊断覆盖率和场景覆盖统一到同一套架构与验证体系中，才能真正实现“故障可切换、切换后仍安全”的设计目标。