基于dSPACE的電動汽車通信協(xié)議的研究與仿真

彭飛帆，李曉倩，曹 銘,2

(1.南昌大學，江西南昌 330031；2.江西省汽車電子工程技術(shù)研究中心，江西南昌 330031)

隨著電動汽車快速發(fā)展，充電設施也在迅速普及。電動汽車電池組設計不同，充電協(xié)議設計往往存在差異，可能會造成充電設施無法兼容。以非車載充電機為例，由于充電通信協(xié)議不統(tǒng)一，充電機只能配套用于指定廠家電動汽車。

為了推動電動汽車充電方式標準化，實現(xiàn)不同品牌規(guī)格電動汽車與充電機互聯(lián)互通，國家出臺相關(guān)標準，建立了比較完善的標準體系。但標準中存在少數(shù)非車載充電機與BMS 通信協(xié)議不兼容現(xiàn)象[1-2]。BMS 與充電機之間的正常通信是保證充電設施與電動汽車正常安全高效工作的關(guān)鍵，BMS 與充電機的通信測試也是充電時必不可少步驟，同時也能驗證協(xié)議實現(xiàn)與協(xié)議標準的一致性，降低協(xié)議實現(xiàn)在實際運用時的錯誤率[3]。

本文設計了基于dSPACE 的BMS 充電協(xié)議開發(fā)測試平臺,建立了基于Simulink 的BMS 端充電模型及策略，在dSPACE 上實現(xiàn)BMS 與充電機通信模擬，驗證了BMS 充電模型兼容性。

1 dSPACE 實時仿真平臺

dSPACE 實時仿真平臺是由德國dSPACE公司開發(fā)的一套基于MATLAB/Simulink 的控制系統(tǒng)在實時環(huán)境下的開發(fā)及測試工作平臺，實現(xiàn)了和MATLAB/Simulink/RTW 等上位機軟件的無縫連接[4]。本章將對dSPACE 的軟硬件組成以及基于dSPACE的充電通信仿真平臺的總體結(jié)構(gòu)進行簡單介紹。

1.1 dSPACE 的軟件與硬件

dSPACE 實時仿真平臺由兩大部分組成，一是硬件系統(tǒng)，二是軟件環(huán)境。本實驗環(huán)境所使用的dSPACE 的硬件主要由快速原型單板系統(tǒng)、CAN 通訊板卡和電源等組成。其中快速原型單板系統(tǒng)核心組成為DS1103 主控制器板，其采用了主頻為250 MHz 的MPC8240 PPC 處理器；內(nèi)置4×16 位、4×12 位AD 轉(zhuǎn)換器和8×16 位DA 轉(zhuǎn)換器；配置有20 路并行I/O；包含RS232/RS422/RS485 串行接口等。

dSPACE 的軟件環(huán)境主要包括兩部分，一部分是實時代碼的生成和下載軟件RTI(Real-Time Interface)，它是離線工具與實時工具的接口，能夠完美地集成于MATLAB/Simulink，實現(xiàn)從Simulink 模型到dSPACE 實時硬件代碼的自動下載；另一部分是實時測試軟件Controldesk、實時處理器通信軟件CUB 以及自動試驗和參數(shù)調(diào)整軟件MLIB/MTRACE等[5]。

1.2 充電通信仿真的總體結(jié)構(gòu)

由圖1 可以比較直觀地看出整個仿真的基本流程：首先在MATLAB/Simulink 軟件中搭建充電模型，通過RTI 實時接口與dSPACE 仿真機相關(guān)聯(lián)，然后使用Controldesk 實現(xiàn)對仿真的控制和監(jiān)控，并通過CANTesk 來觀察模擬通訊過程。

圖1 仿真基本流程

根據(jù)仿真實驗所需條件，在實驗室搭建了基于dSPACE的通信仿真平臺，平臺實物圖如圖2 所示。實驗平臺包括dSPACE 快速原型單板系統(tǒng)DS1103 板卡、板卡接口、USBCAN-2E-U 以及計算機控制平臺。

圖2 實驗平臺實物圖

2 充電機與BMS 的通信協(xié)議實現(xiàn)

2.1 通信協(xié)議總體流程

