自动驾驶系统安全的软件架构设计（上）

01. 简介

本系列文主要关注电子系统，特别是汽车嵌入式系统及其在自动驾驶系统（ADS）标准方面的控制。

本项目的研究范围包括使用汽车开放系统架构“AUTOSAR”对软件架构进行建模，特别强调使用标准化的模式管理机制。该架构将在自动泊车系统中实例化，以验证系统的正确功能。

相关概念将在虚拟环境中进行验证。生成的AUTOSAR运行时环境（RTE）将与环境以及由CARLA模拟器实现的自动驾驶汽车集成。本系列文不涉及泊车运行的实现，这部分内容已在其他研究中进行了详细说明和开发。

02. 研究现状

本节概述了本系列文开发过程中使用的最重要的技术、方法和标准，旨在为读者提供背景信息，帮助理解项目的背景和研究成果。

研究现状涵盖以下几个方面：系统工程（2.1节）、软件架构（2.2节）、作为标准化软件架构的 AUTOSAR（2.3节）以及自动化系统安全标准（2.4节）。

系统工程对于本项目的开发至关重要。开发像自动驾驶汽车这样的复杂系统，需要采用结构化方法，将系统分解为较小的子系统，以有效管理其复杂性。

对于要在软件中实现的子系统，必须设计清晰且定义明确的架构。了解不同架构的适用性、定义方式、文档记录方法以及参考方式等至关重要，这有助于确定哪种架构最适合正在开发的系统。

最后，了解与项目开发相关的所有标准也很重要，以便按照这些标准进行建模。由于本研究的主要目标是确保架构的安全性，因此将重点关注AUTOSAR和自主系统的相关安全标准。

2.1. 系统工程

系统工程旨在研究和理解现实，以优化和改进复杂系统。它可以应用于任何类型的系统，因为它并不局限于特定领域。例如，它既可以用于研究人体消化系统，也可以用于研究计算机系统，尽管这两个领域毫无共同之处。

系统工程为整合相关学科和专业团队提供便利、指导和领导，形成一个结构合理的开发流程，从概念设计到生产、运营、演进，直至最终报废处理。

在系统设计过程中，需要明确描述所有必要信息，例如系统提供的功能、系统与其他系统的交互方式、实现系统所需的不同组件数量、组件之间的交互方式以及每个组件实现的功能部分等。这些信息有助于绘制系统的层次结构，不仅包括顶层结构，还能详细说明满足整体实施要求的具体细节。

基于良好的系统架构开发项目，可以提供坚实的基础。这意味着系统各组成部分之间的所有关系都得到了明确界定和相互连接。它使所有团队成员能够清楚、简单地了解需要完成的任务、完成任务的地点和方式。此外，团队成员使用相同的语言进行沟通，有助于改善沟通效果和项目管理，降低项目失败的风险。

系统工程允许将具有挑战性的大型系统分解为更小、更易于解决的子系统，并对这些子系统进行分类和优先级排序。其主要优势包括提高整个系统的性能、降低潜在的项目成本、提升系统平台的质量，以及使系统能够快速、轻松地进行升级和扩展。

系统工程过程是迭代的。首先，必须对项目进行架构定义。随着需求、通信和实施细节的不断完善，设计在组件层面会变得更加精确。总体而言，系统工程为成功的工程项目设计和实施提供了路线图。

本系列文在开发过程中运用系统工程方法，将系统分解为小型子系统。

2.2. 软件架构

软件架构对于面向未来的基于软件的系统开发至关重要。在本节中，我们将定义架构的概念，以便在设计和开发过程中能够以最佳、正确的方式进行描述。对于复杂系统，如自动驾驶系统，最有效的方法是首先对架构进行建模，然后确定要实现的组件的详细需求。

系统的软件架构不仅代表了系统本身的结构，还对其高级行为提供了逻辑解释。在这种情况下，系统由一组实现特定功能的组件组成，也可以是一组功能的集合。换句话说，软件架构是开发高效软件的必要工具，因为它提供了一个稳定的框架，软件可以在此基础上进行开发。

所描述系统的质量、性能、可维护性和整体成功与否，都直接受到架构决策的影响。现代复杂系统中已经开发并使用了不同的高级架构模式和原则，这些被称为架构风格。需要明确的是，构成系统的架构通常不限于单一的架构风格，而是由不同风格组合形成复杂系统。

软件架构直接展示了系统的外部结构，同时隐藏了系统的实现细节。此外，它还关注系统元素和组件之间的相互作用方式。

确定一个架构的正确性并没有简单、结构化的方法。架构本身必须有明确的目标，必须满足既定的目的和目标。

