ISO 21448

ISO 21448 标准概览

标准全称	道路车辆 预期功能安全 (Road vehicles — Safety of the intended functionality)
简称	SOTIF
核心定义	消除因系统预期功能不足或性能局限导致的危害
适用领域	高级辅助驾驶（ADAS）、自动驾驶系统（AD）
关键策略	通过降低触发条件（Triggering Conditions）来降低风险

ISO 21448，通常被称为 SOTIF（Safety of the Intended Functionality，预期功能安全），是自动驾驶与高级驾驶辅助领域内，与 ISO 26262 同等重要的安全支柱标准。

与 ISO 26262 关注“系统故障导致的风险”不同，ISO 21448 关注的是“系统功能正常，但因为性能不足或环境感知错误导致的危害”。例如，当自动驾驶车辆的摄像头在强眩光下无法正确识别前方障碍物时，系统并未发生电气故障，而是其自身设计的感知算法在特定环境下存在局限性，从而导致了危险。SOTIF 的目标正是通过识别并消除这类“非故障性”风险。

1. 核心定义：什么是 SOTIF？

SOTIF 将风险划分为四大区域：

• I 区（Known Safe）：已知安全场景。
• II 区（Known Unsafe）：已知不安全场景（需通过设计变更消除）。
• III 区（Unknown Unsafe）：未知的不安全场景（需通过测试与验证挖掘）。
• IV 区（Unknown Safe）：未知的安全场景。

SOTIF 的终极目标是将 II 区和 III 区 的面积压缩到最小，从而确保车辆在各种复杂感知环境下具备足够的鲁棒性。

2. SOTIF 与 ISO 26262 的本质差异

在自动驾驶系统设计中，两者共同构成了安全保障的双重防线：

评估维度	ISO 26262 (功能安全)	ISO 21448 (预期功能安全)
核心关注	系统失效（故障，如芯片损坏、短路、软件逻辑错误）。	系统性能限制（算法局限，如识别错误、感知延迟）。
物理机理	系统硬件或软件未按预期工作。	系统按设计规范工作，但该规范无法应对复杂工况。
应对策略	冗余、自检、安全状态进入（Safe State）。	性能提升、运行域（ODD）限制、环境感知增强。
典型案例	刹车控制模块因内存溢出死锁。	在大雾天中车道线识别算法误报。

---

3. 应对 ISO 21448 的工程开发路径

为了满足 SOTIF 要求，硬件与算法协同开发的 Checklist 如下：

1. 定义运行域 (ODD, Operational Design Domain)：必须明确系统能够正常工作的环境边界（如光照强度 $<10^5\text{ lux}$，行驶速度 $<80\text{ km/h}$，雨雪强度等级等）。超出的场景即为不确定边界。
2. 触发条件挖掘 (Triggering Conditions)：利用大量的路测数据与仿真数据，穷尽挖掘可能导致算法失能的场景。例如：特殊的阴影形状、极端的色彩反差、特殊的几何障碍物遮挡。
3. 性能验证与提升 (Verification & Validation)：

   * 仿真测试 (SIL/HIL)：在仿真环境（例如 CARLA 或其他工业级工具链）中进行数千万公里的边缘场景（Edge Case）压力测试。
   * 影子模式 (Shadow Mode)：在量产车辆上部署影子模型，在后台收集真实道路数据，持续闭环验证算法在真实工况下的鲁棒性。

1. 系统设计降级策略：当感知系统检测到环境超出了 ODD 的能力范畴时，必须触发系统分级降级（Degradation Strategy）。例如，从自动驾驶模式降级为 L2 辅助驾驶，或者提示驾驶员接管。

---

4. 硬件层面的配合措施

虽然 SOTIF 侧重于感知算法与 AI 模型，但硬件层面必须提供可靠的支撑：

• 传感器的冗余异构 (Sensor Fusion & Heterogeneity)：不能仅依赖单一传感源。设计上必须采用摄像头、毫米波雷达、激光雷达（LiDAR）等多传感器数据融合机制。当某一传感器因物理局限性（如激光雷达在浓雾中失效）无法识别时，其他传感器必须能接管安全判断。
• 计算平台的算力冗余 (Compute Redundancy)：确保用于执行 SOTIF 相关 AI 算法的 SoC 拥有足够的处理余量。当感知算法需要切换至更复杂的鲁棒模式（Robust Mode）时，硬件资源绝不能因为过载导致计算时间延迟。

参见

• ISO 26262
• ISO 26262-6
• ADAS系统工程
• 自动驾驶运行域 (ODD)