环球信息:开发可与ROS2和DDS交互的AUTOSAR Adaptive分布式系统

2022年8月5日，由盖世汽车、AUTOSAR组织联合主办的2022第三届软件定义汽车论坛暨AUTOSAR中国日活动中，MathWorks资深应用工程师龚小平聚焦基于“单次设计、多种部署”思路，从ROS2和DDS的算法迁移、AP与CP的互相通信两个案例切入，龚小平对如何开发可与ROS2和DDS交互的AUTOSAR Adaptive分布式系统进行了详尽介绍。

MathWorks资深应用工程师龚小平图片来源：盖世汽车

以下为演讲内容整理：

【资料图】

AUTOSAR与非AUTOSAR应用之间的互操作性

图片来源：MathWorks龚小平

首先介绍一下互操作性的概念。自从AUTOSARAP平台引入汽车行业以来，AP就包括了很多面向服务的协议，比如SOME/IP、DDS和ROS2等。除了AP以外，车辆上还包括CP平台、车规级的Linux平台等其他平台。同一车辆中，不同平台的软件之间都往往需要互相产生通信，这便是互操作性概念的第一层含义。

另一方面，此前业内在开发自动驾驶时通常基于生态系统相对成熟的ROS系统。然而当开发走到成熟阶段，准备走向量产时，却会发现由于ROS并非专为汽车行业所开发，能否满足汽车功能安全、信息安全，这块大家心里没有底。

因此，将基于ROS开发的系统迁移到AP上，然后利用AP的中间件实现量产的方案，这便是互操作性概念的第二层含义。

为避免人工介入带来的误失和效率低下，实现算法迁移的理想方式是通过自动化。简而言之，进行应用互操作的原因，首先是通信的需要，第二是算法迁移的需要。

图片来源：MathWorks龚小平

那么如何设计出能够满足互操作性的软件架构，来实现兼容性？

虽然ROS2、DDS、AUTOSAR都是中间件，但三者还是有所不同，如ROS2的数据定义、类型、管理方式都与后两者不同，ROS2会采用msg格式，DDS会用接口描述语言，AUTOSAR则会用到ARXML文件。此外，不同中间件的实现对命名（如“/”的使用）也有不同的限制。

由于设计背景不同，这三个中间件之间的QoS质量策略也有所不同。ROS2里的质量策略较简单，包括消息的历史、深度和可靠性，DDS的质量策略则多达几十种，而AUTOSAR更多是把质量相关的策略分在更低的层面来做。

不同中间件之间的差异就要求我们在设计异构系统时，需考虑如何保持定义的一致性，以使开发者专注于设计，而不是关注名称、数据定义和QoS等与功能无关的细节，这是我们想给大家解决的问题。

面向不同平台部署的基于模型设计

这里简单解释一下，AP里有DDS，这里DDS看起来又是并列的，所以会有点混乱，我们可以称为大DDS和小DDS，大DDS和AP一样是一套完整的协议，小DDS主要是DDS的通信层协议。

图片来源：MathWorks龚小平

解决方案是用上图的方案来做算法承载。无论需要什么中间件，只要将模型作为算法为承载，它的开发方法、验证方法、测试方法都是一样的。在算法上再封装一层面向中间件的接口，就相当于实现了核心算法和中间件接口的剥离，可以实现单次设计和多种部署。这是我们的总体上的解决方案，用于解决前文提到的如何设计软件架构，实现互操作性的问题。

案例1:通过DDS网络实现自适应AUTOSAR、DDS和ROS2的互操作

图片来源：MathWorks龚小平

第一个案例是通过DDS网络来实现AUTOSAR和ROS2的互操作，它同时实现了通信和算法迁移两项互操作。

这是我们软件中自带的自动泊车案例。这一案例以ROS2平台原型为起点，有四个独立的节点，分别是行为规划、路径规划、控制器和车辆仿真，不同节点之间会相互交付数据。

我们希望创建一个含多种节点的异构系统，把行为模型自动化地变成AUTOSARAP的模型，然后把控制器模型变成DDS的模型，保留路径规划和车辆仿真。做完算法迁移后将这一ROS2模型部署到不同中间件平台，并观察是否能保持正常通信。

下面有一段录像，我会和大家解释一下大概的路线。

报告内录屏截图图片来源：MathWorks龚小平

