面向完全自动驾驶汽车的标准驱动式软件架构

自动驾驶已不再是实验室中的实验项目。随着车企竞相提升车辆自动化水平，汽车逐渐成为高度复杂的系统。驾驶任务的自动化，通常被认为是在基础车辆平台上增加一层认知智能模块。传统机械组件逐渐成为标准化配件，规划算法开始承担关键决策任务，软件也因此成为核心的创新驱动力。最新发展趋势表明，通过减少人为干预和人为失误，交通的安全性与通行效率有望得到提升。汽车工程师学会（SAE）将驾驶控制权从人类向机器的完全转移，划分为0至5级的渐进式过程：0级代表无自动化功能，5级则意味着自动驾驶系统能在所有道路和环境条件下，全程完成所有驾驶相关操作。随着软件规模的不断扩大，亟需采用先进的软件工程方法和工具，来应对其在复杂度、规模和关键性方面的挑战。软件系统的非线性特性使其难以被透彻理解—— 一个比特的错误可能导致整个系统瘫痪，而更严重的错误却可能无任何影响。此外，许多错误源于设计缺陷或需求的（错误）定义。

传统车辆本身已运行着大量软件，这些软件在实时处理、故障率、可维护性和安全性方面均面临严格约束。为避免设计缺陷，或防止最终产品中需求的呈现出现失衡，车辆向自动驾驶演进过程中的软件迭代必须得到妥善管理。由于为车辆添加认知智能模块，需要在现有平台上部署新的软件组件，因此功能目标与软件组件之间需建立清晰的映射关系。

软件架构的引入，是为了在开发阶段前管理软件系统的复杂度，并助力评估系统的功能和非功能属性。优良的架构有助于确保系统在功能适宜性、性能、可靠性和互操作性等方面满足关键需求。

本文的研究目标是设计一种面向完全自动驾驶汽车的功能型软件架构。现有文献多采用描述性方法，介绍自动驾驶的过往实验或特定有限场景的实现方案，其架构设计因此成为自动驾驶车辆研发或迭代后的结果，而非规范软件开发生命周期的产物。这种方法的主要问题在于，需求无法与功能组件形成可追溯关联，且多项功能常集中于少数组件中。因此，若缺乏内部技术细节，相关方案往往难以被直接借鉴采用。

本文采用由标准需求驱动的规定性设计方法，以SAE J3016标准中的需求为基础。该标准定义了驾驶自动化的多个等级，并为每个等级制定了功能定义，其目标是为驾驶自动化功能及从无自动化到完全自动驾驶的演进底层原则，提供一套完整的分类体系。在撰写本文时，这是唯一被推荐用于研发自动驾驶汽车的行业标准。本文以权衡分析的形式，对设计决策进行了全面探讨，最终形成一套易于理解和借鉴的核心知识体系。本研究方案是我们前期研究工作的延伸。

本文中所使用的“功能架构”概念，与ISO 26262汽车标准中描述的“功能概念”含义一致，即对实现预期行为所需的拟实现功能及必要交互的规范说明。此外，它与软件架构描述中的“功能视图”等价，能让架构师对功能进行聚类，分配给相应的研发团队，并围绕这些功能展开设计思考。功能架构设计对应于V模型的第二个阶段，而V模型是遵循ISO 26262汽车标准所要求的软件开发生命周期模型。

我们遵循Wieringa所描述的设计周期方法论，该周期是工程周期的一个子集，先于解决方案的实现和实现效果评估阶段，主要包括针对既定需求设计解决方案并进行验证的过程。

本文的结构安排如下：第二部分介绍相关背景知识；第三部分从SAE J3016标准中推导设计需求；第四部分阐述推导出解决方案领域的推理过程；第五部分介绍功能组件，第六部分阐述组件交互模式，第七部分进行总体权衡分析；第八部分展开讨论；第九部分为结论与未来研究方向。

汽车系统的研发工作由整车制造商（OEM）和各类零部件供应商分工完成，形成了分布式的软件开发生命周期，其中整车制造商承担技术集成商的角色。这种研发模式使整车制造商能够将研发、标准化和认证的责任委托给零部件供应商。目前，车辆内部组件的分布和部署也遵循这一分布式模式，即车辆中不存在中央控制单元。

与之相对，车辆中部署了名为电子控制单元（ECU）的嵌入式系统，以实现对转向、制动等功能的数字化控制。许多功能的实现，需要多个电子控制单元之间进行交互和通信。例如，巡航控制系统需要根据道路上其他交通参与者的情况，同时向制动系统和转向系统发送指令。为提高组件在不同系统、不同制造商和供应商之间的复用性，行业内研发了一系列标准化的通信总线（如CAN、FlexRay）和软件技术平台（如AUTOSAR），以简化分布式组件之间的通信和部署。本文的研究重点是设计部署在电子控制单元上、需通过一条或多条通信总线交换信息的功能型软件组件。标准化接口（如AUTOSAR中定义的接口）有助于简化软件组件的研发和通信，但对组件的核心功能影响较小。