定义架构的工程过程有一些黄金准则：首先，该过程必须由一个人或一小群架构师进行管理；其次，架构师必须尊重架构的质量特征；第三，所有内容都应进行文档记录，并且要从多个角度进行记录；最后，从最初的概念到最新的扩展，都要对架构进行再次审查。

2.2.1. 什么是软件架构？

软件架构由系统的方框和线条组成，旨在解决其设计所针对的问题。方框代表系统的元素，线条表示这些元素之间的关系和信息交换。

软件架构更正式的定义是：“一个系统的软件架构是为了对系统进行推理所需的一组结构，它包括软件元素、元素之间的关系以及两者的属性”。换句话说，软件架构是一种系统抽象，其中架构定义了元素及其相互连接方式，但不涉及内部细节。

由于多种原因，架构是工程的重要组成部分。首先，它为利益相关者之间的沟通提供了一个途径。它还体现了系统最关键的设计决策，并且作为一种可转移和可复用的系统抽象。

在定义特定架构时，从一开始就应明确且清晰地定义所考虑的结构。这些结构可分为三类：

・模块化结构：系统被划分为称为模块的小单元。这是一种从静态角度看待系统的方式，因为它划分了开发团队的职责。

・组件结构和连接器：它们侧重于元素在执行过程中如何相互交互。

・映射结构：它们侧重于将软件结构映射到不包含任何软件的结构。

2.2.2. 参考软件架构

参考软件架构（RSA）是一种软件架构，其结构、元素和关系为特定领域或一系列软件系统的具体架构提供模板。RSA的主要目标是使应用软件能够独立于其执行环境进行指定和实现。

RSA一方面提供了功能列表及其接口（API），另一方面提供了与参考架构范围之外的每个功能的交互方式。

在汽车领域，AUTOSAR合作伙伴已经标准化了两种RSA：AUTOSAR经典平台和AUTOSAR自适应平台。

2.3. AUTOSAR

在汽车嵌入式系统中，应用软件与硬件有很强的交互作用。软件被嵌入到分布在车辆各处、资源有限的小型计算机中，这些计算机被称为电子控制单元（ECU）。车辆功能，尤其是在自动驾驶汽车中，正变得越来越复杂。此外，对于这种日益复杂的系统，必须满足实时性和安全性要求。

AUTOSAR是一种标准化的汽车开放系统架构。它是由汽车制造商、供应商、服务提供商以及汽车电子、半导体和软件行业的公司组成的全球开发合作伙伴关系。

AUTOSAR旨在通过提高OEM和供应商之间软件模块的重用性和可交换性，来改善高度集成的电子电气（E/E）架构的复杂性管理。它定义了交换格式和描述模板，以实现基本软件栈的配置过程以及应用软件到ECU的集成。AUTOSAR是全球公认的软件和方法标准，为未来的智能出行实现开放的E/E系统架构，支持高度的可靠性，尤其是功能安全和网络安全。

AUTOSAR已经实现了汽车嵌入式软件平台软件通用功能的标准化，其中包括通信栈、诊断服务或操作系统等。

值得一提的是，AUTOSAR 促进了标准定义方面的合作。其目标是定义通用的规范语言，以描述组件之间的接口和通信机制，确保软件在车辆中的顺利集成。同时，它并未规定软件的具体实现方式，为汽车制造商、ECU供应商和软件供应商之间的竞争留下了空间。

2.3.1. 平台软件

在平台软件规范方面，AUTOSAR目前已经标准化了两种参考软件架构：AUTOSAR经典平台（简称CP）和AUTOSAR自适应平台（简称AP）。

2003年，AUTOSAR开始制定经典平台规范，以支持基于深度嵌入式微控制器的ECU的开发。经典平台非常适合对实时性要求高（微秒级）和对安全性要求高的功能。基于嵌入式微控制器的ECU计算能力较低，大约能处理1000 DMIPs。

2016年，AUTOSAR开始制定自适应平台规范，以支持在基于微处理器的高性能计算平台上开发和集成应用软件。这些ECU提供高资源可用性和软实时执行（毫秒级），如图1所示。自适应平台的开发是为了支持联网和自动驾驶汽车的不断发展，包括满足日益增长的软件更新需求。

图1.AUTOSAR平台之间的差异

两种平台适用于不同的用例，因此AP并不会取代CP。这意味着两者将在汽车生态系统**存。由于两种平台针对不同问题提供解决方案，它们的共存为该标准带来了巨大的附加价值。

尽管AP更适合实现传感器数据融合和障碍物定位，但本文的重点是为自动驾驶汽车指定一种安全架构。为简单起见，考虑到自主系统（AS）模式管理器的安全要求（见2.4.4节），本架构将使用经典平台进行建模。

2.3.2. AUTOSAR经典平台

