基于鴻蒙系統(tǒng)的無(wú)人方程式賽車(chē)遠(yuǎn)程監(jiān)控與數(shù)據(jù)管理系統(tǒng)開(kāi)發(fā)

王紳同,蘇清華,王立勇,張鵬博,王弘軒,姜海燕

(北京信息科技大學(xué) 現(xiàn)代測(cè)控技術(shù)教育部重點(diǎn)實(shí)驗(yàn)室,北京 100192)

0 引言

近年來(lái),隨著科技不斷進(jìn)步,無(wú)人駕駛汽車(chē)(unmanned autonomous vehicle,UAV)技術(shù)飛速發(fā)展[1]。為促進(jìn)我國(guó)UAV產(chǎn)業(yè)和無(wú)人駕駛技術(shù)發(fā)展,2017年中國(guó)汽車(chē)工程學(xué)會(huì)成功舉辦首屆中國(guó)大學(xué)生無(wú)人駕駛方程式大賽(formula student autonomous China,FSAC)[2],引起國(guó)內(nèi)各大高校與汽車(chē)相關(guān)企業(yè)的密切關(guān)注。為保證UAV在運(yùn)行時(shí)的安全,必須開(kāi)發(fā)遠(yuǎn)程監(jiān)控與數(shù)據(jù)管理系統(tǒng)。

車(chē)輛遠(yuǎn)程監(jiān)控系統(tǒng)應(yīng)用研究已經(jīng)具有一定規(guī)模,已有許多科研團(tuán)隊(duì)針對(duì)不同種類(lèi)車(chē)輛進(jìn)行相關(guān)遠(yuǎn)程監(jiān)控系統(tǒng)研究。張海逢[3]提出一套基于控制器局域網(wǎng)(controller area network,CAN)總線與Android技術(shù)的車(chē)輛數(shù)據(jù)采集與遠(yuǎn)程監(jiān)控系統(tǒng),實(shí)現(xiàn)對(duì)普通乘用車(chē)的運(yùn)動(dòng)軌跡回放、數(shù)據(jù)分析、數(shù)據(jù)展示等監(jiān)控功能。王奇等[4]以STM32F103 單片機(jī)為主控制器,采用 CAN 總線傳輸,應(yīng)用多種傳感器融合技術(shù),實(shí)現(xiàn)對(duì)胡蘿卜聯(lián)合收獲作業(yè)的實(shí)時(shí)監(jiān)測(cè)與夾持輸送帶帶速自動(dòng)控制。在無(wú)人駕駛領(lǐng)域,趙丹丹[5]將全球定位系統(tǒng)(global positioning system,GPS)、地理信息系統(tǒng) (geographic information system,GIS)、通用分組無(wú)線業(yè)務(wù) (general packet radio service,GPRS)/3G無(wú)線網(wǎng)絡(luò)集成為一體,實(shí)現(xiàn)數(shù)據(jù)通信功能,使用Visual Basic 6.0設(shè)計(jì)遠(yuǎn)程監(jiān)控系統(tǒng),使監(jiān)控人員通過(guò)觀察監(jiān)控界面對(duì)無(wú)人車(chē)進(jìn)行實(shí)時(shí)監(jiān)視和科學(xué)的控制管理。曹?chē)?guó)浩[6]采用客戶端/服務(wù)器(client-server,C/S)模式,將無(wú)人駕駛智能車(chē)系統(tǒng)和監(jiān)控終端作為客戶端,采集各種傳感器信息,通過(guò)4G網(wǎng)絡(luò)與服務(wù)器系統(tǒng)之間進(jìn)行信息傳遞,實(shí)現(xiàn)對(duì)無(wú)人駕駛智能車(chē)遠(yuǎn)程監(jiān)控。

目前研發(fā)的移動(dòng)端遠(yuǎn)程監(jiān)控系統(tǒng)多基于Android或iOS系統(tǒng)等,基于我國(guó)自主研發(fā)的鴻蒙系統(tǒng)的車(chē)輛無(wú)線監(jiān)控系統(tǒng)仍是空白。針對(duì)無(wú)人方程式賽車(chē)的遠(yuǎn)程監(jiān)控系統(tǒng),目前沒(méi)有相應(yīng)的研究。因此,本文基于鴻蒙系統(tǒng)[7],結(jié)合CAN總線、藍(lán)牙通信、Spring Boot框架、MySQL數(shù)據(jù)庫(kù)等技術(shù)設(shè)計(jì)了無(wú)人方程式賽車(chē)遠(yuǎn)程監(jiān)控與數(shù)據(jù)管理系統(tǒng)。

1 系統(tǒng)整體結(jié)構(gòu)設(shè)計(jì)

