1 中間件的概念界定

1968年，德國(guó)舉辦了NATO軟件工程大會(huì)，會(huì)后發(fā)表的一份報(bào)告中第一次出現(xiàn)了中間件這個(gè)術(shù)語。中間件是為應(yīng)用提供通用服務(wù)和功能的軟件。數(shù)據(jù)管理、應(yīng)用服務(wù)、消息傳遞、身份驗(yàn)證和API管理通常都要通過中間件。

下文中討論的是智能駕駛操作系統(tǒng)中用于消息傳遞的分布式通信中間件。分布式通信中間件在智能駕駛領(lǐng)域有著非常重要的地位。智能駕駛功能如算法及應(yīng)用一般是多個(gè)自主模塊獨(dú)立運(yùn)行，彼此通信實(shí)現(xiàn)各種等級(jí)的智能駕駛功能。同時(shí)，多種智能駕駛功能之間約束和優(yōu)化、功能安全和信息安全等功能也多以自主模塊形式提供。因此分布式通信是智能駕駛及其擴(kuò)展功能的基礎(chǔ)功能，也是系統(tǒng)實(shí)時(shí)性和可靠性的重要支撐之一。由于智能駕駛域控制器是異構(gòu)、多芯片、甚至多板卡形式，分布式通信中間件也需要支持進(jìn)程及線程之間、跨內(nèi)核、跨芯片、跨板卡等通信，通信形式也包括可靠和非可靠、同步和異步等方法。

2 智能駕駛領(lǐng)域主流分布式通信中間件和其架構(gòu)

目前應(yīng)用在智能駕駛領(lǐng)域車載操作系統(tǒng)比較主流的分布式通信中間件有VSOMEIP、DDS、ICEORYX、ROS/ROS2、Apex.OS和AP AUTOSAR。

2.1 VSOMEIP

SOME/IP（Scalable service-Oriented MiddlewarE over IP）是車載以太網(wǎng)通信引入的一個(gè)概念，位于OSI 7層模型的層4之上。此中間件是為典型的汽車用例設(shè)計(jì)的，并且與AUTOSAR兼容。

VSOMEIP則是寶馬公司基于SOME/IP協(xié)議實(shí)現(xiàn)的中間件，實(shí)現(xiàn)了服務(wù)發(fā)現(xiàn)以及通信功能，并在此基礎(chǔ)上增加了少許的安全機(jī)制。

VSOMEIP通信示意圖

（來源https://github.com/COVESA/vsomeip/wiki/vsomeip-in-10-minutes）

如圖所示，VSOMEIP不僅涵蓋了設(shè)備之間的SOME/IP通信（跨機(jī)通信），還涵蓋了內(nèi)部進(jìn)程間通信。兩個(gè)設(shè)備通過所謂的通信端點(diǎn)進(jìn)行通信，這些端點(diǎn)將使用的傳輸協(xié)議（TCP或UDP）及其參數(shù)確定為端口號(hào)或其他參數(shù)。所有這些參數(shù)都是可以在VSOMEIP配置文件中進(jìn)行設(shè)置。內(nèi)部通信是通過本地端點(diǎn)完成的，這些端點(diǎn)由UNIX域套接字使用Boost.Asio庫實(shí)現(xiàn)。由于這種內(nèi)部通信不通過中央組件，比如像D-Bus守護(hù)程序路由，因此非?？?。

2.2 DDS（Data Distribution Service 數(shù)據(jù)分發(fā)服務(wù)）

數(shù)據(jù)分發(fā)服務(wù)DDS是由OMG組織發(fā)布的一個(gè)分布式實(shí)時(shí)系統(tǒng)發(fā)布/訂閱模型的規(guī)范。這個(gè)規(guī)范定義了一個(gè)以數(shù)據(jù)為中心的發(fā)布/訂閱模型，提供了一個(gè)獨(dú)立于平臺(tái)的中間件框架，為實(shí)時(shí)系統(tǒng)中數(shù)據(jù)發(fā)布、傳遞和接收的接口和行為提供統(tǒng)一標(biāo)準(zhǔn)。它允許應(yīng)用程序?qū)崟r(shí)地發(fā)布其所能提供的信息，并訂閱所需要的信息。除此之外，DDS還支持許多QoS屬性，如異步、松耦合、實(shí)時(shí)可靠數(shù)據(jù)分發(fā)等。DDS規(guī)范的目的是簡(jiǎn)化分布式系統(tǒng)中數(shù)據(jù)的有效發(fā)布，它適用于性能要求高、可預(yù)見性強(qiáng)的實(shí)時(shí)關(guān)鍵任務(wù)領(lǐng)域。

DDS域內(nèi)通信示意圖（來源eprosima.com）

