深入探討自動駕駛開發工具鏈的現況與未來趨勢

汽車產業「智慧化」發展趨勢下，各種L2等級的輔助駕駛功能成為吸引消費者的重要配置，另一方面，在「軟體定義汽車」的新時代，自動駕駛更是成為了影響車企未來發展的重要策略。

如此大背景下，車企需要回答一個問題，是否要自研自動駕駛系統？

我們先來盤點下幾家車企在自動駕駛領域的佈局：

車企的自動駕駛佈局盤點

#可以看出來，車企自研自動駕駛系統成為一大趨勢，很多車企也發現自動駕駛的核心是在「軟硬體解耦」背景下，充分發揮數據的價值，甚至有些車企，因為重視自動駕駛業務，也為了方便業務的後續發展，紛紛成立獨立子公司，專注於智慧駕駛的開發。如一汽集團成立了人工智慧子公司一汽(南京)科技開發有限公司；長城汽車成立了毫末智行；上汽集團籌建了軟體中心上汽零束等。

01 自動駕駛開發流程－從基於模型設計到資料驅動

#不過，要自研自動駕駛系統，也並非易事，因為自動駕駛系統的開發流程和工具鏈特別複雜。

傳統的汽車軟體開發使用V 模型，包含許多ADAS功能，也都是使用這種流程去開發。具體可以參考下圖，左側是設計開發流程，右側是測試驗證流程。

V模型開發流程

#左邊的設計開發流程，現階段以基於模型設計MBD（Model Based Design）的開發流程為主，其中的多數元素（模型）是基於MathWorks公司的產品（MATLAB和Simulink）提供的標準工具箱、區塊組，在圖形化介面上搭建模型，並自動產生程式碼。整體需要工程師自己寫的程式碼量不多，開發速度快，開發成本也較低。

右邊是測試驗證流程，即X在環（X in the loop），在不同階段採用不同的測試方法，包括MIL/SIL/PIL/HIL/DIL/ VIL等測試方法。

傳統的汽車軟體控制邏輯，包括L2的一些相對簡單的ADAS功能，使用MBD X在環的開發流程還可以滿足需求，但是隨著自動駕駛演算法功能越來越複雜，以前基於MBD的開發流程已經顯得有點力不從心了。

首先，更複雜的自動駕駛功能，其軟體的程式碼量和功能的複雜程度也提升了幾個數量級。結構化的工具箱和區塊組建模，在開發簡單的功能演算法時還可以勝任，但在面對複雜的深度學習演算法時，MBD在彈性度方面，就顯得有些捉襟見肘了。

其次，人工智慧產業發展這麼多年，無論是架構還是工具鏈、各種開源的函數庫，都已經形成強大的生態，對於如今的自動駕駛從業者而言，直接用程式設計來實現，反而比在Mathworks裡建模效率更高很多。 

同時，傳統汽車軟體量產後就不再發生變化，這對自動駕駛軟體來說是不切實際的。一方面，自動駕駛開發週期長，在整車開發週期內開發、測試的時間遠遠不夠；另一方面，OTA讓軟體持續升級有了可能，這樣軟體的生命週期也得到了延續，而以深度學習模型為代表的自動駕駛演算法，就需要持續不斷地收集長尾的「corner case」數據，作為「燃料」持續迭代演算法系統。

有句話說得好，如果要上太空，就必須要造飛船。為了更有效率地開發自動駕駛系統，業界專家們找到了適用於基於深度學習的自動駕駛開發流程——也就是數據驅動的端到端的開發流程。

對於這個軟體開發流程的轉變，有前瞻意識的車企和Tier 1也早已意識到。

博世底盤控制系統中國區總裁陳黎明曾在公開場合提到：「自動駕駛牽涉的場景非常多，不可能再按照傳統的方式繼續進行，所以必須加入實際道路測試，特別是用數據驅動的驗證方式對自動駕駛安全進行驗證，就是V模型和數據驅動的閉環進行結合，實現安全驗證。」

##泛亞技術中心的高級總監陸健翔在近期的世界智慧大會上表示：「傳統車企要從原本的車端的這種瀑布式的系統集成開發模式向雲管端一體化的敏捷式場景集成開發模式轉型。」

當然，這並不意味著傳統的MBD的方法已經完全過時。 V模型的想法仍然是很有指導意義的，例如在自動駕駛系統測試中發揮重要作用的系統仿真，其實就是SIL（軟體在換），而MBD開發方法，在汽車底層邏輯演算法，如車輛控制演算法中仍然會用到。

雖然每一家的數據驅動的軟體開發流程在細節上有不同，但是大體思路都是一致的，基本按照如下思路：數據採集->數據存儲-> ;資料預處理->資料探勘->資料標註->模型訓練->模擬測試->部署發布。

Waymo的資料閉環平台，引用自黃浴的知乎文章

上述環節中所使用的工具和平台（包括但不限於資料收集、處理、標註工具、模型訓練平台、模擬平台、OTA工具和一些其他環節的開發工具），被稱為“工具鏈” 。工具鏈的效率決定了整個系統開發的效率。

雖然可能看上去步驟不多，但其實整個連結非常複雜。

以數據處理為例，單數據類型就多種多樣，包括攝影機數據、毫米波雷達數據、光達點雲數據，需要先對這些數據進行去噪，也就是所謂的「資料清洗」。以圖片為例，資料處理需要先把圖片的地理位置資訊等擦除，把人臉、車牌等敏感資訊去除，再統一格式，這樣才算處理完成。

資料處理完成後，下一步便開始資料標註。標註的類型大致可分為2D、3D目標物標註、聯合標註、車道線標註和語意分割等，還要涉及具體標註規範和標註質檢流程，整個流程異常繁瑣。

而這複雜流程的每一個環節，都需要與之對應的工具和平台的支撐。

和MBD開發流程已經擁有成熟的工具鏈不同，數據驅動的開發流程，起步晚，工具鏈效率不高，給車企的自動駕駛開發人員帶來了很大的困擾。

數據驅動，源頭是數據，面對數據量龐大但高價值數據稀缺的問題，車企並沒有太多的經驗可供借鏡。

當然，不同的車企，在自動駕駛領域的累積程度不同，在工具鏈上遇到的問題也不盡相同。

