劃重點：

1.車企自研自動駕駛系統成為趨勢。

2.基于MBD的開發流程已經不能滿足自動駕駛系統開發需求，需引入數據驅動的端到端的開發流程。

3.開發工具鏈的效率決定了整個系統開發的效率，工具鏈需要和pipeline數據流結合，當前工具鏈普遍存在割裂和“數據孤島”現象。

4.數據處理是數據驅動的基石：智能化數據采集勢在必行，數據標注的外包化和對高質低價的追求也趨于明顯。

5.自動駕駛仿真是開發的加速器：要求仿真軟件既要懂仿真，也要懂汽車；場景庫被車企視為核心競爭力；仿真評價面臨多樣化和定制化的趨勢；OpenX 得到了業內的普遍認可，仿真軟件也逐漸標準化。

6.高精地圖是工具鏈不可或缺的一環，合規性、復雜場景精度和動態更新仍是行業痛點。

7.自動駕駛上云是大趨勢。

8.自動駕駛開發工具鏈的發展趨勢是：高效（端到端）、開放和靈活合作。

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

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

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

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

一、自動駕駛開發流程——從基于模型設計到數據驅動

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

傳統的汽車軟件開發使用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模型和數據驅動的閉環進行結合，實現安全驗證?！?/p>

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

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

雖然每一家的數據驅動的軟件開發流程在細節上有不同，但是大體思路都是一致的，基本按照如下思路：數據采集->數據存儲->數據預處理->數據挖掘->數據標注->模型訓練->仿真測試->部署發布。

Waymo的數據閉環平臺，引用自黃浴的知乎文章

上述環節中所使用的工具和平臺（包括但不限于數據采集、處理、標注工具、模型訓練平臺、仿真平臺、OTA工具和一些其他環節的開發工具），被稱作“工具鏈”。工具鏈的效率決定了整個系統開發的效率。雖然可能看上去步驟不多，但其實整個鏈路非常復雜。

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

數據處理完成后，下一步便開始數據標注。標注的類型大致可分為2D、3D目標物標注、聯合標注、車道線標注和語義分割等，還要涉及到具體標注規范和標注質檢流程，整個流程異常繁瑣。而這復雜流程的每一個環節，都需要與之對應的工具和平臺的支撐。

和MBD開發流程已經擁有成熟的工具鏈不同，數據驅動的開發流程，起步晚，工具鏈效率不高，給車企的自動駕駛開發人員帶來了很大的困擾。數據驅動，源頭是數據，面對數據量龐大但高價值數據稀缺的問題，車企并沒有太多的經驗可供借鑒。

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

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

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

不同車企雖然開發階段不同，但也有相似之處，那就是都有工具鏈“割裂”的痛點。接下來，我們就分別從數據處理、仿真這兩個環節入手，詳細梳理下工具鏈的現狀和痛點。

二、數據處理：數據驅動的基石

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

數據處理，是整個開發鏈路的第一環節，也是最繁雜的環節，包括了數據采集、數據預處理、數據挖掘和數據標注等環節，其數據量的多少和數據質量的高低直接決定了整個模型的水平。下圖為特斯拉自動駕駛數據處理的鏈路。

數據相關的工具鏈，包括了數據采集、數據上傳、數據清洗、數據標注等環節。

1.數據采集：智能化勢在必行

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

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

 在這種情況下，要訓練匹配特定場景的算法，就需要收集該場景的數據。只有足夠多且高質量的數據采集到了，才有了后續的流程，而這第一個環節，目前工具鏈的效率并不太好。

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

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

而正是因為采集需求復雜，鏈路打通又難，現實中有些工程師遇到問題，便會選擇自己去采集數據。為了避免上述這些問題，有些L4 Robotaxi公司選擇用最原始的“硬盤拷貝”方式，全量數據回傳，然后再進行數據挖掘。

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

而要采集對自動駕駛真正有用的片段數據，就需要更加智能化的數據采集策略。

