新能源汽車遠程監(jiān)控標定的通信系統(tǒng)設計

陳眺+李思灝+楊健龍+鄭偉+周琳凱+曾潔+史昇

摘要：

汽車在出廠時參數(shù)標定便固定不變，但車輛長期運行會導致車輛控制參數(shù)不適應一些變化。隨著車聯(lián)網技術的發(fā)展，實現(xiàn)遠程監(jiān)控標定成為可能?；谛履茉雌囋O計了汽車參數(shù)遠程監(jiān)控標定的通信系統(tǒng)，實現(xiàn)了電控單元和云平臺之間的數(shù)據交換。首先對外部網絡和內部網絡的通信協(xié)議進行設計，然后通過LTE模塊發(fā)送AT指令控制其接入網絡，實現(xiàn)與云平臺監(jiān)控中心的連接與數(shù)據傳輸，最后通過命令解析程序，對云平臺監(jiān)控中心發(fā)送的命令進行校驗、解析并完成對應的命令操作。測試表明，該通信系統(tǒng)實現(xiàn)了電控單元和云平臺之間的數(shù)據實時交換。

關鍵詞：

電控單元；云平臺；通信協(xié)議；LTE模塊；AT指令

DOIDOI：10.11907/rjdk.172121

中圖分類號：TP319

文獻標識碼：A文章編號文章編號：1672-7800（2018）001-0108-05

Abstract：The calibration of existing vehicle parameters is fixed at the factory. With the rapid development of vehicle networking technology， it is possible to realize remote monitoring and calibration. Based on the new energy vehicle， a communication system for remote monitoring and calibration of vehicle parameters is designed， and the data exchange between the ECU and the cloud platform is realized. The paper first designs the communication protocol of the external network and the internal network， then transmits the AT instruction through the LTE module to control its access network， and realizes the connection and the data transmission with the cloud platform monitoring center. Finally， through the command analysis program， the received commands of the cloud platform monitoring center are checked， analyzed， and the corresponding command operation is completed. The test shows that the communication system designed in this paper can realize the data exchange between the electronic control unit and the cloud platform in real time.

Key Words：electronic control uni； cloud platform； communication protocol； LTE module； AT instruction

0引言

傳統(tǒng)新能源汽車電控單元控制參數(shù)標定固化在微控制器的閃存區(qū)內，這些參數(shù)基本不會修改。由于路況和駕駛習慣不同，隨著車輛的長期運行，電池損耗、機械老化、電氣設備和線路的老化、更換關鍵部件等，使原車輛控制參數(shù)不再合適，但將其全部返廠進行二次標定成本較高。

主流車輛遠程監(jiān)控采用外接車載終端，通過控制器局域網絡（Controller Area Network，CAN）總線，接入到汽車的電控單元或通過車載自動診斷系統(tǒng)（On Board Diagnostics，OBD）接口，獲取車輛數(shù)據和車輛故障碼，通過移動網絡將數(shù)據發(fā)送至遠程監(jiān)控中心，操作復雜，不具實時性。為了保證新能源汽車尤其是新能源動力電池汽車能夠安全、高效運行，實時監(jiān)控車輛的運行狀況，建立一套具有遠程監(jiān)控標定功能的新能源汽車電控系統(tǒng)十分必要。

1系統(tǒng)總體設計

為保證新能源汽車長期安全高效運行，基于云平臺的新能源汽車電控系統(tǒng)，在傳統(tǒng)電控系統(tǒng)基礎上加入無線通信和互聯(lián)網服務功能，以實現(xiàn)車輛的實時監(jiān)控、故障分析以及優(yōu)化參數(shù)、遠程標定等功能。監(jiān)控標定通信系統(tǒng)總體結構如圖1所示。

通信系統(tǒng)是核心模塊，由內部數(shù)據網絡和外部網絡通信協(xié)議、LTE數(shù)據通信程序以及命令解析程序3部分構成。其中通信協(xié)議實現(xiàn)汽車參數(shù)信息的打包發(fā)送，LTE模塊實現(xiàn)數(shù)據的高質量通信，命令解析程序對接收到的云平臺信息進行解析，從中得到有用數(shù)據。

