基于GPRS 的整車控制策略遠程監(jiān)測系統(tǒng)的軟件設(shè)計

鄒慶勇， 龔元明

（上海工程技術(shù)大學 機械與汽車工程學院， 上海 201620）

0 引 言

隨著人們對汽車的動力性、經(jīng)濟性、安全性、舒適性的要求越來越高，汽車用電子控制單元要實現(xiàn)的功能也日趨復雜，導致生產(chǎn)周期加長，生產(chǎn)成本提高。 目前，在開發(fā)汽車電子控制單元時，比較常用的方式是采用硬件在環(huán)技術(shù)，根據(jù)預(yù)定目標，快速構(gòu)建控制模型，通過硬件在環(huán)仿真不斷測試優(yōu)化，以得到所需控制策略。 控制策略執(zhí)行效果的監(jiān)測對ECU開發(fā)非常重要，有助于控制策略的參數(shù)標定。 如果能實現(xiàn)遠程向硬件在環(huán)系統(tǒng)中的控制器下載控制策略，實時監(jiān)測控制策略的執(zhí)行效果以及對控制策略相關(guān)參數(shù)進行標定，將極大提高汽車控制器硬件在環(huán)臺架的利用率和汽車ECU 的開發(fā)效率，因此，針對控制策略執(zhí)行效果的實時監(jiān)測，本文提出了一種基于GPRS 和CAN 總線的整車控制策略遠程監(jiān)測系統(tǒng)，支持遠程創(chuàng)建測試用例、開展測試和測試數(shù)據(jù)的實時傳輸。 介紹了整車控制策略遠程監(jiān)測系統(tǒng)的組成和功能，主要描述了現(xiàn)場監(jiān)測終端和服務(wù)器的通信軟件設(shè)計。

1 整車控制策略遠程測試系統(tǒng)概述

整車控制策略遠程測試系統(tǒng)可以作為傳統(tǒng)汽車硬件在環(huán)系統(tǒng)的補充，可以借助云端數(shù)據(jù)庫實現(xiàn)汽車控制策略測試方案的快速制定，通過網(wǎng)絡(luò)快速傳輸測試數(shù)據(jù)到現(xiàn)場監(jiān)測終端實施測試方案，并將測試結(jié)果上傳云端服務(wù)器和客戶端以便于數(shù)據(jù)的長期存儲和結(jié)果分析。 整車控制策略測試方案的快速制定、快速實施和快速分析將縮短汽車控制策略的監(jiān)測時間，縮短控制器的開發(fā)周期。

2 整車控制策略遠程監(jiān)測系統(tǒng)的通信設(shè)計方案

該通信系統(tǒng)包括整車控制器硬件在環(huán)測試平臺、測試終端、云端服務(wù)器和網(wǎng)頁客戶端幾部分。 網(wǎng)頁客戶端用于顯示硬件在環(huán)臺架的選擇和測試方案的制定，云端服務(wù)器包括應(yīng)用軟件和數(shù)據(jù)庫，轉(zhuǎn)發(fā)和存儲網(wǎng)頁客戶端和測試終端提交的數(shù)據(jù)。 測試終端用于臨時存儲測試用例并根據(jù)用戶的設(shè)置向硬件在環(huán)測試平臺發(fā)送測試請求和接收測試響應(yīng)，進而完成GPRS 模塊的驅(qū)動［1］。 數(shù)據(jù)流程見圖1。

圖1 整車控制器遠程測試系統(tǒng)數(shù)據(jù)流程Fig.1 Data flow of remote test system for vehicle controller

3 整車控制策略遠程監(jiān)測系統(tǒng)的結(jié)構(gòu)

測試系統(tǒng)基于GPRS 和CAN 總線，由客戶端、云服務(wù)器和現(xiàn)場設(shè)備終端構(gòu)成，其中云服務(wù)器軟件由2 部分構(gòu)成。 一部分為以Django 為框架制作的網(wǎng)站服務(wù)器軟件，用于與網(wǎng)頁客戶端的數(shù)據(jù)通信和數(shù)據(jù)庫數(shù)據(jù)的存取，另一部分是以PyQt5 所編寫的服務(wù)端界面應(yīng)用程序，用于與現(xiàn)場測試設(shè)備的數(shù)據(jù)通信和數(shù)據(jù)庫數(shù)據(jù)的存取。 系統(tǒng)結(jié)構(gòu)見圖2。

圖2 整車控制器遠程測試系統(tǒng)結(jié)構(gòu)Fig.2 The structure of remote test system for vehicle controller

3.1 網(wǎng)頁客戶端

