日本无码免费高清在线|成人日本在线观看高清|A级片免费视频操逼欧美|全裸美女搞黄色大片网站|免费成人a片视频|久久无码福利成人激情久久|国产视频一二国产在线v|av女主播在线观看|五月激情影音先锋|亚洲一区天堂av

  • 手機站
  • 小程序

    汽車測試網(wǎng)

  • 公眾號

    • 汽車測試網(wǎng)

    • 在線課堂

    • 電車測試

首頁 > 汽車技術 > 正文

閑話自動駕駛的工程化落地（擴展圖像版）

2022-02-27 11:10:14·  來源：計算機視覺深度學習和自動駕駛  作者：黃浴  
　
引言大家有一種認知，覺得自動駕駛進入了“下半場”。類似demo或者POC的早期工作已經不是人們關心的，這里所謂“上半場”大多是解決常見的問題，比如感知、定位
引言
大家有一種認知，覺得自動駕駛進入了“下半場”。類似demo或者POC的早期工作已經不是人們關心的，這里所謂“上半場”大多是解決常見的問題，比如感知、定位、預測、規(guī)劃決策和控制在典型場景（即高速、街道和停車場等）的解決算法和執(zhí)行方案（線控底盤技術）。
另外，在“上半場”期間，計算平臺（AI芯片及其SOC）和傳感器技術的研發(fā)進程也初現(xiàn)成果，比如英偉達的Xavier和Orin、HDR攝像頭、固態(tài)激光雷達和4D毫米波雷達等。
而“下半場”意味著要解決罕見的“長尾”場景，同時構建數(shù)據(jù)閉環(huán)的持續(xù)高效研發(fā)框架，也已經成為行業(yè)的共識。在這個過程中，如何實現(xiàn)自動駕駛的技術工程化落地才是關鍵（見附錄的例子），包括開發(fā)標準化和平臺化、量產規(guī)?；吐涞厣虡I(yè)化（成本、車規(guī)和OTA）的工作。
自動駕駛工程化的一些要素
· 線控底盤
底盤系統(tǒng)約占整車成本的10%，而線控底盤是自動駕駛的關鍵部件，因為如果不能它的支持，自動駕駛最終輸出的控制信號不一定能夠真正得到正確執(zhí)行。
線控（Drive-by-wire 或 X-by-wire），即用電線（電信號）的形式來取代機械、液壓或氣動等形式的連接，從而不需要依賴駕駛員的力或扭矩輸入。


線控底盤主要包括制動系統(tǒng)、轉向系統(tǒng)、驅動系統(tǒng)和懸架系統(tǒng)。其具備響應速度快、控制精度高、能量回收強的特點，是實現(xiàn)自動駕駛不可缺少的零部件。
線控底盤技術的安全性對于自動駕駛來說，是最基礎最核心的要素。曾經的純機械式控制雖然效率低，但可靠性高；線控技術雖然適用于自動駕駛，但同時也面臨電子軟件的故障所帶來的隱患。只有實現(xiàn)功能雙重甚至多重冗余，才能保證在故障情況下仍可實現(xiàn)其基本功能。
全球L4自動駕駛創(chuàng)業(yè)公司最主流的測試開發(fā)車是林肯MKZ，就是因為其高性能高精度的線控能力表現(xiàn)，易于使用逆向工程實現(xiàn)改裝，還有成熟的線控改造服務提供商AS和Dataspeed，共同為自動駕駛初創(chuàng)企業(yè)研發(fā)提供了穩(wěn)定易用的平臺。
電動車底盤有三電系統(tǒng)（電池、電機、電控），有能量回收和熱管理系統(tǒng)、線控轉向和制動系統(tǒng)和懸掛系統(tǒng)等。滑板底盤是把安裝在底盤的轉向、制動、三電和懸架等模塊化布置，根據(jù)車型要求相應的變更需求模塊，從而縮短開發(fā)周期。由于其外形類似于滑板，故名“滑板底盤”?；宓妆P擁有極高的靈活性，可以滿足自動駕駛系統(tǒng)的需要。