2通信系統(tǒng)硬件設計

系統(tǒng)電控單元主要負責采集新能源汽車的工況信息，考慮到車輛運行位置的不確定性，因此采用移動通信網絡與云平臺監(jiān)控中心進行數(shù)據交互。我國LTE網絡已普及，相較于3G、GPRS等技術，其傳輸速率更高、穩(wěn)定性更好。在電控單元中加入LTE模塊，電控單元采集的數(shù)據按照規(guī)定的通信協(xié)議進行打包，利用內嵌TCP/IP協(xié)議的LTE模塊將數(shù)據發(fā)送至指定IP的監(jiān)控中心服務器，可接收監(jiān)控中心發(fā)出的各種命令請求。新能源汽車電控單元硬件結構如圖2所示。

通信管理MCU是整個電控單元通信系統(tǒng)最關鍵部分。為了滿足系統(tǒng)功能需求，方便硬件電路的設計及簡化功能程序開發(fā)，選擇一款合適的MCU十分必要。通信管理MCU需要從主控MCU中獲取車輛實時數(shù)據，然后驅動各通信模塊，將數(shù)據通過串口發(fā)送至各通信模塊。因此，該MCU應具備若干SCI或SPI接口及若干I/O通道，且具有較好的運算能力和中斷處理能力。結合以上分析，選擇飛思卡爾的MC9S12XEP100作為通信管理MCU。endprint

由于和云平臺監(jiān)控中心之間的數(shù)據通信必須遵循TCP/IP協(xié)議，因此需要選擇一款內置TCP/IP協(xié)議的LTE模塊，以避免自主編寫TCP/IP協(xié)議棧造成的麻煩。本文選用移遠公司的EC20 LTE模塊，其不僅支持LTE的FDD-LTE和TDD-LTE兩種制式，還可向下兼容UMTS、GPRS/GSM網絡，確保在缺乏3G和4G網絡的偏遠地區(qū)也能正常工作。其內置豐富的網絡協(xié)議，支持數(shù)據、語音、短信等業(yè)務。

3通信系統(tǒng)軟件設計

車輛數(shù)據和標定反饋命令由主控微處理器（Microcontroller Unit，MCU）打包發(fā)送至通信管理MCU，再由通信管理MCU利用LTE模塊發(fā)送AT指令至云平臺。云平臺發(fā)送的數(shù)據讀取命令先發(fā)送至通信管理MCU中，經過命令解析程序發(fā)送至主控MCU。

3.1通信協(xié)議設計

通信過程涉及到數(shù)據的二次傳輸，分為兩部分：①通信管理MCU通過通信模塊與云平臺數(shù)據交互的協(xié)議，稱為外部網絡通信協(xié)議；②通信管理MCU與主控MCU之間數(shù)據交互的協(xié)議，稱為內部網絡通信協(xié)議。

3.1.1外部網絡通信協(xié)議設計

外部網絡通信協(xié)議規(guī)定，每條消息都由消息標識、消息頭、消息體、校驗碼[1]、消息尾組成，消息結構如圖3所示。

其中，消息標識為每幀有效消息的開始辨識區(qū)，消息標識固定為0×2A，以0，1交替來降低誤碼率。若在消息頭或消息體中出現(xiàn)0×2A，可能會導致解析過程中消息識別出錯，所以需要對消息頭和消息體中出現(xiàn)的0×2A進行轉義處理。若消息頭或消息體中出現(xiàn)0×2A，則在數(shù)據封裝時將其轉義為0×28，并在后面緊跟0×01，若其后又出現(xiàn)0×28，則在0×28后緊跟0×02，這樣來避免數(shù)據解析時可能出現(xiàn)的錯誤。