如第一部分所述，SAE J3016标准定义了多个自动化等级，描绘了从无自动化到完全自动驾驶汽车的渐进式演进路径。该标准的目的是对这一演进过程进行描述性、全面性的阐释，而非制定严格的实现需求。但在撰写本文时，它仍是指导这一演进过程最全面、应用最广泛的文献。基于其广泛的认可度，我们将其作为本研究方法的基准：车辆至少需满足该标准中描述的功能，才能达到相应的自动化等级。为理解车辆自动化的实现过程，我们首先介绍SAE J3016中定义的核心术语：

动态驾驶任务（DDT）：指操作车辆所需的实时操作和战术功能，不包括行程规划、路线规划等战略功能。动态驾驶任务类似于在预设路线上驾驶汽车，包括执行器控制（如转向、制动）和战术规划（如生成并跟踪行驶轨迹、保持车辆在车道内行驶、与其他车辆保持安全距离等）。

自动驾驶系统：指能够持续完成部分或全部动态驾驶任务的硬件和软件系统的总称。自动驾驶系统通常由特定设计的功能模块（即功能特性）组成，如自动泊车、车道保持辅助等。前文已阐述了硬件与软件之间的相互作用，本文主要关注软件组件之间的相互作用，以设计能够实现完全自动驾驶的自动驾驶系统。

设计运行域（ODD）：指特定自动驾驶系统或功能特性被设计用于运行的具体条件。在设计阶段，定义运行域是一项重要工作，因为需求会随运行域的变化而调整。例如，设计用于在城市特定区域晴天环境下行驶的车辆，与设计用于在山区道路冬季环境下行驶的车辆，其需求存在显著差异。后续将探讨，完全自动驾驶要求车辆在所有天气和交通条件下，无需人工干预即可正常行驶。

动态驾驶任务降级处理：指在与动态驾驶任务执行相关的系统发生故障，或车辆驶离指定设计运行域后，用户或自动驾驶系统为继续执行动态驾驶任务，或使车辆进入安全状态所采取的应对措施。

具备动态驾驶任务降级处理能力的用户：指驾驶配备已激活自动驾驶功能车辆的用户，该用户能够操作车辆，且能响应自动驾驶系统发出的干预请求，在系统故障或自动驾驶车辆发出请求时，完成部分或全部动态驾驶任务。

动态驾驶任务功能特性：指在特定驾驶自动化等级、特定设计运行域下的特定设计功能。功能特性可被视为在预设场景中完成某项驾驶自动化任务的特定硬件或软件组件，例如晴天环境下的车道辅助功能，即可视为一种动态驾驶任务功能特性。

除硬件约束外，车辆的完全自动化还需通过研发自动驾驶系统，在所有设计运行域中实现动态驾驶任务的自动化。从递归角度看，自动驾驶系统由特定设计的功能特性组成。因此，车辆的完全自动化可理解为：研发、部署并协调足够多的动态驾驶任务功能特性，以满足人类驾驶员能够安全驾驶的所有场景条件（设计运行域）。

图1展示的SAE道路车辆驾驶自动化分类体系，旨在明确车辆运行过程中人类驾驶员（若有）所承担的角色。第一个判定条件是环境监测主体：在0至2级（无自动化至部分自动化），环境监测由人类驾驶员完成；而在更高自动化等级（3至5级），车辆将承担环境监测的责任。

图1：SAE J3016驾驶自动化等级

第二个判定条件是动态驾驶任务降级处理机制的责任主体：智能自动驾驶系统（4至5级）内置自动化降级处理的责任机制，其运行范围可能受设计运行域约束，也可能无约束；而在低自动化等级（0至3级），动态驾驶任务降级处理的责任完全由人类驾驶员承担。

根据SAE的定义：

1. 若自动驾驶系统仅完成车辆的纵向和/或横向控制，而动态驾驶任务的其余部分仍需驾驶员完成，则对应1级和2级自动化；

2. 若自动驾驶系统能完成全部动态驾驶任务，但在系统发生故障时，需具备动态驾驶任务降级处理能力的用户接管车辆，则对应3级自动化；

3. 若自动驾驶系统能在指定设计运行域内，或在人类驾驶员可应对的所有驾驶场景中（无设计运行域限制），完成全部动态驾驶任务并实现降级处理，则对应4级和5级自动化。

功能架构设计的首要步骤，是梳理功能组件列表及其依赖关系。为此，SAE J3016标准将组件划分为三类：

1. 操作类：基础车辆控制功能；

2. 战术类：避障、快速路线跟踪的规划与执行功能；

3. 战略类：目的地规划和整体路线规划功能。

