新背景下的全棧

自動駕駛?cè)珬?，一個狹義的解讀就是：高精地圖、定位、融合、決策、控制都懂的人。在強調(diào)算法/功能的早期階段，是比較common sense的。但隨著量產(chǎn)的節(jié)奏越來越近，只提供純算法解決方案已不能滿足需求。

回過頭看，狹義的解讀圍繞的只是“大系統(tǒng)”中的一個核心模塊：ads core。一個更廣義的“自動駕駛?cè)珬?rdquo;，則涵蓋了更多非功能的模塊/服務(wù)，自動駕駛仿真會覆蓋一些非核心模塊，是比較合適切入“自動駕駛?cè)珬?rdquo;的節(jié)點。

新背景下的自動駕駛仿真“后臺”

一些大廠的自動駕駛仿真后臺在做什么？為什么大廠都會嘗試切入自動駕駛仿真后臺？各家服務(wù)的區(qū)別點在哪里？

騰訊
·  數(shù)據(jù)采集
·  數(shù)據(jù)管理， 定義數(shù)據(jù)接口，數(shù)據(jù)dashboard，同時接入騰訊云(存儲/計算)
·  數(shù)據(jù)應(yīng)用，數(shù)據(jù)診斷、 ads core迭代
·  回歸測試，數(shù)據(jù)注入仿真引擎
·  仿真kpi

cognata/經(jīng)緯恒潤
·  場景庫, 在線編輯、第三方導(dǎo)入
·  仿真引擎，包括場景生成、交通流、傳感器模型、車輛動力學(xué)模型、仿真評價系統(tǒng)。實現(xiàn)熱插拔，所述模塊都可以通過sdk導(dǎo)入引擎，配置非常靈活，配置ui也非常美觀。單從用戶操作上，是體驗和設(shè)計感最好的一款吧。
·  數(shù)據(jù)kpi分析

百度
·  vehicle log
·  場景集合，實現(xiàn)場景重現(xiàn)、動態(tài)參與物、自車manuver提取
·  仿真引擎，基本模塊都類似，也定義了自己的場景評價系統(tǒng)。分別對理想完美仿真和真實數(shù)據(jù)回放定義了：worldsim，logsim。是國內(nèi)有產(chǎn)品也有工具鏈的團隊。主觀感受比騰訊靠譜。

華為
·  數(shù)據(jù)采集，華為的（tbox)硬件方案
·  數(shù)據(jù)傳輸, 華為的5g車路協(xié)同網(wǎng)絡(luò)
·  數(shù)據(jù)處理
·  dashboard， 定義 corner case, 場景統(tǒng)計，回放等功能
·  數(shù)據(jù)接口，可以接AI訓(xùn)練、仿真、以及第三方(政府、保險)等

