L2 及以下級別的自動駕駛功能基本上都是屬于“駕駛輔助”性質。各功能的場景，主要的駕駛行為是駕駛員主導，自動駕駛系統(tǒng)只在非常限定的條件約束內對車輛進行操作。而且這些約束條件所形成的場景基本上是各自獨立的，這也就是各功能能夠由不同供應商獨立開發(fā)的原因之一。

作為早期賦能自動駕駛行業(yè)的汽車智能化科技企業(yè)，未動科技自成立以來始終專注于打造高級別汽車自動駕駛的視覺感知算法、高實時性與高可靠性的系統(tǒng)軟件平臺及異構計算引擎。高級別自動駕駛即L3 開始逐步主導車輛的駕駛，與L2 有了根本性的變化。L3級別就要求在良好的路況環(huán)境下，大多數(shù)操作將由汽車為主導，車輛將自動完成自適應巡航、車道居中保持、自動變道、自動駛入（駛出）高速匝道等一系列操作。駕駛員只需要在必要的時候對汽車進行干涉。當然這就對自動駕駛系統(tǒng)的硬件算力，傳感器配置，各種感知、規(guī)劃、控制算法都提出了更高的要求。

未動科技作為一家汽車智能化科技企業(yè)，在自動駕駛技術中，更加關注如何提高硬件的算力，尤其是能支持深度學習的算法能力，如何開發(fā)更好的感知算法等等，然而如何讓這些得到大大提升的各專項能力能協(xié)同工作卻很少被特別提及。我們需要的不僅僅是車輛運行過程中，各種自動駕駛功能關聯(lián)的技術模塊能協(xié)同工作，還要考慮這些不同的技術模塊在開發(fā)階段如何能進行有效的分解，因為不同技術模塊往往是完全不同的技術領域，需要不同的專業(yè)團隊（或供應商）去完成。如果能把這些技術模塊“拆得開”又“裝得上”就是軟件架構需要解決的問題。

正因為從 L2 到 L3 的跨越難度太大，所以人們在 L2的軟硬件架構上修修補補，在不改變核心架構邏輯的基礎上盡量增加一些新的功能，才有所謂的 L2．5。然而在L2原生架構上的修補能力終有盡頭，必須有新的架構來支持 L3及以上的自動駕駛。

L2 自動駕駛軟件架構的瓶頸

多個獨立功能的自動駕駛控制器 ＋ 域控制器的方案，多用于 L2 和 L2．5 的開發(fā)，其在軟件架構上的瓶頸至少有以下幾點：

1． 多個獨立的控制器導致計算資源不能協(xié)調調度，導致算力浪費與匱乏并存。比如全自動泊車輔助功能和 ACC／AEB 功能并不是同時啟用的，速度超過20公里后，泊車輔助功能停止執(zhí)行，ACC／AEB 可以啟用。但是泊車輔助系統(tǒng)的算力并不能用于 ACC／AEB功能。低速情況下又恰好相反。

2．自動駕駛域內的通訊延遲。多控制器之間只能通過總線進行通訊帶來一定的數(shù)據(jù)延遲。如果使用高速 Can 總線（1Mbps）， 一個毫米波雷達每周期傳遞30個目標，就能達到總線負載的50％。

3． 各控制器的自動駕駛功能沒有一致性的架構設計，只能通過信號進行數(shù)據(jù)通訊，通過域控制器進行協(xié)調。當堆疊更多功能后，復雜度難以維護。

4． 基于功能（ACC，LKA，TJP等等）的設計方式，難于應對 L3 以上需要的基于場景調度，實現(xiàn)功能越多，功能的邊界越難定義，沒有一致的架構設計，并行運行的功能會造成復雜度指數(shù)上升。

5． 各獨立控制器之間無法有效的進行通用組件的共享，各自重復造輪子。

6． 各控制器的功能實現(xiàn)無法利用其它控制器計算的感知結果，造成資源的浪費。

正是在這些問題的背景下，自動駕駛的域控制器越來越集中化，也就是要將這些控制器集中到一個高性能的域控制器中。即使域內還有其他的控制器，那也基本上是低智能的，一般只做某個單項的感知，獲取原始數(shù)據(jù)。但是感知算法仍然在域控器內完成。這樣高度集中后，高性能的域控制器就需要有新的軟件架構。

L3＋自動駕駛軟件架構鳥瞰圖

未動科技創(chuàng)新的L3＋軟件架構基于滿足高性能域控制器的需求而提出。自動駕駛域控制器是一個非常復雜的系統(tǒng)，其軟件架構涉及非常多的方面，從一個單一的維度很難準確理解整體結構。下圖從三千米高空鳥瞰，從三個正交的維度描述整體的軟件架構。

“正交”是一個數(shù)學概念，是垂直的泛化含義。這里表示兩個分類的維度是獨立不相關的。

圖1未動科技軟件架構鳥瞰圖

2．1未動科技L3＋軟件架構：“層級”維度

從左到右層級逐步升高，每一層依賴其左邊的那一層才能完成工作。雖然本文是講軟件架構，但把硬件也放在圖里方便理解，畢竟軟件依賴硬件。首先，從兩個角度理解每一層的作用：

