智能駕駛需要很多不同專業的人協同工作，并不是所有人都是軟件或汽車軟件背景。為了能讓各種不同背景的人都能一定程度上理解文章內容，本文盡量采用非常通俗的語言來描述，并配合各種圖來進行闡述。本文避免使用有歧義的術語，所有術語在第一次出現時都給出其在本文的準確定義。

智能駕駛軟件架構的重要性

智能駕駛的簡化概念模型

智能駕駛的概念模型簡單來說就是解決三個核心問題： 1. 我在哪？ 2. 我要去哪？ 3. 我該如何去？ 第一個問題“我在哪？”需要解決的是“環境感知”和“定位”問題，需要了解的是車自身的位置以及該位置周邊的靜態環境（道路，交通標識，信號燈等）和動態環境（車、人等）。

由此引發一系列的感知和定位的技術方案，包括各種傳感器以及算法體系。 第二個問題“我要去哪？”在自動駕駛領域就是“規劃決策”。由此延伸出一些術語“全局規劃””局部規劃"、“任務規劃”“路徑規劃”、"行為規劃”、“行為決策”“運動規劃”，等等，由于語言上的歧義，這些術語有的是同一個意思的不同說法，有的其含義在不同場合經常相近但又有點差別。

拋開具體的術語，一般而言這“規劃決策”這個問題都會被分解為三部分：

1. 在一定范圍內的全局意義上的規劃 （常用術語：全局規劃，路徑規劃，任務規劃)

2. 將第一步的結果做劃分出多個階段 （常用術語：行為規劃，行為決策）

3. 對每一個階段進行進一步的規劃 （常用術語：局部規劃，運動規劃）

對于這些各種各樣的規劃衍生出很多解決問題的算法體系。 第三個問題“我該如何去？”一般指的就是“控制執行”，也就是對最小一個規劃的實際執行實踐，達到規劃的目的。具體在車上，往往體現為各種控制算法，控制理論解決的就是這些問題。

因為這三個問題的解決歸根到底都是算法問題，所以某種意義上，說自動駕駛的核心就是算法。而軟件架構從某種意義上說，就是要能承載這些算法。沒有很好的承載體系，再好的算法也無用武之地。

基礎概念模型的分形遞歸特性

為了方面我們把基礎概念模型的三個問題分別表示為 E , P, X,分別代表 環境(Environment)、計劃(Plan)、執行(eXecute)。每一組 E-P-X 都有其描述問題空間。 比如說，我們定義問題空間 A 是“駕車從北京到廣州”，那么對于問題 E：其定位關注的可能就是當前在北京那個區，不必細化到街道。我們還需要關心天氣是否有雷暴雨，省道以上的道路結構信息。

對于問題P：

P-1 : 第一步先設計出一個全局的路徑，走哪條高速、國道、省道

P-2 ：根據全局路徑計劃出一系列行為組成，先到哪個高速路口，行駛多少公里，去服務區加油、更換到另一條道路等等

P-3：計劃出到每一段的具體道路路徑。比如到高速路口要走三環還是四環，在換到哪條路上 X 要執行 P 規劃出來的每一步。

如果我們定義問題空間 B 是“駕車安全通過一個路口”，那么對于E 問題，要關注的是當前的道路信息、交通燈信息、道路上的車輛狀況、行人狀況等。

對于P 問題：

P-1 ：第一步先規劃出通過路口的安全路徑，包括根據交通規則和道路信息計劃到達當前路口的哪個車道，進入目標路口的哪個車道。

P-2 ：第二步要第一步的根結果規劃出一系列動作序列，如先減速，切換目標車道，停車等紅燈，起步加速，通過路口。

P-3 ：第三步對第二步的每一個動作要設計具體的一段軌跡，軌跡要能避開行人車輛等障礙物。

X 負責執行執行 P 問題的輸出結果。 這個問題空間 B 是最接近通常規劃算法要解決的問題。