通过对原始模型进行改造，ROS2系统中控制器模型的算法便可以迁移至DDS平台，行为规划模型也将被改造成AP的模型。且在后台通过使用一些特定工具，便能以自动化的方式完成模块替换和迁移。

报告内录屏截图图片来源：MathWorks龚小平

这是转换后得到的两个模型，一个是中间的过程模型，另一个是AP模型。最终得到的四个模型将进入部署阶段，可以把AP和DDS的模型编译成可执行文件后启动，并和另外两个节点进行联合仿真。这就相当于实现了算法迁移工作，并达成互相通信的效果。

图片来源：MathWorks龚小平

总结以上，这一案例采用了增量式异构系统部署的方法，将ROS2模型迁移到不同的中间件平台。路径是首先ROS2转化为DDS再转化成AP，也可以直接从ROS2转化成AP。从这一过程来看，Simulink作为数据转换的桥梁，从通用平台生成不同中间件的相关项。

案例2:采用SOME/IP协议实现CP和AP的互操作

图片来源：MathWorks龚小平

大家都知道CP和AP不是互相替代的关系，它们会在车辆上长期共存，长期共存就会有通信需要，其中一种方式就是通过SOME/IP改造CP，实现与AP的通讯。

图片来源：MathWorks龚小平

这是大概的架构。大家都知道AP平台中有事件、方法、字段，每种都有各自的建模方式。对于CP来说，我们需要用模式请求、模式切换来对你的服务发现和服务提供以及事件订阅进行建模。仅仅是在应用层进行改造还不够，还需要和底层的BSW和服务发现模块一起做配合，共同实现事件的收发。

图片来源：MathWorks龚小平

AP端相对比较简单。如果用AP建一个事件，大部分工作是由ara::com实现。在做AP建模时，只需要从Simulink中找到事件的收发库，将其添加到相应的端口就完成了事件的建模。和CP建模相比，可以看到AP大大简化了建模的过程。从AP应用可以直接生成C++的代码，也会有服务的发现、订阅自动生成。

图片来源：MathWorks龚小平

验证CP和AP之间的通信，需要通过概念验证框架。分为三步，第一步是在CP中搭建波形发生服务器，第二部分是在AP里同时搭建客户端和服务器，在其中进行自通信，第三步是用CP的服务器加上AP客户端，通过以太网实现对接，验证能否成功通信。

图片来源：MathWorks龚小平

第一步CP服务器实现，采用自上而下的方法，首先采用架构设计工具来建立服务器的框架，再导入Simulink平台后填入算法，自动生成代码。

图片来源：MathWorks龚小平

接下来对CP中搭建的服务器进行验证，这会用到CANoe系统，把生成的代码和库一起编译成dll文件，作为节点运行起来，并基于CANoe进行测试。若波形探测器能观测到信号，便可视作波形发生服务器在CP中已实现。

图片来源：MathWorks龚小平

第二步需要在AP里独立地建一个客户端和服务器。分别将算法填入服务器和客户端，再各自生成C++的AP代码，随后集成自动生成的C++代码到AP平台进行IPC测试。

图片来源：MathWorks龚小平

这是SOME/IP的进程，先启动它，再启动服务器，它会不停地往外发送周期性的数据。如果客户端能按照顺序接入服务器，那它们就可以通过SOME/IP建立通讯。

图片来源：MathWorks龚小平

第三步是要把CP和AP连接起来。CP通过CANoe来模拟，AP在虚拟机里运行，通过以太网将两者的IP地址连接起来进行测试，最终证明AP和CP之间实现了通讯。

总结以上，AUTOSAR和非AUTOSAR之间，或者说CP和AP之间的互操作包括互相通信和算法迁移两层含义，这两种场景都有实际应用需求。关于如何设计架构，我们认为基于模型设计可以实现单次设计，多次部署，且重用现有的知识和模型能降低不同平台迁移的风险，自动化方式也有助于提高效率、减少错误。

我今天的演讲就到此结束，谢谢大家！

（以上内容来自MathWorks资深应用工程师龚小平于2022年8月5日由盖世汽车、AUTOSAR组织联合主办的2022第三届软件定义汽车论坛暨AUTOSAR中国日发表的《开发可与ROS2和DDS交互的AUTOSAR Adaptive分布式系统》主题演讲。）