基于鴻蒙系統(tǒng)的無(wú)人方程式賽車(chē)遠(yuǎn)程監(jiān)控與數(shù)據(jù)管理系統(tǒng)整體架構(gòu)如圖1所示,主要由移動(dòng)端、云數(shù)據(jù)庫(kù)和遠(yuǎn)程監(jiān)控平臺(tái)3部分組成。移動(dòng)端負(fù)責(zé)通過(guò)藍(lán)牙通信接收藍(lán)牙CAN卡轉(zhuǎn)發(fā)的無(wú)人方程式賽車(chē)CAN總線上的電機(jī)、電池箱、位移傳感器、壓力傳感器、霍爾傳感器和其他傳感器數(shù)據(jù);將解析后的CAN數(shù)據(jù)通過(guò)5G移動(dòng)網(wǎng)絡(luò)上傳到云數(shù)據(jù)庫(kù)和顯示到移動(dòng)端設(shè)備界面;接收遠(yuǎn)程監(jiān)控平臺(tái)的控制指令并轉(zhuǎn)發(fā)給無(wú)人方程式賽車(chē)。云數(shù)據(jù)庫(kù)負(fù)責(zé)接收移動(dòng)端發(fā)送到的數(shù)據(jù)并將其存儲(chǔ);存儲(chǔ)遠(yuǎn)程監(jiān)控平臺(tái)的控制記錄信息;根據(jù)遠(yuǎn)程監(jiān)控平臺(tái)發(fā)來(lái)的數(shù)據(jù)請(qǐng)求,通過(guò)互聯(lián)網(wǎng)將數(shù)據(jù)回傳到遠(yuǎn)程監(jiān)控平臺(tái)。遠(yuǎn)程監(jiān)控平臺(tái)負(fù)責(zé)將接收到的傳感器數(shù)據(jù)進(jìn)行展示,實(shí)現(xiàn)對(duì)無(wú)人方程式賽車(chē)的狀態(tài)、故障信息的遠(yuǎn)程監(jiān)控。車(chē)隊(duì)隊(duì)員可以通過(guò)網(wǎng)頁(yè)實(shí)時(shí)查看無(wú)人方程式賽車(chē)的狀態(tài)和故障信息數(shù)據(jù),在賽車(chē)出現(xiàn)故障時(shí)通過(guò)遠(yuǎn)程操作將緊急制動(dòng)指令發(fā)送到移動(dòng)端,從而確保人車(chē)安全。

圖1 系統(tǒng)整體架構(gòu)Fig.1 Overall system architecture

2 基于鴻蒙系統(tǒng)的數(shù)據(jù)采集軟件設(shè)計(jì)

移動(dòng)端軟件采用華為鴻蒙系統(tǒng),并使用華為一站式集成開(kāi)發(fā)環(huán)境DevEco Studio軟件進(jìn)行設(shè)計(jì)與開(kāi)發(fā)。移動(dòng)端軟件采用多線程模式進(jìn)行開(kāi)發(fā),分為主線程、藍(lán)牙數(shù)據(jù)接收線程、解析數(shù)據(jù)發(fā)送線程、遠(yuǎn)程數(shù)據(jù)接收線程、藍(lán)牙數(shù)據(jù)發(fā)送線程。各線程之間互不影響、獨(dú)立工作,無(wú)數(shù)據(jù)時(shí)進(jìn)入休眠期,可實(shí)現(xiàn)數(shù)據(jù)實(shí)時(shí)接收、準(zhǔn)確解析、實(shí)時(shí)發(fā)送。

2.1 主線程

主線程負(fù)責(zé)建立藍(lán)牙連接、更新頁(yè)面用戶界面(user interface,UI),以及調(diào)用子線程。

藍(lán)牙通信使用鴻蒙系統(tǒng)傳統(tǒng)藍(lán)牙模式藍(lán)牙協(xié)議2.0版本進(jìn)行開(kāi)發(fā),并使用鴻蒙系統(tǒng)中的USE_BLUETOOTH、DISCOVER_BLUETOOTH、MANAGE_BLUETOOTH權(quán)限分別獲取允許查看藍(lán)牙配置、允許查找遠(yuǎn)端設(shè)備、允許配對(duì)藍(lán)牙設(shè)備等權(quán)限,實(shí)現(xiàn)開(kāi)啟和關(guān)閉藍(lán)牙掃描、獲取已配對(duì)設(shè)備列表、查詢遠(yuǎn)端藍(lán)牙設(shè)備名稱(chēng)和媒體訪問(wèn)控制(media access control,MAC)地址、獲取配對(duì)狀態(tài)、發(fā)起藍(lán)牙設(shè)備配對(duì)、獲取通用唯一標(biāo)識(shí)符(universally unique identifier,UUID)、使用藍(lán)牙讀寫(xiě)功能、建立藍(lán)牙Socket通信等。藍(lán)牙連接模塊流程如圖2所示。進(jìn)入程序后可自動(dòng)檢測(cè)是否打開(kāi)藍(lán)牙,并提示是否打開(kāi)藍(lán)牙,管理藍(lán)牙狀態(tài)。連接后,自動(dòng)獲取藍(lán)牙設(shè)備的MAC地址,顯示藍(lán)牙連接成功,并調(diào)用藍(lán)牙數(shù)據(jù)接收線程。