在从底层控制到高层统筹的分层控制架构中，每类组件都承担着渐进式的作用：操作类组件实现底层控制，战略类组件负责高层统筹，战术类组件则介于两者之间，处理轨迹规划和交通事件响应。这种随车辆自动化等级提升形成的层级化视角，是架构设计中的重要决策依据。

此外，SAE对动态驾驶任务的定义中，明确了实现完全自动驾驶（5级）所需自动化的各类功能：

1. 通过转向实现车辆横向运动控制（操作类）；

2. 通过加减速实现车辆纵向运动控制（操作类）；

3. 通过目标和事件检测、识别、分类及响应准备，实现驾驶环境监测（操作类+战术类）；

4. 目标和事件响应的执行（操作类+战术类）；

5. 机动动作规划（战术类）；

6. 通过灯光、信号和手势等方式提升车辆可见性（战术类）。

此外，5级自动驾驶车辆必须实现动态驾驶任务的降级处理，并具备动态驾驶任务定义中未提及的战略功能，即根据人类用户或运营中心提供的信息，完成两点之间的目的地规划。

图2展示了上述组件分类的层级化概览，从左至右，从操作类到战略类功能，系统的复杂度逐渐提升。

尽管SAE J3016标准中定义的组件列表及其预期行为并非详尽无遗，但仍可作为一套良好的初始需求。各整车制造商可自主选择任一预期功能的实现方式，例如，目标检测、识别和分类功能可采用不同的算法或软件系统实现。这一选择会影响最终的功能组件设置——某一整车制造商可能选择使用多个传感器和高性能的传感器融合算法，而另一制造商可能开发单个组件来处理所有相关任务。本文致力于将每项功能拆解为原子化组件，即便这些原子化组件后续被整合为更高层级的组件，也不会影响本研究方案的有效性。第七部分将深入分析此类权衡问题，而这些问题往往由分布式的软件开发生命周期所驱动。

我们在此简要说明，任何任务的自动化都是一个控制循环过程：从传感器获取输入信息，进行逻辑推理，再对环境采取行动（可能通过执行器实现）。复杂任务的自动化，需要对传感器数据进行更深入的语义理解，以生成更高层级的决策或规划，但控制循环的核心逻辑保持不变。这一规律同样适用于图2所示的 SAE 功能组件分类体系，每类组件均可实现为一个控制循环，从传感器获取输入并做出相应动作。从左至右，从操作类到战略类功能，做出决策所需的语义知识水平逐渐提升。此外，越靠近右侧的组件，不再直接控制执行器，而是向其他组件发送指令。例如，战术类组件会向操作类组件发送指令；同理，战略类功能无法直接作用于执行器，而是与战术类功能通信，再由战术类功能向操作类功能下达指令。

图2：基于SAE J3016的功能组件分类

因此，我们可将每类组件视为一个大的控制循环（如图2所示），而每类组件中的单个组件则为更小的控制循环——因为每个组件仅需特定的语义信息，而非该类别下的全部可用信息。后续章节将利用这一特性展开设计。

自动驾驶汽车的软件架构设计，与实时智能控制系统（即机器人）的设计具有相似性。尽管机器人技术和人工智能领域已有大量关于软件架构的研究文献，但这些研究成果似乎并未得到汽车软件工程师的重视。因此，许多自动驾驶汽车的参考架构，都忽略了机器人领域已探索的技术发展和权衡策略——这一点将在第九部分详细探讨。本文旨在填补这一空白，通过探讨机器人领域的核心技术进展，为汽车领域筛选出最优的设计方案。

长期以来，人工智能领域的主流观点认为，自主机器人的控制系统应包含三个功能模块：传感系统、规划系统和执行系统。这一观点催生了被广泛应用的“感知-规划-执行（SPA）” 范式。在规划阶段，系统通常会维护一个内部状态模型，以确定自身在环境中的位置并规划后续动作。由于该模型需要实时、准确地反映机器人所处的环境，因此需要大量的环境信息。随着运行环境复杂度的提升，内部状态模型的复杂度也会相应增加，进而延长后续动作的规划时间。因此，在快速变化的环境中，新的规划方案可能在部署前就已失效。此外，规划方案执行过程中出现的意外结果，可能导致后续规划步骤在不适宜的场景中执行，进而引发更多意外。

这一缺陷自然引发了一个问题：“内部状态建模的重要性究竟如何？”为解答这一问题，学术界提出了多种旨在实现类似目标的定义。Maes首次区分了行为式系统和知识式系统——其中知识式系统会维护环境的内部状态模型，而行为式系统则不会。类似地，现有文献也对慎思式系统和反应式系统进行了区分：慎思式系统基于环境的内部状态模型进行逻辑推理，而反应式系统则通过对环境变化做出反射性响应来实现目标。反应式或行为式系统能更快地对环境变化做出响应，但对环境的推理分析能力较弱。

