隨著國內外新勢力車廠的快速崛起，汽車智能化水平不斷提升。整車中央計算平臺，自動駕駛域控制器持續走熱。

談起自動駕駛，可能更多的人想到的是AI技術、如Mobileye視覺感知、地圖、各類規劃算法、控制、大數據。目前越來越多的主機廠聚焦于數據如何更高效和準確的通信，隨著自動駕駛等級從L2向L2++甚至L3/L4過渡，對于數據傳輸要求越來越高。中間件開發和應用一下子被推到了風口浪尖。 談到中間件，我們不得不先講一下操作系統OS。

操作系統有廣義和狹義之分。

狹義的操作系統大家都比較熟悉，手機設備上的ios、Android、車載系統中Linux、QNX都是狹義的操作系統，通常包括內核、文件系統、驅動以及部分協議棧整合在內核中。

廣義的操作系統一般包含操作系統內核、硬件驅動層和中間件。在各家新能源車廠高談軟件定義汽車時代已到來時，真正能全面掌握芯片、操作系統、中間件、算法以及常用常新的應用才能走在技術最前沿。其中廣義操作系統是核心中的核心，已成為國內外主機廠自主研發比拼的方向。 

圖1廣義和狹義OS框圖 

回頭再來談談中間件。中間件是什么，按字面意思翻譯過來就是中間一層組件。實際是介于操作系統/底層軟件和應用軟件之間的橋梁。整個系統軟件可以通過中間件在不同的處理器架構和芯片間共享數據。

一套成熟的中間件給開發帶來的收益往往是指數級別的進步，大大縮短開發周期和系統穩定度、屏蔽底層硬件差異性做到統一的API接口。 

圖2自動駕駛中間件應用

那么自動駕駛需要怎樣的中間件？低時延、高帶寬和多并發。

從整車功能域角度出發，自動駕駛是收集外部傳感器數據量最大的模塊，為了持續探測到車身四周各種復雜環境信息，需要毫米波、攝像頭和激光雷達配合以達到360度無死角感知。并且為了保證安全，所有數據都需要接近實時的速度處理，為了保證大量數據的實時處理，較低的數據延遲需要由高性能的計算單元和高帶寬的網絡通信，數據可輕易在不同內核中共享。

圖3 自動駕駛360度傳感器感知示意圖 

 表1 傳感器典型帶寬

從上表中可以知道隨著自駕功能不斷升級，對于傳感器的傳輸數據帶寬和傳輸延遲要求也在不斷提升。為了滿足此需求，業界各家自駕公司也在開發自己的自動駕駛中間件以滿足要求。 

ICEORYX： 

博世在量產ADAS領域裝配率長期占據市場前三的份額，他們對于如何將自動駕駛數據高效流轉的需求更為迫切，為此在大神Michael P?hnl帶領下，專門為自動駕駛開發了一套中文名叫“冰羚”，英文名ICEORYX的中間件。 

如上面所說，大量自動駕駛相關的感知數據需要在整個系統內完成快速的流轉，這里就不得不提一下進程間通信（Inter ProcessCommunication）這個概念。拿大家最常用的Linux系統舉例，不同進程之間傳播或交換信息，由于不同進程地址空間相互獨立，傳遞數據時不停的來回拷貝數據，建立和釋放堆棧，這個不生成任何價值的拷貝的過程浪費和占有了大量系統資源并產生了不期望的延遲。 

圖4 進程間通信 

ICEORYX為了解決上面的問題，設計了一種“零拷貝”的內存共享技術來優化之前ADAS量產項目中遇到的困擾。 

這種“零拷貝”通過事前定義好的通用接口，將需要消費的數據（圖片原始RGB或者激光點云數據）放入由ICEORYX申請好的內存空間，然后引入“記數器”這個概念，來記錄內存空間中各塊數據是否被調用還是釋放，當計數器為0時，就表示該塊數據可以被釋放。這樣所有的數據調用都發生在共用的內存區域中，免去了各進程將數據拷貝到自己私有存儲內，大大提高了數據通信的效率。 

下面套用一張博世官方介紹材料中的圖，基于共享內存的拷貝其實并不是一種創新的通信機制，但ICEORYX采用了發布/訂閱架構、服務發現、和計數器相結合的機制。通過添加避免復制的應用程序編程接口，實現了所說的真正的零拷貝——一種從發布者到訂閱者的端到端的方法，而無需創建一個拷貝。

 圖5 零拷貝通信（引用1） 