1． 這一層做什么

2． 這一層不做什么

表格 1未動科技軟件架構層級

2．2 未動科技L3＋軟件架構：“實時域”和“性能域”的分工

自動駕駛中，越是到末端的，規(guī)劃和控制的實時性要求就越高。硬實時要求在確定的時間內響應、確定的時間內完成。這需要由硬件和計算機OS一起提供基礎的保證。一般采用在 MCU上運行相對簡單的實時系統(tǒng)來實現(xiàn)。MCU的計算能力有限，其算力資源對于基于機器學習的視覺算法需求差了幾個數(shù)量級。所以需要集成了高性能CPU和 AI 算力資源的 SoC來滿足高性能計算的需求。這樣就被劃分出來了“實時域”和“性能域”。在性能域，運行的計算機OS一般達不到硬實時要求，而是盡量滿足軟實時要求。比如Linux 就有支持實時性的內核補丁。但也并不是打了實時補丁就具備了實時性，還需要基于 Linux 的應用程序利用實時補丁提供了的能力。

在上面的三維度圖中，“分工”與“層級”這兩個坐標軸是正交關系。也就是說“層級”軸上的每一段在“實時域”和“性能域”都有對應的標的物。每一個標的物往往對應于一個具體的軟件產品。下表列出了一些組合例子：

表格 2 產品劃分示例

Classic AutoSar 比較特殊，它屬于實時域，但是在層級軸上橫跨了兩層。

2．3 未動科技L3＋軟件架構：切面

切面“Aspect”是軟件架構中的一個概念。編程范式中有一個概念叫“面向切面的編程”（AOP， Aspect Oriented Program）。其基本含義在軟件架構上把軟件的功能分為“核心業(yè)務”和“周邊業(yè)務”：

核心業(yè)務是指完成實際業(yè)務邏輯的功能體系，比如算法執(zhí)行，場景切換等等。

周邊業(yè)務是指那些即使沒有實現(xiàn)，也不會影響核心業(yè)務執(zhí)行的功能。比如說性能統(tǒng)計，信息安全等。并不是說這些功能不重要，而是說將它從核心業(yè)務邏輯中區(qū)分出來后，方便更好的理解和實現(xiàn)核心業(yè)務。同時可以把相同切面的的周邊業(yè)務能夠以更全局的視角進行統(tǒng)籌設計和實現(xiàn)，能為對應切面設計合適的專有架構，再與核心業(yè)務整合。

在上面的三維度圖中，D 軸和 L 軸 構成的平面中的每一個交叉點是一個產品，這個交叉在A 軸上映射就是這個產品在對應切面需要實現(xiàn)的功能。比如 D．R ＋ L．HW 代表的硬件MCU，在 A．FuSa 平面需要達到 ASIL－D 等級。因為 D 軸和 L 軸的每一個交叉點涉及的軟件技術差別很大，其投影在 A 軸上每一個平面上的需求點，采用的技術方案也差別非常大。

所以在系統(tǒng)開發(fā)時（V 模型左上角的系統(tǒng)開發(fā)階段），可以對某一個切面提出整體的設計要求。但是落實到每一個 DL軸交叉點時，應該由該交叉點對應的產品開發(fā)團隊分別實現(xiàn)。不可能由一個團隊實現(xiàn)一個完整切面的所有功能。

ROS／ROS2 與“中間件”

因為 ROS／ROS2 經(jīng)常用來自動駕駛系統(tǒng)的原型開發(fā)，所以結合上面的三維度圖，我們討論一下 ROS／ROS2 的位置，以及它能否用于自動駕駛量產的問題。

首先先澄清一下OS的概念，ROS 是機器人操作系統(tǒng)，雖然名字中有 OS的字母，但此 OS 非彼OS。一般來講 OS，狹義上是專指計算機操作系統(tǒng)，如 Windows， Linux， MacOS， RTOS 等等。為避免歧義，本文中都不用簡寫，都完整地寫作“計算機OS”或“計算機操作系統(tǒng)”。廣義的OS，為某一個專業(yè)領域提供了一套軟件的解決方案和應用接口，該專業(yè)領域的用戶可以基于此接口簡化領域相關的開發(fā)，那么可以把這個解決方案軟件體系稱為領域特定的OS。ROS 就是用于解決機器人軟件開發(fā)的領域特定OS。但實際上，使用ROS或ROS2寫的應用程序只是運行在計算機OS之上的進程，但是鏈接了 ROS／ROS2 提供的庫。ROS／ROS2也提供了方便機器人開發(fā)的軟件包，比如某些算法或者坐標轉換的工具庫。

因為一輛自動駕駛的汽車，從某種意義上來說，也是一個自動駕駛的機器人，所以可以使用 ROS／ROS2 來做自動駕駛的原型開發(fā)，而且ROS／ROS2 的生態(tài)中有很多方便的工具能夠給開發(fā)提供很多便利。

