基于云平臺(tái)的新能源汽車電控系統(tǒng)通信設(shè)計(jì)*

，，，，，

(1.大連交通大學(xué)， 大連 116028；2.大連理工大學(xué)；3.鎮(zhèn)江恒馳科技有限公司)

基于云平臺(tái)的新能源汽車電控系統(tǒng)通信設(shè)計(jì)*

沈世輝1，周琳凱1，曾奕哲2，史昇3，曾潔1，郭永偉1

(1.大連交通大學(xué)， 大連 116028；2.大連理工大學(xué)；3.鎮(zhèn)江恒馳科技有限公司)

為解決新能源汽車的安全監(jiān)控和能量優(yōu)化控制問題，提出了一種具有遠(yuǎn)程監(jiān)控和標(biāo)定功能的新能源汽車電控系統(tǒng)設(shè)計(jì)方案。該系統(tǒng)主要針對新能源汽車電控系統(tǒng)的網(wǎng)絡(luò)通信功能硬件電路進(jìn)行設(shè)計(jì)，利用云平臺(tái)實(shí)現(xiàn)電控單元與手機(jī)間的無線數(shù)據(jù)通信，通過LTE/WiFi模塊可實(shí)現(xiàn)電控單元與云平臺(tái)間的數(shù)據(jù)交互。電控單元通過WiFi或藍(lán)牙模塊與手機(jī)建立連接后，通過車輛監(jiān)控客戶端對電控單元發(fā)送的數(shù)據(jù)進(jìn)行解析和存儲(chǔ)，實(shí)時(shí)掌握車輛狀況。

新能源汽車；監(jiān)控與標(biāo)定；LTE；WiFi；藍(lán)牙

引 言

當(dāng)今社會(huì)，傳統(tǒng)汽車的數(shù)量不斷增多,帶來的能源消耗和尾氣排放污染等問題日益凸出，發(fā)展新能源汽車變得尤為重要。由于新能源汽車使用了新能源動(dòng)力裝置及一些新的技術(shù)，所以其技術(shù)上還不像傳統(tǒng)汽車那樣成熟，從而導(dǎo)致新能源汽車的安全事故頻發(fā)[1]。為了保證新能源汽車能夠安全、高效地運(yùn)行，基于云平臺(tái)的新能源汽車電控系統(tǒng)在傳統(tǒng)電控系統(tǒng)的基礎(chǔ)上增加了無線通信和互聯(lián)網(wǎng)服務(wù)功能，以期實(shí)現(xiàn)車輛的實(shí)時(shí)監(jiān)控、故障診斷分析及參數(shù)優(yōu)化、遠(yuǎn)程標(biāo)定等諸多功能。

基于云平臺(tái)的新能源汽車電控系統(tǒng)的總體結(jié)構(gòu)如圖1所示。該通信系統(tǒng)主要功能是實(shí)現(xiàn)新能源汽車的遠(yuǎn)程監(jiān)控與優(yōu)化標(biāo)定。直接采用新能源汽車電控單元作為車輛數(shù)據(jù)的采集裝置，并利用其無線通信功能實(shí)現(xiàn)與手機(jī)和云平臺(tái)之間的數(shù)據(jù)通信，形成手機(jī)+云端對車輛的雙重監(jiān)控模式；云平臺(tái)可對電控單元上傳的海量車輛數(shù)據(jù)進(jìn)行分析處理，生成優(yōu)化控制參數(shù)并對電控單元進(jìn)行遠(yuǎn)程優(yōu)化標(biāo)定[2]。

圖1 基于云平臺(tái)的新能源汽車電控系統(tǒng)總體結(jié)構(gòu)

1 通信系統(tǒng)硬件設(shè)計(jì)

1.1 電控單元結(jié)構(gòu)設(shè)計(jì)

電控系統(tǒng)硬件結(jié)構(gòu)如圖2所示。

圖2 基于云平臺(tái)的新能源汽車電控單元硬件結(jié)構(gòu)

