功能正常≠绝对安全!解读自动驾驶背后的ISO 21448 (SOTIF)

导语:当汽车变得越来越“聪明”,高级驾驶辅助(ADAS)和自动驾驶(AD)技术日益普及,一个核心问题浮出水面:即使硬件没坏、软件没崩,这些智能功能本身是否足够安全可靠?ISO 21448标准(又称SOTIF),正是为解决这个“预期功能安全”难题而生!


SOTIF是什么?

聚焦“功能不足”与“人为误操作”

简单来说,ISO 21448 (SOTIF) 的核心目标,是解决预期功能本身可能存在的安全问题。

这包括两大风险源头:

  • 功能不足:系统设计或能力存在局限,在特定情况下无法正确应对(比如传感器未能识别某些障碍物)。
  • 人为误操作:驾驶员或其他道路使用者以合理可预见的方式,误用或超出系统设计范围使用功能(比如过度依赖辅助驾驶导致分神)。

SOTIF 关注的重点,并非传统意义上的硬件故障或软件错误(那是ISO 26262功能安全标准的范畴),而是功能在“正常工作”状态下,由于设计局限或使用场景的复杂性,依然可能引发的危险。它的终极目标,是将这些未知风险降到合理可接受的最低水平。


为何需要SOTIF?

自动驾驶时代的必然要求

随着ADAS/AD技术的飞速发展,车辆感知环境、做出决策的过程变得极其复杂,涉及大量传感器(摄像头、雷达、激光雷达等)与软件算法的精密协作。

传统基于硬件故障分析的安全标准(如ISO 26262)已无法完全覆盖这些由系统能力边界和复杂人机交互带来的新型风险。

SOTIF 应运而生,成为ISO 26262在智能驾驶领域的重要补充。它强调一个关键点:必须证明系统在已知的、定义好的运行场景(Operational Design Domain, ODD)内行为是安全的,并且遭遇未知、不安全场景的概率足够低(这需要像驾驶员监控系统DMS这样的保障机制)。


SOTIF怎么做?

高度迭代的设计与验证

实现SOTIF是一个高度迭代的过程,核心围绕三个阶段展开:

识别风险: 基于系统规格和预定运行范围,深入分析可能触发系统功能不足或导致误操作的条件(称为“触发条件”)。这些条件是后续改进的基础。

设计改进: 针对识别出的风险点,优化系统设计(如改进算法、增加冗余感知、完善人机交互)。

验证与确认: 通过大量基于场景的测试,在实际或模拟的用例中验证系统表现,确认残余风险是否达标。虚拟测试(仿真)在此扮演了核心角色。


SOTIF vs. ISO 26262

分工明确,互为补充

ISO 26262 (功能安全): 管的是“硬件坏了/软件崩了”怎么办?目标是防止由电气/电子系统故障直接引发的危险(比如传感器突然失灵)。

ISO 21448 (SOTIF - 预期功能安全): 管的是“硬件软件都正常,但功能本身不够用或用错了”怎么办?目标是应对因设计局限和合理预见的人为操作带来的风险。


SOTIF的价值与挑战

虚拟测试是关键

SOTIF 极大地推动了基于场景的测试,尤其是虚拟仿真测试在汽车开发中的应用。原因很直接:面对ADAS/AD系统传感器与软件间近乎无穷的复杂交互,仅靠实车路试是远远不够的——成本高昂、场景覆盖有限、极端危险场景难以复现。

虚拟测试提供了在可控、可重复环境中进行海量场景验证的可能性,是评估系统在已知和探索未知风险区域的关键工具。这正是SOTIF标准的巨大价值所在,它已成为成功开发可靠ADAS/AD功能的基石。

当然,挑战犹存: SOTIF 并未详细规定如何将虚拟测试、试验场测试和实际道路测试完美结合。如何有效整合这些验证手段,形成完整的证据链,确保系统在真实世界的绝对安全,仍是行业需要持续探索和实践的重要课题。


总结

ISO 21448 (SOTIF) 是智能汽车安全演进的重要里程碑。它直面智能驾驶时代的核心安全挑战——预期功能本身的可靠性。通过系统性地识别功能局限、防范人为误用,并依托强大的虚拟测试技术,SOTIF 致力于让自动驾驶系统不仅“聪明”,更能在复杂多变的现实世界中“可靠、安全”地运行。随着技术的进步,如何融合多种验证手段,将是实现更高等级自动驾驶安全的关键路径。


本文转自:知行致远管理咨询,转载此文目的在于传递更多信息,版权归原作者所有。如不支持转载,请联系小编demi@eetrend.com删除。

最新文章