余雪玮 赵熙俊 苏波

（中国北方车辆研究所，北京 100072）

主题词：异构 无人驾驶车辆 互操作性 标准 中间件

1 前言

目前，在无人驾驶车辆的异构性（在功能架构、编程语言、操作系统等方面的差异）逐渐扩大的同时，人们希望无人驾驶车辆能够完成复杂度更高的任务，而利用群体智能的集群任务模式是提高无人驾驶车辆灵活性与智能性的有效途径。综上，无人驾驶车辆多样性的发展趋势与集群任务的需求带来了异构无人驾驶车辆的互操作性问题。

GJB/Z 144A—2015《军事信息系统互操作性等级与评估》中定义互操作性为两个或两个以上的系统或应用之间交换信息并相互利用所交换信息的能力[1]。对无人驾驶车辆互操作性的研究将为开发统一的操控终端、跨域（海、陆、空）的互操作实现、车辆任务单元快速实时的无缝融合与接入等问题的解决提供基础，互操作能力是无人驾驶车辆间交流协作的保障，对未来所有无人系统的发展具有关键作用。

本文围绕面向异构无人驾驶车辆的互操作性问题，分析对比了目前主流的解决方案，选择了基于标准的中间件技术作为实现手段，基于自动发现、去中心化、松散耦合、支持一对多通信的原则，设计了面向异构无人驾驶车辆的互操作系统。系统包括基于互操作标准的互操作中间件以及兼容异构无人驾驶车辆（以基于机器人操作系统（Robot Operating System，ROS）[2]架构与4维实时控制系统（4D Real-time Control Systems，4D/RCS）架构[3]的异构车辆为例）的统一操控终端两部分，并在Gazebo仿真环境下进行了验证。

2 异构无人驾驶车辆集群对互操作系统的需求

面向异构无人驾驶车辆集群的互操作系统应满足对多种异构车辆的通用控制、不同单体数据的存储与处理、开放式体系的任务单元扩展与删减、多元异构传感器与执行单元的无缝接入与数据融合等互操作性需求。

如图1所示，将以上需求实例化，在该异构无人驾驶车辆集群系统中，有操控终端（Operator Control Unit，OCU）、异构的无人驾驶车辆A、B、C、D共5类单体。在互操作系统的支持下，这些在功能、结构、系统等方面异构的单体应能实现信息与控制指令的共享。例如，OCU可以控制任意无人驾驶车辆A、B、C、D，如改变其速度、航向、轨迹，或者获取侦察图像等。

图1 异构无人驾驶车辆集群对互操作系统的需求

3 互操作问题的解决方案

3.1 总体方案

解决互操作性问题的典型手段包括制定私有协议、制定互操作标准规范以及开发互操作中间件等[4-5]。在解决简单系统的互操作性问题时，常采用定制私有协议的解决方案，即在限定应用的情况下，针对某一特定的设备制定满足彼此互操作要求的协议。该方案比较灵活，但具有“一式一议”性，即对不同的设备每次均需临时设计，因此复用性差、适用范围小、效率低下。

解决私有协议复用性差的有效手段是制定并推广统一的公用标准规范，遵循统一的行业规范开展设计是互操作问题的根本解决方案，但地面无人驾驶车辆体系架构标准化进程的推进需要时间，顶层的规范只给出了基本的实现架构，欠缺对细节的具体设计，短期内标准还无法应用于实际设计工作[6]。

基于标准的中间件技术将标准进行二次封装，开放通用接口，实现了无人驾驶车辆之间的资源管理和网络通讯。这些中间件系统的普及形成了庞大的组件库，从而实现无人驾驶车辆新功能组件化的高效率开发[7]。基于标准的中间件技术是将标准逐步落地的有效方案，是私有协议向公有标准过渡的桥梁，本文将采用基于互操作标准的中间件技术作为解决异构无人驾驶车辆集群互操作问题的总体方案。

3.2 核心功能的实现

结合面向异构无人驾驶车辆集群的互操作系统的应用需求，提出自动发现、去中心化、松散耦合、支持一对多通信的原则[8]，并基于这些原则实现互操作系统所必需的运行时自动发现与异构模块间可通信两大核心功能，从而实现系统对异构平台的兼容性，提高系统的可扩展性。

3.2.1 运行时自动发现的功能

设想如图2所示的场景，消息产生方（例如异构无人驾驶车辆集群中的某单体车辆）A′、B′、C′分别产生类型1、类型2、类型3等3种类型的消息，消息请求方A、B、C分别请求类型2、类型1、类型3的消息。使同类型消息的产生方与请求方动态地互相发现，是实现异构无人驾驶车辆集群互操作系统中各单体交流信息的前提。