整個(gè)系統(tǒng)由三大部分構(gòu)成，分別是基于云平臺(tái)的新能源汽車電控單元、Android手機(jī)車輛監(jiān)控客戶端以及云平臺(tái)監(jiān)控中心。電控單元主要負(fù)責(zé)對整個(gè)車輛的控制，它需要采集新能源汽車的工況數(shù)據(jù)，為車輛的運(yùn)行控制提供決策依據(jù)，包括電機(jī)狀態(tài)參數(shù)(轉(zhuǎn)速、電壓、電流、溫度等)、動(dòng)力電池狀態(tài)參數(shù)(電壓、電流、溫度、剩余電量)、駕駛員輸入信號(加速踏板開度、制動(dòng)踏板開度、方向盤轉(zhuǎn)角)等。另外，電控單元將采集到的車輛工況數(shù)據(jù)按照規(guī)定的通信協(xié)議進(jìn)行打包并發(fā)送至Android智能手機(jī)或上傳至云平臺(tái)監(jiān)控中心。Android手機(jī)監(jiān)控客戶端作為整個(gè)系統(tǒng)的中間環(huán)節(jié)[3]。當(dāng)手機(jī)接收到電控單元發(fā)送的數(shù)據(jù)后，進(jìn)行協(xié)議解析并將這些實(shí)時(shí)數(shù)據(jù)顯示給用戶，若在手機(jī)連入互聯(lián)網(wǎng)的情況下可將接收到的數(shù)據(jù)實(shí)時(shí)地上傳至云平臺(tái)監(jiān)控中心，當(dāng)手機(jī)沒有連入互聯(lián)網(wǎng)時(shí)，將數(shù)據(jù)按接收時(shí)間緩存至手機(jī)數(shù)據(jù)庫中，待手機(jī)接入網(wǎng)絡(luò)后可手動(dòng)將緩存的數(shù)據(jù)進(jìn)行上傳?？蛻舳诉€可實(shí)現(xiàn)本地歷史數(shù)據(jù)查詢和配置電控單元連接無線熱點(diǎn)的功能。云平臺(tái)監(jiān)控中心收到電控單元上傳的數(shù)據(jù)后可通過監(jiān)控平臺(tái)進(jìn)行顯示以實(shí)現(xiàn)對車輛的遠(yuǎn)程監(jiān)控，同時(shí)將數(shù)據(jù)存儲(chǔ)在云平臺(tái)，根據(jù)車輛數(shù)據(jù)進(jìn)行分析判斷車輛是否發(fā)生故障；云平臺(tái)還根據(jù)長期累積的海量數(shù)據(jù)進(jìn)行分析和計(jì)算，以生成符合當(dāng)前車輛狀況的控制參數(shù)，最后通過監(jiān)控平臺(tái)向電控單元發(fā)送標(biāo)定命令以實(shí)現(xiàn)車輛的遠(yuǎn)程標(biāo)定，從而提高車輛的運(yùn)行效率和駕駛舒適性。

通信系統(tǒng)采用飛思卡爾(現(xiàn)被NXP收購)的MC9S12XEP100型芯片作為通信管理MCU。該芯片廣泛應(yīng)用于汽車電子領(lǐng)域，作為飛思卡爾16位MCU的旗艦型號，它擁有豐富的片上資源和強(qiáng)大的運(yùn)算能力，不僅具有32位MCU的性能，并且還保留了S12X系列MCU的低成本、低功耗和高效的代碼率等優(yōu)勢。

1.2 LTE模塊接口電路

在車輛附近沒有無線熱點(diǎn)的情況下，就需要通過LTE移動(dòng)通信模塊實(shí)現(xiàn)與云平臺(tái)監(jiān)控中心間的數(shù)據(jù)通信[4]。本設(shè)計(jì)選用移遠(yuǎn)公司的EC20 LTE通信模塊。該模塊不僅支持LTE的兩種制式FDD-LTE和TDD-LTE，還可向下兼容UMTS，GPRS/GSM網(wǎng)絡(luò)，確保在缺乏3G和4G網(wǎng)絡(luò)的偏遠(yuǎn)地區(qū)也能正常工作，其內(nèi)置豐富的網(wǎng)絡(luò)協(xié)議，支持?jǐn)?shù)據(jù)、語音、短信等業(yè)務(wù)。

EC20模塊的基本電路如圖3所示，包括開機(jī)信號、旁路濾波電容、工作狀態(tài)指示燈及復(fù)位電路。使用電源模塊提供的3.3 V電源，旁路濾波電容電路應(yīng)盡量靠近模塊的供電引腳；PWRKEY引腳為開機(jī)信號引腳，與MCU的PA5相連，通過PA5輸出不少于1 s的高電平信號,從而開啟LTE模塊；STATUS為工作狀態(tài)指示引腳，與MCU的PA6連接，當(dāng)LTE模塊上電后長時(shí)間沒有進(jìn)行任何操作就會(huì)自動(dòng)進(jìn)入休眠狀態(tài)，MCU根據(jù)STATUS引腳的狀態(tài)判斷LTE模塊是否為休眠狀態(tài)；WAKEUP_IN為休眠喚醒引腳，默認(rèn)為上拉狀態(tài)，與MCU的PB2連接，當(dāng)MCU檢測出LTE為休眠狀態(tài)，通過PB2輸出低電平喚醒模塊。

