面向異構無人駕駛車輛的互操作性研究

余雪瑋 趙熙俊 蘇波

（中國北方車輛研究所，北京 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仿真模型驗證了解決方案的可行性。后續工作將進一步增加更多服務，并在實車上進行驗證。