从ISO 26262到ISO 21448的演进与落地实践
目录导读
- 自动驾驶功能安全的内涵与挑战
- 核心标准体系解析：ISO 26262与ISO 21448
- 安全标准在感知、决策、执行层的落地
- 功能安全与预期功能安全（SOTIF）的区别与协同
- 行业实践案例与常见误区
- 未来趋势：合规性与创新性的平衡
- 问答专区（8个高频问题深度解答）
自动驾驶功能安全的内涵与挑战
随着L3级以上自动驾驶逐步商用,功能安全已成为行业生死线，功能安全的核心目标是：当系统发生可预见的故障时，能通过冗余设计、降级策略等手段，将风险降至可接受水平，与传统的ADAS不同，自动驾驶系统面临更高的复杂性——感知融合、行为规划、控制执行环环相扣，任何一个环节的失效都可能导致灾难性后果。
主要挑战包括：
- 系统级安全目标的分解与验证（ASIL等级分配）
- 传感器、执行器的随机硬件失效与系统性失效
- 机器学习模型的可解释性与安全边界
- 多供应商协作下的接口一致性
核心标准体系解析：ISO 26262与ISO 21448
ISO 26262：功能安全的基础框架
- 适用范围：道路车辆电子/电气系统（量产前）
- 核心概念：ASIL（A/B/C/D）等级定义、安全生命周期管理（概念阶段→开发→生产→运行）、故障覆盖率要求
- 关键输出：安全目标、功能安全概念、技术安全概念、硬件架构度量（PMHF、SPFM、LFM）
- 局限性：默认假设系统功能本身是“正确”的，即仅处理随机硬件失效和系统性失效，不涵盖“功能不足”导致的风险
ISO 21448（SOTIF）：预期功能安全标准
- 应对场景：系统在无故障时，因性能局限（如传感器识别盲区、场景理解偏差）引发的危害
- 核心方法：已知危害场景覆盖（通过仿真+路测）、未知危害场景的统计覆盖度提升、触发条件分析（ODD边界定义）
- 关键区别：SOTIF不关注“硬件坏了”或“软件bug”，而关注“算法在正常工况下做不到”
两者关系：ISO 26262是基础，ISO 21448是补充，开发流程上，需先完成功能安全设计，再评估预期功能安全风险。
安全标准在感知、决策、执行层的落地
感知层：冗余与多样性
- 硬件冗余：双目摄像头+毫米波雷达+激光雷达，确保单一传感器失效时仍可感知
- 算法冗余：多模型并行推理（如基于CNN和基于Transformer的感知网络），投票机制输出最终结果
- 标准落地：对传感器本身需满足ASIL-B/C要求（如摄像头ISP的校验机制）；感知算法需通过ISO 21448的场景覆盖测试（如雨雾、逆光、异形障碍物）
决策层：安全裕度与降级逻辑
- 行为决策：规划路径时预留安全时间缓冲（如TTC<3s触发紧急制动），避免“速度-距离”边界临界
- 控制切换：当主控制器失效时，立即切换至备份控制器（冗余+独立供电）
- 标准落地：决策逻辑需通过FMEA分析，定义“功能不足”场景（如无法识别静止车辆时，系统应启动最小风险策略）
执行层：故障响应与容错
- 制动系统：双回路液压+电子驻车冗余，单点失效后仍可提供80%制动效能
- 转向系统：双电机冗余，检测到失效后立即切换至同轴备份
- 标准落地：执行器需满足ASIL-D硬件要求（如PMHF<10 FIT），并通过硬件故障注入测试验证
功能安全与预期功能安全（SOTIF）的区别与协同
| 维度 | 功能安全（ISO 26262） | 预期功能安全（ISO 21448） |
|---|---|---|
| 关注问题 | 硬件随機失效/系统性失效 | 功能性能局限（无故障时） |
| 典型场景 | 传感器电源短路、CPU死锁 | 雷达误检静止物体、夜间识别准确率下降 |
| 分析方法 | FMEA、FTA、FMEDA | 场景覆盖分析、触发条件识别 |
| 验证手段 | 故障注入测试、硬件老化测试 | 仿真场景库覆盖、真实路测统计 |
协同要点：
- SOTIF中识别的触发条件,可能引发功能安全危害（如传感器在雨雾中性能下降，导致系统无法及时制动），需两者联合分析
- 功能安全的“安全目标”应覆盖SOTIF的危害事件；SOTIF的“场景覆盖度”应纳入功能安全的验证计划
- 实际开发中,建议建立“安全案例”（Safety Case），整合两者的证据链条
行业实践案例与常见误区
正确实践：Waymo的安全论证方法
- 构建详细的ODD（运行设计域）边界，如“禁止在无路灯道路行驶”
- 通过仿真+封闭场地+公共道路，覆盖数十亿英里里程
- 每项功能变更后,重新评估安全目标的ASIL等级与SOTIF场景覆盖
常见误区
- 误区一：认为“有冗余就是安全的”——冗余设计需考虑共因失效（如同一路线的供电）
- 误区二：将ASIL等级简单加总——多系统交互时，安全目标需从系统级分解
- 误区三：忽略SOTIF的“未知危害”——仅覆盖已知场景，对罕见天气、不规则交通行为缺乏统计
- 误区四：验证不足——仅通过路测验证，未结合仿真生成“极限边缘场景”
未来趋势：合规性与创新性的平衡
- 标准演进：ISO 26262第二版已增加半导体指南，预期ISO 21448将扩展至机器学习模型的量化验证
- 工具链融合：安全分析工具（如Medini Analyze）与仿真平台（如Carla）的深度集成
- 法规联动：联合国WP.29的自动车道保持系统（ALKS）法规要求功能认证，未来L4级车辆需提交功能安全与SOTIF的双重文档
- 开源方案：如Automotive Grade Linux的安全框架，降低中小厂商合规成本
关键建议：
- 早于量产3年建立安全文化,而非临门一脚
- 建立“安全档案”，记录每个功能的安全目标与验证证据
- 与标准组织保持互动,参与WG14等工作组以获取最新解读
问答专区（8个高频问题深度解答）
Q1：ISO 26262与ISO 21448哪个更重要？
A：两者并重，没有功能安全，系统会“因故障失效”；没有SOTIF，系统会“正常但搞砸事情”，理想流程是：先完成功能安全的基础架构，再逐层补充SOTIF的场景覆盖。
Q2：ASIL等级可以降低吗？
A：可以，但需满足“安全目标分解+冗余验证”规则，将一个ASIL-D需求，分解为两个ASIL-B的子系统并行工作，需满足独立性证据。
Q3：中小车企如何高效满足标准？
A：建议采用“核心功能自研+安全壳模式”——关键安全模块（如制动、转向）严格按标准开发；非安全模块（如娱乐系统）采用隔离策略，与工具提供商（如Rapita Systems）合作，减少人工审查。
Q4：仿真测试能替代路测吗？
A：不能完全替代，但可大幅减少路测成本，关键场景（如行人横穿、侧撞）必须通过真实封闭场地验证；通用场景可通过仿真生成百万级覆盖。
Q5：机器学习模型如何做功能安全？
A：目前尚无单独标准，常用方法：① 对模型进行形式化验证（约束求解）；② 使用高斯过程等统计方法估计模型置信度；③ 设计安全监控模块（Safety Monitor），在模型输出异常时切至Rule-based策略。
Q6：ODD定义不明确怎么办？
A：采用“自顶向下+数据驱动”结合：先定义地理/天气/交通条件等硬边界，再通过路测中非预期事件反向修正ODD，建议保留10%的ODD余量。
Q7：多供应商系统如何保证安全一致性？
A：关键手段包括：① 定义清晰的接口安全契约（如信号保护时间、数据校验算法）；② 要求每个供应商提供DIA（Dependent Failure Analysis）报告；③ 进行系统级集成测试，注入故障看整链反应。
Q8：为什么有些公司宣称“通过了功能安全认证”但仍有事故？
A：可能原因：① 认证仅覆盖特定ODD，车辆驶出了认证范围；② SOTIF场景未被充分覆盖（如静止车辆碰撞）；③ 认证依据的是早期版本的标准（如ISO 26262:2011），未包含SOTIF要求。
自动驾驶功能安全标准的落地，不是“一纸认证”而是系统化工程，从ISO 26262到ISO 21448，行业正在从“故障防护”走向“性能置信”，任何想要在L3及以上赛道立足的企业，都需要在开发早期就建立安全基线，将标准内化为设计语言，面对日益严格的全球法规（如欧盟GSR、中国GB/T），合规不是成本，而是商业通行证。
注：本文综合了ISO官方文档、SAE J3016、Waymo安全报告、以及行业开发实践，旨在为工程师与管理者提供系统化视角，标准原文应以官方最新版本为准。