圖3 EC20模塊的基本電路

1.3 WiFi模塊接口電路

WiFi模塊不僅要實(shí)現(xiàn)與云平臺(tái)監(jiān)控中心間的無線通信，也要與手機(jī)之間完成數(shù)據(jù)交互。其中，與云平臺(tái)的交互需要通過連接無線熱點(diǎn)來實(shí)現(xiàn)，而與手機(jī)的通信是通過WiFi-Direct模式來實(shí)現(xiàn),所以選用的WiFi模塊需要支持STA和WiFi-Direct兩種工作模式[5]。又綜合考慮模塊的工作環(huán)境，故本設(shè)計(jì)的WiFi模塊采用Redpine Signals公司的RS-WC-201工業(yè)級WiFi模塊。

WiFi模塊的基本電路如圖4所示。

RS-WC-201模塊使用3.3 V電源，其中，WLAN-

ACTIVITY為WLAN工作指示引腳，當(dāng)有數(shù)據(jù)通過無線進(jìn)行傳輸時(shí)引腳輸出高電平，使指示燈閃爍。MOD_SEL0～MOD_SEL2為通信方式選擇引腳，通過連接撥碼開關(guān)，可選擇將這些引腳的電平拉高或者接地，當(dāng)MOD_SEL2=0，MOD_SEL1=0，MOD_SEL0=1就選擇了SPI通信模式，當(dāng)這三個(gè)引腳全部接地就選擇了UART通信模式。SPI_MISO、SPI_MOSI、SPI_CLK、SPI_CS是 RS-WC-201模塊的SPI通信接口引腳，RS-WC-201模塊作為從設(shè)備與MCU的SPI接口的PS4～PS7引腳連接。INTR是RS-WC-201模塊的中斷觸發(fā)引腳，與MCU的外部中斷引腳IRQ(PE1)連接，當(dāng)RS-WC-201模塊向MCU發(fā)送命令響應(yīng)或數(shù)據(jù)時(shí)會(huì)通過該引腳觸發(fā)MCU的中斷。

圖4 RS-WC-201 BEL模塊的基本電路

為了方便上位機(jī)對模塊進(jìn)行調(diào)試，模塊的UART接口用于和上位機(jī)進(jìn)行通信，而模塊與上位機(jī)接口電平標(biāo)準(zhǔn)不同，所以采用串口通信驅(qū)動(dòng)芯片MAX232將模塊的TTL電平轉(zhuǎn)換成PC可識(shí)別的邏輯電平，UART_RXD經(jīng)MAX232轉(zhuǎn)換后接PC端的TXD，UART_TXD經(jīng)MAX232轉(zhuǎn)換后接PC端的RXD。

1.4 藍(lán)牙模塊接口電路

藍(lán)牙模塊主要實(shí)現(xiàn)與手機(jī)間的數(shù)據(jù)交互。藍(lán)牙功能的實(shí)現(xiàn)方案主要有兩種:采用藍(lán)牙芯片或串口藍(lán)牙模塊。藍(lán)牙芯片需要使用者對芯片進(jìn)行底層程序編寫并根據(jù)藍(lán)牙通信協(xié)議對數(shù)據(jù)消息進(jìn)行特定的編碼，增加了開發(fā)人員的工作量，并且代碼的可移植性差。但串口藍(lán)牙模塊將藍(lán)牙通信協(xié)議提供的接口直接封裝為藍(lán)牙轉(zhuǎn)串口的通信接口，可以通過串口連接到MCU上，只需要根據(jù)串口通信協(xié)議進(jìn)行編程，增加了軟件開發(fā)的靈活性和可移植性[6]。故本文采用蜂匯物聯(lián)公司的蜂匯B-004 BEL透傳模塊。