部分車企起步早、投入大，（數據驅動）pipeline已經可以完整跑通，累積也比較多，為了進一步提升效率，他們也做了很多工具鏈的客製化開發。某車企的開發人員告訴《九章智駕》，由於現有不同公司提供的工具鍊是“分段開發”，只關注自己部分的功能而不關注全局，導致割裂和“數據孤島”現象嚴重。為了滿足自己的效率需求，他們必須自己開發工具鏈或是找生態體系內的企業來提供，甚至連數據標註平台都要自己開發。

對於在該領域累積沒有那麼多的車企來說，現階段投入那麼多人去開發工具鏈，就不是多麼「划算」了，一方面基礎薄弱，技術還沒研發到那個地步，另一方面也確實沒那麼多人。受限於資源投入和技術基礎，他們更多還是希望整合現成的工具鏈，盡快跑通（數據驅動）Pipeline，「工具鏈不是我們的競爭力，需求定義、系統整合和功能測試才是我們的競爭力”，某車企智能駕駛負責人告訴《九章智駕》。

不同車企雖然開發階段不同，但也有相似之處，那就是都有工具鏈「割裂」的痛點。接下來，我們就分別從資料處理、模擬這兩個環節入手，詳細整理下工具鏈的現況與痛點。

02 資料處理：資料驅動的基石

資料驅動，最核心的就是資料。

傳統基於模型的開發流程，更多是基於開發者的過往經驗對模型最佳化，而資料驅動，則是要基於海量的資料來最佳化模型。對車企而言，要建立數據驅動的開發流程，必須學會怎麼處理龐大的數據。

資料處理，是整個開發鏈路的第一環節，也是最繁雜的環節，包括了資料收集、資料預處理、資料探勘和資料標註等環節，其數據量的多寡和資料品質的高低直接決定了整個模型的水準。

下圖為特斯拉自動駕駛資料處理的連結。

Tesla Autopilot資料處理流程（引用自黃浴的知乎文章）

資料相關的工具鏈，包括了資料收集、資料上傳、資料清洗、資料標註等環節。

1.資料收集：智慧化勢在必行

先說資料收集。

業界有一些開源的資料集，可以用做基礎演算法訓練，目前最常用的資料集有KITTI、nuScenes等，不過這些資料還是多半來自海外的公開測試集，中國本土特色的資料集，還是比較少的。

自動駕駛開源資料集匯總，引用知乎文章《自動駕駛開源資料集匯總》

在這種情況下，要訓練符合特定場景的演算法，就需要收集該場景的資料。只有足夠多且高品質的資料收集到了，才有了後續的流程，而這第一個環節，目前工具鏈的效率並不太好。

某頭造車新勢力員工告訴《九章智駕》，該公司自動駕駛資料收集觸發、資料上傳的策略還不能滿足後續問題分析的要求。例如，用戶撞了車之後，回傳的數據不能用——要嘛數據量不全，要嘛採集頻率不對，開發人員在排查問題時效率很低。

一般來說，不同的Corner Case，後續分析所需的資料格式不一樣、前後所需的時間段也不一樣。這很容易理解，不同原因導致的接管，是感知還是決策模組的問題，還是高精地圖的錯誤，所需要的數據當然是不一樣的。甚至針對某些特殊的Corner Case，還會有一些客製化的資料收集需求，讓測試人員帶著採集任務去路測。

而正是因為採集需求複雜，鏈路打通又難，現實中有些工程師遇到問題，便會選擇自己去採集資料。

為了避免上述這些問題，有些L4 Robotaxi公司選擇用最原始的「硬碟拷貝」方式，全量資料回傳，然後再進行資料探勘。

這樣做，當測試車輛數量少時，是沒有問題的，一旦後續車輛多到一定程度後，自動駕駛採集的數據量即將進入PB時代，如此“海量”的數據，真正找到有價值的、佔比較少的Corner Case，真正的「大海撈針」。

而要擷取對自動駕駛真正有用的片段數據，就需要更智慧的資料擷取策略。

何謂智慧化資料擷取策略？就是針對特定場景進行資料採集。

華為內部人員在和《九章智駕》交流時，提到「華為八爪魚」有對場景進行智慧化打標籤的功能：「例如發生人工接管，或遇到隧道、環島、無保護左轉等，以及快遞三輪車之類雲端需要主動蒐集累積資料進行學習的場景。開發人員可以上傳需要車輛取得的圖片，透過雲端下發指令，車端會採取類似'以圖搜圖'的方式，遇到類似的場景就會自動截取下來。這樣，只需要把這些打過標籤的'有價值'數據篩選出來上傳到雲端即可，可避免整段數據上傳，能提升Corner Case挖掘的效率。」

##2.資料標註：外包趨勢與對高品質低價的追求

##找到有價值的數據之後，就需要進行資料清洗和資料標註。

在以深度學習為主的知覺模型中，主流的深度學習訓練方法還是監督學習，用這種方法訓練，需要向模型「餵養」海量有「真值（Ground Truth）」的數據。

那這些「真值」資料從哪裡來？人工標註出來的。

所以行業經常開玩笑說，人工智慧，就是“有多少人工，就有多少智能”，也因為海量數據標註的需求，還誕生了一個新職業—— 「人工智慧訓練師」。

雖然職業名字聽起來很好聽，但其實，資料標註本質上是一個勞力密集的產業。為了能夠獲得足夠廉價的勞動力，企業在新疆、河南、山西的某些地區集聚，形成了數據標註的產業群聚。

作為客戶（標註需求方），他們關心的是標註品質夠不夠好，標註價格夠不夠便宜，換句話說，就是「既要馬兒跑得快，還要馬兒不吃草」。

首先，模型訓練對標註資料的品質要求很高，資料品質直接決定了訓練出來的模型精度高低，品質不高，很容易“Rubbish In，Rubbish Out” 。而標註品質和標註成本密切相關，經濟不發達地區的廉價勞動力的標註質量，能否滿足開發者們的需求，是一個很大的疑問。

其次，需要標註的資料量龐大，例如新的視覺演算法通常需要上萬張到數十萬張不等的標註圖片做訓練，定期優化也有數千張圖片的需求，單張圖片標註價格差一點，放在幾十萬張的體量下就是個很大的數字，因此，需求方對價格很敏感。

