采集車除了用戶自己的系統(tǒng)外還有大量的采集及支持設(shè)備。對于一個復(fù)雜的系統(tǒng)來說，保持穩(wěn)定運(yùn)行是一項(xiàng)異常復(fù)雜的任務(wù)。由于采集車數(shù)量眾多，部署大量的技術(shù)人員進(jìn)行維護(hù)成本非常高，通常都是一人多車的結(jié)構(gòu)，因此為車上系統(tǒng)提供自動化及網(wǎng)絡(luò)化的集成方案是一個必選項(xiàng)。在設(shè)備擴(kuò)展方面，Vector提供時間同步服務(wù)和數(shù)據(jù)記錄擴(kuò)展接口，可以將用戶的In-house方案以及第三方設(shè)備集成到CANape的環(huán)境中，形成一個“簡潔”的應(yīng)用。

實(shí)車數(shù)據(jù)應(yīng)用背景

01

目標(biāo)

采集實(shí)車數(shù)據(jù)的最終目的是服務(wù)于研發(fā)或者測試，數(shù)據(jù)消費(fèi)的核心是利用算法支持和推動算法的快速迭代，而數(shù)據(jù)消費(fèi)系統(tǒng)可以為算法運(yùn)行和調(diào)試提供便捷的環(huán)境，但是大多數(shù)情況下我們會在消費(fèi)系統(tǒng)的構(gòu)建上花費(fèi)大量的時間。例如：構(gòu)建文件接口、對齊數(shù)據(jù)的時間、測定數(shù)據(jù)質(zhì)量、數(shù)據(jù)匿名化等。缺乏“標(biāo)準(zhǔn)”的數(shù)據(jù)消費(fèi)系統(tǒng)，會導(dǎo)致工程師不停地開發(fā)和維護(hù)多個數(shù)據(jù)消費(fèi)系統(tǒng)，這種情況在多個項(xiàng)目并行開發(fā)時尤為明顯，不僅消耗大量的時間，且產(chǎn)出（迭代效率）很低。因此要想達(dá)到數(shù)據(jù)閉環(huán)的效果就需要大量的標(biāo)準(zhǔn)化工作，而減少非核心環(huán)節(jié)上的消耗，將核心資源放在迭代和改進(jìn)算法上，平衡與整合自研與商業(yè)工具鏈，這往往需要從時間、資金、人力等多個維度綜合考量。

Vector工具鏈在具備標(biāo)準(zhǔn)性的同時，保持對用戶的各種場景提供開放性支持，例如數(shù)據(jù)采集系統(tǒng)框架、數(shù)據(jù)可視化、自動化、文件IO等，用戶可以基于自己的流程和認(rèn)知進(jìn)行靈活擴(kuò)展和整合，快速構(gòu)建起穩(wěn)定、高效的實(shí)車數(shù)據(jù)消費(fèi)鏈。

圖1：CANape實(shí)車擴(kuò)展應(yīng)用

02

一般用戶訴求

用戶在構(gòu)建數(shù)據(jù)消費(fèi)鏈時的訴求，可能包括：私有化數(shù)據(jù)的落盤方案、多系統(tǒng)多時域的整合、采集車網(wǎng)絡(luò)化自動化、數(shù)據(jù)物流與實(shí)時數(shù)據(jù)傳輸、數(shù)據(jù)質(zhì)量控制、數(shù)據(jù)管理、配置工程管理、數(shù)據(jù)消費(fèi)業(yè)務(wù)構(gòu)建及部署、數(shù)據(jù)生命周期及復(fù)用技術(shù)等。

本質(zhì)上可以將數(shù)據(jù)生命周期簡單劃分為：

>

車端數(shù)據(jù)收集

>

數(shù)據(jù)流轉(zhuǎn)（物流及實(shí)時傳輸）

>

數(shù)據(jù)中心構(gòu)建及數(shù)據(jù)消費(fèi)業(yè)務(wù)整合

>

復(fù)用價值開發(fā)

其中每個過程中涉及的流程、技術(shù)及工具跨越比較大，從技術(shù)角度將不同領(lǐng)域人員的開發(fā)能力連接起來是比較困難的，創(chuàng)建必要的橋接流程及工具是構(gòu)建數(shù)據(jù)鏈的核心任務(wù)，畢竟鏈路構(gòu)成的穩(wěn)定性和效率在連接，而不在節(jié)點(diǎn)本身。

03

數(shù)據(jù)格式選擇

測量信號值是許多應(yīng)用的一項(xiàng)基本任務(wù)。大多數(shù)試驗(yàn)需要對獲取的信號同時進(jìn)行處理、顯示和存儲，測量過程同時也需要與工程師進(jìn)行前端交互，以達(dá)到敏捷閉環(huán)，針對后端的數(shù)據(jù)消費(fèi)及閉環(huán)做好充足的準(zhǔn)備。汽車應(yīng)用中，典型信號包括傳感器數(shù)據(jù)、ECU內(nèi)部變量/狀態(tài)、車輛網(wǎng)絡(luò)中的總線報文或內(nèi)部計算值等。

