查看“︁ISO 21448”︁的源代码

__TOC__
{| class="wikitable" style="float: right; width: 330px; margin-left: 1.5em; clear: right; font-size: 90%; border: 1px solid #a2a9b1; background-color: #f8f9fa;"
|+ style="font-weight: bold; font-size: 1.1em; padding: 6px; background-color: #007a33; color: #fff; border: 1px solid #a2a9b1; border-bottom: none;" | ISO 21448 标准概览
|-
! style="background-color: #f2f2f2; width: 40%; text-align: left; padding: 5px;" | 标准全称
| 道路车辆 预期功能安全 (Road vehicles — Safety of the intended functionality)
|-
! style="background-color: #f2f2f2; text-align: left; padding: 5px;" | 简称
| SOTIF
|-
! style="background-color: #f2f2f2; text-align: left; padding: 5px;" | 核心定义
| 消除因系统预期功能不足或性能局限导致的危害
|-
! style="background-color: #f2f2f2; text-align: left; padding: 5px;" | 适用领域
| 高级辅助驾驶（ADAS）、自动驾驶系统（AD）
|-
! style="background-color: #f2f2f2; text-align: left; padding: 5px;" | 关键策略
| 通过降低触发条件（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 的本质差异 ==

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

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

---

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

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

# '''定义运行域 (ODD, Operational Design Domain)'''：必须明确系统能够正常工作的环境边界（如光照强度 <math>< 10^5\text{ lux}</math>，行驶速度 <math>< 80\text{ km/h}</math>，雨雪强度等级等）。超出的场景即为不确定边界。
# '''触发条件挖掘 (Triggering Conditions)'''：利用大量的路测数据与仿真数据，穷尽挖掘可能导致算法失能的场景。例如：特殊的阴影形状、极端的色彩反差、特殊的几何障碍物遮挡。
# '''性能验证与提升 (Verification & Validation)'''：
    * '''仿真测试 (SIL/HIL)'''：在仿真环境（例如 CARLA 或其他工业级工具链）中进行数千万公里的边缘场景（Edge Case）压力测试。
    * '''影子模式 (Shadow Mode)'''：在量产车辆上部署影子模型，在后台收集真实道路数据，持续闭环验证算法在真实工况下的鲁棒性。
# '''系统设计降级策略'''：当感知系统检测到环境超出了 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)]]
* [[分类:功能安全]]
* [[分类:自动驾驶]]

[[Category:功能安全]]
[[Category:自动驾驶]]