高品質的標註要求，必然會導致人力成本上升，而低價格則會影響標註質量，高品質和低價格似乎成了一個難以調和的矛盾。

對車企而言，養幾十號人去做數據標註會顯得人力成本過於沉重。他們一般更傾向選擇外包給專業的數據標註平台或數據標註團隊去做，比較有名的數據標註平台有百度眾測、京東眾智、龍貓數據、數據堂等。

不過外包也分為兩類：第一類是人力外包，即自己提供標註平台和標註工具，外包公司只需提供人力即可；第二類是服務外包，即自己不提供標註平台和標註工具，直接將待標註數據提供給外包公司，外包公司提供標註好的數據。

部分車企對標註效率要求很高，會選擇自己開發標註平台和標註工具，這樣他們就會選擇人力外包；而對於另一些車企而言，自己開發標註平台顯然性價比不高——一方面需要投入那麼多資源去開發標註平台，另一方面，自己開發的標註平台和外面的對比價格上又沒有優勢，不划算。

因為市場需求的爆發，資料標註產業湧現了許多新創公司，data.forge就是其中一家，其創辦人兼CEO楊洋向《九章智駕》介紹：客戶最關心的是品質/價格比，為了提升品質/價格比，他們採取了許多措施，例如自動化輔助標註，還有優化標註工具的便利性，這也形成了公司的核心競爭力。

華為內部人員向《九章智駕》介紹時，提到「華為八爪魚」也提供資料標註服務：

「首先，'華為八爪魚'花了很多時間打磨自己的預標註演算法，目前華為的預標註演算法精度已經達到領先水平，在nuScenes、COCO、KITTI等多個自動駕駛國際公開資料集測試挑戰中獲得第一，預標註演算法可以大幅減少每框資料標註所需的時間。

「其次，為優化標註平台的操作，我們會結合具體的業務操作去優化人機互動方式，提升工作人員的操作效率。

「再次，我們有成熟的管理系統來保證標註質量，標註人員標註完成後，經過標註人員的自檢、質檢員的抽檢和標註經理的抽檢三重質檢流程後，才會交付給客戶。與其他標註團隊大部分標註人員分佈在新疆、河南、山西等地不同，華為的人工標註團隊在深圳，就在華為的辦公室。之所以這麼做，是為了方便溝通和管理，也能更好地保證標註品質。

「最後，為了解決本土開源資料集不足的問題，'華為八爪魚'除了能夠給客戶提供增量的資料標註服務外，還可為客戶提供2,000萬個已標註的對象，而且這個資料集是持續迭代、持續擴充的，客戶可以利用這些資料進行訓練，快速地搭建起模型。 」

03 模擬－自動駕駛開發的加速器  

#作為自動駕駛工具鏈中非常核心的一環，模擬系統主要由場景庫、模擬平台和評測體系三部分組成，模擬系統的效率高低直接影響到了整個開發鏈路的效率，所以一直是客戶的痛點，也是眾多玩家瞄準的市場。

##也正是因為看到了模擬系統的重要性和不成熟的現狀，深感“廣闊天地，大有可為”，眾多玩家紛紛進入了這個賽道。根據公司類型，這些玩家大致可以分為傳統仿真軟體公司、新創仿真軟體公司與科技巨擘模擬軟體三類，以下就分類盤點一下。

1.模擬軟體玩家盤點

（1）傳統模擬軟體公司

傳統模擬軟體以西門子公司的PreScan、德國VIRES公司的VTD、德國IPG公司的CarMaker和美國MSC的CarSim等為代表。他們或憑藉某部分領域深厚積累，或因某些功能做的出色，而廣大車企廣泛使用：CarMaker和CarSim在車輛動力學領域積累最深、實力最強；VTD以其場景高渲染能力和最先支持OpenX而知名；PreScan以操作方便、上手容易吸引了眾多用戶。

憑藉現有的客戶資源加上過去的累積的優勢，他們成為了自動駕駛模擬軟體領域的重要玩家。#

（2）新創模擬軟體公司

看到了模擬軟體龐大的市場空間，許多新創公司新玩家也紛紛進入，希望分一杯羹。例如國內的新創公司51WORLD（原51VR）推出了51Sim-One自動駕駛模擬測試平台；以色列新創公司Cognata，為智慧駕駛產品各個階段提供不同的模擬解決方案，為了滿足不同客戶的需求，甚至推出了本地版、雲端版和硬體版本三個版本。

新創公司對市場更敏感，沒有歷史包袱，其為車企提供的模擬平台，開始有意識打通仿真的各個環節，成為一股不可忽視的力量。

（3）科技巨擘模擬軟體公司

英偉達：Drive Constellation

英偉達於2018 年推出Drive Constellation 模擬系統。該仿真係統由兩台不同的伺服器打造，第一台伺服器運行英偉達DRIVE Sim 軟體來進行感測器仿真，如相機、光達和毫米波雷達，第二台伺服器搭載了英偉達DRIVE Pegasus 人工智慧車載運算平台，用來處理仿真的感測器資料。

Drive Sim基於Omniverse平台，根據英偉達官方的說法，它可以達到「照片級逼真且物理精確」的感應器模擬。在場景方面，Drive Constellation 可以產生資料流，創造各種測試環境，模擬各種天氣條件，以及不同的路面和地形，還可以模擬白天不同時間的眩目強光以及晚上有限的視野。

華為：「華為八爪魚」自動駕駛雲端服務

在自動駕駛開發工具鏈領域，華為推出了自動駕駛雲端服務，也稱為“華為八爪魚」（HUAWEI Octopus），從資料收集、難例挖掘、資料標註、演算法訓練、模擬平台等方面提供了完整的解決方案，並提供了大量的資料集和場景庫供客戶使用，幫助車企建構數據驅動閉環的自動駕駛開發平台。

另外，基於華為強大的雲端業務，「華為八爪魚」整合了雲端訓練和雲端並行仿真，有豐富的仿真場景，高並發實例處理能力，提供超過20萬個模擬場景實例；系統每日虛擬測試里程可超過1000萬公里，支援3000個實例並發測試。

百度：阿波羅平台

百度Apollo為開發者提供基於雲端的決策系統模擬服務，建置在百度雲端和微軟Azure上的雲端模擬平台，輕鬆打造日行百萬公里的虛擬運作能力。在場景庫方面，百度Apollo平台提供的場景庫涵蓋了法規標準場景、危險工況場景和能力評估場景，共200種左右。

