背景介绍
在汽车行业，AUTOSAR是一个由汽车原始设备制造商（OEM）、供应商和其他行业成员组成的国际联盟，他们于2003年发布了第一个参考架构AUTOSAR Classic，它的重点不在于独立于底层硬件的动态应用，但是随着SOA和自动驾驶的日益重要，2018年发布的第二个标准Adaptive AUTOSAR则解决了这些需求。
然而汽车行业并不是第一个面临向动态和灵活的通信模式转变的行业，在物理系统和机器人技术的环境中，也发生了类似的演变，在这个背景下，广泛使用的ROS1（一套开源的库和工具集，用于软件架构开发）无法满足实时性、安全性和跨平台互操作性的需求，其继任者ROS2解决了这些缺点，并实现了面向服务的通信。ROS2在研究环境中被广泛使用，用于实现软件封装和通信，也在汽车电气/电子架构的背景下得到了应用。现在甚至有经过认证的解决方案，满足电气和/或电子系统的功能安全标准（ISO26262）和必要的汽车安全完整性级别（ASIL），关于ADAS功能和高度连接的车辆背景下的面向服务的架构（SOAs），仍有许多问题有待解决。
在这个背景下，这篇文章结合以下两篇文献：
Jacqueline Henle， Martin Stoffel. Architecture platforms for future vehicles: a comparison of ROS2 and Adaptive AUTOSAR
Apex.AI report :Adaptive Autosar and ROS 2
比较了ROS2和Adaptive AUTOSAR，并研究了它们在汽车电气/电子架构中的适应性如图所示：
基于Adaptive AUTOSAR标准化的架构比较了ROS2的相似之处和差异，下面的比较旨在确定它们的优点和缺点，使用标准的原因以及它们对现代车辆的未来就绪电气/电子架构的适用性。
前言
自适应AUTOSAR规范和ROS2两者的关键区别在于ROS2采用“先编码，再规范”的方法，因为ROS在机器人领域已经使用和验证了12年，自适应AUTOSAR部分是从零开始编写的，部分采用了经过验证的技术，如SOME/IP3、DLT4和UDS5，自适应AUTOSAR遵循“先规范，再生成代码”的方法。
在大型社区和数据记录、回放、可视化和调试等工具方面，ROS2表现出色，它还可以与其他语言（如Python和Java）进行绑定，ROS2利用常见的开源工具，而不是由各个自适应AUTOSAR供应商提供的工具，因此用户群规模较小，自适应AUTOSAR使用面向服务的SOME/IP，而ROS2使用面向数据的DDS，前者只能在UDP和TCP之间切换，而后者具有QoS（服务质量）。由于DDS的存在，ROS2中的数据传输非常高效和快速，这得益于共享内存（SHM）和零拷贝实现。
ROS2版本F于2020年6月作为第二个长期支持版本发布，目前尚不清楚个别自适应AUTOSAR实现的进展情况以及它们是否基于最新的规范（19.03），据了解大多数实现是基于18.03规范的。另一方面，自适应AUTOSAR规范在软件更新和配置管理以及DEXT诊断管理方面优于ROS2，两种技术在现代C++方面都有好处和挑战，最大的挑战包括：
1. 标准异常处理
2. 静态容器（字符串、向量、映射）
3. 内存管理
目前最好的总结是：自适应AUTOSAR在与现有车内基础设施的兼容性方面表现出色，而ROS2在应用程序开发方面非常出色，理想情况下，两种技术都能在生产中共存。
什么是ROS2
ROS框架是一个由软件工具、库、协议和API组成的集合，旨在简化为复杂的多传感器、多执行器系统开发软件的任务。在大多数情况下，机器人框架的使用决定了开发软件的一般架构原则。例如软件是集中式还是分散式，实时还是非实时等，关键组成部分是中间件，它是将机器人框架的众多组件粘合在一起的关键，中间件的最基本任务是提供自主车辆中软件节点之间的通信基础设施。ROS框架的典型用例是提供系统的上层（软件）和低层（硬件）组件之间的基本接口。这些接口和组件包括各种操作系统（OS）特定的驱动程序，单个开发人员开发这些驱动程序可能需要很长时间。ROS2主要由Open Robotics和ROS2技术指导委员会开发，它拥有数千个用户，并且被数百家自动驾驶和机器人公司使用。ROS2的架构如下图所示：
什么是Adaptive AUTOSAR
Adaptive AUTOSAR是一个官方定义的术语，将其描述为“用于自适应应用程序（ARA）的AUTOSAR运行时。提供两种类型的接口，即服务和API，该平台由功能集群组成，这些功能集群又分组在服务中，并且构成了自适应AUTOSAR基础”。实际上，它是另一个机器人框架，由以下所称的功能集群组成：该框架的规范由Autosar联盟开发。然后由Elektrobit、Vector、ETAS、Mathworks、Aubass等公司进行实际实现，开发工作由联盟成员完成，只有规范是公开发布的，Adaptive Autosar基于用于在单核微控制器上编程应用程序的经典Autosar。
面向服务的架构及其对架构平台的影响
汽车的电子/电气（E/E）架构作为一个系统，包括软件（SW）和硬件（HW）组件以及机械部件。传统的分布式架构的特点是HW和SW紧密耦合在许多电控单元（ECU）上。相反面向服务的架构使应用软件和执行硬件相互独立，为了实现这种松耦合的架构，操作系统（OS）和中间件起着关键作用。中间件层主要负责ECU之间的通信，因此，中间件的要求包括在整个车辆架构内或与云和后端基础设施进行抽象和虚拟化通信的执行，这些系统组件之间的通信在系统开发期间可能是未知的，因此，在互连系统中，通信是动态的，需要在运行时灵活地建立链接，在连接车辆中产生的大量数据和面向服务的架构导致了新协议在E/E架构中的集成。作为自适应AUTOSAR规范中指定的动态通信的汽车参考架构，将功能应用程序和一个符合POSIX标准的操作系统与名为自适应应用程序运行环境（ARA）的模块化层分开。参见下图。
自适应AUTOSAR的结构
在ARA中，定义了接口和服务，用于指定操作系统访问和一个通信中间件，以基于以太网实现面向服务的架构。自适应AUTOSAR的首个版本中，指定了可扩展的面向服务的IP中间件（SOME/IP）作为相应的标准化架构的中间件协议。除了面向汽车的中间件解决方案之外，DDS是一个非汽车特定的替代方案，自适应AUTOSAR从18-10版本开始包括了DDS，而ROS2从一开始就是基于DDS构建的，没有提供其他中间件， DDS的集成是一个例子，非行业特定的中间件解决方案丰富了汽车标准自适应AUTOSAR。
ROS2的结构
在这一发展的同时，源于机器人应用的ROS2进入了汽车行业，与自适应AUTOSAR相比，ROS2是开源的不需要会员资格或许可费用，ROS社区提供的未经调整的实现未经官方认证，不适用于车辆系统的实时应用。然而，最近由汽车软件公司开发的基于ROS2的商业实时操作系统（RTOS）已获得ASIL-D应用的认证， 受到这些发展的推动，我们对ROS2的架构与基于自适应AUTOSAR模块化结构的比较进行了如下比较。
自适应AUTOSAR和ROS2提供了分离执行硬件和应用程序的层次结构，比较这些平台的整体结构，可以看到自适应AUTOSAR应用程序编程接口（API）的命名给人一种预期功能的印象，ROS2的层次结构在同样的程度上并不好解释，因此我们需要对ROS2的Client Library和Abstract DDS Layer的范围和内容与自适应AUTOSAR架构进行比较。由于自适应AUTOSAR是汽车行业的标准，我们想要评估ROS2在该行业中的适用性，将基于自适应AUTOSAR的功能和核心优势来比较这两个平台。自适应AUTOSAR架构的核心是包含自适应API的ARA由功能集提供。功能集被分类为自适应平台基础或自适应平台服务，为访问ARA和平台内应用程序提供API，它们从应用程序和网络的角度描述了软件平台的行为，但不进一步指定软件设计，自适应应用程序可以相互提供服务或与非平台服务进行交互。
自适应AUTOSAR架构和ROS2差异
通信管理（Communication Management）
在自适应AUTOSAR中，应用程序的通信和信息共享由通信管理（CM）API包组织，通过这种方式实现和监控平台各级之间的面向服务的通信，CM还提供机内和机间通信。API指定了SOME/IP作为实现的中间件协议，DDS在18-10版本中添加了。虽然DDS和SOME/IP具有共同的特性，但也存在关键差异。
SOME/IP实现了基于对象的面向服务的通信，订阅者的服务类在开发过程中需要预先定义，因此在一定程度上是静态的，相比之下，DDS通过发送方和接收方的动态运行时发现实现了动态运行时发现，并由于不需要静态服务规范，提供了更多的互操作性和灵活性。DDS基于实时传输协议（RTPS）实现发布-订阅功能，通过提供高级数据管理功能来利用该传输协议。此外，还可以添加其他协议。在SOME/IP中，可以通过使用用户数据报协议（UDP）或传输控制协议（TCP）向所有订阅者广播发布信息。SOME/IP中的事件驱动通信可以提供当前快照的数据，基于字段的通信可以传输带有读写权限和接收方数据历史记录的数据。另一个特性是基于方法的远程过程调用（RPC），使客户端能够根据请求启动特定的函数，并返回带有数据的消息。DDS定义了三种通信方式：消息可以根据其主题发送给订阅者，或者客户端可以调用一个服务并将其传递给接收方。第三种模式结合了这两种方法：一个目标被发布，触发周期性地将反馈发送给接收方。
在自适应AUTOSAR中，通信路径和服务定义可以在开发过程中、系统启动时或运行时动态建立。此外，自适应AUTOSAR还指定了基于信号的网络绑定，以允许将相应通信应用程序转换为面向服务的通信应用程序。
ROS2定义了一个名为rmw的中间件API，以实现与RTPS组合的DDS的应用程序无关集成，作为唯一的中间件框架解决方案，自适应AUTOSAR和ROS2都提供了零拷贝能力和在汽车行业中标准化的进程间通信。此外，ROS2中的通信是通过节点进行组织的，每个节点为系统提供一个功能，发布-订阅通信以分散的方式实现，节点在没有中间主节点的情况下相互发现，与自适应AUTOSAR不同，ROS2中的节点需要在设计时进行集成，但服务发现仅在运行时发生。这是两个平台之间的一个关键区别，自适应AUTOSAR的CM使得在不需要动态通信的情况下可以减少开销。
执行管理（Execution Management）
自适应AUTOSAR中的API实现与平台和应用程序生命周期管理相关的功能，包括身份验证、应用程序的启动和关闭，EM与操作系统进行交互，在运行时调度应用程序，因此应用程序可以根据其优先级进行组织，执行清单规定了与EM相关的其他主题，它明确定义了为特定应用程序静态设置资源的可能性，以及通过通信从而控制资源分配。
ROS2中的执行管理是通过rcl API中的launch文件进行组织的，执行是通过执行器（Executors）实现的，该概念基于使用操作系统的线程来实现回调函数、执行定时器、服务服务器和动作服务器，以处理传入的消息和事件。虽然ROS2的标准执行器不能保证确定性，但可以进行调整优化以达到这个目标，然而这种调整目前只能在基于ROS2的商业解决方案中找到，而不是标准的开源实现的一部分。此外使用ROS2标准执行器会出现其他实时性和效率问题，因此，似乎在满足汽车行业的要求方面还有待进一步改进。
核心类型（Core Type）
核心类型API包定义了适用于自适应平台所有功能集群的基本要求，它包含了一个中央初始化函数，用于初始化ARA层中包含的所有共享库，建议为每个自适应应用程序调用该函数作为入口点，此外，它描述了错误处理，并区分错误、违规和损坏。错误是自适应函数的返回值，通常是由于输入数据引起的。违规是指自适应平台的内部状态，无法恢复。损坏是系统资源（如堆栈、堆或硬件）损坏的后果。预计对于应用程序开发人员而言，只会出现错误，因为违规或损坏可能表明系统环境中存在严重问题，如有故障的硬件。此外，核心类型API定义了自适应平台中常用的数据类型，平台类型包描述了标准类型，如整数、双精度浮点数或浮点数，而核心类型包定义了数组和向量等数据类型。此外，它还定义了在出现异常或错误时的返回数据类型。
与自适应AUTOSAR类似，ROS2的客户端库clcpp需要首先进行初始化，客户端库还包含错误的定义，例如无效的节点或主题名称、错误的函数参数或运行时错误。然而，并没有明确描述错误、违规或损坏之间的清晰分离。因此，无法确定哪个错误导致整个过程中止或抛出异常。
ROS2应用程序通常通过接口进行通信，可以是消息、服务或操作，接口包含多个字段，每个字段都有一个字段类型和字段名称，内置的字段类型包括布尔值、整数、字符、浮点数、双精度浮点数和字符串，它们可以用于定义静态、有界或无界动态数组，或有界字符串，这些类型的组合可以用于创建自定义消息，这方面与自适应AUTOSAR类似。
Representational State Transfer（RESTful）
虽然CM API包涵盖了自适应应用之间的面向服务的通信，但是Representational State Transfer（RESTful）API包提供了基于Web服务的通信选项，与移动领域中的RESTful服务不经常暴露资源限制的情况不同，它需要针对汽车应用进行优化，以提供低延迟和确定性的内存和处理时间。CM包中的API被精确地定义为字节级别，因此大部分是处理静态数据，RESTful API通常以异步处理的方式处理动态数据，结合统一资源标识符（URI）。在实现RESTful API方面，目前尚未找到ROS2的专用包。然而，对于ROS版本Indigo或Kinetic，存在名为ROSTful的包，我们不能预测是否以及何时将能够其移植为ROS2包。在ROS2中实现异步数据处理的另一种替代方法是使用Action，客户端可以调用Action，类似于远程过程调用，并传递多个数据参数，然后，Action处理数据并在完成后执行回调，尽管Action与Adaptive AUTOSAR中的RESTful API类似，但它们并不完全相同，而且ROS2并不完全满足RESTful API的特性。
持久性（Persistency）
Adaptive AUTOSAR明确指定了在启动和点火之后信息的持久性，除了使用易失性存储。另一方面，ROS2在数据持久性方面受限于底层DDS实现，Cyclone DDS表示在0.9版本之前将不使用瞬态和持久性内存，当前的0.8.2版本仅支持数据的易失性存储，因此可以认为它部分满足了Adaptive AUTOSAR持久性功能的要求。
时间同步（Time-Synchronisation）
在时间同步方面，Adaptive AUTOSAR和ROS2都采用类似的方法，在Adaptive AUTOSAR中，主时钟和从时钟进行同步，通常使用网络时间协议（NTP）进行同步，但精确时间协议（PTP）是实现更高精度的替代方案， 在ROS2中，消息也可以相互同步，并且有不同的时钟可供选择，相同的PTP是实现最高精度的解决方案。
平台状态管理（ Platform Health Management）
Adaptive AUTOSAR监测其应用程序的时间约束、逻辑程序流以及平台状态，当检测到错误时，它通知状态管理模块，由状态管理模块确定错误处理方法，此外平台健康管理与硬件看门狗进行交互，在发生严重故障时可以触发看门狗响应，而仅向状态管理模块发出通知是不足够的。然而，平台健康管理与其他功能集群之间的接口只具有信息性质，没有进行标准化。在ROS2中，默认情况下没有实现这些功能。然而根据ROS2的开源文档，可以实现平台健康管理。例如，可以使用记录功能，在发生错误时触发各种恢复例程，以实现此功能。
身份访问管理（Identity Access Management）
Adaptive AUTOSAR身份和访问管理（IAM）使用x.509证书，负责资源访问的身份验证和授权，IAM在ECU之间和ECU内部提供访问控制。ROS2也使用x.509证书在提供的DDS安全插件“DS:Access:Permission”中使用权限文件来实现访问控制。ROS2的访问控制和授权机制使用DDS实现的“DDS:Auth:PKI-DH”插件提供的公钥基础设施，两个平台的主要区别在于AUTOSAR提供了在ECU内部的自适应身份验证和授权，而ROS2在这方面没有明确表态，目前没有找到用于此目的的可用调整选项。
诊断（Diagnostics）
诊断API包描述了符合统一诊断服务（UDS）的实现，符合相应的ISO 14229-1标准。目前它提供了基于以太网的IP诊断（DoIP）层的功能，但预计将扩展以包括传统的汽车网络，如CAN 。ROS2不包含符合UDS的诊断功能，尽管官方的ROS2软件包索引文件夹中包含多个诊断软件包，但它们与UDS无关，因此不符合ISO 14229-1标准。
日志和跟踪（Log and Trace）
在Adaptive AUTOSAR中，日志和跟踪提供了用于记录和跟踪应用程序的API。生成的信息根据严重程度进行分类，并可以与不同案例（例如安全和安全性主题）关联起来，AUTOSAR联盟提供了用于表示日志信息的标准协议以及相应数据分析工具，对于ROS2，有可用于日志记录和跟踪的软件包。其中大部分不是二进制软件包的一部分，但可以根据需要进行集成。跟踪软件包可以记录运行时和执行数据、系统和组件行为以及其分析。还推荐使用用于跟踪文件的分析工具。ROS2的一个主要缺点是其日志记录功能不符合实时要求，而且某些日志条目的可信度存在问题。虽然不清楚这些问题是否也存在于Adaptive AUTOSAR中，但对于安全和可靠的E/E架构来说，这肯定是一个必要的要求。
加密技术（Cryptography）
在加密程序方面，Adaptive AUTOSAR平台定义了与加密堆栈"ara::sec::crypto"的接口，其中包括随机数生成、高级加密标准、非对称加密Rivest–Shamir–Adleman（RSA）、哈希函数、媒体访问控制地址（MAC）和密钥交换机制。AUTOSAR还支持处理加密对象，例如X.509证书。ROS2的安全功能基于DDS标准的安全插件，它称为"DDS:Crypto:AES-GCM-GMAC"，使用高级加密标准的Galois计数器模式，公钥基础设施处理加密、解密、签名和哈希。由于DDS的所有安全功能默认情况下都是禁用的，用户必须通过ROS2安全工具启用它们，Adaptive AUTOSAR和ROS2都提供了相同的功能，但在ROS2中需要手动激活。
状态管理（State Management）
状态管理接收来自其他Adaptive AUTOSAR平台应用程序（如平台健康管理、诊断管理、更新和配置管理以及网络管理）的事件。这些事件包括事件类型、优先级和应用程序标识作为状态管理器请求执行管理器进行状态转换的输入。例如，平台健康管理可以通过状态管理服务触发错误恢复，该服务请求执行管理器重新启动相应的功能，诊断管理可以请求将系统切换到不同的诊断状态或启动更新和配置管理以关闭系统部分，在诊断和更新过程中，状态管理将使用网络管理来保持网络在诊断或更新过程中的持续运行。
ROS2没有类似的诊断或更新功能，然而可以使用服务质量（Quality-of-Service，QoS）特性来实现对中断进程的恢复，通过将进程确定为不可用，可以启动恢复机制，然而，QoS选项是底层DDS实现的一部分，只是ROS2的间接特性。
更新和配置管理（Update and Configuration Management）
Adaptive AUTOSAR的更新和配置管理是处理更新请求、更新本身和软件修改的接口，它负责实现无线更新（OTA），并将安装和更新过程与软件组件的删除和跟踪记录结合起来以实现此目的。该服务类似于Linux的软件包管理器（如dpkg或Yellowdog Updater, Modified (YUM)），仅执行经授权的软件更新。它还可以实现特定变体的配置和功能验证，以及更新后的所有其他过程。在ROS2中有两个用于持续集成（CI）和持续开发的软件包，即构建工厂内的ROS2脚本和模板，由Open Robotics提供， Pull Request（PR）构建软件包会在发生PR时运行并测试软件包，它仅适用于Linux，且不能跨存储库工作。为弥补这些限制，还有CI构建软件包，与PR构建不同，它不会自动运行和测试，并且其测试活动不仅限于更新的组件，而是测试所有平台上的所有软件包。出于时间限制的原因，也可以限制测试范围。对于更新功能，软件包维护者必须不断进行软件包发布。总体而言，这个功能似乎与Adaptive AUTOSAR服务相似。
总结差异
上表展示了ROS2与Adaptive AUTOSAR API功能的能力摘要，然而，在这个背景下值得一提的是ROS和ROS2最初是作为机器人应用的解决方案开发的，从这个出发点出发，它现在也在现有的自动驾驶解决方案中使用。
ROS/ROS2之所以成功，原因之一可能是汽车工程师可能正在寻找替代AUTOSAR的解决方案，因为该平台的标准化内容非常庞大，遵守规范所需的工作量似乎很高，特别是对于缺乏AUTOSAR经验的开发人员来说。此外与标准的一致性所需的工作量与软件项目的规模不成比例地增加，ROS/ROS2解决方案似乎是有希望的替代方案，它们明确设计用于实现使用节点进行交互的功能，这些节点的松耦合性导致了模块化、可扩展性、可调整性，并实现了更快的开发。
此外ROS2还提供了多种简化应用程序开发任务的功能。一个例子是预定义的、专门用于机器人的消息类型，可以直接使用来实现节点内通信。此外，ROS2提供了强大的代码调试工具，可以记录、回放和可视化数据，例如，RQT-Graph可以显示节点之间的通信，从而自下而上推导出系统的逻辑架构。另一个例子是RVIZ，它可以可视化传感器数据和车辆在环境中的位置。 就平台的开发方式而言，它们都遵循基于模型的方法。在编码方面，Adaptive AUTOSAR平台定义了使用C++14作为标准的指南，以实现更简单的分布式系统结构，编码指南基于汽车行业现有的指南。ROS2的客户端库是用于确保API使用一致性和适用性的代码集，这些库使用户可以访问ROS2的概念来构建应用程序，有各种编程语言的客户端库可用。ROS2文档还提供了编码的样式指南，以支持实现一致产品的目标。
这两个平台之间的主要区别之一是AUTOSAR的标准不是开源的，要访问文档，需要成为由近300个组织组成的全球联盟的成员，这些组织也为标准的规范和评估做出贡献，需要支付许可费用，也没有免费提供AUTOSAR许可的工具。相比之下ROS库和相关文档是开源的，开发者社区提供了额外的包和代码库，可以进行个性化修改，这非常重要，因为AUTOSAR的另一个限制是文档质量较差。另一方面，也有基于ROS2的解决方案是不开源的，特别是最近获得认证的专门针对汽车的解决方案是不公开的，在这种情况下，可能无法充分享受与开源相关的好处，但汽车特定的适应性似乎是有益的， 如果ROS社区能够弥补表格I中所发现的最重要的差距，那么这里提到的优势可能使ROS从自动驾驶领域扩展到其他汽车领域，从而形成对于成熟的AUTOSAR标准的现实替代方案。
ROS2的其他关键优势
1. Adaptive Autosar组件是一个进程。在ROS2中组件是一个节点，一个进程可以有多个节点。
2. Adaptive Autosar仅在应用层使用C++，ROS2的原型也可以使用Python等其他语言编写。
3. Adaptive Autosar没有提供数据记录、回放、可视化或调试工具，特别是大规模数据记录似乎完全缺失。
4. Adaptive Autosar使用基于服务的SOME/IP，ROS2使用基于数据的DDS。前者只能在UDP和TCP之间切换，而后者具有QoS（服务质量）。
5. ROS2只有一个开源实现，有数千用户使用。Adaptive Autosar有多个闭源实现，它们在很大程度上彼此不兼容。
6. ROS2支持高性能的数据传输协议，如共享内存或零拷贝（通过RTI Connext Micro）。
7. ROS2包含设备驱动程序的参考实现，例如Velodyne VLP-16 HiRes。
8. ROS2提供了一些工具，如静态变换库、可认证数学库的部分功能以及用于主题同步的时间同步库。
结束语
在当前汽车架构开发挑战的背景下介绍了自适应AUTOSAR和ROS2的架构和内容，虽然基于许可的自适应平台专门针对汽车领域向面向服务架构的趋势进行了定制，而开源的ROS2最初是针对机器人应用的，从自适应AUTOSAR规定的层和API出发解释了ROS2架构与AUTOSAR平台的自适应功能集之间的对应程度，自适应AUTOSAR比ROS2更加标准化，还提供了开发过程的标准，它满足了行业内的互操作性和一致的规范，该平台在本质上满足了汽车的要求，特别是安全方面的要求。
虽然ROS2没有指定那么多的服务、API或过程标准，但社区提供了额外功能的软件包，正如表I的结论所指出的那样，ROS2可以完全满足自适应AUTOSAR的一些API和服务功能，虽然标准实现并不能提供所有与汽车相关的功能，但可以通过添加软件包和自定义设置进行调整，另一方面，自适应AUTOSAR具有部分由ROS2实现的特性，但并不清楚是否有额外的软件包来填补差距，另外，根据分析自适应AUTOSAR提供了一些API，而ROS2的实现无法满足这些API的要求，正如API的各个部分所描述的那样，这些差距有时可能是强制性的（例如网络管理），在其他情况下，这些差异与汽车要求更相关（例如诊断），基于ROS2的商业版本的安全认证表明，通过相应的调整和设计，它可以符合汽车面向服务架构的要求，这明确指的是通过重写开源实现的部分来增强实时能力和内存管理，与自适应AUTOSAR相比，新用户可以无障碍地开始使用ROS2进行架构开发。
参考文献
【1】Jacqueline Henle， Martin Stoffel. Architecture platforms for future vehicles: a comparison of ROS2 and Adaptive AUTOSAR
【2】Apex.AI report :Adaptive Autosar and ROS 2
联系客服