發布者將數據寫入事前申請好的內存塊中，訂閱者可以收到這些內存塊的實時狀態，并且知道哪些內存塊正在處理中，哪些內存塊將被釋放。發布者可以在訂閱者讀取數據塊的時候同時再次寫入而不收到任何時間干擾和延遲，因為即使之前的內存塊在被讀取中，發布者也可以選擇之前已經分配好的新的內存塊中操作。 

ICEORYX是開源的，遵從Apache-2.0許可證。任何個人或者團隊都可以免費使用源代碼，但如果需要過ASIL-B或ASIL-D等級功能安全認證，那還需要從博世購買相關的安全服務。 

目前對于ICEORYX這套中間件來說最大的挑戰還是需要有主機廠快速搭載量產車上市，來真正檢驗其價值。另外由于自動駕駛感知信息種類越來越多，激光點云數據、攝像頭RGGB幀、3D毫米波雷達目標信息以及4D毫米波雷達點云信息，整車信號數據等，如何高效申請和分配內存塊也是實現真正“零拷貝”的前提，這少不了在實際項目中不斷打磨優化。 

ROS2：

接下來我們再來看一下大名鼎鼎的ROS2。

說到ROS2不得不先聊一下ROS(Robot Operating System), ROS2正是從ROS發展升級過來的。ROS最早開發出來是去適配機器人的一套開源軟件系統，里面包含3000多個基礎庫、靈活的進程間通信機制、底層驅動、硬件抽象等。

如前文所述，自動駕駛是非常復雜并對安全性要求很高，它包含了車道線檢測、目標物檢測、障礙物檢測、決策、控制模塊等；需要將這些功能各異的模塊集成到一起，形成一個端到端系統。所以要找到一個適合的中間件框架很不容易，ROS在學術界和機器人屆廣泛使用、消息機制靈活開發以及豐富調試工具恰恰符合自動駕駛開發的需求。我們看到國內自動駕駛黃埔軍校百度在早期Apollo1.0/2.0版本中正是選用了ROS框架。

但是在實際開發應用中，開發人員發現了ROS適配自動駕駛的不足之處。比如ROS通信延遲太大，數據從發布節點到訂閱節點之間需要進行拷貝，在機器人設計中可能還不是一個Block點，但在自動駕駛系統中很顯然會大大影響數據的傳輸效率。另外ROS的單Master節點機制也是一個瓶頸，所有的子節點通信都需要借助單一的通信主節點。萬一主節點出現故障，整個系統也會受到影響。為了解決ROS的明顯缺陷，百度Apollo在3.5版本后發布了自研的Cyber RT框架來取代ROS。  

圖6 以Master為中心的ROS交互機制 

ROS社區和組織也意識到了不足之處，并于2016年底正式發布了ROS2 beta版，新一代的ROS之中，帶來了整體架構的革新以解決前一代的不足。

ROS底層基于DDS（Data Distribution Service）通信機制，取消了ROS上Master模式。DDS遵從發布和訂閱模式，創建全局的數據塊。然后每一個數據的發布或者訂閱者都是數據的參與者，可以讀寫全局的數據。同時也保留了ROS中Topic數據結構概念。

圖7 基于Topic話題的發布/訂閱流程 

另外DDS一個重要特質是支持QoS（Quality ofService），滿足在不同場景對于不同數據傳輸的實時性要求。每個數據傳輸都可以通過QoS策略選擇不同的選項進行配置，ROS2中支持傳輸期限、可靠性傳輸、歷史信息等策略。     

圖8 支持QoS策略的DDS機制 

當然目前ROS2整體穩定度和應用案例還遠不如ROS，但擁有了以上特性的ROS2系統，我們拭目以待。

極氪軟件和電子中心，秉承平等、多元、共成長的價值觀，對產品持續極致追求，為用戶提供用心體驗。從中央計算、智能區域控制器、整車OTA、智能車身控制、整車軟件等領域出發，打造行業頂級的電子電氣架構，為智能電動車保駕護航。 

目前我們一直在開發中央計算和區控制器內高效IPC通信并應用在量產項目中，除了會包含上面提到的共享內存和DDS技術外，還會用到SOME/IP協議來加強不同服務數據之間的傳輸效率。   

圖9 極氪中間件框圖 

另外ZEEKR OS也正在熱火朝天的開發測試中，作為中央計算SoC核心中間件，將管理整車服務（支持自動駕駛、車身電子控制、底盤、三電和智能座艙等功能持續迭代）、提供基礎平臺、高度分層解耦、分布式管理。 搭載ZEEKR OS的下一代3.0中央計算平臺將采用全棧自研，專注打造一套高效穩定的整車軟件中間件，為自動駕駛、SOA和整車OTA服務提供核心競爭力并持續賦能。