1 中間件的概念界定
1968年，德國舉辦了NATO軟件工程大會，會後發表的一份報告中第一次出現了中間件這個術語。中間件是爲應用提供通用服務和功能的軟件。數據管理、應用服務、消息傳遞、身份驗證和API管理通常都要通過中間件。
下文中討論的是智能駕駛操作系統中用於消息傳遞的分佈式通信中間件。分佈式通信中間件在智能駕駛領域有着非常重要的地位。智能駕駛功能如算法及應用一般是多個自主模塊獨立運行，彼此通信實現各種等級的智能駕駛功能。同時，多種智能駕駛功能之間約束和優化、功能安全和信息安全等功能也多以自主模塊形式提供。因此分佈式通信是智能駕駛及其擴展功能的基礎功能，也是系統實時性和可靠性的重要支撐之一。由於智能駕駛域控制器是異構、多芯片、甚至多板卡形式，分佈式通信中間件也需要支持進程及線程之間、跨內核、跨芯片、跨板卡等通信，通信形式也包括可靠和非可靠、同步和異步等方法。
2 智能駕駛領域主流分佈式通信中間件和其架構
目前應用在智能駕駛領域車載操作系統比較主流的分佈式通信中間件有VSOMEIP、DDS、ICEORYX、ROS/ROS2、Apex.OS和AP AUTOSAR。
2.1 VSOMEIP
SOME/IP（Scalable service-Oriented MiddlewarE over IP）是車載以太網通信引入的一個概念，位於OSI 7層模型的層4之上。此中間件是爲典型的汽車用例設計的，並且與AUTOSAR兼容。
VSOMEIP則是寶馬公司基於SOME/IP協議實現的中間件，實現了服務發現以及通信功能，並在此基礎上增加了少許的安全機制。
VSOMEIP通信示意圖（來源https://github.com/COVESA/vsomeip/wiki/vsomeip-in-10-minutes）
如圖所示，VSOMEIP不僅涵蓋了設備之間的SOME/IP通信（跨機通信），還涵蓋了內部進程間通信。兩個設備通過所謂的通信端點進行通信，這些端點將使用的傳輸協議（TCP或UDP）及其參數確定爲端口號或其他參數。所有這些參數都是可以在VSOMEIP配置文件中進行設置。內部通信是通過本地端點完成的，這些端點由UNIX域套接字使用Boost.Asio庫實現。由於這種內部通信不通過中央組件，比如像D-Bus守護程序路由，因此非常快。
2.2 DDS（Data Distribution Service 數據分發服務）
數據分發服務DDS是由OMG組織發佈的一個分佈式實時系統發佈/訂閱模型的規範。這個規範定義了一個以數據爲中心的發佈/訂閱模型，提供了一個獨立於平臺的中間件框架，爲實時系統中數據發佈、傳遞和接收的接口和行爲提供統一標準。它允許應用程序實時地發佈其所能提供的信息，並訂閱所需要的信息。除此之外，DDS還支持許多QoS屬性，如異步、松耦合、實時可靠數據分發等。DDS規範的目的是簡化分佈式系統中數據的有效發佈，它適用於性能要求高、可預見性強的實時關鍵任務領域。
DDS域內通信示意圖（來源eprosima.com）
目前常用的商用DDS實現有RTI的RTIDDS，開源DDS實現有eprosima公司的Fast-DDS，OCI公司的OpenDDS，eclipse公司的Cyclone DDS，Prismtech公司的OpendSplice DDS等。
Fast DDS和Cyclone DDS在延遲性能方面的比較表明，Fast DDS的平均延遲低於Cyclone DDS。此外， Fast DDS也是更穩定的DDS實現，隨着有效載荷變大，延遲增加的速度會變慢。在吞吐性能方面的比較表明，Fast DDS的吞吐量對於每個有效載荷都是最高的，這意味着Fast DDS能夠爲每個有效載荷每秒發送更多給定大小的消息。但是Fast DDS也有不足之處，在多種廠商的DDS實現中，FastDDS不支持部分QoS策略。
SOME/IP和DDS都允許分佈式應用程序使用發佈/訂閱和請求/響應的方式進行通信，但是也存在很大的差異。
SOME/IP作爲AUTOSAR的一部分，開發了一系列規範，描述其序列化協議、服務發現以及集成在CP中的協議標準接口。而DDS應用在更廣泛的工業物聯網領域，是OMG發佈的一系列標準，專門爲分佈式實時系統設計，應用在很多行業，包括航空航天、國防軍工、醫療系統等，在商業和開源領域都有許多獨立的實現。應用程序在使用DDS時，不用像SOME/IP一樣要綁定到特定的服務實現，通過簡單的引用主題和服務，就可以透明地實現一對一和一對多的通信，無需更改代碼，比SOME/IP更加靈活。
DDS基於RTPS協議進行傳輸，可以映射到不同的網絡傳輸協議，RTPS實現了與傳輸無關地可靠性與分段協議，該協議可以在任何傳輸之上運行，因此使用DDS可以通過多播UDP處理大數據和可靠數據，而SOME/IP無法做到這一點。
DDS提供了許多QoS策略，使用戶可以聲明性地指定發佈者與訂閱者之間如何交換性息，比如資源使用、數據優先級、數據可用性等。而SOMEIP僅提供一種用於選擇UDP與TCP的可靠性QoS設置。
2.3 冰羚（ICEORYX）
冰羚實現了真正基於共享內存的“零拷貝”數據傳輸，將共享內存與發佈/訂閱架構、服務發現機制、C ++以及無鎖算法（lock-free algorithms）相結合。通過添加避免複製的應用程序接口，實現了真正的零拷貝，即數據從“發佈者”到 “訂閱者”的端到端傳輸過程中，無需創建任何數據副本。
冰羚零拷貝示意圖（來源GitHub - eclipse-iceoryx/iceoryx: Eclipse iceoryx™ - true zero-copy inter-process-communication）
在使用實現“零拷貝”的共享內存中間件冰羚後，系統的運行時間和延遲跟傳輸的數據量脫離關係。換句話說，系統可以在一定時間內實現幾乎無限的數據傳輸。
但冰羚在使用上稍顯複雜。首先，用戶在使用訂閱發佈之前，必須啓動一個守護進程，用於管理共享內存以及管理節點發現；其次，在發佈數據之前需要先獲得一塊能夠存放數據的內存地址，用戶也只能使用定長數據進行傳輸；此外，冰羚跨機通信依賴於Eclipse公司的Cyclone DDS。
2.4 ROS1/ROS2（Robot Operating System）
ROS 名爲機器人操作系統，但它並不是真正的操作系統。最好將其理解爲用於開發機器人應用程序的軟件開發工具包 (SDK)：它提供開發、調試、測試和最終部署機器人應用程序所需的軟件、庫和工具。
ROS1與ROS2的架構對比圖（來源於網絡）
ROS1與ROS2的架構如上圖所示，ROS1中依賴Master註冊獲取節點信息，而ROS2實現了去中心化。ROS2 的應用框架總體分爲三個部分，應用層、中間件層和操作系統層。RCL 是中間件層與用戶層程序直接交互的接口。RMW 接口層抽象了 DDS的具體實現，可根據用戶需求，切換不同的 DDS 實現。ROS2 根據通訊邊界，分別做了不同的實現，進程內通訊由 ROS2 實現，際間通訊（進程間和跨機通訊）則採用 DDS實現。這樣的通信策略是由於部分 DDS 的進程內通信仍使用迴環地址的網絡通訊方式，數據要進行用戶態與內核態的拷貝，且通訊受限於協議棧，通訊效率低。
ROS的優勢：
- 每個供應商提供的DDS接口都不同，如果要更換供應商，則需要更改代碼，而ROS提供了一層中間層，使面向用戶的接口不變，易於更換底層DDS供應商。
- ROS2爲需要創建應用程序的用戶提供了生態系統、文檔和友好的框架，提供了比DDS更高級別的抽象，因此ROS2更側重於應用程序開發，消除了不同DDS的複雜訂閱發佈應用程序編寫的困難。
- ROS2不僅僅是實現了通信層的功能，它還提供了機器人技術中常用的包，從基本的座標系轉換包到高級的生成環境地圖並依此對機器人導航的應用程序；
- 提供了構建系統，從ROS1的catkin到ROS2的colcon，可以輕鬆的構建包，並指定各個包之間的依賴關係
- 提供了一個啓動系統，可以輕鬆運行由多個互相依賴的應用程序組成的複雜系統，並提供一種更輕鬆的修改參數的方法；
- 提供了豐富的調試工具，包括回顯工具、播包錄包工具、以及可視化工具等。
但是，需要注意的是，使用ROS2而不是原生的DDS也會產生成本，ROS2只支持底層各個供應商DDS都支持的QoS策略子集，因此直接使用ROS2無法訪問某些DDS的功能和QoS策略。DDS面向應用程序提供的功能要廣泛得多，接口和QoS的使用也更加通用、靈活。
2.5 Apex.OS
與ROS一樣，Apex.OS並不是真正的操作系統，而是一套軟件開發框架，但Apex.OS是經過安全認證的軟件開發框架。Apex.OS由Apex.AI公司推出，是爲移動設備、智能機器和IoT準備的，基於ROS2開發的汽車操作系統。
Apex.OS對ROS2進行改造，修復了ROS2的一些bug，同時給上游提供監控節點；增強實時性、可靠性以及確定性；和ROS2未來的release同步，保持API兼容。Apex.OS Cert產品通過了ISO26262 Seooc功能安全認證，最高支持ASIL-D，基於Apex.OS可以開發安全相關應用。
Apex Middleware是由Apex.AI推出的能夠滿足汽車通信需求、支持機器內部通信、支持跨機器通信、支持雲端通信的通信中間件。核心組件基於Eclipse Cyclone DDS™ 的高魯棒性、高性能網絡通信和 Eclipse iceoryx™的高效零拷貝通信，它們都是開源項目，並且在汽車和任務關鍵型分佈式系統中得到驗證。Apex Middleware和Apex.OS高度優化集成，也可作爲一個獨立產品。
Apex. Middleware的優勢如下：
- 具有跨ECU/ECU內部通信完整的，集成化的解決方案；
- 已經集成到了通用的框架，比如ROS 2，Apex.OS，AUTOSAR Adaptive；
- 支持DDS和SOME/IP，當前汽車以太網最相關的協議；
- 支持發佈/訂閱和請求/響應通信；
- 能高效處理海量數據，滿足駕駛輔助和智能駕駛應用的數據傳輸需求；
- 低運行時開銷的高性能通信；
- 通信發現機制，用於支持現代化的SOA；
- 基於ISO26262的安全認證；
- 大量的QoS特性；
- 提供有效的橋接至網絡協議，比如MQTT、AMQP、OPC-UA、Eclipse Zenoh。
2.6 AUTOSAR AP
AUTOSAR Adaptive Platform（AP） 是 ARA（AUTOSAR Runtime for Adaptive Applications）的實現。如下圖所示爲AP架構邏輯視圖。
AP模塊示意圖（來源《AUTOSAR AP規範Platform Design》）
AP包含執行管理、通信管理、狀態管理、診斷管理、網絡管理等模塊，我們這裏重點討論與通信管理相關的中間件模塊。通信管理提供了機器內以及機器間面向服務的通信，包括Event、Method和Fields，可以在設計時，啓動時或運行時建立通信夥伴之間的通信路徑。該機制的重要組成部分是服務註冊中心，它充當中介實例，並且也是通信管理軟件的一部分。
AP面向服務示意圖（來源《AUTOSAR AP規範Platform Design》）
提供服務的每個應用程序都在服務註冊表中註冊這些服務。要使用服務，應用程序需要通過查詢服務註冊表來找到請求的服務，此過程稱爲服務發現。
通信管理提供了標準化的手段，將定義的服務呈現給應用程序實現者（上層，語言綁定）以及網絡上服務數據的相應表示（下層，網絡綁定）。這確保了源代碼的可移植性以及跨平臺的不同實現的已編譯服務的兼容性。
語言綁定定義如何通過使用目標編程語言的便捷功能將服務的Method，Event和Field轉換爲可直接訪問的標識符。性能和類型安全性（就目標語言所支持的程度而言）是主要目標。因此，語言綁定通常由Service Interface定義提供的源代碼生成器實現。
AP通信模塊網絡綁定示意圖（來源《AUTOSAR AP規範Platform Design》）
網絡綁定定義瞭如何將已配置服務的實際數據序列化並綁定到特定網絡。可以基於通信管理配置（AUTOSAR元模型的接口定義），通過解釋生成的服務特定配方或直接生成序列化代碼本身來實現。當前，通信管理支持SOME / IP，DDS，IPC（進程間通信或任何其他自定義綁定）和Signal PDU（基於信號的網絡綁定）。
AUTOSAR AP的優勢在於層次化和模塊化、配置化、接口標準化。
- 層次化和模塊化：AUTOSAR將硬件依賴和非硬件依賴的軟件進行了封裝，同時模塊的層次處理也收集了先進廠家的經驗，分享出一個穩定可靠的算法模塊框架；
- 配置化：如果使用工具鏈進行開發，目前的基礎軟件已做到通過配置參數實現功能剪裁，算法邏輯，提高了基礎軟件開發效率；
- 接口標準化：有利於降低軟件的移植成本。
AP的劣勢在於：工具鏈昂貴且不成熟，供應商不多，且在使用過程中不斷髮現、修改BUG。同時不同工具鏈廠商之間沒有做好兼容性設計，影響了複用性和獨立性。
3 中間件的關鍵技術
分佈式通信中間件需要在分佈式的環境中，實現各節點之間數據的正確、高效分發。單個節點需要保持較高的獨立性，各個節點之間的耦合度降到最低，任何一個節點產生的異常不影響整個系統的運行。
一次數據的傳輸過程需要完成如下任務：用戶消息的發佈與訂閱；消息的發現與識別；配對節點的選擇與數據鏈路的建立；消息的高效傳輸；傳輸過程中對節點狀態的實時監控；用戶取消訂閱或發佈時，數據鏈路的釋放與重建。
因此，分佈式通信中間件需要實現鏈路動態管理、數據高效管理以及系統實時性等關鍵技術。對於鏈路管理，其難點主要體現在鏈路的動態建立及正確地釋放；對於數據管理，其難點主要在於找到適當的消息組織方法，以解決消息的高效存取、消息優先級的實現、消息的本地零拷貝、多線程安全以及消息保存的問題；對於實時性的實現，其難點則主要在於攻克高效的本地消息組織方法、節點之間消息投遞方式以及節點對消息的處理模式。
3.1 鏈路管理
鏈路管理難點主要體現在鏈路的動態建立及正確的釋放。數據鏈路建立的過程就是發佈訂閱的配對過程。系統初始並不知道哪些節點會形成發佈/訂閱關係，而且發佈訂閱關係也是隨節點運行情況動態變化的。這要求發佈者/訂閱者之間的數據鏈路必須根據節點運行狀態動態建立，用來適應節點運行變化。可以採用詢問/應答/確認（三次握手）、定時器技術以及超時重傳解決鏈路建立的問題，如下圖所示。
3.2 數據管理
數據管理難點主要在於找到適當的數據組織方式，解決數據的便利存取、優先級的實現、數據本地零拷貝、多線程的安全以及數據保存的問題.
3.2.1 內存數據組織
對於內存數據組織，可以採用隊列技術、定時器技術以及鎖機制實現一個高效的消息隊列來對數據進行管理，滿足了系統對消息管理的要求，其實現基於如下兩個類：
Message_Node：代表隊列中的一個節點，內部分配緩衝區用以保存需要管理的消息數據。一個Message_Node對象實例管理着一條消息數據。該類提供接口設置信息的優先級，用以實現在隊列中根據優先級排隊。
Message_Queue：消息隊列，由很多Message_Node連接而成。內部採用了定時器技術來實現進隊、出隊的定時，進隊、出隊操作會一直阻塞到操作成功或者超時失敗，從而避免了一直阻塞導致系統無法工作。採用互斥量技術或無鎖操作來對多線程操作隊列進行同步，保證進隊、出隊操作的多線程安全。同時提供了put_prior接口實現按優先級進隊，操作會根據MessageNode實例的優先級將其插入到隊列的合適位置，而不是始終插入到隊尾，從而實現數據的按優先級排序。更重要的是隊列不直接管理Message Node實例，而是管理Message_Node實例的指針，從而避免了進隊出隊的拷貝操作，實現了數據本地零拷貝，減小了系統開銷。Message_Queue對Message_Block的管理如下圖所示。
3.2.2 消息數據持久性
消息數據持久性策略主要解決節點之間時間耦合問題。對於每一個主題消息數據，均可以配置其持久性用以決定主題消息數據是否可重現，具體會存在四種策略：
- 實時消息數據：系統不保存消息數據，發佈方生產出消息數據則直接交付系統投遞，投遞時在線的訂閱者可獲得該消息數據，不在線的節點則不能獲取到消息數據，消息數據沒有重現性。
- N條有效：系統在內存中保存最新的N條消息數據。後加入的訂閱者可以獲取到這N條歷史消息數據，這裏的N可以由用戶設置。
- N秒有效：指的是消息數據從生產出來的時刻算起，有N秒的存活時間，一旦時間超過N秒，則消息數據失效。系統保存所有尚未失效的消息數據。後加入的訂閱者可以獲取到還存活的歷史消息數據，這裏的N可以由用戶設置。
- 永久保存：即保存所有該主題消息數據，後加入的訂閱者可以獲取到所有的歷史消息數據。
3.2.3 系統實時性
高實時性一直是分佈式通信中間件系統的終極目標，衡量實時性的一個最直觀的變量就是數據從生產者生產出數據到消費者獲取到數據之間的時間間隔。
- 該時間間隔包括以下過程產生的時間開銷：
- 數據封裝、進入隊列阻塞的時間開銷；
- 出隊的時間開銷；
- 出隊的數據進入到本地物理網絡傳輸媒介的時間開銷；
- 數據在兩個節點之間的物理媒介傳輸的時間開銷；
- 數據從本地物理媒介到操作系統用戶空間時間開銷；
- 從用戶空間進入接收隊列的時間開銷；
- 在接收隊列的等待時間
針對以上時間開銷可以採取以下的優化措施：
- 採用簡單應用層協議，減小封裝和解封的時間開銷；
- 採用多線程技術，減小數據入隊出隊的時間開銷；
- 採用消息隊列管理數據指針，減少數據在本地內存的拷貝；
- 消息數據進行點對點傳送，不經過中間節點轉發，避開廣播，緩解網絡擁塞從而減小數據在網絡之間的傳輸時間；
- 採用優先級技術和消息數據質量衡量技術，對消息數據進行分級，過濾掉質量比較低的不符合用戶需求的消息數據
4 AICC中間件的架構與實現
4.1 AICC中間件分層架構
AICC中間件分層架構圖
AICC中間件分層架構圖如上圖所示，分爲通信層、發現層和用戶層。通信層的進程間與進程內通信是由基於共享內存的零拷貝技術實現的，跨機通信是基於DDS實現的，用於用戶數據的傳輸；發現層是用來進行進程內、進程間、跨機通信的發佈者/訂閱者之間的數據鏈路建立；用戶層用來定義中間件的對外接口。
4.2 AICC中間件實現的功能
AICC中間件實現的功能有訂閱/發佈、請求/響應兩大功能，對兩大功能的數據傳輸過程進行描述。
AICC中間件訂閱/發佈數據流傳輸過程表示
AICC中間件訂閱/發佈數據流傳輸過程如上圖所示。在發現層中，會建立一個網絡拓撲結構管理整個域內的節點、訂閱者與發佈者，他們可以主動加入或退出網絡拓撲關係。假設訂閱節點先於發佈節點上線，當對應的發佈節點上線時，會根據拓撲結構裏訂閱節點的位置，創建所需的真實發布傳輸通道。通信層的進程內與進程間通信都是通過零拷貝技術實現的，真正實現了基於共享內存的數據零拷貝。同時支持定長與變長數據的傳輸，傳輸速度在GB/s級，延遲在us級。而跨機通信是基於DDS實現的，同時實現了與ROS2的互聯互通，因此可以利用ROS2的工具，比如ros2 topic list/hz/echo、ros2 bag record/play等。還通過開發一層簡單的Adapter層，就可實現基於RVIZ的消息可視化功能，爲後期調試提供便利。
AICC中間件請求/響應數據傳輸過程表示
同時，AICC中間件除了訂閱/發佈功能，還實現了請求/響應功能，如上圖所示。請求響應功能是基於兩對訂閱/發佈實現的，因此，與訂閱發佈功能採用的通信方式類似，根據Client和Server所處的位置，建立不同的傳輸協議，進程間與進程內的請求響應也可以實現基於共享內存的數據零拷貝，而跨機依舊依賴於DDS。
請求響應功能實現方式如下，Client端通過Request Topic將某種類型的請求消息傳遞給Server端，Server端收到請求消息後根據用戶傳入的處理方法，請求消息處理得到響應消息，並通過Reply Topic將消息傳遞到Client，至此用戶請求操作之後獲取到響應消息。
4.3 AICC中間件的優勢
AICC中間件的優勢有以下幾個方面：
在發現層，基於主動拓撲實現鏈路管理機制。該機制主要用於監測節點的上下線，在DDS的參與者自動發現機制的基礎之上，進行了完善， AICC中間件的訂閱發佈節點上線與下線時，主動調用相關接口，實現即時主動管理節點機制。
在通信層，針對進程間通信，AICC中間件實現了基於共享內存的零拷貝，使得進程間通信發佈訂閱的只是真實消息數據的地址，對於延遲和吞吐量的提升有一個質的改變，因此延遲時間在us級別，吞吐量在GB/s級別，性能提升很大。對於跨機通信，AICC中間件是基於DDS實現的，對於該實現也能夠保證在每個機器部分能夠實現消息數據的零拷貝，同時重寫序列化與反序列化函數，把不同的數據類型均當作字節流來處理，因此跨機通信的性能也有一定的提升。
同時，在通信層的跨機通信中，AICC中間件通過提供與ROS2序列化與反序列化規則相同的序列化與反序列化函數，建立與ROS2通信的傳輸器，實現了與ROS2的互聯互通。
在用戶層，AICC中間件爲用戶提供的是C接口，方便用戶更高層級的封裝使用。同時，由於在通信層實現了與ROS2的互聯互通功能，在用戶層可以複用ROS2幾乎全部的工具，比如ros2 topic、ros2 bag以及rviz可視化工具，大大方便了用戶的使用。
作者陽陽，多年智能駕駛研發經驗，碩士期間從事鉸接礦用自卸車的環境感知工作，畢業後專注車載操作系統中間件的研發，擅長基於FastDDS、ICEORYX等中間件進行二次開發。