在上面的三維度圖 中，ROS／ROS2的位置在 （D．P ＋ L．BSW） 的交叉區(qū)域內并向（D．P ＋ L．FW） 區(qū)域有一定擴展。但是，它只是覆蓋了這個兩個區(qū)域的一小部分。而且在 A 軸上幾乎沒有實現(xiàn)什么特性。

3．1 ROS／ROS2 在 （D．P ＋ L．BSW）中的地位

在上表中詳細描述了 L．BSW（車載控制器基礎軟件）層需要做的工作，與通訊網(wǎng)絡設備的概念相映射，很大一部分是管理平面的工作，然后還很重要的一點就是要提供通訊的能力。一般還會提出基于 L．BSW的功能開發(fā)應用的框架形式的規(guī)范。ROS／ROS2 實際上主要提供了 L．BSW 層中的通訊支持能力，通過發(fā)布訂閱模式能讓各個應用節(jié)點解耦合。車載控制器需要的基礎管理能力 ROS／ROS2中都很少有實現(xiàn)。

有些人以為 ROS2 不能用于工業(yè)化量產的車載控制器是因為通訊實時性不夠。這是一個理解上的誤區(qū)。ROS2本來就不是為實時域設計的，如果一定要把實時性要求高的車輛控制算法運行在 ROS2中，那是軟件設計的錯誤（原型系統(tǒng)沒關系，量產不行），而不是ROS2的問題。ROS2能否用于量產的智能駕駛控制器？答案是可以，前提是補齊 L．BSW層所需要完成的所有功能，補齊 A 軸所有切面要求的特性。這實際上是基于 ROS2的架構去實現(xiàn)一套 AP AutoSar 規(guī)范。這可以成為一個單獨的產品，投入時間＋人＋錢可以開發(fā)出來，只是看有沒有必要，值不值得。

3．2 ROS／ROS2 在 （D．P ＋ L．FW）中的地位

ROS／ROS2 確實實現(xiàn)了一個機器人開發(fā)的應用框架并提供了很多基礎組件，大大便利了機器人應用的開發(fā)。但是目前的機器人應用都是在一個很小的區(qū)域內移動。一般范圍比較大的是倉庫機器人，運動范圍也就在百米數(shù)量級，場景也比較單一。所以 ROS／ROS2對機器人開發(fā)的支持映射到智能駕駛，多體現(xiàn)在分形遞歸的 EPX 模型的最內層。即短距離內單一場景的感知、規(guī)劃和控制執(zhí)行。其并沒有對復雜的場景的調度（S）和多場景并行下的執(zhí)行仲裁（A）機制。畢竟還沒有機器人需要從北京走到廣州。

所以作為自動駕駛的軟件開發(fā)框架，ROS／ROS2仍然有很多欠缺，但是作為快速原型工具仍然是非常好的選擇。

3．3 關于L3＋自動駕駛＂中間件＂

顧名思義，“中間件”一定是在兩層中間，為上層屏蔽底層的復雜性。計算機軟件架構中有一句名言：“計算機科學領域的任何問題都可以通過增加一個間接的中間層來解決” 。這是軟件架構設計的一個主要的設計哲學，用在了無數(shù)地方，也解決了無數(shù)的問題。而且“中間”一詞也是相對的，當有多層堆疊的時候，每一層都是其上下兩層的中間層。所以我們說“中間件”的時候，需要指明其上下文，否則容易出現(xiàn)表達與理解的不一致。

當我們說 AP AutoSar 或 CP AutoSar 是中間件時，這個中間件是很明確的 L．BSW 層語義。即處于計算機OS與車載ECU特定功能實現(xiàn)之間，為 ECU功能實現(xiàn)層屏蔽掉特定處理器和計算機OS相關的細節(jié)，并實現(xiàn)與車輛網(wǎng)絡、電源等系統(tǒng)交互所需的基礎服務。

當我們稱 “ROS／ROS2 為中間件”時，其含義與 “AP AutoSar為 中間件”并不是對等的關系。ROS／ROS2 是作為機器人開發(fā)的應用框架，在機器人應用和計算機OS之間提供了通用的中間層框架和常用軟件模塊（ROS Package）。而且 ROS團隊認為這個框架做得足夠好，可以稱作操作系統(tǒng)（OS）了。

L．FW 層在 L．BSW 和 L．APK 層之間，它為自動駕駛功能或場景的開發(fā)提供軟件框架和基礎組件。對于其上層來說，它也是中間件。如果做得好，也可以稱為OS，那就是“自動駕駛OS”。Anyway，一切都是相對的。

為了避免歧義，本文一般不使用“中間件”術語，如果使用也會明確指出是代表哪兩層的中間。多數(shù)情況下，我們使用“車載控制器基礎軟件”代表任何汽車電子ECU都需要實現(xiàn)的基礎軟件功能，是計算機OS系統(tǒng)之上，ECU實際功能層（FW＋APK）之下的中間層，代號 L．BSW。

未動科技對于自動駕駛中間件如何更好地支持上層應用有準確、透徹的理解，結合多年的視覺感知的研發(fā)落地積累，可以更好地配合主機廠進行汽車本身功能的優(yōu)化，提升用戶駕乘體驗。