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

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

智能駕駛的簡化概念模型

智能駕駛的概念模型簡單來說就是解決三個(gè)核心問題：

1. 我在哪？

2. 我要去哪？

3. 我該如何去？

第一個(gè)問題“我在哪？”需要解決的是“環(huán)境感知”和“定位”問題，需要了解的是車自身的位置以及該位置周邊的靜態(tài)環(huán)境（道路，交通標(biāo)識，信號燈等）和動(dòng)態(tài)環(huán)境（車、人等）。由此引發(fā)一系列的感知和定位的技術(shù)方案，包括各種傳感器以及算法體系。

第二個(gè)問題“我要去哪？”在自動(dòng)駕駛領(lǐng)域就是“規(guī)劃決策”。由此延伸出一些術(shù)語“全局規(guī)劃””局部規(guī)劃"、“任務(wù)規(guī)劃”“路徑規(guī)劃”、"行為規(guī)劃”、“行為決策”“運(yùn)動(dòng)規(guī)劃”，等等，由于語言上的歧義，這些術(shù)語有的是同一個(gè)意思的不同說法，有的其含義在不同場合經(jīng)常相近但又有點(diǎn)差別。

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

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

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

3. 對每一個(gè)階段進(jìn)行進(jìn)一步的規(guī)劃 （常用術(shù)語：局部規(guī)劃，運(yùn)動(dòng)規(guī)劃）

對于這些各種各樣的規(guī)劃衍生出很多解決問題的算法體系。

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

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

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

為了方面我們把基礎(chǔ)概念模型的三個(gè)問題分別表示為 E , P, X,分別代表 環(huán)境(Environment)、計(jì)劃(Plan)、執(zhí)行(eXecute)。每一組 E-P-X 都有其描述問題空間。

比如說，我們定義問題空間 A 是“駕車從北京到廣州”，那么對于問題 E：其定位關(guān)注的可能就是當(dāng)前在北京那個(gè)區(qū)，不必細(xì)化到街道。我們還需要關(guān)心天氣是否有雷暴雨，省道以上的道路結(jié)構(gòu)信息。對于問題P：

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

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

P-3：計(jì)劃出到每一段的具體道路路徑。比如到高速路口要走三環(huán)還是四環(huán)，在換到哪條路上

X 要執(zhí)行 P 規(guī)劃出來的每一步。

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

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

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

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

X 負(fù)責(zé)執(zhí)行執(zhí)行 P 問題的輸出結(jié)果。

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

圖 1 兩個(gè)EPX的問題空間

A 和 B 兩個(gè)問題空間都有 相似的 E-P-X 結(jié)構(gòu)，但是他們解決的問題在時(shí)間和空間上的跨度差別很大。上圖中 A:X 需要執(zhí)行的任務(wù) “完成進(jìn)入北四環(huán)”完全可以下一級的 EPX 循環(huán)去完成。所以實(shí)際上，如下圖所示 E-P-X 模型是一個(gè)分形遞歸的結(jié)構(gòu)。

圖 2  EPX的分形遞歸結(jié)構(gòu)

上一級的 X 總能被下一級的再一次分解為更小粒度的 E-P-X 來執(zhí)行。

"分形" 又稱為“自相似分形”，其通俗理解是事物的局部與整體有相似的結(jié)構(gòu)，是在不同尺度上的對稱，例如一顆樹的一支樹枝與整顆樹是相似的結(jié)構(gòu)，再進(jìn)一步，每片樹葉的莖脈也是相似的結(jié)構(gòu)。下圖列舉了一些典型的分形結(jié)構(gòu)。

圖3 分形示例

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

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

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

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

自動(dòng)駕駛系統(tǒng)從 Level 1 到 Level 5， 越往上，上述 E-P-X 模型的嵌套深度就越多。軟件架構(gòu)上的難度也就越大。大部分單一的 Level1 和 Level2 功能只需要一層 E-P-X 模型。以 AEB (自動(dòng)緊急剎車）為例：

E 部分(感知) ：主要就是對前方目標(biāo)（車，人）的靜態(tài)識別和分類、動(dòng)態(tài)跟蹤，檢測距離和速度。

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

X 部分：將速度規(guī)劃交由車輛控制單元執(zhí)行。

并不是說只有一層 EPX ，AEB功能就簡單。實(shí)際上 能夠量產(chǎn)的 AEB 功能實(shí)現(xiàn)難度一樣是非常大的。不過一層的 EPX , 就不需要基于場景進(jìn)行調(diào)度，只需要關(guān)注與單一場景下 EPX 的實(shí)現(xiàn)，其軟件架構(gòu)就相對簡單。第二章會(huì)介紹 L2 功能常見的軟件架構(gòu)。

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

即便是在最小粒度層級的 EPX 循環(huán)中，也不是一個(gè)EXP的實(shí)現(xiàn)就能解決這一層級的所有問題。

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

圖4  EPX的調(diào)度

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

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

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

Level 3 以上功能中，很長一段連續(xù)的駕駛過程都不需要人工干預(yù)。就必然涉及到多個(gè)不同的 EXP層級自動(dòng)調(diào)度。這樣在軟件架構(gòu)上就跟L2以下功能有很大不同。這也是為什么很多公司把 L2 和 L3+分成兩個(gè)不同的團(tuán)隊(duì)的原因之一。

實(shí)際上只要是有意識的基于多層級的 EXP-S 模型來設(shè)計(jì)軟件架構(gòu)，每一個(gè)EXP-S單元都有其合適的體現(xiàn)，實(shí)際上是可以實(shí)現(xiàn)一套軟件架構(gòu)支持從 L1到L3+以上的自動(dòng)駕駛基本。只是說 S 單元對 L2以下功能來說比較弱一些，但是其架構(gòu)地位仍然存在。

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

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

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

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

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

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

圖 5 方案一拓?fù)?/span>

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