目前常用的商用DDS實(shí)現(xiàn)有RTI的RTIDDS，開源DDS實(shí)現(xiàn)有eprosima公司的Fast-DDS，OCI公司的OpenDDS，eclipse公司的Cyclone DDS，Prismtech公司的OpendSplice DDS等。

Fast DDS和Cyclone DDS在延遲性能方面的比較表明，F(xiàn)ast DDS的平均延遲低于Cyclone DDS。此外， Fast DDS也是更穩(wěn)定的DDS實(shí)現(xiàn)，隨著有效載荷變大，延遲增加的速度會(huì)變慢。在吞吐性能方面的比較表明，F(xiàn)ast DDS的吞吐量對(duì)于每個(gè)有效載荷都是最高的，這意味著Fast DDS能夠?yàn)槊總€(gè)有效載荷每秒發(fā)送更多給定大小的消息。但是Fast DDS也有不足之處，在多種廠商的DDS實(shí)現(xiàn)中，F(xiàn)astDDS不支持部分QoS策略。

SOME/IP和DDS都允許分布式應(yīng)用程序使用發(fā)布/訂閱和請(qǐng)求/響應(yīng)的方式進(jìn)行通信，但是也存在很大的差異。

• SOME/IP作為AUTOSAR的一部分，開發(fā)了一系列規(guī)范，描述其序列化協(xié)議、服務(wù)發(fā)現(xiàn)以及集成在CP中的協(xié)議標(biāo)準(zhǔn)接口。而DDS應(yīng)用在更廣泛的工業(yè)物聯(lián)網(wǎng)領(lǐng)域，是OMG發(fā)布的一系列標(biāo)準(zhǔn)，專門為分布式實(shí)時(shí)系統(tǒng)設(shè)計(jì)，應(yīng)用在很多行業(yè)，包括航空航天、國(guó)防軍工、醫(yī)療系統(tǒng)等，在商業(yè)和開源領(lǐng)域都有許多獨(dú)立的實(shí)現(xiàn)。應(yīng)用程序在使用DDS時(shí)，不用像SOME/IP一樣要綁定到特定的服務(wù)實(shí)現(xiàn)，通過簡(jiǎn)單的引用主題和服務(wù)，就可以透明地實(shí)現(xiàn)一對(duì)一和一對(duì)多的通信，無需更改代碼，比SOME/IP更加靈活。

• DDS基于RTPS協(xié)議進(jìn)行傳輸，可以映射到不同的網(wǎng)絡(luò)傳輸協(xié)議，RTPS實(shí)現(xiàn)了與傳輸無關(guān)地可靠性與分段協(xié)議，該協(xié)議可以在任何傳輸之上運(yùn)行，因此使用DDS可以通過多播UDP處理大數(shù)據(jù)和可靠數(shù)據(jù)，而SOME/IP無法做到這一點(diǎn)。

• DDS提供了許多QoS策略，使用戶可以聲明性地指定發(fā)布者與訂閱者之間如何交換性息，比如資源使用、數(shù)據(jù)優(yōu)先級(jí)、數(shù)據(jù)可用性等。而SOMEIP僅提供一種用于選擇UDP與TCP的可靠性QoS設(shè)置。

2.3 冰羚（ICEORYX）

冰羚實(shí)現(xiàn)了真正基于共享內(nèi)存的“零拷貝”數(shù)據(jù)傳輸，將共享內(nèi)存與發(fā)布/訂閱架構(gòu)、服務(wù)發(fā)現(xiàn)機(jī)制、C ++以及無鎖算法（lock-free algorithms）相結(jié)合。通過添加避免復(fù)制的應(yīng)用程序接口，實(shí)現(xiàn)了真正的零拷貝，即數(shù)據(jù)從“發(fā)布者”到 “訂閱者”的端到端傳輸過程中，無需創(chuàng)建任何數(shù)據(jù)副本。

冰羚零拷貝示意圖

（來源GitHub - eclipse-iceoryx/iceoryx: Eclipse iceoryx? - true zero-copy inter-process-communication）

在使用實(shí)現(xiàn)“零拷貝”的共享內(nèi)存中間件冰羚后，系統(tǒng)的運(yùn)行時(shí)間和延遲跟傳輸?shù)臄?shù)據(jù)量脫離關(guān)系。換句話說，系統(tǒng)可以在一定時(shí)間內(nèi)實(shí)現(xiàn)幾乎無限的數(shù)據(jù)傳輸。

