自动驾驶的安全工程

功能安全 (Functional Safety, FuSa) 与预期功能安全 (Safety of the Intended Functionality, SOTIF) 的关系，犹如一枚金牌的两面：二者共同构成宝贵的整体。这两方面在现代高级驾驶辅助系统 (Advanced Driver Assistance System, ADAS) 以及自动驾驶 (Autonomous Driving, AD) 中都扮演着决定性角色。

在 FuSa 方面，有一个经典问题：当软件或硬件组件失效时，系统会作何反应？功能安全理念旨在确保系统不会因内部故障（例如传感器失效或软件故障）而导致不可接受的风险。该理念依托于一个结构化的分析过程，在此过程中，所有相关的软件和硬件故障都会就其影响进行分析和评估。对于那些被评定为安全关键的影响，会采取技术性和流程性措施予以减轻。功能安全的方法贯穿始终，意味着既应用于系统架构的概念设计阶段，也应用于量产开发过程中。

SOTIF 则提出了另一个同样重要的问题：如果系统本身运行无故障，但却无法应对真实的运行场景，会发生什么？这里关注的是由功能自身局限所产生风险的可接受度，例如，当车载摄像头因阳光产生眩光，或是算法在复杂驾驶场景中无法识别自行车骑行者。SOTIF 是一个探索性的发现过程，迭代是其逐步改进功能设计和生成知识的核心工具。

为实现系统的整体安全性，FuSa 与 SOTIF 二者系统性地相互关联、彼此互补。“FuSa 的作用是确保硬件和软件可靠工作。SOTIF 则确保这些可靠组件的性能得到充分界定并落实安全保障，从而在现实世界中安全运行。”保时捷工程系统安全专业学科负责人马雷克·胡德克 (Marek Hudec) 解释道，“原因在于：一个系统可能在功能安全上是完备的，但由于性能局限，在 SOTIF 意义上可能依然不够安全。”

尽管有相似之处，FuSa 与 SOTIF 在流程步骤上仍有所不同，因为实现 SOTIF 通常首选迭代式方法，并辅以探索性分析和测试方法（见第 38 页信息框）。“这意味着：开发人员对系统的设计进行规范、测试和修订，直至残余风险降至可接受的水平，”保时捷工程开发工程师丹尼斯·穆勒(Dennis Müller) 介绍道。

例如，为应对驾驶辅助系统和自动驾驶功能在复杂开发与安全保障方面的挑战，保时捷工程为客户提供了全面的解决方案组合，该组合涵盖了SOTIF 和 FuSa 这两种安全方法。“我们为客户提供的支持包括协助应用相关标准，例如 ISO 26262(FuSa) 和 ISO 21448 (SOTIF)。这包括将标准要求融入现有开发流程、执行危害与风险分析、制定安全概念以及全程支持整个安全生命周期，”穆勒解释道，“在保时捷工程，我们通过明确定义、职责清晰的整合流程，确保开发符合 FuSa 与 SOTIF的要求。这保证了标准的合规性以及完整的可追溯性。”

保时捷工程在整个开发链上均拥有深厚的专业积淀：从需求定义到仿真，再到实车测试，均采用最先进的仿真与测试方法，涵盖警告功能、泊车系统及（部分）自动驾驶功能的开发。在此过程中，专家团队尤其倚重于模块化软件组件“Guardian”。该组件旨在简化从先进的 Level 2 系统向符合 Level 3 标准的高等级自动驾驶的过渡。为自动驾驶系统安全组件的实施提供稳健、安全且符合标准的解决方案。通过分析真实驾驶数据，能够以探索性的方式识别出潜在的危险情景和边界情况（即所谓的“角落案例”和“边界案例”），并将其用于数据驱动的场景生成。

随着系统责任级别的提升，系统面临的挑战也随之水涨船高。在功能安全方面，挑战主要在于系统的降级策略和预警机制不能再仅仅依赖驾驶员——在辅助驾驶 (Level 1) 和部分自动驾驶 (Level 2) 阶段，驾驶员仍需独立承担所有车辆操控责任。这一情况从 Level 3 开始发生了改变：系统必须能够自主处理故障，因为从该级别起，驾驶员不再被要求持续监控驾驶环境。只有当系统达到其能力边界时，才需要在给予适当的预警时间后，由驾驶员接管并进行干预。因此，原则上，即使在出现故障状态时，也必须至少在一定时间内继续保持安全的运行能力——正因如此，从Level 2 到 Level 3 的跃升才如此富有挑战性。车辆电子系统中的冗余设计数量大幅增加——开发工作量和成本也随之显著上升。

而对于 SOTIF，挑战在于功能所需应对的所有潜在运行场景在范围上的深度和广度。“这包括不断变化的车辆环境、交通参与者的行为以及不可预见的事件（即所谓的‘未知不安全场景’），”胡德克说。为了驾驭这种复杂性，系统在初期会为一个明确的运行设计域进行设计。如此一来，安全保障场景便被限定在一个通过系统化方法推导出的空间内，该空间又通过一个场景组合被拆解为离散的独立场景。系统必须确保能够尽早探测到接近该区域边界的情况，从而保证在车辆仍处于经过安全保障的设计范围内时，能够将控制权交还给驾驶员或使车辆安全停车。“对于驾驶辅助功能的开发，这种方法至关重要：系统对实际驾驶所承担的责任越大，FuSa 和 SOTIF 安全方面的考量就越关键，”穆勒解释道。