我们发现，上述两种定义均围绕同一个核心问题展开，即“系统如何规划其决策？”——是通过对从传感器提取的复杂语义信息进行推理，还是通过对简单输入做出简单响应？这一决策本质上是在计算速度与系统对环境的理解程度之间进行初始权衡。

从这一视角审视自动驾驶汽车的研发，可发现车辆同时需要反应式和慎思式组件。保持预设行驶轨迹、与周围目标保持安全距离，是反应式系统的典型应用场景，这类系统需要高频率运行，且能快速响应环境变化，此时维护复杂的周边环境模型并无实际意义。

而超车决策机制则是慎思式系统的典型例子，在这种场景下，维护复杂的世界模型有助于系统做出更合理的决策。

例如，若车辆在超车后不久需要右转，那么超车是否有必要？要解答这一问题，需要一个整合了整体行驶目标、未来行驶状态和周边目标等语义信息的复杂世界模型。处理这类海量信息自然需要更长的时间，但由于该决策仅影响乘客的乘坐舒适性（假设长时间跟在慢车后方会降低舒适性），系统可接受这一处理耗时。

Gat和Bonnasso首次探讨了内部状态的作用，并提出在系统中平衡反应式和慎思式组件的设计思路。在其研究方案中，功能组件根据对内部状态的记忆和知识储备，分为三类：无知识储备、具备过往知识、具备未来知识，最终形成三层功能组件架构。但该模型并未明确各层级之间的知识是否可共享，也未说明是否存在组件能整合过往、未来及其他静态数据的知识。

Albus提出的美国国家标准与技术研究院实时控制系统（NIST RCS）参考架构，是更优的研究方案，有效填补了反应式和慎思式组件之间的设计空白。该架构并非根据记忆能力对组件进行划分，而是基于语义知识构建层级结构。

因此，层级结构中较低层级的组件语义理解能力有限，其输出可为更高层级的组件提供输入，从而深化高层组件的语义知识和理解能力。此外，RCS架构对组件知识的时间范围无限制，组件可存储关于过去、现在或未来的静态或动态信息。尽管所有组件都维护一个世界模型，但该模型可简单到仅包含用于对比输入信息的参考值。

我们发现，该研究方案非常契合汽车领域的需求，也与第三部分提出的功能分类体系相匹配——因为它能平衡反应式和慎思式组件的设计，且支持层级化的语义处理，而这正是前文提出的功能组件分类体系的核心需求之一。后续将详细介绍该架构，并在图3中进行展示。

图3：实时智能控制系统参考架构

RCS节点控制循环的核心，是对外部世界的表征——即世界模型，它承担着数据融合的载体、感知与行为之间的缓冲器的作用，同时为传感处理和行为生成提供支撑。节点所负责任务的复杂度越高，其世界模型的复杂度也相应提升。对于最简单的任务，世界模型可高度简化，例如节气门系统的世界模型，仅需包含车辆速度和加速踏板输入信息即可。而对于目的地规划这类复杂任务，世界模型则需整合设计运行域的地图、实时交通信息等复杂数据。

传感处理模块对传感器输入的信息进行窗口化、聚类、计算、估计和分类处理；世界建模模块还可以图像、地图、事件及其相互关系的形式，存储静态知识；价值判断模块为决策制定提供评判标准；行为生成模块则负责行为的规划与执行。

Albus提出了分层控制结构中节点的设计方案，较低层级的节点可为更高层级的节点生成输入，从而提升抽象化和认知水平。因此，层级结构中较低层级的节点，可拥有高度简化的世界模型和行为生成功能，能够轻松实现为反应式组件。以保持与前车的安全距离为例，实现该功能的节点，其世界模型模块仅需存储与前车的距离、参考安全距离和车辆自身速度即可；当实际距离过近，或系统根据车辆速度预测距离将持续缩短时，行为生成模块将下达制动指令。

代表慎思式组件的高层节点，也可通过该架构轻松实现。其世界模型模块将处理更多的语义信息，并生成更复杂的行为（例如，为提升整体乘坐舒适性、优化行驶目标而做出的超车决策）。

在该层级结构中，高层节点会调用低层节点提取的语义信息，但在自动驾驶汽车中，这一规律并非绝对——不同层级的多个节点可能会调用相同的信息。例如，与前车的距离信息，可同时被上述的反应式组件和慎思式组件调用。此外，同一层级的多个组件可通过串行过程进行交互。

从架构设计的角度，遵循不同独立处理步骤的串行处理流，可通过“管道-过滤器”模式实现。该模式将一个过程拆分为多个串行步骤，步骤之间通过数据流连接——前一步骤的输出数据作为后一步骤的输入，每个处理步骤由一个过滤器组件实现。

纯“管道-过滤器”模式仅能表征串行过程，对于层级化结构，可采用该模式的变体——“分支-合并”管道系统。在该范式中，传感器的输入信息可被传递至对应底层控制循环的低层级管道、对应高层控制的高层级管道，或同时传递至两者。