為了保證一致性，GB/T 27930-2015 規(guī)定了非車載充電機與BMS 之間通信的基本步驟。如圖3 所示，整個充電過程包括物理連接完成、低壓輔助上電、充電握手、充電參數(shù)配置、充電以及充電結(jié)束等六個步驟。根據(jù)通信協(xié)議流程，在物理連接之后的各個步驟，充電機和BMS 如果在規(guī)定時間內(nèi)沒有收到對方報文或正確報文，即判定為超時，出現(xiàn)超時后，充電機或BMS即發(fā)送協(xié)議規(guī)定的錯誤報文，進入錯誤處理狀態(tài)[6]。

圖3 充電總體流程圖

2.2 J1939 協(xié)議在dSPACE 平臺上的實現(xiàn)

J1939 協(xié)議是由美國汽車工程師協(xié)會(SAE)定義的一組標準。此協(xié)議對CAN 物理層、數(shù)據(jù)鏈路層、應用層、網(wǎng)絡層、故障診斷和網(wǎng)絡管理都作了相關(guān)規(guī)定。目前dSPACE 自帶的RTI 實時接口能夠?qū)崿F(xiàn)CAN 報文的收發(fā)和CAN 模塊的簡單配置，并且支持DBC 數(shù)據(jù)庫的配置，但dSPACE 尚未搭載基于J1939 協(xié)議的配置模塊，因此將通過dSPACE/Simulink 搭建相關(guān)模型來遵循協(xié)議的規(guī)定。

2.2.1 通信協(xié)議DBC 數(shù)據(jù)庫的建立

根據(jù)協(xié)議的定義，每個CAN 數(shù)據(jù)幀包含一個單一的協(xié)議數(shù)據(jù)單元(PDU)，即報文格式。遵循協(xié)議規(guī)定的報文格式，即可建立BMS 與充電機通信的DBC 數(shù)據(jù)庫文件。如圖4 所示，DBC 文件能完整地定義CAN 通信的信息，包括CAN 網(wǎng)絡節(jié)點、報文以及信號等。CAN 網(wǎng)絡的通訊就是根據(jù)DBC 文件提供的信息進行的，建立完整準確的DBC 文件可以說是實現(xiàn)CAN 通訊的基礎。

圖4 DBC 文件的建立

2.2.2 J1939 的多幀傳輸機制

根據(jù)CAN 通信協(xié)議的規(guī)定，長度超過8 個字節(jié)的消息無法通過單個數(shù)據(jù)幀進行傳輸，如通信協(xié)議中的BRM、BCP 和BCS 報文，這些消息需要被拆分為多個數(shù)據(jù)幀進行傳輸，本次通信測試對于這些報文的發(fā)送遵循J1939 協(xié)議多幀傳輸?shù)南嚓P(guān)規(guī)定。J1939 的多幀傳輸機制就是將長度超過8 字節(jié)的數(shù)據(jù)分成多個數(shù)據(jù)幀進行傳輸，格式上占用數(shù)據(jù)域的第一個字節(jié)當作每一幀的編號，即每一幀只能傳輸7 個字節(jié)的數(shù)據(jù)，則多幀傳輸?shù)淖畲髷?shù)據(jù)長度為1 785 字節(jié)[7]。

針對多幀傳輸，J1939 協(xié)議規(guī)定了一種特定參數(shù)組：連接管理，其包括請求發(fā)送(TP.CM/RTS)、準備發(fā)送(TP.CM/CTS)以及消息結(jié)束應答(TP.CM/EndofMsgAck)等報文。在本文所介紹的充電模型中，需要發(fā)送內(nèi)容較長報文時，將由BMS 端發(fā)送請求發(fā)送報文，充電機端接收到該報文后發(fā)送準備發(fā)送報文，BMS 收到準備發(fā)送報文后，隨即開始將已拆分好的數(shù)據(jù)包依次發(fā)送。數(shù)據(jù)包發(fā)送完畢后，充電機端發(fā)送消息結(jié)束應答報文，結(jié)束此報文的發(fā)送。

3 基于dSPACE/Simulink 的充電通信模型搭建

通信協(xié)議GB/T 27930-2015 中詳細解析了整個充電通信的過程，本章將介紹BMS 端的充電通信模型、報文接收發(fā)送的實現(xiàn)以及基于Stateflow 的充電時序流程的建立。

圖5 為基于Simulink 搭建的BMS 端的充電通信模型，模型外部主要包括報文接收、充電時序流程圖和報文發(fā)送三個模塊。

圖5 充電通信模型總覽

3.1 接收報文的實現(xiàn)