AUTOSAR经典平台架构是一种分层软件架构。如图2所示，它为基础软件（BSW）提供了三个抽象层：微控制器抽象层、ECU抽象层和服务层。运行时环境（RTE）对应用层和基础软件服务之间的通信进行抽象。

图2.AUTOSAR经典平台架构的主要层

经典平台各层和模块的最重要属性总结如下。应用软件层在大多数情况下与硬件无关，RTE代表应用程序的接口，用于与较低层级进行通信。

2.3.3. 虚拟功能总线

在AUTOSAR中，应用软件由软件组件（SWC）描述。SWC是AUTOSAR的构建块，可以组合起来设计完整系统的功能。不同SWC之间的通信通过端口进行。P端口提供对象，R端口需要对象。必须为这些端口分配接口，它们控制可传输的内容和使用的语义。

AUTOSAR定义了不同的通信类型。最常用的通信机制是发送-接收和客户端-服务器通信。在发送-接收通信中，一个SWC通过推送数据元素将数据发送到一个或多个SWC。在客户端-服务器通信中，一个SWC实现一个功能（服务器），其他SWC（客户端）可以调用该功能。

虚拟功能总线（VFB）管理SWC之间的连接和交互。VFB将应用程序与系统基础设施隔离开来。

VFB提供了足够的信息，允许在确定软件组件到ECU的分配之前对软件系统进行集成和测试，即在了解电气架构（ECU网络）之前，可以对系统的整个功能行为进行原型设计。

图3.VFB中SWC之间的通信

2.4. 自动化系统安全标准

本节描述了适用于自动化系统的不同安全标准。目前，为了确保自动驾驶系统的安全性，需要考虑并遵守多种标准。

对于本项目的开发，考虑了以下标准：

- V模型

- SAE自动驾驶等级

- ISO-26262

- ISO/TR-4804

- ASAM OpenODD概念文件

- ISO/PAS-21448

后续各节将简要描述每个标准涵盖的主题以及它们试图规范的内容。

2.4.1. V模型

V模型是德国委员会制定的一种系统开发项目规划和执行方法。强烈建议遵循V模型标准中规定的阶段，以实现项目的系统开发。图4提供了V模型的图形描述。

图4.系统工程流程的V模型

V模型很好地考虑了系统的整个生命周期，与系统工程理论相契合。该模型是系统开发生命周期的图形表示，用于生成准确的开发模型和项目管理模型。它也被称为验证和确认模型。

该模型将开发过程分为两部分：项目定义（左侧）和项目测试与集成（右侧）。每一侧都有多个阶段，每个阶段必须在进入下一个阶段之前完成。项目集成和实施过程在每个定义的阶段对项目定义进行评估和验证。

实施该模型的优点如下：（i）简单易用；（ii）规划和设计活动在早期进行，在项目开始时就能对项目有很好的理解，从而在实施过程中节省时间；（iii）避免缺陷的向下传递，便于定位错误。缺点是：（i）僵化且缺乏灵活性；（ii）由于在实施前不创建原型，对先前所有层级进行修改更新既耗时又昂贵。

V模型是本项目开发的基础，目的是以系统的方式开发最小自主系统的架构。

2.4.2. SAE自动驾驶等级

美国汽车工程师学会（SAE）将人类对车辆的完全控制权转移给机器的过程，划分为从0到5的逐步过程。0级表示无自动化，5级意味着自动驾驶系统在所有道路和环境条件下，都能全时执行所有驾驶任务。

多个自动驾驶等级在标准SAE J3016中进行了定义。该标准旨在对这一演进过程进行描述和概括，但并未提供严格的要求。

SAE对道路车辆自动驾驶的分类，旨在明确车辆运行过程中人类驾驶员（如有）的角色。第一个判别条件是环境监测主体。在无自动化到部分自动化（0-2级）的情况下，环境由人类驾驶员监测；而在更高程度的自动化（3-5级）中，车辆负责环境监测。图5展示了用于定义每个等级的其余分类因素。

另一个判别标准是动态驾驶任务（DDT）回退机制的责任归属。智能驾驶自动化系统（4-5级）承担自动化回退的责任，且受运行域的限制或不受限制；而在低等级自动化（0-3级）中，人类驾驶员承担全部责任。图5展示了用于定义每个等级的其余分类因素。

图5. SAE J3016驾驶自动化等级的识别

2.4.3. ISO-26262

ISO-26262《道路车辆-功能安全》是一项基于车辆电气和电子系统功能安全的标准。该标准的范围已从乘用车扩展到除轻便摩托车外的所有道路车辆。

ISO-26262:2011系列的第一版，是基于当时汽车行业最先进系统（如转向、制动和安全气囊系统等）的知识开发的，但它并未完全解决非常复杂的分布式系统问题，以及如何处理可用性要求。第二版解决了其中一些问题，但仍需要进一步解读。