图2 基于中心化的消息配对机制

3.2.1.1 去中心化的动态发现机制

图2所示的是基于中心化的解决方案，即设立一个消息的存储与转发中心，由该中心根据消息自身的配对信息对消息进行分拣与转发。各单体不必关心中心的消息分发机制，但这种对中心的强依赖性降低了整个系统的容错性与抗毁性，一旦中心崩溃，消息分发机制将全部瘫痪。此外，消息的分拣基于消息本身携带的配对信息进行，但在异构无人驾驶车辆集群中，各单体往往是异构的，彼此的通信协议差别很大，配对信息的提取将十分复杂。

针对基于中心化的消息配对机制存在的两点问题，需要一种去中心化、配对信息规范化的解决方案。在图3所示的去中心化的动态发现架构中，基于中心化的消息配对机制中中心的功能被分布在各单体上，因此，异构无人驾驶车辆集群中的每个单体均高度自主，单体间处于平等地位，可实现彼此的自由连接，形成新的连接单元，为后续任务的执行提供保障。例如，图3中的每个单体都有消息配对功能，使得消息的请求方A、B、C与发送方B′、A′、C′得以自主配对，最后经由广播或组播等方式发现彼此，建立连接。

3.2.1.2 基于面向服务思想的动态发现机制

在紧耦合的系统中，不同应用程序的组件间的接口与功能紧密相连，当需要应用程序修改或变更时，接口的复用性很差，系统的整体架构就需要更改，紧耦合的架构无法保证系统的灵活升级，也无法满足建立统一的异构平台操控终端的需求。而对于松耦合的系统来说，接口与功能的实现方式（具体平台或应用）无关，实现方式的改变不会对系统的整体架构造成影响[9]。建立面向服务的架构是构造松耦合系统的重要思想。结构化信息标准促进组织（Organization for the Advancement of Structured Information Standards，OASIS）将面向服务的体系结构（Service Oriented Architecture，SOA）定义为“用于组织和利用不同所有权范围控制下的分布式系统的一个范式”，它是构造分布式系统应用程序的方法，将应用程序功能作为服务发送给最终用户或其他服务，采用开放标准，与软件资源进行交互并采用标准的表示方式[10]。这一思想很好地适应了地面无人集群互操作系统的需求。

图3 去中心化的动态发现机制

在图4所示的系统中，A是服务调用者（即用户），向服务的提供者请求某一服务，该服务可以由B1、B2、B3等异构平台以不同的方式实现，中间件负责将服务调用者与提供者的消息进行转化以符合同一输入、输出标准，从而实现调用者用统一的方式调用同一种服务的不同实现方式。

图4 面向服务的体系架构

在动态发现去中心化的基本架构中，发现功能将发送方产生的信息类型与接受方请求的信息类型进行匹配，将面向服务的思想引入后，发现用于匹配的条件将得到扩展，即信息类型扩展为服务类型。如图5所示，每个单体都具备发现功能这一项服务，该服务以广播或组播的形式，将自身拥有的服务、请求的服务以固定频率广播或组播。这样，在通信范围内的即使是异构的单体也能动态发现彼此，并建立相应的设备列表（发现设备的ID、权限信息、所拥有的服务、请求的服务等）。例如，图5所示场景中，A、B、C、A′、B′、C′分别代表异构的无人驾驶车辆单体，它们拥有发现等服务，利用组播/广播的形式，各单体间共享彼此的设备信息，并建立了能被发现的设备拥有的以及请求的服务的列表（LIST），根据列表可建立配对结果。

图5 基于面向服务思想的动态发现机制

3.2.2 异构模块间的通信功能

如图6所示，在面向服务的架构中，为了实现各系统、子系统、组件间的交流，需要传输服务作为沟通的桥梁，连接应用层服务与传输层服务。传输服务是互操作标准传输层的接口，通过抽象的双向通信模型屏蔽了特定的物理介质，可以通过特定的ID信息进行寻址，设置单播、系统内广播和全局广播等通信方式。

图6 传输层服务架构

在图7所示的基于面向服务思想的动态发现机制中，已经完成了单体B与单体C′间的动态发现，并建立了各单体拥有与请求服务的列表。为了完成消息的传输，引入传输服务。图7中，单体B中的传输服务负责采集其他服务产生的消息，并上传到物理传输层，随后下发到单体C′的传输服务。传输服务将进行信息的分拣，将不同的信息传递给需要的服务（假定消息类型1、2、3与服务5、6、7所需要的消息类型一一对应）。

图7 基于面向服务思想的传输机制