但冰羚在使用上稍顯復(fù)雜。首先，用戶在使用訂閱發(fā)布之前，必須啟動(dòng)一個(gè)守護(hù)進(jìn)程，用于管理共享內(nèi)存以及管理節(jié)點(diǎn)發(fā)現(xiàn)；其次，在發(fā)布數(shù)據(jù)之前需要先獲得一塊能夠存放數(shù)據(jù)的內(nèi)存地址，用戶也只能使用定長(zhǎng)數(shù)據(jù)進(jìn)行傳輸；此外，冰羚跨機(jī)通信依賴于Eclipse公司的Cyclone DDS。

2.4 ROS1/ROS2（Robot Operating System）

ROS 名為機(jī)器人操作系統(tǒng)，但它并不是真正的操作系統(tǒng)。最好將其理解為用于開發(fā)機(jī)器人應(yīng)用程序的軟件開發(fā)工具包 (SDK)：它提供開發(fā)、調(diào)試、測(cè)試和最終部署機(jī)器人應(yīng)用程序所需的軟件、庫和工具。

ROS1與ROS2的架構(gòu)對(duì)比圖（來源于網(wǎng)絡(luò)）

ROS1與ROS2的架構(gòu)如上圖所示，ROS1中依賴Master注冊(cè)獲取節(jié)點(diǎn)信息，而ROS2實(shí)現(xiàn)了去中心化。ROS2 的應(yīng)用框架總體分為三個(gè)部分，應(yīng)用層、中間件層和操作系統(tǒng)層。RCL 是中間件層與用戶層程序直接交互的接口。RMW 接口層抽象了 DDS的具體實(shí)現(xiàn)，可根據(jù)用戶需求，切換不同的 DDS 實(shí)現(xiàn)。ROS2 根據(jù)通訊邊界，分別做了不同的實(shí)現(xiàn)，進(jìn)程內(nèi)通訊由 ROS2 實(shí)現(xiàn)，際間通訊（進(jìn)程間和跨機(jī)通訊）則采用 DDS實(shí)現(xiàn)。這樣的通信策略是由于部分 DDS 的進(jìn)程內(nèi)通信仍使用回環(huán)地址的網(wǎng)絡(luò)通訊方式，數(shù)據(jù)要進(jìn)行用戶態(tài)與內(nèi)核態(tài)的拷貝，且通訊受限于協(xié)議棧，通訊效率低。

ROS的優(yōu)勢(shì)：

• 每個(gè)供應(yīng)商提供的DDS接口都不同，如果要更換供應(yīng)商，則需要更改代碼，而ROS提供了一層中間層，使面向用戶的接口不變，易于更換底層DDS供應(yīng)商。

• ROS2為需要?jiǎng)?chuàng)建應(yīng)用程序的用戶提供了生態(tài)系統(tǒng)、文檔和友好的框架，提供了比DDS更高級(jí)別的抽象，因此ROS2更側(cè)重于應(yīng)用程序開發(fā)，消除了不同DDS的復(fù)雜訂閱發(fā)布應(yīng)用程序編寫的困難。

• ROS2不僅僅是實(shí)現(xiàn)了通信層的功能，它還提供了機(jī)器人技術(shù)中常用的包，從基本的坐標(biāo)系轉(zhuǎn)換包到高級(jí)的生成環(huán)境地圖并依此對(duì)機(jī)器人導(dǎo)航的應(yīng)用程序；

• 提供了構(gòu)建系統(tǒng)，從ROS1的catkin到ROS2的colcon，可以輕松的構(gòu)建包，并指定各個(gè)包之間的依賴關(guān)系

• 提供了一個(gè)啟動(dòng)系統(tǒng)，可以輕松運(yùn)行由多個(gè)互相依賴的應(yīng)用程序組成的復(fù)雜系統(tǒng)，并提供一種更輕松的修改參數(shù)的方法；

• 提供了豐富的調(diào)試工具，包括回顯工具、播包錄包工具、以及可視化工具等。

但是，需要注意的是，使用ROS2而不是原生的DDS也會(huì)產(chǎn)生成本，ROS2只支持底層各個(gè)供應(yīng)商DDS都支持的QoS策略子集，因此直接使用ROS2無法訪問某些DDS的功能和QoS策略。DDS面向應(yīng)用程序提供的功能要廣泛得多，接口和QoS的使用也更加通用、靈活。

2.5 Apex.OS

與ROS一樣，Apex.OS并不是真正的操作系統(tǒng)，而是一套軟件開發(fā)框架，但Apex.OS是經(jīng)過安全認(rèn)證的軟件開發(fā)框架。Apex.OS由Apex.AI公司推出，是為移動(dòng)設(shè)備、智能機(jī)器和IoT準(zhǔn)備的，基于ROS2開發(fā)的汽車操作系統(tǒng)。