图4为该模式的示例：传感器输入的信息被输送至不同的处理管道。在低抽象层级，管道1仅执行简单操作，并将结果发送至执行器；在高抽象层级，管道2处理更多的传感器数据，生成机动动作规划，并将其转换为执行器可识别的指令。系统将通过优先级判定，确定向执行器发送哪一路输入指令。第六和第七部分将进一步探讨该模式的其他替代方案，本部分将重点关注功能拆解，为后续架构设计确定核心节点。

图4：“分支-合并”管道架构模式

本部分首先介绍功能组件，第六部分将探讨组件的交互模式。图5描绘了满足SAE J3016完全自动驾驶汽车需求的功能组件，数据从左至右流动，从传感器抽象层到执行器接口层，形成一个闭环控制循环。图中包含三类实体：功能组件（蓝色方框）、组件类别（浅灰色方框）和组件子类别（深灰色方框）。

图5：拟提出的功能架构（第一部分）：功能组件

本研究方案与第二部分介绍的SAE功能组件分类体系的映射关系如下：车辆控制和执行器接口类组件对应SAE的操作类功能，规划类组件对应SAE的战术类功能，行为生成类组件则同时对应SAE的战略类和战术类功能。

图中还展示了两个正交的组件类别——数据管理类和系统与安全管理类，它们代表着跨领域的核心需求：数据管理组件实现数据的长期存储与检索，系统与安全管理组件与常规控制循环并行运行，实现动态驾驶任务的降级处理机制或其他安全相关功能。以下各小节将逐一探讨各类过滤器及其组件，最后一小节将阐述本架构与中间件解决方案及AUTOSAR的关联。

5.1 传感器抽象层

传感器抽象层为硬件传感器提供软件接口，并实现数据解析所需的适配和转换功能。我们将传感器及对应的抽象层分为两类：（1）监测车辆内部状态或动态属性的传感器（如惯性测量、车速等）；（2）满足SAE需求、监测车辆外部环境的传感器。

环境监测可基于雷达、激光雷达和摄像头技术实现；在协同驾驶场景中，车辆与其他交通参与者的通信通过车联万物（V2X）技术实现；全球定位系统（GPS）用于在地图环境中定位车辆或生成全局行驶路线，因此被设计为独立的功能组件。

由于整车制造商的设计选择存在差异，所有与车辆内部状态相关的抽象层功能被整合为一个功能组件。

5.2 传感器融合层

多传感器环境会产生大量不同分辨率的数据，这些数据往往受多种噪声和杂波干扰，且干扰情况会随环境的动态变化而持续改变。传感器融合技术通过整合来自不同异构数据源的信息，提升测量的准确性。

本研究根据 SAE 对目标和事件检测、识别、分类的需求，设计了相应的功能组件。我们将目标分为静态目标和动态目标（如护栏、行人），并单独划分出道路设施目标（如交通信号灯），因为它们具有不同的语义含义。此外，车辆相对已识别目标的定位需要局部定位功能，而战略功能的实现则需要全球定位系统的支持。

通过传感器融合技术，可构建一个整合雷达、摄像头等多种传感器信息的处理管道，以实现目标分类、速度判定，并为目标描述添加其他属性。图5中保留了车辆外部环境和内部状态的区分：前四个组件处理与外部环境相关的数据，最后一个功能组件则表征车辆的内部状态。

5.3 世界模型层

世界模型层整合车辆感知到的外部环境全貌与自身内部状态，将传感器融合层的输出数据与存储数据（如地图）相结合，构建完整的环境表征模型。

与 RCS 架构一致，世界模型层在传感处理和行为生成之间扮演缓冲器的角色。该类别中的组件存储并管理与图像、地图、实体、事件及其相互关系相关的知识，同时利用历史信息（来自过往的处理循环），并为其他组件提供查询和过滤其内容的接口。这些接口被称为“数据接收器”，可针对不同的消费组件过滤或聚类数据，以挖掘不同的信息价值。汽车行业中广泛应用的“鸟瞰视角”就是典型例子，不过实际部署的数 - 据接收器类型由各整车制造商自主决定。

5.4 行为生成层

行为生成层是本架构中认知层级最高的功能类别，该层的核心功能是对环境和车辆行为进行预测。系统会根据车辆的行驶目标，生成多种行为方案（通过行为生成模块）并选择最优方案（通过行为选择模块）。通常，车辆的行为可通过有限状态机（FSM）或马尔可夫决策过程（MDP）进行建模：行为生成模块从当前状态出发，生成一系列可能的状态序列；行为推理模块则利用目标函数（或策略）选择最优方案。强化学习（RL）中的复杂算法，会利用存储在知识数据库中的驾驶策略进行推理，生成未来的状态序列。尽管实现方式不同，但核心的功能循环保持一致：先生成多种备选行为，再通过目标函数（或策略）选择最优行为。