消息頭包含設備編號/權限碼、消息ID和消息序號。當電控單元發(fā)送消息時，消息頭中添加的是設備編號，設備編號是每個電控單元具有的獨一無二的編號，在每幀數(shù)據中占6字節(jié)，方便上位機記錄數(shù)據，云平臺監(jiān)控中心發(fā)送消息時添加的是權限碼；消息ID在每幀數(shù)據中占2字節(jié)，它是每種消息的特定編號，如電控單元發(fā)送的車輛數(shù)據消息ID為0x9011。消息ID對應的消息類型及消息體格式如表1所示。消息序號在每幀數(shù)據中占2字節(jié)，按消息的發(fā)送順序從0開使循環(huán)累加，方便判斷是否有丟包現(xiàn)象發(fā)生。

消息體是車輛數(shù)據、命令和命令應答的具體內容。校驗碼占1個字節(jié)，從消息頭開始，每一字節(jié)同后一字節(jié)做異或運算，直到校驗碼前一字節(jié)停止。發(fā)送端和接收端都做校驗運算，以確保數(shù)據幀在傳輸過程中不出現(xiàn)差錯。

消息尾是一幀完整消息的結尾標志，消息尾固定為0×CC，以00，11交替來降低誤碼率。與消息標識類似，在消息頭和消息體出現(xiàn)0×CC時也需要進行轉義。若消息頭或消息體中出現(xiàn)0×CC，則在數(shù)據封裝時將其轉義為0×CB并在后面緊跟0×01，若后面又出現(xiàn)0×CB，則在該0×CB后緊跟0×02。

一幀標準的外部網絡通信協(xié)議消息示例如圖4所示。

3.1.2內部網絡通信協(xié)議設計

內部網絡通信協(xié)議的消息結構與外部網絡通信協(xié)議相同，只是消息標識、消息頭、消息尾內容有所不同。

內部網絡通信協(xié)議的消息標識固定為0×AA，若消息頭或消息體中出現(xiàn)0×AA，則在數(shù)據封裝時將其轉義為0×A8并在后面緊跟0×01，若其后又出現(xiàn)0×A8，則在該0×A8后緊跟0×02。消息尾固定為0×33，若消息頭或消息體中出現(xiàn)0×33，則在數(shù)據封裝時將其轉義為0×32并在后面緊跟0×01，若其后又出現(xiàn)0×32，則在該0×32后緊跟0×02。消息頭中只有命令碼或響應碼。

通信管理MCU和主控MCU通過UART串口連接，按照“通信管理MCU命令消息—主控MCU響應消息”流程通信。通信管理MCU發(fā)送的命令消息中，消息頭是命令碼，主控MCU反饋的響應消息中消息頭是響應碼，響應碼與對應的命令碼保持一致。命令消息與響應消息格式如表2所示。

3.2LTE數(shù)據通信程序設計

電控單元采用LTE模塊實現(xiàn)與云平臺監(jiān)控中心的連接與數(shù)據交互。本文設計的LTE通信功能基于移動EC20LTE模塊，通信管理MCU通過SCI串口向LTE模塊發(fā)送AT指令控制其接入網絡，完成數(shù)據傳輸。

3.2.1AT指令

本文AT指令指從終端設備TE（TerminalEquipment）向終端適配器TA（TerminalAdapter）發(fā)送的指令，以實現(xiàn)TE與ME（Mobile Equipment）的連接與信息交換，最終實現(xiàn)與移動網絡的通信；用戶通過AT指令實現(xiàn)設備呼叫、短信收發(fā)、數(shù)據通信等業(yè)務功能[2]，其原理如圖5所示。

AT的每一條指令都以字母AT開頭，并以字符串作為指令結尾，采用一問一答的響應方式，每條指令無論執(zhí)行成功與否，都會反饋響應信息。若一條指令執(zhí)行成功會反饋“OK”，執(zhí)行失敗會反饋“ERROR”，并提示對應的錯誤信息。

3.2.2LTE網絡連接程序設計

本文電控單元通過LTE無線模塊建立與云平臺監(jiān)控中心之間的網絡連接。首先，云平臺監(jiān)控中心建立一個具有公網IP的TCP服務端，并以固定端口號進行監(jiān)聽。LTE模塊根據云平臺監(jiān)控中心的服務端IP地址和相應的端口號與之建立TCP透傳連接。TCP透傳是將本地異步串行通信直接轉為基于TCP協(xié)議的網絡通信，實現(xiàn)不同串口設備在網絡上的通信。進入透傳模式后，設備既是客戶端也是服務端，數(shù)據可在兩個設備間實現(xiàn)透明雙向傳輸。LTE模塊網絡連接工作流程如圖6所示。