一般在選擇記錄數(shù)據(jù)格式時，需要考慮以下幾個方面：

>

數(shù)據(jù)的屬性關(guān)聯(lián)；

>

數(shù)據(jù)的讀寫要求；

>

數(shù)據(jù)的體積

這些特征間接決定了數(shù)據(jù)記錄及消費(fèi)的總體成本（時間成本和資金成本）。

MDF本質(zhì)是一個數(shù)據(jù)容器，支持?jǐn)?shù)據(jù)的版本族信息寫入，支持信號的定義甚至信號定義的文件寫入，甚至支持坐標(biāo)系信息、安裝數(shù)據(jù)等一些額外信息寫入。如果沒有上述特征的支持，那么需要保存為多份文件，而文件關(guān)系本質(zhì)上是離散的且難以管理的，這些會給后面的數(shù)據(jù)管理和消費(fèi)帶來額外的開發(fā)負(fù)擔(dān)。

在當(dāng)前的業(yè)務(wù)場景中經(jīng)?？吹?，高速大帶寬的數(shù)據(jù)寫入需求，同時又看到數(shù)據(jù)消費(fèi)環(huán)節(jié)要求的快速數(shù)據(jù)索引和數(shù)據(jù)提取，本質(zhì)上這些要求都是相互矛盾的。通常的文件格式的性能特點(diǎn)要么是支持高速并發(fā)（亂序）寫入，要么是支持高性能索引（有序）讀取，而MDF為了滿足這兩方面要求，采用了數(shù)據(jù)塊鏈表結(jié)構(gòu)，在寫入時支持亂序?qū)懭?，在讀取時支持快速重排序來保證高性能的索引及讀取，如圖2所示。

圖2：摘自ASAM–MDF特征描述文獻(xiàn)

MDF（Measurement Data Format）是一種二進(jìn)制文件格式，用于存儲記錄測量或計算的數(shù)據(jù)，便于測量后處理、離線評估或長期存儲。作為ASAM收錄的數(shù)據(jù)文件格式標(biāo)準(zhǔn)，被廣泛應(yīng)用于測量和標(biāo)定領(lǐng)域。MDF同時也支持無損數(shù)據(jù)壓縮，第三方的數(shù)據(jù)序列化結(jié)果也可以直接存儲在MDF的數(shù)據(jù)塊中，例如：Protobuf、CDR、BSON等，甚至聲音、視頻這類數(shù)據(jù)也可以有損或者無損的存放在MDF中。這些特性可以很好的平衡存儲與計算的資金成本。

圖3：MDF數(shù)據(jù)的特征與優(yōu)勢

除此之外，在汽車領(lǐng)域常用的還有很多數(shù)據(jù)格式，例如：總線數(shù)據(jù)格式BLF、以太網(wǎng)數(shù)據(jù)格式PCAP，以及各種數(shù)據(jù)庫格式（DBC、A2L、ARXML等），仍具有各自的應(yīng)用場景。

構(gòu)建消費(fèi)鏈

01

采集車網(wǎng)絡(luò)化及自動化

通常站在駕駛員的視角，希望啟動系統(tǒng)只需要一個按鈕，然后等待系統(tǒng)回復(fù)是否可以開始駕駛。站在車上系統(tǒng)開發(fā)和維護(hù)人員的角度，希望系統(tǒng)所有的功能都可以按照設(shè)置條件自動執(zhí)行，反饋并記錄所有的細(xì)節(jié)，用于異常時的技術(shù)排查。站在更高的層面上，還有車隊(duì)管理系統(tǒng)、數(shù)據(jù)看板系統(tǒng)等，因此希望車輛將必要的信息反饋回來獲取車輛狀態(tài)及任務(wù)進(jìn)度，為決策提供更多的統(tǒng)計支撐。

CANape作為車載的核心軟件之一為這類需求提供了必要的橋接能力。CANapeAPI是一個自動化接口，可以使用該接口實(shí)現(xiàn)一鍵自檢和啟動，同時也可以使用該接口將必要的狀態(tài)信息實(shí)時傳遞到用戶前端及監(jiān)測系統(tǒng)端。圖4是一個網(wǎng)絡(luò)調(diào)用的實(shí)例，展示了如何驅(qū)動CANape載入工程運(yùn)行腳本，控制測量的能力。實(shí)際上CANapeAPI提供非常豐富的功能。

圖4：CANape網(wǎng)絡(luò)調(diào)用實(shí)例

02

物流及實(shí)時傳輸

應(yīng)用場景一：在日均TB級的數(shù)據(jù)生產(chǎn)環(huán)境中，網(wǎng)絡(luò)傳輸?shù)臅r效性和成本無法被行業(yè)用戶接受，因此數(shù)據(jù)物流成為用戶的必然選擇。Vector的工控機(jī)提供磁盤陣列及Copy系統(tǒng)，減少用戶對數(shù)據(jù)記錄、存儲和轉(zhuǎn)移的焦慮。