Apollo也與Unity合作，開發基於Unity 引擎的虛擬模擬環境，提出了端到端的自動駕駛模擬系統－擴增實境的自動駕駛模擬系統AADS，透過模擬交通串流來擴增實境世界影像，進而創造逼真的模擬場景。

百度開放了自動駕駛資料集ApolloScape，目前已經開放了14.7萬幀的像素級語義標註影像，包括感知分類和路網資料等數十萬幀逐像素語義分割標註的高解析度影像數據，以及與其對應的逐像素語義標註。 」

騰訊：TAD Sim

騰訊於2018年發布模擬平台TAD Sim，這是一個結合專業的遊戲引擎、工業級車輛動力學模型、虛實一體交通流等技術打造的虛實結合、線上線下一體的自動駕駛模擬平台，可實現場景的幾何還原、邏輯還原及物理還原。

TAD Sim 也支援雲端運行，包括場景型雲仿真和虛擬城市型雲仿真兩種模式。城市型雲仿真既可以實現加速仿真，也可以實現高並發仿真，滿足真實世界中各種場景和駕駛的可能性，加速企業自動駕駛測試流程。場景庫中有超過1000 種場景類型，具備每日1000 萬公里以上的測試能力。

這些科技巨頭做模擬平台，更多的基於其已有的渲染能力、雲端運算等優勢去建構自動駕駛仿真流程，他們更重視雲端並行仿真，對場景庫也更為重視，也更有意識地打通上下游各環節，將自動駕駛系統的測試驗證向前推進了一步。

2.模擬的痛點

（1）模擬軟體：既要懂仿真，也要懂汽車

作為自動駕駛開發連結中的一環，模擬需要和其他環節有機地結合在一起。

傳統模擬軟體，雖然在某些領域很專業，但和上下游連結打通時就很麻煩。

例如，對路測中發現的問題，開發者們當然希望將該場景納入模擬場景庫，後續可以做回歸測試，而許多傳統軟體是不支持這一功能的，只能自己手動去建場景庫，手動建立場景庫的效率很低，一天也建不了幾個。

例如，有些傳統模擬軟體只能在WINDOWS環境運行，而現在自動駕駛開發的環境都是在Ubuntu環境下。

再比如，傳統模擬軟體的雲端平行模擬功能相容性不好，有些是最近版本才開始相容雲端模擬。根據某業內專家透露，因為傳統模擬軟體是賣License的，幾台電腦裝這個軟體就賣幾個License。

隨著雲端平行模擬發揮越來越大的作用，依照服務收費的SaaS模式對客戶顯然更加友好，也是後續的發展趨勢，傳統模擬軟體賣License的模式也需要隨之調整。

雲端平行模擬無疑能大幅提升自動駕駛開發效率，華為、百度、騰訊等巨頭的模擬平台可以無縫銜接他們的雲端平台，新創公司51WORLD 的產品也支持並行模擬並支援部署在私有雲和公有雲上。

而生態型巨頭們除了提供模擬軟體外，還把模擬平台和其他工具鏈打通，融入他們的全端解決方案中。例如「華為八爪魚」提供了雲端一站式的模擬評測工具鏈，實現自動駕駛領域的DevOps，從程式碼倉庫接入、版本管理，到模擬、評測，可以實現自動化閉環。這樣，車企使用起來，上手更容易，適配成本也更低。

不過這些巨頭們也面臨一個不小的挑戰，那就是由於對車輛動力學模型、汽車核心零件等硬體方面缺乏足夠的積累，這些公司需要通過自研或合作補齊相關的能力。如百度選擇自研車輛動力學模型，Apollo 5.0新增了車輛動力學模型；「華為八爪魚」的模擬系統，則和VTD戰略合作，並嵌入了CarMaker的車輛動力學模型。據了解，華為與賽目科技也開始建立合作關係，將在自動駕駛預期功能安全（SOTIF）領域發力。

（2）場景庫是核心

在資料驅動的開發連結中，資料驅動相當於“題海戰術”，考官能做的就是出更多更難的題目。在系統開發連結中，場景庫便相當於考官出的考題，來評價軟體好壞的標準，因此，場景庫的數量和質量，直接決定了系統層級的高低。

場景庫一般有幾個來源：採購自第三方的場景庫，市面上能買到的第三方場景庫多以標準法規和專家的經驗資料為主；針對場景去正向搭建場景庫，例如要做泊車功能，就針對泊車設計場景，比較費人力；針對路測中發現的接管事件或者Corner Case，反向生成場景庫，相當於考生根據之前錯題整理成了自己的「錯題本」。

除了這些場景庫外，車企還持續不斷地透過路測中遇到的Corner case來「擴建」自己的場景庫。針對這一需求，有些模擬軟體，如“華為八爪魚”，則提供了“一鍵將真實路測場景轉化為仿真場景”的功能，並且可以在此基礎上進行編輯泛化。例如，改變天氣環境、週邊環境、鏡像等手段去泛化出更多的場景，華為也提供了虛實混合模擬能力。

所謂虛實混合仿真，就是在雲端建造測試場景，再將其加載到車端運行，這樣車輛可以在空曠的道路上或封閉場地內，模擬出各種虛擬場景，尤其是行人橫越、非機動車輛CUT-IN等危險場景，這樣就可以測試自動駕駛演算法和實車的車輛動力學性能，進而提升測試效率。

（3）模擬評估

#

模擬評估可能是整個模擬體系中最容易被忽略的部分。

模擬評估主要包括兩方面，一方面指當前測試是否可以判定為通過，另一方面指當前測試對應的同場景實車測試的一致性、重複性如何。

如何評估系統能否順利通過一個場景庫的考試？考題也出了，考生也做完了，那如何進行“閱卷”，給自動駕駛軟體系統打KPI呢？

如果你是考官，你能想到的評價標準有哪些?

目標點是否到達？是否安全行駛（沒有發生碰撞）？有沒有闖紅燈？是否急加速急減速？等等。

評價標準隨便一想就可以有很多，更讓人頭痛的是，不同場景對演算法考察的重點不同，很可能評價標準也是不一樣的。場景庫千奇百怪，評價標準自然也千差萬別。

