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

智能駕駛軟件架構(gòu)的重要性

智能駕駛的簡化概念模型

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

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

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

1. 在一定范圍內(nèi)的全局意義上的規(guī)劃 （常用術(shù)語：全局規(guī)劃，路徑規(guī)劃，任務(wù)規(guī)劃)

2. 將第一步的結(jié)果做劃分出多個階段 （常用術(shù)語：行為規(guī)劃，行為決策）

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

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

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

基礎(chǔ)概念模型的分形遞歸特性

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

對于問題P：

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

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

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

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

對于P 問題：

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

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

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

X 負責(zé)執(zhí)行執(zhí)行 P 問題的輸出結(jié)果。 這個問題空間 B 是最接近通常規(guī)劃算法要解決的問題。

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



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

上圖中 A:X 需要執(zhí)行的任務(wù) “完成進入北四環(huán)”完全可以下一級的 EPX 循環(huán)去完成。所以實際上，如下圖所示 E-P-X 模型是一個分形遞歸的結(jié)構(gòu)。



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




圖3 分形示例

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

“分形”更學(xué)術(shù)化的表達是"用分數(shù)維度的視角和數(shù)學(xué)方法描述和研究客觀事物，跳出了一維的線、二維的面、三維的立體乃至四維時空的傳統(tǒng)藩籬，更加趨近復(fù)雜系統(tǒng)的真實屬性與狀態(tài)的描述，更加符合客觀事物的多樣性與復(fù)雜性“。當(dāng)我們?yōu)椤拔锢憩F(xiàn)實”找到合適的數(shù)學(xué)表述，再轉(zhuǎn)換為“程序現(xiàn)實”，就能找到更簡潔、清晰、準確的軟件架構(gòu)及實現(xiàn)方式。

軟件架構(gòu)解決“物理現(xiàn)實”到“程序現(xiàn)實”的映射

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

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

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

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

什么叫基于場景的調(diào)度？

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



圖4 ?EPX的調(diào)度

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

軟件架構(gòu)上如何兼容 L1 到 L3+

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

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

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

L2及以下單一功能控制器的軟件架構(gòu)

我們先來看一下L2 功能的常用軟件架構(gòu)，我們對常用

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

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

常用的硬件架構(gòu)

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



圖 5 方案一拓撲

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



圖 6 方案二拓撲

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

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

典型的軟件架構(gòu)

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

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

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

圖7 ACC/AEB/LKA 的典型軟件架構(gòu) ?

MBD開發(fā)方式

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

集成度更高的產(chǎn)品解決方案

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

硬件拓撲示意

圖 8 ?泊車系統(tǒng)的硬件拓撲方案

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

典型的軟件架構(gòu)

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




圖 9 ?泊車系統(tǒng)的軟件架構(gòu)

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

性能域的 OS 采用 Linux 后 ，OS 級別的執(zhí)行環(huán)境比RTOS復(fù)雜很多

需要一系列的框架或中間件來支持應(yīng)用的開發(fā)

數(shù)據(jù)通路復(fù)雜性

增加了視頻流的處理通路

增加了實時域和性能域之間的數(shù)據(jù)通路需求

性能域各個軟件模塊之間有數(shù)據(jù)通訊要求

落實到具體的芯片平臺解決方案后，架構(gòu)設(shè)計需要跟芯片的各種 SDK 進行整合和統(tǒng)籌設(shè)計

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

在網(wǎng)絡(luò)通訊設(shè)備領(lǐng)域，這些往往被稱為管理平面。很多也是 AutoSar AP 提供的基礎(chǔ)能力。實際上無論是 CP AutoSar 還是 AP AutoSar ，除了負責(zé)通訊的模塊，其他大部分都是管理平面的能力。

多個單一功能的 ECU 的協(xié)同

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



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

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

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

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

輕量化的域控制器設(shè)計中，域控制器只做簡單的數(shù)據(jù)轉(zhuǎn)發(fā)，將骨干網(wǎng)上的數(shù)據(jù)篩選后發(fā)送到域內(nèi)的控制器。將域內(nèi)控制器的控制信號發(fā)送到骨干網(wǎng)。這種方式對域控制器的算力要求不高。

域控制器再多承擔(dān)一些工作就可以把其它控制器的實時域部分的計算工作接管過去。比如ACC/AEB/LKA 的規(guī)劃控制計算都放在域控制器中進行。這就要求其他控制器把感知數(shù)據(jù)發(fā)送給域控制器，由域控制器統(tǒng)一處理。這對算力要求就更高了一些。同時對域內(nèi)網(wǎng)絡(luò)的帶寬要求也提高了。

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

EPX-SA 概念模型

仲裁機制

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

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

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



圖 11 ?EPX-SA 概念模型 ?

環(huán)境模型概念的提出

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

智能駕駛的感知部分，實際上就是用盡可能多的傳感器加上算法來達到對理想模型的逼近。可用的傳感器越多，算法越準確，與理想模型的偏差就越少。

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





審核編輯：劉清