功能安全旨在防止因输入、硬件或环境变化导致的任何事故或组件失效。然而，目前尚不清楚自动驾驶汽车在无法避免事故时应如何行动，以及应将哪些风险降至最低。

该标准中定义的功能安全范围仅适用于静态环境。该标准确保在事先了解可能的环境情况时的安全性。然而，这一假设在自动驾驶系统中完全不成立，因为自动驾驶系统的环境是动态的，这使得研究和定义所有可能应用功能安全的场景变得不可能。

这意味着ISO-26262无法保证自动驾驶系统的完全安全，因为它无法详细定义系统运行的所有环境场景。ISO PAS 8800《道路车辆-安全和人工智能》解决了这一问题。

2.4.4. ISO/TR-4804

ISO/TR-4804《道路车辆-自动驾驶系统的安全和网络安全-设计、验证和确认》描述了一个框架和建议，用于自动驾驶系统的开发、验证、确认、生产和运营，重点关注从全球适用的出版物中衍生出的安全和网络安全问题。汽车和交通运输行业的所有利益相关者都可以从中受益。它考虑了针对SAE J3016:2018中3级和4级自动驾驶系统的验证和确认方法。

本技术报告的目的是提供一种通用策略，以应对自动驾驶汽车带来的风险。虽然这种基本方法可作为安全自动驾驶的起点，但它并未描述完整的安全产品。

该标准旨在补充当前与安全相关的标准和出版物。该文件对实现积极的风险平衡、避免不合理风险和网络安全相关威胁的建议、指导和策略进行了更具技术性的概述，重点强调了设计安全的重要性。

它为自动驾驶系统的开发、验证、确认、生产和运营提供了一个框架和建议，汽车和交通运输行业的所有利益相关者都可以从中受益。

2.4.5. ASAM OpenODD概念文件

ASAM代表自动化和测量系统标准化组织，是1998年由德国汽车行业创立的非营利性标准化组织。ASAM在接口、协议、API、数据模型、数据交换格式以及E/E开发流程的其他重要方面，都具有很高的标准化水平。ASAM定义的标准仅为建议，对监管框架没有任何影响。目前，它在7个不同领域开展活动。

本项目相关的标准是OpenODD标准，它在ASAM仿真领域中定义。该标准尚未完成，目前是一个概念，将用于开发未来的标准。其主要目标是提供一种格式，用于表达为联网自动驾驶汽车（CAV）定义的运行设计域（ODD），以进行仿真测试。

ODD必须在车辆的整个生命周期内有效，因为它是车辆安全和运行概念的一部分。为系统选择的ODD将对该功能的设计产生重大影响，包括其功能能力和相应的验证。ODD主要用于指定联网自动驾驶汽车的功能，特别是CAV必须能够运行的环境。所有交通参与者、天气条件、基础设施、位置、时间以及其他对自动驾驶有影响的因素，都属于该环境的一部分。

ASAM OpenODD概念项目的开发，是为了管理为自动驾驶系统指定的所有ODD。该概念项目的主要目标之一，是定义一种机器可读的格式，用于定义ODD规范。这种抽象格式将使利益相关者能够共享、比较和重用系统的ODD规范。

ODD的正式定义见标准SAE J3016 (2018)，其中指出：“给定的驾驶自动化系统或其功能被专门设计为在特定的运行条件下运行，包括但不限于环境、地理和时间限制，以及某些交通或道路特征的必要存在或不存在”。图6展示了ASAM标准中定义的ODD分类法。

图6.根据BSI PAS 1883的ODD分类

图7显示了如何根据车辆所在的场景开发系统运行设计域。

图7.ODD分类的示例定义

ASAM的策略是填补现有空白，而不是重复其他标准组织的工作，或制定与现有标准相矛盾的新标准。在这种情况下，ASAM OpenODD标准化旨在补充BSI（BSI PAS 1883，提供ODD分类法）和ISO（ISO 34503，使用该分类法提供ODD的高级定义格式）的活动。

2.4.6. ISO/PAS-21448

标准ISO/PAS 21448《预期功能安全》（简称“SOTIF”），是专门为应对汽车行业自主软件开发人员面临的新安全挑战而制定的。该标准与人工智能（IA）和机器学习（ML）在自动驾驶汽车开发中的作用同样重要。

ISO/PAS 21448至关重要，因为它与所谓的功能安全（ISO 26262）采用了完全不同的方法。最初，SOTIF标准旨在作为ISO 26262的一个额外部分，但在意识到在无故障情况下保证安全性的挑战后，决定创建一个单独的标准。

由于以下因素，SOTIF对于当今为自动化和人工智能开发的大型系统至关重要。第一个因素是，由于可能的场景数量众多，对自动化系统进行正确验证极其困难。第二个因素是，自动化系统拥有大量数据，并用于复杂算法，这给使用AI和ML的系统开发带来了重大挑战。第三个也是最后一个因素是，它还有助于避免系统在做出某些决策时可能出现的风险。