其中 P-1 的第一步常稱為“全局規劃”或“任務規劃”，P-2 常被稱為“行為規劃”或 “行為決策”，P-3 被稱為“局部規劃”或“運動規劃(Motion Plan)”。如下圖所示，E-P-X 形成抽象的基礎概念模型，問題空間 A 和 B 都是其在某個范圍上的具體實現。



圖 1 兩個EPX的問題空間 A 和 B 兩個問題空間都有 相似的 E-P-X 結構，但是他們解決的問題在時間和空間上的跨度差別很大。

上圖中 A:X 需要執行的任務 “完成進入北四環”完全可以下一級的 EPX 循環去完成。所以實際上，如下圖所示 E-P-X 模型是一個分形遞歸的結構。



圖2 ?EPX的分形遞歸結構 上一級的 X 總能被下一級的再一次分解為更小粒度的 E-P-X 來執行。 "分形" 又稱為“自相似分形”，其通俗理解是事物的局部與整體有相似的結構，是在不同尺度上的對稱，例如一顆樹的一支樹枝與整顆樹是相似的結構，再進一步，每片樹葉的莖脈也是相似的結構。下圖列舉了一些典型的分形結構。




圖3 分形示例

這 6 個圖形都有一個特點，每個圖形的任何一個局部都與整個圖形的結構是一樣的。局部進一步放大，會發現局部的局部也是同樣的結構。因此當我們有一套業務處理邏輯能夠適用于整體，也同樣可以適用于局部。就像有些樹的培育，可以取一根樹枝種下去，會長成一棵新樹。映射到軟件程序的表達，就是“遞歸”。這并不是說使用遞歸函數來處理，是指架構層級的遞歸。

“分形”更學術化的表達是"用分數維度的視角和數學方法描述和研究客觀事物，跳出了一維的線、二維的面、三維的立體乃至四維時空的傳統藩籬，更加趨近復雜系統的真實屬性與狀態的描述，更加符合客觀事物的多樣性與復雜性“。當我們為“物理現實”找到合適的數學表述，再轉換為“程序現實”，就能找到更簡潔、清晰、準確的軟件架構及實現方式。

軟件架構解決“物理現實”到“程序現實”的映射

E-P-X 是根據“物理現實”抽象出來的結構。而且其中絕大部分都是各種各樣的是算法的工作。單個算法本身的研究和開發可以根據預定義的輸入輸出條件獨立進行。但是算法怎么組合起來，在合適的時機被正確的觸發，其結果被合理使用，才能最終形成有實際用途的功能。這個從“物理現實”到“程序現實”的橋梁核心就是軟件架構。

自動駕駛系統從 Level 1 到 Level 5， 越往上，上述 E-P-X 模型的嵌套深度就越多。軟件架構上的難度也就越大。大部分單一的 Level1 和 Level2 功能只需要一層 E-P-X 模型。以 AEB (自動緊急剎車）為例： E 部分(感知) ：主要就是對前方目標（車，人）的靜態識別和分類、動態跟蹤，檢測距離和速度。

P 部分: 因為 AEB 只做縱向的控制，可以全部通過對速度的控制來實現。所以只需要做對一段時間內的速度做出規劃。

X 部分：將速度規劃交由車輛控制單元執行。 并不是說只有一層 EPX ，AEB功能就簡單。實際上 能夠量產的 AEB 功能實現難度一樣是非常大的。不過一層的 EPX , 就不需要基于場景進行調度，只需要關注與單一場景下 EPX 的實現，其軟件架構就相對簡單。第二章會介紹 L2 功能常見的軟件架構。

什么叫基于場景的調度？

即便是在最小粒度層級的 EPX 循環中，也不是一個EXP的實現就能解決這一層級的所有問題。 比如：就一個簡單的直線行駛用例，我們可以將最末端 X 單元實現為一個車輛控制算法，這算法處理完所有的平道、上坡、下坡場景。也可以使用一個調度單元（S），根據 E 單元的信息，將平道、上坡、下坡識別為不同的場景，切換不同的 下一級 EXP 循環。下一級的每個 EXP 循環實現單一的場景。實際上，即便使用一個 X 單元的控制算法解決所有平道、上坡、下坡場景，這個算法內部也一樣會對這些場景進行區分，實際還是一個微小粒度的 EXP 循環。



圖4 ?EPX的調度

如圖 4所示，場景的調度（S) 可以在每一個層級都有，也就是說對“場景”的定義也有粒度的劃分。所以 ，EPX模型應該是 EPX-S 模型。只是在 L2 以下沒有明顯的 S 部分。