圖2 藍(lán)牙連接模塊流程Fig.2 Bluetooth connection module process

主線程與子線程之間使用鴻蒙系統(tǒng)線程間通信處理機(jī)制EventHandler來(lái)處理獲取最新數(shù)據(jù)。當(dāng)數(shù)據(jù)解析線程解析數(shù)據(jù)后,通過(guò)EventHandler將數(shù)據(jù)傳遞給主線程,主線程將數(shù)據(jù)從相應(yīng)的數(shù)組中取出用于更新界面。

2.2 藍(lán)牙數(shù)據(jù)接收線程

藍(lán)牙Socket通信建立后,數(shù)據(jù)接收線程激活,開(kāi)始接收并解析數(shù)據(jù),藍(lán)牙數(shù)據(jù)接收流程如圖3所示。接收到數(shù)據(jù)幀后,按照定義的CAN協(xié)議判斷數(shù)據(jù)幀是否為空、數(shù)據(jù)幀頭格式是否正確,若不正確則丟棄該幀數(shù)據(jù)。當(dāng)數(shù)據(jù)幀頭正確時(shí),按照如表1所示的CAN協(xié)議解析傳感器數(shù)據(jù)信息。當(dāng)數(shù)據(jù)解析并濾波后,存入到設(shè)置的數(shù)組CarInfoBean的相應(yīng)變量中用于傳遞到主線程與解析數(shù)據(jù)發(fā)送線程。

表1 CAN通信部分協(xié)議Table 1 Part of CAN communication protocol

圖3 藍(lán)牙數(shù)據(jù)接收線程流程Fig.3 Bluetooth data receiving thread process

數(shù)據(jù)解析后,考慮到霍爾傳感器數(shù)據(jù)容易受到電磁干擾、油門(mén)踏板在有人駕駛模式下使用頻率較高,故對(duì)霍爾傳感器數(shù)據(jù)、油門(mén)踏板位移傳感器數(shù)據(jù)使用擴(kuò)展卡爾曼濾波(extended Kalman filter,EKF)算法進(jìn)行數(shù)據(jù)處理。相較于標(biāo)準(zhǔn)卡爾曼濾波,EKF算法的主要優(yōu)勢(shì)在于其能夠處理非線性系統(tǒng)。

EKF算法的狀態(tài)方程如式(1)所示,用于進(jìn)行預(yù)測(cè),根據(jù)先前的狀態(tài)估計(jì)和控制輸入,預(yù)測(cè)系統(tǒng)的下一個(gè)狀態(tài)。

xk=f(xk-1)

(1)

式中:xk為k時(shí)刻系統(tǒng)的狀態(tài)向量;f(xk-1)為描述狀態(tài)演化的函數(shù)。

測(cè)量方程如式(2)所示,用于將系統(tǒng)狀態(tài)的預(yù)測(cè)與實(shí)際觀測(cè)數(shù)據(jù)進(jìn)行比較,并校正狀態(tài)估計(jì)。

zk=h(xk)

(2)

式中:zk為k時(shí)刻的測(cè)量值;h(xk)為測(cè)量函數(shù),描述測(cè)量值和狀態(tài)之間的關(guān)系。

以下為EKF算法的迭代過(guò)程,分為預(yù)測(cè)和更新2個(gè)步驟。這2個(gè)步驟交替進(jìn)行,形成迭代循環(huán),用于逐步估計(jì)系統(tǒng)的狀態(tài),從而逐步提高對(duì)系統(tǒng)的狀態(tài)估計(jì)。

預(yù)測(cè)步驟中的狀態(tài)預(yù)測(cè)方程如式(3)所示,用于預(yù)測(cè)當(dāng)前時(shí)刻的系統(tǒng)狀態(tài)。通過(guò)將先前時(shí)刻的狀態(tài)估計(jì)和控制輸入傳遞給狀態(tài)轉(zhuǎn)移函數(shù),可以獲得對(duì)當(dāng)前時(shí)刻狀態(tài)的預(yù)測(cè)。

(3)

預(yù)測(cè)步驟中的協(xié)方差預(yù)測(cè)方程如式(4)所示,用于在沒(méi)有新觀測(cè)數(shù)據(jù)的情況下,估計(jì)下一時(shí)刻系統(tǒng)狀態(tài)的協(xié)方差,并在后續(xù)的更新步驟中繼續(xù)使用。