滑板底盤最核心的優(yōu)勢是軟件定義及軟硬件解耦。它可以簡化機械結構，減少零部件以及硬件帶來的邊界和限制，可通過輪轂電機的分布式驅動算法升級實現(xiàn)更安全的底盤功能。底盤能夠真正做到完全由軟件定義，具體體現(xiàn)在分布式驅動的算法上。因為分布式驅動的算法能夠實現(xiàn)底盤的完全解放，讓它從傳統(tǒng)的汽車底盤變成真正的輪式機器人。其背后需要一套算法驅動的設計和柔性制造系統(tǒng)，并實現(xiàn)多品類小批量的分布式制造，才能完全釋放滑板底盤的模塊化、靈活性等優(yōu)勢。
Arrival、Rivian、Canoo和REE等歐美創(chuàng)業(yè)公司，還有中國創(chuàng)業(yè)公司Upower（悠跑科技）和PIX Moving，都宣布采用滑板地盤。而豐田、現(xiàn)代和雪鐵龍等車企，還有舍弗勒和采埃孚等Tier -1，都紛紛開始研發(fā)滑板底盤。
· E2A（電子電氣架構）
伴隨著汽車行業(yè)“網(wǎng)聯(lián)化、智能化、共享化和電動化（CASE）”趨勢推動下的智能化發(fā)展，促使汽車分布式架構向著集中式架構轉變。E2A是整合汽車各類傳感器、處理器、電子電氣分配系統(tǒng)和軟硬件的總布置方案（包括數(shù)據(jù)中心平臺和高性能計算平臺）。
通過E2A，可以將動力總成、驅動信息以及娛樂信息等，轉化為實際電源分配的物理布局、信號網(wǎng)絡、數(shù)據(jù)網(wǎng)絡、診斷、容錯、功耗管理等電子電氣解決方案。
汽車E2A基本劃分為三個時代：分布式多MCU組網(wǎng)架構、功能集群式域控制器（Domain Controller）和區(qū)域連接域控制器（Zone Controller）及中央平臺計算機（CPC）。
自動駕駛汽車需要使用大量傳感器，車內線束也在迅速增長。車內需要傳輸?shù)臄?shù)據(jù)量激增，同時線束不僅承載的信號更多，而且數(shù)據(jù)傳輸速率要求更快。
自動駕駛在新一代E2A平臺下，通過標準化API接口實現(xiàn)了軟硬件的真正解耦，可以更加獲得更強算力的支持，同時數(shù)據(jù)通信的帶寬也得到增強，資源分配和任務調度更加靈活，另外也方便OTA（over-the-air）。
針對智能汽車E2A，Aptiv提出“大腦”與“神經”結合的方案，包括三個部分：中央計算集群、標準電源和數(shù)據(jù)主干網(wǎng)絡以及電源數(shù)據(jù)中心。這個智能汽車架構關注三大特性：靈活性、生命周期內持續(xù)更新性、以及系統(tǒng)架構相對容錯性和魯棒性。


特斯拉Model 3的E2A分為域控制架構和電源電源分配架構。駕駛輔助與娛樂系統(tǒng)AICM控制合并到CCM中央計算模塊當中，而電源分配架構則考慮自動駕駛系統(tǒng)所需要的電源冗余要求。


· Middleware（中間件）軟件平臺
中間件是基礎軟件的一大類，在操作系統(tǒng)、網(wǎng)絡和數(shù)據(jù)庫之上，應用軟件的下層，其作用是為應用軟件提供運行與開發(fā)的環(huán)境，便于靈活、高效地開發(fā)和集成復雜的應用軟件。在不同的技術之間共享資源并管理計算資源和網(wǎng)絡通信。
另外中間件的定位不是操作系統(tǒng)，而是一套軟件框架，雖然包括了RTOS、微控制抽象層（MCAL）、服務通信層等協(xié)議和服務。
中間件的核心是“統(tǒng)一標準、分散實現(xiàn)、集中配置”。其具備如下功能：解決汽車功能的可用性和安全性需求；保持汽車電子系統(tǒng)一定的冗余；移植不同平臺；實現(xiàn)標準的基本系統(tǒng)功能；通過網(wǎng)絡共享軟件功能；集成多個開發(fā)商提供的軟件模塊；在產品生命期內更好地進行軟件維護；更充分利用硬件平臺處理能力；實現(xiàn)汽車電子軟件的更新和升級等。
面向服務的軟件架構SOA（Service-Oriented Architecture）具有松耦合的系統(tǒng)，即有著中立的接口定義，這意味 著應用程序的組件和功能沒有被強制綁定，應用程序的不同組件和功能于結構的聯(lián)系并不緊密。應用程序服務的內部結構和實現(xiàn)逐漸改變時， 軟件架構并不會受到過大的影響。


“接口標準可訪問”和“拓展性優(yōu)秀”的 SOA 使得服務組件的部署不再依賴于特定的操作系統(tǒng)和編程語言，一定程度上實現(xiàn)軟硬件的分離。SOA軟件架構開發(fā)從用戶的角度進行功能考慮，以業(yè)務為中心，將業(yè)務邏輯進行抽象和封裝。
新一代中間件平臺支持的自動駕駛軟件，通過SOA進行適當顆粒度的功能抽象、軟件代碼插件化（獨立的開發(fā)、測試、部署及發(fā)布） 、軟件功能服務化以及功能之間松耦合。
AUTOSAR（見附錄）是一個各大整車廠商和零部件廠商聯(lián)合制定軟件的標準化接口。
· AI模型壓縮和加速
AI模型壓縮和加速是兩個不同的話題，壓縮重點在于減少網(wǎng)絡參數(shù)量，加速目的在降低計算復雜度、提升并行能力等。
目前壓縮和加速AI模型的技術大致分為四種方案如下：
  • 1) 參數(shù)修剪和共享：探索模型參數(shù)中的冗余，并嘗試去除冗余和不重要的參數(shù)；
  • 2) 低秩分解：使用矩陣/張量分解來估計深度CNN模型的信息參數(shù)；
  • 3) 遷移/緊致卷積濾波器：設計特殊的結構卷積濾波器，以減少參數(shù)空間并節(jié)省存儲/計算；
  • 4) 知識蒸餾：學習蒸餾模型并訓練更緊湊的神經網(wǎng)絡以再現(xiàn)更大網(wǎng)絡的輸出。
