陸林　熊珂

摘 要：為了在競爭日益激烈的汽車市場上取得成功，汽車制造商必須高度響應消費者的需求，并進一步加快新樣車的設計驗證周期。通過收集網(wǎng)聯(lián)車輛的用戶駕駛數(shù)據(jù)，促進數(shù)據(jù)驅(qū)動的試驗認證，可以滿足客戶不同駕駛習慣的需求，但測試工程師面臨著利用用戶駕駛大數(shù)據(jù)的挑戰(zhàn)。這促使一個專門的道路試驗大數(shù)據(jù)分析系統(tǒng)的提出，為工程師獲得對關聯(lián)用戶駕駛的整車道路實驗提供有效途徑。該系統(tǒng)不僅屏蔽了工程師操縱大數(shù)據(jù)的技術(shù)障礙，而且還幫助他們通過有指導的數(shù)據(jù)科學過程挖掘有價值的信息。該系統(tǒng)已被一些汽車工程師實際用于他們的道路試驗用例，肯定了其靈活即用的功能和令人印象深刻的效率。

關鍵詞：道路試驗 大數(shù)據(jù) 用戶關聯(lián)

1 引言

整車道路試驗（Vehicle Road Test， VRT）[1]是指在公共/測試道路上進行一定強度的預生產(chǎn)車輛駕駛操作，以評估車輛的設計功能和性能。VRT與仿真測試相比，具有更強的客觀優(yōu)勢，通常被認為是原型車輛距離交付市場階段的“最后一公里”。未關聯(lián)用戶的VRT可能導致某些子系統(tǒng)的過度設計或者欠設計[2]。這是由于消費者對主機廠過去售出車輛的使用信息未能有效向車輛研發(fā)與測試工程師反饋的結(jié)果。故朱佳琦[3]提出了基于用戶使用數(shù)據(jù)分析的整車道路試驗優(yōu)化方案，江毓等人[4]提出了一種關聯(lián)用戶使用情況的相對合理的試驗場整車耐久性試驗方案。用戶關聯(lián)的VRT可用于測試認證規(guī)范的制定，以發(fā)現(xiàn)和消除潛在的設計缺陷，從而減少售后索賠和召回成本。

車聯(lián)網(wǎng)[5][6]允許從開放道路上運行的車輛中收集車輛參數(shù)，為關聯(lián)用戶駕駛提供了數(shù)據(jù)收集渠道。然而，隨著長期和高頻的數(shù)據(jù)積累，研發(fā)工程師正面臨著處理大數(shù)據(jù)的挑戰(zhàn)。利用大數(shù)據(jù)技術(shù)可以為汽車行業(yè)提供轉(zhuǎn)型的機會。2014年初，Johanson Mathias等人[7]開發(fā)了一個大數(shù)據(jù)框架，以探索利用汽車大數(shù)據(jù)進行知識驅(qū)動的產(chǎn)品開發(fā)。龔蓉軍[8]開發(fā)了一個針對道路試驗的數(shù)據(jù)平臺，使用Hadoop、Hive和Spark工具實現(xiàn)數(shù)據(jù)收集、存儲、分析和報告展示。然而，當將大數(shù)據(jù)技術(shù)應用于VRT領域時，以往的系統(tǒng)忽略了領域?qū)＜业膶W習成本，導致可用性體驗較差。更糟糕的是，沒有定制的分析組件來整合領域知識并協(xié)助業(yè)務專家應用到具體的案例級分析。

本文的目標是設計和實現(xiàn)一個大數(shù)據(jù)科學指導的VRT系統(tǒng)以屏蔽大數(shù)據(jù)的復雜性，使用戶能夠直觀地探索、分析和可視化數(shù)據(jù)。如圖1所示，該系統(tǒng)扮演著利用大數(shù)據(jù)科學指導工程師進行關聯(lián)分析的最后一公里的角色，為關聯(lián)用戶駕駛的道路試驗分析提供更直觀的信息挖掘過程。

2 系統(tǒng)概述

圖2為該系統(tǒng)的技術(shù)架構(gòu)，其將整個系統(tǒng)分為三層架構(gòu)：