(4)

更新步驟中的卡爾曼增益計(jì)算如式(5)所示,用來(lái)在狀態(tài)更新步驟中權(quán)衡系統(tǒng)模型預(yù)測(cè)和觀測(cè)數(shù)據(jù)之間的不確定性,以及它們的相對(duì)權(quán)重,從而獲得對(duì)系統(tǒng)狀態(tài)更準(zhǔn)確的估計(jì)。

(5)

式中:Kk為卡爾曼增益;Hk為測(cè)量方程在k時(shí)刻狀態(tài)預(yù)測(cè)下的雅可比矩陣;Rk為測(cè)量噪聲協(xié)方差矩陣。

更新步驟中的狀態(tài)更新方程如式(6)所示,用于計(jì)算新的狀態(tài)估計(jì)值,將系統(tǒng)狀態(tài)的預(yù)測(cè)值與觀測(cè)數(shù)據(jù)進(jìn)行校正,以獲得更優(yōu)的狀態(tài)估計(jì)。

(6)

更新步驟中的協(xié)方差更新方程如式(7)所示,用于計(jì)算新的協(xié)方差矩陣,以反映通過(guò)觀測(cè)數(shù)據(jù)對(duì)系統(tǒng)狀態(tài)進(jìn)行修正后的不確定性。

Pk|k=(I-KkHk)Pk|k-1

(7)

式中:I為單位矩陣。

2.3 解析數(shù)據(jù)發(fā)送線程

解析后數(shù)據(jù)將通過(guò)5G網(wǎng)絡(luò)被發(fā)送至云端。采用2種發(fā)送方式:一種使用WebSocket協(xié)議將數(shù)據(jù)發(fā)送到監(jiān)控系統(tǒng)后臺(tái),前端從后臺(tái)實(shí)時(shí)獲取數(shù)據(jù)進(jìn)行顯示;一種是使用HTTP協(xié)議將數(shù)據(jù)發(fā)送到數(shù)據(jù)庫(kù)中。2種方式都使用處理網(wǎng)絡(luò)請(qǐng)求的開(kāi)源框架OKHttp3。這是一個(gè)Java的HTTP+SPDY客戶端開(kāi)發(fā)包,不僅支持Android,也同樣支持鴻蒙系統(tǒng)使用。在發(fā)送數(shù)據(jù)到數(shù)據(jù)庫(kù)時(shí)需要獲取訪問(wèn)數(shù)據(jù)庫(kù)權(quán)限,故需要首先登錄平臺(tái),獲取登錄后的token數(shù)值,從而獲取訪問(wèn)數(shù)據(jù)庫(kù)接口權(quán)限。在使用OKHttp3時(shí),需要加入網(wǎng)絡(luò)依賴(lài):implementation′com.squareup.okhttp3:okhttp:4.9.0′,網(wǎng)絡(luò)訪問(wèn)權(quán)限:ohos.permission.INTERNET,修改網(wǎng)絡(luò)連接狀態(tài)權(quán)限:ohos.permission.SET_NETWORK_ INFO,獲取網(wǎng)絡(luò)連接信息權(quán)限:ohos.permission.GET_NETWO RK_INFO。OKHttp3中支持同步與異步2種請(qǐng)求,由于數(shù)據(jù)是快速接收并解析轉(zhuǎn)發(fā)的,數(shù)據(jù)量較大,故使用異步請(qǐng)求的POST請(qǐng)求進(jìn)行數(shù)據(jù)發(fā)送,其中數(shù)據(jù)是按照J(rèn)avaScript對(duì)象符號(hào)(javascript object notation,JSON)格式進(jìn)行發(fā)送。

OKHttp3發(fā)送異步請(qǐng)求按照以下5步進(jìn)行:1)創(chuàng)建OKHttpClient實(shí)例。2)創(chuàng)建RequestBody實(shí)例,主要用來(lái)傳遞JSON字符串中的數(shù)據(jù),并對(duì)params數(shù)組的長(zhǎng)度進(jìn)行判斷,如果大于0則往下執(zhí)行。3)創(chuàng)建Request實(shí)例,在該實(shí)例中設(shè)置發(fā)送路徑URL(uniform resource locator)和post請(qǐng)求方式。4)創(chuàng)建Call回調(diào)對(duì)象并執(zhí)行,獲取一個(gè)response對(duì)象。5)發(fā)送請(qǐng)求:在發(fā)送登錄請(qǐng)求的方法中通過(guò)登錄接口將用戶名密碼傳入到后臺(tái)中,從而登錄系統(tǒng),并通過(guò)onResponse回調(diào)中保存獲取到登錄成功后的token值,保存到變量中,并在發(fā)送數(shù)據(jù)的request實(shí)例加入Header頭,將token放入Header中,用于驗(yàn)證信息。在發(fā)送數(shù)據(jù)時(shí),通過(guò)數(shù)據(jù)接口,將帶有token值的Header頭部和數(shù)據(jù)值的Params數(shù)組所形成的字符串傳入數(shù)據(jù)庫(kù)后臺(tái)。

