引言
大家有一種認知，覺得自動駕駛進入了“下半場”。類似demo或者POC的早期工作已經不是人們關心的，這裡所謂“上半場”大多是解決常見的問題，比如感覺、定位、預測、規劃決策和控制在典型場景（即高速、街道和停車場等）的解決算法和執行方案（線控底盤技術）。
另外，在“上半場”期間，計算平台（AI晶片及其SOC）和傳感器技術的研發程序也初現成果，比如英偉達的Xavier和Orin、HDR攝像頭、固态雷射雷達和4D毫米波雷達等。
而“下半場”意味着要解決罕見的“長尾”場景，同時建構資料閉環的持續高效研發架構，也已經成為行業的共識。在這個過程中，如何實作自動駕駛的技術工程化落地才是關鍵（見附錄的例子），包括開發标準化和平台化、量産規模化和落地商業化（成本、車規和OTA）的工作。
自動駕駛工程化的一些要素
· 線控底盤
底盤系統約占整車成本的10%，而線控底盤是自動駕駛的關鍵部件，因為如果不能它的支援，自動駕駛最終輸出的控制信号不一定能夠真正得到正确執行。
線控（Drive-by-wire 或 X-by-wire），即用電線（電信号）的形式來取代機械、液壓或氣動等形式的連接配接，進而不需要依賴駕駛員的力或扭矩輸入。
線控底盤主要包括制動系統、轉向系統、驅動系統和懸架系統。其具備響應速度快、控制精度高、能量回收強的特點，是實作自動駕駛不可缺少的零部件。
線控底盤技術的安全性對于自動駕駛來說，是最基礎最核心的要素。曾經的純機械式控制雖然效率低，但可靠性高；線控技術雖然适用于自動駕駛，但同時也面臨電子軟體的故障所帶來的隐患。隻有實作功能雙重甚至多重備援，才能保證在故障情況下仍可實作其基本功能。
全球L4自動駕駛創業公司最主流的測試開發車是林肯MKZ，就是因為其高性能高精度的線控能力表現，易于使用逆向工程實作改裝，還有成熟的線控改造服務提供商AS和Dataspeed，共同為自動駕駛初創企業研發提供了穩定易用的平台。
電動車底盤有三電系統（電池、電機、電控），有能量回收和熱管理系統、線控轉向和制動系統和懸挂系統等。滑闆底盤是把安裝在底盤的轉向、制動、三電和懸架等子產品化布置，根據車型要求相應的變更需求子產品，進而縮短開發周期。由于其外形類似于滑闆，故名“滑闆底盤”。滑闆底盤擁有極高的靈活性，可以滿足自動駕駛系統的需要。
滑闆底盤最核心的優勢是軟體定義及軟硬體解耦。它可以簡化機械結構，減少零部件以及硬體帶來的邊界和限制，可通過輪毂電機的分布式驅動算法更新實作更安全的底盤功能。底盤能夠真正做到完全由軟體定義，具體展現在分布式驅動的算法上。因為分布式驅動的算法能夠實作底盤的完全解放，讓它從傳統的汽車底盤變成真正的輪式機器人。其背後需要一套算法驅動的設計和柔性制造系統，并實作多品類小批量的分布式制造，才能完全釋放滑闆底盤的子產品化、靈活性等優勢。
Arrival、Rivian、Canoo和REE等歐美創業公司，還有中國創業公司Upower（悠跑科技）和PIX Moving，都宣布采用滑闆地盤。而豐田、現代和雪鐵龍等車企，還有舍弗勒和采埃孚等Tier -1，都紛紛開始研發滑闆底盤。
· E2A（電子電氣架構）
伴随着汽車行業“網聯化、智能化、共享化和電動化（CASE）”趨勢推動下的智能化發展，促使汽車分布式架構向着集中式架構轉變。E2A是整合汽車各類傳感器、處理器、電子電氣配置設定系統和軟硬體的總布置方案（包括資料中心平台和高性能計算平台）。
通過E2A，可以将動力總成、驅動資訊以及娛樂資訊等，轉化為實際電源配置設定的實體布局、信号網絡、資料網絡、診斷、容錯、功耗管理等電子電氣解決方案。
汽車E2A基本劃分為三個時代：分布式多MCU組網架構、功能叢集式域控制器（Domain Controller）和區域連接配接域控制器（Zone Controller）及中央平台計算機（CPC）。
自動駕駛汽車需要使用大量傳感器，車内線束也在迅速增長。車内需要傳輸的資料量激增，同時線束不僅承載的信号更多，而且資料傳輸速率要求更快。
自動駕駛在新一代E2A平台下，通過标準化API接口實作了軟硬體的真正解耦，可以更加獲得更強算力的支援，同時資料通信的帶寬也得到增強，資源配置設定和任務排程更加靈活，另外也友善OTA（over-the-air）。
針對智能汽車E2A，Aptiv提出“大腦”與“神經”結合的方案，包括三個部分：中央計算叢集、标準電源和資料主幹網絡以及電源資料中心。這個智能汽車架構關注三大特性：靈活性、生命周期内持續更新性、以及系統架構相對容錯性和魯棒性。
特斯拉Model 3的E2A分為域控制架構和電源電源配置設定架構。駕駛輔助與娛樂系統AICM控制合并到CCM中央計算子產品當中，而電源配置設定架構則考慮自動駕駛系統所需要的電源備援要求。
· Middleware（中間件）軟體平台
中間件是基礎軟體的一大類，在作業系統、網絡和資料庫之上，應用軟體的下層，其作用是為應用軟體提供運作與開發的環境，便于靈活、高效地開發和內建複雜的應用軟體。在不同的技術之間共享資源并管理計算資源和網絡通信。
另外中間件的定位不是作業系統，而是一套軟體架構，雖然包括了RTOS、微控制抽象層（MCAL）、服務通信層等協定和服務。
中間件的核心是“統一标準、分散實作、集中配置”。其具備如下功能：解決汽車功能的可用性和安全性需求；保持汽車電子系統一定的備援；移植不同平台；實作标準的基本系統功能；通過網絡共享軟體功能；內建多個開發商提供的軟體子產品；在産品生命期内更好地進行軟體維護；更充分利用硬體平台處理能力；實作汽車電子軟體的更新和更新等。
面向服務的軟體架構SOA（Service-Oriented Architecture）具有松耦合的系統，即有着中立的接口定義，這意味 着應用程式的元件和功能沒有被強制綁定，應用程式的不同元件和功能于結構的聯系并不緊密。應用程式服務的内部結構和實作逐漸改變時， 軟體架構并不會受到過大的影響。
“接口标準可通路”和“拓展性優秀”的 SOA 使得服務元件的部署不再依賴于特定的作業系統和程式設計語言，一定程度上實作軟硬體的分離。SOA軟體架構開發從使用者的角度進行功能考慮，以業務為中心，将業務邏輯進行抽象和封裝。
新一代中間件平台支援的自動駕駛軟體，通過SOA進行适當顆粒度的功能抽象、軟體代碼插件化（獨立的開發、測試、部署及釋出） 、軟體功能服務化以及功能之間松耦合。
AUTOSAR（見附錄）是一個各大整車廠商和零部件廠商聯合制定軟體的标準化接口。
· AI模型壓縮和加速
AI模型壓縮和加速是兩個不同的話題，壓縮重點在于減少網絡參數量，加速目的在降低計算複雜度、提升并行能力等。
目前壓縮和加速AI模型的技術大緻分為四種方案如下：
1) 參數修剪和共享：探索模型參數中的備援，并嘗試去除備援和不重要的參數；
2) 低秩分解：使用矩陣/張量分解來估計深度CNN模型的資訊參數；
3) 遷移/緊緻卷積濾波器：設計特殊的結構卷積濾波器，以減少參數空間并節省存儲/計算；
4) 知識蒸餾：學習蒸餾模型并訓練更緊湊的神經網絡以再現更大網絡的輸出。
通常，參數修剪和共享、低秩分解和知識蒸餾方法可以用于具有全聯接層和卷積層的深度神經網絡模型；另一方面，使用遷移/緊緻濾波器的方法僅适用于具有卷積層的模型。低秩分解和基于遷移/緊緻濾波器的方法提供了端到端流水線，可在CPU / GPU環境中輕松實作。參數修剪和共享會使用不同的方法，如矢量量化，二進制編碼和稀疏限制等。總之，實作壓縮和加速需要多個步驟來進行。
至于訓練方式，可以從預訓練方式中提取基于參數修剪/共享低秩分解的模型，或者從頭開始訓練（train from scratch）。遷移/緊緻卷積濾波器和知識蒸餾模型隻能從頭開始訓練。這些方法是獨立設計的，互相補充。例如，可以一起使用遷移網絡層以及參數修剪和共享，也可以将模型量化和二值化與低秩分解近似一起使用。
知識蒸餾将深度寬度網絡壓縮成較淺網絡，其中壓縮模型模拟了複雜模型所學習的函數。基于蒸餾方法的主要思想是通過學習得到softmax輸出的類分布，将知識從大教師模型轉變為國小生模型。一種蒸餾架構通過遵循“學生-教師”範式來簡化深度網絡的訓練，其中學生根據教師輸出的軟版本受到懲罰；該架構将教師網絡（teacher network）內建到一個有類似深度的學生網絡（student network）中，訓練學生預測輸出和分類标簽。
模型參數可以采用32位/比特浮點（FP32）格式表示，但不如以定點（fixed point）格式表示，因為這幾乎沒有精度損失，甚至更高，但計算量卻較低。這種政策不僅可以減少占用的記憶體，還可以減少與計算相關的功耗。但是，DNN模型的每一層對準确性都有不同的影響，是以可以使用細粒度的混合精度量化方法，其中每層權重和激活值的位寬不同。
· 車載自動駕駛晶片
自動駕駛晶片以及SOC（system on chip），目的是實作高效、低成本、低功耗的自動駕駛計算平台。而工控機實作的自動駕駛平台，是很難實作量産規模化和控制成本的。
一個SOC可能會包括自動駕駛晶片（深度學習模型實作）、CPU/GPU、DSP晶片、ISP晶片和CV（計算機視覺）晶片等。在晶片基礎上，還有一個支援深度學習模型實作的編譯器需要開發來最大效率地提高晶片的使用率，避免處理器等待或者資料瓶頸堵塞。
其中算法的适配性（子產品和程序分解）、自動駕駛軟體的高效運作（包括程序資料通信、深度學習模型加速、任務排程和資源管理等）及其安全（功能安全/預期功能安全）保障，都是需要很多工程性的艱苦努力和必要付出的代價（比如系統備援）。
目前英偉達的Xavier和Orin（見附錄）是市場上最成功最開放的自動駕駛晶片。
· 資料閉環平台
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）作為基礎，來優化程式開發、測試、系統運維等所有環節。
主幹（trunk- based）開發是CI前提（不是特征分支開發），自動化以及代碼集中管理是實施CI的必要條件。DevOps 是CI思想的延伸，CD/CI是 DevOps 的技術核心。
· MLOps
MLOps的核心目标是使得AI模型從訓練到布署的整條端到端鍊路能夠穩定，高效地運作在生産環境中，滿足客戶的終端業務需求。
為了達到這個目标，其對AI系統核心技術也提出了相應的需求。比如布署自動化，對AI架構的前端設計會提出明确的需求，如果AI架構的前端設計不利于導出完整的模型檔案，會使得大量的下遊不得不在布署環節引入針對各自業務場景需求的”更新檔”。
布署自動化的需求，也會催生一些圍繞AI核心系統的軟體元件，比如模型推理布署優化、模型訓練預測結果的可複現性和AI生産的系統可伸縮性。
· 場景庫建設和測試
基于場景的自動駕駛汽車測試方法是實作加速測試、加速評價的有效途徑。
“場景作為行駛環境與汽車駕駛情景的一種綜合展現，描述了車輛外部行駛環境的道路場地、周邊交通、氣象(天氣和光照)和車輛自身的駕駛任務和狀态等資訊，是影響和判定智能駕駛功能與性能因素集合的一種抽象與映射，具有高度的不确定、不可重複、不可預測和不可窮盡等特征”。
測試場景的分類方法有所不同：
1）按照場景的抽象程度，可分為功能場景、邏輯場景、具體場景；
2）按照測試場景資料來源，可分為自然駕駛場景、危險工況場景、标準法規場景和參數重組場景。
一個場景庫的次元包括：
場景：靜态部分和動态部分
交通：駕駛行為和VRU（行人、自行車）等非機動行為
天氣：傳感器（攝像頭、雷達、雷射雷達）和幹擾
場景庫建設，基本上基于真實、虛拟以及專家資料等不同的資料源，通過場景挖掘、場景分類、場景演繹等方式分層建構成一個完整的體系。
德國PEGASUS（見附錄）是一個建立場景資料庫的傳統方法項目。
· 安全備援設計
不少自動駕駛公司都公布過自己的安全報告，其中涉及到自動駕駛安全的諸多設計考慮，主要有：
系統安全
操作域設計（ODD）
應變（最小風險條件）
目标和事件監測和反應（OEDR）
資訊安全
驗證和确認（V&V）
政府法規
自動駕駛車輛應工作在操作域設計（ODD）的場景，在出現任何故障和故障時，可預測、可控和安全地運作。與安全相關的故障是指一種對人員造成合理機率傷害的故障。其他類型的故障可能會導緻與安全無關的結果，例如駕駛員的不幸體驗。
所謂最小風險條件是一種系統狀态“當給定行程無法或不應完成時，降低撞車風險……這可能需要自動将車輛停在其目前行駛道路内，或需要進行更廣泛的機動，以便車輛從活動車道上移開和/或自動将車輛傳回排程中心。對于L3級自動駕駛系統，當接近ODD出口或出現自動駕駛故障時，一個善于接受的“應變準備就緒使用者（fallback-ready user）”應準備好接管駕駛任務。
ISO 26262，“用于功能安全的道路車輛”，國際标準化組織于2011年制定的汽車生産中電氣和/或電子系統功能安全标準。功能安全過程需要進行危險分析和安全風險評估（hazard analysis and safety risk assessment），該評估指定了一個稱為汽車安全完整性等級（Automotive Safety Integrity Level，ASIL）的屬性。對于高度安全相關的功能，内置了特定的備援，以便這些系統的故障不會造成不合理的安全風險。
這種情況可分為三類：“故障運作（fail- operational）”，其中一個傳感器可能會故障，但備援傳感器可以繼續系統的安全運作；“故障降級（fail-degraded）”，當發生故障時，系統仍在運作，但可能不具備全部功能；以及“故障安全（fail-safe）”，即系統不再運作，但故障不會造成不安全狀況。
ISO 26262的目标是：
提供汽車安全生命周期，并支援定制必要的活動
涵蓋整個開發過程的功能安全方面
提供一種基于汽車特定風險的方法來确定風險等級（ASIL）
使用ASIL來指定各個條目的必要安全要求
提供驗證和确認（V&V）措施的要求
ISO 26262标準包括十部分，分别為：
詞彙，功能安全管理，概念階段（1-3）；
系統級、硬體級和軟體級的産品開發（4-6）；
生産經營及配套流程（7-8）；
汽車安全完整性等級（ASIL）導向分析和安全導向分析（9）；
準則（10）。
汽車安全完整性等級（ASIL）是ISO 26262-道路車輛功能安全标準定義的風險分類方案。按标準有4個ASIL級别，即A-B-C-D，從最低到最高。ASIL的确定是危害分析和風險評估（hazard analysis andrisk assessment）的結果。
ASIL D代表在發生故障時可能發生嚴重危及生命或緻命傷害，并要求最進階别的保證，以確定相關安全目标充分且已實作。提到“品質管理（QM）”，QM級别意味着與危險事件相關的風險并非不合理，是以不需要按照ISO 26262采取安全措施。
IEC 61508定義了廣泛引用的安全完整性等級（SIL）分類。ASIL是風險的定性度量，SIL是根據安全功能的類型定量定義為危險故障的機率或頻率。ASIL D與SIL 3對齊，ASIL A與SIL 1相當。
美國國家高速交通安全局（NHTSA，National Highway Traffic Safety Administration）負責制定、設定和執行美國聯邦機動車安全标準（FMVSS）以及機動車和裝置法規。其使命描述為“拯救生命、防止受傷、減少與車輛相關的碰撞”，確定自動駕駛車輛的道路測試将對其他道路使用者的風險降至最低；另外，将測試操作限制在适合測試自動駕駛車輛能力的道路、交通和環境條件下；并制定報告要求，以在測試期間監控自動駕駛技術的性能，確定從自動駕駛模式過渡到駕駛員控制的過程安全、簡單和及時；自動駕駛測試車輛應具有檢測、記錄并通知駕駛員自動技術系統出現故障的能力，確定任何自動駕駛車輛技術的安裝和操作不會禁用任何聯邦要求的安全功能或系統。
ISO/PAS 21448規定了車輛預期功能安全性（SOTIF），做危急情況分析，比如天氣狀況、機械擾動、電磁相容幹擾、聲幹擾和糟糕的反映。SOTIF指由于預期功能的不足或人員合理預見的誤用而導緻的危害；其定義并改進功能定義，将以下風險降低到可接受的水準：
通過分析，那些預先功能的剩餘風險
通過驗證，那些已知情況下的意外行為
通過驗證情況的确認，那些可能導緻意外行為的剩餘未知情況
SOTIF的自動駕駛系統功能局限包括：
目标場景考慮不周到，系統無法對環境做出正确相應 （Perception）
功能邏輯仲裁機制、算法不合理，導緻決策出現問題 （Decision）
執行機構的輸出與理想輸出發生偏差，難以完美控制 （Execution）
SOTIF把駕駛的場景(Scenario)分成四個區間：
已知安全 Known Safe
已知不安全 Known Unsafe
未知安全 Unknown Safe
未知不安全 Unknown Unsafe （黑天鵝）
SOTIF主要覆寫電子電器系統非故障引起的危害, 例如：1）車輛運作過程中超出了ODD範圍，需要駕駛員接管（但是系統本身并無故障，并不算是“失效”），而且這個接管過程需要一定時間；在這個接管的過渡時間中，要保證系統能夠“堅持住”，這就對系統提出了新的安全要求；2）視覺感覺系統将一個救護車誤認為是一輛普通的卡車，而導緻車輛沒有給救護車讓道，電子電器系統沒有任何失效，但是确實形成了某種危害。
SOTIF一般驗證都是圍繞ODD/OEDR/應變等引申出來的含義展開的, 比如系統性的把智能駕駛系統暴露出ODD，看看系統接管的性能是否OK；系統性的訓練和測試系統的OEDR能力（感覺極端工況），看看系統的響應是否正确。
還有一個安全任務是汽車的網絡安全，網絡安全漏洞可能會損害系統實作基本安全目标的能力。
BMW公司在其L3級自動駕駛概念車Vision iNEXT設計中就考慮各種安全故障的處理（見附錄）。
結束語
自動駕駛進入一個工程化落地的時期，這裡提到了一些必要的工程化要素，如線控底盤、電子電氣架構、中間件軟體平台、模型壓縮加速、車載自動駕駛晶片（計算平台）、資料閉環、DevOps/MLOps、場景庫建設及其測試和系統安全設計等。
另外，這裡還有沒提到的工程問題，比如傳感器清洗、計算平台的記憶體/指令優化和任務排程等。
附錄A：自動駕駛工程化舉例
· Pony（小馬智行）
2021 年 2 月，小馬宣布最新一代的自動駕駛車輛從一套标準化産線正式下線，開啟全天候自動駕駛的公開道路測試，并加入到各地的 Robotaxi 車隊中做規模化的營運。
這批車輛從設計、開發到産線生産、标定和驗證，經曆非常嚴格的标準化流程。整個流程裡面大概涉及 40 多道工序（如攝像頭和雷射雷達清洗、震動和防水等）200多項質檢項目，盡可能保證整個系統的一緻性。
比起以前的系統，在硬體穩定性方面大概有 30 倍到 50 倍提升的效果，整個自動駕駛系統的生産效率和前一年相比大概能夠提升 6 倍。
2022年1月20日，小馬智行公開新自動駕駛解決方案，包括軟硬體系統外型設計、傳感器以及計算平台。據說，該系統面向L4車規級量産設計，可加速 L4自動駕駛技術的規模化部署。第一批搭載該系統的車型為豐田S-AM（7座賽那混電），計劃2023年上半年投入Robotaxi日常營運。
· AutoX（安途）
2021年12月22日，AutoX（安途）對外揭曉AutoX RoboTaxi超級工廠的内部視訊。該超級工廠由Auto X獨立設計、投建。而RoboTaxi則是AutoX與克萊斯勒FCA內建合作打造，具備車規級備援線控，支援量産。
AutoX無人車零部件進入倉庫後，先進行品質檢測，通過檢測的零件走上部裝線，進行局部內建。
總裝線由半自動化滑闆傳輸線和吊裝輸送線組成，采用ABB 7軸機器人。電控系統與傳動系統則是由西門子、歐姆龍、施耐德、飛利浦、三菱、SEW等提供。從車内操作界面可以對系統的全部軟硬體子產品進行質檢。
下線時，工廠中的房間内自動化多傳感器在轉盤、四輪定位等方面進行标定，并在廠内完成恒溫房、噴淋房等車規級檢測，在出廠時即可進入無人駕駛狀态。
附錄B：英偉達自動駕駛晶片
· 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），圖像處理器，視覺處理器和視訊處理器。
· Orin
和Xavier相比，Orin的算力提升到接近7倍，從30TOPS提升到了200TOPS。CPU部分從ARM Cortex A57到A78。Xavier的功耗大概30W，Orin功耗僅為45W左右。
Orin多晶片方案版本用兩個Orin + 兩個7nm A100 GPU，算力達到2000TOPS。Orin 系統級晶片內建NVIDIA 新GPU 架構Ampere、Arm Hercules CPU 核心、新深度學習加速器（DLA）和計算機視覺加速器（PVA），每秒運作200萬億次計算。
DRIVE AGX系列推出一款新型Orin SoC。其功率僅為5瓦，但性能卻可達到10 TOPS。
· 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。
附錄D：德國場景庫項目PEGASUS
德國PEGASUS項目（2016~2019年5月）聚焦于高速公路場景的研究和分析，基于事故以及自然駕駛資料建立場景資料庫，以場景資料庫為基礎對系統進行驗證。
該研究定義了場景（scenario）“功能—邏輯—具體”（functional-logical-concrete）三級分層體系，以及面向概念—開發—測試—标定 (concept-development-testing-calibration) 的場景庫建構流程及智能駕駛測試方法。
PEGASUS通過開發OpenScenario接口試圖建立可用于模拟仿真、試驗場和真實環境中測試和試驗進階智能駕駛系統的标準化流程。
該項目分四個階段：1）場景分析&品質評估，定義一種系統的場景生成方法以及場景檔案的的文法結構，計算場景的KPI，定義一套基于專家經驗的場景困難（危險）程度評價方法；2）實施流程，以安全為基礎，設計一套足夠靈活的、魯棒性強的适用于自動駕駛功能的設計實施流程；3）測試，輸出為一套用于實驗室（仿真軟體，台架等）以及真實交通場景的方法和工具鍊；4）結果驗證&內建，對前三個階段的結果進行分析。
PEGASUS建立三種測試場景格式标準，即OpenCRG、OpenDRIVE和OpenSCENARIO，定義了測試場景的六層模型：道路層、交通基礎設施、前兩層的臨時操作（如道路施工現場）、對象、 環境和數字資訊。
附錄E：BMW概念車Vision iNEXT的安全備援設計
寶馬2018年釋出了L3自動駕駛概念車Vision iNEXT，駕駛員可以選擇自己駕駛（在“加速Boost”模式下）或被駕駛（在“緩解”模式下）。“增壓”模式使用電力驅動系統，提供高動态、幾乎靜音的零排放駕駛體驗。在“輕松Ease”模式下，車輛為駕駛員和乘客提供了一個從事一些活動的空間。
一旦系統出現故障，L3級BMW自動駕駛車将以視覺、聽覺和觸覺警報的形式向人類駕駛員發送一系列警告，緊急程度将越來越高。該警告級聯包括L3級BMW自動駕駛接管請求，并使用人機界面（HMI）。如果應變準備就緒使用者（即人類駕駛員）不接受接管請求的警告級聯，L3級寶馬自動駕駛車将執行風險緩解操作。這僅僅意味着，如果無法到達路肩，例如在交通繁忙時，車輛将采取行動，甚至包括在硬路肩或車道上安全停車。如圖所示是風險緩解過程示意圖：
寶馬INEXT概念車遵循相同的BMW流程，這些流程包括ISO 26262和ISO/PAS 21448 SOTIF以及其他穩健的内部流程。L3級BMW自動駕駛車中故障安全操作的一個例子是風險緩解（risk mitigation）政策。
随着對L3級BMW自動駕駛車的改進，穩健的更新過程變得至關重要。iNEXT生産車輛将部署OTA（over-the-air）功能。這些軟體更新遵循行業最佳實踐的開發、驗證和部署政策，以便及時傳遞。
在SOTIF功能架構中，BMW區分技術（Technical）SOTIF和人為因素（Human Factors ）SOTIF，因為措施驗證可以通過技術設計決策（設計-安全）或通過驗證系統的人類行為來顯示安全運作（與評估風險相關的設計決策）。在功能安全方面，根據ISO 26262定義了駕駛功能的安全目标，并導出功能和技術安全概念。
在故障條件下，BMW設計可通過“故障運作（fail operational）”政策（備援）、“故障降級（fail degraded”）”政策（降級運作）或“故障安全（fail safe）”政策（使車輛安全停車）實作安全功能。選擇哪種方法始終取決于故障條件下設計元素的性質和系統的剩餘能力。
考慮的設計安全因素包括：
-設計架構
-傳感器
-執行器
-通信故障
-潛在的軟體錯誤
-可靠性
-潛在不勝任的控制
-不良控制行為
-與環境目标和其他道路使用者的潛在碰撞—可能由自動駕駛車操作引起的潛在碰撞
-離開道路
-失去牽引力或穩定性
-違反交通法規
-與正常/預期駕駛實踐的偏差
BMW認為有必要采用多樣性備援（多樣性）：主通道和輔助通道本身備援，并且都有自己的診斷單元。這允許檢測有故障的通道，并讓另一個通道接管。如果故障影響兩個通道，第三個基本通道将接管，以達到最低風險條件。
如圖就是BMW在L3級自動駕駛的備援安全設計：
實施備援的目标，就是允許駕駛員作為應變準備就緒（fallback-ready）使用者接管駕駛任務。如果應變準備就緒的使用者沒有接管駕駛任務，則會觸發風險緩解（risk mitigation）操作。
風險緩解政策確定安全運作，直到達到故障安全狀态（即駕駛員接管駕駛任務或車輛完全停止）。若無法確定L3級BMW 自動駕駛的安全連續運作，将執行該程式，例如：
-如果駕駛員忽略了标準接管請求（TOR）；
-由于環境條件中的危險導緻減少的傳感器或執行器
-性能（傳感器堵塞、低摩擦等）—由于車輛部件（機械、E/E）的故障。
故障操作（fail-operational ）政策如圖所示：