圖 6 方案二拓?fù)?/span>

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

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

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

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

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

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

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

MBD開發(fā)方式

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

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

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

硬件拓?fù)涫疽?/span>

圖 8  泊車系統(tǒng)的硬件拓?fù)浞桨?/span>

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

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

下圖是自動(dòng)泊車系統(tǒng)一個(gè)典型的軟件架構(gòu)(只是簡化后的示意，實(shí)際量產(chǎn)系統(tǒng)會(huì)復(fù)雜更多)：

與 2.1.1 相比，這里最顯著的改變就是區(qū)分了“實(shí)時(shí)域”和 “性能域”兩套系統(tǒng)。一般來說，我們把MCU或其它實(shí)時(shí)核心（Cortex-R,Cortex-M 或其它對等系列）上的軟硬件系統(tǒng)成為“實(shí)時(shí)域”。把 SOC 內(nèi)的大核心(Cortex-A或?qū)Φ认盗校┮约斑\(yùn)行在其上的 Linux/QNX 統(tǒng)稱為性能域，這里面一般還包含了支持視覺算法加速的軟硬件體系。

雖然從量產(chǎn)的工程化難度上，全自動(dòng)泊車系統(tǒng)比 ACC/AEB/LKA 等 Level2 主動(dòng)安全功能要小很多。但是在軟件架構(gòu)上，泊車系統(tǒng)卻復(fù)雜很多。主要體現(xiàn)在以下方面：

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

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

• 性能域的 OS 采用 Linux 后 ，OS 級別的執(zhí)行環(huán)境比RTOS復(fù)雜很多
• 需要一系列的框架或中間件來支持應(yīng)用的開發(fā)
• 數(shù)據(jù)通路復(fù)雜性
• 增加了視頻流的處理通路
• 增加了實(shí)時(shí)域和性能域之間的數(shù)據(jù)通路需求
• 性能域各個(gè)軟件模塊之間有數(shù)據(jù)通訊要求
• 落實(shí)到具體的芯片平臺解決方案后，架構(gòu)設(shè)計(jì)需要跟芯片的各種 SDK 進(jìn)行整合和統(tǒng)籌設(shè)計(jì)

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

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

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

如果一輛車上有多種 L2 功能該如何協(xié)同工作。下圖是一個(gè)簡化的多控制器拓?fù)涫纠?/span>

圖10 多個(gè)L2 功能控制器加域控制器的拓?fù)浞桨?/span>

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

這個(gè)拓?fù)渲杏腥缦乱c(diǎn)：引入域控制器連接多個(gè)獨(dú)立的駕駛輔助功能控制器，域控制器與骨干網(wǎng)連接；駕駛輔助域內(nèi)多條 Can 總線，避免總線帶寬不夠。

從軟件架構(gòu)上講，各駕駛輔助控制器獨(dú)立運(yùn)行，自主決定自己的功能開啟和停止。相關(guān)控制信號發(fā)送給域控制器，由域控制器轉(zhuǎn)發(fā)到動(dòng)力域。駕駛輔助域控制器要負(fù)責(zé)對各獨(dú)立控制器的控制輸出做出裁決。從域控制器在這里可以起的作用看，由輕到重有各種可能的設(shè)計(jì)。輕量化的域控制器設(shè)計(jì)中，域控制器只做簡單的數(shù)據(jù)轉(zhuǎn)發(fā)，將骨干網(wǎng)上的數(shù)據(jù)篩選后發(fā)送到域內(nèi)的控制器。將域內(nèi)控制器的控制信號發(fā)送到骨干網(wǎng)。這種方式對域控制器的算力要求不高。

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

更進(jìn)一步，因?yàn)槟苣玫剿械母兄獢?shù)據(jù)，域控制器還可以開發(fā)出一些增加的功能，比如依靠圖中的傳感器，有可能在域控制器中實(shí)現(xiàn)變道輔助或緊急避障的功能。

在功能逐步往域控制器集中的過程中，承擔(dān)了感知部分的其它控制器的非感知部分就被逐步弱化。

EPX-SA 概念模型

仲裁機(jī)制

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

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

當(dāng)有多個(gè)控制器同時(shí)運(yùn)行的時(shí)候由域控制器在更高層級上進(jìn)行仲裁。

所以 EPX-S 模型應(yīng)該被擴(kuò)展為 EPX-SA 模型。如下圖所示，場景1和場景2是兩個(gè)并行運(yùn)行的 EPX-S 循環(huán)，它們產(chǎn)生的 X 被經(jīng)過仲裁后輸出。

圖 11  EPX-SA 概念模型

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

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

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

L2的域控制器中，如果需要，可以取到所有下級控制器的感知數(shù)據(jù)，那么在這一級，就可以基于所有的感知結(jié)果拼出一個(gè)理想環(huán)境模型的現(xiàn)實(shí)模型，雖然與理想模型還有很大差距，但是已經(jīng)是一個(gè)整體意義上的環(huán)境模型。

環(huán)境模型提供的信息，不僅僅用在各級的規(guī)劃模塊(P)，在調(diào)度(S) 和仲裁（A)階段一樣會(huì)被用到。