通過AT命令對LTE模塊進行控制步驟如下：①模塊初始化設置：模塊初始化已在系統(tǒng)初始化程序中執(zhí)行，故在此程序中無需再執(zhí)行；②接入網關的參數(shù)設置：通過指令AT+QICSGP=1，1，“WONET”，“”，“”，2設置接入網關參數(shù)，按指令順序其具體含義為：設置上下文的ID為1，協(xié)議類型為IPV4。鑒于模塊中的SIM卡采用的是聯(lián)通4GSIM卡，因此將APN設置為WONTE并將認證方式設置為CHAP方式；③激活配置參數(shù)：通過指令AT+QIACT=1激活上述配置的參數(shù)。指令中的1代表上下文的ID。配置激活后就建立了與外部網絡之間的PPP數(shù)據鏈路；④完成TCP數(shù)據透傳：當配置參數(shù)被激活，PPP連接完成后就可與云平臺監(jiān)控中心的TCP進行連接。endprint

通過指令AT+QIOPEN=1，1，“TCP”，“114.215.184.145”，7705，0，2[3]完成與云平臺監(jiān)控中心之間的TCP透傳連接。指令中首先將已激活的上下文ID寫入，再設置本次TCP連接的ID為1，并將云平臺監(jiān)控中心的服務端IP及端口號寫入指令中，最后填寫2將該TCP連接設置為透明傳輸模式。經過這些設置后可通過串口直接實現(xiàn)網絡數(shù)據的收發(fā)?？紤]到車輛移動過程中不可避免地會遇到信號較弱路段，導致與云平臺監(jiān)控中心服務端連接中斷，因此在程序中添加了TCP連接狀態(tài)檢測，在發(fā)送數(shù)據前，通過使用指令AT+QISTATE=1，實現(xiàn)對之前建立的ID為1的TCP連接狀態(tài)進行檢測。若連接斷開，程序將自動進行重連，以此保證連接的可靠性，盡量減少由于連接斷開導致的數(shù)據丟失。

3.3命令解析程序設計

命令解析程序用于對接收到的云平臺監(jiān)控中心發(fā)送的命令進行校驗、解析，完成對應的命令操作。當接收到云平臺監(jiān)控中心發(fā)送的命令后，進入中斷并調用命令解析程序。云平臺監(jiān)控中心發(fā)送的命令為MAP標定命令。對于MAP標定命令，經過校驗解析后，將MAP標定命令中的MAP數(shù)據按行列提取出來，并按照自定義內部通信協(xié)議格式重新封裝，通過串口轉發(fā)至主控MCU中。命令解析程序工作流程如圖7所示。

命令解析程序第一步是對接收的數(shù)據進行校驗，校驗程序可確認接收到的命令數(shù)據沒有在傳輸過程中出錯，從而執(zhí)行后續(xù)相關操作。首先設置校驗和變量的初始值。由于一幀數(shù)據中消息標識為第一個數(shù)，消息尾為最后一個數(shù)，校驗碼為數(shù)據幀中倒數(shù)第二個數(shù)，所以這3個數(shù)據可以不參與數(shù)據校驗。然后從數(shù)據幀中第二個數(shù)開始校驗，校驗的次數(shù)為數(shù)據幀長度減3，校驗方法為將初始校驗與當前校驗數(shù)據異或后再賦給校驗和。最后將最終的校驗和與數(shù)據幀中的校驗碼進行比較，獲得校驗結果的返回值。數(shù)據校驗程序流程如圖8所示。

4通信模塊測試

云平臺監(jiān)控中心服務器需要建立在具有公網IP的網絡上，并開啟遠程桌面訪問權限；在本地PC中通過輸入mstsc命令并輸入監(jiān)控中心的IP地址，實現(xiàn)本地PC對監(jiān)控中心服務器的遠程桌面控制。進入監(jiān)控中心服務器的遠程桌面后，使用“網絡調試助手”軟件，在監(jiān)控中心服務器上建立一個使用公網IP的TCP服務端，并在固定端口進行監(jiān)聽。

