1 中間件的概念界定

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

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

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

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

2.1 VSOMEIP

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

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

VSOMEIP通信示意圖

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

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

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

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

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

目前常用的商用DDS實現(xiàn)有RTI的RTIDDS，開源DDS實現(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實現(xiàn)，隨著有效載荷變大，延遲增加的速度會變慢。在吞吐性能方面的比較表明，F(xiàn)ast DDS的吞吐量對于每個有效載荷都是最高的，這意味著Fast DDS能夠為每個有效載荷每秒發(fā)送更多給定大小的消息。但是Fast DDS也有不足之處，在多種廠商的DDS實現(xiàn)中，F(xiàn)astDDS不支持部分QoS策略。

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

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

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

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

2.3 冰羚（ICEORYX）

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

冰羚零拷貝示意圖

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

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

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

2.4 ROS1/ROS2（Robot Operating System）

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

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

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

ROS的優(yōu)勢：

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

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

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

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

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

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

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

2.5 Apex.OS

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

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

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

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

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

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

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

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

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

• 低運行時開銷的高性能通信；

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

• 基于ISO26262的安全認證；

• 大量的QoS特性；

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

2.6 AUTOSAR AP

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

AP模塊示意圖

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

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

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

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

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

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

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

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

網(wǎng)絡綁定定義了如何將已配置服務的實際數(shù)據(jù)序列化并綁定到特定網(wǎng)絡?？梢曰谕ㄐ殴芾砼渲茫ˋUTOSAR元模型的接口定義），通過解釋生成的服務特定配方或直接生成序列化代碼本身來實現(xiàn)。當前，通信管理支持SOME / IP，DDS，IPC（進程間通信或任何其他自定義綁定）和Signal PDU（基于信號的網(wǎng)絡綁定）。

AUTOSAR AP的優(yōu)勢在于層次化和模塊化、配置化、接口標準化。

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

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

• 接口標準化：有利于降低軟件的移植成本。

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

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

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

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

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

3.1 鏈路管理

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

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

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

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

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

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

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

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

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

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

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

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

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

3.2.3 系統(tǒng)實時性

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

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

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

• 出隊的時間開銷；

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

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

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

• 從用戶空間進入接收隊列的時間開銷；

• 在接收隊列的等待時間

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

• 采用簡單應用層協(xié)議，減小封裝和解封的時間開銷；

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在發(fā)現(xiàn)層，基于主動拓撲實現(xiàn)鏈路管理機制。該機制主要用于監(jiān)測節(jié)點的上下線，在DDS的參與者自動發(fā)現(xiàn)機制的基礎之上，進行了完善， AICC中間件的訂閱發(fā)布節(jié)點上線與下線時，主動調(diào)用相關接口，實現(xiàn)即時主動管理節(jié)點機制。

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

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

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

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