车辆的核心行驶目标是无事故地抵达指定目的地。当目的地发生变化（通过人机交互（HMI）输入）时，全局路径规划组件将更新行驶目标，并触发新的行为生成流程。这些组件对应 SAE 定义的战略类功能。

5.5 规划层

规划层的核心功能，是确定自动驾驶汽车为实现选定行为所需执行的各项机动动作。路径规划与监测组件生成无障碍物的行驶轨迹，并利用车辆上部署的组合功能，制定轨迹执行计划。该组件相当于一个监控器，负责任务拆解、选择任务实现的替代方法，并监测任务执行过程。为实现组件在不同车辆间的复用，或将研发工作外包，组合功能成为了关键设计选择，这些功能可被视为第二部分所述的动态驾驶任务功能特性，例如车道保持系统、自动泊车系统等，均为已商业化部署的组合功能实例。

组合功能是RCS架构的具体实现，它们通过数据接收器从传感器融合层或世界建模层获取数据输入，进行价值判断后做出相应动作，并将输出发送至车辆控制层。路径规划与监测组件作为协调器，决定完成行驶轨迹所需的功能，并对这些功能进行协调，直至行驶目标达成或出现新的目标。对于4级及以下的自动驾驶车辆（无法在所有驾驶条件下实现完全自动驾驶），当行驶目标无法实现时，车辆控制权必须交还给专业驾驶员。因此，该类别中包含驾驶提醒人机交互组件。

5.6 车辆控制层

车辆控制层是引导汽车沿规划轨迹行驶的核心模块，其总体控制任务被划分为横向控制和纵向控制，与SAE操作类功能的需求相契合。这种划分方式使控制系统能够独立处理车辆特性（如轮胎最大许用力、最大转向角等），并进行安全与舒适性的权衡分析。轨迹控制模块将路径规划与监测层生成的行驶轨迹作为输入，对横向和纵向控制模块进行调控。该行驶轨迹代表着某一路径规划组合功能设定的未来期望状态，例如，当车辆需要变道时，行驶轨迹仅会定义车辆在坐标和方向上的期望位置，而不会包含加速、转向或制动的具体执行方式。纵向控制算法接收纵向目标状态（如制动至40千米/小时），并决定通过加速、制动、收油或使用传动模块（即发动机制动）来实现该目标；横向控制算法则根据车辆的动态特性和目标轨迹，计算目标转向角。若行驶轨迹的变化需要进行信号提示，意图通信模块将触发相应的通信机制。

5.7 执行器接口层

执行器接口层将车辆控制层输出的数据转换为执行器指令，图5中展示的模块是实现纵向和横向控制的基础接口。

5.8 数据管理层

数据是自动驾驶汽车的核心。尽管大部分数据需要进行实时处理，但数据的持久化存储同样至关重要。数据管理类组件正是为满足这一需求而设计：全局定位功能需要内部地图存储；智能决策和模式识别算法需要训练好的模型（知识数据库）；内部状态上报需要先进的日志记录机制（日志数据库）。日志-报告数据库还可存储后续用于优化智能算法的数据；此外，审计数据库会保存权威的日志记录（类似于飞机的黑匣子），用于解决责任认定问题。为支持动态的部署配置，以及参考变量（如校准参数、决策变量）的修改，本架构中还设计了参考值数据库。

5.9 系统与安全管理层

系统与安全管理层负责处理功能安全机制（故障检测与管理）和交通安全相关问题，是“分离安全模式”的具体实现——该模式将控制系统与安全操作进行分离设计。图5中仅展示了识别故障并触发安全行为的组件（内部状态监测器，等效于看门狗），未展示冗余机制，而冗余机制可实现功能组件的部分或完全复用。此外，整车制造商为提升交通安全部署的专用安全功能，也被单独表征，目前这类功能的设计由各整车制造商自主决定。

随着车辆自动化等级的提升，制定复杂的安全决策成为必然要求。从3级自动化开始，车辆需完全承担交通安全责任，因此，车辆需部署具备完整安全推理和伤亡最小化能力的算法。尽管目前尚未明确安全推理功能在未来车辆中的标准化和实现方式，但这类组件很快将成为自动驾驶车辆的标配。文献详细阐述了自动驾驶车辆未来面临的安全挑战。基于“分离安全模式”的设计思路，图5中将安全推理组件与行为生成组件进行了分离设计。

5.10 AUTOSAR适配性

AUTOSAR是由整车制造商和零部件供应商组成的联盟，致力于推动汽车软件集成和运行所需软件基础设施的标准化。本文并非支持或反对AUTOSAR标准，各整车制造商可自主选择是否采用该标准。但由于其广泛的应用度，我们认为有必要明确本研究工作与该标准的适配性。在AUTOSAR标准的框架下，图5中的功能组件对应AUTOSAR软件组件，组件之间的接口可通过AUTOSAR定义的标准化接口进行规范。本文的抽象设计层级暂未涉及具体的软件接口设计。