2.4 遠(yuǎn)程數(shù)據(jù)接收線程

遠(yuǎn)程數(shù)據(jù)接收線程負(fù)責(zé)接收遠(yuǎn)程監(jiān)控平臺(tái)發(fā)送的控制指令信號(hào),在主線程啟動(dòng)的同時(shí)即啟動(dòng)。當(dāng)監(jiān)測(cè)到指令信號(hào)時(shí),線程先對(duì)指令進(jìn)行判斷。如果不是緊急制動(dòng)控制指令,則忽略該幀數(shù)據(jù);如果是緊急制動(dòng)控制指令時(shí),按照定義的CAN協(xié)議封裝為1條16進(jìn)制數(shù)據(jù),該數(shù)據(jù)含有控制車(chē)輛控制單元(vehicle control unit,VCU)發(fā)出緊急制動(dòng)的指令,數(shù)據(jù)生成后線程將數(shù)據(jù)傳遞并激活藍(lán)牙數(shù)據(jù)發(fā)送線程。

2.5 藍(lán)牙數(shù)據(jù)發(fā)送線程

藍(lán)牙數(shù)據(jù)發(fā)送線程負(fù)責(zé)將數(shù)據(jù)通過(guò)藍(lán)牙Socket通信經(jīng)藍(lán)牙CAN卡發(fā)送到賽車(chē)VCU[8]中。藍(lán)牙數(shù)據(jù)發(fā)送線程對(duì)接收16進(jìn)制數(shù)據(jù)按照表2中的數(shù)據(jù)幀格式進(jìn)行加工,即在幀數(shù)據(jù)前加上幀類(lèi)型、數(shù)據(jù)長(zhǎng)度等幀描述與幀ID信息。CAN數(shù)據(jù)幀封裝后,按照表3中的藍(lán)牙數(shù)據(jù)包格式進(jìn)行藍(lán)牙數(shù)據(jù)包封裝,即在數(shù)據(jù)幀前加入藍(lán)牙數(shù)據(jù)包頭0x24與CAN數(shù)據(jù)幀總數(shù)量N,使其符合藍(lán)牙CAN卡數(shù)據(jù)幀格式,之后通過(guò)藍(lán)牙通信發(fā)送該數(shù)據(jù),從而實(shí)現(xiàn)控制賽車(chē)。

表2 CAN幀格式Table 2 CAN frame format

表3 藍(lán)牙數(shù)據(jù)包格式Table 3 Bluetooth packet format

3 數(shù)據(jù)庫(kù)設(shè)計(jì)與建立

本系統(tǒng)選用MySQL軟件對(duì)數(shù)據(jù)庫(kù)進(jìn)行設(shè)計(jì),并使用MySQL8.0版本。通過(guò)對(duì)系統(tǒng)需求的分析,將數(shù)據(jù)表設(shè)置為用戶信息表、用戶角色表、賽車(chē)運(yùn)行信息表、賽車(chē)遠(yuǎn)程控制記錄表、系統(tǒng)操作日志表,每個(gè)表根據(jù)不同的信息設(shè)置相關(guān)字段與主鍵。用戶可以通過(guò)賽車(chē)運(yùn)行信息表查看各個(gè)傳感器數(shù)據(jù)、電池電流、電池電壓等數(shù)據(jù)情況,可以實(shí)現(xiàn)故障位置與時(shí)刻精準(zhǔn)定位。

3.1 Mybatis框架

數(shù)據(jù)庫(kù)建立時(shí),使用基于Java的持久層框架Mybatis來(lái)實(shí)現(xiàn)對(duì)數(shù)據(jù)庫(kù)的底層操作。Mybatis的功能架構(gòu)分為3層[9]:

1)應(yīng)用編程接口(application programming interface,API)層。提供給開(kāi)發(fā)人員的接口API,收到調(diào)用請(qǐng)求后立刻調(diào)用數(shù)據(jù)處理層來(lái)完成具體的數(shù)據(jù)處理。

2)數(shù)據(jù)處理層。負(fù)責(zé)具體的SQL查找、SQL解析、SQL執(zhí)行和執(zhí)行結(jié)果映射等。

3)基礎(chǔ)支撐層。負(fù)責(zé)基礎(chǔ)功能,包括連接管理、事務(wù)管理、配置加載和緩存處理等,為上層的數(shù)據(jù)處理層提供最基礎(chǔ)的支撐。

3.2 數(shù)據(jù)安全