但整體來說，可以將評價標準分為五大面向：標準匹配性（是否符合標準法規）、駕駛安全性（是否足夠安全）、駕駛高效性（是否能夠足夠高效的到達目的地、燃油經濟性）、駕駛舒適性（是否足夠舒適）和駕駛智慧性（是否足夠聰明）。

據業內專家透露，每個在場景庫在搭建的時候都要「量身訂做」通過與否的評價標準。這時候就需要模擬軟體提供多樣化的模擬評估標準了，如果不提供的話，相當於在某些方面無法考核到。

因此，各個模擬軟體也給客戶提前預定義了場景庫的評測標準，如「華為八爪魚」從安全性、舒適性、可靠性、人機交互體驗、可用性、合規性、能耗性和通行效率等維度，共開放了200項評估指標。據華為內部人員透露，為讓模擬評價更靈活，後續也將支援由客戶自行客製開發模擬評價標準。

3.模擬軟體的標準化發展趨勢

上文所說的模擬平台和上下游工具鏈打通，都是縱向打通 ，業界還有一個比較大的痛點，是橫向打通時，不同模擬軟體之間格式無法相容。

同一家車企往往會同時使用幾種模擬軟體，例如可能既用Prescan，又用VTD，每個模擬軟體上都會累積一系列場景案例，但是不同的仿真軟體製作的場景案例庫，格式是相互無法相容、文件不能通用的。

這其實是因為整個產業的標準化程度不夠。

為了解決這個問題，ASAM 發布的模擬領域標準 OpenX 得到了許多車企、供應商和科研機構的認可，目前大多數模擬軟體也都開始支援OpenX標準。 ASAM正在製定更多的標準。

ASAM模擬格式標準（引用自2020中國自動駕駛模擬藍皮書）

#當下仍有部分模擬軟體目前不支援OpenX格式。據業內人士透露：「某些模擬軟體公司想把所有的環節掌握在自己手裡，讓自己具有不可替代性，讓客戶綁定在自己身上，想換也換不了。這也是以前一些做模擬測試的巨頭的慣用的手段。但車企肯定是不能接受的，他們非常不想被綁架，希望做到標準化，減少遷移成本。」

畢竟不支持OpenX的還是少數，從整體來看，標準化是大勢所趨。相信隨著標準化的推進，不久後不同軟體之間的檔案相容將不再是問題。

4. 高精地圖，工具鏈不可或缺的一環

大家都知道，現在很多L2 自動駕駛功能，都會使用高精地圖，尤其是L4自動駕駛，高精地圖將成為重要的基礎設施。而對於自動駕駛模擬來說，高精地圖也是不可或缺的重要環節。許多模擬場景的構建，例如上文提到的路測場景轉化為模擬場景，以及虛實混合模擬都離不開高精地圖的支援。

（1）合規性問題

#不過高精地圖也有很多痛點，首先要解決的是合規性問題。

目前國內只有20多家企業有甲級測繪資質，華為、阿里、騰訊、百度、小米、滴滴都擁有該資質，車企中，上汽中海庭、吉利億咖通，以及近期收購智途科技的小鵬汽車，也都擁有甲級測繪資質。

四維圖新執行總裁白新平曾經對媒體表示：「高精地圖必須是有資格的企業參與，資質關係到合規和安全，前期國家在這個領域監管不是太嚴格，以後會越來越嚴」。

在這樣的背景下，車企的量產方案為了解決合規問題，就會紛紛選擇有資格的地圖服務商合作。地圖服務商需要建構高效能、高可靠、符合安全合規要求的基礎設施，能有效支撐海量地圖資料的安全存儲，還應具備強大的算力資源以及智慧演算法，對路測資料進行資料脫敏與合規應用的處理，同時系統也要有效支援第三方合作夥伴進行智慧駕駛開發以及地圖資料應用服務。

（2）複雜場景精度問題

目前頭部地圖服務商已經涵蓋了全國主要的高速公路和快速路，但地圖品質仍不容樂觀，仍會有漏標和錯標的情況。

業內人士告訴九章智駕，某頭部地圖服務商對高速路段的高精地圖覆蓋並不完整，尤其是對於進出高速的匝道以及收費站和服務區，會存在偏差或覆蓋不到的情況。

而在和某車企的高精地圖負責人溝通時，該負責人告訴九章智駕，他們做L4 Robotaxi測試時，主要場景就是在城市道路，而這部分可以涵蓋的地圖服務商較少，而且品質和更新頻率都不高，他們必須自己採集和製作高精地圖。

因此高精地圖不僅要加強高快速路的覆蓋，也要重點解決城市通勤場景的覆蓋問題，提升複雜路況的精確度。這樣才能提升高精地圖對自動駕駛的支撐作用，同時有效支援城市複雜場景的自動駕駛模擬與測試。

（3）動態更新問題

高精地圖還需要解決動態更新的問題，否則，資料一旦失去時效性，非但無法有效支撐智慧駕駛，還可能帶來安全隱憂。

目前多位業內人士分析認為，地圖眾包更新模式，因為從更新時效率和採集成本角度上更具優勢，將會成​​為未來主流技術模式，針對該技術路線，國內相關地圖服務商也不斷探索，並進行了相關技術測試。地圖眾包更新，除了技術上面臨不少挑戰，例如資料來源多樣化，品質參差不齊、採集要素標準未統一、雲端-端-車鏈路互通等問題，更面臨著國家法律法規方面的限制，這其中涉及敏感地理資訊過濾、地圖資料加密、個人隱私外洩等風險，需要國家相關部門做進一步的統籌規劃。

事實上，解決高精地圖的動態更新是一個系統工程，需要多方資源、資料的匯聚和融合，以及雲邊端的協同，未來將透過地圖服務商、智慧網聯汽車、各類交通參與者、道路基礎設施、邊緣運算與雲端協同，以及交通大數據、路政建設維護數據、道路營運企業等多方合作，實現高精地圖動態更新，提升高精地圖數據的鮮活度。

在筆者看來，高精地圖的製作和更新是一個浩大的工程，如果能形成統一的高精地圖要素標準，多方資源統籌協作，減少重複性工作，共同繪製全國一張圖，從而大幅降低產業成本、提升產業效率和資料可靠性，減少資料安全風險，將是一大幸事。