Apex.OS對(duì)ROS2進(jìn)行改造，修復(fù)了ROS2的一些bug，同時(shí)給上游提供監(jiān)控節(jié)點(diǎn)；增強(qiáng)實(shí)時(shí)性、可靠性以及確定性；和ROS2未來的release同步，保持API兼容。Apex.OS Cert產(chǎn)品通過了ISO26262 Seooc功能安全認(rèn)證，最高支持ASIL-D，基于Apex.OS可以開發(fā)安全相關(guān)應(yīng)用。

Apex Middleware是由Apex.AI推出的能夠滿足汽車通信需求、支持機(jī)器內(nèi)部通信、支持跨機(jī)器通信、支持云端通信的通信中間件。核心組件基于Eclipse Cyclone DDS? 的高魯棒性、高性能網(wǎng)絡(luò)通信和 Eclipse iceoryx?的高效零拷貝通信，它們都是開源項(xiàng)目，并且在汽車和任務(wù)關(guān)鍵型分布式系統(tǒng)中得到驗(yàn)證。Apex Middleware和Apex.OS高度優(yōu)化集成，也可作為一個(gè)獨(dú)立產(chǎn)品。

Apex. Middleware的優(yōu)勢(shì)如下：

• 具有跨ECU/ECU內(nèi)部通信完整的，集成化的解決方案；

• 已經(jīng)集成到了通用的框架，比如ROS 2，Apex.OS，AUTOSAR Adaptive；

• 支持DDS和SOME/IP，當(dāng)前汽車以太網(wǎng)最相關(guān)的協(xié)議；

• 支持發(fā)布/訂閱和請(qǐng)求/響應(yīng)通信；

• 能高效處理海量數(shù)據(jù)，滿足駕駛輔助和智能駕駛應(yīng)用的數(shù)據(jù)傳輸需求；

• 低運(yùn)行時(shí)開銷的高性能通信；

• 通信發(fā)現(xiàn)機(jī)制，用于支持現(xiàn)代化的SOA；

• 基于ISO26262的安全認(rèn)證；

• 大量的QoS特性；

• 提供有效的橋接至網(wǎng)絡(luò)協(xié)議，比如MQTT、AMQP、OPC-UA、Eclipse Zenoh。

2.6 AUTOSAR AP

AUTOSAR Adaptive Platform（AP） 是 ARA（AUTOSAR Runtime for Adaptive Applications）的實(shí)現(xiàn)。如下圖所示為AP架構(gòu)邏輯視圖。

AP模塊示意圖

（來源《AUTOSAR AP規(guī)范Platform Design》）

AP包含執(zhí)行管理、通信管理、狀態(tài)管理、診斷管理、網(wǎng)絡(luò)管理等模塊，我們這里重點(diǎn)討論與通信管理相關(guān)的中間件模塊。通信管理提供了機(jī)器內(nèi)以及機(jī)器間面向服務(wù)的通信，包括Event、Method和Fields，可以在設(shè)計(jì)時(shí)，啟動(dòng)時(shí)或運(yùn)行時(shí)建立通信伙伴之間的通信路徑。該機(jī)制的重要組成部分是服務(wù)注冊(cè)中心，它充當(dāng)中介實(shí)例，并且也是通信管理軟件的一部分。

AP面向服務(wù)示意圖（來源《AUTOSAR AP規(guī)范Platform Design》）

提供服務(wù)的每個(gè)應(yīng)用程序都在服務(wù)注冊(cè)表中注冊(cè)這些服務(wù)。要使用服務(wù)，應(yīng)用程序需要通過查詢服務(wù)注冊(cè)表來找到請(qǐng)求的服務(wù)，此過程稱為服務(wù)發(fā)現(xiàn)。

通信管理提供了標(biāo)準(zhǔn)化的手段，將定義的服務(wù)呈現(xiàn)給應(yīng)用程序?qū)崿F(xiàn)者（上層，語言綁定）以及網(wǎng)絡(luò)上服務(wù)數(shù)據(jù)的相應(yīng)表示（下層，網(wǎng)絡(luò)綁定）。這確保了源代碼的可移植性以及跨平臺(tái)的不同實(shí)現(xiàn)的已編譯服務(wù)的兼容性。

語言綁定定義如何通過使用目標(biāo)編程語言的便捷功能將服務(wù)的Method，Event和Field轉(zhuǎn)換為可直接訪問的標(biāo)識(shí)符。性能和類型安全性（就目標(biāo)語言所支持的程度而言）是主要目標(biāo)。因此，語言綁定通常由Service Interface定義提供的源代碼生成器實(shí)現(xiàn)。

AP通信模塊網(wǎng)絡(luò)綁定示意圖

（來源《AUTOSAR AP規(guī)范Platform Design》）