操作本地PC向LTE模塊發(fā)送相應的AT指令，建立LTE模塊與監(jiān)控中心服務器間的TCP連接，并向TCP連接的服務端發(fā)送一串車輛數(shù)據幀字符串。在遠程桌面的“網絡調試助手”中查看來自LTE模塊的數(shù)據，并向其返回一串字符。

由于LTE模塊只有一路異步串口，因此通過LTE模塊的USB口與上位機PC之間建立連接，配合驅動模擬異步串行通信，并在上位機PC中通過“串口調試助手”軟件向LTE模塊發(fā)送相應的AT指令，以實現(xiàn)LTE模塊與云平臺監(jiān)控中心服務器間的TCP連接，完成相應的數(shù)據傳輸[4]。LTE模塊與監(jiān)控中心服務器的TCP數(shù)據傳輸測試如圖9所示。

在LTE模塊與云平臺監(jiān)控中心服務器間的TCP通信測試AT指令含義為：

（1）AT+CPIN？；這條指令用于檢測SIM卡的工作狀態(tài)，模塊返回+CPIN：READY，證明SIM卡正常，已準備就緒[5]。

（2）AT+QICSGP=1，1，“WONET”，“”，“”，2；該指令用于設置網絡的上下文參數(shù)，其中首先將上下文ID設置為1。由于使用了聯(lián)通SIM卡，因此接入點設置為WONET，最后將認證方式設置為CHAP。

（3）AT+QIACT=1；該命令的作用是將剛設置好的ID為1的上下文參數(shù)激活。

（4）AT+QIACT？；該命令是查詢已激活上下文參數(shù)狀態(tài)，模塊會返回已激活的上下文參數(shù)的具體信息。

（5）AT+QIOPEN=1，0，“TCP”，“123.57.41.13”，8080，0，2；該指令建立與監(jiān)控中心服務器的TCP連接，并將模塊設置為透傳模式[6]。其中，TCP服務端的IP地址為“123.57.41.13”，且監(jiān)聽端口為8080，連接成功后模塊返回CONNECT。

TCP連接成功并且模塊進入透傳模式后，模塊從串口接收到的數(shù)據會直接轉發(fā)至監(jiān)控中心服務器，輸入一串模擬車輛數(shù)據幀字符串并發(fā)送出去，在遠程桌面的“網絡調試助手”中會收到這串字符，并通過“網絡調試助手”輸入received發(fā)送給模塊，本地PC的串口助手中就會顯示出來。

5結語

本文通過LTE模塊進行電控單元和云平臺的無線數(shù)據通信，直接采用車輛電控單元通過無線通信方式實現(xiàn)與外界數(shù)據交互。測試表明，本文設計的通信系統(tǒng)實現(xiàn)了新能源汽車電控單元和云平臺之間的數(shù)據通信，電控單元采集的汽車數(shù)據可以實時、準確地傳輸?shù)皆破脚_，以快捷低成本的方式實現(xiàn)了汽車參數(shù)的監(jiān)控和標定。

參考文獻：

[1]林效峰.基于超聲波的交互式電子白板電路設計[D].武漢：華中師范大學，2014.

[2]吳晶晶.純電動汽車車載信息的采集與遠程監(jiān)測系統(tǒng)的研發(fā)[D].南昌：南昌大學，2011.

[3]呂昕暉.施工升降機遠程監(jiān)控系統(tǒng)研究與開發(fā)[D].濟南：山東大學，2015.

[4]王水源.基于Wince的車輛導航監(jiān)控系統(tǒng)設計[D].蘭州：蘭州交通大學，2013.

[5]梁朝喜.嵌入式塔吊安全監(jiān)控系統(tǒng)的開發(fā)[D].成都：電子科技大學，2013.

[6]王藝愷，李陽節(jié)，周少甫，等.一種基于物聯(lián)網的公交車信息查詢系統(tǒng)設計[J].電子科技，2012，25（10）：32-35.

（責任編輯：杜能鋼）endprint