知圈 | 進“激光雷達社群”請加微信13636581676，備注激光
繼上一篇文章【 支持L3+的軟件架構及產品架構 】分享了智能駕駛域控制器軟件架構的鳥瞰圖，本文重點闡述鳥瞰圖描述的整體軟件架構中跟智能駕駛相關的部分。也就是“智能駕駛軟件框架和基礎組件” 部分。深入描述了這一部分的兩個核心框架，“環境模型框架”和“EPX-SA模型的實現框架”。
算法執行的上下文
現在我們來討論 L.FW 層的架構。前面說到，從這一層開始才有了“智能駕駛”這個語義。這個語義會在 D 軸的實時域和性能域都有體現，同時要能支持 A 軸各個切面要求的特性。
第1章說到，自動駕駛的核心是各種類型的“算法”。L.FW 層要提供的就是算法運行的載體，那么如何能讓承載算法的運行呢？如下圖，我們從時間(T)、資源(R)和數據流(F)三個維度來對一個算法的運行的上下文進行分析。
任何算法運行最終需要落實到物理設備上。這在自動駕駛相關的算法中尤為突出。算法運行在哪個物理設備上由以下幾個因素約束：
有些算法必須要運行在實時域，比如雷達處理算法，它要控制電磁波的發送，并接收回波，根據收發的時間差來做分析。算法要求執行周期的時間調度精度非常高，所以一般運行在 MCU 的RTOS之上。如果 MCU主CPU 算力不夠，就增加 DSP 芯片來加速。
使用深度學習的視覺算法運行在哪里，跟硬件物理設備及其 SDK 有關系。多數情況下其專用的硬件模塊(芯片內的 IP 核心)只能在 Linux/QNX 等OS 上訪問，算法需要使用的SDK依賴Linux/QNX 上的軟件生態， 因為那就只能運行在性能域。
一般高級程度的 SoC芯片會提供各種用于算法加速的資源，包括用于圖像信號處理的ISP模塊，用于數字信號處理的 DSP模塊，用于執行深度學習推理算法的 AI模塊，用于支持圖形渲染的GPU等等。芯片廠商同時也會提供對應的專用SDK。這些專用 SDK 是平臺強相關的，并不屬于“自動駕駛軟件框架(L.FW)”的一部分。
“自動駕駛軟件框架(L.FW)”需要能為算法分配和管理其所需的硬件計算資源。這又分為“硬件平臺無關”與“硬件平臺相關”兩部分。
如果L.FW 只是使用下層 L.BSW 層提供的服務或API接口，那么基本上就是“硬件平臺無關”的。因為 L.BSW層已經屏蔽掉了一部分平臺相關的底層細節。
如果某個硬件平臺提供能某個算法加速的硬件模塊，而兩個算法都需要使用它，那么就需要在 L.FW 層做出管理。或者L.FW 成開發出相應的抽象接口來屏蔽硬件相關性。
無論是平臺相關還是平臺無關，當多個算法競爭同一個資源的時候，L.FW 需要作出仲裁。
1.2 時間維度
前面說到多個算法可能會競爭同一個資源。最基礎的就是要安排算法合理的在時間上避免沖突。每一個算法都應該有其合理的開始時間和結束時間。然而這恰恰是最難的部分。大多數的智能駕駛原型系統一般都是讓所有算法都一起跑起來。這對簡單的單一場景是可以的。L2及以下單一功能的ECU中，因為涉及的算法不多，根據單一功能的狀態機確定算法的啟用或停止還是可以做到的。
到 Level 3 及以上時，不同場景下需要的各種算法有很大差別。所以算法的執行時間管理就非常重要。更準確的說法，“自動駕駛軟件框架(L.FW)”要管理算法的生命周期。
1.3 數據流維度
自動駕駛中的各種算法不是孤立的，相互之間有數據上的交互。某一個算法的輸出是另外一個或多個算法的輸入。多個算法級聯起來形成一個數據流管道。
但是否是所有算法都以數據流的形式被組裝還需要根據實際情況進行分析。一般來說，感知類的算法容易呈現出多級級聯的數據管道形式。但是對于其他算法，是否數據流是最合適的模式還值得商榷。比如同一個EPX-SA 分形遞歸層級的 "規劃(P)+執行(X)"算法，會形成一個反饋回路, P時刻會監控X的執行結果做重新規劃。調度算法(S)需要識別場景，對算法管道進行調整，更像是算法管道之外的控制機制。
無論如何，在這個維度，“自動駕駛軟件框架(L.FW)”要管理算法在數據處理流程中的裝配與卸載，監督單個算法的輸入輸出數據質量。
算法的裝配可是靜態的也可以是動態的。靜態裝配是在配置文件中描述，修改后需要重新啟動才能生效。在汽車內就是要OTA更新配置。動態裝配是根據運行的狀態動態決定算法模塊的安裝和卸載，甚至在不同的硬件資源上動態遷移。
靜態裝配的好處是可測試性強，能夠通過完全覆蓋的測試保證系統的可靠性。動態裝配的好處是靈活性強。一般汽車軟件為了可靠性都傾向于靜態配置。自動駕駛的算法模塊必然要動態的啟用和停止，但是動態和靜態也是相對的，我們需要的動態切換的功能也許就可以通過某種靜態的配置去支持呢。這都需要在具體的設計開發中去找具體的實現辦法。也要看 L.BSW這一層提供了哪些可用的能力。
1.4 三個平面的含義
上圖中 ，F T R 三個軸每兩個軸形成一個平面。
總結前面所述，我們必須清楚一點：“自動駕駛軟件框架(L.FW)”不做具體的算法實現，但它為算法準備好上下文，即算法執行所需的資源，時間，數據，它是算法執行的容器。另外別忘了，L.FW 包括實時域和性能域，在兩個域應該有對等的實現，還要有合適的通訊機制。當然，兩個域的具體實現架構是不一樣的，但做的事情都是上面說的范疇，不過實時域在架構上可以簡化很多。
感知算法的目標是構建環境模型
前文 已經提出了環境模型的概念。環境模型是 L.FW 層的重要產品，這里進一步詳細說明。
當我們只做一個單一場景的原型系統時，可以只談感知，感知的結果被用于后續的規劃，基本上是一個線性的模型。這個線性模型可以支持到 Level2 以下的大多數自動駕駛功能的實現。因為每個Level2 功能單獨實現時，涉及到的傳感器數量不多，需要感知數據的軟件模塊也比較單一。
2.3 節中的“駕駛輔助域控制器”就已經可以接收多種類型的感知數據。這些感知數據集中被集中表達與處理時，就已經開始有了環境模型的雛形。
2.1 環境模型的探索
下圖是 Mobileye EyeQ4 目標識別結果信息的 UML 類圖表示。內容根據 EyeQ4輸出信息的 DBC 文件反向分析整理而來。
圖3 EyeQ4 的數據語義
EyeQ4屬于 Smart Sensor, 將視覺算法與執行算法的硬件集成在了一起。算法加速使用了 Mobile 自己的專用芯片。EyeQ4通過 Can 總線輸出視覺算法檢測到的結果。從上圖中可以看出，EyeQ4 輸出的信息主要是三類：
1）Object 代表所有的目標，ObjectClass 對目標的分類，包括，小汽車，卡車，自行車，行人，動物等。MotionStatus 表示了目標的狀態，有停止，移動等，沒有移動的速度方向等更具體的信息。
2）Lane 代表車道線。更進一步有車道線的類型(實現、虛線、雙線等等)、顏色的描述。
3）TSR 是交通標識牌識別，詳細信息包括標識牌的類型和語義等。
這里有一個 LaneAssigment 有特別的意義，它表示目標在哪個車道。將兩類信息結合在了一起。
EyeQ4 也需要輸入的信息，它需要當前車輛狀態信息來幫助更好的獲取和利用前面的三類信息。比如指出哪個目標是前方車輛。
EyeQ4 是一個商業產品，上圖是其明確的對外感知數據接口協議。它內部的或許還有更細節的數據格式沒有對外公布。比如它的算法也會是多級算法級聯，每級之間的數據接口并沒有公布。公開的接口數據已經對一部分環境的描述了。
下圖是華為與國汽智聯聯合發布的《自動駕駛功能軟件接口標準》。定義了定位(Localtion)、感知融合(Enviroment)、預測(predict)、決策規劃(Plan)四個服務方面的數據接口。Common 包含一些公共概念，會被其它部分引用。括號中的英文是該標準中的用語。標準接口以 Protobuf 的格式定義。下圖是根據 Protobuf 反向分析整理出來的UML類圖。
EyeQ4 輸出的信息在《自動駕駛功能軟件接口標準》中是放在了 Common 部分。Common 還包含了從 2D點，3D點開始的基礎數據格式，停車位，可行駛區域等信息，這已經是與環境相關的內容了。詳細信息如下圖。
另外，上述接口標準中還包含了，預測和定位的內容。定位是指自車信息的一部分，自車信息包括位置、速度、姿態以及車內裝置(如油門和剎車）的狀態等等。狹義的"環境"不包括自車信息，只包含自車之外的環境。本文中提到的"環境"或者"環境模型"都包含自車信息。
上述接口標準中還包括了"預測"部分，包括行為預測和軌跡預測。行為預測指的是被檢測到的“目標”在未來一段時間可能發生的行為語義，比如啟動、減速、加速、左轉等等。軌跡預測是對“目標”在一定時間內可能行駛(或行走)的軌跡的預估。上述接口標準中沒有把這兩個預測算作環境的一部分。
我們認為環境不僅僅包括空間屬性，也應該包括時間屬性。“預測”是環境模型在時間維度上“未來”的可能結果，對應還應該有環境模型在時間維度上的“歷史”。也就是說“歷史軌跡”和“歷史行為”也是環境模型的一部分。其實在 EQ4的環境數據中，Object 有一個字段“ObjectAge”,代表的是改目標出現了多少幀。這里就已經有了一點時間屬性。感知算法中有一類跟蹤算法，也是屬于時間語義。本文中的環境模型概念包括時間屬性上的“預測”與“歷史”。
環境模型有兩種類型的層級關系，一種是分形遞歸的 EPX-SA 模型的層級。這個類比的層級關系體現在場景粒度上。假設有以下三種粒度：
粒度1. 我們關注的是一個城市范圍的場景，關心的環境信息是路網的擁堵狀況，用于規劃城市范圍從A點到B點的行駛路徑。對當前旁邊有什么車不感興趣。這些路網信息可能是通過車聯網云端獲取。
粒度2：我們關注的是街道級別(500米內)的場景，關心的環境信息是前方幾個車道的擁堵狀況，和前方兩個路口的紅綠燈的狀況。這個信息可以是車路云協同的路側單元(RSU)提供過來。這個粒度下也不用關心旁邊是否有車。
粒度3：當根據粒度2 的信息我們確定我們需要變道來避免擁堵。這時候就需要關心周邊車輛信息，車道信息。這個信息可以通過本車的傳感器獲取，也可以通過 RSU 獲取。
另一種是在粒度3情況下的，由低級(淺)到高級(深)的不同的語義層級。這里所謂的“語義”，是指有特定領域含義的結構化信息。比如一張照片，沒有語義信息的情況下它就是一堆無意義的像素點。從像素點中識別出“這是人，這是車，那是路”就是語義信息，而判斷出“人在車上”就是更深一層的語義信息。
0級就是沒有語義的原始物理信號。如攝像頭的原始像素點集合，激光雷達的點云，雷達收到的電磁波形狀。
1級是根據原始物理信號計算出來的屬性特征，偏向物理屬性(有計量單位或量綱)。比如速度，位置，顏色等。不具有與車輛行駛相關的語義信息。
2級就開始有與車輛行駛相關的語義，比如限速，左轉彎道，停車位等。一般沒有物理量綱。幾何可行駛區域。
3級語言是在2級語義上的進一步加工，有一下幾種可能情況
4級語義就是多個二三級語義的組合，比如加上了交通規程，其它目標的行為和軌跡預測之后，得出的可行駛區域。到這一級已經是最接近規劃的部分了。
如下圖所示，列舉了一些語義層級的例子。不過，本節的重點是闡述的基于語義層級的環境模型分析方法，具體的層級劃分標準，以及圖中每個語義所屬的層級有待商榷，需要進一步研究分析。
1）. 語義層級本身就是感知算法的自然邏輯，明確定義語義層級可以更清晰的界定不同類型算法的分工界面。讓各段算法更清晰的關注并解決本領域的問題
2）. 方便多路感知來源的協同工作，互為備份。Level2以下自動駕駛使用的傳感器數量較少，重疊度也不高。Level3+逐步裝備了更多的傳感器，各傳感器可能有功能重疊的部分。同時 V2X技術讓我們可以直接從云端或路側單元收到感知數據，這些經過云端或路側單元的算力處理后的感知數據直接就是2級或級語義。清晰的語義分級有利于定義不同語義等級直接的接口形式，不同來源的語義可以直接注入到環境模型中的對應位置。
3）. 低級的環境模型語義可以被用于計算多個高級語義，清晰的語義分級可以復用低級語義的技術，避免各自高級語義重復計算低級語義。
4）. 高級的環境語義能讓規劃算法的更簡單合理。目前多數感知算法的實現是做到1級語義和部分2級語義。更高級的語義經常在規劃算法中實現。在 EPX-SA模型中，每一個分形遞歸層級的 EPX 可能被調度算法替換掉。每個 P(規劃) 組件都要做高級語義的計算就會讓 P 組件復雜度提高。高層級的語義由專門的算法直接提供，每個P組件按需取用。這這樣能讓感知和規劃的分工更清晰，各自算法更專注于自己本領域的工作。
2.3 理想模型與現實模型
環境模型“理想模型與現實模型”是與“語義層級”正交的另一個維度。
理想的環境模型是假設所有得到的環境數據的各級語義是全角度、無延遲、絕對正確的。然而現實情況并非如此。現實的環境模型與理想的環境模型至少有幾方面的不同：
前面提到過，每一個傳感器可以看做是環境模型在“角度、距離、光譜區間”的一個過濾器。如下圖。一個傳感器組合就是多個過濾器的并集。但無論多少傳感器，其并集也只是整個理想環境模型的子集。
任何傳感器都有延遲，數據在多級傳輸、計算的過程中，延遲逐步累加。一張 1080p 的圖片經過目前最快的傳輸線路GMSL2(~6Gbps）需要約7毫秒的傳輸時間，然后經過多級感知算法，規劃算法，到控制輸出，需要的時間至少在30-50毫秒之間。車輛以60km/h的速度，已經走出去 0.5 到 0.8 米。
Level3~Level4 的自動駕駛實現中，各級粒度的場景會按情況進行切換，各種算法依次輪流使用計算資源，有的算法會競爭使用計算資源。那么這種數據處理的延遲會是動態的。有必要把數據延遲相關的信息內置與環境模型中，作為現實模型的一部分。
數據準確度存在一個置信區間，而且置信區間會隨著環境(日夜、天氣)等因素改變。任何算法的結果的準確度都是一個概率上的置信區間范圍。環境模型數據中如果能包含各級語義的置信區間數據，可以為規劃提供更多的依據。
2.4 環境模型作為產品邊界的定義及對開發方式的影響
環境模型還定義了 L.FW(智能駕駛軟件框架) 層內部的產品邊界。這句話有兩層含義。首先，L.FW 內部可以有多個產品的組合，第二，環境模型定義了一類產品的邊界。
我們以 Mobile 的 EyeQ 系列產品為例來說明。EyeQ 本身是一個獨立的軟硬一體的產品，很多 ADAS 解決方案都采用它做為感知的解決方案。
如下圖: 可以把它輸出的感知數據理解為一種環境模型的表達形式。環境模型左邊是模型數據的生產者，環境模型右邊是模型數據的消費者。EyeQ 作為獨立產品，扮演了模型數據的生產者角色。它使用專用的芯片和算法獲取可以量產的感知結果，以它定義的環境模型形式供其它模型數據消費者使用。
環境模型定義了模型數據的“生產者”和“消費者”之間的邊界。有了這個邊界，我們可以替換掉左側“模型生產者”的實現方式。
支持Level3智能駕駛的域控器集成了感知算法加速的硬件模塊，可以自己完成構建環境模型需要的計算。也可以用仿真軟件來作為環境模型數據的生產者，這樣及時在算法能力還不具備的情況下，也可以直接開始右側“模型數據消費者”的功能開發。這也是環境模型作為產品邊界的意義，通過產品級別的區分，可以讓不同的團隊完成各自專業的產品定義。不同的開發團隊能同時進行各自產品的開發。
2.5 環境模型模塊與接口要求
“環境模型”可以作為 FW 層提供的服務(FW:ENV:Mod)。它保存著實時的1-4級環境語義，也會保留一段時間內的歷史信息。
FW:ENV:Mod 需要提供語義注入的接口，格式符合環境模型語義規范，能夠支持多種不同層級的語義注入。FW:ENV:Pipe 是環境模型相關算法的執行管道，負責裝配算法模塊(FW:ENV:Algo)，提供算法模塊的執行環境。FW:ENV:Pipe 會在合適的語義生成時，注入到 FW:ENV:Mod 服務中。
ENV:Mod, ENV:Pipe和 ENV:Algo 一起構成了 L.FW 層的 FW:ENV 模塊。
FW:ENV 模塊整體需要對外提供環境模型的訪問接口，接口格式執行多級語義，支持現實模型的含義表達。接口需要支持 “推”和“拉”兩種形式。“接口”即請求響應接口，可選實現 Restful 形式。消費者使用"推"接口需要先向 FW:ENV 發起訂閱，數據到達后獲得通知。或者結合使用，即消費者先訂閱，收到推送的通知后，主動調用“拉”接口請求數據。
FW:ENV 模塊還有一個重要的特性，就是要能夠根據消費者當前對環境模型數據要求，動態調整算法執行管道的裝配。FW:ENV:Mod 是有所有對環境語義需求的信息，這個信息可以反饋到 FW:ENV:Pipe 來調整算法的裝配。
2.6 FW:ENV 的實現以及對上層的接口
L.FW 層包括實時域和性能域兩部分。FW:ENV 需要在兩個域都有實現。實時域的實現可能會適當簡化，主要是 Pipe 部分，可能沒有明確的 Pipe 形式，只是以獨立的 Algo 存在。但是 FW:ENV:Mod 在實時域和性能域都需要存在，并且能支持數據的同步。比如性能域的深度學習視覺算法發布的環境語義信息，運行在實時域的規劃算法可以得到。反之亦然。為了避免多余的數據傳輸，某一個域不需要的數據可以不同步，但這是優化傳輸的問題，基本的數據同步邏輯亦然不變。
FW:ENV 為上層 L.APK 層提供一些接口及SDK：
l FW:ENV 的"推""拉"接口說明及 SDK
l FW:ENV:Pipe 的定制開發說明及SDK，支持L.APK層開發自定義的 Pipe.
l FW:ENV:Algo 定制開發說明及SDK，支持 L.APK 層開發自定義的 Algo 被裝配到已有的 Pipe.
深入EPX-SA 模型 3.1 EPX的抽象語義
EPX-SA 是一個抽象模型，它對復雜自動駕駛場景進行分解，并提供一致性的表達方式。下圖描述了一個3層 EPX 的協作關系。首先我們來定義一下符號表示法。
因為EPX 的分形遞歸特性，我們在使用 EPX 標識符時，需要對其層次進行標注，不然很容易表述不清楚。我們使用下標來表達分形遞歸的層級。相對層級使用數字下標 “-1”“+1”分別表示下一層和上一層，比如 E-1 表所示下一層的E，P+1 表示上一層的P. 沒有下標表示當前層。絕對層級使用字母下標，如 Xa，Xb，Xc 表示逐個遞進層級的 X。每一組 EPXS 都是在 X+1內。
E 是對環境的感知需求，當我們有環境模型服務提供感知能力后，就不需要E來具備實際的感知能力，只需要要描述對感知的需求，并不實際執行感知動作。
P 是抽象意義的規劃，會將上一層的任務 T+1拆解為一系列的小任務序列（T1，T2，.. ,Tn）,表示為Seq<T>，Seq<T> 被送給S 進行調度。Seq<T>有時間約束屬性，下文詳述。P 會根據E的變化重新規劃新的 Seq<T>，重新被 S調度。
S 是抽象的調度器。它有幾個作用：
Seq<T> 是由P 產生的任務序列。這里的任務是一個抽象的概念，代表需要“在一定約束下需要達到的某種目標”。約束可以是對單個任務T，比如要求在一定時間內完成，或者在一定空間內完成。約束也可以是對任務序列 Seq<T>,比如要求必須按照順序完成，或者某些任務可以并行，即有不同的 X 同時執行。這將會導致仲裁機制的引入。
X 是同層次T 執行器。它要么直接完成實際的任務執行動作，或者調用其內部的下一層 E-1P-1X-1 來執行。X 每次執行完成一個T，要向通知 S ，S會檢查Seq<T>是否為空，不為空就執行下一個T，如果為空就要求P生成新的Seq<T>, P 如果根據 E 的信息發現 T+1 已經完成，將會輸出空任務序列，S將認為 X+1 已完成。
下圖用 UML 序列圖描述了一個典型的EPX 執行過程。
X+1 被創建時，其內部先創建 S,再由S創建了 E、P，E會向環境模型服務訂閱需要的環境信息
外部將 T+1 交給 X+1執行，被交給 S進行調度，S 將 T+1交給 P做規劃
P 創建了任務T1，交由S進行調度。S 創建 X，將 T1 交給X 進行執行
X 執行完成T1后銷毀 T1，通知 S 執行完成。S通知 P 重新規劃
第3，4步 重復執行，直到P 沒有新的 T 產生，通知S無新任務
最內層的 X 是會是非常簡單的執行機制，不需要進一步被分解為下一層的 EPX。這相當于遞歸的終止條件。
最外層的 EPX 往往并不是三者都屬于計算機系統。如上圖，人自身的感知完成 E 的工作，人腦完成 P 的工作，產生的任務 T 交給計算機系統X去執行。所以對于計算機系統而言，X是分形遞歸的起點。
3.2 EPX 示例 以上說的內容都非常抽象，下面我們舉具體的例子。
3.2.1 OKR的設定與逐級分解
OKR（Objectives and Key Results）即目標與關鍵成果法，是一套明確和跟蹤目標及其完成情況的管理工具和方法，由英特爾公司創始人安迪·葛洛夫（AndyGrove）發明。并由約翰·道爾（JohnDoerr）引入到谷歌使用，1999年OKR在谷歌發揚光大，在Facebook、Linked in等企業廣泛使用。2014年，OKR傳入中國。2015年后，百度、華為、字節跳動等企業都逐漸使用和推廣OKR。詳細內容參見百度百科的相關詞條(baike.baidu.com/item/OK
一個企業的 OKR 是自頂向下逐層制定的。一般來說，公司制定幾個頂級的目標(Objectives)，以及達成這個目標后的關鍵結果(key results)。然后各部門根據公司級的OKR，指定自己的OKR，然后部門內各組，到個人依次逐層制定各自的OKR。
我們可以用 EPX 模型來對OKR進行解釋。企業要對自己的業務狀況、業務數據進行了解，對市場進行分析這是企業級“E”的部分，即對企業所在的市場環境和自身狀態進行感知。基于這個感知結果，企業進行業務分析和規劃，這是“P”的部分，“P”的結果就是公司級別的OKR（目標和關鍵結果），這是 “T”。也可以把 “KR”（關鍵結果）當做 “T”, O 是 “T”的分組。公司級的領導會把這個OKR分配到各個業務部門去完成，某個部門可能只是完成一個或多個 “KR”。在這里每個業務部門就是“X”。哪個部門完成哪個“KR”，就是 S 的工作。
業務部門(X) 領到自己需要完成的“KR”（T）后，會根據自己的情況（E-1）進行分析，規劃（P-1）出自己部門的OKR（T-1），然后交由部門內的各組（X-1）去進一步制定下一級的OKR。各組的職能不一樣，能夠完成的 T-1的類型也不一樣，這由 S-1 進行分配。
組一級就是 E-2X-2P-2，到每一個人就是E-3X-3P-3。然后就不再進一步分解了。
整個逐層遞歸的分解過程就是一個完整的EPX模型的實施。這個過程將一個抽象的任務逐層落實到了具體的執行層并完成。
3.2.2 “自適應巡航”(ACC)
“ACC”作為“定速巡航”的升級功能，相對于“定速巡航”的最大優點在于不僅能夠保持駕駛人預先設定的車速，還能夠根據前方車輛的狀態自適應的調整本車的車速，甚至自動停車，并在合適的時機自動起步。
1)當前方無車輛時,ACC車輛將處于普通的巡航駕駛狀態,按照駕駛員設定的車速行駛,駕駛員只需要控制方向(橫向控制)
2)當ACC車輛前方出現目標車輛時,如果目標車輛的速度小于ACC車輛時,ACC車輛將自動開始進行減速控制，確保兩車的距離為所設定的安全距離，并以與前車相同的速度自動跟隨行駛。
3)當前方車輛停止時，本車也會剎停，待前方車輛啟動后自動起步、加速，跟隨前車。
4)為了更好的用戶體驗，ACC開啟過程中，駕駛員依舊可以和ACC系統進行少量的交互。比如車輛快停止時主動剎停，“輕踩油門”通知ACC系統隨時準備啟動等。
如下圖，我們把 ACC 的EPX 遞歸層級分為 0-3 共四級。E0和P0存在于系統之外，X0 代表ACC系統，它能完成的任務就是按照用戶的設定速度實現自適應巡航功能。X0內部有 E1、P1、X1。E1對環境的要求包括車輛信息，車道信息，本車信息，需要知道本車道前方是否有車，前方車的速度距離，還需要知道本車道的限速。P1 根據從 E1獲得的信息，決定一段時間內需要達到的車速（0~用戶設置的循環速度），交由 X1執行。X1內部的E2已經不關心，只需關心當前的自車車速，P2計算出一段時間內需要達到的加速度交由 X2執行。同理 X2內部的P2-產生油門開度信息，交由 X3執行。X-3可以是汽車VCU（車輛控制單元）。這里把X3作為遞歸的終止點，也就是說，我們認為 X3內部的執行機制對我們是透明的，對于ACC應用不需要了解其細節。當然，X3內部也可能有進一步的EPX機制，只是在這里我們不關心。
通過0~3共4級的分形遞歸，我們把問題逐步簡化。需要注意的是，X0~X3，它們執行任務的時間周期是不一樣的。
X0是啟用ACC的一個完整過程，其時間周期可以是10分鐘以上。
X1需要讓車達到某個速度，一般我們期望在保證安全和舒適的前提下，這個過程在10秒內完成。
X2 需要讓車達到某個加速度，一般這會在200~1000毫秒內完成。
X3 是達到期望的油門開度，其執行周期可能在20~200毫秒區間。
X1、X2、X3的執行時間還與其對應的 P1、P2、P3的具體輸出的任務粒度有關。一般P1、P2、P3都可采用PID控制算法， X的執行時間與對應P的算法實現是的增量區間相關。但X1、X2、X3的執行時間的數量級是逐步遞減的。我們需要根據這個數量級來判斷某一級別的EPX是否必須在實時域執行。
還有一個問題是，前面所說的ACC狀態機在哪里體現。有兩種可行的方式。
一是所有狀態機邏輯都放在P1中實現。P1中保存狀態的變化，根據不同的狀態輸出不同的速度要求。第二種方式就是引入 S1，并增加多個不同的P1的實現。多種不同的P1實現，處理狀態機中的不同場景，這里的場景可能是一個狀態，或者多個狀態的組合。比如，有的P1處理前方無車的情況，有的P1處理前方有車并且在減速的情況，有的P1處理前方有車，本車已經跟停的情況。由S1負責根據當時的情況選擇不同的P1裝配到處理流程。這樣狀態機就實際分布在 S1以及不同的P1實現中。這是另一種對問題進行分解的方式。具體選用哪種看具體的設計而定，哪種更能符合實際情況，簡化設計就使用哪種。需要具體問題具體分析。
3.3 仲裁機制
前面說過，S可以同時啟動多個并行的X執行不同的任務。如下圖：
α 和 β 是被上一層同時啟動的兩個并行執行的 EPX 運行機制。但是它們在 Xb這一層級，都是引用了同一個 Xb 的實例。這樣Xb實例就會同時收到兩個不同來源的任務執行請求。這就需要仲裁機制(Arbitration)來對多個來源的輸入進行分析，如果不沖突，能否進行合并，如果沖突選擇優先級最高的執行。
例如，車道保持輔助(LKA)功能和自動緊急剎車(AEB)功能是可以和 ACC 同時運行的，它們可以有一個獨立的EPX分形遞歸結構，但是在最內層的 X （指向VCU）可以與 ACC的分形遞歸結構共享同一個實現。這個被共享的X需要有仲裁機制A。因為LKA是輸出方向盤的扭矩來進行橫向控制，與ACC的縱向控制不沖突，一般來說可以合并一起執行。但AEB也是輸出縱向控制信號，需要與ACC的輸出進行仲裁，但AEB一般有更高的優先級。這個仲裁邏輯就由A組件來實現。
并不是所有 EPX 層級都有 A 的存在。只有能夠被多個次引用的 EPX 才需要。該層級的 A最清楚本層級的能力，它要負責該EPX層級的仲裁邏輯。
FW:ENV 與FW:EPX-SA在軟件架構上的意義
第3章我們提到L.FW層開始有智能駕駛相關的語義，這一層的主要作用是提供智能駕駛的軟件框架和基礎組件。4.1 節指出：“L.FW不做具體的算法實現，但它為算法準備好上下文，即算法執行所需的資源，時間，數據，它是算法執行的容器“。所以FW層軟件架構就就是要為各種智能駕駛相關的算法運行提供良好的組織方式和運行環境。讓算法關注與自身邏輯的實現，怎么被裝配和執行，交由框架來處理。
FW:ENV與FW:EPX-SA 是L.FW 層
最
重要的兩個框架，對整個L.FW 層的軟件架構有如下重要意義：
1. FW:ENV框架為作為構建環境模型的基礎框架，為感知提供了可標準化的語義層級，從而可以定義標準化的感知領域的API 接口，將感知能力的開發與智能駕駛的功能開發解耦合。
2. FW:ENV 框架為感知領域的算法提供了運行環境。
3. FW:EPX-SA 提供了三個維度的場景分析與簡化的方法論。
4. 這兩個框架為L1-L2開發和L3以上功能的開發提供了一致的方法論模型。
5. 讓組件式開發成為可能。FW:ENV中每一個 Pipe可以是一個組件集合，每一個算法也可以是一個組件。FW:EPX-SA 中每一個EPX層級可以是一個組件，每個層級中單獨的 EPXSA都可以成為一個組件。基于組件進行分析、設計、開發、測試，讓智能駕駛這個復雜系統的開發能夠被分解成可操作的單元，這對智能駕駛系統軟件開發具有重要意義。
6. 可以支持組件的重用機制。能力范圍、數據接口定義清楚的組件是可以被重用的。一方面可以在同一個自動駕駛系統的不同功能（或場景）中復用已經經過良好測試的組件。另一方面，積累的可復用組件庫可以大大加快新項目的開發。
7. 實質上定義了對應用層（L.APK）的API 接口形式。
L.FW 在域控制器中的實現 5.1 實時域和性能域都要實現 ENV 和 EPX-SA 框架
前面 ACC的示例中，我們提到，不同EPX 層級的執行的時間要求是不一樣的。執行時間周期越小，特別是有確定性的時間周期要求的 X 應該在實時域中完成。通常越是與車輛控制層接近的操作應該在實時域實現。某些感知算法，一般是雷達相關算法，會要求在實時域實現。因為要精確控制雷達脈沖的發送和回波采樣時間，這個時間要求一般在毫秒級別。我們應該在實時域和性能域都實現各自的 FW:ENV 和 FW:EPX-SA框架，當然實現方式可以有所不同。
5.1.1環境模型的數據同步
性能域的FW:ENV 產生的環境模型數據需要能夠被同步的實時域。也就是說，當實時域的某個EPX 中的E訂閱的環境信息，實際上是產生于性能域，但實時域的E任然只需要向實時域的FW:ENV訂閱。但所需的數據會從性能域自動同步到實時域。如下圖：
實時域需要車道線數據只需要向本域的FW:ENV訂閱。至于車道線數據如何從性能域同步到實時域，是由兩域的FW:ENV負責實現。同時，要再兩域之間同步的數據應該是充分必要的，即不需要的數據（沒有被某個E訂閱）不應該被同步。數據同步是雙向的，比如，自車狀態信息也是環境模型的一部分，一般是先從實時域獲得，要按需同步到性能域。
類似的兩域之間的數據傳遞幾乎在所有劃分了“實時域“和”性能域”的智能駕駛系統中都會有實現。那么本文所描述的數據同步機制有什么特別之處？有三點：
1）. 環境模型語義的結構化表達與標準化的定義。我們要定義多級環境模型語義的結構化表達形式（使用某種接口定義語言 IDL來描述），形成內部標準。這個結構化標準并不是為特定項目或特定智能駕駛功能設計，它應該是具有一定的通用性。當然可以有逐步的版本演進過程。
2）. 兩域之間環境模型數據同步的實現機制是通用的。一般來說，不同的項目會為兩域之間的環境模型數據傳輸單獨設計項目特定的傳輸協議。而FW:ENV框架的數據在兩域之間的傳輸不是這樣。因為我們已經定義了標準化的環境模型語義格式，所以可以做出特定項目無關的通用實現機制。即使當標準的版本發生變化時，也應該能通過代碼生成的方式產生通用的模板代碼。
3）. 運行時同步機制自動進行的。一旦系統運行起來，兩域之間環境模型數據的同步是自動進行的。實時域或性能域的環境數據消費者并不需要知道環境模型數據具體是在哪個域產生的。
5.1.2 EPX 中X的代理模式
一般來說，在EPX多層級遞歸模型的實現中，越往外層與用戶的交互就越近，實時性要求不高，多半會在性能域完成。越往內層實時性要求高，多半會在實時域完成。也就是說同一個EPX多級序列，會發生一部分在性能域，一部分在實時域的情況。這種情況下如何進行跨域的EPX多級遞歸實現呢？
解決方法就是在性能域實現一個實時域X的代理，裝配到性能域的EPX結構中。
如上圖，X2對于性能域的EPX遞歸結構而言，它是最內層，也是遞歸的終止層，沒有更細一層的EPX分解。但實際上，X2只是實時域最外層的一個X結構的代理。這個代理直接將任務發送到實時域的X2實例進行執行。
也就是說，實時域的X要被性能域使用，需要在性能域實現一個它的代理，這個代理與實際的X實例進行跨域的通訊。反之亦然。
5.2 實現方案的技術選型參考
5.2.1 L.FW 對 L.BSW 的強依賴
L. FW 層是需要基于 L.BSW 層進行開發。L.BSW 準備好了作為汽車電子控制器(ECU)所需具備的基礎功能。同時為L.FW準備好了執行環境和基礎服務。L.FW 層要使用 L.BSW層提供的執行機制，就必須按照它的應用開發規范去編寫代碼，按照它的配置規范去編寫配置文件，使用它提供的 API和服務。這會讓L.FW對 L.BSW 層構成強依賴關系。
在實時域，L.BSW 層可行的實現方式有使用 CP AutoSar 或其它RTOS。(有的情況下 實時域也會有多核心，一個核心運行 CP AutoSar , 解決與車輛交互的問題，其他核心使用簡單的 RTOS解決部分計算的問題。) 使用 CP AutoSar 那就是編寫CP BSW層的配置，生成 RTE, 編寫 SWC 使用RTE接口。如果在此基礎上是實現 L.FW ，那就是跟CP AutoSar 緊密相關的。
在性能域也是一樣的問題，如果基于 AP AutoSar 開發那就是要符合 AP 的一系列規范。當然也得到 AP 帶來好處。基于ROS2開發就是使用 ROS2的一系列概念(Node, Topic, Service, Action),與基于AP開發是完全不一樣的方式和實現架構。但是 L.FW 層如果對不同 L.BSW層各開發一套，那倒是有可能讓 L.APK層能兼容不同的L.BSW平臺。因為 L.FW層的差異化實現實際扮演了中間層的角色，屏蔽了更下一層的差異。
因此，實際開發 L.FW層之前，要先選擇好 L.BSW 層的技術方案。
作者介紹： 肖猛，北京未動科技有限公司研發VP
（閱讀原文，關注作者知乎)
北京未動科技有限公司成立于2014年，是一家汽車智能化科技企業，專注于打造高級別汽車自動駕駛的高精度感知算法、高實時性與高可靠性的系統軟件平臺及異構計算引擎。未動科技致力于賦能OEM為消費者提供更安全、更便捷的駕乘體驗。
圖3 EyeQ4 的數據語義