4 面向异构无人驾驶车辆的互操作系统的实现

4.1 实现手段

去中心化的面向服务的思想是解决异构无人驾驶车辆集群互操作性问题的有效思路，而基于标准的中间件技术是推广互操作规范的必要途径。现有的与互操作性相关的标准有：美军公布的提高陆军和海军陆战队的各种地面无人车辆及其有效载荷和外围设备之间通用性的无人地面车辆互操作性指导原则（Interoperability Profile，IOP）[11]；美国国防部于 1998年提出的无人系统联合架构（Joint Architecture for Unmanned Systems，JAUS）[12]，它是一种面向服务的开放式体系架构，基于分级式体系架构，提供了在无人系统间交换信息的标准，目的在于提高无人系统间的互操作能力。本文选择JAUS标准作为实现手段。

4.2 互操作能力的分层设计

JAUS将互操作能力划分为3个级别，图8～图10[13]分别为一级、二级、三级互操作模型。一级互操作能力指在子系统间使用JAUS消息进行信息交换（如图8中的操控者到无人系统），但每个子系统内部不受约束，这使得多个无人系统间可相互通信，或者一个OCU能够控制多个无人系统；二级互操作能力指节点间使用JAUS消息进行信息交换（如图9中的自动载荷到无人系统），但节点内部不受约束，这使得搭载于无人系统的计算机可被车辆、载荷等共享；三级互操作能力指组件间通过JAUS消息进行信息交换，可在无人系统的组件间（如图10中的无人系统内部JAUS的路点驱动服务到JAUS本体驱动服务）进行共享，提高了源代码的重用率。

图8 一级互操作模型

图9 二级互操作模型

图10 三级互操作模型

本文研究上述体系架构中互操作能力的各个层次，实现操控端与异构的无人驾驶车辆以及其间的各节点与组件间的互操作性。

4.3 整体架构设计

该系统的整体架构如图11所示，操控终端和基于ROS和RCS等其他架构的无人车通过基于JAUS标准的互操作中间件进行互联互通。对于控制终端，操控人员通过键盘、鼠标、摇杆等外设控制异构的无人驾驶车辆，其中互操作中间件是连接操控终端与无人驾驶车辆的桥梁。在各异构系统中，互操作中间件之间遵守互操作协议标准，从而实现消息交互。互操作中间件被封装在一个节点内，针对不同的异构系统的定制部分，将消息转化为各系统架构内的消息格式，因此该方式不会影响系统自身各节点间的通信。

4.4 具体模块的实现

按照上述的系统整体框架，软件设计分为2个部分：指挥控制端单元软件，包括软件界面设计，以及指挥控制单元端的互操作中间件设计；无人驾驶车辆端的互操作中间件设计。

图11 面向异构无人驾驶车辆的互操作系统整体架构

本系统中各异构车辆通过基于标准的互操作中间件连接，选择JAUS标准，JAUS++软件开发工具包（Soft⁃ware Development Kit，SDK）作为实现手段，互操作中间件的设计流程为：创建面向某一端的中间件的类A；在构造函数中初始化ID信息（系统号、子系统号、组件号）；在类A中根据需求创建不同组件a、b、c；为各组件添加所需要的服务（核心服务必须添加，其他服务按需添加，并可新建自定义的服务）；初始化组件与服务；功能函数的实现。

设计过程中根据需求为各组件添加服务十分关键，其中核心服务是实现互操作的基础，包括传输服务、事件服务、访问控制服务、管理服务、生存性服务、时间服务以及发现服务[14]。此外，JAUS标准中还定义了机动服务集[15]、扩展服务集等服务集[16]，可以根据需求添加。

5 仿真验证

本文提出的面向异构无人车辆的互操作系统主要包括兼容异构无人驾驶车辆（以ROS架构与RCS架构为例）的统一操控终端OCU以及基于互操作标准的互操作中间件（分别部署在OCU端与异构的无人驾驶车辆端）两部分。仿真主要测试本系统的各服务功能以及对异构无人驾驶车辆的兼容性，以证明该互操作系统可以实现组件级别的互操作能力。

5.1 Gazebo中仿真车辆的搭建

为了实现仿真结果的可视化，在ROS环境下的三维动态仿真软件Gazebo中建立仿真场景，Gazebo可以有效地模拟复杂室内外环境下的无人驾驶车辆群体，提供与常规游戏类似的高保真度的物理引擎、一套传感器和程序接口[17-18]。

