2.  車云一體計(jì)算架構(gòu)的設(shè)計(jì)

車云一體的基本概念，是車端與云端之間基于 SOA 的設(shè)計(jì)思想以服務(wù)化的方式通信的軟件架構(gòu)。車內(nèi)各 ECU 的服務(wù)抽象 ( 如車門開關(guān) ) 與云端服務(wù)能力 ( 如生態(tài)服務(wù) ) 通過統(tǒng)一的服務(wù)化協(xié)議完成車與云之間服務(wù)的自由調(diào)度，充分發(fā)揮整車各傳感器 / 執(zhí)行器與云平臺服務(wù)能力組合帶來的場景化優(yōu)勢，從而支撐 OEM 構(gòu)建海量個(gè)性化的智能應(yīng)用場景，車云一體計(jì)算架構(gòu)如下圖 4.3-2 所示：

圖4.3-2 車云一體計(jì)算架構(gòu)

    全棧邊緣計(jì)算 + 大數(shù)據(jù)架構(gòu)：

• 車云一體的數(shù)據(jù)結(jié)構(gòu) + 序列化 + 語法編譯器 + 流算子 + 算法解析器 + 執(zhí)行計(jì)劃優(yōu)化器，支持同數(shù)據(jù)同計(jì)算結(jié)果

• 執(zhí)行器屏蔽跨平臺資源調(diào)度與信號接入之間的差異

  
  

  高層語法支撐動態(tài)車內(nèi)加載部署：

  
  

• 算法 = 多算子組合的文本描述，車云算子一致

• 流算子、動態(tài) plugin 加載、在整車測試集成過程測試驗(yàn)證

• 算法更新下發(fā)文本描述即可，監(jiān)測算法文件更新后可自動生成可執(zhí)行對象線程

  
  

  面向生態(tài)的算法開發(fā)靈活性：

  
  

• 開發(fā)者工具拖拉拽，云上測試即可，無需整車長時(shí)間周期成本

• 完善可組合的數(shù)據(jù)處理，信號，特征，機(jī)器學(xué)習(xí)等算子模型

• 與 FOTA 集成，靈活更新，按需計(jì)算，互聯(lián)網(wǎng)級別的迭代速度

  
  

  車云一體的計(jì)算架構(gòu)對于 OEM 的價(jià)值：

(1) OEM 個(gè)性化智能場景的支撐

基于車云一體架構(gòu)帶來的服務(wù)化基礎(chǔ)能力，實(shí)現(xiàn)車云 SOA 服務(wù)的高效穩(wěn)定、協(xié)調(diào)工作，充分開發(fā)車輛硬件能力實(shí)現(xiàn)最大化功能和出行場景智能化，構(gòu)建更貼近使用場景的智能化以及跨域創(chuàng)新組合的場景化應(yīng)用。

(2) 云端與整車級系統(tǒng)聯(lián)動能力的提升

一套車云同構(gòu)的計(jì)算框架，意味著工程師無需在 C/C++、Java，Scala、Python 等云端不同語言間來回切換移植，即可實(shí)現(xiàn)算法功能云端與車端的無縫銜接；因此，云端對于整車級數(shù)據(jù)采集、遠(yuǎn)程診斷 / 標(biāo)定、整車 OTA 等都可以通過服務(wù)化協(xié)議實(shí)現(xiàn)動態(tài)策略的能力提升。

(3) 支持新場景的快速迭代

基于車 / 云服務(wù)化的封裝可以通過工具化、圖形化、流程化的方式支撐新的功能場景的快速開發(fā)，面向不同技術(shù)背景人員也能夠通過場景的企劃設(shè)計(jì)，快速地完成制作。

(4) OEM 生態(tài)構(gòu)建與服務(wù)運(yùn)營支撐

相比于傳統(tǒng)的車聯(lián)網(wǎng)服務(wù)運(yùn)營模式，車云一體帶來的智能化的體驗(yàn)，將整車能力和互聯(lián)網(wǎng)生態(tài)緊密的連接；另外，對于第三方開發(fā)者的能力開放，相比車機(jī)聯(lián)網(wǎng)模式帶來更多的能力提升，支撐更多智能化應(yīng)用場景的價(jià)值創(chuàng)造，幫助 OEM 構(gòu)建自己的軟件服務(wù)生態(tài)，使軟件收益成為 OEM 全新的商業(yè)模式。

3.  車端結(jié)構(gòu)化數(shù)據(jù)管理

由于車端結(jié)構(gòu)化數(shù)據(jù)大多是高頻率、連續(xù)的的信號數(shù)據(jù)，且單車的信號量較大，對于數(shù)據(jù)系統(tǒng)的寫入、存儲、計(jì)算能力都有較大挑戰(zhàn)。在車端數(shù)據(jù)管理系統(tǒng)的設(shè)計(jì)思路上，應(yīng)當(dāng)以一個(gè)時(shí)序的、嵌入式的數(shù)據(jù)庫的方式來應(yīng)對，且應(yīng)當(dāng)具備以下關(guān)鍵特性：