網(wǎng)頁客戶端用于創(chuàng)建測試條例，配置CAN 通信的基礎(chǔ)參數(shù)，查詢和下載測試結(jié)果。 為了實時顯示臺架的使用狀態(tài)和測試數(shù)據(jù)，運用了Asynchronous JavaScript and XML（AJAX）技術(shù)，可以在異步的情況下去數(shù)據(jù)庫讀取數(shù)據(jù)，然后更新部分網(wǎng)頁內(nèi)容。AJAX 使用DOM 實現(xiàn)動態(tài)顯示和交互， 通過XMLHttpRequest 實現(xiàn)異步數(shù)據(jù)的讀取，有助于減輕服務(wù)器負擔，減少用戶等待時間［2］。 網(wǎng)頁的制作還用到了HTML、CSS、JS 語言，共同完成了用戶的登錄、臺架選擇、測試條例的創(chuàng)建和測試結(jié)果的查詢等功能。 在遠程測試時可以選用云端提供的測試條例，也可以選擇自己創(chuàng)建測試條例。 測試開始后，界面將實時顯示測試結(jié)果，用戶可以在測試結(jié)束后將測試結(jié)果下載保存至本地。 測試臺架的選擇界面和測試條例的創(chuàng)建界面見圖3、圖4。

圖3 測試臺架選擇界面Fig.3 Web page for choosing a test bench

圖4 測試條例創(chuàng)建界面Fig.4 Web page for creating test cases

3.2 云端服務(wù)器

由于Django 具有自帶數(shù)據(jù)庫訪問組件和后臺管理系統(tǒng)等優(yōu)點，構(gòu)成測試系統(tǒng)客戶端和網(wǎng)站服務(wù)端程序選擇Django 框架開發(fā)。 云端服務(wù)器平臺采用阿里云服務(wù)器，用于運行Django 框架網(wǎng)站項目和PyQt5 應(yīng)用軟件，服務(wù)器軟件選擇性能穩(wěn)定、應(yīng)用廣泛的Apache 服務(wù)器，云服務(wù)器數(shù)據(jù)庫管理系統(tǒng)采用MYSQL，用于存儲診斷測試條例的配置信息、測試條例以及測試終端測得的整車控制器響應(yīng)數(shù)據(jù)。 服務(wù)端軟件可實現(xiàn)多終端設(shè)備的連接和數(shù)據(jù)的解析以及數(shù)據(jù)的存儲。

3.3 現(xiàn)場測試終端

該測試終端微控制器采用意法半導體公司推出的STM32F103ZET6 微控制器，為了存儲控制器開發(fā)測試人員制定的復雜的測試條例和測試結(jié)果，終端采用SD 卡作為存儲模塊。 GPRS 模塊選用了芯訊通公司生產(chǎn)的SIM900A。 微控制器通過USB-TOCAN 模塊向電腦發(fā)送診斷測試報文，同時接收響應(yīng)報文存儲于SD 卡內(nèi)并同時通過SIM900A 模塊上傳到云端服務(wù)器［3］。 現(xiàn)場測試終端硬件結(jié)構(gòu)見圖5。

圖5 測試終端硬件結(jié)構(gòu)Fig.5 Hardware structure of test terminal equipment

4 測試系統(tǒng)軟件設(shè)計實現(xiàn)

遠程控制器測試系統(tǒng)整體通信軟件的基本流程如圖6 所示。

圖6 遠程測試系統(tǒng)通信軟件流程圖Fig.6 Flow chart of communication software of remote test system

4.1 測試終端的軟件設(shè)計實現(xiàn)

終端軟件采用了模塊化的設(shè)計思想，主要分為GPRS 模塊、SD 卡存儲模塊、CAN 報文收發(fā)模塊。這里擬對此展開研究分述如下。

4.1.1 CAN 初始化程序

CAN 初始化包括3 部分，分別為：模塊初始化、節(jié)點初始化和報文初始化。 其中，模塊初始化的配置主要是時鐘頻率的選擇；節(jié)點初始化主要完成節(jié)點和工作模式的選擇以及輸入輸出引腳的設(shè)置；報文初始化主要完成幀格式、消息體ID 和數(shù)據(jù)長度的設(shè)置［4］。在設(shè)置波特率和工作模式前，需要設(shè)置CAN_MCR 寄存器的INRQ 位，使CAN 進入初始化模式。 此外，還要設(shè)置INRQ 位為0，退出初始化模式。

4.1.2 CAN 報文收發(fā)模塊程序

CAN 報文收發(fā)模塊主要完成向CAN 總線發(fā)送測試請求報文、接收CAN 總線響應(yīng)數(shù)據(jù)。 STM32F103ZET6 有一個CAN 控制器，通過濾波器可以過濾掉標識符不符的CAN 報文，從而減少CPU 處理CAN 通信的開銷。