B-004 BEL透傳模塊支持藍(lán)牙4.0協(xié)議，具有無線信號覆蓋距離遠(yuǎn)、低功耗、抗干擾能力強(qiáng)等特點(diǎn)，符合本設(shè)計(jì)的需要。B-004 BEL的基本電路如圖5所示。藍(lán)牙模塊使用電源模塊提供的3.3 V電源，模塊的CMD引腳是透傳/命令控制引腳與MCU的PB3連接，當(dāng)CMD為低電平表示MCU向模塊發(fā)送的為配置命令，CMD為高電平表示MCU向模塊發(fā)送的為具體透傳數(shù)據(jù)；CONN為模塊狀態(tài)指示引腳，與MCU的PB4連接，若輸出高電平表示藍(lán)牙模塊已與其他設(shè)備建立了連接，MCU可根據(jù)此引腳判斷藍(lán)牙模塊的連接狀態(tài)進(jìn)而執(zhí)行相應(yīng)的操作；SET為恢復(fù)出廠設(shè)置引腳，默認(rèn)上拉，當(dāng)按下按鈕被拉低至少2 s后將藍(lán)牙的參數(shù)設(shè)置恢復(fù)到出廠狀態(tài)。RESET為模塊復(fù)位引腳，其電路及操作與SET類似。SLEEP為模塊的睡眠控制引腳，與MCU的PB5連接，當(dāng)該引腳被由低拉高即使模塊進(jìn)入待機(jī)模式，從而停止掃描或斷開連接，當(dāng)引腳被由高拉低，模塊被喚醒，可重新開啟廣播或掃描指定設(shè)備，MCU由此可根據(jù)情況控制模塊的工作狀態(tài)。CTS和RTS引腳分別連接MCU的PB6和PB7，在MCU向模塊發(fā)送數(shù)據(jù)前300 μs，拉低RTS引腳，當(dāng)數(shù)據(jù)發(fā)送結(jié)束后將RTS拉高。

圖5 B-004 BEL模塊的基本電路

2 系統(tǒng)軟件流程設(shè)計(jì)

根據(jù)對系統(tǒng)功能需求和工作流程的研究與分析，并基于電控單元的通信系統(tǒng)硬件電路設(shè)計(jì)，開發(fā)了通信系統(tǒng)軟件，該軟件通過主程序調(diào)用各功能子程序來實(shí)現(xiàn)系統(tǒng)的各項(xiàng)功能。電控單元通信系統(tǒng)主程序按工作流程可分為兩部分：

① 系統(tǒng)初始化程序：主程序中首先執(zhí)行的是系統(tǒng)初始化程序，在硬件上電開機(jī)后這部分程序只運(yùn)行一次。系統(tǒng)初始化程序主要完成通信管理MCU的初始化以及對各通信模塊初始工作狀態(tài)的設(shè)置，為后續(xù)各功能的實(shí)現(xiàn)做好充分的準(zhǔn)備[8]。

② 循環(huán)執(zhí)行的功能程序：該部分程序在硬件上電后處于循環(huán)執(zhí)行狀態(tài)，主要是對各模塊的連接狀態(tài)進(jìn)行判斷，根據(jù)情況通過調(diào)用不同功能的子程序來實(shí)現(xiàn)系統(tǒng)的具體功能。通信系統(tǒng)軟件的主要子程序包括LTE網(wǎng)絡(luò)連接程序、WiFi-STA模式網(wǎng)絡(luò)連接程序、WiFi-Direct模式手機(jī)連接程序、命令解析程序。由于藍(lán)牙模塊工作在從機(jī)狀態(tài)，由手機(jī)主動(dòng)對其發(fā)起配對請求，而模塊會(huì)自動(dòng)處理配對請求和連接建立的過程，因此不需再對藍(lán)牙的連接程序進(jìn)行設(shè)計(jì)。通信系統(tǒng)軟件的主程序工作流程如圖6所示。

3 功能測試

系統(tǒng)功能測試主要包括兩個(gè)方面:一方面是電控單元通信系統(tǒng)與云平臺(tái)間的通信功能測試;另一方面是電控單元通信系統(tǒng)與智能手機(jī)間的通信功能測試。電控單元的通信系統(tǒng)實(shí)驗(yàn)板實(shí)物如圖7所示。

3.1 通信系統(tǒng)與云平臺(tái)間的通信功能測試

本設(shè)計(jì)中電控單元可以通過LTE模塊或WiFi模塊實(shí)現(xiàn)與云平臺(tái)監(jiān)控中心間的通信。

首先對LTE網(wǎng)絡(luò)通信功能測試。測試的方法為：由于LTE模塊只有一路異步串口，因此通過LTE模塊的USB口與上位機(jī)PC之間建立連接，配合驅(qū)動(dòng)模擬異步串行通信[7]。并在上位機(jī)PC中通過“串口調(diào)試助手”軟件向LTE模塊發(fā)送相應(yīng)的AT指令，以實(shí)現(xiàn)LTE模塊與云平臺(tái)監(jiān)控中心服務(wù)器間的TCP連接，并完成相應(yīng)的數(shù)據(jù)傳輸。LTE模塊與云平臺(tái)監(jiān)控中心服務(wù)器間的數(shù)據(jù)傳輸測試如圖8所示。