本模型使用dSPACE 實時接口擴展的RTI CAN 模塊組將dSPACE 系統(tǒng)與CAN 通信網(wǎng)絡結(jié)合，通過Simulink 來配置CAN 通信。根據(jù)通信協(xié)議，本文所搭建的模型需要實現(xiàn)充電機報文接收和BMS 報文發(fā)送，而充電機報文均為單包發(fā)送，BMS 報文包括單包和多包發(fā)送。這里以CHM 接收模塊為例，展示基于RTI CAN 的報文接收模塊的設計。

圖6 所示為充電機握手報文(CHM)的單包接收模塊。為了提高CAN 總線的利用率，達到盡可能快的接收速度，報文接收方式采用中斷觸發(fā)(Interrupt)[8]。模型使用dSPACE 程序模塊接收中斷器(CAN RX Interrupt)來發(fā)送觸發(fā)信號，此信號能觸發(fā)功能調(diào)用子系統(tǒng)(Function-Call Subsystem)中的接收模塊(RTI CAN Receive Message)進行報文接收。

圖6 CHM接收模塊

3.2 發(fā)送報文的實現(xiàn)

單包報文發(fā)送與單包報文接收類似，不同的是發(fā)送報文觸發(fā)方式采用使能觸發(fā)，使能信號控制使能子系統(tǒng)中報文發(fā)送模塊(RTI CAN Transmit Message)發(fā)送相關(guān)報文。由于本模型是基于BMS 端的通信模型，主要承擔發(fā)送BMS 端報文和接收充電機端報文作用，本節(jié)將重點介紹BMS 多包發(fā)送設計和實現(xiàn)。圖7 為多包發(fā)送實現(xiàn)流程。

圖7 多包發(fā)送實現(xiàn)流程

通信協(xié)議中需要進行多包發(fā)送的內(nèi)容較長報文有BRM、BCP 和BCS，根據(jù)J1939 多幀傳輸協(xié)議，多包發(fā)送開始條件是BMS 接收到充電機發(fā)送準備發(fā)送報文(CTS)，但由于同個發(fā)送節(jié)點連接管理報文幀ID 相同，需要BMS 能夠識別所接收的是哪個報文的連接管理報文。模型通過選擇(Switch)函數(shù)，根據(jù)接收到的CTS 報文內(nèi)容的PGN 來判斷即將進行的是哪個報文的多包發(fā)送，然后觸發(fā)相應報文使能子系統(tǒng)開始此報文發(fā)送。以BRM 報文為例，當BMS 收到BRM 的CTS 報文，即開始發(fā)送第一幀數(shù)據(jù)；由于多幀傳輸機制規(guī)定各數(shù)據(jù)幀的第一個字節(jié)為幀的編號，模型設定除第一幀外，其他各數(shù)據(jù)幀的發(fā)送由上一幀的幀編號控制，當?shù)谝粠l(fā)送結(jié)束，模塊識別數(shù)據(jù)幀第一個字節(jié)數(shù)值為1，則觸發(fā)第二幀報文發(fā)送，以此類推。當所有數(shù)據(jù)幀發(fā)送完畢，則停止發(fā)送，并等待充電機發(fā)送結(jié)束應答報文(ACK)，BMS 接收到ACK 報文，即結(jié)束此多包發(fā)送。

3.3 充電流程的建立

本模型根據(jù)通信協(xié)議規(guī)定的BMS 端充電時序流程圖，基于Stateflow 建立了完整邏輯狀態(tài)圖，能夠?qū)崿F(xiàn)對報文發(fā)送使能控制、接收報文成功標志位讀取以及超時判斷。

以如圖8 所示的充電握手階段的邏輯狀態(tài)圖為例，物理連接完成后充電機與BMS 通過低壓電源輔助上電，進入充電握手階段。由充電機向BMS 發(fā)送充電機握手報文，標志位R/CHM 置1，表示BMS 收到CHM，此時車輛握手報文(BHM)發(fā)送使能為高電平，BMS 隨即開始向充電機發(fā)送BHM 報文，等待接收充電機辨識報文(CRM)，若在30 s 內(nèi)為正確接收CRM報文，則進入超時狀態(tài)，開始發(fā)送BMS 錯誤報文(BEM)。BMS 正確收到CRM 報文后，BHM 報文隨即停止發(fā)送，然后開始發(fā)送BMS 和車輛辨識報文(BRM)，BRM 發(fā)送完畢后充電機向BMS 發(fā)送0xAA 的CRM 報文，BMS 收到報文后即停止BRM 報文的發(fā)送，準備開始向充電機發(fā)送動力電池參數(shù)報文(BCP)。接下來的幾個階段的進行也同充電握手階段類似。