04 上雲 或 不上雲，這是一個問題

1.上雲好處多

資料驅動的系統開發中，無論是海量資料的儲存、模型的訓練還有平行模擬測試，都需要用到大量的IT資源。

業內人士告訴《九章智駕》，自動駕駛系統開發時，會突然遇到一些突發的算力需求，如模型訓練，本地的算力無法滿足需求，而走流程採購新的伺服器，審批流程可能動輒幾個月，很影響開發進度。而據了解，為了因應該需求，某車企智能駕駛開發的子公司，在規劃新辦公大樓時，把整整一層辦公大樓規劃為機房。

不管是儲存還是訓練，應付這種突發的需求，其實有個非常好的辦法，就是──上雲。

上雲好處很多，像是雲端的開發環境相容性好，快速彈性擴容能提升開發效率，在成本和資料安全性上也有好處。

比較比較自建機房，上雲的好處

在新冠疫情特殊背景下，數位轉型成了企業生存之道。為因應疫情，企業要實現業務即時在線，將服務場景從線下搬到線上，就要數位轉型，透過雲端會議、雲端採購、雲端銷售、雲端簽約等，將員工、客戶、服務和流程的全面線上化。

數位化發展程度越高，對企業發展越有利，IDC研究資料發現，數位化指數高的企業，生存能力甚至超過平均5倍以上。 

業界普遍認為，要實現數位轉型，上雲是必經之路，甚至是第一步，「數位化必然要先上雲」。

上雲，更是建立自動駕駛資料閉環開發連結的必要選項。以「華為八爪魚」對Corner Case的最佳化連結為例，在車端發生人工接管後，「華為八爪魚」自動觸發並在線上回饋至雲端，雲端進行追蹤回放並診斷確定原因，如果確認是自車責任（自身係統問題），那麼資料擷取服務會將接管前後的有效資料上傳至雲端，並進入資料處理流程。

如果是感知環節需要最佳化，則進行資料擷取、清洗、標註，處理完後在雲端進行感知模組的訓練；如果需要最佳化規劃控制模組，則將該問題場景一鍵轉化為模擬場景庫。優化後的演算法系統要平行模擬測試和回歸測試，若模擬評測也通過，則雲端啟動OTA推送服務，對車端系統進行升級，如此一個完整的閉環便完成了。

「華為八爪魚」資料閉迴路連結

上雲，更是自動駕駛從開發測試階段到商業化的必經之路。

目前，大多數車企還是以開發測試為主，測試車輛數量幾台、幾十台不等，但是隨著測試車輛越來越多，到後續量產後的成千上萬台，每天產生的資料量也將由百/千TB的量級提升到10PB級，訓練和平行模擬所需的GPU算力也會從數十個擴展到到上千個，屆時上雲的需求會變得越來越迫切。

了解完上雲的好處，我們再來看下稍微了解下雲運算的分類。

雲一般分為三類：公有雲、私有雲、混合雲。

公有云是非用戶所有的基礎架構建構的，可以分配給多個租用戶使用的雲，平時最常說的上雲，就是指的是公有雲，常見的公有雲服務商有亞馬遜AWS、阿里雲、華為雲和騰訊雲等。

私有雲一般是指為單一客戶創建的，存取權限歸該客戶專有，客戶可以選擇在自己的機房中搭建（私有化部署），也可以選擇在雲服務商的機房內進行託管服務（託管私有雲）。

混合雲一般可以被看做是私有雲和公有雲的二者結合體，或是採用不同服務商的公有雲。

一般認為，公有雲可以快速擴容，更適合需求量大或有波動的工作負載，而私有雲要擴容，則要購買或租借新的硬體和資源，要複雜的多。在自動駕駛開發過程中，一方面隨著車輛數的增多，儲存的需求量會指數級上升，另一方面開發中也常會有突發的大算力需求（雲端訓練或平行模擬等），面對這樣的需求，公有雲會比較適合一些。

從雲端運算的發展趨勢來看，公有雲市場佔比逐年提升，私有雲佔比逐年下降。艾媒諮詢數據顯示，2020年中國雲端運算市場，公有雲規模在2019年超過了私有雲，成為了第一的主要市場。

2.資料安全的隱憂

在和《九章智駕》溝通時，車企人員在認可公有雲的好處的同時，也提出了擔心——資料安全，「我的資料放在公有雲上，會不會被別人盜用？」一位車企人員這樣說。

正是因為有這樣的擔憂，許多車企會選擇自建伺服器，或是選擇私有雲；部分車企會選擇混合雲，即企業只將一部分不涉及到資料安全和資料隱私的服務運行在公有雲上，而將其他服務運行在私有雲裡。

一些頭部車企和造車新勢力，雖然選擇公有云，但在選擇公有雲服務商時選擇和自己存在股權關係的服務商，「畢竟是自己人，不用擔心資料安全”，他們這樣解釋。

信任的基礎是彼此之間的了解、熟悉。很多時候，不信任，就是因為不了解，例如上雲。

對於上雲的企業而言，其雲端上資料被妥善地保護，是其最重要也是最基礎的安全需求，這也是雲端服務商贏得客戶信任的“生命線」。

根據《阿里巴巴經濟體雲原生實踐》內的介紹，客戶對資料安全的要求，可以用資訊安全基本三要素 "CIA"來概括，即機密性（ Confidentiality）、完整性（Integrity）和可用性（Availability）。

機密性專指受保護資料只可以被合法的（或預期的）用戶可訪問，其主要實現手段包括資料的存取控制、資料防外洩、資料加密和金鑰管理等手段；

完整性是保證只有合法的（或預期的）使用者才能修改數據，主要透過存取控制來實現，同時在資料的傳輸和儲存中可以透過校驗演算法來保證使用者資料的完整性；

資料的可用性主要體現在雲端上環境整體的安全能力、容災能力、可靠性，以及雲端上各個相關係統（儲存系統、網路通路、身分驗證機制和權限校驗機制等等）的正常工作保障。

在這三方面中，保障機密性（Confidentiality）的最主要的技術手段就是資料加密，而且是全連結的資料加密能力。