大數(shù)據(jù)平臺層。我們選擇了Hadoop、Spark、Oozie用于分布式數(shù)據(jù)存儲、計算和作業(yè)調(diào)度。該平臺基于Spark SQL和ML來執(zhí)行分析操作。Spark的數(shù)據(jù)源是存儲在HDFS文件系統(tǒng)上的汽車傳感器數(shù)據(jù)。然后，選擇Oozie工作流調(diào)度器來調(diào)度特定作業(yè)（如Scala Spark程序和Pyspark腳本）。一旦后端服務提交了一個Spark作業(yè)，這個作業(yè)將立即被發(fā)送到相應的Oozie調(diào)度器。這個平臺層主要用于探索和分析從全國客戶處收集的大量真實駕駛數(shù)據(jù)。

混合服務層。中間層是一個混合的Java和Python服務，用于本地和集群計算，實現(xiàn)自動和智能的數(shù)據(jù)驅(qū)動分析。在我們的設計中，提供了兩種后端服務?；赑ython的分析（Python-based Analysis， PA）和基于Java的分析（Java-based Analysis， JA）服務。PA服務可以提交Spark分布式作業(yè)，也可以用本地進程服務處理本地數(shù)據(jù)。這個由Flask提供的本地進程服務結(jié)合了pandas和scikit-learn等軟件包，用于提供快速統(tǒng)計或機器學習API。同樣，JA服務也有兩個分支，其本地進程服務在處理其他事務性功能方面具有優(yōu)勢。在某些情況下，本地數(shù)據(jù)分析仍然是必要的，測試工程師希望上傳一個本地MDF文件，傾向于更節(jié)省時間的本地分析。當分析任務返回時，結(jié)果被提交給系統(tǒng)的展示層。這個服務層分別處理來自測試車輛和售出車輛的數(shù)據(jù)樣本的實時計算任務。

展示層。我們選擇使用一個基于web的用戶界面，其采用了React框架實現(xiàn)，并使用Echart插件來繪制圖表。這個展示層能夠?qū)崿F(xiàn)豐富的互動操作和選項，以指導數(shù)據(jù)科學流程。同時，如果定義了一個分析任務，對數(shù)據(jù)進行的分析類型將被記錄。根據(jù)所要求的分析類型，分析任務的結(jié)果可以是不同種類的圖表或圖形，通過基于web的用戶界面進行組合并提供給用戶。

3 系統(tǒng)重點實現(xiàn)描述

該系統(tǒng)從業(yè)務目標的確定，數(shù)據(jù)準備，先樣本后總體分析以得出結(jié)論，最后以web報告的形式可視化四個主要階段輔助工程師快速利用大數(shù)據(jù)手段進行業(yè)務分析。

3.1 業(yè)務目標

VRT分析的一個共同業(yè)務目標是在用性能比（In Use Performance Ratio， IUPR）[9]研究，通常包括：（1）發(fā)動機怠速時長分析；（2）車速持續(xù)時間分析；（3）油門位置From-To分析；（4）油門位置與車速的距離范圍；（5）發(fā)動機停機時間分析。這些案例具有強烈的實際意義，都可以通過我們的系統(tǒng)來實現(xiàn)。

3.2 數(shù)據(jù)準備

該階段將準備一個關于業(yè)務目標的目標數(shù)據(jù)集。首先，測試人員既可以通過JA服務上傳一個本地文件，也可以使用PA服務訪問HDFS文件。無論數(shù)據(jù)集如何添加，它都被稱為VRT域中的總體。然后，后端服務將啟動一個本地或Spark作業(yè)，以獲得關于此總體的摘要以及這個總體的子集。摘要是對數(shù)據(jù)的統(tǒng)計描述（計數(shù)、最小值、平均值等），以及所有信號的缺失值、唯一值情況。先樣本后總體（First Sample Then Population， FSTP）是測試工程師進行IUPR分析的工業(yè)經(jīng)驗。這里的樣本指的就是剛才的子集。

3.2.1 FSTP抽樣策略

對上述大數(shù)據(jù)的一步步操作是很耗時的，用戶的耐心會隨著時間的推移逐漸耗盡。采樣已被證明是處理大數(shù)據(jù)問題的一種有效方式。為了使我們的系統(tǒng)更加友好，我們將首先采樣總體數(shù)據(jù)并將其加載到本地MySQL數(shù)據(jù)庫中。因為動力學片段是測試工程師重點關注的樣本，我們讓采樣過程中除了均勻隨機的方式外，還選擇幾個動力學片段。提取部分動力學片段被稱為線性采樣。