圖8 充電握手階段邏輯狀態(tài)圖

4 基于dSPACE/Controldesk 的通信測試

為了驗證通信模型的正確性和可靠性，更貼近實際地模擬仿真對象實時通信情況，獲得更可靠和準確的仿真結(jié)果，本文以dSPACE 仿真平臺模擬BMS 節(jié)點，計算機模擬充電機節(jié)點，通過dSPACE 控制BMS 通信模型，實現(xiàn)BMS 與充電機的模擬通信。本章將對Controldesk 仿真用戶界面和通信測試結(jié)果進行介紹。

4.1 Controldesk 仿真用戶界面

通信協(xié)議的仿真測試通過dSPACE 實時仿真平臺來實現(xiàn)。Controldesk 是dSPACE 的上位機軟件，可以通過此軟件控制由MATLAB/Simulink 等軟件搭建的模型，在dSPACE 平臺進行仿真測試。Controldesk 可以根據(jù)模型需要設計模塊化用戶界面，對模型的仿真進程進行控制，并能為仿真的某些狀態(tài)和重要結(jié)果提供實時顯示。

圖9 為本次通信測試所設計的用戶界面截圖，根據(jù)通信模型，該用戶界面能夠?qū)崿F(xiàn)對充電過程開始和中止的控制以及通信過程相關(guān)報文收發(fā)狀態(tài)的顯示。除此之外，該界面還能通過采集相關(guān)報文的數(shù)據(jù)，顯示充電過程的相關(guān)信息，包括當前荷電狀態(tài)(SOC)、累計充電時間、預計剩余充電時間、充電電壓、充電電流等。

圖9 Controldesk仿真用戶界面

4.2 通信測試結(jié)果

通信測試結(jié)果主要由通信報文的收發(fā)情況來體現(xiàn)。報文是充電機與BMS 之間數(shù)據(jù)傳輸?shù)闹匾d體，其裝載了如充電電壓、充電電流以及當前荷電狀態(tài)等充電過程中的狀態(tài)參數(shù)，因此實現(xiàn)通信報文的正確收發(fā)是充電機與BMS 完成通信的基礎。

本章已介紹過以dSPACE 模擬BMS 節(jié)點，計算機模擬充電機節(jié)點，通過CAN 接口卡USBCAN-2E-U 與dSPACE 主控板DS1103 的CAN 接口和計算機相連接，實現(xiàn)對CAN 信號的讀取，并通過上位機軟件CANTest 實現(xiàn)報文的發(fā)送和接收。圖10 為CANTest 報文監(jiān)控界面截圖，圖中省略了循環(huán)接收的報文，只顯示協(xié)議所規(guī)定的必要報文的收發(fā)情況，并對這些報文進行了相關(guān)注釋。

圖10 CANTest報文監(jiān)控界面

在測試過程中，首先將搭建好的通信模型導入Controldesk 與dSPACE 建 立 連接，由Controldesk 控 制和 監(jiān) 測通信測試的進程，通過CANTest 提前設定好作為充電機端需要向BMS 端發(fā)送的報文，仿真開始后，CANTest 即向dSPACE發(fā)送第一幀報文，dSPACE 根據(jù)通信模型接收并處理后，向模擬充電機端發(fā)送回應報文，由CANTest 接收并根據(jù)設定自動向dSPACE 發(fā)送下一幀報文，由此實現(xiàn)充電機與BMS 的模擬通信。

5 結(jié)論

本文以國標充電協(xié)議為基礎，基于MATLAB/Simulink 搭建了BMS 端的通信模型，介紹了通信協(xié)議的實現(xiàn)以及報文接收與發(fā)送的模塊設計，通過dSPACE 實時仿真平臺模擬BMS節(jié)點實現(xiàn)與CANTest 模擬充電機節(jié)點的通信測試。CANTest通訊結(jié)果表明所搭建的模型能正確模擬BMS 端實現(xiàn)與充電機的通信，驗證了BMS 充電模型的設計。BMS 充電模型可作為BMS 硬件在環(huán)測試的基礎，下一步將繼續(xù)完善此模型，力爭在實車和充電機上進行通信應用測試。