本文作者：極氪軟體及電子中心-托地

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

談起自動駕駛，可能更多的人想到的是AI 技術、如Mobileye 視覺感知、地圖、各類規劃演算法、控制、大資料。目前越來越多的主機廠聚焦於資料如何更高效和準確的通訊，隨著自動駕駛等級從L2 向L2++ 甚至L3/L4 過渡，對於資料傳輸要求越來越高。中介軟體開發和應用一下子被推到了風口浪尖。

談到中介軟體，我們不得不先講一下作業系統OS 。

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

狹義的作業系統大家都比較熟悉，手機裝置上的ios 、Android 、車載系統中Linux 、QNX 都是狹義的作業系統，通常包括核心、檔案系統、驅動以及部分協議棧整合在核心中。

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

 

圖 1 廣義和狹義 OS 框圖

 

回頭再來談談中介軟體。中介軟體是什麼，按字面意思翻譯過來就是中間一層元件。實際是介於作業系統/ 底層軟體和應用軟體之間的橋樑。整個系統軟體可以通過中介軟體在不同的處理器架構和晶片間共享資料。

一套成熟的中介軟體給開發帶來的收益往往是指數級別的進步，大大縮短開發週期和系統穩定度、遮蔽底層硬體差異性做到統一的API 介面。

 

圖 2 自動駕駛中介軟體應用

那麼自動駕駛需要怎樣的中介軟體？低時延、高頻寬和多併發。

從整車功能域角度出發，自動駕駛是收集外部感測器資料量最大的模組，為了持續探測到車身四周各種複雜環境資訊，需要毫米波、攝像頭和鐳射雷達配合以達到360 度無死角感知。並且為了保證安全，所有資料都需要接近實時的速度處理，為了保證大量資料的實時處理，較低的資料延遲需要由高效能的計算單元和高頻寬的網路通訊，資料可輕易在不同核心裡共享。

 

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

 

感測器型別	典型頻寬需求
3D 毫米波	2M/s
4D 毫米波	100M/s
8M 攝像頭	2G/s - 3G/s
100 線鐳射雷達	1G/s

表 1 感測器典型頻寬

 

從上表中可以知道隨著自駕功能不斷升級，對於感測器的傳輸資料頻寬和傳輸延遲要求也在不斷提升。為了滿足此需求，業界各家自駕公司也在開發自己的自動駕駛中介軟體以滿足要求。

 

ICEORYX ：

 

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

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

                 

圖 3 程式間通訊

 

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

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

下面套用一張博世官方介紹材料中的圖，基於共享記憶體的拷貝其實並不是一種創新的通訊機制，但ICEORYX 採用了釋出/ 訂閱架構、服務發現、和計數器相結合的機制。通過新增避免複製的應用程式程式設計介面，實現了所說的真正的零拷貝—— 一種從釋出者到訂閱者的端到端的方法，而無需建立一個拷貝。

 

      

圖 4 零拷貝通訊 （引用 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 。

 

             

圖 5 以 Master 為中心的 ROS 互動機制

 

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

ROS 底層基於DDS （Data Distribution Service ）通訊機制，取消了ROS 上Master 模式。DDS 遵從釋出和訂閱模式，建立全域性的資料塊。然後每一個資料的釋出或者訂閱者都是資料的參與者，可以讀寫全域性的資料。同時也保留了ROS 中Topic 資料結構概念。

             

圖 6 基於 Topic 話題的釋出 / 訂閱流程

 

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

     

圖 7 支援 QoS 策略的 DDS 機制

 

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

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

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

           

圖 8 極氪中介軟體框圖

 

另外ZEEKR OS也正在熱火朝天的開發測試中，作為中央計算SoC核心中介軟體，將管理整車服務（支援自動駕駛、車身電子控制、底盤、三電和智慧座艙等功能持續迭代）、提供基礎平臺、高度分層解耦、分散式管理。

搭載ZEEKR OS的下一代3.0中央計算平臺將採用全棧自研，專注打造一套高效穩定的整車軟體中介軟體，為自動駕駛、SOA和整車OTA服務提供核心競爭力並持續賦能。

 

參考資料：

1.   Michael Pöhnl - Bosch

2.  Simon Hoinkis - Bosch

3.  Cn-ROS Wiki - wiki.ros.org

4.   百度開發者中心 - Apollo ROS 有何不同

5. Exploring the performance of ROS2