·  信號以列存儲：信號數(shù)據(jù)因?yàn)槲锢碓O(shè)計(jì)有天然的變化規(guī)律，在高質(zhì)量采集下這些信號數(shù)值的詳細(xì)變化過程可以被精準(zhǔn)的識別，而且有數(shù)千個(gè)的時(shí)候以單信號列來存儲的格式將比傳統(tǒng)以報(bào)文條的行存儲格式有更高的壓縮率。

·  以流壓縮算法平攤 CPU 消耗：車端對于服務(wù)使用 CPU 的穩(wěn)定性非常關(guān)注。一是邊緣資源有限， 二是全局壓縮算法容易造成壓縮時(shí) CPU 峰值飆高，這時(shí)候如果其他服務(wù)也出現(xiàn) CPU 使用飆高造成超過警戒線，對于整個(gè) E/E 架構(gòu)的服務(wù)優(yōu)先級管理來講很難處理。設(shè)計(jì)上應(yīng)當(dāng)考慮對 CPU 消耗的平緩占用，避免劇烈波動。

·  帶公式自描述：傳統(tǒng)數(shù)采格式 BLF/ASC 需要配套對應(yīng)車型和版本的 DBC 才能解析，但在現(xiàn)實(shí)量產(chǎn)環(huán)境中，不同車輛的信號矩陣版本都可能不一樣，實(shí)際車端可能和云端記錄也不一樣，諸如此類的問題會讓車輛數(shù)據(jù)解析非常復(fù)雜。傳統(tǒng)車聯(lián)網(wǎng)以 JSON 格式上傳數(shù)值，JSON 靈活但文本格式導(dǎo)致上傳包 / 流量非常大。設(shè)計(jì)上應(yīng)當(dāng)借鑒 MDF 格式帶公式自描述的理念，支持如線性、多項(xiàng)式等超過 8 種公式嵌在列存儲元數(shù)據(jù)里，具有支持多種計(jì)算轉(zhuǎn)換。使得數(shù)據(jù)包到云端時(shí)無需尋找DBC 版本比對、所有數(shù)據(jù)包自解析等功能。

·  支持高精度采集：系統(tǒng)應(yīng)當(dāng)能夠支持 10ms 精度以上，上萬個(gè)信號的數(shù)據(jù)的寫入，同時(shí)能將車端的不同協(xié)議按照統(tǒng)一的規(guī)則排序以列進(jìn)行存儲。

·  支持邊緣計(jì)算：系統(tǒng)應(yīng)當(dāng)可以通過在邊緣計(jì)算實(shí)現(xiàn)對數(shù)據(jù)的查詢和處理，并篩選需要的數(shù)據(jù)進(jìn)行上傳，使傳輸?shù)臄?shù)據(jù)都是有價(jià)值的數(shù)據(jù)。一方面控制了數(shù)據(jù)量優(yōu)化了成本，另一方面還大幅減少云端數(shù)據(jù)處理的工作量。

4.  車端非結(jié)構(gòu)化數(shù)據(jù)管理

自動駕駛的數(shù)據(jù)源來自于車身各種傳感器的數(shù)據(jù)，包括車載攝像頭、激光雷達(dá)、毫米波雷達(dá)、超聲波雷達(dá)等感知數(shù)據(jù)；同時(shí)，在這個(gè)場景中還分為自動駕駛路試車數(shù)據(jù)和量產(chǎn)車數(shù)據(jù)兩種區(qū)別較大的數(shù)據(jù)管理方式。

（1）路試車數(shù)據(jù)管理系統(tǒng)

路試車往往采用大容量高算力數(shù)采盒子全量數(shù)據(jù)采集的方案。數(shù)據(jù)落入磁盤后，通過停車后插拔硬盤， 并人工拷貝到對應(yīng)服務(wù)器中。采集量大，數(shù)據(jù)完整。但同時(shí)帶來大量的數(shù)據(jù)整理篩選工作。且數(shù)據(jù)依賴 測試車和測試員，數(shù)據(jù)積累成本高，對于 Corner Case 的輸入效率低。

(2) 量產(chǎn)車非結(jié)構(gòu)化數(shù)據(jù)管理系統(tǒng)

面向量產(chǎn)車的非結(jié)構(gòu)化數(shù)據(jù)采集，無法通過插拔硬盤或者有線傳輸。用 4G/5G 無線回傳需要考慮到流量、算力等成本因素。因此需要在車端進(jìn)行數(shù)據(jù)篩選，盡可能只采集有限的，但高價(jià)值的數(shù)據(jù)。需要一定的邊緣計(jì)算能力和業(yè)務(wù) Know how 儲備。