網(wǎng)絡(luò)綁定定義了如何將已配置服務(wù)的實(shí)際數(shù)據(jù)序列化并綁定到特定網(wǎng)絡(luò)。可以基于通信管理配置（AUTOSAR元模型的接口定義），通過解釋生成的服務(wù)特定配方或直接生成序列化代碼本身來實(shí)現(xiàn)。當(dāng)前，通信管理支持SOME / IP，DDS，IPC（進(jìn)程間通信或任何其他自定義綁定）和Signal PDU（基于信號(hào)的網(wǎng)絡(luò)綁定）。

AUTOSAR AP的優(yōu)勢(shì)在于層次化和模塊化、配置化、接口標(biāo)準(zhǔn)化。

• 層次化和模塊化：AUTOSAR將硬件依賴和非硬件依賴的軟件進(jìn)行了封裝，同時(shí)模塊的層次處理也收集了先進(jìn)廠家的經(jīng)驗(yàn)，分享出一個(gè)穩(wěn)定可靠的算法模塊框架；

• 配置化：如果使用工具鏈進(jìn)行開發(fā)，目前的基礎(chǔ)軟件已做到通過配置參數(shù)實(shí)現(xiàn)功能剪裁，算法邏輯，提高了基礎(chǔ)軟件開發(fā)效率；

• 接口標(biāo)準(zhǔn)化：有利于降低軟件的移植成本。

AP的劣勢(shì)在于：工具鏈昂貴且不成熟，供應(yīng)商不多，且在使用過程中不斷發(fā)現(xiàn)、修改BUG。同時(shí)不同工具鏈廠商之間沒有做好兼容性設(shè)計(jì)，影響了復(fù)用性和獨(dú)立性。

3 中間件的關(guān)鍵技術(shù)

分布式通信中間件需要在分布式的環(huán)境中，實(shí)現(xiàn)各節(jié)點(diǎn)之間數(shù)據(jù)的正確、高效分發(fā)。單個(gè)節(jié)點(diǎn)需要保持較高的獨(dú)立性，各個(gè)節(jié)點(diǎn)之間的耦合度降到最低，任何一個(gè)節(jié)點(diǎn)產(chǎn)生的異常不影響整個(gè)系統(tǒng)的運(yùn)行。

一次數(shù)據(jù)的傳輸過程需要完成如下任務(wù)：用戶消息的發(fā)布與訂閱；消息的發(fā)現(xiàn)與識(shí)別；配對(duì)節(jié)點(diǎn)的選擇與數(shù)據(jù)鏈路的建立；消息的高效傳輸；傳輸過程中對(duì)節(jié)點(diǎn)狀態(tài)的實(shí)時(shí)監(jiān)控；用戶取消訂閱或發(fā)布時(shí)，數(shù)據(jù)鏈路的釋放與重建。

因此，分布式通信中間件需要實(shí)現(xiàn)鏈路動(dòng)態(tài)管理、數(shù)據(jù)高效管理以及系統(tǒng)實(shí)時(shí)性等關(guān)鍵技術(shù)。對(duì)于鏈路管理，其難點(diǎn)主要體現(xiàn)在鏈路的動(dòng)態(tài)建立及正確地釋放；對(duì)于數(shù)據(jù)管理，其難點(diǎn)主要在于找到適當(dāng)?shù)南⒔M織方法，以解決消息的高效存取、消息優(yōu)先級(jí)的實(shí)現(xiàn)、消息的本地零拷貝、多線程安全以及消息保存的問題；對(duì)于實(shí)時(shí)性的實(shí)現(xiàn)，其難點(diǎn)則主要在于攻克高效的本地消息組織方法、節(jié)點(diǎn)之間消息投遞方式以及節(jié)點(diǎn)對(duì)消息的處理模式。

3.1 鏈路管理

鏈路管理難點(diǎn)主要體現(xiàn)在鏈路的動(dòng)態(tài)建立及正確的釋放。數(shù)據(jù)鏈路建立的過程就是發(fā)布訂閱的配對(duì)過程。系統(tǒng)初始并不知道哪些節(jié)點(diǎn)會(huì)形成發(fā)布/訂閱關(guān)系，而且發(fā)布訂閱關(guān)系也是隨節(jié)點(diǎn)運(yùn)行情況動(dòng)態(tài)變化的。這要求發(fā)布者/訂閱者之間的數(shù)據(jù)鏈路必須根據(jù)節(jié)點(diǎn)運(yùn)行狀態(tài)動(dòng)態(tài)建立，用來適應(yīng)節(jié)點(diǎn)運(yùn)行變化?？梢圆捎迷儐?應(yīng)答/確認(rèn)（三次握手）、定時(shí)器技術(shù)以及超時(shí)重傳解決鏈路建立的問題，如下圖所示。