考慮到要分析的整個數(shù)據(jù)集，我們假設由均勻和線性抽樣產(chǎn)生的相對較小的比例可以近似于總體的分布。那么，我們對樣本包含不同參數(shù)的缺失和異常情況就有更大的把握。這樣一來，對樣本的數(shù)據(jù)預處理步驟就可以完全復制到總體數(shù)據(jù)集上，有效避免在樣本上的預處理步驟與總體數(shù)據(jù)集上的不一致問題。在統(tǒng)計上，樣本分布的大小分別取決于置信水平、誤差范圍，分別表示為α、E。令p表示總體采樣比例，根據(jù)公式（1）可計算得到樣本量大小。

其中Zα/2是對應于置信度的Z分數(shù)。在VRT背景下，總體的大小總是已知的，如果是100萬，那么計算出的樣本n只有385。這大大提高了FSTP分析過程的效率。

3.3 FSTP分析

一旦數(shù)據(jù)準備好了，測試人員就可以為特定的用戶群體分析創(chuàng)建一個新的工作臺。相應的分析界面會根據(jù)信號的類型進行分類和顯示，然后列出可選的分析組件。測試人員只需點擊相關的分析組件，將需要分析的信號拖到相應的輸入框中，就會立即計算并顯示該組件對樣本數(shù)據(jù)的分析結(jié)果。

可視化方面，我們提供了一些繪圖組件，如直方圖、散點圖、柱狀圖、折線圖和熱圖。它們可以用于不同的情況，例如，直方圖可以用來檢查汽車的速度分布，折線圖可以用來觀察制動狀態(tài)的變化，熱圖可以顯示發(fā)動機轉(zhuǎn)速和扭矩的使用規(guī)律?？梢暬ㄔ诠こ處熆扇萑虝r間內(nèi)的樣本級分析呈現(xiàn)，和最終總體級別分析結(jié)果的呈現(xiàn)。

通過樣本集上分析可視化，工程師可快速決定數(shù)據(jù)準備和分析邏輯是否是他們所期望的。如果這些操作是它們希望在總體級別上執(zhí)行的操作，則將啟動一個Spark作業(yè)，以分布式的方式進行集群計算。

4 案例研究

在本節(jié)中，我們將以某汽車研究院的某個應用為例進行闡述。該系統(tǒng)導入了基于車載T-BOX從市場用戶車輛采集的各種車載傳感器數(shù)據(jù)。典型的信號包括速度、轉(zhuǎn)向角速度、里程表、轉(zhuǎn)速、制動踏板狀態(tài)、加速度開啟度等。自2019年以來，該大數(shù)據(jù)平臺已經(jīng)存儲了五千多輛汽車的數(shù)據(jù)。平均每天收集1800萬條記錄，容量為3.6GB，數(shù)據(jù)總?cè)萘繛?328GB，其中包括225億條記錄。

在本示例中，工程師A、B和C想要獲得一份關于所有用戶車輛上動力系統(tǒng)極端溫度分布的報告。他們的任務分工為：A進行數(shù)據(jù)準備和電機的極端溫度分布分析，B負責蓄電池的極端溫度分布，C最后匯報報告。

首先，A選擇2019年7月1日在中國全省運行的所有車輛，并選擇所需的信號，即車輛識別號（VIN）、電機和電池溫度。然后，系統(tǒng)根據(jù)用戶的選擇開始數(shù)據(jù)準備任務，獲得相應數(shù)據(jù)集上的描述性統(tǒng)計信息。同時，通過提出的采樣策略，獲得采樣數(shù)據(jù)集并將其存儲在MySQL表中。

上一階段完成后，工程師A可以預覽樣本和相應的描述性統(tǒng)計結(jié)果，以檢查是否存在空值或異常情況。如果數(shù)據(jù)質(zhì)量不好，則將啟動數(shù)據(jù)編輯操作。在編輯階段，A可以選擇刪除或填充空值，并過濾掉相關的值。一旦確定，編輯步驟將被記錄并封裝成一系列的Spark操作，這些操作將提交給Oozie進行任務調(diào)度。用戶可能需要很長時間來等待大數(shù)據(jù)平臺才能完成數(shù)據(jù)編輯階段。數(shù)據(jù)編輯階段是可重復的，用戶可以重復執(zhí)行預覽、探索和編輯操作，直到數(shù)據(jù)質(zhì)量滿足要求。