本项目中的一个例子有助于理解SOTIF的含义：道路结冰时，系统无法识别这种情况。因此，车辆的响应将不适合这种情况，影响系统的运行安全，因为即使系统没有任何故障，车辆也可能行驶得比应有的速度更快。

换句话说，SOTIF的主要目标是减少可能出现的未知和不安全状况，就像上述例子一样。然而，要证明已经考虑了所有可能的场景是很困难的。

安全一直是汽车行业的重要话题。如今，随着自动驾驶汽车的引入，它正成为软件开发中的一个重要且关键的问题。与任何与安全相关的领域一样，确保功能安全仍然是一项具有挑战性的任务。SOTIF提供了一个指导方针，指出了执行设计、验证和确认的不同步骤。借助各种定义的措施，可以在非故障情况下实现系统安全。

03. 开发

本项目旨在为一个最简自动驾驶系统构建架构模型。第2.4节中探讨的安全标准构成了该模型的基础。此架构的关键在于自动驾驶系统（ADS）模式管理器的设计与实现，它负责在任何情况下保障系统安全。

最简自动驾驶系统的架构已应用于自动泊车系统（APS）的案例研究中，该自动泊车系统在其他研究中有定义和编程。APS与本项目同步开发，以便能与本系列文的架构设计顺利整合。

案例研究涉及的组件包括自动驾驶汽车、专用移动应用程序和外部云服务（ECS）。外部云服务组件不在本项目范围内，但它对于系统正常运行是必需的（用于提供空闲停车位信息）。自动驾驶汽车和专用移动应用程序是APS设计中的系统组成部分，如图8所示。

图8.ADS模式管理器与APS的关系

该架构具有通用性，支持自动驾驶汽车功能的渐进式开发。通过调整系统需求，并在运行设计域（ODD，见2.4.5节）和模式声明组中进行适当修改，可添加更多自动驾驶功能。

鉴于汽车系统本身的复杂性，若不采用第2.1节所述的系统工程方法，开发此最简自动驾驶系统几乎不可能。此外，自动驾驶功能与环境的交互进一步增加了系统的复杂性，因为它取代了驾驶员行为（这是另一个复杂且与安全相关的系统）。因此，不仅要应用系统工程方法，还要遵循第2.4.1节中V模型的设计阶段，这一点至关重要。ISO/TR-4804（2.4.4节）的要求和APS的系统需求是详细设计的基础。

ISO/TR-4804 提出的逻辑架构已使用AUTOSAR进行建模，AUTOSAR是汽车领域成熟的参考软件架构（见2.2和2.3节）。

虚拟功能总线（VFB）为软件架构描述提供了必要的抽象。本系列文不涉及技术架构的实现。不过，整个系统已配置为在虚拟车辆中运行，以便轻松集成到模拟器（如CARLA）中。

VFB的实现依赖于AUTOSAR运行时环境（RTE），它管理系统中软件组件（SWC）之间的所有通信，包括模式管理。AUTOSAR经典平台提供了标准化的方式来描述模式声明组、对车辆模式进行建模和管理，以及实现模式切换，这些特性对于ADS模式管理器的建模非常理想。

ADS模式管理器是保障安全的关键组件。为确保车辆的完全安全，该组件需分析所处环境，并根据分析结果从一种模式切换到另一种最适宜的模式。

在模拟环境中定义和实现APS不在本系列文的范围内。

3.1. ADS模式管理器的系统需求

自动泊车系统（APS）应能够自动、安全地完成车辆的泊车和出库运行。ADS模式管理器负责在所有可能的情况下保障APS的安全，它必须满足表1中定义的所有系统需求。这些需求均源自ISO/TR-4804的建议，以确保安全性，并根据APS的功能进行了调整。

表1.适用于APS ADS模式管理器的系统需求

为简化系统设计并满足安全需求，我们设定了表2中的假设条件。

表2.应用于APS ADS模式管理器的约束

3.2. 安全逻辑架构

自动驾驶系统的软件架构是根据上述表1中定义的系统需求推导而来的。与系统需求类似，该架构基于ISO/TR-4804提供的信息，以确保自动化系统的安全性。

ISO/TR-4804中定义了一种经典的自动驾驶系统软件架构——“感知-规划-行动”，图9对其进行了高度概括。首先，雷达、激光雷达、摄像头等传感器进行感知，系统利用这些信息解读周围环境，并预测障碍物的未来位置。其次，在处理完接收到的所有信息后，系统必须规划行驶策略。最后，系统通过动力系统、转向系统和制动系统来移动车辆。

图9.经典软件架构“感知-计划-行动”