如上，百度、華為、騰訊，還有阿里、滴滴、美團等，大廠都較快的基于其”大后臺“去構(gòu)建/拓展了自動駕駛仿真流程。大廠的優(yōu)勢是，軟件棧，包括中間件、大數(shù)據(jù)、AI等棧都是ready-to-go的，云服務(wù)也是成熟的。而且大廠都有意識打通各個業(yè)務(wù)模塊(AI、算法模型、仿真等），沒有孤島。其實想想，騰訊沒幾輛自動駕駛車，可以快速推出一套自動駕駛仿真PaaS，可想其中多少是源自自動駕駛業(yè)務(wù)需求，而多少是源自騰訊在游戲領(lǐng)域的積累和成熟。

各家的仿真PaaS所提供的服務(wù)/功能都很類似。最定制化的細節(jié)，都是在業(yè)務(wù)中反復(fù)實踐出來的。傳統(tǒng)汽車主機廠，缺乏成熟可用的”大后臺“積累，各個組件相對孤立的。一方面是可以考慮購買大廠基于自家公有云的PaaS服務(wù)，但難免跟原來的開發(fā)實踐不能很好的融合。引入了一些新問題。另外，就是迅速轉(zhuǎn)變，提高自己“大后臺”構(gòu)建的能力。

我們需要什么技術(shù)棧

大廠里面對“大后臺”有不少成熟的實踐了。諸如，微服務(wù)，DevOps。各家也有不少開源的框架、中間件。下面可以從自動駕駛仿真的幾個環(huán)境，簡單總結(jié)下所依賴的技術(shù)棧。

場景庫

真實數(shù)據(jù)在自動駕駛領(lǐng)域場景的使用包括：數(shù)據(jù)服務(wù)，包括大數(shù)據(jù)挖掘、傳感器驗證、數(shù)據(jù)診斷等；仿真服務(wù)，生成場景，即建立場景庫；AI訓(xùn)練

對于生成場景，技術(shù)棧主要圍繞真實數(shù)據(jù)解構(gòu)展開，包括清洗、分類、標(biāo)簽、入庫、檢索、回放、數(shù)據(jù)可視化、數(shù)據(jù)資源url訪問、真值系統(tǒng)計算等。

需求層面的細節(jié)問題較多，諸如，數(shù)據(jù)如何采集、采集車隊管理監(jiān)控、數(shù)據(jù)如何回傳本地數(shù)據(jù)中心/遠程數(shù)據(jù)中心、數(shù)據(jù)格式、存儲系統(tǒng)(nfs, ceph, s3)、數(shù)據(jù)備份恢復(fù)、數(shù)據(jù)安全等。

也有一些很大廠的技術(shù)實踐：大規(guī)模圖片數(shù)據(jù)分布式存取的緩存設(shè)計，大數(shù)據(jù)io的批處理設(shè)計，基于AI的場景推理/提取/生成等技術(shù)(roman roads)。

實現(xiàn)上述場景業(yè)務(wù)需要的“大后臺”包括：分布式數(shù)據(jù)存儲訪問、數(shù)據(jù)庫、web服務(wù)開發(fā)、數(shù)據(jù)可視化、數(shù)據(jù)接口設(shè)計、服務(wù)監(jiān)控管理、包括分布式運維等。

仿真引擎

引擎的開發(fā)，在前面提到了很多，cognata的實踐是很好的參考。需要強調(diào)，仿真引擎的評價能力，尤其對于自動化測試，非常需要；sdk接口的設(shè)計，對ads core一般采用ros協(xié)議，對第三方動力學(xué)一般采用fmi；對數(shù)據(jù)注入的支持，也逐漸成為考量仿真引擎的指標(biāo)。

還有一類仿真引擎，更像是數(shù)據(jù)批處理業(yè)務(wù)：數(shù)據(jù)回放，然后分析，統(tǒng)計。

這些業(yè)務(wù)需要的“大后臺”包括：分布式DevOps, docker 化，運行管理k8s、工作狀態(tài)監(jiān)控、任務(wù)/消息隊列、配置管理、數(shù)據(jù)接口、通信協(xié)議、數(shù)據(jù)流業(yè)務(wù)緩存、批處理等。

KPI

數(shù)據(jù)呈現(xiàn)、回放、問題診斷、corner case分析提取、評價指標(biāo)統(tǒng)計等。需要的“大后臺”包括：大數(shù)據(jù)套件、數(shù)據(jù)可視化套件等。

開發(fā)階段。在傳統(tǒng)主機廠的v-型開發(fā)思路下，引入一些agile的思想：快速迭代，持續(xù)集成，持續(xù)部署。采用gitlab/jekins/jira等DevOps生態(tài)，打通生產(chǎn)環(huán)境中的各個節(jié)點。通過快速試錯，小步快跑，最終給用戶提供持續(xù)的小驚喜。特斯拉就是這樣子嘛。當(dāng)然，最難的是改變團隊的文化。扁平化管理、提高個人主觀能動性、提倡分享、充分信任等等。

量產(chǎn)階段。在量產(chǎn)階段，需要的“后臺”是車-云方案。仍然要解決：車端數(shù)據(jù)收集、數(shù)據(jù)診斷、系統(tǒng)(仿真)驗證等，在研發(fā)階段的數(shù)據(jù)鏈路，仍然是有效的。但是，規(guī)模成本、系統(tǒng)穩(wěn)定性、用戶可用性等因素也必將考量，需要更深的后臺技術(shù)棧。

總結(jié)

從“狹義全棧“自動駕駛到“廣義全棧”，圍繞核心功能模塊，拓展了更多外圍非功能模塊/服務(wù)。強調(diào)“大后臺”并不是簡單的邯鄲學(xué)步：把互聯(lián)網(wǎng)的成熟經(jīng)驗簡單套用到自動駕駛的開發(fā)運維上。而是自動駕駛發(fā)展到了一個需要全盤規(guī)劃非功能性業(yè)務(wù)的階段了。在當(dāng)今的微服務(wù)架構(gòu)下，強調(diào)可用性，高拓展性，這樣的推進是自然又必然的。另外，數(shù)據(jù)驅(qū)動的自動駕駛隊伍，也會越來越加強“后臺”的建設(shè)。