摘要：在汽车行业中，目前正开展将自适应汽车开放系统架构（Adaptive AUTOSAR）应用于自动驾驶、联网汽车等下一代移动出行领域开发的相关研究。然而，自动驾驶相关研究主要基于机器人平台ROS2（机器人操作系统2）进行，这使得自动驾驶研究与实际车辆应用之间存在较大差距。为弥合这一鸿沟，需实现一种互操作性方案，既能发挥自适应AUTOSAR和ROS2平台的优势，又能弥补二者的不足。因此，本研究提出了一种面向这两个平台的互操作性架构，命名为“融合ROS2与自适应AUTOSAR的自动驾驶系统（ASIRA）”。该架构通过ROS2 SOME/IP桥接器实现两个平台间的通信，支持必要的数据交换，并在自动驾驶场景中进行了验证。其应用范围不仅限于车辆开发、测试和原型设计，还能充分利用各平台的优势。此外，通过将ROS2代表性开源自动驾驶项目Autoware与自适应AUTOSAR仿真器进行互操作，验证了ASIRA架构下自动驾驶车辆的仿真可行性。本研究通过将ROS2与自适应AUTOSAR相连，为ROS2融入汽车行业并应用于实际车辆奠定了基础。
原文作者：Dongwon Hong，Changjoo Moon
原文标题：Autonomous Driving System Architecture with Integrated ROS2 and Adaptive AUTOSAR
编译：猿东东，猿西西
随着汽车行业的日益复杂化，对更多传感器和电子设备的需求导致车辆内部配置的复杂性不断增加。与此同时，车辆必须确保安全性、稳定性、保密性以及数据的实时收发。车辆内部的电子控制单元（ECU）数量不仅不断增多，所需软件的复杂性也呈指数级增长。现代车辆架构的管理难度极大，部分车辆的 ECU 连接数量已超过100个。这意味着传统的车辆电子电气（E/E）架构需要进行变革。
为响应这些技术发展需求，汽车行业推出了“汽车开放系统架构（AUTOSAR）”，这是一个由汽车原始设备制造商（OEM）、供应商及其他行业相关方组成的国际联盟。自2003年起，AUTOSAR推出了经典平台（Classic Platform），该平台适用于资源有限的嵌入式系统，具备高安全性，可满足汽车安全完整性等级（ASIL-D）要求。AUTOSAR 基于控制器局域网（CAN）或 FlexRay 等基于信号的通信方式。然而，随着自动驾驶、联网汽车等先进技术的发展，以及能持续产生大量数据的高性能传感器在车辆中的集成应用，CAN等传统通信方式开始暴露出带宽问题。此外，架构在为各类软件应用提供传感器数据时的灵活性变得愈发关键，而用于传感器数据顺畅采集和处理的高性能处理器也变得更为重要。
为满足这些技术需求，AUTOSAR于2017年推出了自适应AUTOSAR，该架构基于POSIX操作系统。自适应AUTOSAR支持基于以太网的高带宽可扩展面向服务中间件（SOME/IP）协议，实现了从传统基于信号的数据通信向基于服务的通信转变。此外，对高性能计算的支持使得自动驾驶所需的计算性能更易获取，也便于各类高性能传感器和算法的集成。这一进步旨在推动自动驾驶等下一代移动出行领域的发展。汽车行业与AUTOSAR在这一方向上已取得显著进展。
与汽车行业的努力不同，大多数自动驾驶的研发工作是在由开放机器人技术公司（Open Robotics）管理和开发的机器人平台——机器人操作系统（ROS）上进行的。ROS最初是为大学和研究机构的研究目的而设计的中间件，后以开源项目的形式对外开放，吸引了大量用户开发并分发各类软件包和库。这种开放性极大地加快了开发速度，提供了众多支持自动驾驶所需传感器的驱动程序以及传感器处理算法。此外，ROS支持Gazebo等强大的仿真环境和Rviz等可视化工具，提升了开发的便捷性。然而，ROS缺乏实时控制能力，且对计算资源要求较高。它还采用了专有的通信方式TCPROS，该方式依赖于单一故障点——ROS主节点（ROS Master）。由于暴露主节点IP和端口存在严重的安全风险，TCPROS不适用于工业场景。为解决这些问题，第二代版本ROS2应运而生。
ROS2通过引入数据分发服务（DDS），弥补了ROS1以研究为导向的局限性。DDS是军事和航空航天领域用于面向服务通信（SOC）的标准。此外，DDS实时发布-订阅（DDS-RTPS）协议的引入，使得在代码结构良好的前提下实现实时控制成为可能。这些创新表明ROS1有望突破自身局限，向工业化方向发展。例如，Apex公司基于ROS2成功开发出一种高安全性解决方案，满足了电气和/或电子系统功能安全标准（ISO 26262）的ASIL-D等级要求。这一趋势促使众多基于ROS1的自动驾驶项目向ROS2迁移，Autoware便是其中的典型代表。Autoware是一个开源项目，涵盖了感知、决策和控制等自动驾驶核心功能。目前，它正在自动驾驶巴士、穿梭车和自动代客泊车等多个测试平台上进行测试，相关技术正朝着激活和商业化的方向持续发展。然而，要让消费者在日常生活中使用自动驾驶车辆，必须满足严格的条件。目前几乎所有汽车企业都遵循AUTOSAR标准，这意味着自动驾驶技术的研发与实际车辆应用之间存在明显差距。为充分发挥各平台的优势并规避其劣势，需以一种可实际应用于汽车行业的形式，确保自适应AUTOSAR与ROS2平台之间的互操作性。
实现这种互操作性的两种数据通信方式为DDS和SOME/IP。尽管自适应AUTOSAR的研究和应用正在积极推进，但它可能因非确定性问题导致不可预测的行为。因此，在实际车辆开发和生产阶段，为保证稳定性，通常会采用与经典AUTOSAR相结合的架构，经典AUTOSAR可实现确定性执行。经典AUTOSAR支持SOME/IP，但不支持DDS。此外，从成本角度来看，经典AUTOSAR所使用的半导体芯片硬件资源非常有限。DDS涵盖的协议范围更广，且由于其具备多种服务质量（QoS）特性，对内存的需求远高于SOME/IP。因此，与SOME/IP相比，DDS对车辆网络基础设施的硬件资源依赖性更强，在微控制器上实现和使用DDS在功能方面受到极大限制。
基于上述原因，本研究提出了一种通过基于以太网的SOME/IP协议集成自适应AUTOSAR和ROS2的方法，旨在确保安全性的同时，为自动驾驶车辆的开发和测试提供灵活的环境。自适应AUTOSAR长期以来一直是汽车企业的标准架构，是经过验证的平台，侧重于汽车系统的高可靠性和安全性。而在机器人领域广泛应用的ROS2，虽然在安全性和实时控制方面存在不足，但在通信灵活性、活跃开源社区带来的开发便捷性、传感器驱动程序开发等方面具有显著优势。此外，ROS2在强大的可视化工具、开发工具和仿真工具方面也具备突出特点。将自适应AUTOSAR与ROS2集成，可充分利用汽车领域的安全性和机器人领域的灵活性，简化并加速自动驾驶车辆的开发和测试过程。同时，与DDS相比，通过SOME/IP协议实现的互操作性能更快地被当前汽车行业所采纳。为整合这两个截然不同的平台，本研究设计并实现了一种互操作性架构，即“融合ROS2与自适应AUTOSAR的自动驾驶系统（ASIRA）”。在Linux环境中使用ASIRA，可实现ROS2自动驾驶项目Autoware与自适应AUTOSAR平台之间的数据交换，从而支持自动驾驶车辆的运行。
本文的结构如下：第2节介绍相关研究和背景知识；第3节描述系统架构、组件及系统实现方法；第4节通过场景仿真验证所开发的系统，验证两个平台的数据交换能力和自动驾驶实现效果；最后，第5节总结全文并提出未来的研究方向。
第2节提供本研究中使用的平台、技术及其他相关工作的背景信息。2.1节介绍自适应AUTOSAR；2.2节介绍ROS和ROS2；2.3节介绍相关工作，并讨论其优势与局限性。
2.1. 自适应AUTOSAR
AUTOSAR 2.0于2006年发布，此后不断演进至AUTOSAR 4.3（2017年），并广泛应用于各类车辆。然而，近年来电动汽车和自动驾驶的兴起对现有AUTOSAR平台提出了新的需求，如高网络带宽和高计算能力。为满足这些需求，研究人员尝试在车辆中安装Linux系统。Linux环境虽能弥补现有AUTOSAR平台的部分不足，但缺乏车辆开发环境中使用的必要软件，如CAN通信和诊断功能。在此背景下，AUTOSAR联盟将原有的AUTOSAR平台命名为经典平台，并推出了基于POSIX操作系统的自适应AUTOSAR平台。
自适应AUTOSAR的整体架构逻辑视图如图1左侧所示。顶层为自适应应用程序（AA），自适应应用程序运行在自适应应用程序AUTOSAR运行时（ARA）之上。ARA由平台基础功能集群（FC）组成，此外还包括自适应平台服务和标准应用程序/接口（图中未显示）。功能集群提供自适应AUTOSAR的基本功能，且随着自适应平台版本的不断演进，新的功能集群也在持续增加。
图1右侧展示了自适应AUTOSAR平台的运行机制，其中包含一个使用基于POSIX的操作系统API的功能集群，AUTOSAR运行时嵌入其中。用户可通过该API开发和使用所需的应用程序。同样，在本研究中，通过开发基于ARA的应用程序，实现与ROS2的集成。自适应AUTOSAR与传统经典平台的一个显著区别在于，它不依赖于传统的面向信号的通信，而是基于面向服务的通信（SOC）。通过利用基于面向服务的通信、在ara::com中实现的SOME/IP协议，可开发支持服务器与客户端之间动态连接的应用程序。
图1：自适应AUTOSAR平台的架构（左侧）与运行机制（右侧）
2.2.ROS
2.2.1.ROS1
自2009年关于ROS开源中间件的论文发表以来，ROS中间件已被大学、研究机构和个人广泛应用于机器人和自主系统的开发。特别是其活跃的社区，促成了大量适用于各类机器人的库和软件包的开源发布（例如点云库（PCL））。此外，各类企业生产的传感器驱动程序也可获取，这为ROS生态系统的快速发展提供了有力支持。然而，为研究目的开发的ROS1在商业应用中面临诸多限制。除了实时控制需求外，ROS1在开发过程中还存在一些从工业角度来看的缺陷，包括操作系统限制、单一故障点和安全问题。例如，美国国家航空航天局（NASA）的Robonaut机器人开发基于ROS1，但由于上述局限性，其在实际应用中面临挑战。
2.2.2.ROS2
2017年，开放机器人技术公司（Open Robotics）发布了ROS2的首个版本，以弥补ROS1的不足并使其能够应用于商业场景。ROS2的一个关键变化是不再使用ROS1中常用的TCPROS，而是采用DDS作为节点间通信的基础中间件。该服务被对象管理组织（OMG）指定为国际标准，并允许将DDS-Security安全规范集成到ROS2中。这一改进解决了ROS1中的安全漏洞。此外，DDS支持实时发布-订阅（RTPS）协议的特性，使其能够满足实时控制要求。
ROS2提供了机器人客户端库（RCL），支持rclcpp、rclpy、rcljava等多种编程语言。与ROS1相比，这显著提升了开发灵活性，允许为特定算法选择优化的编程语言。
2.3.相关工作
近年来，关于自适应AUTOSAR与ROS2的互操作性以及ROS2在车辆中应用的研究逐渐增多。Jacqueline Henle对ROS2和自适应AUTOSAR进行了对比，以评估二者在未来车辆架构中的适用性。自适应AUTOSAR采用面向服务的架构和以太网技术，提供更宽的带宽，适用于自动驾驶等未来车辆的架构需求。然而，它也存在一些劣势：在ara::iam安全机制、平台健康检查、通过ara::per实现的信息持久性以及车辆诊断功能方面，自适应AUTOSAR优于ROS2；但在维持持续集成和开发环境、节点间的松耦合、开发速度以及提供强大的调试和可视化工具方面，ROS2 的表现更优。不过，该研究并未考虑两个平台之间的互操作性。本研究提出的架构设计旨在弥补两个平台的劣势，同时强化其优势，实现二者的交互，并通过自动驾驶仿真进行验证。
Arestova提出了一种新的架构，通过集成自适应AUTOSAR、开放平台通信统一架构（OPC UA）和时间敏感网络（TSN）技术，满足汽车行业面向服务和实时通信的需求。自适应AUTOSAR支持动态部署和高性能处理，OPC UA实现设备间灵活的面向服务的通信，TSN确保实时网络通信。该研究探讨了这三种技术的组合如何提供高速确定性通信，特别是OPC UA的客户端-服务器和发布-订阅模型如何应用于自适应AUTOSAR的面向服务的通信。此外，通过实时系统绑定的实现和性能评估，验证了该架构的有效性。然而，研究人员仅对通信本身进行了实现和验证，并未在实际运行环境中进行测试。本研究通过自动驾驶场景验证了两个平台的互操作性，并通过仿真对所开发的系统进行了有效性验证。
第3节描述本研究开发的ASIRA架构的结构和实现方法。3.1节解释整体架构、各组件的作用及数据流向；3.2节讨论架构的实现方法。
3.1.系统架构
本研究的系统架构分为两个主要部分：自适应AUTOSAR平台和ROS2自动驾驶平台，如图2所示。
3.1.1.自适应AUTOSAR平台
自适应AUTOSAR平台采用符合AUTOSAR标准开发的开源软件，在Linux上仿真自适应AUTOSAR运行时，基于R20-11和R22-11版本实现。虽然并未实现ARA的所有组件，但如图所示，已按照AUTOSAR标准实现了ara::com、ara::core、ara::diag、ara::exec、ara::log和ara::phm。自适应应用程序（AA）可利用符合AUTOSAR标准的ARA开发所需功能。在本研究中，基于ARA开发了一个自适应应用程序，通过构建SOME/IP服务发现（SD）服务器和RPC发布/订阅服务器，与ROS2自动驾驶平台交换必要的数据包。
3.1.2. ROS2自动驾驶平台
ROS2自动驾驶平台部分基于ROS2的开源自动驾驶软件平台Autoware以及本研究提出的ROS2 SOME/IP桥接器实现。Autoware包含自动驾驶车辆运行所需的所有必要组件，如感知、定位、规划和控制，并提供自身的仿真环境。本研究利用Autoware的仿真环境实现并验证自适应AUTOSAR平台与ROS2的集成。
ROS2 SOME/IP桥接器主要由三部分组成：第一部分是接收器和发送器，负责接收和传输与自适应AUTOSAR平台集成所需的RPC请求/响应数据包；第二部分是将接收到的数据包转换为ROS2可使用的“数据类型”，转换为所需的话题名称和消息类型并生成消息，或者反过来将其转换为可打包成RPC请求/响应数据包的字节数组；第三部分是通过DDS中间件将转换后的消息发布到ROS2平台，或接收需要从Autoware传输到自适应AUTOSAR平台的话题。ROS2 SOME/IP桥接器中的节点均按照这三部分的功能进行结构化设计，可根据数据的格式或类型进行必要的修改。
3.1.3.数据流向
图3展示了整个系统的数据流向图，描述了在ROS2 SOME/IP桥接器中实现的、作为ASIRA系统架构实际实现和验证一部分的运动学状态和控制命令交换过程，执行顺序以数字标识。
1. 服务发现（SD）服务器通过从ARXML文件解析得到的组播IP和端口，以及RPC服务器的端点信息启动服务器。ROS2 SOME/IP桥接器中的运动学状态订阅者节点和控制命令发布者节点加入组播组并发送服务查找（findService）数据包。服务发现服务器检查数据包中的服务ID信息，并将相应的RPC端点信息发送给桥接器节点。
2. 每个数据包从服务发现服务器接收的RPC端点数据包中获取各自的RPC服务器端点信息：运动学状态订阅者获取RPC发布服务器的端点，控制命令发布者获取RPC订阅服务器的端点。
3. 桥接器节点利用获取到的端点信息尝试连接RPC服务器，连接建立后发送请求。
4. 当RPC发布服务器收到来自运动学状态订阅者的RPC请求时，调用其处理器（Handler）。该处理器生成用于系统验证的虚拟车辆里程计数据，并在响应负载（Response Payload）中发送回运动学状态订阅者。
5. 运动学状态订阅者接收响应负载后，解析数据包以获取位置（Pose）、姿态（Orientation）、线速度（Linear Velocity）和角速度（Angular Velocity）信息。
6. 随后，按照ROS2中使用的nav_msgs/Odometry消息格式对该信息进行格式化，并发布到ROS2平台，包含车辆的位置、方向和速度等数据。
7. ROS2 Autoware平台订阅里程计话题（Odometry Topic），随后从规划节点（Planning Node）获取轨迹信息并发送至控制节点（Control Node）。控制节点利用该信息生成车辆控制命令并发布话题。
8. 控制命令发布者节点（Control Command Publisher Node）订阅车辆控制命令话题（Vehicle Control Command Topic），并按照RPC请求负载格式将其转换为字节数组以创建数据包。
9. 向RPC订阅服务器发送请求。
10. 当RPC订阅服务器收到请求时，从负载中提取车辆控制命令，包括横向和纵向命令，详细信息如转向角、转向旋转速率、速度、加速度和加加速度（jerk）值，随后将该信息转换为自适应AUTOSAR平台可使用的格式。
以上是整个系统的运行流程：自适应AUTOSAR平台发送的数据通过桥接器节点被ROS2自动驾驶平台使用，这些数据经处理后的结果再通过桥接器返回给自适应AUTOSAR平台供其使用。
3.2.系统实现
系统实现包括自适应AUTOSAR平台的ARXML创建、自适应应用程序实现以及ROS2 SOME/IP实现。
3.2.1.自适应AUTOSAR平台的ARXML编写
自适应AUTOSAR平台的典型开发流程是创建ARXML清单文件（Manifest file），并基于该清单文件设计AUTOSAR建模和电子电气（E/E）架构，这通常通过提供不同AUTOSAR工具的公司的工具链完成。本研究未使用任何特定公司的AUTOSAR解决方案，而是通过ARXML定义运行应用程序所需的各种参数。待执行应用程序的规范通过ARXML清单文件编写并作为参数传递，随后利用该参数执行自适应AUTOSAR平台。首先执行通过ara::exec实现的执行管理（Execution Management），然后执行负责与ROS2交互的自适应应用程序（AA）。
自适应应用程序通过ARXML读取器（ARXML Reader）读取ARXML清单文件，该文件包含SOME/IP网络设置的参数。本研究使用的清单文件遵循自适应平台清单的R20-11标准规范，其主要属性如表1所示。
表1描述了自适应应用程序（AA）实现的主要组件。用于集成ROS2的自适应应用程序包含三个主要组件：
第一个是通信集群组件。在集群配置中，设置了两个端点（EP），即服务发现端点（ServiceDiscoveryEP）和RPC订阅服务器端点（RPCSubscribeServerEP）。服务发现端点是服务发现（SD）的端点信息，RPC订阅服务器端点是通过服务发现配置连接后用于RPC通信的端点信息。
第二个是以太网通信连接器（Ethernet Communication Connector），定义上述通信集群组件中的端点属性，本研究中仅指定端口号。
最后是配置提供的SOME/IP服务实例（Provided SOME/IP Service Instance），自适应应用程序利用该组件配置和设置SOME/IP服务发现服务器，以实现与ROS2桥接器的相互发现。运行一个服务发现服务器，在适当的频段中指定IP和端口以启用组播IP，然后为服务发现服务器的初始提供（Initial Offer）设置最大/最小延迟时间。
3.2.2.自适应AUTOSAR平台上的自适应应用程序实现
执行管理（Execution Management）在新线程中启动自适应应用程序（AA）。首次运行时，自适应应用程序导入ARXML清单文件并解析参数，以设置SOME/IP服务发现服务器和RPC服务器。通过ara::com内部的SOME/IP创建服务发现服务器，并在与具有组播组IP和地址的网络组建立连接时处于等待状态。此时，根据上述配置的初始延迟（Initial Delay），在发送第一条消息前进入等待状态。随后，消费者（本研究中为ROS2 SOME/IP桥接器）为所需服务配置数据包，并通过服务查找（findService）消息将其发送至组播组。此时，服务发现服务器检查数据包中的服务ID信息，若与服务器的服务ID匹配，则向组播组发送包含端点信息的服务提供消息（service offer message）。这一过程称为服务发现（SD），使自适应AUTOSAR平台和ROS2 SOME/IP桥接器能够相互发现，并允许消费者端获取端点信息以请求连接。
RPC服务器根据从ARXML清单文件解析的端点信息创建，采用ara::com内部SOME/IP网络绑定支持的RPC。共创建了两个RPC服务器，其作用如下：
· RPC发布服务器（RPC Publish Server）：当收到来自ROS2桥接器的请求时，自适应AUTOSAR平台在RPC响应数据包中向ROS2桥接器发送车辆里程计数据。
· RPC订阅服务器（RPC Subscribe Server）：当收到来自ROS2桥接器的请求时，RPC订阅服务器解析请求数据包以获取车辆的命令信息，并将该信息提供给自适应AUTOSAR平台。
设置两个RPC服务器并与ROS2桥接器建立独立连接的原因是各自的数据传输周期不同。通过两个RPC服务器，每个服务器可以独立地发送和接收数据。若向RPC服务器发送请求时出现延迟，响应也会相应延迟，这对于实时数据收发的系统来说可能是致命的。
创建RPC服务器后，为每个服务器创建RPC处理器（RPC Handler）并将每个处理器绑定到RPC服务器。绑定过程包括向RPC服务器注册服务ID和方法ID（Method ID）。每个处理器负责检查接收的数据包、解析数据包的负载，以及消费该数据包或发送相应的响应。与两个RPC服务器连接的处理器的作用如下：
· RPC运动学状态处理器（RPCKinematicStateHandler）：与RPC发布服务器相关联。当收到来自ROS2 SOME/IP桥接器的RPC请求时，调用RPC运动学状态处理器。该处理器向ROS2 Autoware发送车辆里程计信息，生成包含仿真过程中产生的虚拟车辆里程计信息的数据包，并将其发送至RPC响应（RPC Response）。待传输的数据如表2所示。
· RPC车辆命令处理器（RPCVehicleCommandHandler）：与RPC订阅服务器相关联。当收到来自ROS2 SOME/IP桥接器的RPC请求时，调用RPC车辆命令处理器。该处理器处理ROS2 Autoware中RPC运动学状态处理器发送的车辆里程计信息，并接收包含车辆轨迹跟踪命令的数据包作为请求，从请求数据包中提取信息供自适应AUTOSAR平台使用。接收的数据如表3所示。
3.2.3.ROS2 SOME/IP桥接器实现
ROS2 SOME/IP桥接器收到数据包后，从中提取用户想要连接的服务器的端点信息。端点信息包含服务器的IP地址和端口信息，构成SOME/IP RPC的客户端套接字。ROS2 SOME/IP桥接器包含两种类型的套接字。
图4展示了ROS2 SOME/IP桥接器为定位服务发现服务器而接收的组播数据包的组件，遵循R20-11版本的AUTOSAR标准。该数据包的组件中，ROS SOME/IP桥接器主要使用的数据如表4所示。
· 运动学状态订阅者（KinematicStateSubscriber）：持续向自适应AUTOSAR平台的RPC发布服务器发送RPC请求，以获取运动学状态。自适应AUTOSAR平台接收请求，并在响应中发送指示车辆当前里程计的信息。桥接器解析响应数据包，提取所需信息，并按照ROS2的nav_msgs/Odometry消息类型填入数据。nav_msgs/Odometry消息如表5所示。
将从数据包中提取的数据填入里程计消息（Odometry Message），并发布到ROS2平台供Autoware使用。
· 控制命令发布者（ControlCommandPublisher）：订阅ROS2平台上Autoware发布的车辆控制命令话题（Vehicle Control Command Topic）。该话题包含使车辆能够跟踪自动驾驶平台中规划算法生成的轨迹的方向盘和速度曲线相关数据。从该话题中提取数据，并以RPC请求数据包的形式发送至自适应AUTOSAR平台的RPC订阅服务器。车辆控制命令话题的结构如表6所示。
控制命令发布者（ControlCommandPublisher）基于从话题中提取的数据，构建要发送至自适应AUTOSAR平台的数据包。随后，将阿克曼控制命令话题（AckermannControlCommand Topic）的数据内容作为RPC请求的负载发送，使车辆控制信息可供自适应AUTOSAR平台使用。
第4节描述验证本文构建的ASIRA架构的流程。4.1节描述系统验证的环境配置；4.2节描述验证场景和仿真方法；4.3节基于实际仿真结果，验证本研究构建的ASIRA架构的互操作性。
4.1.系统验证环境
为验证本研究实现的系统，在ROS2自动驾驶平台上创建了点云地图（Point Cloud Map）和矢量地图（Vector Map）。图5中的红色正方形区域表示机器人平台移动以收集图6所示数据时，使用激光雷达（LiDAR）传感器采集数据的区域。机器人在收集16通道三维激光雷达数据的同时，通过基于图的同步定位与地图构建（SLAM）算法执行广义迭代最近点（gicp）/正态分布变换（ndt）扫描匹配和同步定位与地图构建（SLAM），构建点云地图。
同步定位与地图构建（SLAM）的结果如图7所示，创建了三维点云地图，用于Autoware中的定位和感知过程。除点云地图外，还构建了矢量地图（图中所示）。该矢量地图采用Lanelet2格式，包含车辆可行驶道路的位置信息，如左右车道、停止线、交通信号灯等各种驾驶所需的约束条件。利用TIER V4的矢量地图构建器，构建了包含道路信息的矢量地图，用于仿真验证。图8中，点云重叠部分的黄色区域为车辆可行驶区域。
4.2.验证场景
图9展示了用于验证本研究提出的系统的场景，下文将描述各部分的验证实现方法。
· 虚拟里程计数据文件（Dummy Odometry Data File）：验证场景假设车辆已知其位置、姿态、线速度和角速度。自适应AUTOSAR平台配备虚拟里程计数据，虚拟位置信息通过在场景环境中运行图6所示的实际数据采集机器人获得。该过程中获取的里程计结果与时间戳（Timestamps）一起以20毫秒的间隔记录，并转换为逗号分隔值（CSV）文件，用于ASIRA的验证过程。
图10展示了部分获取的里程计数据转换为带时间戳的逗号分隔值（CSV）文件的结果。为可读性起见，图10中省略了部分线速度和加速度数据。当收到来自ROS2 SOME/IP桥接器的请求时，逐行读取逗号分隔值（CSV）文件，以模拟车辆位置信息的获取。车辆的x、y、z位置基于通用横轴墨卡托（UTM）坐标系，以纬度37.5422、经度127.0785为原点。里程计数据还包含指示车辆姿态的姿态x、y、z、w值，以及线速度和角速度。
· ROS2 SOME/IP桥接器：如3.2节所述，ROS2 SOME/IP桥接器负责请求和接收车辆位置数据并将其发送至ROS2话题，从Autoware接收车辆命令话题（Vehicle Command Topic）并通过RPC请求发送至自适应AUTOSAR平台。此外，为匹配Autoware使用的里程计信息的速率，每2.5毫秒向自适应AUTOSAR平台请求一次位置信息。
· Autoware：当Autoware从ROS2 SOME/IP桥接器收到里程计信息时，利用该信息进行定位；通过点云地图执行感知（Perception），利用感知和矢量地图结果执行规划（Planning），并生成轨迹信息。控制节点（Control Node）利用该轨迹信息最终发布车辆控制命令话题（Vehicle Command Control Topic）。除算法部分外，通过ROS2 Rviz的可视化配置仿真环境。
图11展示了在Autoware提供的仿真器和可视化工具Rviz中，将点云地图和矢量地图应用于系统验证的场景。在矢量地图中，绿色的Lanelet2组件表示车辆可行驶的路线，计算到目的地的最短距离并以绿色显示预估路线。图中，预估路线当前显示为绿色线条，全局路径（Global Path）以浅绿色显示，基于当前车辆位置的可行路线以深绿色显示。可通过二维位姿估计（2D Pose Estimation）按钮设置车辆的初始位置，通过二维目标位姿（2D Goal Pose）按钮设置车辆的目的地。
图11：带有3D点云与矢量地图的Autoware模拟器
4.3. 系统验证
图12展示了整个系统的仿真过程。左上角终端为运动学状态订阅者（Kinematic State Subscriber），右上角终端为车辆命令发布者（Vehicle Command Publisher），下方终端为自适应AUTOSAR平台，图右侧为用于可视化Autoware仿真的Rviz界面。
图13展示了轨迹和路径随时间的变化。自适应AUTOSAR平台接收ROS2随时间传输的虚拟里程计信息，并持续向目的地行驶，车辆的路径也相应地持续计算和更新。这表明ROS2与自适应AUTOSAR平台正在协同工作并实时交换数据。（为满足Autoware的需求，里程计数据应在20毫秒内传输；为匹配Autoware的周期，车辆控制命令应在50毫秒内传输。）
图14展示了仿真过程中数据交换的终端输出。图左上角为运动学状态订阅者，显示数据交换过程：接收来自自适应AUTOSAR平台的车辆位置、姿态、线速度和角速度，将其转换为ROS2消息并发布。如终端1所示，它接收包含车辆x、y、z位置、x、y、z、w姿态以及线速度和角速度的数据包，并解析负载以生成结果。
图右上角为车辆命令发布者，接收来自Autoware的车辆控制命令话题（Vehicle Control Command Topic）并发送至自适应AUTOSAR平台。如终端2所示，它捕获控制命令话题中包含的转向轮角度、旋转速率、速度、加速度和加加速度信息，然后发送数据包。
图下方为自适应AUTOSAR平台，通过ROS2桥接器与Autoware自动驾驶软件进行数据传输。终端3显示该平台发送封装在RPC响应负载（RPC Response Payload）中的里程计数据，并通过请求负载（Request Payload）接收车辆命令数据包。RPC处理器解析这些数据包，以双精度（double）格式显示转向角、旋转速率、速度、加速度和加加速度信息，同时展示了从虚拟里程计数据（Odometry Dummy Data）中获取当前位置信息、序列化该信息并在响应负载（Response Payload）中传输的过程。
图14:自适应AUTOSAR平台与ROS2 SOME/IP桥接工具的终端界面
表7记录了场景中传输的两种类型数据的详细信息，基于3分钟的驾驶过程进行测量。延迟时间的测量从数据生成开始，经过序列化、通过ROS2-SOME/IP桥接器传输，直至数据包转换为可用数据格式为止。从自适应 AUTOSAR 平台传输至运动学状态订阅者的里程计数据与Autoware自动驾驶平台要求的50赫兹（20毫秒）传输周期保持一致，平均延迟时间和峰值延迟时间分别记录为10.95毫秒和13.45毫秒。这些延迟水平显著低于20毫秒的周期，表明其足以满足本研究提出的自动驾驶平台的使用需求。从车辆命令发布者传输至自适应 AUTOSAR 平台的数据延迟相对于周期也非常低，证明其适用于本研究描述的自动驾驶平台。
表7:系统仿真中数据传输的平均延迟时间和峰值延迟时间分析
本研究构建了一种通过基于以太网的SOME/IP协议实现自适应AUTOSAR与ROS2互联的架构，并展示了仿真结果。研究表明，原本在不同领域开展研究的基于ROS2的自动驾驶与基于自适应AUTOSAR的车辆架构之间的连接是可行的。自适应AUTOSAR平台的车辆位置信息通过SOME/IP协议传输至ROS2桥接器节点，转换为自动驾驶系统可订阅的ROS2话题。此外，ROS2平台并非仅进行单向数据传输，而是利用接收的数据执行自动驾驶所需的感知、判断和控制，并通过ROS2桥接器将结果传输至自适应AUTOSAR平台。
利用该架构，各类基于ROS2正在开发的机器人系统、传感器驱动程序和传感器处理技术，以及开源社区中现有的各类软件，都可在车辆中实现。这对于快速原型设计也非常有用，因为车辆开发所需的测试和各类传感器的使用可在ROS2平台上进行——ROS2平台已具备众多驱动程序和传感器处理算法，无需在自适应AUTOSAR平台上重新开发。此外，激光雷达和视觉相关的机器学习目标检测与识别技术已有开源项目正在积极研究并应用于自动驾驶，这将有助于实现更先进的自动驾驶功能。由于采用SOME/IP进行连接，该架构不仅可与自适应AUTOSAR协同工作，还能与当前汽车行业为保障安全而持续使用的经典AUTOSAR兼容。这意味着它能快速适应现有汽车行业，且由于其硬件要求低于其他通信协议，可实现低成本部署。此外，随着ROS2融入汽车行业的研究不断推进，以及为满足安全标准所做的努力，该架构有望超越测试和原型设计阶段，充分利用ROS2和自适应AUTOSAR的优势，应用于实际车辆。
本研究的局限性和未来发展挑战可总结如下：
1.本研究使用的自适应AUTOSAR平台是一个部分满足AUTOSAR标准的开源平台，并非实际汽车行业中使用的软件。本研究重点关注的SOME/IP协议虽符合AUTOSAR标准并在ara::com中实现，但在实际车辆中，该开源平台未实现的各类其他因素可能导致意外冲突，因此需要开展更多的测试和研究。
2.本研究的验证仅通过仿真进行。当为实际设备集成ROS2和自适应AUTOSAR平台以实现自动驾驶时，应考虑计算能力等硬件约束。
3.本研究未深入考虑网络拓扑选择或流量优化，仅专注于通过SOME/IP协议实现和验证自适应AUTOSAR与ROS2之间的互操作性。在实际通信环境中，应进一步考虑更合适的服务质量（QoS）设置或流量优化方案。
通过本研究及后续的扩展研究，汽车行业与在不同领域发展的自动驾驶技术将实现融合。最终，ROS2平台与自适应AUTOSAR平台将相互补充，有助于缩短开发过程中的测试和原型设计时间，推动自动驾驶技术的快速发展，并有望创造更优越的交通环境——摆脱传统交通拥堵，减少能源消耗和排放等交通领域的负面影响。
免责声明：文中观点仅供分享交流，文章版权及解释权归原作者及发布单位所有，如涉及版权等问题，请您联系TechApe@yeah.net告知，我们会在第一时间做出处理。