何謂智能化數據采集策略？就是針對特定場景進行數據采集。華為內部人員在和《九章智駕》交流時，提到“華為八爪魚”便有對場景進行智能化打標簽的功能：“比如發生人工接管，或者遇到隧道、環島、無保護左轉等，以及快遞三輪車之類云端需要主動搜集積累數據進行學習的場景。開發人員可以上傳需要車輛獲取的圖片，通過云端下發指令，車端會采取類似‘以圖搜圖’的方式，遇到類似的場景就會自動截取下來。這樣，只需要把這些打過標簽的‘有價值’數據篩選出來上傳到云端即可，可避免整段數據上傳，能提升Corner Case挖掘的效率?！?/span>

2.數據標注：外包趨勢和對高質低價的追求

找到有價值的數據之后，就需要進行數據清洗和數據標注。

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

那這些“真值”數據從哪來？人工標注出來的。所以行業里經常開玩笑說，人工智能，就是“有多少人工，就有多少智能”，也因為海量數據標注的需求，還誕生了一個新職業——“人工智能訓練師”。

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

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

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

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

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

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

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

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

因為市場需求的爆發，數據標注行業涌現了很多初創公司，data.forge就是其中一家，其創始人兼CEO楊洋向《九章智駕》介紹道：客戶最關心的是質量/價格比，為了提升質量/價格比，他們采取了很多措施，比如自動化輔助標注，還有優化標注工具的便利性，這也形成了公司的核心競爭力。

華為內部人員向《九章智駕》介紹時，提到“華為八爪魚”也提供數據標注服務：“首先，‘華為八爪魚’花了很多時間打磨自己的預標注算法，目前華為的預標注算法精度已經達到領先水平，在nuScenes、COCO、KITTI等多個自動駕駛國際公開數據集測試挑戰中獲得第一，預標注算法可以大幅減少每框數據標注所需的時間。

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

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

“最后，為了解決本土開源數據集不足的問題，‘華為八爪魚’除了能夠給客戶提供增量的數據標注服務外，還可為客戶提供2000萬個已標注的對象，而且這個數據集是持續迭代、持續擴充的，客戶可以利用這些數據進行訓練，快速地搭建起模型。”

三、仿真——自動駕駛開發的加速器  

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

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

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格式。據業內人士透露：“某些仿真軟件公司想把所有的環節掌握在自己手里，讓自己具有不可替代性，讓客戶綁定在自己身上，想換也換不了。這也是以前一些做仿真測試的巨頭的慣用的手段。但車企肯定是不能接受的，他們非常不想被綁架，希望做到標準化，減少遷移成本?！碑吘共恢С諳penX的還是少數，從整體來看，標準化是大勢所趨。相信隨著標準化的推進，不久后不同軟件之間的文件兼容將不再是問題。

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

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

（1）合規性問題

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

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

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

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

（2）復雜場景精度問題

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

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

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

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

（3）動態更新問題

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

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

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

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

四、上云 還是 不上云，這是一個問題

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%，交通物流、制造等傳統行業云計算應用水平正在快速提高。相信接下來，隨著車企對云計算的認識加深和數字化轉型的進程加快，對上云的接受度也會越來越高。在不久的將來，上不上云，或許也不再是一個問題。

五、工具鏈的發展趨勢

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?！叭A為八爪魚”內部人員介紹道： 如果采用各家公司離散的工具鏈方案，光調試鏈路，可能要花幾個月的時間，而“華為八爪魚”，已經針對整個鏈路做好了集成和適配，減少了重復工作，此外華為還提供給客戶一套參考算法，客戶可以在此基礎上調試優化，大大降低了上手的難度，最快只需要幾天就可以跑通整個完整鏈路，效率很高。

2.開放：各模塊解耦

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

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

據華為內部人員介紹，“華為八爪魚”的工具鏈分為數據、訓練、仿真、監管四部分，這四部分完全開放解耦、不綁定，客戶隨時可以替換。 

3.合作方式更靈活

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

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

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

六、總結

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

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

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

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

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