3.2 數(shù)據(jù)管理

數(shù)據(jù)管理難點(diǎn)主要在于找到適當(dāng)?shù)臄?shù)據(jù)組織方式，解決數(shù)據(jù)的便利存取、優(yōu)先級(jí)的實(shí)現(xiàn)、數(shù)據(jù)本地零拷貝、多線程的安全以及數(shù)據(jù)保存的問題.

3.2.1 內(nèi)存數(shù)據(jù)組織

對(duì)于內(nèi)存數(shù)據(jù)組織，可以采用隊(duì)列技術(shù)、定時(shí)器技術(shù)以及鎖機(jī)制實(shí)現(xiàn)一個(gè)高效的消息隊(duì)列來對(duì)數(shù)據(jù)進(jìn)行管理，滿足了系統(tǒng)對(duì)消息管理的要求，其實(shí)現(xiàn)基于如下兩個(gè)類：

Message_Node：代表隊(duì)列中的一個(gè)節(jié)點(diǎn)，內(nèi)部分配緩沖區(qū)用以保存需要管理的消息數(shù)據(jù)。一個(gè)Message_Node對(duì)象實(shí)例管理著一條消息數(shù)據(jù)。該類提供接口設(shè)置信息的優(yōu)先級(jí)，用以實(shí)現(xiàn)在隊(duì)列中根據(jù)優(yōu)先級(jí)排隊(duì)。

Message_Queue：消息隊(duì)列，由很多Message_Node連接而成。內(nèi)部采用了定時(shí)器技術(shù)來實(shí)現(xiàn)進(jìn)隊(duì)、出隊(duì)的定時(shí)，進(jìn)隊(duì)、出隊(duì)操作會(huì)一直阻塞到操作成功或者超時(shí)失敗，從而避免了一直阻塞導(dǎo)致系統(tǒng)無法工作。采用互斥量技術(shù)或無鎖操作來對(duì)多線程操作隊(duì)列進(jìn)行同步，保證進(jìn)隊(duì)、出隊(duì)操作的多線程安全。同時(shí)提供了put_prior接口實(shí)現(xiàn)按優(yōu)先級(jí)進(jìn)隊(duì)，操作會(huì)根據(jù)MessageNode實(shí)例的優(yōu)先級(jí)將其插入到隊(duì)列的合適位置，而不是始終插入到隊(duì)尾，從而實(shí)現(xiàn)數(shù)據(jù)的按優(yōu)先級(jí)排序。更重要的是隊(duì)列不直接管理Message Node實(shí)例，而是管理Message_Node實(shí)例的指針，從而避免了進(jìn)隊(duì)出隊(duì)的拷貝操作，實(shí)現(xiàn)了數(shù)據(jù)本地零拷貝，減小了系統(tǒng)開銷。Message_Queue對(duì)Message_Block的管理如下圖所示。

3.2.2 消息數(shù)據(jù)持久性

消息數(shù)據(jù)持久性策略主要解決節(jié)點(diǎn)之間時(shí)間耦合問題。對(duì)于每一個(gè)主題消息數(shù)據(jù)，均可以配置其持久性用以決定主題消息數(shù)據(jù)是否可重現(xiàn)，具體會(huì)存在四種策略：

• 實(shí)時(shí)消息數(shù)據(jù)：系統(tǒng)不保存消息數(shù)據(jù)，發(fā)布方生產(chǎn)出消息數(shù)據(jù)則直接交付系統(tǒng)投遞，投遞時(shí)在線的訂閱者可獲得該消息數(shù)據(jù)，不在線的節(jié)點(diǎn)則不能獲取到消息數(shù)據(jù)，消息數(shù)據(jù)沒有重現(xiàn)性。

• N條有效：系統(tǒng)在內(nèi)存中保存最新的N條消息數(shù)據(jù)。后加入的訂閱者可以獲取到這N條歷史消息數(shù)據(jù)，這里的N可以由用戶設(shè)置。

• N秒有效：指的是消息數(shù)據(jù)從生產(chǎn)出來的時(shí)刻算起，有N秒的存活時(shí)間，一旦時(shí)間超過N秒，則消息數(shù)據(jù)失效。系統(tǒng)保存所有尚未失效的消息數(shù)據(jù)。后加入的訂閱者可以獲取到還存活的歷史消息數(shù)據(jù)，這里的N可以由用戶設(shè)置。

• 永久保存：即保存所有該主題消息數(shù)據(jù)，后加入的訂閱者可以獲取到所有的歷史消息數(shù)據(jù)。

3.2.3 系統(tǒng)實(shí)時(shí)性