有一个来自实践的具体例子，可以清晰阐明 FuSa与 SOTIF 之间的差异性和互补性：在高速公路上实现 SAE Level 3 自动驾驶的场景，在此场景中，驾驶员将完全交出车辆控制权。当需要掌控硬件或软件失效时，便是 FuSa 的用武之地：假设用于测量与前车距离的雷达传感器发生了硬件故障，不再提供数据。这个示例性故障案例可能导致功能依赖于陈旧或无效的传感器数据，在某些情况下甚至可能引发追尾事故。因此，保时捷工程的专家们会通过演绎和归纳式安全分析来识别此类故障，并且这些分析必须有相应的安全机制作为支撑。在此具体案例中，采用冗余设计是一个有效的解决方案，它可以确保此类局部单一故障不会导致传感器数据“全局性失效”，这一安全状态至少维持到驾驶员重新接管车辆控制权的那一刻。

当问题涉及高速公路自动驾驶中的性能边界管控时，便需要 SOTIF 介入。例如，车辆识别功能必须设计成能够识别围绕本车或正在接近本车的所有其他车辆，包括所有摩托车。然而，由于所用传感器普遍存在的、受技术限制的性能边界，在实际中可能出现这种情况：在光照不佳或恶劣天气条件下，车辆无法正确识别某些具有狭窄轮廓的物体及其接近轨迹。尽管硬件和软件运行无误，但这可能导致系统试图发起变道，从而带来与一辆正在超车的摩托车发生碰撞的风险。在这种情况下，SOTIF 流程规定，必须对所有运行场景下的设计方案进行分析和验证，并在下一个设计迭代周期内（更新规范并随之实现）修正已识别的缺陷。例如，可能通过在车辆后部加装额外的摄像头和激光雷达传感器，或优化传感器融合算法来实现。

“最大的挑战已不再只源于系统本身，更在于现实世界近乎无限的复杂性。我们不可能预先测试所有可以想象的场景，但必须实现对运行设计域的充分覆盖。因此，开发过程相应地也变得极为复杂。SOTIF 提供了一套指导框架，用以理解系统的局限性并确保其安全运行，即使所有系统组件都处于完美工作状态时也是如此，”穆勒解释道。

要在定性和定量层面证明一个系统是安全的，需要大量的测试数据，其中相当一部分需要通过仿真模拟来生成。最大的挑战在于如何应对“未知不安全场景”——即那些在开发阶段因规范不充分而未被考虑、或可能因运行条件变化而出现的危险情景。探索并最小化这类风险，是 SOTIF 的核心目标，也是系统开发中的重大挑战。

“在保时捷工程，我们为客户提供的不仅仅是单一的测试服务，更是一种紧密且长期的合作伙伴关系，旨在共同应对 ADAS/AD 开发的艰巨要求，并将安全、稳健、可靠的功能付诸实践，”胡德克承诺道。未来，基于人工智能的角落案例识别或专门训练的 AI 模型等方法将为开发人员带来越来越多的支持。

目前已经明确的是：要保障包含 AI 组件系统的安全，未来将需要更加复杂的验证流程。新的国际标准草案 ISO/PAS 8800 等正是旨在为这方面定义一个框架，该标准专注于对作为最终产品组成部分的人工智能进行安全保障。同样新出台的国际标准草案 ISO/TS 5083 则特别聚焦于车辆自动驾驶功能的安全保障议题，并（全新地）考虑了内部和外部相关组件的相互作用（即所谓整体安全）。车辆之间以及车辆与基础设施之间以安全为导向的车联万物 (V2X) 通信，不仅带来了提升安全性的新机遇，同时也引入了新的潜在故障源和系统依赖性。这些也同样需要以同等的严谨态度进行安全保障——这是一个充满挑战的过程，保时捷工程的专家们日复一日地投身于此。

在罕见的边界情况下，即使是正确实现的驾驶功能也可能出现运行异常。在本示例中，一名摩托车骑手正从车辆后方接近。在大多数情况下，骑手能被系统正确识别，从而阻止变道，但在如图所示的低角度阳光照射条件下，识别会变得更加困难。SOTIF 流程要求此类缺陷需在下一个设计迭代周期中得到修复——例如通过在车尾加装额外传感器或优化算法。

随着辅助系统的日益普及，对车辆功能安全的要求正在显著提高。SOTIF关注的核心在于正确实现的系统在边界情况下的性能表现。保时捷工程运用数据驱动和基于人工智能的多种方法来驾驭复杂性，从而将可靠的系统投入实际应用。

本文首次发表于《保时捷工程杂志》2025年第1期。

文字： Ralf Bielefeldt

版权：本文中发布的所有图片、视频和音频文件均版权保护。未经保时捷工程书面许可，不得部分或全部复制。欲了解更多信息，请联系我们。

您有问题或想了解更多信息吗？请联系我们：info@porsche-engineering.de