通常，參數(shù)修剪和共享、低秩分解和知識蒸餾方法可以用于具有全聯(lián)接層和卷積層的深度神經網(wǎng)絡模型；另一方面，使用遷移/緊致濾波器的方法僅適用于具有卷積層的模型。低秩分解和基于遷移/緊致濾波器的方法提供了端到端流水線，可在CPU / GPU環(huán)境中輕松實現(xiàn)。參數(shù)修剪和共享會使用不同的方法，如矢量量化，二進制編碼和稀疏約束等?？傊?，實現(xiàn)壓縮和加速需要多個步驟來進行。
至于訓練方式，可以從預訓練方式中提取基于參數(shù)修剪/共享低秩分解的模型，或者從頭開始訓練（train from scratch）。遷移/緊致卷積濾波器和知識蒸餾模型只能從頭開始訓練。這些方法是獨立設計的，相互補充。例如，可以一起使用遷移網(wǎng)絡層以及參數(shù)修剪和共享，也可以將模型量化和二值化與低秩分解近似一起使用。
知識蒸餾將深度寬度網(wǎng)絡壓縮成較淺網(wǎng)絡，其中壓縮模型模擬了復雜模型所學習的函數(shù)?；谡麴s方法的主要思想是通過學習得到softmax輸出的類分布，將知識從大教師模型轉變?yōu)樾W生模型。一種蒸餾框架通過遵循“學生-教師”范式來簡化深度網(wǎng)絡的訓練，其中學生根據(jù)教師輸出的軟版本受到懲罰；該框架將教師網(wǎng)絡（teacher network）集成到一個有類似深度的學生網(wǎng)絡（student network）中，訓練學生預測輸出和分類標簽。
模型參數(shù)可以采用32位/比特浮點（FP32）格式表示，但不如以定點（fixed point）格式表示，因為這幾乎沒有精度損失，甚至更高，但計算量卻較低。這種策略不僅可以減少占用的內存，還可以減少與計算相關的功耗。但是，DNN模型的每一層對準確性都有不同的影響，因此可以使用細粒度的混合精度量化方法，其中每層權重和激活值的位寬不同。
· 車載自動駕駛芯片
自動駕駛芯片以及SOC（system on chip），目的是實現(xiàn)高效、低成本、低功耗的自動駕駛計算平臺。而工控機實現(xiàn)的自動駕駛平臺，是很難實現(xiàn)量產規(guī)模化和控制成本的。
一個SOC可能會包括自動駕駛芯片（深度學習模型實現(xiàn)）、CPU/GPU、DSP芯片、ISP芯片和CV（計算機視覺）芯片等。在芯片基礎上，還有一個支持深度學習模型實現(xiàn)的編譯器需要開發(fā)來最大效率地提高芯片的利用率，避免處理器等待或者數(shù)據(jù)瓶頸堵塞。
其中算法的適配性（模塊和進程分解）、自動駕駛軟件的高效運行（包括進程數(shù)據(jù)通信、深度學習模型加速、任務調度和資源管理等）及其安全（功能安全/預期功能安全）保障，都是需要很多工程性的艱苦努力和必要付出的代價（比如系統(tǒng)冗余）。
目前英偉達的Xavier和Orin（見附錄）是市場上最成功最開放的自動駕駛芯片。
· 數(shù)據(jù)閉環(huán)平臺
AI的最挑戰(zhàn)應用之一，自動駕駛，是一個長尾效應的典型。大量少見的極端情況（corner case）往往是缺乏搜集的訓練數(shù)據(jù)，這樣要求我們在一個閉環(huán)中不斷地發(fā)現(xiàn)這些有價值的數(shù)據(jù)，標注后放入訓練集中，同時也放入我們的測試集或者仿真場景庫；在NN模型得到迭代升級后，會再交付到自動駕駛車進入新的循環(huán)，即數(shù)據(jù)閉環(huán)。
如圖就是特斯拉的數(shù)據(jù)閉環(huán)框架：確認模型誤差、數(shù)據(jù)標注和清洗、模型訓練和重新部署/交付。


如圖是谷歌waymo的數(shù)據(jù)閉環(huán)平臺：數(shù)據(jù)挖掘、主動學習、自動標注、自動化模型調試優(yōu)化、測試校驗和部署發(fā)布。


數(shù)據(jù)閉環(huán)需要一個云計算/邊緣計算平臺和大數(shù)據(jù)的處理技術，這個不可能在單車或單機實現(xiàn)的。大數(shù)據(jù)云計算發(fā)展多年，在數(shù)據(jù)批處理/流處理、工作流管理、分布式計算、狀態(tài)監(jiān)控和數(shù)據(jù)庫存儲等方面提供了數(shù)據(jù)閉環(huán)的基礎設施支持。
模型訓練平臺，主要是機器學習（深度學習）而言，開源的最早有Caffe，目前最流行的是Tensorflow和Pytorch（Caffe2并入）。在云平臺部署深度學習模型訓練，一般采用分布式。按照并行方式，分布式訓練一般分為數(shù)據(jù)并行和模型并行兩種。當然，也可采用數(shù)據(jù)并行和模型并行的混合。
  • 模型并行：不同GPU負責網(wǎng)絡模型的不同部分。例如，不同網(wǎng)絡層被分配到不同的GPU，或者同一層不同參數(shù)被分配到不同GPU。
  • 數(shù)據(jù)并行：不同GPU有模型的多個副本，每個GPU分配不同的數(shù)據(jù)，將所有GPU計算結果按照某種方式合并。