軟件架構上如何兼容 L1 到 L3+

自動泊車輔助功能就開始有場景調度的需求，比如垂直泊車、垂直泊入、水平泊出、水平泊入、斜向泊入等等都是不同的場景，其 P 和 X 部分都需要分別實現。但是場景調度可以通過HMI界面由人工來選擇，是一個“人在回路中”的 S 單元。

Level 3 以上功能中，很長一段連續的駕駛過程都不需要人工干預。就必然涉及到多個不同的 EXP層級自動調度。這樣在軟件架構上就跟L2以下功能有很大不同。這也是為什么很多公司把 L2 和 L3+分成兩個不同的團隊的原因之一。 實際上只要是有意識的基于多層級的 EXP-S 模型來設計軟件架構，每一個EXP-S單元都有其合適的體現，實際上是可以實現一套軟件架構支持從 L1到L3+以上的自動駕駛基本。

只是說 S 單元對 L2以下功能來說比較弱一些，但是其架構地位仍然存在。

L2及以下單一功能控制器的軟件架構

我們先來看一下L2 功能的常用軟件架構，我們對常用

使用Smart Sensor 的 AEB/ACC/LKA 解決方案

AEB/ACC/LKA 三個功能是 L2 最經典的駕駛輔助功能，一般的系統方案的感知部分多采用前向的攝像頭輸出目標(車輛、行人)信息，并與前向毫米波雷達給出的目標數據做融合，得到更準確的速度和距離。視覺感知和雷達感知多采用Smart Sensor 方案，這樣 Tier 1 可以選用成熟的 Tier2 供應商的產品。Tier 1 主要的開發工作在感知融合與功能狀態機的實現以及車輛控制算法。

常用的硬件架構

方案一：視覺感知結果傳遞給雷達感知控制器，雷達感知控制器中完成感知融合和 L2功能狀態機



圖 5 方案一拓撲

方案二：獨立的L2 控制器連接 視覺和雷達的Smart Sensor，L2控制器完成感知融合和 L2 功能狀態機



圖 6 方案二拓撲

兩個方案都是經常被采用的。方案一采用較高性能的雷達控制器，分配部分計算單元用來實現融合算法和功能狀態機。很多芯片廠商做雷達處理芯片設計時就考慮到這部分算力預留。比如NXP 專為雷達ECU設計的 S32R 系列，其多核心足夠同時做雷達信號處理與 L2 的功能實現。畢竟最耗算力的視覺算法是在另外器件上完成的。

方案二單獨獨立出來 L2實現 L2 功能的控制器, 通過私有Can 與兩個 Smart Sensor 通訊獲取感知數據。一般來說，這個方案可以考慮后續增加更多的 L2 功能，如果有需要，可以再接更多的 Smart Sensor。

典型的軟件架構

對于采用 Smart Sensor 的系統架構來說，前向智能攝像頭和前向毫米波雷達分別給出各自觀測到的環境中目標對象的語義。這兩部分數據直接通過 Can 總線或內部的 IPC (計算機OS的進程間通訊)機制傳遞給負責感知融合和 L2 功能實現的模塊。

無論是硬件方案一還是方案二，業內最常用的軟件架構是基于 Classic AutoSar 來開發。Classic AutoSar 提供了車載ECU通用的功能并為引用軟件提供執行環境和數據輸入輸出通道。感知融合模塊和其它 ACC/AEB/LKA 功能可以實現為一個或多個 AutoSar SWC（軟件組件）。具體這些 SWC 組件是否進行拆分，如何拆分，各家開發商有自己的合理邏輯。但基本架構大同小異。

當然也可以不采用 Classic AutoSar , 用其它合適的 RTOS 作為底層系統，或許對于車載ECU需要通用功能開發和達到功能安全標準的難度會大一些，但在應用功能開發的架構體系上跟采用 Classic AutoSar 的方案沒有太大差別。