數(shù)據(jù)由移動(dòng)端發(fā)送至數(shù)據(jù)庫(kù)、數(shù)據(jù)由前端發(fā)送到后臺(tái)時(shí),使用高級(jí)加密標(biāo)準(zhǔn)(advanced encryption standard,AES)加密算法,AES加密算法具體的加密流程如圖4所示。AES具有3種密鑰長(zhǎng)度,分別是128位、192位、256位,且還擁有128位分組長(zhǎng)度。AES密鑰長(zhǎng)度和加密解密次數(shù)相互對(duì)應(yīng)。不同的密鑰長(zhǎng)度,加密的次數(shù)完全不同。當(dāng)密鑰為 128 位時(shí),僅僅通過(guò)10次加密解密的輪換即可,密鑰長(zhǎng)度變長(zhǎng),加密的次數(shù)也就變多。依次按照密鑰變長(zhǎng)一次,密鑰加密解密次數(shù)增加兩次的規(guī)律遞增。數(shù)據(jù)庫(kù)會(huì)將AES加密后的數(shù)據(jù)存入,當(dāng)監(jiān)控系統(tǒng)調(diào)用數(shù)據(jù)時(shí),將從數(shù)據(jù)庫(kù)獲取的數(shù)據(jù)使用AES解密算法進(jìn)行解密操作,并將解密后的數(shù)據(jù)發(fā)送至前端。

圖4 AES加密算法流程Fig.4 AES encryption algorithm process

在用戶注冊(cè)時(shí),使用BCryptPasswordEncoder算法對(duì)用戶名密碼進(jìn)行加密,并將加密后的結(jié)果存入數(shù)據(jù)庫(kù)中的用戶信息表中。當(dāng)用戶進(jìn)行登錄時(shí),后臺(tái)系統(tǒng)將用戶添加的信息使用BCryptPasswordEncoder進(jìn)行加密,數(shù)據(jù)傳遞到數(shù)據(jù)庫(kù)中,與數(shù)據(jù)庫(kù)中用戶名密碼對(duì)比,若一致則視為鑒權(quán)成功,用戶登錄成功。BCryptPasswordEncoder算法工作流程如圖5所示。

圖5 BCryptPasswordEncoder算法工作流程Fig.5 BCryptPasswordEncoder algorithm workflow

4 遠(yuǎn)程數(shù)據(jù)監(jiān)控平臺(tái)

遠(yuǎn)程數(shù)據(jù)監(jiān)控平臺(tái)采用瀏覽器/服務(wù)端(browser-server,B/S)架構(gòu)進(jìn)行開(kāi)發(fā)。相比C/S架構(gòu)的使用每次都需安裝新的客戶端軟件,B/S架構(gòu)的開(kāi)發(fā)無(wú)需任何安裝,以Web為基礎(chǔ),瀏覽器就是B/S架構(gòu)的客戶端,用戶只需下載一個(gè)瀏覽器,就可以使用C/S架構(gòu)開(kāi)發(fā)所有的應(yīng)用程序。

監(jiān)控平臺(tái)采用前后端分離模式,前端使用超文本標(biāo)記語(yǔ)言(hyper text mark-up language,HTML)、級(jí)聯(lián)樣式表(cascading style sheets,CSS)與JavaScript技術(shù)。后端使用SpringBoot框架,遠(yuǎn)程數(shù)據(jù)監(jiān)控平臺(tái)功能模塊如圖6所示。

圖6 數(shù)據(jù)監(jiān)控平臺(tái)功能模塊結(jié)構(gòu)Fig.6 Functional module structure of data monitoring platform

監(jiān)控平臺(tái)主要由用戶管理模塊、數(shù)據(jù)監(jiān)控模塊、歷史數(shù)據(jù)模塊、系統(tǒng)管理模塊組成。用戶管理模塊有用戶登錄、賬號(hào)管理功能,用戶通過(guò)填寫(xiě)用戶名、密碼、驗(yàn)證碼信息訪問(wèn)監(jiān)控系統(tǒng),超級(jí)管理員通過(guò)登錄系統(tǒng)管理其他角色用戶。數(shù)據(jù)監(jiān)控模塊有導(dǎo)航菜單、賽車(chē)實(shí)時(shí)數(shù)據(jù)顯示功能,通過(guò)數(shù)據(jù)監(jiān)控模塊可以查看賽車(chē)各傳感器實(shí)時(shí)信息,車(chē)輛出現(xiàn)異常狀況時(shí),可以通過(guò)遠(yuǎn)程操作,將遠(yuǎn)程指令發(fā)送到車(chē)端,使車(chē)輛進(jìn)入緊急制動(dòng)模式。歷史數(shù)據(jù)模塊有歷史數(shù)據(jù)查看、數(shù)據(jù)導(dǎo)出功能,可以查看車(chē)輛傳感器的歷史詳細(xì)數(shù)據(jù)信息,并提供數(shù)據(jù)下載功能,將從數(shù)據(jù)庫(kù)取出的數(shù)據(jù)寫(xiě)入到xlsx文件中保存在本地電腦。系統(tǒng)管理模塊主要用于管理日志信息與服務(wù)器信息,可以查看登錄日志信息、數(shù)據(jù)發(fā)送記錄信息、數(shù)據(jù)操作信息、數(shù)據(jù)庫(kù)操作信息、服務(wù)器中央處理器(central processing unit,CPU)和內(nèi)存信息等。