應(yīng)用場景二：在數(shù)據(jù)驅(qū)動的模式下，如何快速定位“價值”數(shù)據(jù)，讓實(shí)時數(shù)據(jù)傳輸也成為必然的選項(xiàng)。由于傳輸能力的限制，存在兩種不同的價值挖掘方法：

>

先篩后傳：將篩選后的有限數(shù)據(jù)實(shí)時傳輸?shù)綌?shù)

據(jù)中心，數(shù)據(jù)中心的應(yīng)用實(shí)時完成信息的定位

和提??；

>

先傳后篩：車載工控機(jī)將“大數(shù)據(jù)”全部運(yùn)輸至

“云端/數(shù)據(jù)中心”，云端部署數(shù)據(jù)挖掘相關(guān)應(yīng)用；

CANape和vSignalyzer分別提供在線和離線的數(shù)據(jù)挖掘功能，傳輸接口（SL-API）和云服務(wù)（Team Service）等提供多種組件和接口，可以幫助用戶搭建其上述兩種應(yīng)用場景。

03

數(shù)據(jù)中心構(gòu)建及數(shù)據(jù)消費(fèi)業(yè)務(wù)整合

Vector提供SaaS服務(wù)，有多種應(yīng)用可以選擇，能夠在公有云和混合云上為用戶提供快速落地的解決方案，從軟件角度快速連接車端和臺架端，幫助數(shù)據(jù)中心快速建立。

對于數(shù)據(jù)消費(fèi)業(yè)務(wù)，最大的壁壘在于打通本地的數(shù)據(jù)消費(fèi)應(yīng)用如何部署在服務(wù)器端，主要原因是人員知識背景和工程經(jīng)驗(yàn)之間的差異。因此，提供一個“標(biāo)準(zhǔn)”樣式，既適合本地端又適合服務(wù)端的框架，會讓這個工作變得更容易推動。它不應(yīng)挑戰(zhàn)用戶的技術(shù)背景和知識體系，且應(yīng)該足夠簡單，不需要讓用戶學(xué)習(xí)太多與專業(yè)無關(guān)的知識與技能，這是一項(xiàng)技術(shù)能夠快速被目標(biāo)用戶接受的前提。

Vector提供多種行業(yè)主流的記錄格式讀寫庫，例如：MDFlib、BLF等。但是直接使用這些庫，需要用戶了解格式的技術(shù)內(nèi)容才能有效使用。Vector項(xiàng)目團(tuán)隊(duì)以眾多項(xiàng)目經(jīng)驗(yàn)為基石，對工具鏈進(jìn)行封裝，實(shí)現(xiàn)了接口代碼的自動化，方便用戶直接獲取所需信息。同時根據(jù)數(shù)據(jù)消費(fèi)業(yè)務(wù)的形式，按照DataFlow的風(fēng)格抽象了數(shù)據(jù)處理的接口（如圖5所示），方便用戶開發(fā)風(fēng)格統(tǒng)一的消費(fèi)組件，便于業(yè)務(wù)層復(fù)用、本地開發(fā)和服務(wù)端部署。

圖5：DataFlow模塊化設(shè)計

如圖6所示，這是一個模塊化圖像處理的實(shí)際案例，用戶在后端提供了所有模塊的Python代碼，實(shí)現(xiàn)了“MDF讀取數(shù)據(jù)→檢查圖像質(zhì)量→輸出JPG圖片”的業(yè)務(wù)功能，還可以在前端重新組裝業(yè)務(wù)。

圖6：模塊化設(shè)計應(yīng)用實(shí)例

04

Vector提供的支持

如圖7所示，針對整個數(shù)據(jù)消費(fèi)鏈，Vector提供多種標(biāo)準(zhǔn)化工具幫助用戶快速搭建數(shù)據(jù)采集、管理、應(yīng)用等模塊，使用戶能夠集中精力聚焦核心業(yè)務(wù)。

圖7：數(shù)據(jù)消費(fèi)鏈?zhǔn)疽鈭D

本篇文章技術(shù)內(nèi)容所依賴的Vector標(biāo)準(zhǔn)工具，包括：

>

CANape - 用于測量與標(biāo)定的標(biāo)準(zhǔn)上位

機(jī)軟件

>

vMDM - 用于數(shù)據(jù)管理的服務(wù)器/客戶

端軟件

>

vAnonymize - 用于數(shù)據(jù)脫敏的匿名化

工具軟件

>

Team Service - 用于云端管理數(shù)據(jù)/工

程的云服務(wù)

>

MDF4 Lib - 用于讀寫MDF數(shù)據(jù)操作

數(shù)據(jù)流的商用庫接口，包括單機(jī)/服務(wù)器

和Windows/Linux版本

如有相關(guān)技術(shù)需求和興趣，

歡迎聯(lián)系我們，我們將竭誠為您答疑。