「全鏈路加密」指的是端對端的資料加密保護能力，也是資料全生命週期的加密，主要指的是從雲端到雲端和雲端單元之間的傳輸過程、到資料在應用程式運行時的計算過程（處理/交換），和到資料最終被持久化落盤的儲存過程中的加密能力。

整體來說，資料加密操作流程是明文資料經由國際國內公認的安全演算法計算得出資料密文。在加密操作中，被安全保護和管理的金鑰是加密保護的充分且必要的條件。換言之，控制了金鑰，也就控制了整體加密操作的主動權。由於使用者自備主金鑰為使用者資源，而任何呼叫需透過使用者授權，使用者對於加密後資料的使用有了完全自主的控制權和主動權。同時，任何對於使用者資源的呼叫都會在日誌審計中完整的顯示出來，因此加密後資料的雲端上使用透明性也有了更好的保障。

 資料安全的生命週期，摘自阿里巴巴經濟體雲原生實踐

諸多業內人士在和《九章智駕》交流的時候，也提到了一點：誰能保證雲端服務商內部員工或維運人員不會利用自己的權限去偷偷的使用我的資料？  

這其實涉及到合規，需要透過內部流程來保證，而這個內部流程往往透過權威第三方的合規認證來確認。其中目前國際上最權威、最廣受接受及應用的資安系統認證是ISO27001，在各大雲服務商的官網上也都能查到各自通過的合規認證。

外部的合規認證還要落實到內部的執行，以華為為例，其內部從開發到管理的安全紅線都有一系列規定，一旦有人違反，處置很嚴格，動輒降職、處分、警告，甚至開除等。在聊到合規問題時，該華為內部人士還開玩笑說，美國在開始製裁華為之後，一直傾全力在全球範圍找華為“不合規”的“實錘”證據，結果兩年多了也沒找到，這也從側面證明了華為在合規性方面做得有多嚴格，前段時間華為智慧車雲端服務也通過了ASPICE L2第三方認證和大眾集團APSICE(KGAS) PN（潛在供應商）審核，這也說明華為智慧車雲端服務的研發品質和開發流程已經被國際主流汽車廠商所認可。

也許，從商業邏輯上來理解會比較容易。對雲端服務商來說，客戶的資料安全就是命根子，客戶把命交給你，一旦出現問題，這份信任就不存在了，也就失去了商業上的立足點了。而且從雲端運算本身的架構來說，雲端上的資料也會更安全：一方面雲端服務商會做異地容災的資料備份（防止火災等天災導致資料遺失），另一方面安全保護等級也更高（更多的安全人才，採取更多的安全措施）。

雖然對車企來說，上雲是大勢所趨，但也不會一蹴而就，車企對公有雲的理解和接受，需要一個過程。

某公有雲市場推廣人員告訴《九章智駕》，相對來說，網路背景的自動駕駛公司和外資車企更願意上雲，傳統車企，尤其是國企，在數據方面的擔憂會更多。

從雲端運算的產業發展趨勢來看，不同產業對雲端的認識程度不同，雲端運算的使用率也不同，根據Frost & Sullivan數據顯示，目前中國雲端運算的主要使用者集中在對雲端接觸比較早的網路、金融、政府等領域，其中，網路相關產業佔比約三分之一，政務雲目前佔比約29%，交通物流、製造業等傳統產業雲計算應用水準正在快速提高。相信接下來，隨著車企對雲端運算的認識加深和數位轉型的進程加快，對上雲的接受度也會越來越高。在不久的將來，上不上雲，或許也不再是個問題。

05 工具鏈的發展趨勢

1.高效率：端對端

目前車企在開發自動駕駛系統中，最大的痛點是，工具鏈的相互分割和資料孤島。

傳統工具鏈公司和新創公司往往聚焦在工具鏈的某一個環節，例如做仿真的就做仿真，做標註的就做標註，而車企在使用時，每一部分是作為整個開發工具鏈中的一環來串聯使用的，如果只聚焦在中間的某個環節，難免就會與其他環節「錯位」。

並且，目前工具鏈缺少行業規範，每一家的差別很大，客戶不得不花大量的時間去適配，所以車企希望能由一家供應商將工具鏈的多個環節打通，減少自己的適配成本。也正是看到這個機會，科技巨頭們紛紛攜「工具鏈生態」入局，提供了全端的工具鏈。

以下就盤點下科技巨擘的生態：

#（1）英偉達：基於晶片的生態

晶片巨頭英偉達已圍繞車端、桌面端、雲端建構了GPU硬體統一架構和CUDA軟體架構，開發者可以用很簡單的指令呼叫複雜的深度學習模型。 《九章智駕》在和業界專家交流中得知，他們選擇英偉達很重要的原因在於，英偉達擁有穩定的工具鏈和豐富的軟體生態。成熟工具鏈的好處在於，如果出了問題，可以快速定位到問題出在哪裡。

2017年，英偉達發表了自動駕駛平台NVIDIA DRIVE ，該平台上也搭配了自研的軟體架構Drive AV 和 Drive IX。 NVIDIA DRIVE 平台的車用智慧駕駛控制器。目前上市的有 Xavier 系列，最新 Orin  計畫2022年量產上車，並能達到 ISO 26262 ASIL-D 的功能安全標準。

在模擬領域，英偉達於 2018 年 推出Drive Constellation 模擬系統與Drive Sim。

2019年，英偉達也展示了其高精定位方案 DRIVE Localization，此外，英偉達也正在規劃高精地圖眾包方案NVIDIA MapWorks 。

目前，英偉達已經和賓士、奧迪、豐田、沃爾沃、博世、大陸等公司建立了自動駕駛研發合作。

（2）華為：雲管端芯組合的開放生態

華為堅持「不造車，聚焦ICT技術，幫助車企造好車」的策略，在晶片、雲、軟硬體、工具鏈和高精地圖等多方面發力，打“組合拳”，形成開放的生態。

華為智慧駕駛運算平台MDC整合了華為自研的CPU、AI晶片和其他控制晶片，並透過底層的軟硬體一體化調優，使整體效能達到業界領先水準。此外，華為MDC也有完整的測試平台與工具鏈，為MDC的開發提供了全端解決方案。 MDC平台硬體上運行智慧駕駛作業系統AOS/VOS和MDC Core。也就是說，MDC擁有車規級的軟硬件，方便車商的量產車款選用。

MDC整體架構圖-來自華為MDC白皮書 