模型并行不常用，而數(shù)據(jù)并行涉及各個GPU之間如何同步模型參數(shù)，分為同步更新和異步更新。同步更新等所有GPU的梯度計算完成，再計算新權值，同步新值后，再進行下一輪計算。異步更新是每個GPU梯度計算完無需等待，立即更新權值，然后同步新值進行下一輪計算。
分布式訓練系統(tǒng)包括兩種架構：Parameter Server Architecture（PS，參數(shù)服務器）和Ring -AllReduce Architecture（環(huán)-全歸約）。
主動學習（active learning）的目標是找到有效的方法從無標記數(shù)據(jù)池中選擇要標記的數(shù)據(jù)，最大限度地提高準確性。主動學習通常是一個迭代過程，在每次迭代中學習模型，使用一些啟發(fā)式方法從未標記數(shù)據(jù)池中選擇一組數(shù)據(jù)進行標記。因此，有必要在每次迭代中為了大子集查詢所需標簽，這樣即使對大小適中的子集，也會產生相關樣本。
機器學習模型往往會在out-of-distribution（OOD) 數(shù)據(jù)上失敗。檢測OOD是確定不確定性（Uncertainty）的手段，既可以安全報警，也可以發(fā)現(xiàn)有價值的數(shù)據(jù)樣本。
不確定性有兩種來源：任意（aleatoric）不確定性和認知（epistemic）不確定性。導致預測不確定性的數(shù)據(jù)不可減（Irreducible）不確定性，是一種任意不確定性（也稱為數(shù)據(jù)不確定性）。另一類不確定性是由于知識和數(shù)據(jù)不適當造成的認知不確定性（也稱為知識/模型不確定性）。
最常用的不確定性估計方法是貝葉斯近似（Bayesian approximation）法和集成學習（ensemble learning）法。
一類 OOD 識別方法基于貝葉斯神經網(wǎng)絡推理，包括基于 dropout 變分推理（variational inference）法、馬爾可夫鏈蒙特卡羅 (MCMC) 和蒙特卡羅 dropout法等。另一類OOD識別方法包括 (1) 輔助損失或NN 架構修改等訓練方法，以及 (2) 事后統(tǒng)計（post hoc statistics）方法。
數(shù)據(jù)樣本中有偏離正常的意外情況，即所謂的極端情況（corner case）。在線檢測可以用作安全監(jiān)控和警告系統(tǒng)，在corner case情況發(fā)生時進行識別。線下檢測可應用于大量收集的數(shù)據(jù)，選擇合適的訓練和相關測試數(shù)據(jù)。
· DevOps
DevOps，簡單地來說，就是更好的優(yōu)化開發(fā)(DEV)、測試(QA)、運維(OPS)的流程，開發(fā)運維一體化，通過高度自動化工具與流程，使得軟件構建、測試、發(fā)布更加快捷、頻繁和可靠。


DevOps 是一個完整面向IT運維的工作流， IT 自動化以及持續(xù)集成（CI）/持續(xù)部署（CD）作為基礎，來優(yōu)化程式開發(fā)、測試、系統(tǒng)運維等所有環(huán)節(jié)。
主干（trunk- based）開發(fā)是CI前提（不是特征分支開發(fā)），自動化以及代碼集中管理是實施CI的必要條件。DevOps 是CI思想的延伸，CD/CI是 DevOps 的技術核心。
· MLOps
MLOps的核心目標是使得AI模型從訓練到布署的整條端到端鏈路能夠穩(wěn)定，高效地運行在生產環(huán)境中，滿足客戶的終端業(yè)務需求。


為了達到這個目標，其對AI系統(tǒng)核心技術也提出了相應的需求。比如布署自動化，對AI框架的前端設計會提出明確的需求，如果AI框架的前端設計不利于導出完整的模型文件，會使得大量的下游不得不在布署環(huán)節(jié)引入針對各自業(yè)務場景需求的”補丁”。
布署自動化的需求，也會催生一些圍繞AI核心系統(tǒng)的軟件組件，比如模型推理布署優(yōu)化、模型訓練預測結果的可復現(xiàn)性和AI生產的系統(tǒng)可伸縮性。
· 場景庫建設和測試
基于場景的自動駕駛汽車測試方法是實現(xiàn)加速測試、加速評價的有效途徑。
“場景作為行駛環(huán)境與汽車駕駛情景的一種綜合體現(xiàn)，描述了車輛外部行駛環(huán)境的道路場地、周邊交通、氣象(天氣和光照)和車輛自身的駕駛任務和狀態(tài)等信息，是影響和判定智能駕駛功能與性能因素集合的一種抽象與映射，具有高度的不確定、不可重復、不可預測和不可窮盡等特征”。
測試場景的分類方法有所不同：
  • 1）按照場景的抽象程度，可分為功能場景、邏輯場景、具體場景；
  • 2）按照測試場景數(shù)據(jù)來源，可分為自然駕駛場景、危險工況場景、標準法規(guī)場景和參數(shù)重組場景。