Gazebo仿真模型搭建的关键点主要包括：建立含有仿真器中所有元素的World描述文件；建立使模型能够重复并简化使用的Model文件；修改环境变量以对服务器和客户端之间的通信进行设置和定位文件。建立如图12所示的3辆基于ROS架构的轮式车辆的模型，使用统一的操控终端对3台车辆进行控制，利用封装在ROS节点内的互操作中间件与操控端进行消息交互。

图12 Gazebo中的车辆模型

5.2 互操作系统功能测试

图13所示为基于跨平台C++图形用户界面应用程序开发框架Qt开发的统一操控终端OCU，结合该OCU可实现基于服务的以下功能：

a. 发现，按照用户选择的服务，显示所有具有该服务的组件的ID信息，用户按照需求输入该组件的ID信息，并获得该组件的控制权限；

b. 操控，操控所选择的组件，用户控制所选择组件所在车辆的线速度和角速度，并可以设置每次调整的线速度和角速度的步长；

c.路点跟随，将设置好的路径信息下发给所选的具有路点服务的车辆，并下达执行指令；

d.回传，将无人驾驶车辆回传至操控端的位置等信息，以数字及坐标图的形式显示；

e. 侦察，实时显示无人驾驶车辆回传的视频信息；

f.激光可视化，对无人驾驶车辆回传的激光点云数据进行可视化处理。

图13 机动与路点服务演示

5.2.1 发现、操控、路点跟随、回传功能测试

该系统以实现组件间的互操作性为目标，可以发现具有所需要功能（遥控、路点跟随、侦察）的组件，每个子系统、节点、组件均有自己特定的标识信息，用户可根据显示的组件ID信息进行选择与操作。在图13所示的操控终端中，用户可以操控Gazebo中的3辆仿真车辆，在终端界面选择所需要的服务。在JAUS标准中，无人驾驶车辆可以实现6自由度遥控驾驶，包括X、Y、Z3个方向的推进、制动和3个轴向的转动、转动制动，这些值被抽象并封装到WrenchEffort结构[17]中，控制端通过向车辆发送这组控制数据，实现对车辆的遥控。路点服务中，用户可将预设的轨迹发送给具有路点服务组件的车辆，车辆可实时反馈自身状态，并在坐标轴及提示框中显示仿真车辆的位置、线速度、角速度。

5.2.2 视频功能测试

图14所示为视频功能展示，操控端通过发现功能，经由用户选择获得具有视频服务的车辆的控制权限，并可以控制视频的播放与停止。

图14 视频服务演示

5.3 互操作系统对异构无人车辆的兼容性测试

以激光可视化功能为例，采用基于ROS架构的无人驾驶车辆与基于RCS架构无人驾驶车辆的激光点云数据，验证本系统对异构车辆的兼容性。在RCS和JAUS中，输入的数据是.PCD格式的激光点云，在ROS中，输入的数据是.BAG格式的激光点云。采用来自RCS与ROS架构实车的激光点云数据，由ROS节点与RCS节点发送激光数据，经由互操作系统完成异构无人平台间的激光数据传输。

图15所示为ROS架构无人车拍摄到的室内实景画面，以及ROS端在RViz（ROS官方的一款3D可视化工具）中显示的激光点云数据和OCU端对来自ROS架构无人车的激光点云数据的可视化功能。图16所示为RCS架构无人车摄像头拍摄到的道路画面，以及RCS端基于PCL点云库显示的激光点云数据和OCU对来自RCS架构无人车的激光点云数据的可视化功能。

图16 接收来自RCS架构无人车的激光点云数据

5.4 仿真结果分析

互操作系统功能测试以发现、操控、路点、回传、视频等基于服务的各功能的实现证明了本文设计方案的可行性，互操作系统对异构无人车辆的兼容性测试结合激光服务，以ROS架构与RCS架构的无人车为例证明了该方案对异构无人驾驶车辆的兼容性。综上，本文设计的互操作系统可以实现异构无人驾驶车辆集群系统间组件级别的互操作，该方案体现的设计原则与思想是解决异构无人驾驶车辆互操作性问题的有效途径。

6 结束语

本文分析了异构无人驾驶车辆集群对互操作性的需求及当前主流解决方案的优劣，选择了基于标准的中间件技术的解决方案，针对典型的异构无人驾驶车辆集群应用场景进行了构想，结合应用场景的需求，基于自动发现、去中心化、松散耦合、支持一对多通信的原则进行了软件实现，在目前主流的互操作协议中选择JAUS协议，基于Qt设计了可以操控异构车辆的统一操控端中间件以及无人驾驶车辆端的互操作中间件，利用ROS环境下的Gazebo仿真模型验证了解决方案的可行性。后续工作将进一步增加更多服务，并在实车上进行验证。