开发可与ROS2和DDS交互的AUTOSARAdaptive分布式系统

日前，在由盖世汽车和AUTOSAR联合主办的2022第三届软件定义汽车论坛暨AUTOSAR中国日上，MathWorks高级应用工程师龚小平重点阐述了单一设计，多重部署的思想龚小平从ROS2和DDS的算法移植和AP与CP的通信两个案例出发，详细介绍了如何开发一个可以与ROS2和DDS交互的AUTOSAR自适应分布式系统

组织以下演讲内容:

AUTOSAR和非AUTOSAR应用程序之间的互操作性

首先，介绍互操作性的概念自从AUTOSARAP平台被引入汽车行业以来，AP已经包含了许多面向服务的协议，如SOME/IP，DDS和ROS2除AP外，车辆还包括其他平台如CP平台，车辆监管级Linux平台等在同一辆车上，不同平台的软件往往需要相互通信，这是互操作性概念的第一层含义

另一方面，自动驾驶在行业发展之前，通常是基于生态系统相对成熟的ROS系统但是当开发已经到了成熟阶段，准备量产的时候，我们就会发现，由于ROS并不是专门针对汽车行业开发的，所以对于是否能满足汽车功能和信息的安全性，大家心里都没有底

所以把基于ROS开发的系统迁移到AP，然后利用AP的中间件实现量产，这就是互操作概念的第二层含义。

为了避免人工干预带来的错误和低效，实现算法迁移的理想方式是通过自动化简而言之，应用互操作的原因首先是通信的需要，其次是算法迁移的需要

那么如何设计一个能够满足互操作性的软件架构来实现兼容性呢。

ROS2，DDS，AUTOSAR虽然都是中间件，但还是有区别的例如，ROS2在数据定义，类型和管理上都与后两者不同ROS2将采用msg格式，DDS将使用接口描述语言，AUTOSAR将使用ARXML文件此外，不同的中间件实现对命名有不同的限制

由于设计背景不同，三个中间件之间的QoS质量策略也不同ROS2中的质量策略相对简单，包括消息的历史，深度和可靠性，而DDS中有几十种质量策略，而AUTOSAR大多将质量相关的策略划分为较低的级别

不同中间件之间的差异要求我们在设计异构系统时考虑如何保持定义的一致性，让开发人员专注于设计，而不是关注名称，数据定义，QoS等与功能无关的细节这是我们想为您解决的问题

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

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

解决方案是使用上面所示的方案作为算法载体不管需要什么中间件，只要把模型作为算法，它的开发方法，验证方法，测试方法都是一样的在算法上给中间件封装一层接口，相当于核心算法和中间件接口的分离，可以实现单个设计，多个部署这是我们的整体解决方案，用来解决前面提到的如何设计软件架构，实现互操作的问题

案例1:通过DDS网络实现adaptive AUTOSAR，DDS和ROS2的互操作

第一种情况是通过DDS网络实现AUTOSAR和ROS2的互操作，同时实现通信和算法移植的互操作。

这是我们软件附带的自动停车箱本案例基于ROS2平台的原型有四个独立的节点，即行为规划，路径规划，控制器和车辆仿真不同的节点将相互传递数据

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

下面有一个视频，我给大家讲解一下大概的路线。

通过对原模型的改造，可以将ROS2系统中控制器模型的算法移植到DDS平台上，将行为规划模型转化为AP模型并且通过在后台使用一些特定的工具，可以自动完成模块替换和迁移

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

综上所述，本案例采用增量式异构系统部署的方法，将ROS2模型迁移到不同的中间件平台路径是先把ROS2转换成DDS再转换成AP，或者直接从ROS2转换成AP从这个过程中，Simulink作为数据转换的桥梁，从一个公共平台生成不同中间件的相关项目

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

众所周知，CP和AP并不是相互替代的他们会在车内长期共存，长期共存会有交流需求方法之一是通过SOME/IP对CP进行转换，实现与AP的通信

大致结构是这样的众所周知，AP平台有事件，方法，字段，各有各的建模方法对于CP，我们需要通过模式请求和模式切换对您的服务发现，服务提供和事件订阅进行建模仅仅改造应用层是不够的，还要配合底层的BSW和服务发现模块实现事件的发送和接收

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

要验证CP和AP之间的通信，需要通过概念验证框架它分为三个步骤第一步是在CP中设置波形生成服务器，第二步是在AP中同时设置客户端和服务器，并进行自通信第三步，使用CP的服务器和AP的客户端通过以太网实现对接，验证通信是否能成功

第一步是CP服务器的实现，采用自顶向下的方法首先利用架构设计工具建立服务器的框架，然后导入Simulink平台后填充算法，自动生成代码

接下来验证CP内置的服务器，它会使用CANoe系统，将生成的代码和库编译成dll文件，作为节点运行，基于CANoe进行测试如果波形检测器可以观察到信号，则可以认为波形生成服务器已经在CP中实现

第二步是在AP中独立构建客户端和服务器将算法分别填充到服务器端和客户端，然后分别生成C++的AP代码，再将自动生成的C++代码集成到AP平台进行IPC测试

这是一些/IP的过程先启动它，再启动服务器，它会不断发出周期性的数据如果客户端可以按顺序访问服务器，它们就可以通过一些/IP建立通信

第三步，连接CP和AP通过对CP CANoe的模拟，AP运行在虚拟机中，通过以太网连接两者的IP地址进行测试，最终证明实现了AP与CP的通信

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

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