在進行簡單的CAN 初始化后，即可發(fā)送數(shù)據(jù)，首先聲明一個CAN 發(fā)送報文對象，設(shè)置標識符、幀類型、數(shù)據(jù)長度、要發(fā)送的數(shù)據(jù)，指定發(fā)送CAN 報文所使用的CAN 通道開始發(fā)送報文，循環(huán)檢測發(fā)送結(jié)束標志直至發(fā)送完成。

在接收CAN 報文時，先要檢查接收標志判斷是否有新消息，若有新數(shù)據(jù)則從相應(yīng)的FIFO 中讀取CAN 報文消息，提取ID、幀類型、數(shù)據(jù)長度、數(shù)據(jù)等信息，再清除接收標志位。

主控制器在接收到響應(yīng)報文后，將判斷其響應(yīng)類型并記錄接收時間，將響應(yīng)數(shù)據(jù)、設(shè)備號和時間等信息組成一幀數(shù)據(jù)上傳至服務(wù)器。

4.1.3 SD 卡存儲模塊

SD 卡控制器對SD 卡的初始化和讀寫是通過借助于SD 總線完成的，SD 總線有數(shù)據(jù)線DATA0～DATA3、命令線CMD 和時鐘線CLK 等構(gòu)成［5］。 SD 控制器通過命令線將命令發(fā)到SD 卡以完成某項操作，并接受來自SD 卡的響應(yīng)，分析后進行下一步操作［6］。

SD 卡初始化時，首先初始化與SD 卡連接的I／O 配置，上電并延時一段時間后發(fā)送CMD0 命令和CMD8 命令，判斷SD 卡是否支持SD 2.0 協(xié)議，此后發(fā)送ACMD41 命令，根據(jù)響應(yīng)判斷是標準容量SD卡、還是高容量的SD 存儲卡［7］。4.1.4 GPRS 模塊網(wǎng)絡(luò)通信程序

ATK-SIM900A 是ALIENTEK 推出的一款高性能工業(yè)級GSM／GPRS 模塊，支持RS232 串口和LVTTL 串口。 控制器向GPRS 模塊發(fā)送命令是通過AT 指令完成的，在進行通信時常用到的AT 指令見表1。

表1 GPRS 通信常用的AT 指令Tab.1 AT commands commonly used in GPRS communication

通過GPRS 傳輸數(shù)據(jù)時，首先確定通信的模式（TCP／UDP），然后通過AT+CIPSTART 指令發(fā)起連接，連接建立后發(fā)送AT+CIPSEND 指令，成功后再發(fā)送需要傳輸?shù)臄?shù)據(jù)。

GPRS 網(wǎng)絡(luò)通信程序主要負責測試終端和云端服務(wù)器的數(shù)據(jù)交互。 終端設(shè)備啟動后，將通過GPRS 向云端PyQt5 服務(wù)器程序發(fā)起連接請求，建立連接后將終端設(shè)備信息存儲到數(shù)據(jù)庫以供用戶查詢各終端設(shè)備的狀態(tài)。 在用戶選擇好終端設(shè)備后，終端設(shè)備向云端服務(wù)器發(fā)出查詢用戶是否啟動測試的指令，若用戶沒有開啟測試，將循環(huán)查詢，直至收到用戶啟動測試的信號；如果用戶已經(jīng)開啟測試，就會發(fā)出查詢用戶創(chuàng)建的測試用例和CAN 配置信息的指令，并將接收到的數(shù)據(jù)存入SD 卡。 數(shù)據(jù)接收完畢，將SD 卡中的數(shù)據(jù)取出構(gòu)建CAN 請求報文逐個發(fā)送至CAN 總線，當終端設(shè)備收到CAN 總線的響應(yīng)報文后，會通過GPRS 模塊發(fā)到云端數(shù)據(jù)庫，以便用戶可以即時查詢分析和下載。 測試終端和云端服務(wù)器之間的數(shù)據(jù)通信程序如圖7 所示。

圖7 測試終端和云端服務(wù)器間數(shù)據(jù)通信流程圖Fig.7 Flow chart of data communication between test terminal and cloud server

4.2 云端服務(wù)器軟件（與現(xiàn)場終端設(shè)備通信部分）設(shè)計實現(xiàn)

與現(xiàn)場終端設(shè)備通信部分服務(wù)器軟件用于監(jiān)聽各個終端設(shè)備的連接請求，連接成功后即可進行數(shù)據(jù)的傳輸，且支持多設(shè)備同時連接和數(shù)據(jù)傳輸。 程序主要流程是首先監(jiān)聽終端的連接請求，當有終端成功連接后創(chuàng)建一個線程單獨處理和該終端的通信。 該線程等待接收終端的數(shù)據(jù)，接收到數(shù)據(jù)之后解析數(shù)據(jù)并執(zhí)行相應(yīng)的操作，主要操作有向數(shù)據(jù)庫中存入該設(shè)備的信息以表示有新終端建立了連接，在數(shù)據(jù)庫中刪除該設(shè)備信息用于表示有設(shè)備停止了使用，查詢用戶是否選擇了該設(shè)備以便于決策是否繼續(xù)定時查詢，從數(shù)據(jù)庫中取出測試條例。 軟件的主線程和子線程流程圖如圖8、圖9 所示。