一個場景庫的維度包括：
  • 場景：靜態(tài)部分和動態(tài)部分
  • 交通：駕駛行為和VRU（行人、自行車）等非機動行為
  • 天氣：傳感器（攝像頭、雷達、激光雷達）和干擾
場景庫建設，基本上基于真實、虛擬以及專家數(shù)據(jù)等不同的數(shù)據(jù)源，通過場景挖掘、場景分類、場景演繹等方式分層構建成一個完整的體系。
德國PEGASUS（見附錄）是一個建立場景數(shù)據(jù)庫的傳統(tǒng)方法項目。
· 安全冗余設計
不少自動駕駛公司都公布過自己的安全報告，其中涉及到自動駕駛安全的諸多設計考慮，主要有：
  • 系統(tǒng)安全
  • 操作域設計（ODD）
  • 應變（最小風險條件）
  • 目標和事件監(jiān)測和反應（OEDR）
  • 信息安全
  • 驗證和確認（V&V）
  • 政府法規(guī)
自動駕駛車輛應工作在操作域設計（ODD）的場景，在出現(xiàn)任何故障和故障時，可預測、可控和安全地運行。與安全相關的故障是指一種對人員造成合理概率傷害的故障。其他類型的故障可能會導致與安全無關的結果，例如駕駛員的不幸體驗。
所謂最小風險條件是一種系統(tǒng)狀態(tài)“當給定行程無法或不應完成時，降低撞車風險……這可能需要自動將車輛停在其當前行駛道路內，或需要進行更廣泛的機動，以便車輛從活動車道上移開和/或自動將車輛返回調度中心。對于L3級自動駕駛系統(tǒng)，當接近ODD出口或出現(xiàn)自動駕駛故障時，一個善于接受的“應變準備就緒用戶（fallback-ready user）”應準備好接管駕駛任務。
ISO 26262，“用于功能安全的道路車輛”，國際標準化組織于2011年制定的汽車生產中電氣和/或電子系統(tǒng)功能安全標準。功能安全過程需要進行危險分析和安全風險評估（hazard analysis and safety risk assessment），該評估指定了一個稱為汽車安全完整性等級（Automotive Safety Integrity Level，ASIL）的屬性。對于高度安全相關的功能，內置了特定的冗余，以便這些系統(tǒng)的故障不會造成不合理的安全風險。
這種情況可分為三類：“故障運行（fail- operational）”，其中一個傳感器可能會故障，但冗余傳感器可以繼續(xù)系統(tǒng)的安全運行；“故障降級（fail-degraded）”，當發(fā)生故障時，系統(tǒng)仍在運行，但可能不具備全部功能；以及“故障安全（fail-safe）”，即系統(tǒng)不再運行，但故障不會造成不安全狀況。
ISO 26262的目標是：
  • 提供汽車安全生命周期，并支持定制必要的活動
  • 涵蓋整個開發(fā)過程的功能安全方面
  • 提供一種基于汽車特定風險的方法來確定風險等級（ASIL）
  • 使用ASIL來指定各個條目的必要安全要求
  • 提供驗證和確認（V&V）措施的要求
ISO 26262標準包括十部分，分別為：
  • 詞匯，功能安全管理，概念階段（1-3）；
  • 系統(tǒng)級、硬件級和軟件級的產品開發(fā)（4-6）；
  • 生產經營及配套流程（7-8）；
  • 汽車安全完整性等級（ASIL）導向分析和安全導向分析（9）；
  • 準則（10）。
汽車安全完整性等級（ASIL）是ISO 26262-道路車輛功能安全標準定義的風險分類方案。按標準有4個ASIL級別，即A-B-C-D，從最低到最高。ASIL的確定是危害分析和風險評估（hazard analysis andrisk assessment）的結果。
ASIL D代表在發(fā)生故障時可能發(fā)生嚴重危及生命或致命傷害，并要求最高級別的保證，以確保相關安全目標充分且已實現(xiàn)。提到“質量管理（QM）”，QM級別意味著與危險事件相關的風險并非不合理，因此不需要按照ISO 26262采取安全措施。
IEC 61508定義了廣泛引用的安全完整性等級（SIL）分類。ASIL是風險的定性度量，SIL是根據(jù)安全功能的類型定量定義為危險故障的概率或頻率。ASIL D與SIL 3對齊，ASIL A與SIL 1相當。
美國國家高速交通安全局（NHTSA，National Highway Traffic Safety Administration）負責制定、設置和執(zhí)行美國聯(lián)邦機動車安全標準（FMVSS）以及機動車和設備法規(guī)。其使命描述為“拯救生命、防止受傷、減少與車輛相關的碰撞”，確保自動駕駛車輛的道路測試將對其他道路使用者的風險降至最低；另外，將測試操作限制在適合測試自動駕駛車輛能力的道路、交通和環(huán)境條件下；并制定報告要求，以在測試期間監(jiān)控自動駕駛技術的性能，確保從自動駕駛模式過渡到駕駛員控制的過程安全、簡單和及時；自動駕駛測試車輛應具有檢測、記錄并通知駕駛員自動技術系統(tǒng)出現(xiàn)故障的能力，確保任何自動駕駛車輛技術的安裝和操作不會禁用任何聯(lián)邦要求的安全功能或系統(tǒng)。
ISO/PAS 21448規(guī)定了車輛預期功能安全性（SOTIF），做危急情況分析，比如天氣狀況、機械擾動、電磁兼容干擾、聲干擾和糟糕的反映。SOTIF指由于預期功能的不足或人員合理預見的誤用而導致的危害；其定義并改進功能定義，將以下風險降低到可接受的水平：
  • 通過分析，那些預先功能的剩余風險
  • 通過驗證，那些已知情況下的意外行為
  • 通過驗證情況的確認，那些可能導致意外行為的剩余未知情況