高實(shí)時(shí)性一直是分布式通信中間件系統(tǒng)的終極目標(biāo)，衡量實(shí)時(shí)性的一個(gè)最直觀的變量就是數(shù)據(jù)從生產(chǎn)者生產(chǎn)出數(shù)據(jù)到消費(fèi)者獲取到數(shù)據(jù)之間的時(shí)間間隔。

該時(shí)間間隔包括以下過程產(chǎn)生的時(shí)間開銷：

• 數(shù)據(jù)封裝、進(jìn)入隊(duì)列阻塞的時(shí)間開銷；

• 出隊(duì)的時(shí)間開銷；

• 出隊(duì)的數(shù)據(jù)進(jìn)入到本地物理網(wǎng)絡(luò)傳輸媒介的時(shí)間開銷；

• 數(shù)據(jù)在兩個(gè)節(jié)點(diǎn)之間的物理媒介傳輸?shù)臅r(shí)間開銷；

• 數(shù)據(jù)從本地物理媒介到操作系統(tǒng)用戶空間時(shí)間開銷；

• 從用戶空間進(jìn)入接收隊(duì)列的時(shí)間開銷；

• 在接收隊(duì)列的等待時(shí)間

針對(duì)以上時(shí)間開銷可以采取以下的優(yōu)化措施：

• 采用簡(jiǎn)單應(yīng)用層協(xié)議，減小封裝和解封的時(shí)間開銷；

• 采用多線程技術(shù)，減小數(shù)據(jù)入隊(duì)出隊(duì)的時(shí)間開銷；

• 采用消息隊(duì)列管理數(shù)據(jù)指針，減少數(shù)據(jù)在本地內(nèi)存的拷貝；

• 消息數(shù)據(jù)進(jìn)行點(diǎn)對(duì)點(diǎn)傳送，不經(jīng)過中間節(jié)點(diǎn)轉(zhuǎn)發(fā)，避開廣播，緩解網(wǎng)絡(luò)擁塞從而減小數(shù)據(jù)在網(wǎng)絡(luò)之間的傳輸時(shí)間；

• 采用優(yōu)先級(jí)技術(shù)和消息數(shù)據(jù)質(zhì)量衡量技術(shù)，對(duì)消息數(shù)據(jù)進(jìn)行分級(jí)，過濾掉質(zhì)量比較低的不符合用戶需求的消息數(shù)據(jù)

4 AICC中間件的架構(gòu)與實(shí)現(xiàn)

4.1 AICC中間件分層架構(gòu)

AICC中間件分層架構(gòu)圖

AICC中間件分層架構(gòu)圖如上圖所示，分為通信層、發(fā)現(xiàn)層和用戶層。通信層的進(jìn)程間與進(jìn)程內(nèi)通信是由基于共享內(nèi)存的零拷貝技術(shù)實(shí)現(xiàn)的，跨機(jī)通信是基于DDS實(shí)現(xiàn)的，用于用戶數(shù)據(jù)的傳輸；發(fā)現(xiàn)層是用來進(jìn)行進(jìn)程內(nèi)、進(jìn)程間、跨機(jī)通信的發(fā)布者/訂閱者之間的數(shù)據(jù)鏈路建立；用戶層用來定義中間件的對(duì)外接口。

4.2 AICC中間件實(shí)現(xiàn)的功能

AICC中間件實(shí)現(xiàn)的功能有訂閱/發(fā)布、請(qǐng)求/響應(yīng)兩大功能，對(duì)兩大功能的數(shù)據(jù)傳輸過程進(jìn)行描述。

AICC中間件訂閱/發(fā)布數(shù)據(jù)流傳輸過程表示

AICC中間件訂閱/發(fā)布數(shù)據(jù)流傳輸過程如上圖所示。在發(fā)現(xiàn)層中，會(huì)建立一個(gè)網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)管理整個(gè)域內(nèi)的節(jié)點(diǎn)、訂閱者與發(fā)布者，他們可以主動(dòng)加入或退出網(wǎng)絡(luò)拓?fù)潢P(guān)系。假設(shè)訂閱節(jié)點(diǎn)先于發(fā)布節(jié)點(diǎn)上線，當(dāng)對(duì)應(yīng)的發(fā)布節(jié)點(diǎn)上線時(shí)，會(huì)根據(jù)拓?fù)浣Y(jié)構(gòu)里訂閱節(jié)點(diǎn)的位置，創(chuàng)建所需的真實(shí)發(fā)布傳輸通道。通信層的進(jìn)程內(nèi)與進(jìn)程間通信都是通過零拷貝技術(shù)實(shí)現(xiàn)的，真正實(shí)現(xiàn)了基于共享內(nèi)存的數(shù)據(jù)零拷貝。同時(shí)支持定長(zhǎng)與變長(zhǎng)數(shù)據(jù)的傳輸，傳輸速度在GB/s級(jí)，延遲在us級(jí)。而跨機(jī)通信是基于DDS實(shí)現(xiàn)的，同時(shí)實(shí)現(xiàn)了與ROS2的互聯(lián)互通，因此可以利用ROS2的工具，比如ros2 topic list/hz/echo、ros2 bag record/play等。還通過開發(fā)一層簡(jiǎn)單的Adapter層，就可實(shí)現(xiàn)基于RVIZ的消息可視化功能，為后期調(diào)試提供便利。

