（圖檔源于網絡）
引言
大家有一種認知，覺得自動駕駛進入了“下半場”。類似demo或者POC的早期工作已經不是人們關心的，這裡所謂“上半場”大多是解決常見的問題，比如感覺、定位、預測、規劃決策和控制在典型場景（即高速、街道和停車場等）的解決算法和執行方案（線控底盤技術）。
另外，在“上半場”期間，計算平台（AI晶片及其SOC）和傳感器技術的研發程序也初現成果，比如英偉達的Xavier和Orin（見附錄）、HDR攝像頭、固态雷射雷達和4D毫米波雷達等。
而“下半場”意味着要解決罕見的“長尾”場景，同時建構資料閉環的持續高效研發架構，也已經成為行業的共識。在這個過程中，如何實作自動駕駛的技術工程化落地才是關鍵，包括開發标準化和平台化、量産規模化和落地商業化（成本、車規和OTA）的工作。
01.
自動駕駛工程化的一些要素
線控底盤
底盤系統約占整車成本的10%，而線控底盤是自動駕駛的關鍵部件，因為如果不能它的支援，自動駕駛最終輸出的控制信号不一定能夠真正得到正确執行。
線控（Drive-by-wire 或 X-by-wire），即用電線（電信号）的形式來取代機械、液壓或氣動等形式的連接配接，進而不需要依賴駕駛員的力或扭矩輸入。
線控底盤主要包括制動系統、轉向系統、驅動系統和懸架系統。其具備響應速度快、控制精度高、能量回收強的特點，是實作自動駕駛不可缺少的零部件。
線控底盤技術的安全性對于自動駕駛來說，是最基礎最核心的要素。曾經的純機械式控制雖然效率低，但可靠性高；線控技術雖然适用于自動駕駛，但同時也面臨電子軟體的故障所帶來的隐患。隻有實作功能雙重甚至多重備援，才能保證在故障情況下仍可實作其基本功能。
E2A（電子電氣架構）
伴随着汽車行業“網聯化、智能化、共享化和電動化（CASE）”趨勢推動下的智能化發展，促使汽車分布式架構向着集中式架構轉變。E2A是整合汽車各類傳感器、處理器、電子電氣配置設定系統和軟硬體的總布置方案（包括資料中心平台和高性能計算平台）。
通過E2A，可以将動力總成、驅動資訊以及娛樂資訊等，轉化為實際電源配置設定的實體布局、信号網絡、資料網絡、診斷、容錯、功耗管理等電子電氣解決方案。
汽車E2A基本劃分為三個時代：分布式多MCU組網架構、功能叢集式域控制器（Domain Controller）和區域連接配接域控制器（Zone Controller）及中央平台計算機（CPC）。
自動駕駛汽車需要使用大量傳感器，車内線束也在迅速增長。車内需要傳輸的資料量激增，同時線束不僅承載的信号更多，而且資料傳輸速率要求更快。
自動駕駛在新一代E2A平台下，通過标準化API接口實作了軟硬體的真正解耦，可以更加獲得更強算力的支援，同時資料通信的帶寬也得到增強，資源配置設定和任務排程更加靈活，另外也友善OTA（over-the-air）。
針對智能汽車電子電氣架構，Aptiv提出“大腦”與“神經”結合的方案，包括三個部分：中央計算叢集、标準電源和資料主幹網絡以及電源資料中心。這個智能汽車架構關注三大特性：靈活性、生命周期内持續更新性和系統架構相對容錯性和魯棒性。
特斯拉Model3的E2A分為域控制架構和電源電源配置設定架構。駕駛輔助與娛樂系統AICM控制合并到CCM中央計算子產品當中，而電源配置設定架構則考慮自動駕駛系統所需要的電源備援要求。
Middleware（中間件）軟體平台
中間件是基礎軟體的一大類，在作業系統、網絡和資料庫之上，應用軟體的下層，其作用是為應用軟體提供運作與開發的環境，便于靈活、高效地開發和內建複雜的應用軟體。在不同的技術之間共享資源并管理計算資源和網絡通信。
另外中間件的定位不是作業系統，而是一套軟體架構，雖然包括了RTOS、MCAL、服務通信層等協定和服務。
中間件的核心是“統一标準、分散實作、集中配置”。其具備如下功能：解決汽車功能的可用性和安全性需求；保持汽車電子系統一定的備援；移植不同平台；實作标準的基本系統功能；通過網絡共享軟體功能；內建多個開發商提供的軟體子產品；在産品生命期内更好地進行軟體維護；更充分利用硬體平台處理能力；實作汽車電子軟體的更新和更新等。
面向服務的軟體架構SOA（Service-Oriented Architecture） 具有松耦合的系統，即有着中立的接口定義，這意味 着應用程式的元件和功能沒有被強制綁定，應用程式的不同元件和功能 于結構的聯系并不緊密。應用程式服務的内部結構和實作逐漸改變時， 軟體架構并不會受到過大的影響。
“接口标準可通路”和“拓展性優秀”的 SOA 使得服務元件的部 署不再依賴于特定的作業系統和程式設計語言，一定程度上實作軟硬體的分 離。SOA 軟體架構開發從使用者的角度進行功能考慮，以業務為中心，将業務 邏輯進行抽象和封裝。
新一代中間件平台支援的自動駕駛軟體，通過SOA進行适當顆粒度的功能抽象、軟體代碼插件化（獨立的開發、測試、部署及釋出） 、軟體功能服務化以及功能之間松耦合。
AI模型壓縮和加速
AI模型壓縮和加速是兩個不同的話題，壓縮重點在于減少網絡參數量，加速目的在降低計算複雜度、提升并行能力等。
目前壓縮和加速AI模型的技術大緻分為四種方案如下。
1) 參數修剪和共享：探索模型參數中的備援，并嘗試去除備援和不重要的參數；
2) 低秩分解：使用矩陣/張量分解來估計深度CNN模型的資訊參數；
3) 遷移/緊緻卷積濾波器：設計特殊的結構卷積濾波器，以減少參數空間并節省存儲/計算；
4) 知識蒸餾：學習蒸餾模型并訓練更緊湊的神經網絡以再現更大網絡的輸出。
通常，參數修剪和共享、低秩分解和知識蒸餾方法可以用于具有全聯接層和卷積層的深度神經網絡模型；另一方面，使用遷移/緊緻濾波器的方法僅适用于具有卷積層的模型。低秩分解和基于遷移/緊緻濾波器的方法提供了端到端流水線，可在CPU / GPU環境中輕松實作。參數修剪和共享會使用不同的方法，如矢量量化，二進制編碼和稀疏限制等。總之，實作壓縮和加速需要多個步驟來進行。
至于訓練方式，可以從預訓練方式中提取基于參數修剪/共享低秩分解的模型，或者從頭開始訓練（train from scratch）。遷移/緊緻卷積濾波器和知識蒸餾模型隻能從頭開始訓練。這些方法是獨立設計的，互相補充。例如，可以一起使用遷移網絡層以及參數修剪和共享，也可以将模型量化和二值化與低秩分解近似一起使用。
知識蒸餾将深度寬度網絡壓縮成較淺網絡，其中壓縮模型模拟了複雜模型所學習的函數。基于蒸餾方法的主要思想是通過學習得到softmax輸出的類分布，将知識從大教師模型轉變為國小生模型。一種蒸餾架構通過遵循“學生-教師”範式來簡化深度網絡的訓練，其中學生根據教師輸出的軟版本受到懲罰；該架構将教師網絡（teacher network）內建到一個有類似深度的學生網絡（student network）中，訓練學生預測輸出和分類标簽。
車載自動駕駛晶片
自動駕駛晶片以及SOC（system on chip），目的是實作高效、低成本、低功耗的自動駕駛計算平台。而工控機實作的自動駕駛平台，是很難實作量産規模化和控制成本的。
一個SOC可能會包括自動駕駛晶片（深度學習模型實作）、CPU/GPU、DSP晶片、ISP晶片和CV（計算機視覺）晶片等。在晶片基礎上，還有一個支援深度學習模型實作的編譯器需要開發來最大效率地提高晶片的使用率，避免處理器等待或者資料瓶頸堵塞。
其中算法的适配性（子產品和程序分解）、自動駕駛軟體的高效運作（包括程序資料通信、深度學習模型加速、任務排程和資源管理等）及其安全（功能安全/預期功能安全）保障，都是需要很多工程性的艱苦努力和必要付出的代價（比如系統備援）。
資料閉環平台
AI的最挑戰應用之一，自動駕駛，是一個長尾效應的典型。大量少見的極端情況（corner case）往往是缺乏搜集的訓練資料，這樣要求我們在一個閉環中不斷地發現這些有價值的資料，标注後放入訓練集中，同時也放入我們的測試集或者仿真場景庫；在NN模型得到疊代更新後，會再傳遞到自動駕駛車進入新的循環，即資料閉環。
如圖就是特斯拉的資料閉環架構：确認模型誤差、資料标注和清洗、模型訓練和重新部署/傳遞。
如圖是谷歌waymo的資料閉環平台：資料挖掘、主動學習、自動标注、自動化模型調試優化、測試校驗和部署釋出。
資料閉環需要一個雲計算/邊緣計算平台和大資料的處理技術，這個不可能在單車或單機實作的。大資料雲計算發展多年，在資料批處理/流處理、工作流管理、分布式計算、狀态監控和資料庫存儲等方面提供了資料閉環的基礎設施支援。
模型訓練平台，主要是機器學習（深度學習）而言，開源的最早有Caffe，目前最流行的是Tensorflow和Pytorch（Caffe2并入）。在雲平台部署深度學習模型訓練，一般采用分布式。按照并行方式，分布式訓練一般分為資料并行和模型并行兩種。當然，也可采用資料并行和模型并行的混合。
模型并行：不同GPU負責網絡模型的不同部分。例如，不同網絡層被配置設定到不同的GPU，或者同一層不同參數被配置設定到不同GPU。
資料并行：不同GPU有模型的多個副本，每個GPU配置設定不同的資料，将所有GPU計算結果按照某種方式合并。
模型并行不常用，而資料并行涉及各個GPU之間如何同步模型參數，分為同步更新和異步更新。同步更新等所有GPU的梯度計算完成，再計算新權值，同步新值後，再進行下一輪計算。異步更新是每個GPU梯度計算完無需等待，立即更新權值，然後同步新值進行下一輪計算。
分布式訓練系統包括兩種架構：Parameter Server Architecture（PS，參數伺服器）和Ring -AllReduce Architecture（環-全歸約）。
主動學習（active learning）的目标是找到有效的方法從無标記資料池中選擇要标記的資料，最大限度地提高準确性。主動學習通常是一個疊代過程，在每次疊代中學習模型，使用一些啟發式方法從未标記資料池中選擇一組資料進行标記。是以，有必要在每次疊代中為了大子集查詢所需标簽，這樣即使對大小适中的子集，也會産生相關樣本。
機器學習模型往往會在out-of-distribution（OOD) 資料上失敗。檢測OOD是确定不确定性（Uncertainty）的手段，既可以安全報警，也可以發現有價值的資料樣本。
不确定性有兩種來源：任意（aleatoric）不确定性和認知（epistemic）不确定性。導緻預測不确定性的資料不可減（Irreducible）不确定性，是一種任意不确定性（也稱為資料不确定性）。另一類不确定性是由于知識和資料不适當造成的認知不确定性（也稱為知識/模型不确定性）。
最常用的不确定性估計方法是貝葉斯近似（Bayesian approximation）法和內建學習（ensemble learning）法。
一類 OOD 識别方法基于貝葉斯神經網絡推理，包括基于 dropout 變分推理（variational inference）法、馬爾可夫鍊蒙特卡羅 (MCMC) 和蒙特卡羅 dropout法等。另一類OOD識别方法包括 (1) 輔助損失或NN 架構修改等訓練方法，以及 (2) 事後統計（post hoc statistics）方法。
資料樣本中有偏離正常的意外情況，即所謂的極端情況（corner case）。線上檢測可以用作安全監控和警告系統，在corner case情況發生時進行識别。線下檢測可應用于大量收集的資料，選擇合适的訓練和相關測試資料。
DevOps
DevOps，簡單地來說，就是更好的優化開發(DEV)、測試(QA)、運維(OPS)的流程，開發運維一體化，通過高度自動化工具與流程，使得軟體建構、測試、釋出更加快捷、頻繁和可靠。
DevOps 是一個完整面向IT運維的工作流，IT 自動化以及持續內建（CI）/持續部署（CD）作為基礎，來優化程式開發、測試、系統運維等所有環節。
主幹開發是CI前提，自動化以及代碼集中管理是實施CI的必要條件。DevOps是CI思想的延伸，CD/CI是 DevOps 的技術核心。
MLOps
MLOps的核心目标是使得AI模型從訓練到布署的整條端到端鍊路能夠穩定，高效地運作在生産環境中，滿足客戶的終端業務需求。
為了達到這個目标，其對AI系統核心技術也提出了相應的需求。比如布署自動化，對AI架構的前端設計會提出明确的需求，如果AI架構的前端設計不利于導出完整的模型檔案，會使得大量的下遊不得不在布署環節引入針對各自業務場景需求的”更新檔”。
布署自動化的需求，也會催生一些圍繞AI核心系統的軟體元件，比如模型推理布署優化、模型訓練預測結果的可複現性和AI生産的系統可伸縮性。
場景庫建設和測試
基于場景的自動駕駛汽車測試方法是實作加速測試、加速評價的有效途徑。
“場景作為行駛環境與汽車駕駛情景的一種綜合展現，描述了車輛外部行駛環境的道路場地、周邊交通、氣象(天氣和光照)和車輛自身的駕駛任務和狀态等資訊，是影響和判定智能駕駛功能與性能因素集合的一種抽象與映射，具有高度的不确定、不可重複、不可預測和不可窮盡等特征”。
測試場景的分類方法有所不同：
1）按照場景的抽象程度，可分為功能場景、邏輯場景、具體場景；
2）按照測試場景資料來源，可分為自然駕駛場景、危險工況場景、标準法規場景和參數重組場景。
一個場景庫的次元包括：
場景：靜态部分和動态部分
交通：駕駛行為和VRU（行人、自行車）等非機動行為
天氣：傳感器（攝像頭、雷達、雷射雷達）和幹擾
場景庫建設，基本上基于真實、虛拟以及專家資料等不同的資料源，通過場景挖掘、場景分類、場景演繹等方式分層建構成一個完整的體系。
德國PEGASUS項目（2016~2019年5月）聚焦于高速公路場景的研究和分析，基于事故以及自然駕駛資料建立場景資料庫，以場景資料庫為基礎對系統進行驗證。
該研究定義了場景（scenario）“功能—邏輯—具體”（functional-logical-concrete）三級分層體系，以及面向概念—開發—測試—标定 (concept-development-testing-calibration) 的場景庫建構流程及智能駕駛測試方法。
PEGASUS通過開發OpenScenario接口試圖建立可用于模拟仿真、試驗場和真實環境中測試和試驗進階智能駕駛系統的标準化流程。
該項目分四個階段：1）場景分析&品質評估，定義一種系統的場景生成方法以及場景檔案的的文法結構，計算場景的KPI，定義一套基于專家經驗的場景困難（危險）程度評價方法；2）實施流程，以安全為基礎，設計一套足夠靈活的、魯棒性強的适用于自動駕駛功能的設計實施流程；3）測試，輸出為一套用于實驗室（仿真軟體，台架等）以及真實交通場景的方法和工具鍊；4）結果驗證&內建，對前三個階段的結果進行分析。
PEGASUS建立三種測試場景格式标準，即OpenCRG、OpenDRIVE和OpenSCENARIO，定義了測試場景的六層模型：道路層、交通基礎設施、前兩層的臨時操作（如道路施工現場）、對象、環境和數字資訊。
02.
結束語
自動駕駛進入一個工程化落地的時期，這裡提到了一些必要的工程化要素，如線控底盤、電子電氣架構、中間件軟體平台、模型壓縮加速、車載自動駕駛晶片（計算平台）、資料閉環、DevOps/MLOps和場景庫建設及其測試等。
另外，這裡還有沒提到的工程問題，比如傳感器清洗、計算平台的記憶體/指令優化和安全備援設計等等。
轉載自汽車ECU開發，文中觀點僅供分享交流，不代表本号立場，如涉及版權等問題，請您告知，我們将及時處理。