SOTIF的自動駕駛系統(tǒng)功能局限包括：
  • 目標場景考慮不周到，系統(tǒng)無法對環(huán)境做出正確相應 （Perception）
  • 功能邏輯仲裁機制、算法不合理，導致決策出現(xiàn)問題 （Decision）
  • 執(zhí)行機構的輸出與理想輸出發(fā)生偏差，難以完美控制 （Execution）
SOTIF把駕駛的場景(Scenario)分成四個區(qū)間：
  • 已知安全 Known Safe
  • 已知不安全 Known Unsafe
  • 未知安全 Unknown Safe
  • 未知不安全 Unknown Unsafe （黑天鵝）
SOTIF主要覆蓋電子電器系統(tǒng)非故障引起的危害, 例如：1）車輛運行過程中超出了ODD范圍，需要駕駛員接管（但是系統(tǒng)本身并無故障，并不算是“失效”），而且這個接管過程需要一定時間；在這個接管的過渡時間中，要保證系統(tǒng)能夠“堅持住”，這就對系統(tǒng)提出了新的安全要求；2）視覺感知系統(tǒng)將一個救護車誤認為是一輛普通的卡車，而導致車輛沒有給救護車讓道，電子電器系統(tǒng)沒有任何失效，但是確實形成了某種危害。
SOTIF一般驗證都是圍繞ODD/OEDR/應變等引申出來的含義展開的, 比如系統(tǒng)性的把智能駕駛系統(tǒng)暴露出ODD，看看系統(tǒng)接管的性能是否OK；系統(tǒng)性的訓練和測試系統(tǒng)的OEDR能力（感知極端工況），看看系統(tǒng)的響應是否正確。
還有一個安全任務是汽車的網(wǎng)絡安全，網(wǎng)絡安全漏洞可能會損害系統(tǒng)實現(xiàn)基本安全目標的能力。
BMW公司在其L3級自動駕駛概念車Vision iNEXT設計中就考慮各種安全故障的處理（見附錄）。
結束語
自動駕駛進入一個工程化落地的時期，這里提到了一些必要的工程化要素，如線控底盤、電子電氣架構、中間件軟件平臺、模型壓縮加速、車載自動駕駛芯片（計算平臺）、數(shù)據(jù)閉環(huán)、DevOps/MLOps、場景庫建設及其測試和系統(tǒng)安全設計等。
另外，這里還有沒提到的工程問題，比如傳感器清洗、計算平臺的內存/指令優(yōu)化和任務調度等。
附錄A：自動駕駛工程化舉例
· Pony（小馬智行）


2021 年 2 月，小馬宣布最新一代的自動駕駛車輛從一套標準化產線正式下線，開啟全天候自動駕駛的公開道路測試，并加入到各地的 Robotaxi 車隊中做規(guī)?；倪\營。
這批車輛從設計、開發(fā)到產線生產、標定和驗證，經歷非常嚴格的標準化流程。整個流程里面大概涉及 40 多道工序（如攝像頭和激光雷達清洗、震動和防水等）200多項質檢項目，盡可能保證整個系統(tǒng)的一致性。
比起以前的系統(tǒng)，在硬件穩(wěn)定性方面大概有 30 倍到 50 倍提升的效果，整個自動駕駛系統(tǒng)的生產效率和前一年相比大概能夠提升 6 倍。
2022年1月20日，小馬智行公開新自動駕駛解決方案，包括軟硬件系統(tǒng)外型設計、傳感器以及計算平臺。據(jù)說，該系統(tǒng)面向L4車規(guī)級量產設計，可加速 L4自動駕駛技術的規(guī)?；渴?。第一批搭載該系統(tǒng)的車型為豐田S-AM（7座賽那混電），計劃2023年上半年投入Robotaxi日常運營。
· AutoX（安途）
2021年12月22日，AutoX（安途）對外揭曉AutoX RoboTaxi超級工廠的內部視頻。該超級工廠由Auto X獨立設計、投建。而RoboTaxi則是AutoX與克萊斯勒FCA集成合作打造，具備車規(guī)級冗余線控，支持量產。