如第四部分所述，图5中的组件构成一个分层控制结构，抽象化和认知水平随层级提升而提高，与 SAE 功能组件分类体系相映射：层级结构中较低层级的组件处理车辆控制等复杂度较低的操作类功能，较高层级的组件则处理路径规划、全局路线规划等规划类和战略类目标。

我们提出，在扁平控制结构（同一层级）中，组件间的交互采用“管道-过滤器”模式；在层级化结构中，采用“分支-合并”管道模式。在层级化设计中，较低层级的组件为相邻的较高层级的组件提供服务，但两者往往会调用相同的数据输入。图6通过“分支-合并”管道模式，展示了该系统的高层级表征，其中灰色方框代表处理管道，蓝色方框代表组件类别。

每个组件类别对应的处理过程均可视为一个管道，以用户输入最终目的地为例，该过程将触发行为生成流程，具体如图7所示：当人机交互输入过滤器接收到目的地信息后，全局路径规划过滤器将路线发送至行为生成过滤器；行为生成过滤器将路线拆解为车辆抵达目的地所需执行的一系列动作，这些动作等效于有限状态机中的状态，且任意两个状态之间通常存在多条可行路径；随后，行为选择组件将选择两个状态之间的最优路径，并将其发送至规划流程。

图6：拟提出的功能架构（第二部分）：基于“分支-合并”管道模式的分层控制结构

图7：拟提出的功能架构（第三部分）：类别级组件交互——行为生成流程

此外，组件层级接收到的消息需要进行优先级排序。例如，执行器接口可能同时接收来自纵向控制组件的常规指令，或来自安全专用功能（如紧急制动）的指令，为确定优先执行的指令，消息中需包含优先级标识。由于该功能与组件接口设计相关，且由各整车制造商自主实现，本文暂不展开深入探讨。

第七部分将详细讨论所选交互模式的各类替代方案。

软件架构设计并非一个确定性的过程，针对同一组需求，不同的架构师可能会得出不同的设计方案。对各类替代方案进行评估并选择最优方案的过程，被称为权衡分析。本文中的多项设计决策均存在其他可行方案，因此，本部分将介绍这些决策的替代方案，并分析其优缺点。

本文的基本前提是：可从SAE J3016汽车标准中推导出一套有效的设计需求。如第二部分所述，该标准的目的并非为自动驾驶提供完整的定义，而是对实现自动驾驶所需的核心功能进行基础性阐释，旨在指导研发过程，而非进行详尽的描述。但我们认为，这些信息已能满足本研究的目标，因为超出基础需求的任一功能，均可由各整车制造商自主设计实现。

第二个需要探讨的设计决策，是将NIST RCS架构作为本研究的参考架构。第四部分已将其与其他研究方案进行了深入对比，本部分将重点分析选择该参考架构带来的权衡问题。尽管该架构能够清晰地区分反应式和演绎式组件，且具有足够的通用性来表征两类组件，但对于简单的节点而言，该架构有时过于复杂。

为实现操作类的简单功能，无需复杂的世界模型或行为生成模块，部分组件甚至可完全省略这些模块。但该架构并未对世界模型的复杂度施加约束，因此，通过简化世界建模或行为生成模块，该架构可轻松表征数值比较器等简单的控制循环。此外，与其他研究方案相比，该参考模型允许每个独立节点具备一定的推理能力——而在其他模型中，仅层级结构中较高层级的组件负责规划任务。这一特性对于汽车软件开发生命周期，以及本架构中表征的组合功能而言，是一项重要优势。

我们预计，整车制造商将继续承担技术集成商的角色，并将更复杂的功能研发工作外包给供应商，例如完整的车道保持系统或避障系统。这些系统可轻松实现为RCS节点，并整合到整体架构中。

我们认为，RCS模型的通用性足以支持复杂功能的研发，但对于简单功能而言，其设计有时过于复杂——这一权衡问题可通过简化后者的架构模块轻松解决。一种更具表达性的替代方案是，提出不同复杂度的RCS节点——较低层级的节点可仅用价值判断模块替代世界建模模块。但这一决策需要进行独立的权衡分析，因为在为每个组件选择节点类型时，可能会增加设计的复杂性，并引发其他权衡问题。

第三个明显的权衡问题与功能拆解相关。尽管我们致力于将每项功能进行原子化拆解，并单独表征每个子组件，但无法证明这是唯一正确的方式。新的市场趋势显示，片上系统电路的应用日益广泛，这类电路可整合越来越多的组件。Mobileye等技术企业正致力于将多项功能整合到专用芯片中。在这类场景下，传感器抽象层和融合层可进行合并，但此类芯片实现的功能仍与本研究方案高度相似。例如，即便传感器抽象层被整合为一个组件，传感器融合层的所有功能仍需实现，因为静态、动态和道路设施目标的检测，是自动驾驶的必备功能。因此，本文提出的原子化拆解方式，能够适配这类技术演进。