圖7 ACC/AEB/LKA 的典型軟件架構 ?

MBD開發方式

業內常用MBD（基于模型的開發）方式來實現感知融合算法，規劃和控制執行算法以及 ACC/AEB/LKA 功能狀態機。然后使用工具生成 C 代碼，再手動集成到目標平臺。MDB開發方式的一個便利之處在于可以先使用模型工具和 CanOE 之類的設備直接上車開發調試，或者與仿真平臺連接進行開發調試。這樣開發團隊可以分成兩部分，一部分人用模型工具開發應用功能，一部分人開發所有車載ECU都需要的一系列繁瑣工作，然后再集成在一起。

集成度更高的產品解決方案

一般全自動泊車產品會采用集成度更高的方案，在一個 ECU 內將視覺算法（靜態障礙物識別，動態障礙物識別，行人識別，車位線識別）超聲波雷達算法（距離檢測，障礙物檢測）泊車過程的軌跡規劃和控制執行，都放在一個控制器內完成。集成度更高的還會在自動泊車控制器中同時 支持360環視功能，這就還需要支持攝像頭環視圖像的校正和拼接2D/3D 的圖形渲染視頻輸出HMI 生成等功能。
?示意性的硬件拓撲如下。

硬件拓撲示意

圖 8 ?泊車系統的硬件拓撲方案

圖中的各個模塊在不同的硬件選型方案中有不同的分布模式。一般情況下用于實時處理的 MCU 會單獨使用一顆芯片。不同的芯片廠家有各自的 AI 單元解決方案。有的用高性能的 DSP,有的專有的矩陣計算單元，有的用FPGA, 不一而足。

典型的軟件架構