其次對 WiFi-STA模式網(wǎng)絡(luò)通信功能測試。電控單元要實(shí)現(xiàn)通過WiFi與云平臺(tái)監(jiān)控中心建立網(wǎng)絡(luò)連接，首先需要將WiFi模塊切換到WiFi-STA模式下，最終通過連接無線熱點(diǎn)的方式實(shí)現(xiàn)網(wǎng)絡(luò)通信。

WiFi模塊的測試方法與LTE模塊相類似，由于WiFi模塊通過SPI與電控單元的通信管理MCU進(jìn)行通信，因此預(yù)留的異步串口可專門用于上位機(jī)測試。當(dāng)WiFi模塊使用SPI通信時(shí)，控制WiFi模塊需要使用固定格式的數(shù)據(jù)幀，但WiFi模塊使用UART進(jìn)行通信時(shí)，控制WiFi模塊是通過AT指令來實(shí)現(xiàn)的。

圖6 主程序工作流程圖

圖7 通信系統(tǒng)實(shí)驗(yàn)板實(shí)物

圖8 LTE模塊與監(jiān)控中心服務(wù)器的TCP數(shù)據(jù)傳輸測試

3.2 通信系統(tǒng)與手機(jī)間的通信功能測試

本設(shè)計(jì)中電控單元可以通過WiFi模塊或藍(lán)牙模塊實(shí)現(xiàn)與手機(jī)間的通信，因此與手機(jī)的通信測試也分為兩部分。

首先是WiFi-Direct模式與手機(jī)通信功能測試。測試的方法為：WiFi模塊與上位機(jī)PC通過串口連接，并在上位機(jī)PC中通過“串口調(diào)試助手”軟件向WiFi模塊發(fā)送相應(yīng)的AT指令，以實(shí)現(xiàn)WiFi模塊與手機(jī)間的連接，并完成相應(yīng)的數(shù)據(jù)傳輸[8]。由于手機(jī)客戶端的數(shù)據(jù)接收程序運(yùn)行在子線程中，因此需要將手機(jī)與上位機(jī)PC通過USB連接，并進(jìn)入調(diào)試模式，通過Eclipse中的logcat來顯示具體收到的數(shù)據(jù)。WiFi模塊與手機(jī)間的數(shù)據(jù)傳輸測試如圖9所示。

其次是藍(lán)牙與手機(jī)通信功能測試。測試的方法為：通過USB轉(zhuǎn)串口數(shù)據(jù)線實(shí)現(xiàn)藍(lán)牙模塊與上位機(jī)PC的串口通信連接，并在上位機(jī)PC中通過“串口調(diào)試助手”軟件向藍(lán)牙模塊發(fā)送相應(yīng)的命令幀，進(jìn)行藍(lán)牙模塊的參數(shù)設(shè)置。當(dāng)手機(jī)主動(dòng)與藍(lán)牙模塊建立連接后，通過“串口調(diào)試助手”向手機(jī)發(fā)送數(shù)據(jù)，并通過Eclipse中的logcat來顯示具體收到的數(shù)據(jù)。

圖9 WiFi模塊與手機(jī)的數(shù)據(jù)傳輸測試

結(jié) 語

[1] 于泳.電動(dòng)汽車運(yùn)行狀態(tài)參數(shù)的遠(yuǎn)程監(jiān)控系統(tǒng)的研究與實(shí)現(xiàn)[D].大連:大連交通大學(xué),2015.

[2] 崔正杰,劉南杰,趙海濤.基于管-云-端結(jié)構(gòu)的汽車遠(yuǎn)程實(shí)時(shí)監(jiān)控系統(tǒng)設(shè)計(jì)[J].微型機(jī)與應(yīng)用,2014(24):91-94.

[3] 茍霞.基于Android平臺(tái)的車輛監(jiān)控系統(tǒng)研究與實(shí)現(xiàn)[D].西安:西安科技大學(xué),2013.

[4] 李靈玲.基于LTE的列車無線定位方法研究[D].北京:北京交通大學(xué),2014.

[5] 史寧寧.基于WiFi Direct的移動(dòng)共享和通訊平臺(tái)的設(shè)計(jì)與實(shí)現(xiàn)[D].西安:長安大學(xué),2014.