第四个需要考虑的权衡问题与组件交互模式的选择相关。我们研究了“分支-合并”管道模式的多种替代方案，其中最明确的一种是分层架构——将功能组件划分为不同的层级，高层级组件可向低层级组件发起函数调用。但这一选择会限制组件间的潜在交互，进而约束设计的灵活性。首先，每个层级会封装部分组件，导致这些组件无法在其他流程中被复用或重新协调；其次，低层级组件的函数调用必须由高层级组件发起，进一步限制了设计的灵活性。

另一种替代方案是基于组件的架构，所有组件处于同一层级，任意组件均可与其他所有组件进行通信。该模式似乎更契合汽车领域的需求，因为不同的组件部署在不同的电子控制单元上，并通过总线进行通信，但它无法表征层级化的推理过程。

我们认为，“分支-合并”模式与基于组件的架构具有等效性，且能够表征层级化的处理过程。因为从任意一个组件出发，均可与其他任意组件构建新的管道。若仅采用“管道-过滤器”模式，设计的灵活性将大幅降低；而通过允许在不同管道中重新协调过滤器，“分支-合并”管道模式可轻松表征扁平或层级化的各类处理过程。

在该模式下，既可以定义类似于基于组件协调的扁平处理过程，也可以定义类似于第三部分提出的层级化功能类别的层级化处理过程，唯一需要考虑的是处理优先级——即确定各管道的执行顺序。

软件架构师会同时评估架构的功能适宜性，以及性能、可维护性等非功能属性。本文仅关注架构是否满足SAE J3016标准的功能需求，以及功能的完整性，但我们认为有必要探讨另外两个重要方面：（1）拟提出架构与汽车软件开发生命周期的契合性；（2）拟提出架构与规范功能安全的ISO 26262标准的关联。第九部分将将本研究方案与现有文献进行对比。

8.1 渐进式研发与组件复用

第二部分介绍的SAE分类体系，展示了从部分自动化到完全自动驾驶汽车的渐进式演进路径，软件组件的功能划分应遵循这一渐进式特征。此外，还需考虑整车制造商的软件开发生命周期，以及其对外包研发的偏好。

如第二部分所述，动态驾驶任务的自动化，等效于部署并协调足够多的驾驶自动化功能特性，以满足人类驾驶员能够安全驾驶的所有场景条件（设计运行域）。这一前提衍生出两种研发路径：

1. 部署针对新动态驾驶任务功能特性的软件组件；

2. 对现有驾驶功能特性进行升级，增强其功能。

在图5中，新的动态驾驶任务功能特性对应路径规划层中新增的组合功能。组合功能的使用，实现了渐进式和分布式的研发，但增加了路径规划与监测组件的复杂度。这些组件可为商用现货产品，可轻松外包给一级供应商研发。

行为生成层的功能优化，可通过更新知识数据库实现；车联万物组件与外部环境进行交互，因此可通过该组件推送更新。在大多数情况下，更新主要针对知识数据库或参考值数据库。

8.2 功能安全

汽车行业受ISO 26262标准的约束，对功能安全提出了严格要求。功能安全的目标是，避免组件因输入、硬件或环境变化而引发故障，或造成人员伤亡。ISO 26262标准提出了故障检测、安全关键组件冗余等实现机制。本研究方案中，我们表征了故障检测相关的功能组件，但未表征任何冗余或组件复用机制。

同时，我们旨在填补ISO 26262标准在自动驾驶汽车领域的一项空白：安全推理。目前，对于自动驾驶汽车在无法避免事故时应采取何种行为，以及应优先降低哪种风险，尚未形成明确的标准。但预计未来的安全标准将纳入安全行为的规范要求。

本文提出了一种面向完全自动驾驶汽车的功能型软件架构。鉴于汽车行业高度的标准化特征，本研究以定义了多个驾驶自动化等级、并为每个等级制定功能定义的汽车行业标准为基础，遵循其功能需求展开设计。

在架构设计过程中，我们力求遵循自动驾驶汽车的渐进式研发流程，以及汽车行业特有的分布式软件开发生命周期。最终的研究成果，是NIST RCS实时智能控制系统参考架构在汽车领域的具体实现。我们采用“管道-过滤器”架构模式实现组件间的交互，采用“分支-合并”管道模式表征分层控制结构。本文对多项设计决策的权衡问题和替代方案进行了详细探讨。

未来的研究工作可通过行业专家意见，对本架构进行优化完善；后续还将开展组件接口设计、硬件架构选择、功能组件在电子控制单元间的分布，以及本地网络内的组件部署等研究，以满足安全需求。

免责声明：文中观点仅供分享交流，文章版权及解释权归原作者及发布单位所有，如涉及版权等问题，请您联系TechApe@yeah.net告知，我们会在第一时间做出处理。