一種電動汽車充電協議的設計與實現

周 侗

（沈陽理工大學自動化與電氣工程學院， 遼寧 沈陽 110159）

新能源汽車發展20多年以來，世界主要汽車強國將其提升至國家戰略，中國也將新能源汽車作為戰略性產業之一，更主動、系統地推動新能源汽車產業的發展。在新能源汽車發展戰略中，純電動汽車（EV） 成為了主要突破口。

在電動汽車充電標準方面，國際上有美國SAE標準體系的ISO 15118和歐洲充電標準體系的DIN 70121，其中ISO 15118標準包括ISO 15118-1～ISO 15118-6幾個部分，分別定義了V2G充電網絡的基本信息、網絡拓撲、物理/數據鏈路層功能、物理/數據鏈路層測試及無線充電幾部分功能，支持交、直流充電方式；DIN 70121標準僅支持直流充電方式。中國于2015年12月底發布了新修訂的《電動汽車傳導充電系統》相關的充電系列標準，包括通用要求、交流充電接口、直流充電接口、通信協議等國家標準的內容［1-5］。

有別于前面介紹的國內外電動汽車充電標準，本文設計了一種簡單、易用的電動汽車充電協議，本協議屬于應用層協議的范疇，不局限于特定的傳輸技術，類似于現場總線技術中的MODBUS協議。后面在TI TMS570LS12xx硬件平臺開發出面向EV充電的通信控制器，在實際應用中驗證了充電協議的功能性，達到了預期目的［6-8］。

1 EV充電場景分析

在EV充電應用場景中，EV和供電設備（充電樁，簡稱EVSE） 之間通過EVCC（EV Communication Controller，EV通信控制器） 進行信息交互（圖1），實現EV充電過程中的授權管理、充電控制和充電狀態監測等操作，其中授權管理操作包括了充電付費業務，這也是電動汽車能否充電的先決條件。

圖1 電動汽車充電業務關系

EV與EVSE之間的通信鏈路可采用CAN、PLC（Power Line Communication） 等，EV中EVCC通過內部CAN總線連接BMS（Battery Management System） 系統，獲取BMS充電的狀態信息，如SOC（剩余電量，State of Charge）。

圖2為電動汽車充電的總體流程。EV充電過程分為4個階段：充電握手階段、充電參數配置階段、充電階段、充電結束階段。當EV和EVSE物理連接完成且上電后，雙方進入“握手”階段，EV會將自己的身份信息，即EVCC-ID，上傳給EVSE，進行充電之前的“權限核準”操作；“充電握手”階段完成后，EV和EVSE進入“充電參數配置”階段，雙方就EVSE最大輸出能力等參數進行協商，以判斷是否能夠充電；充電參數配置階段完成后，則進入“充電”階段。在整個充電階段，EVSE實時輸出自身輸出電流限值，EV則根據整車情況（如環境溫度） 及此電流限值綜合調整充電功能，同時，EV定時向EVSE發送充電狀態供EVSE顯示及上傳服務器；當EV充電完成（即SOC達到100%），或者用戶停止充電（如用戶拔槍或） 后，雙方進入“充電結束”狀態，EVSE停止電流輸出，充電過程結束。

圖2 電動汽車充電流程

上述各個階段中，如果EVCC之間在規定時間內沒有接收到對方報文或者沒有收到正確報文，即判定為超時（超時時間除特殊規定外，一般設為5s）；當出現通信超時后，EVSE或者EV進入錯誤處理狀態，一般會立即停止，進入“充電結束階段”，結束充電。

2 充電協議設計

本文在參考相關國際標準［6-7］的基礎上，結合具體應用需求，提出一個結構簡單且可低成本實現的電動汽車充電協議，簡稱EVCP，具體設計如下。

2.1 EVCP協議模型

結合電動汽車充電業務的特點，EVCP協議模型定義如圖3所示。EVCP協議模型采用了OSI參考模型中的物理層、數據鏈路層和應用層這3層，其中物理層和數據鏈路層可以支持多種通信技術，如PLC或CAN通信，在數據鏈路層中增加了一個邏輯鏈路控制子層（Logic Link Control Sublayer，簡稱LLC），主要負責通信鏈路的建立、斷開和維護功能。

圖3 EVCP協議模型

EVCP協議中LLC子層負責通信過程中的可靠性管理。具體流程如下：LLC子層在接收到完整的遠程報文并校驗成功后，需要給遠程LLC子層發送一個“接收確認”報文，即L_Cnf，表示已經收到遠程報文，然后將接收到的遠程報文上傳給APL層處理，如果接收到的遠程報文不正確（例如校驗錯誤），則放棄不回復。

支持EVCP通信協議的EVCC之間通信示例流程如圖4所示，示例中左側EVCC-A為服務發起方。

圖4 EV與EVSE之間的通信示例流程