在自動駕駛開發工具鏈領域，華為推出了自動駕駛雲端服務。此外，華為也推出了車聯網雲端服務（智慧駕駛、智慧座艙資料擷取與儲存）和三電雲服務（三電系統的雲端管控）和高精地圖雲端服務。除了這些，華為還“軟硬兼施”，佈局了自動駕駛感應器。

（3）百度：阿波羅開放平台

2017年，百度發布了無人駕駛開放平台阿波羅，向汽車產業及自動駕駛領域的合作夥伴提供一個開放、完整、安全的軟體平台，阿波羅平台是一套完整的軟硬體與服務系統，包括車輛平台、硬體平台、軟體平台、雲端資料服務等四大部分，可以幫合作夥伴結合車輛和硬體系統，快速搭建一套屬於自己的自動駕駛系統。

後續阿波羅持續升級，分別開放了限定區域視覺高速自動駕駛、自主泊車（Valet Parking）、無人作業小車（MicroCar）、自動接駁巴士（MiniBus）、複雜城市道路的自動駕駛等方案，並開始自建Robotaxi車隊，以「蘿蔔快跑」品牌在各地進行測試營運。

值得一提的是，Apollo發布了中間件Cyber​​ RT，提升了自動駕駛系統的安全性。

Apollo生態開發者提供基於雲端的系統模擬服務和擴增實境的自動駕駛模擬系統 AADS。

2021年初，百度和吉利合資成立集度汽車，宣布下場造車，李彥宏公開表示「成立集度汽車的目的，就是把百度的自動駕駛技術、智慧座艙技術推廣到市場」。

（4）騰訊：全鏈路雲端服務和開發平台

騰訊也在佈局自動駕駛雲端生態的開發平台。騰訊不造車，也不造感測器，僅提供軟體和服務。

在車端，騰訊提供包含了感知、定位、規劃、決策、控制的的解決方案；在雲端，基於雲端儲存及算力支撐，騰訊建構了資料擷取管理、樣本標註、演算法訓練評測、診斷調試、雲端模擬（模擬平台TAD Sim）、實車回授閉環全流程雲服務，提供支援自動駕駛研發的全鏈路雲端服務及開發平台。

#騰訊自動駕駛業務佈局和定位（引用自騰訊蘇奎峰的線上公開分享）

全端工具鏈對於效率的提升是很明顯的，尤其是可以快速建立Pipeline。 「華為八爪魚」內部人員介紹： 如果採用各家公司離散的工具鏈方案，光調試鏈路，可能要花幾個月的時間，而“華為八爪魚”，已經針對整個鏈路做好了整合和適配，減少了重複工作，此外華為還提供給客戶一套參考演算法，客戶可以在此基礎上調試優化，大大降低了上手的難度，最快只需要幾天就可以跑通整個完整鏈路，效率很高。

2.開放：各模組解耦

許多車企之所以會選擇自研工具鏈，一方面是出於效率考慮，另一方面還出於「安全」的考慮，車企還想延續自己過去在生態中的掌控地位，而本能地不喜歡潛在的被「卡脖子」的風險，所以往往喜歡和工具鏈上的小公司合作。

在開放性上，不同的科技巨頭策略也不盡相同，據某車廠自動駕駛開發人員透露，某企業自動駕駛開發平台的生態是不解耦的， “如果要選用，就必須'全盤接受'，不接受單模組使用”，籍此來深度綁定客戶；而華為選擇了另一條路——各模組解耦。

據華為內部人員介紹，「華為八爪魚」的工具鏈分為資料、訓練、模擬、監管四部分，這四部分完全開放解耦、不綁定，客戶隨時可以替換。

3.合作方式更靈活

對車企來說，如果已有的技術儲備不能支持量產方案，要量產就只能外購，這似乎和自研的策略產生了衝突。

在和《九章智駕》交流時，車企開發人員給出的答案出奇的一致：一方面，量產車裝的是外采的ADAS解決方案，由於是黑盒採購，供應商並不開放任何數據，但是為了整車的競爭力和銷量，車企只能容忍下這「眼前的苟且」；另一方面，車企們同時投入大量人力物力在自研L2 方案上，“一旦自研方案成熟，就會逐步替換上車”，於是自研成了“詩和遠方”。

考慮到車企客戶的這些訴求，「華為八爪魚」提供給客戶多種合作方案，華為內部人員介紹道：「第一種方案，華為負責開發並提供完整量產解決方案；第二種方案，華為負責開發，客戶可自由配置部分參數；第三種方案，華為提供自動駕駛開發工具鏈，客戶自研，華為提供全套售後開發諮詢服務。」 

06 總結

本文從自動駕駛開發工具鏈的角度分析了產業現況與發展趨勢。

目前自動駕駛開發工具鏈產業發展仍不成熟，非標準化和資訊孤島現像比較嚴重，頭部的自動駕駛團隊為了開發效率，不得不各自“造輪子” 。

不過，隨著眾多工具鏈新玩家的進入，整體產業正朝著成熟發展，後續工具鏈會逐漸開放、標準、規範。尤其是像華為、英偉達等巨頭攜生態入局，打通了整個開發鏈路，給行業帶來了範例，促進了行業發展，用華為內部人員的話說，這麼做是在「拉著中國的自動駕駛產業，不停地往前跑」。

自動駕駛上雲是大趨勢，隨著高等級自動駕駛，正逐漸從技術研究階段向規模商用階段演進，除了對儲存、算力等資源的要求，也對基礎設施服務的高可靠性、安全性以及可拓展性提出了嚴苛的要求。

傳統的資料中心建置模式將為自動駕駛開發企業帶來巨大的建設成本和營運維護壓力。而公有雲透過對多元算力的支持，可滿足自動駕駛開發過程中，模型訓練和平行模擬對海量基礎設施資源極致算力、安全可靠和彈性靈活的業務需求，進而實現自動駕駛演算法的敏捷開發與迭代。因此，儘管當前多數企業對公有雲的方式還心存疑慮，不過相信隨著整個自動駕駛行業的快速發展，以及對公有雲認識的持續加深，這種服務模式將會得到進一步推廣。

以上是深入探討自動駕駛開發工具鏈的現況與未來趨勢的詳細內容。更多資訊請關注PHP中文網其他相關文章！