引言
大家有一種認知，覺得自動駕駛進入了“下半場”。類似demo或者POC的早期工作已經不是人們關心的，這裡所謂“上半場”大多是解決常見的問題，比如感知、定位、預測、規劃決策和控制在典型場景（即高速、街道和停車場等）的解決演算法和執行方案（線控底盤技術）。
另外，在“上半場”期間，計算平臺（AI晶片及其SOC）和感測器技術的研發程序也初現成果，比如英偉達的Xavier和Orin（見附錄）、HDR攝像頭、固態鐳射雷達和4D毫米波雷達等。
而“下半場”意味著要解決罕見的“長尾”場景，同時構建資料閉環的持續高效研發框架，也已經成為行業的共識。在這個過程中，如何實現自動駕駛的技術工程化落地才是關鍵，包括開發標準化和平臺化、量產規模化和落地商業化（成本、車規和OTA）的工作。
自動駕駛工程化的一些要素
· 線控底盤
底盤系統約佔整車成本的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生產的系統可伸縮性。
l 場景庫建設和測試
基於場景的自動駕駛汽車測試方法是實現加速測試、加速評價的有效途徑。
“場景作為行駛環境與汽車駕駛情景的一種綜合體現，描述了車輛外部行駛環境的道路場地、周邊交通、氣象(天氣和光照)和車輛自身的駕駛任務和狀態等資訊，是影響和判定智慧駕駛功能與效能因素集合的一種抽象與對映，具有高度的不確定、不可重複、不可預測和不可窮盡等特徵”。
測試場景的分類方法有所不同：
· 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，定義了測試場景的六層模型：道路層、交通基礎設施、前兩層的臨時操作（如道路施工現場）、物件、環境和數字資訊。
結束語
自動駕駛進入一個工程化落地的時期，這裡提到了一些必要的工程化要素，如線控底盤、電子電氣架構、中介軟體軟體平臺、模型壓縮加速、車載自動駕駛晶片（計算平臺）、資料閉環、DevOps/MLOps和場景庫建設及其測試等。
另外，這裡還有沒提到的工程問題，比如感測器清洗、計算平臺的記憶體/指令最佳化和安全冗餘設計等等。
附錄A：自動駕駛工程化舉例
l Pony（小馬科技）
2021 年 2 月，小馬宣佈最新一代的自動駕駛車輛從一套標準化產線正式下線，開啟全天候自動駕駛的公開道路測試，並加入到各地的 Robotaxi 車隊中做規模化的運營。
這批車輛從設計、開發到產線生產、標定和驗證，經歷非常嚴格的標準化流程。整個流程裡面大概涉及 40 多道工序（如攝像頭和鐳射雷達清洗、震動和防水等）200多項質檢專案，儘可能保證整個系統的一致性。
比起以前的系統，在硬體穩定性方面大概有 30 倍到 50 倍提升的效果，整個自動駕駛系統的生產效率和前一年相比大概能夠提升 6 倍。
l AutoX（安途）
2021年12月22日，AutoX（安途）對外揭曉AutoX RoboTaxi超級工廠的內部影片。該超級工廠由Auto X獨立設計、投建。而RoboTaxi則是AutoX與克萊斯勒FCA集成合作打造，具備車規級冗餘線控，支援量產。
AutoX無人車零部件進入倉庫後，先進行質量檢測，透過檢測的零件走上部裝線，進行區域性整合。
總裝線由半自動化滑板傳輸線和吊裝輸送線組成，採用ABB 7軸機器人。電控系統與傳動系統則是由西門子、歐姆龍、施耐德、飛利浦、三菱、SEW等提供。從車內操作介面可以對系統的全部軟硬體模組進行質檢。
下線時，車間內自動化多感測器在轉盤、四輪定位等方面進行標定，並在廠內完成恆溫房、噴淋房等車規級檢測，在出廠時即可進入無人駕駛狀態。
附錄B：英偉達自動駕駛晶片
l Xavier
Xavier被NVIDIA稱作為“世界上最強大的SoC（片上系統）”，有高達 32 TOPS的峰值計算能力和 750 Gbps 的高速 I/O 效能。
Xavier SoC基於臺積電12nm工藝， CPU採用NVIDIA自研8核ARM64架構（代號Carmel），GPU採用512顆CUDA的Volta，支援FP32/FP16/INT8，20W功耗下單精度浮點效能1.3TFLOPS，Tensor核心效能20TOPs，解鎖到30W後可達30TOPs。
Xavier 內有六種不同的處理器：Volta TensorCore GPU，八核ARM64 CPU，雙NVDLA 深度學習加速器（DLA），影象處理器，視覺處理器和影片處理器。
l Orin
和Xavier相比，Orin的算力提升到接近7倍，從30TOPS提升到了200TOPS。CPU部分從ARM Cortex A57到A78。Xavier的功耗大概30W，Orin功耗僅為45W左右。
Orin多晶片方案版本用兩個Orin + 兩個7nmA100 GPU，算力達到2000TOPS。Orin 系統級晶片整合NVIDIA 新GPU 架構Ampere、Arm Hercules CPU 核心、新深度學習加速器（DLA）和計算機視覺加速器（PVA），每秒執行200萬億次計算。
DRIVE AGX系列推出一款新型Orin SoC。其功率僅為5瓦，但效能卻可達到10 TOPS。
l Hyperion
NVIDIA 構建並開放 DRIVE Hyperion 平臺。該平臺配置高效能計算機和感測器架構，滿足自動駕駛汽車的安全要求。DRIVE Hyperion 採用適用於軟體定義汽車的冗餘 NVIDIA DRIVE Orin 系統級晶片，持續改善和建立各種基於軟體和服務的新業務模式。
新平臺採用 12 個環繞攝像頭、12 個超聲波模組、9 個普通雷達、3 個內部感知攝像頭和 1 個前置鐳射雷達打造。是有功能安全的架構設計，具備故障備份。
不少汽車製造商、卡車製造商、一級供應商和無人駕駛出租車服務公司採用了此 DRIVE Hyperion 架構。
附錄C：車載中介軟體AUTOSAR
AUTOSAR (AUTomotive Open System ARchitecture) 由各大整車廠商和零部件廠商開始著手聯合制定軟體的標準化介面。它是由BMW、BOSCH、Continental、DAIMLER、Ford、OPEL、PSA、TOYOTA、VW等共同制定的汽車開放式系統架構標準，俗稱AUTOSAR Classic （CP），基本上做為MCU/ECU的標準，包 括髮動機控制機和電機控制器。
CP主要包含微控制器層（Microcontroller）、基礎軟體層（Basic Software）、中介軟體層（Runtime Environment，RTE）以及應用層（Application）。基礎軟體層再分為服務層（Services Layer）、ECU抽象層（ECU Abstraction Layer）、微控制器抽象層（Microcontroller Abstraction Layer）和複雜驅動（Complex Device Drivers）。
具體講，服務層主要提供各類維持系統執行的基礎服務，如監控，診斷，通訊，以及實時作業系統等；ECU抽象層主要功能是封裝微處理器及其外圍裝置；微處理器抽象層主要功能是對微控制器進行分裝，例如I/O、ADC、SPI等；複雜驅動用於那些不能進行統一封裝的複雜硬體，為上層RTE訪問硬體提供支援。
AUTOSAR Adaptive platform （AP），更多的應用於 ADAS 和自動駕駛等對於計算能力和頻寬通訊要求更高的領域中，儘可能從其他領域 (如消費電子產品) 的發展中獲益，同時仍然考慮汽車的特定要求，如功能安全。
AP平臺主要提供高效能計算與通訊機制，並且提供靈活的軟體配置，例如軟體遠端更新（OTA）等，包括如下主要部分：（1）使用者應用，一個應用可以為其他應用提供服務，這樣的服務稱為非平臺服務；（2）支援使用者應用的AUTOSAR Runtime（ARA，Autosar Runtime for Adaptive Application），其由功能叢集提供的一系列應用介面組成，其中有兩種型別的功能叢集，即自適應平臺基礎功能和自適應平臺服務；（3）硬體視作機器（Machine），可以透過各種管理程式相關技術虛擬化，並且可以實現一致的平臺檢視。
AP需要支援E2A的兩個關鍵特徵：異構軟體平臺的整合和麵向服務的通訊。AP元件封裝面向服務SOA軟體底層的通訊細節 (包括SOME/IP協議，IPC等)，同時提供代理(Proxy)-骨架(Skeleton)模型，方便應用開發人員呼叫標準服務介面(API)進行開發。
AP選擇POSIX PSE 51作為OS要求，避免底層OS過於複雜，上層應用限制使用一些複雜功能，避免overspec。