上述经典架构在当前正在开发的自动驾驶系统面前已经过时，它仅在高度受控的环境中有用。如果环境不断变化，则需要比上述结构更复杂的架构。自动驾驶系统的环境是动态的，很难预见自动驾驶汽车可能运行的所有情况，因此ISO 26262并不适用。

系统应检查和监控周围环境是否按预期运行，关注系统状态，并管理整个系统以确保其处于安全模式。

在定义的任何环境（ODD）中，系统都必须安全运行。因此，系统比以往更加复杂，但同时也更安全可靠。在设计这类系统并探索新架构时，参考一些组织定义的建议和标准非常重要。

ISO/TR-4804提出了一种自动驾驶汽车的通用架构，如图10所示。最简自动驾驶系统的安全架构将基于此方法构建。

图10.预期功能的基于安全的架构示例

用于自动泊车的最简自动驾驶系统与“感知-规划-行动”范式以及标准化中定义的能力保持一致。然而，我们仅考虑图11中所示的一组组件：感知、定位、行驶规划、车辆运动、ODD处理和ADS模式管理器。

图11.最小自动驾驶系统的基于安全的架构

为简化架构（因为这是一个最简自主系统），一些重要组件，如预测、监测等未被考虑。上层组件（ODD处理和ADS模式管理器）确保了在动态环境中的安全性。

具体而言，本系列文重点根据AUTOSAR标准对架构组件进行建模，并定义图11中展示的不同组件，同时阐述组件之间的交互。以下各节将描述每个组件，包括交换的数据和集成的可运行程序。

3.3. 详细设计

本节将对设计的安全架构中的每个组件进行定义，并讨论每个组件对APS的作用。为满足安全要求，此详细设计源自ISO/TR-4804以及相关研究。

3.3.1. 感知

感知组件负责获取车辆不同传感器接收的数据，并识别所有相关的外部信息，以创建一个环境对象。车载传感器的各种输入和可选的车联网（V2X）信息在此汇聚，生成实际的感知信息。

感知组件中的传感器包括激光雷达、摄像头、用于定位的全球导航卫星系统（GNSS）、雷达和惯性测量单元（IMU）传感器。为满足最简安全自动驾驶系统的需求，需要综合使用这些传感器，因为单一传感器无法同时提供可靠精确的检测、分类、测量，且在恶劣条件下的稳定性不足。感知组件还包括用于与基础设施连接的车与基础设施通信（V2I）设施。

3.3.2. 定位

定位组件负责识别车辆所处的环境。自动驾驶汽车仅依靠感知组件提供的信息，准确、恰当定位自身及周围环境至关重要。车辆上的每个传感器提供信息后，定位组件负责分析和融合这些数据，并据此对车辆环境进行建模。

定位组件必须为行驶规划组件提供规划车辆任何运动前，需要考虑的周围物体的必要信息。

3.3.3. 行驶规划

行驶规划组件确定为完成后续驾驶步骤且避免碰撞所需执行的操作。该组件必须处理位置信息、遵守交通规则、考虑自身运动，并根据模式管理器提供的切换指令调整功能。

自动驾驶系统遵守交通规则，因此行驶规划组件生成合法的驾驶计划。只有在避免碰撞时，操作才可以优先于交通规则以防止事故发生。

对于要开发的APS系统，其运动模型分为两个部分：自动驾驶和泊车运行。自动驾驶模式负责将车辆行驶至停车位，泊车运行模式则负责以适当的运行将车辆停入停车位。为简化实现过程，自动驾驶功能将包含在每个定义的泊车功能中。

泊车和出库运行各有两个不同功能：（i）PM_Forwards（向前泊车），（ii）PM_ForwardBackwards（前进-后退泊车），（iii）UM_Backwards（向后出库），（iv）UM_BackwardForwards（后退-前进出库）。这些可运行程序的参数包括：车位定位（x,y,z）、泊车侧（右侧或左侧）、泊车类型（平行泊车或斜角泊车）以及泊车角度（仅适用于斜角泊车）。图12展示了定义的泊车类型。

图12.定义的停车类型（平行和角度类型）

PM_Forwards和UM_Backwards函数分别用于斜角车位的泊车和出库，而PM_ForwardBackwards和UM_BackwardForwards用于平行车位。

若最简自主系统运行过程中发生意外情况，车辆必须进入安全模式，并启动必要功能以确保车辆安全。为此定义的安全模式功能称为M_Safe。

上述定义的功能在模拟环境中的具体定义和实现不在本系列文范围内。

3.3.4. AS运动

自动系统运动组件涉及车辆围绕三个轴（即纵向、横向和垂直轴，以及滚动、偏航和俯仰运动）的平移和旋转。为在车辆中实现期望的运动，必须根据行驶规划组件的指令生成执行器命令。

