智慧駕駛需要很多不同專業的人協同工作，並不是所有人都是軟體或汽車軟體背景。為了能讓各種不同背景的人都能一定程度地理解文章內容，本文盡量採用非常通俗的語言來描述，並配合各種圖來進行闡述。本文避免使用有歧義的術語，所有術語在第一次出現時都給出其在本文的準確定義。
智能駕駛的概念模型簡單來說就是解決三個核心問題：
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 部分。
自動停車輔助功能就開始有場景調度的需求，例如垂直停車、垂直泊入、水平泊出、水平泊入、斜向泊入等等都是不同的場景，其P 和X 部分都需要分別實現。但是場景調度可以透過HMI介面由人工來選擇，是一個「人在迴路中」的 S 單元。
Level 3 以上功能中，很長一段連續的駕駛過程都不需要人工幹預。就必然涉及多個不同的 EXP層級自動調度。這樣在軟體架構上就跟L2以下功能有很大不同。這也是為什麼很多公司把 L2 和 L3 分成兩個不同的團隊的原因之一。
實際上只要是有意識的基於多層級的EXP-S 模型來設計軟體架構，每一個EXP-S單元都有其合適的體現，實際上是可以實現一套軟體架構支援L1到L3 以上的自動駕駛基本。只是說 S 單元對 L2以下功能來說比較弱一些，但是其架構地位仍然存在。
#我們先來看看L2 功能的常用軟體架構，我們對常用
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 泊車系統的軟體架構
資料通路複雜性
增加了視訊串流的處理通路
######增加了即時域和效能域之間的資料通路需求############效能域各軟體模組之間有資料通訊需求############落實到具體的晶片平台解決方案後，架構設計需要跟著晶片的各種SDK 整合和統籌設計################另外，透過這個軟體架構可以看到，引入Linux (或QNX/vxworks)後帶來的一些問題。這些系統本身就是與特定產業無關的電腦作業系統，當被用於汽車電子控制器的時候，會有一系列與特定產品功能無關，但是作為汽車 ECU 需要具備的通用功能需要實現。例如診斷、時鐘同步、升級等等。這部分在整體的控制器開發中佔了非常大的工作量，很多情況下會超過40%，而且跟控制器的可靠性非常相關。 ############在網路通訊設備領域，這些往往被稱為管理平面。很多也是 AutoSar AP 提供的基礎能力。實際上無論是 CP AutoSar 還是 AP AutoSar ，除了負責通訊的模組，其他大部分都是管理平面的能力。 ######如果一輛車上有多種 L2 功能該如何協同工作。下圖是一個簡化的多控制器拓樸範例。
圖10 多個L2 功能控制器加網域控制器的拓樸方案
這個拓樸中整合了6個控制器，「全自動泊車系統」「前向智慧攝影機」和「前向毫米波雷達」提供的功能如前面所述。左右角雷達是兩個鏡像的設備，各自獨立運行可以實現“後車逼近告警”，“開門告警”等功能。 「駕駛員監控系統」偵測駕駛的狀態，發現駕駛人疲勞駕駛時可以給予告警，如果駕駛完全失去行動能力，就通知其它系統嘗試減速靠邊停車。
這個拓撲中有以下要點：引入網域控制器連接多個獨立的駕駛輔助功能控制器，網域控制器與骨幹網路連接；駕駛輔助域內多條Can 總線，避免總線頻寬不夠。
從軟體架構上講，各駕駛輔助控制器獨立運行，自主決定自己的功能開啟和停止。相關控制訊號傳送給網域控制器，由網域控制器轉送到動力域。駕駛輔助域控制器要負責對各獨立控制器的控制輸出做出裁決。從網域控制器在這裡可以扮演的角色看，由輕到重有各種可能的設計。在輕量化的網域控制器設計中，網域控制器只做簡單的資料轉發，將骨幹網路上的資料篩選後傳送到網域內的控制器。將域內控制器的控制訊號傳送到骨幹網路。這種方式對網域控制器的算力要求不高。
網域控制站再多承擔一些工作就可以把其它控制器的即時網域部分的運算工作接管過去。例如ACC/AEB/LKA 的規劃控制計算都放在網域控制器中進行。這就要求其他控制器把感知資料傳送給網域控制器，由網域控制器統一處理。這對算力要求就更高了一些。同時對域內網路的頻寬要求也提高了。
更進一步，因為能拿到所有的感知數據，網域控制器還可以開發出一些增加的功能，例如依靠圖中的感測器，有可能在網域控制器中實現變換車道輔助或緊急避障的功能。
在功能逐步往網域控制站集中的過程中，承擔了感知部分的其它控制器的非感知部分就被逐步弱化。
#仲裁機制
前面說到，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)階段一樣會被用到。
以上是一文學習智慧駕駛域控制器軟體架構的詳細內容。更多資訊請關注PHP中文網其他相關文章！