數(shù)據(jù)監(jiān)控平臺(tái)使用流程如圖7所示。當(dāng)用戶登錄系統(tǒng)后首先進(jìn)行身份認(rèn)證,系統(tǒng)根據(jù)數(shù)據(jù)庫(kù)中的用戶表進(jìn)行用戶名密碼匹配驗(yàn)證,若認(rèn)證通過(guò),則進(jìn)入系統(tǒng);若認(rèn)證失敗則需重新登錄。登錄系統(tǒng)后,可查看系統(tǒng)狀態(tài)信息、查詢賽車(chē)歷史數(shù)據(jù)、查看當(dāng)前賽車(chē)實(shí)施狀態(tài)、導(dǎo)出賽車(chē)歷史數(shù)據(jù)、查看系統(tǒng)日志信息。

圖7 數(shù)據(jù)監(jiān)控平臺(tái)使用流程Fig.7 Usage process of data monitoring platform

5 系統(tǒng)測(cè)試

為驗(yàn)證無(wú)人方程式賽車(chē)遠(yuǎn)程監(jiān)控與數(shù)據(jù)管理系統(tǒng)的模塊功能,在北京信息科技大學(xué)沙河校區(qū)某封閉路段開(kāi)展實(shí)車(chē)測(cè)試。測(cè)試路段長(zhǎng)100 m,寬20 m。按照無(wú)人駕駛方程式大賽規(guī)則要求,在賽車(chē)左側(cè)放置紅色錐桶,右側(cè)放置藍(lán)色錐桶,起點(diǎn)終點(diǎn)處左右兩側(cè)各放置2個(gè)黃色錐桶,同側(cè)錐桶相隔5 m,賽車(chē)左右兩側(cè)錐桶相隔3.5 m。按照規(guī)則進(jìn)行有人駕駛與無(wú)人駕駛下的系列測(cè)試,在賽車(chē)行駛的過(guò)程中驗(yàn)證系統(tǒng)功能。圖8為測(cè)試使用的無(wú)人方程式賽車(chē)。

圖8 無(wú)人方程式賽車(chē)實(shí)車(chē)試驗(yàn)Fig.8 Real car test of unmanned formula racing

5.1 通信與監(jiān)控功能測(cè)試

為驗(yàn)證系統(tǒng)的可行性,在實(shí)車(chē)測(cè)試前,移動(dòng)端使用華為MatePad11平板電腦與賽車(chē)上安裝的藍(lán)牙CAN卡進(jìn)行藍(lán)牙通信連接,安裝手機(jī)用戶識(shí)別模塊 (subscriber identity module,SIM)卡并打開(kāi)移動(dòng)數(shù)據(jù)網(wǎng)絡(luò)進(jìn)行數(shù)據(jù)傳送,從而測(cè)試監(jiān)控系統(tǒng)的可行性。

圖9為通信與監(jiān)控功能測(cè)試結(jié)果。從圖中可以看出,系統(tǒng)能夠接收并成功解析CAN數(shù)據(jù)報(bào)文信息,并將解析后的數(shù)據(jù)顯示到移動(dòng)端設(shè)備與遠(yuǎn)程Web端。解析結(jié)果與賽車(chē)狀態(tài)相同。

圖9 數(shù)據(jù)顯示界面Fig.9 Data display interface

5.2 數(shù)據(jù)接收存儲(chǔ)測(cè)試

為測(cè)試系統(tǒng)在數(shù)據(jù)解析后發(fā)送到數(shù)據(jù)庫(kù)端之間的數(shù)據(jù)丟失情況與數(shù)據(jù)存儲(chǔ)耗時(shí)情況,在不同時(shí)間段的實(shí)車(chē)測(cè)試中對(duì)接收到的數(shù)據(jù)進(jìn)行計(jì)數(shù)統(tǒng)計(jì),并將計(jì)數(shù)結(jié)果與數(shù)據(jù)庫(kù)中存儲(chǔ)的數(shù)據(jù)總量進(jìn)行比對(duì),通過(guò)數(shù)據(jù)庫(kù)中最后一條數(shù)據(jù)與第一條數(shù)據(jù)的時(shí)間差得出存儲(chǔ)耗時(shí)。實(shí)驗(yàn)測(cè)試結(jié)果如表4所示。