车辆运动控制器必须稳定，能够平衡车辆在运行过程中可能出现的动态变化。生成的命令控制转向、制动和动力系统，使车辆按计划移动。与行驶规划的实现一样，此组件不在本系列文范围内。

3.3.5. ODD处理

ODD处理组件通过分析感知组件提供的不同信息，确定系统所处的环境（ODD）。本项目的运行设计域是根据标准PAS 1883:2020定义的。该标准提供了ADS可能需要的ODD的所有可能属性，并给出了分类法的不同示例。

首先，APS的用例和定义的不同约束条件对ODD进行了筛选，结果如表3所示。“能力”列显示了哪些环境与自动泊车系统相关或对其有影响。

Yes：要将其集成到模拟中，需要创建一个超出范围的新地图

表3.支持APS定义的ODD，并基于PAS 1883:2020

其次，由于选择的模拟环境无法模拟标准中定义的所有环境，因此再次进行筛选。鉴于本项目为教学项目，仅选择了部分ODD以简化项目实现。表4展示了在AUTOSAR工具中为APS建模所支持的ODD，每个选定的ODD都与APS系统相关。

表4.为在CARLA模拟器中实施APS而选择的ODD

然后，将ODD映射到3.3.6.3节中指定的模式。但首先，需要解释CARLA模拟器如何识别指定的环境，即CARLA模拟器使用哪些API来确定车辆是否处于指定的ODD中，这对于定义从模拟器提取环境数据的接口至关重要。

CARLA模拟器允许定义世界（即客户端创建并出现在模拟中的对象，称为CARLA.World）。世界包含我们可见的活动地图（即世界资产，而非导航地图），地图还管理天气和场景中的参与者。每个模拟只能有一个世界，但它始终可能发生变化。在模拟运行时，有多种函数可用于了解定义的环境，这些函数将用于识别环境。

在场景中调用以下函数来识别环境：（i）Get_environment_objects (self, object_type=Any)，（ii）Get_weather (self) 和（iii）get_turned_on_lights (self, light_group)。

云量、降雨、风速和太阳位置等是模拟中当前活动的天气参数，由Get_weather (self)函数提供。天气信息总共包含14个浮点参数，每个变量代表一种天气状况，且设定了相应的值。在本项目中，这些变量被视为二进制变量，即如果其值大于0.5，则表示该天气状况正在发生，因为本项目只关注天气状况是否存在，而非其具体参考值。

Get_environment_objects (self, object_type=Any)函数返回一个包含请求语义标签的环境对象列表。默认情况下，该方法返回环境中的任何对象，但对象类型参数可用于按语义标签进行筛选。如果定义了筛选条件，响应将是一个数组，包含在现实世界中找到的所有筛选元素，数组由包含对象ID、名称（模拟器定义的语义标签）和位置的变量组成。每个需要此函数的ODD都将指定其语义标签并进行筛选，以确定该对象是否出现在现实世界中。

get_turned_on_lights (self, light_group)方法返回场景中按组筛选的已打开灯光列表。该函数的返回值是一个数组，包含每个识别到的灯光的信息：灯光标识符、表示灯光是否打开的布尔值以及所属的灯光组。每个需要此函数的ODD都将指定其灯光组并进行筛选，以确定该灯光是否出现在现实世界中。

此外，需要使用IMU雷达来确定车辆的倾斜度，在这种情况下，仅使用指南针变量，它表示汽车相对于北方的倾斜度。

表5列出了CARLA模拟器中用于计算车辆ODD的特定变量和函数。

表5.CARLA的功能是定义特定的ODD

3.3.6. ADS模式管理器

ADS模式管理器在系统安全方面起着关键作用，是本系列文的核心内容。该组件负责在手动驾驶模式和自动驾驶模式之间安全切换。

模式管理器在切换到另一种模式之前，必须确认所有条件和前提（如ODD）都已满足且正确（例如，车辆是否在正确的道路上、天气条件是否允许模式转换等）。

3.3.6.1. 模式管理组

根据APS的定义，设计了多种模式组，以应对自动泊车系统可能出现的所有情况。

APS开启后，模式管理器在定义的模式之间切换。需要考虑的三组模式如下：（i）车辆模式，（ii）APS 模式，（iii）停车位置模式。每个指定的模式在其模式组内都有一个可识别的值。

第一组模式“车辆模式”列出了车辆可能的四种驾驶模式，如表6所示。

表6.车辆模式的定义

第二组模式“APS模式”定义了自动泊车系统在车辆运行过程中可管理的五种不同模式，如表7所示。

表7.自动停车系统模式的定义

当系统识别到可能威胁车辆安全的情况时（例如，有固体物体在潜在碰撞路径上或发生碰撞时），为避免更严重的后果，模式管理器将负责将车辆切换到安全模式。