[6] Camps-Mur D,Garcia-Saavedra A,Serrano P.Device-to-device communications with WiFi Direct: overview and experimentation[J].Wireless Communications IEEE,2013,20(3):96-104.

[7] 吳晶晶.純電動(dòng)汽車車載信息的采集與遠(yuǎn)程監(jiān)測系統(tǒng)的研發(fā)[D].南昌:南昌大學(xué),2011.

[8] 周麗琛.用于電動(dòng)汽車電池管理系統(tǒng)的遠(yuǎn)程監(jiān)控系統(tǒng)研究[D].哈爾濱:哈爾濱工業(yè)大學(xué),2013.

硬件斷點(diǎn)設(shè)置后，每一條新指令的地址都會(huì)與硬件斷點(diǎn)進(jìn)行比較，判斷是否滿足條件，如果滿足，那么就會(huì)觸發(fā)Debug中斷，從Debug ROM開始執(zhí)行，并直接進(jìn)入循環(huán)等待狀態(tài)，從用戶角度，F(xiàn)reedom E310由于觸發(fā)斷點(diǎn)進(jìn)入了停止運(yùn)行狀態(tài)。

4.5 軟件斷點(diǎn)實(shí)現(xiàn)過程分析

用戶在Telnet或者GDB中輸入bp命令，后面不加上參數(shù)hw，就表示設(shè)置的是軟件斷點(diǎn)，該命令被送入OpenOCD，后者首先通過Debug Bus Access寄存器將斷點(diǎn)處的指令讀取到并保存，隨后通過Debug Bus Access寄存器將斷點(diǎn)處的指令替換為EBREAK。

當(dāng)Freedom E310執(zhí)行到斷點(diǎn)處時(shí)，實(shí)際執(zhí)行的是EBREAK指令，該指令引發(fā)Debug中斷，F(xiàn)reedom E310轉(zhuǎn)移至Debug ROM開始執(zhí)行，并直接進(jìn)入循環(huán)等待狀態(tài)，從用戶角度，F(xiàn)reedom E310由于觸發(fā)斷點(diǎn)進(jìn)入了停止運(yùn)行狀態(tài)。

結(jié) 語

參考文獻(xiàn)

[1] Waterman A.The RISC-V Instruction Set Manual, Volume I:User-Level ISA,Version 2.1[S],2016.

[2] SiFive Inc.SiFive E3 Coreplex Series Manual,Version1.2[EB/OL]. [2017-04].https://dev.sifive.com/documentation/e3-coreplex-series-manual/.

[3] SiFive Inc.SiFive FE310-G000 Manual, Version1.0.1[EB/OL].[2017-04].https://dev.sifive.com/documentation/freedom-e310-g000-manual/.

[4] RISC-V External Debug Support, Version 0.13[EB/OL].[2017-04]. https://dev.sifive.com/documentation/risc-v-external-debug-support-0-11/.

[5] OpenOCD User Guide,for release 0.10.0-dev[EB/OL].[2017-04].http://openocd.org/doc-release/html/index.html.

雷思磊(工程師)，研究方向?yàn)樘幚砥骷軜?gòu)、嵌入式處理器應(yīng)用等。

(責(zé)任編輯：薛士然 收稿日期：2017-04-28)

New Energy Vehicles Electronic Control System Communication Design Based on Cloud Platform

ShenShihui1,ZhouLinkai1,ZengYizhe2,ShiSheng3,ZengJie1,GuoYongwei1

(1.School of Dalian Jiaotong University,Dalian 116028,China;2.Dalian University of Technology;3.Zhenjiang Hents Technologies Inc.)

To solve the problem of safety monitoring and energy optimization control of the new energy vehicles,a control system with the function of remote monitoring and calibration is put forward.The system is mainly designed for the hardware circuits of network communication functions of new energy vehicles,and uses the cloud platform to communicate the wireless data between electronic control system and cell phone,and the data interaction between the electronic control unit and the cloud platform can be achieved through LTE/WiFi module.After the connection between electronic control unit and mobile phone is established by WiFi or bluetooth module,the vehicle monitoring client analyzes and stores the data sent by the electronic control unit,then the real-time status of vehicle can be monitored.

new energy vehicles;monitoring and calibration;LTE;WiFi;Bluetooth

2016年遼寧省自然基金(項(xiàng)目編號：201602116)；2015年江蘇省科技計(jì)劃項(xiàng)目(項(xiàng)目編號：BE2015132)。

TP277

: A

2017-05-22)