表4 數(shù)據(jù)接收存儲(chǔ)測(cè)試結(jié)果Table 4 Data reception and storage test results

由測(cè)試結(jié)果計(jì)算得出數(shù)據(jù)丟失率平均為0.042 4%,CAN卡數(shù)據(jù)每10 ms發(fā)送一幀,數(shù)據(jù)存儲(chǔ)時(shí)間平均延遲時(shí)間為8.6 s,移動(dòng)網(wǎng)絡(luò)信號(hào)強(qiáng)度和質(zhì)量對(duì)延時(shí)影響較大。

5.3 EKF算法測(cè)試

選取第一個(gè)數(shù)據(jù)作為初始狀態(tài),設(shè)置初始協(xié)方差矩陣為

(8)

設(shè)置過(guò)程噪聲協(xié)方差矩陣為

(9)

設(shè)置測(cè)量噪聲協(xié)方差矩陣為

R=[0.1]

(10)

構(gòu)建算法代碼,并選取測(cè)試數(shù)據(jù)進(jìn)行測(cè)試。圖10為定速30 km/h條件下霍爾傳感器測(cè)試結(jié)果,圖11為變速條件下霍爾傳感器測(cè)試結(jié)果,圖12為油門(mén)踏板位移傳感器測(cè)試結(jié)果。

圖10 定速30 km/h時(shí)霍爾傳感器數(shù)據(jù)濾波測(cè)試結(jié)果Fig.10 Test results of Hall sensor data filtering at a constant speed of 30 km/h

圖11 變速時(shí)霍爾傳感器數(shù)據(jù)濾波測(cè)試結(jié)果Fig.11 Test results of Hall sensor data filtering at variable speed

圖12 油門(mén)踏板位移傳感器測(cè)試結(jié)果Fig.12 Test results of accelerator pedal displacement sensor

從圖10可以看出,在30 km/h的定速情況下,霍爾傳感器數(shù)據(jù)通過(guò)EKF算法處理濾波后曲線比未濾波曲線更加接近30 km/h,濾波后的速度多集中在30.17～29.83 km/h之間,未濾波的速度集中在30.23～29.78 km/h之間。

從圖11可以看出,在變速情況下,霍爾傳感器數(shù)據(jù)通過(guò)EKF算法濾波處理后曲線比未濾波曲線分布更集中,未濾波數(shù)據(jù)比濾波后數(shù)據(jù)起伏劇烈。

從圖12可以看出,油門(mén)踏板位移數(shù)據(jù)通過(guò)EKF濾波算法處理后曲線比未濾波曲線更加平穩(wěn),濾波前上下起伏的數(shù)據(jù)均被過(guò)濾處理。

由上述試驗(yàn)可以看出,數(shù)據(jù)通過(guò)EKF算法處理后數(shù)據(jù)曲線更加光滑,方便系統(tǒng)對(duì)車(chē)輛狀態(tài)進(jìn)行判斷,從而減少系統(tǒng)狀態(tài)誤判。

6 結(jié)束語(yǔ)

本文針對(duì)大學(xué)生無(wú)人方程式大賽中MCT無(wú)人車(chē)隊(duì)在日常調(diào)試賽車(chē)的實(shí)際需要,結(jié)合當(dāng)前車(chē)輛監(jiān)控系統(tǒng)研究現(xiàn)狀,設(shè)計(jì)了一套基于鴻蒙系統(tǒng)的無(wú)人方程式賽車(chē)遠(yuǎn)程監(jiān)控與數(shù)據(jù)管理系統(tǒng)。由測(cè)試結(jié)果得出主要結(jié)論如下:

1)根據(jù)通信與監(jiān)控功能測(cè)試,基于鴻蒙系統(tǒng)的無(wú)人車(chē)遠(yuǎn)程監(jiān)控與數(shù)據(jù)管理系統(tǒng)可以與安卓系統(tǒng)一樣進(jìn)行車(chē)輛監(jiān)控,在車(chē)輛監(jiān)控領(lǐng)域使用鴻蒙系統(tǒng)具有可行性。

2)根據(jù)數(shù)據(jù)接收存儲(chǔ)測(cè)試,移動(dòng)端多線程的設(shè)計(jì)方法可有效解決大量數(shù)據(jù)下數(shù)據(jù)的快速解析、數(shù)據(jù)顯示與數(shù)據(jù)發(fā)送。

3)根據(jù)數(shù)據(jù)接收存儲(chǔ)測(cè)試,該系統(tǒng)可有效解決無(wú)人方程式賽車(chē)傳感器數(shù)據(jù)快速存儲(chǔ)問(wèn)題。