AutoX無人車零部件進入倉庫后，先進行質量檢測，通過檢測的零件走上部裝線，進行局部集成。
總裝線由半自動化滑板傳輸線和吊裝輸送線組成，采用ABB 7軸機器人。電控系統(tǒng)與傳動系統(tǒng)則是由西門子、歐姆龍、施耐德、飛利浦、三菱、SEW等提供。從車內操作界面可以對系統(tǒng)的全部軟硬件模塊進行質檢。
下線時，車間內自動化多傳感器在轉盤、四輪定位等方面進行標定，并在廠內完成恒溫房、噴淋房等車規(guī)級檢測，在出廠時即可進入無人駕駛狀態(tài)。
附錄B：英偉達自動駕駛芯片
· Xavier
Xavier被NVIDIA稱作為“世界上最強大的SoC（片上系統(tǒng)）”，有高達 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 系統(tǒng)級芯片集成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 系統(tǒng)級芯片，持續(xù)改善和創(chuàng)建各種基于軟件和服務的新業(yè)務模式。
新平臺采用 12 個環(huán)繞攝像頭、12 個超聲波模塊、9 個普通雷達、3 個內部感知攝像頭和 1 個前置激光雷達打造。是有功能安全的架構設計，具備故障備份。
不少汽車制造商、卡車制造商、一級供應商和無人駕駛出租車服務公司采用了此 DRIVE Hyperion 架構。
附錄C：車載中間件 AUTOSAR
AUTOSAR (AUTomotive Open System ARchitecture) 是由各大整車廠商和零部件廠商聯(lián)合制定的，是由BMW、BOSCH、Continental、DAIMLER、Ford、OPEL、PSA、TOYOTA、VW等共同制定的汽車開放式系統(tǒng)架構標準，俗稱AUTOSAR Classic （CP），基本上做為MCU/ECU的標準，包 括發(fā)動機控制機和電機控制器。


CP主要包含微控制器層（Microcontroller）、基礎軟件層（Basic Software）、中間件層（Runtime Environment，RTE）以及應用層（Application）?；A軟件層再分為服務層（Services Layer）、ECU抽象層（ECU Abstraction Layer）、微控制器抽象層（Microcontroller Abstraction Layer）和復雜驅動（Complex Device Drivers）。
具體講，服務層主要提供各類維持系統(tǒng)運行的基礎服務，如監(jiān)控，診斷，通信，以及實時操作系統(tǒng)等；ECU抽象層主要功能是封裝微處理器及其外圍設備；微處理器抽象層主要功能是對微控制器進行分裝，例如I/O、ADC、SPI等；復雜驅動用于那些不能進行統(tǒng)一封裝的復雜硬件，為上層RTE訪問硬件提供支持。
后來出現(xiàn)的AUTOSAR Adaptive platform （AP），更多的應用于 ADAS 和自動駕駛等對于計算能力和帶寬通信要求更高的領域中，盡可能從其他領域 (如消費電子產品) 的發(fā)展中獲益，同時仍然考慮汽車的特定要求，如功能安全。


AP平臺主要提供高性能計算與通訊機制，并且提供靈活的軟件配置，例如軟件遠程更新（OTA）等，包括如下主要部分：（1）用戶應用，一個應用可以為其他應用提供服務，這樣的服務稱為非平臺服務；（2）支持用戶應用的AUTOSAR Runtime（ARA，Autosar Runtime for Adaptive Application），其由功能集群提供的一系列應用接口組成，其中有兩種類型的功能集群，即自適應平臺基礎功能和自適應平臺服務；（3）硬件視作機器（Machine），可以通過各種管理程序相關技術虛擬化，并且可以實現(xiàn)一致的平臺視圖。
AP需要支持E2A的兩個關鍵特征：異構軟件平臺的集成和面向服務的通信。AP組件封裝面向服務SOA軟件底層的通訊細節(jié) (包括SOME/IP協(xié)議，IPC等)，同時提供代理(Proxy)-骨架(Skeleton)模型，方便應用開發(fā)人員調用標準服務接口(API)進行開發(fā)。
AP選擇POSIX PSE 51作為OS要求，避免底層OS過于復雜，上層應用限制使用一些復雜功能，避免overspec。
附錄D：德國場景庫項目PEGASUS
德國PEGASUS項目（2016~2019年5月）聚焦于高速公路場景的研究和分析，基于事故以及自然駕駛數(shù)據(jù)建立場景數(shù)據(jù)庫，以場景數(shù)據(jù)庫為基礎對系統(tǒng)進行驗證。
該研究定義了場景（scenario）“功能—邏輯—具體”（functional-logical-concrete）三級分層體系，以及面向概念—開發(fā)—測試—標定 (concept-development-testing-calibration) 的場景庫構建流程及智能駕駛測試方法。