接下來，以準備好的樣本數(shù)據(jù)作為輸入，A和B可以并行完成他們的分析任務。分析工作臺如圖3所示，在我們的系統(tǒng)中，VIN顯示為一個“維度”，因為它的數(shù)據(jù)類型是字符串；電池和電機溫度信號是數(shù)值類型，所以它被分為“指標”欄。為了完成它們的工作，A和B都應該首先選擇要分析的組件，在示例中是一個多維的條形圖。對于電機部件，A將VIN和電機溫度拖動到相應的輸入箱中。通過點擊電池溫度并選擇所提供的匯總方法中的最大選項，將顯示所有車輛的最大電機溫度的直方圖。需要注意的是，這里給出的結(jié)果仍然是基于樣本數(shù)據(jù)集的。如果樣本集上的顯示結(jié)果是他們想要的，他們保存這個項目。然后提交一個Spark作業(yè)，以對總體執(zhí)行分析過程。完成后，電機和電池部件的結(jié)果圖將共享給C制作最終報告。

通過這份報告，工程師發(fā)現(xiàn)用戶駕駛數(shù)據(jù)中的動力系統(tǒng)溫度分布與零部件供應商提供的溫度分布有所偏差。動力系統(tǒng)溫度是熱管理系統(tǒng)中一些故障的關鍵。因此，研發(fā)人員修改了一些相關測試標準的參數(shù)。

5 結(jié)語

VRT的最終目標不僅是滿足清晰的要求，還要涵蓋用戶的駕駛習慣，提高研發(fā)測試認證與實際使用的相關性，從而減少售后問題和召回成本。然而，該行業(yè)仍沒有完全整合其用于道路試驗，還有很多工作要做。為了應對測試工程師所面臨的大數(shù)據(jù)挑戰(zhàn)，我們提出了一個可視化的大分析系統(tǒng)。它是一個自助服務環(huán)境，支持整個分析周期——整合、準備、分析和可視化。此外，易于使用的界面和即時建模使業(yè)務分析師能夠輕松工作，無需額外的IT協(xié)助。它還可以促進測試數(shù)據(jù)的收集和處理，這些數(shù)據(jù)可以用來更新整個車輛原型，從而減少現(xiàn)實和模擬測試之間的差距。在未來，我們將嘗試涵蓋更多的商業(yè)案例。

參考文獻：

[1]Koopman， P. and Wagner， M.， “Challenges in Autonomous Vehicle Testing and Validation，”SAE Int. J. Trans. Safety 4（1）：15-24，2016，https：//doi.org/10.4271/2016-01-0128.

[2]LI Yu-long，PENG Jian，LI Xin-tian. Failure distribution analysis for vehicle road durability test and customer complaint. Machinery Issue 5，Volume 40 （2013）.

[3]朱佳琦.基于用戶使用數(shù)據(jù)分析的整車道路試驗優(yōu)化方案[J].上海汽車，2017（03）：16-19.

[4]江毓，王驍磊，鄭燕萍，王羽塵.與用戶使用關聯(lián)的整車耐久性試驗方案確定[J].時代汽車，2017，No.282（06）：81-83+85.

[5]Johanson，M.（2011）. Information and communication support for automotive testing and Validation.New Trends and Developments in Automotive System Engineering，473.

[6]趙津，張博，潘霞，謝蓉.車聯(lián)網(wǎng)通信技術(shù)及應用前景研究[J].時代汽車，2021（06）：15-16+32..

[7]Johanson，M.，Belenki，S.，Jalminger，J.，F(xiàn)ant，M.，& Gjertz，M.（2014，October）.Big automotive data： Leveraging large volumes of data for knowledge-driven product development. In 2014 IEEE international conference on big data （Big Data）（pp. 736-741）.IEEE.

[8]龔蓉軍.基于云計算的轎車道路試驗數(shù)據(jù)存儲與分析[D]. 上海交通大學，2017.

[9]Guogang，Q.，Nan，X.，& Fan，Y. （2018，July）.The In-Use Performance Ratio of China Real World Vehicles and the Verification of Denominator/Numerator Increment Activity Compliance. In International Conference on Frontier Computing（pp. 1821-1828）.Springer， Singapore.