圖8 服務(wù)器程序主線程流程圖Fig.8 Flow chart of main thread of server program

圖9 服務(wù)器程序子線程流程圖Fig.9 Flow chart of main sub-thread of server program

4.3 數(shù)據(jù)傳輸協(xié)議

為保證數(shù)據(jù)的可靠傳輸，現(xiàn)場測試設(shè)備和云端服務(wù)器之間的通信采用TCP Socket 技術(shù)，云端服務(wù)器將測試用例打包發(fā)向現(xiàn)場測試終端，測試終端在啟動測試并收到響應(yīng)報文后會立即上傳至云端服務(wù)器。

云端服務(wù)器向現(xiàn)場測試設(shè)備傳輸?shù)臄?shù)據(jù)幀格式見表2。 由表2 可知，云端服務(wù)器向現(xiàn)場測試設(shè)備傳輸數(shù)據(jù)由設(shè)備號、數(shù)據(jù)有效個數(shù)、請求報文和校驗位構(gòu)成。

表2 云端服務(wù)器向現(xiàn)場測試設(shè)備傳輸?shù)臄?shù)據(jù)幀格式Tab.2 Data frame format transmitted from cloud server to field test equipment

現(xiàn)場測試設(shè)備向云端服務(wù)器傳輸?shù)臄?shù)據(jù)幀格式見表3。 由表3 可知，現(xiàn)場測試設(shè)備至云端服務(wù)器傳輸數(shù)據(jù)幀中數(shù)據(jù)塊部分包含一個請求報文和一個響應(yīng)報文以及每個報文的發(fā)送或接受時間和ID。

表3 現(xiàn)場測試設(shè)備向云端服務(wù)器傳輸?shù)臄?shù)據(jù)幀格式Tab.3 Data frame format transmitted from field test equipment to cloud server

5 實驗結(jié)果

測試均在實驗室環(huán)境下完成，終端設(shè)備通過USB-To-CAN 設(shè)備與電腦相連，電腦運行CANTest軟件用于接收和發(fā)送CAN 報文。 首先運行服務(wù)器軟件，打開終端設(shè)備和服務(wù)器建立連接，此時在網(wǎng)頁即可看到有新終端設(shè)備在線，選擇該設(shè)備后進入創(chuàng)建測試條例界面，創(chuàng)建完成后點擊開始測試，則在CANTest 上定時收到測試請求報文，給出響應(yīng)報文后在網(wǎng)頁也可以實時顯示出來。 通過編寫軟件模擬終端設(shè)備向服務(wù)器軟件循環(huán)發(fā)起連接，當連接數(shù)超過300 個時，終端設(shè)備仍可以正常收發(fā)數(shù)據(jù)且無明顯網(wǎng)絡(luò)延遲。 測試結(jié)果和測試系統(tǒng)實驗實物如圖10、圖11 所示。

圖10 測試結(jié)果顯示界面Fig.10 Web page of displaying test result

圖11 遠程測試系統(tǒng)試驗實物Fig.11 Test object of remote test system

6 結(jié)束語

本文研究的整車控制器遠程測試系統(tǒng)采用在網(wǎng)頁客戶端創(chuàng)建測試條例，全部發(fā)送到現(xiàn)場終端以后再開始逐個報文的發(fā)送，在發(fā)送每幀報文的同時記錄發(fā)送時間，接收到響應(yīng)報文后也同樣記錄接收時間并連同對應(yīng)的請求報文一起傳輸?shù)皆贫朔?wù)器，以便客戶端查看，避免了傳統(tǒng)從服務(wù)器到現(xiàn)場終端發(fā)送報文帶來的網(wǎng)絡(luò)延遲問題。 測試系統(tǒng)通過現(xiàn)場終端和云端服務(wù)器通信軟件的設(shè)計，支持多現(xiàn)場終端連接云端服務(wù)器，運行穩(wěn)定，且實時性高。 與汽車控制器硬件在環(huán)系統(tǒng)連接后即可對控制器進行遠程測試，實時讀取故障碼、汽車運行狀態(tài)信息以便實時監(jiān)測控制器控制策略的效果，方便調(diào)整控制策略。

未來工作中，可以圍繞遠程向硬件在環(huán)系統(tǒng)汽車控制器下載控制策略，遠程對控制器參數(shù)進行標定以及多任務(wù)協(xié)同對硬件在環(huán)中各控制器控制策略同時開發(fā)展開深入的研究。