AICC中間件請(qǐng)求/響應(yīng)數(shù)據(jù)傳輸過程表示

同時(shí)，AICC中間件除了訂閱/發(fā)布功能，還實(shí)現(xiàn)了請(qǐng)求/響應(yīng)功能，如上圖所示。請(qǐng)求響應(yīng)功能是基于兩對(duì)訂閱/發(fā)布實(shí)現(xiàn)的，因此，與訂閱發(fā)布功能采用的通信方式類似，根據(jù)Client和Server所處的位置，建立不同的傳輸協(xié)議，進(jìn)程間與進(jìn)程內(nèi)的請(qǐng)求響應(yīng)也可以實(shí)現(xiàn)基于共享內(nèi)存的數(shù)據(jù)零拷貝，而跨機(jī)依舊依賴于DDS。

請(qǐng)求響應(yīng)功能實(shí)現(xiàn)方式如下，Client端通過Request Topic將某種類型的請(qǐng)求消息傳遞給Server端，Server端收到請(qǐng)求消息后根據(jù)用戶傳入的處理方法，請(qǐng)求消息處理得到響應(yīng)消息，并通過Reply Topic將消息傳遞到Client，至此用戶請(qǐng)求操作之后獲取到響應(yīng)消息。

4.3 AICC中間件的優(yōu)勢(shì)

AICC中間件的優(yōu)勢(shì)有以下幾個(gè)方面：

在發(fā)現(xiàn)層，基于主動(dòng)拓?fù)鋵?shí)現(xiàn)鏈路管理機(jī)制。該機(jī)制主要用于監(jiān)測(cè)節(jié)點(diǎn)的上下線，在DDS的參與者自動(dòng)發(fā)現(xiàn)機(jī)制的基礎(chǔ)之上，進(jìn)行了完善， AICC中間件的訂閱發(fā)布節(jié)點(diǎn)上線與下線時(shí)，主動(dòng)調(diào)用相關(guān)接口，實(shí)現(xiàn)即時(shí)主動(dòng)管理節(jié)點(diǎn)機(jī)制。

在通信層，針對(duì)進(jìn)程間通信，AICC中間件實(shí)現(xiàn)了基于共享內(nèi)存的零拷貝，使得進(jìn)程間通信發(fā)布訂閱的只是真實(shí)消息數(shù)據(jù)的地址，對(duì)于延遲和吞吐量的提升有一個(gè)質(zhì)的改變，因此延遲時(shí)間在us級(jí)別，吞吐量在GB/s級(jí)別，性能提升很大。對(duì)于跨機(jī)通信，AICC中間件是基于DDS實(shí)現(xiàn)的，對(duì)于該實(shí)現(xiàn)也能夠保證在每個(gè)機(jī)器部分能夠?qū)崿F(xiàn)消息數(shù)據(jù)的零拷貝，同時(shí)重寫序列化與反序列化函數(shù)，把不同的數(shù)據(jù)類型均當(dāng)作字節(jié)流來處理，因此跨機(jī)通信的性能也有一定的提升。

同時(shí)，在通信層的跨機(jī)通信中，AICC中間件通過提供與ROS2序列化與反序列化規(guī)則相同的序列化與反序列化函數(shù)，建立與ROS2通信的傳輸器，實(shí)現(xiàn)了與ROS2的互聯(lián)互通。

在用戶層，AICC中間件為用戶提供的是C接口，方便用戶更高層級(jí)的封裝使用。同時(shí)，由于在通信層實(shí)現(xiàn)了與ROS2的互聯(lián)互通功能，在用戶層可以復(fù)用ROS2幾乎全部的工具，比如ros2 topic、ros2 bag以及rviz可視化工具，大大方便了用戶的使用。

作者陽陽，多年智能駕駛研發(fā)經(jīng)驗(yàn)，碩士期間從事鉸接礦用自卸車的環(huán)境感知工作，畢業(yè)后專注車載操作系統(tǒng)中間件的研發(fā)，擅長(zhǎng)基于FastDDS、ICEORYX等中間件進(jìn)行二次開發(fā)。