首先，EVCC-A APP 發送服務請求報文（Req），EVCC-B LLC接收到EVCC-A請求報文（Ind） 后，先發送確認報文L-Cnf給EVCC-A LLC，表示已收到Req報文，EVCCA LLC在接收到EVCC-B的L-Cnf報文后，通過A-Cnf服務通知自己上層APP請求報文發送成功，如果EVCC-A LLC在約定時間內未收到來自EVCC-B LLC的確認報文，則通過ACnf服務通知上層APP報文發送失敗。

EVCC-B LLC把接收到的EVCC-A請求報文（Ind） 上傳到EVCC-B APP處理，EVCC-B APP處理完成后，把響應報文（Rsp） 發送給EVCC-A，EVCC-A LLC在接收到Rsp報文（Cnf） 后，給EVCC-B LLC發送一個L-Cnf報文，表示已經接收到Rsp報文，EVCC-B LLC接收到L-Cnf后，通過A-Cnf服務通知上層APP Rsp發送成功，如果EVCC-B LLC在一定時間內未接收到L-Cnf報文，則認為Rsp發送失敗，也通過A-Cnf服務通知上層APP。

EVCC-A在接收到Cnf報文后，處理響應數據，至此完成一個完整的通信流程。需要注意的是，在EVCC之間通信過程中，需要通過L-Cnf報文來確認報文發送成功與否，這也是一種保證通信可靠性的有效機制。

2.2 EVCP幀格式定義

EVCP協議幀格式定義如圖5所示。EVCP幀主要包括幀頭（6字節）、幀尾（2字節） 和協議數據3個部分，其中“服務數據”區域用于容納電動汽車充電業務相關的服務數據。

圖5 EVCP幀格式

EVCP幀中“長度LE”字段是“服務數據”區域的長度，如圖5中灰色區域所示。EVCP幀中“校驗字”為“幀頭”和“協議數據”兩部分內容的“簡單累加和”（忽略溢出）。LLC L-Cnf確認幀中“長度LE”值為0，即不包含服務數據內容。EVCP幀序號取值范圍為0～255，循環計數，溢出后再從0開始計數。EVCP協議的最小長度為8（6+2=8）。

EVCP通信協議采用“大端模式”，即多字節數據發送過程中，高位在前。EVCP幀格式中的“協議類型”定義參見表1。

表1 “協議類型” 定義

2.3 EVCP充電服務定義

EVCP協議定義了若干充電業務服務，該服務內容在EVCP幀中“服務數據”中發送。具體服務定義如表2所示。

表2 EVCP充電服務定義

EVCP協議支持SessionSetup、PowerDeliverReq、ChargeStatus和SessionStop這4個充電服務，分別對應充電握手、充電參數配置、充電和充電結束4個充電階段。

表3～表7給出了部分服務的定義，礙于篇幅所限，不做詳細說明。

表3 SessionSetup請求服務

表4 SessionSetup響應服務

表5 PowerDeliverReq請求服務

表6 ChargingStatusReq請求服務

表7 SessionStop請求服務

2.4 EVCP協議實現

在前面研究成果的基礎上，我們開發了支持EVCP協議的EVCC模塊。EVCC開發采用的硬件平臺為TI TMS570LS12xx處理器。其物理層采用PLC通信技術，使用高通公司的QCA7xxx系列通信模塊，PLC通信速率可達到8Mb/s以上。PLC模塊與CPU之間通過串口交換信息。EVCC功能結構如圖6所示。

圖6 EVCC功能示意圖

軟件平臺為CCS6，采用C語言編程，使用CCS6自帶的實時操作系統FreeRTOS。

EVCC提供兩路串口，其中一路用于連接高通PLC模塊，另外一路連接以太網接口模塊或者GPRS接口模塊，用于連接云服務器，以便進行用戶權限處理。EVCC還提供兩路CAN 接口，一路CAN 接口用于連接BMS ECU，以獲取BMS的充電狀態信息（如SOC值），另一路CAN接口也可用于設備診斷和固件升級。針對基于CAN總線的固件升級方案，我們也開發了基于UDS（Unified Diagnostic Services） 的升級軟件。最終EVCC產品在國內某款電動汽車上進行了測試，通過了可行性方面的驗證，證明EVCP充電協議在設計方面的完善性和功能性，達到了預期的目的。

3 結論

本文提出了一種適用于電動汽車簡單、易實現的充電協議，適配多種傳輸技術。針對電動汽車的應用場景，充電協議在協議模型、報文結構、服務及參數定義等方面給出了比較詳盡的定義。在EVCC通信過程中加入了報文發送確認機制，保證了通信的可靠性，最后給出了一種基于TI單片機的軟硬件解決方案。

充電協議還未考慮充電設備（如充電樁） 與云服務器之間信息交互及通信安全保障方面的內容，后續會考慮對這些問題進行補充，擴展充電協議的功能，以適應更廣泛的應用場景。