PEGASUS通過開發(fā)OpenScenario接口試圖建立可用于模擬仿真、試驗場和真實環(huán)境中測試和試驗高級智能駕駛系統(tǒng)的標準化流程。
該項目分四個階段：1）場景分析&質量評估，定義一種系統(tǒng)的場景生成方法以及場景文件的的語法結構，計算場景的KPI，定義一套基于專家經驗的場景困難（危險）程度評價方法；2）實施流程，以安全為基礎，設計一套足夠靈活的、魯棒性強的適用于自動駕駛功能的設計實施流程；3）測試，輸出為一套用于實驗室（仿真軟件，臺架等）以及真實交通場景的方法和工具鏈；4）結果驗證&集成，對前三個階段的結果進行分析。


PEGASUS建立三種測試場景格式標準，即OpenCRG、OpenDRIVE和OpenSCENARIO，定義了測試場景的六層模型：道路層、交通基礎設施、前兩層的臨時操作（如道路施工現(xiàn)場）、對象、 環(huán)境和數(shù)字信息。
附錄E：BMW概念車Vision iNEXT的安全冗余設計
寶馬2018年發(fā)布了L3自動駕駛概念車Vision iNEXT，駕駛員可以選擇自己駕駛（在“加速Boost”模式下）或被駕駛（在“緩解”模式下）?！霸鰤骸蹦Ｊ绞褂秒娏︱寗酉到y(tǒng)，提供高動態(tài)、幾乎靜音的零排放駕駛體驗。在“輕松Ease”模式下，車輛為駕駛員和乘客提供了一個從事一些活動的空間。
一旦系統(tǒng)出現(xiàn)故障，L3級BMW自動駕駛車將以視覺、聽覺和觸覺警報的形式向人類駕駛員發(fā)送一系列警告，緊急程度將越來越高。該警告級聯(lián)包括L3級BMW自動駕駛接管請求，并使用人機界面（HMI）。如果應變準備就緒用戶（即人類駕駛員）不接受接管請求的警告級聯(lián)，L3級寶馬自動駕駛車將執(zhí)行風險緩解操作。這僅僅意味著，如果無法到達路肩，例如在交通繁忙時，車輛將采取行動，甚至包括在硬路肩或車道上安全停車。如圖所示是風險緩解過程示意圖：


寶馬INEXT概念車遵循相同的BMW流程，這些流程包括ISO 26262和ISO/PAS 21448 SOTIF以及其他穩(wěn)健的內部流程。L3級BMW自動駕駛車中故障安全操作的一個例子是風險緩解（risk mitigation）策略。
隨著對L3級BMW自動駕駛車的改進，穩(wěn)健的更新過程變得至關重要。iNEXT生產車輛將部署OTA（over-the-air）功能。這些軟件更新遵循行業(yè)最佳實踐的開發(fā)、驗證和部署策略，以便及時交付。
在SOTIF功能架構中，BMW區(qū)分技術（Technical）SOTIF和人為因素（Human Factors ）SOTIF，因為措施驗證可以通過技術設計決策（設計-安全）或通過驗證系統(tǒng)的人類行為來顯示安全運行（與評估風險相關的設計決策）。在功能安全方面，根據(jù)ISO 26262定義了駕駛功能的安全目標，并導出功能和技術安全概念。
在故障條件下，BMW設計可通過“故障運行（fail operational）”策略（冗余）、“故障降級（fail degraded”）”策略（降級運行）或“故障安全（fail safe）”策略（使車輛安全停車）實現(xiàn)安全功能。選擇哪種方法始終取決于故障條件下設計元素的性質和系統(tǒng)的剩余能力。
考慮的設計安全因素包括：
  • -設計架構
  • -傳感器
  • -執(zhí)行器
  • -通信故障
  • -潛在的軟件錯誤
  • -可靠性
  • -潛在不勝任的控制
  • -不良控制行為
  • -與環(huán)境目標和其他道路使用者的潛在碰撞——可能由自動駕駛車操作引起的潛在碰撞
  • -離開道路
  • -失去牽引力或穩(wěn)定性
  • -違反交通法規(guī)
  • -與正常/預期駕駛實踐的偏差
BMW認為有必要采用多樣性冗余（多樣性）：主通道和輔助通道本身冗余，并且都有自己的診斷單元。這允許檢測有故障的通道，并讓另一個通道接管。如果故障影響兩個通道，第三個基本通道將接管，以達到最低風險條件。
如圖就是BMW在L3級自動駕駛的冗余安全設計：


實施冗余的目標，就是允許駕駛員作為應變準備就緒（fallback-ready）用戶接管駕駛任務。如果應變準備就緒的用戶沒有接管駕駛任務，則會觸發(fā)風險緩解（risk mitigation）操作。
風險緩解策略確保安全運行，直到達到故障安全狀態(tài)（即駕駛員接管駕駛任務或車輛完全停止）。若無法確保L3級BMW 自動駕駛的安全連續(xù)運行，將執(zhí)行該程序，例如：
  • -如果駕駛員忽略了標準接管請求（TOR）；
  • -由于環(huán)境條件中的危險導致減少的傳感器或執(zhí)行器
  • 性能（傳感器堵塞、低摩擦等）—由于車輛部件（機械、E/E）的故障。
故障操作（fail-operational ）策略如圖所示：

 
分享到：
 
反對 0 舉報 0 收藏 0 評論 0
滬ICP備11026917號-25