下圖是自動泊車系統一個典型的軟件架構(只是簡化后的示意，實際量產系統會復雜更多)： 與 2.1.1 相比，這里最顯著的改變就是區分了“實時域”和 “性能域”兩套系統。一般來說，我們把MCU或其它實時核心（Cortex-R,Cortex-M 或其它對等系列）上的軟硬件系統成為“實時域”。把 SOC 內的大核心(Cortex-A或對等系列）以及運行在其上的 Linux/QNX 統稱為性能域，這里面一般還包含了支持視覺算法加速的軟硬件體系。 雖然從量產的工程化難度上，全自動泊車系統比 ACC/AEB/LKA 等 Level2 主動安全功能要小很多。但是在軟件架構上，泊車系統卻復雜很多。主要體現在以下方面：




圖 9 ?泊車系統的軟件架構

實時域和性能域的劃分帶來系統性的復雜度，需要根據實時性要求和計算資源的要求，為不同的計算選擇不同的硬件平臺

性能域的 OS 采用 Linux 后 ，OS 級別的執行環境比RTOS復雜很多

需要一系列的框架或中間件來支持應用的開發

數據通路復雜性

增加了視頻流的處理通路

增加了實時域和性能域之間的數據通路需求

性能域各個軟件模塊之間有數據通訊要求

落實到具體的芯片平臺解決方案后，架構設計需要跟芯片的各種 SDK 進行整合和統籌設計

另外，通過這個軟件架構可以看到，引入Linux (或QNX/vxworks)后帶來的一些問題。這些系統本身是與特定行業無關的計算機操作系統，當被用于汽車電子控制器的時候，會有一系列與特定產品功能無關，但是作為汽車 ECU 需要具備的通用功能需要實現。比如診斷、時鐘同步、升級等等。這部分在整體的控制器開發中占了非常大的工作量，很多情況下會超過40%，而且跟控制器的可靠性非常相關。

在網絡通訊設備領域，這些往往被稱為管理平面。很多也是 AutoSar AP 提供的基礎能力。實際上無論是 CP AutoSar 還是 AP AutoSar ，除了負責通訊的模塊，其他大部分都是管理平面的能力。

多個單一功能的 ECU 的協同

如果一輛車上有多種 L2 功能該如何協同工作。下圖是一個簡化的多控制器拓撲示例。



圖10 多個L2 功能控制器加域控制器的拓撲方案

這個拓撲中集成了6個控制器，“全自動泊車系統”“前向智能攝像頭”和“前向毫米波雷達”提供的功能如前面所述。左右角雷達是兩個鏡像的設備，各自獨立運行可以實現“后車逼近告警”，“開門告警”等功能?！榜{駛員監控系統”檢測駕駛員的狀態，發現駕駛員疲勞駕駛時可以給出告警，如果駕駛員完全失去行動能力，就通知其它系統嘗試減速靠邊停車。

這個拓撲中有如下要點：引入域控制器連接多個獨立的駕駛輔助功能控制器，域控制器與骨干網連接；駕駛輔助域內多條 Can 總線，避免總線帶寬不夠。

從軟件架構上講，各駕駛輔助控制器獨立運行，自主決定自己的功能開啟和停止。相關控制信號發送給域控制器，由域控制器轉發到動力域。駕駛輔助域控制器要負責對各獨立控制器的控制輸出做出裁決。從域控制器在這里可以起的作用看，由輕到重有各種可能的設計。

輕量化的域控制器設計中，域控制器只做簡單的數據轉發，將骨干網上的數據篩選后發送到域內的控制器。將域內控制器的控制信號發送到骨干網。這種方式對域控制器的算力要求不高。

域控制器再多承擔一些工作就可以把其它控制器的實時域部分的計算工作接管過去。比如ACC/AEB/LKA 的規劃控制計算都放在域控制器中進行。這就要求其他控制器把感知數據發送給域控制器，由域控制器統一處理。這對算力要求就更高了一些。同時對域內網絡的帶寬要求也提高了。

更進一步，因為能拿到所有的感知數據，域控制器還可以開發出一些增加的功能，比如依靠圖中的傳感器，有可能在域控制器中實現變道輔助或緊急避障的功能。 在功能逐步往域控制器集中的過程中，承擔了感知部分的其它控制器的非感知部分就被逐步弱化。

EPX-SA 概念模型

仲裁機制

前面說到，ACC/AEB/LKA 功能實現，全自動泊車的實現，以及其他的單一 L2 以下功能，都可以理解為一層或兩層分形遞歸的 EPX-S 模型。

其實 ACC/AEB/LKA 這三個功能，在實際量產產品中就是可以同時開啟的，每個都是一個單獨的 EPX-S 循環。也就是說多個 EPX-S 循環是可以同時并行運行的。如果同時產生的 X 輸出，需要由一個仲裁機制進行裁決（Arbitration）。

當有多個控制器同時運行的時候由域控制器在更高層級上進行仲裁。 所以 EPX-S 模型應該被擴展為 EPX-SA 模型。如下圖所示，場景1和場景2是兩個并行運行的 EPX-S 循環，它們產生的 X 被經過仲裁后輸出。



圖 11 ?EPX-SA 概念模型 ?

環境模型概念的提出

每個實現單一 L2 功能的控制器都有某一方面的感知能力。都描述了車輛內外環境中某一個方面的屬性，可以從空間上的角度、距離進行劃分，也可以從物理屬性進行劃分，如可見光，超聲波，毫米波，激光。如果對整個環境建立一個理想的完全準確的3D模型系統，每一個傳感器就相當于這個模型的一個過濾器，像“盲人摸象”一樣，各自表達了理想模型某一方面的屬性。

智能駕駛的感知部分，實際上就是用盡可能多的傳感器加上算法來達到對理想模型的逼近?？捎玫膫鞲衅髟蕉啵惴ㄔ綔蚀_，與理想模型的偏差就越少。

L2的域控制器中，如果需要，可以取到所有下級控制器的感知數據，那么在這一級，就可以基于所有的感知結果拼出一個理想環境模型的現實模型，雖然與理想模型還有很大差距，但是已經是一個整體意義上的環境模型。 環境模型提供的信息，不僅僅用在各級的規劃模塊(P)，在調度(S) 和仲裁（A)階段一樣會被用到。 ? ? ??





審核編輯：劉清