2022年8月5日，在由盖世汽车和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之间的互操作性包括两层含义:相互通信和算法迁移。这两种场景都有实际的应用需求。关于如何设计架构，我们认为基于模型的设计可以实现单个设计和多个部署，重用现有的知识和模型可以降低不同平台迁移的风险，自动化也有助于提高效率和减少错误。
我今天的演讲到此结束。谢谢大家！
郑重声明：此文内容为本网站转载企业宣传资讯，目的在于传播更多信息，与本站立场无关。仅供读者参考，并请自行核实相关内容。