ADS模式管理器计算APS模式和车辆模式，而ECS提供第三组模式“停车位置模式”，该模式组给出选定的停车位类型，如表8所示。

表8.停车位模式的定义

需要注意的是，停车场内的停车位只有一种停车方式（无论是室内还是室外），即斜角停车。停车场是专门用于停车的封闭区域，有多个停车位，街边的单个停车位不在此定义范围内CARLA模拟器中的停车选项如图13所示。

图13.CARLA的停车位类型：停车场和街道停车场

另外，在停车场中，只要传感器可用，就可以正常使用，不受天气影响；而在街边停车场，根据外部环境的不同，传感器可能可用但无法使用。这就是设置不同APS模式的原因。

例如，在雪天，街边停车位的线检测系统可能无法检测到白色的停车线，但在停车场中却可以，因为停车场有相应设施来适应各种情况。

3.3.6.2. 基于功能操作的模式切换

明确根据APS可管理的每种模式，调用行驶规划组件中定义的哪个可运行程序，对于确保系统安全至关重要。此外，还应考虑选择的停车位类型。

图9展示了泊车运行的映射关系。此信息必须在行驶规划组件的内部行为中进行建模，以便根据架构设计执行正确的可运行程序。这也简化了APS的实现过程，因为只需要对上述五个泊车和出库功能进行编程，其余部分将由架构自行决定。

表9展示了用于定义行驶规划中操作功能的模式切换。

表9.模式开关，用于定义驾驶计划的操纵功能

表10展示了出库运行的映射关系。

表10.模式开关，用于定义驾驶计划的操纵功能

这样，系统具有更高的可扩展性。如果需要添加新模式或新的停车位置，系统只需指明每种给定模式和位置应激活的功能，无需编写新代码。

3.3.6.3. 基于环境的模式切换

系统应明确在ODD处理中选择的哪些环境，对于上述定义的每个自动泊车系统模式是可接受的。如果环境不允许，模式管理器不应激活新模式，这确保了系统在任何环境中的安全性，也是架构的主要目的。

表11将3.3.5节中选择的ODD映射到车辆模式组。在以下表格中，“x”表示该模式与相关环境兼容。在这种情况下，车辆几乎可以在所有环境中自动驾驶，但泊车和出库模式在坡度和黑暗区域受到的限制稍多。

表11.ODD映射与车辆模式组

聚焦于泊车和出库模式，表12将ODD映射到APS模式组。逻辑上，APS_OFF模式支持所有环境，因为此时系统处于禁用状态。如前所述，室内停车位的优势是可适应所有天气情况，而室外停车位在恶劣天气下的限制更多，如表12所示。

表12.与APS模式组的ODD映射

周围环境（如建筑物、汽车、行人、交通标志和信号灯等）的影响，是区分APS_OUTDOOR和APS_LANDROAD的关键。特别是，APS_LANDROAD不考虑这些周围物体。因此，如果环境中存在这些物体，则意味着车辆不在陆路上，此时合适的模式应为APS_OUTDOOR。

3.3.6.4. ADS模式管理器的实现

用于自动泊车系统功能的ADS模式管理器，被实现为图14所示的状态机。

图14.ADS模式管理器状态机

评估状态机状态转换所需的变量如下：（i）APS_activation（APS激活状态），（ii）Parking/Unparking（泊车/出库状态），（iii）Context_Data（环境数据），（iv）Parking_Location_Mode（停车位置模式）和（v）APS_Done（APS操作完成状态）。除了Context_Data和Parking_Location_Mode，所有变量均为布尔类型，定义见表13。

表13.布尔变量的定义

3.3.5小节中描述的ODD处理提供的信息包含在Context_Data变量中。Parking_Location_Mode变量是一个整数，0到4中的每个数字代表不同的模式，如前所述。

OFF状态根据ECS提供的停车位置模式选择APS模式，如表14所示。

表14.基于停车位置模式的APS模式选择

泊车和出库状态非常相似。在这两个状态下，都要检查环境数据，以验证其是否适合当前激活的APS模式。如果环境合适，内部变量ContextRight将被启用，否则将被禁用。将CARLA模拟器提供的环境数据与上一循环的数据进行比较，以识别环境变化。一旦检测到变化，就应更新ContextRight变量。

这两个状态的区别在于选择的车辆模式。在泊车状态下，VEH_Parking模式开启；在出库状态下，VEH_Unparking模式开启。最后，紧急状态激活APS_SafeMode，以确保紧急情况下的安全。

因此，ADS模式管理器能够为行驶规划组件提供每个模式组中当前激活的模式。当定位组件检测到有障碍物威胁系统安全时，将激活紧急状态（Em）。

看看学习学习膜拜一下