散文網(wǎng) » 科技 »汽車 » 案例研究 | 充電機與BMS之間的通信協(xié)議&V2G在AUTOSAR軟件中的應用

案例研究 | 充電機與BMS之間的通信協(xié)議&V2G在AUTOSAR軟件中的應用

2022-06-10 17:02 作者:Elektrobit 0人讀過 | 我要投稿

前言

隨著新能源汽車的不斷發(fā)展，充電樁作為配套設施的建設規(guī)模也在持續(xù)增長。在相關(guān)零部件領(lǐng)域，我們也能偶爾聽到電池技術(shù)升級的新聞，想到一開始只有一兩百公里級別續(xù)航能力的新能源車，如今再去選購時，會覺得放心很多，基本都能做到300、400公里續(xù)航起步，甚至還能在差不多的價格區(qū)間買到高達600、700公里續(xù)航的車輛。當然，無論電池技術(shù)本身如何升級，作為從業(yè)者的我們，有一個共同觀點是——充電標準能夠做到統(tǒng)一，硬件也好，軟件也好，都能遵照統(tǒng)一規(guī)范進行設計，開發(fā)，部署，提升通用性。

和AUTOSAR標準提出的想法類似，以軟件開發(fā)為例，如果底層軟件能夠做到通用，那么電池管理或者充電樁軟件開發(fā)人員能夠更加專注于應用體驗的提升，而無需對不同廠家的充電樁或者BMS系統(tǒng)進行一次次的開發(fā)以及適配。

充電模式

根據(jù)國標GB/T18487.1—2015，有四種充電模式:

? ? ? ? ? ? ? ? ? ? ? ?

連接方式

一般來說，充電機與車輛連接方式有三種:

日常生活中，我們一般看到的都是連接方式C的情況。

?

充電機與BMS之間的通信協(xié)議

對于充電機與電池管理系統(tǒng)（BMS）之間的通信，同樣有國標規(guī)定。

國標GB/T 27930—2015規(guī)定了電動汽車非車載傳導式充電機(以下簡稱充電機)與電池管理系統(tǒng)(Battery Management System,以下簡稱BMS)之間基于控制器局域網(wǎng)(Control Area Network,以下簡稱CAN)的通信物理層、數(shù)據(jù)鏈路層及應用層的定義。

此標準適用于采用GB/T18487.1規(guī)定的充電模式4的充電機與BMS之間的通信,也適用于充電機與具有充電控制功能的車輛控制單元之間的通信。

J1939

本文僅關(guān)注于車載軟件中和軟件相關(guān)的部分內(nèi)容，在這部分中，我們需要關(guān)注到SAE J1939-21:2006（商用車控制系統(tǒng)局域網(wǎng)CAN通信協(xié)議第21部分:數(shù)據(jù)鏈路層）與SAE J1939-73:2006（商用車控制系統(tǒng)局域網(wǎng)CAN通信協(xié)議第73部分:應用層診斷）。

實際上歐洲執(zhí)行的是ISO 15118標準，而日本則執(zhí)行的是CHAdeMO標準，至于特斯拉，又是另外一種，不過在國內(nèi)，特斯拉可以提供支持國標的充電適配器以支持非特斯拉專用充電樁。

也有新聞說國標和CHAdeMO會進行共同制定，更具通用性。

什么是J1939

J1939協(xié)議是由美國汽車工程師協(xié)會（SAE）定義的一組標準。J1939標準用于卡車、公共汽車和移動液壓等重型車輛。在許多方面，J1939標準類似于舊版J1708和J1587標準，但J1939標準協(xié)議建立在CAN（控制器區(qū)域網(wǎng)絡，ISO 11898）上。

來源：https://www.csselectronics.com/pages/j1939-explained-simple-intro-tutorial

CAN總線提供了通信的基礎(chǔ)規(guī)范，更偏向于是一個工具——例如電話，但是使用電話的雙方如何“對話”？CAN總線并不能完成這樣的工作。和我們熟悉的診斷規(guī)范UDS類似，在充電國標這里，使用的是J1939協(xié)議。

J1939的特點

J1939協(xié)議有如下特點：

?J1939使用的波特率典型值為250K，也能支持500K。J1939 CAN ID使用29 bit的CAN擴展幀。
大部分J1939消息都是在CAN總線上以廣播形式發(fā)送，部分數(shù)據(jù)可以通過請求的方式進行獲取。
J1939消息由18 bit的PGN（Parameter Group Numbers 參數(shù)組編號）進行識別，J1939的信號稱為SPN（Suspect Parameter Numbers可疑參數(shù)編號）。
J1939的消息以intel字節(jié)序進行發(fā)送，J1939傳輸協(xié)議最大支持1785字節(jié)的PGN。

PGN與SPN

如上圖所示，PGN長度為18 bit，是標準CAN擴展幀ID的29 bit中從第九個bit位開始的18個bit。在J1939通信當中，PGN作為唯一的幀標識符，來識別何種設備或者何種消息，以及其包含消息的具體含義。

假設我們收到了一個CAN ID為0x0CF00401的消息，那么PGN值為0x0F004（61444），此時我們可以查閱J1939-71手冊，得知它代表的是“發(fā)動機電控單元1-EEC1”，同時還列有七個SPN各自代表的含義：

我們先來了解一下PF(PDU Format)，當PF的值在0~239（<240）時，代表PDU1格式，用來點對點通信，此時PS(PDU Specific)表示目標地址。而當PF值>=240時，代表PDU2格式，用來做廣播通信，此時PS字段用來作組擴展，和PF一起共同作為廣播參數(shù)組，組的數(shù)量大大增加。

因為Data Page占一個bit，0代表當前屬于頁0，1代表當前屬于頁1，也就是說PGN所代表的組的數(shù)量可以增加一倍。

有了PGN，我們就能找到對應SPN的含義，仍然以上文假設的J1939消息為例，我們能夠注意到其中含義為Engine Speed的SPN，所在位置為第4個字節(jié)開始的2個字節(jié)，也即0x68與0x13，由于已經(jīng)提到過字節(jié)的發(fā)送順序為intel字節(jié)序，所以我們用來進行計算的值應當是0x1368，也即十進制的4968。

同時，我們計算實際具有物理含義的值時，使用上方的公式，采用的精度為每bit位代表0.125rpm，偏移量為0，最終得到的引擎轉(zhuǎn)速為621rpm。

消息類型

J1939一共定義了5個類型的消息：命令，請求，廣播/響應，確認，組功能。

命令

消息類型為命令的J1939消息，包括從某個地址源命令特定目的地或者全局目的地的參數(shù)群，目的地址收到命令消息之后，將采取特定的動作。命令的消息可能包括傳動控制，地址請求，扭矩/速度控制等等。

請求

消息類型為請求的J1939消息，可以從全局范圍或者特定目的地請求信息。

請求消息有定義對應的PGN，59904，對應的PF值為234。SPN僅包含三個字節(jié)的數(shù)據(jù)，代表請求的PGN消息。我們常見的請求消息就包括診斷消息。

廣播/響應

廣播或者響應消息，既可以是某個設備主動提供的廣播消息，也可以是某個命令或請求的響應。

確認

確認消息，是對于特定命令、請求的ACK或者NACK響應。確認消息也有固定的PGN值，59392，對應的PF值為232。

確認類型有肯定應答，否定應答，拒絕應答，無法應答四種。

組功能

組功能消息應用于特殊功能，例如專用功能，網(wǎng)絡管理功能，多包傳輸功能等。

J1939 Transport Protocol (TP) 傳輸協(xié)議

之前所講的PGN與SPN，都是基于不大于8個字節(jié)的J1939消息，當我們需要發(fā)送大于8個字節(jié)數(shù)據(jù)的消息時，我們就需要用到J19393傳輸協(xié)議。

J19393 TP存在兩種類型通信：Connection Mode以及?Broadcast Announce Message（BAM）。

連接模式用于與特定設備的通信，而BAM則用于與整個網(wǎng)絡當中。

如上圖所示，ECU先發(fā)送了一個BAM包，BAM包中指定了多包消息的PGN值以及即將要發(fā)送的包的數(shù)量以及數(shù)據(jù)字節(jié)長度。在BAM之后，最大可以跟隨255個數(shù)據(jù)報文，每一個報文的第一個字節(jié)指定了當前的序列號碼（1到255），然后是7個字節(jié)的數(shù)據(jù)。所以，J1939中多包消息最大能夠傳輸?shù)淖止?jié)數(shù)為1785。

最后一個數(shù)據(jù)報文包含至少一個字節(jié)的數(shù)據(jù)，未使用到的字節(jié)用FF填充。在BAM場景下，消息之間的時間間隔約為50-200ms。

對于接收方，需要做的是，在接收到BAM消息后，初始化一個新的sequence，從6-8字節(jié)中得到PGN值，然后由后續(xù)數(shù)據(jù)傳輸過程中報文的2-8字節(jié)的數(shù)據(jù)組成最終消息的完整數(shù)據(jù)。

J1939診斷

J1939協(xié)議也規(guī)定了一部分PGN用來做不同的診斷服務，這些診斷消息（Diagnostic Message, DM）基本上覆蓋了UDS診斷的功能，同時也兼容OBD診斷。

不同于UDS診斷需要由上位機主動激活診斷服務，J1939 ECU在標準操作過程中也會發(fā)送診斷消息。

類似地，記錄地DTC也可以通過工具讀出來，包括對應的SPN，F(xiàn)MI，OC，CM。

SPN在這里用來代表某種故障碼，占19 bit，應用層文檔已經(jīng)定義了用來做診斷用的SPN。

FMI（Failure Mode Identifier，故障模式ID）代表發(fā)生錯誤的類型，例如超出范圍，短路，校準錯誤等，占5 bit。

OC（Occurrence Counter，發(fā)生次數(shù)），記錄故障發(fā)生的次數(shù)，每當故障從非激活狀態(tài)進入到激活狀態(tài)時，OC計數(shù)器加1，當數(shù)值為126時，激活次數(shù)的增加不再影響計數(shù)器，OC值保持為126。

CM（SPN Conversion Method，SPN轉(zhuǎn)換模式）定義了DTC的字節(jié)對齊方式。過去的J1939規(guī)范定義過三種方式，目前版本僅支持一種，如果CM bit位設置為0，那么則代表當前最新的方法，如果為1，則代表過去三種方法其中之一，具體使用的哪一種，由系統(tǒng)設計者決定。

國標GB/T 27930—2015

國標中定義了，充電機和BMS的地址為不可配置地址，無法用配置工具改變，也不允許使用任何服務（診斷）方式進行修改。

充電總體流程

整個重點過程包括六個階段：物理連接完成，低壓輔助上電，充電握手階段，充電參數(shù)配置階段，充電階段和充電結(jié)束階段。

在各個階段，充電機和BMS如果在規(guī)定的時間內(nèi)沒有收到對方報文或者沒有收到正確的報文，會被判定為超時，超時時間一般默認為5秒。超時后，BMS或者充電機還需要發(fā)送錯誤保溫，進入錯誤處理狀態(tài)。如果充電結(jié)束階段出現(xiàn)故障，則直接結(jié)束充電流程。

報文類型及定義

具體報文類型及定義這里不重復說明，詳細可閱讀國標全文（https://link.zhihu.com/?target=http%3A//c.gb688.cn/bzgk/gb/showGb%3Ftype%3Donline%26hcno%3D2240DB3BCD0A1C5712DCDE65D177BDA3）

AUTOSAR中的J1939 Stack

對于J1939 Stack的實現(xiàn)各家都大同小異，這里以Elektrobit產(chǎn)品 - EB tresos AutoCore J1939 stack為例，提供了如下四個模塊：

J1939 Tp，處理數(shù)據(jù)分拆與組裝，數(shù)據(jù)流控制，超時監(jiān)控等等
J1939 Dcm，處理診斷通信
J1939 Rm，處理請求，確認消息
J1939 Nm，處理地址聲明參數(shù)組消息的接收與發(fā)送

在測試/記錄工具這一塊兒，由于是基于CAN通信，所以有任何一個CAN消息檢測工具，然后配合python腳本也是能做到數(shù)據(jù)解析、記錄的。

J1939 Dcm

AUTOSAR規(guī)范中使用的是J1939規(guī)范中的部分診斷消息 (DMx)，

J1939 Tp

長度不大于8字節(jié)的N-SDU的發(fā)送

當發(fā)送的字節(jié)不超過8字節(jié)時，發(fā)送流程如上圖所示，數(shù)據(jù)不需要被分段發(fā)送。

點對點通信模式數(shù)據(jù)發(fā)送

當數(shù)據(jù)長度大于8個字節(jié)，直接發(fā)送給接收端時，采用的是上圖所示流程。

數(shù)據(jù)發(fā)送前需要先發(fā)送CM RTS（Request to Send）以初始化一次本次數(shù)據(jù)傳輸，在收到CM CTS（Clear to Send）后代表握手成功。然后開始進行數(shù)據(jù)傳輸，直至最后收到確認消息，消息發(fā)送完畢。

BAM發(fā)送

當發(fā)送數(shù)據(jù)大于8個字節(jié)，并且需要發(fā)送給整個網(wǎng)絡時，采用上圖所示流程。首先發(fā)送CM BAM消息初始化本次發(fā)送，然后開始在每個Main Function中進行數(shù)據(jù)發(fā)送。當最后一個報文成功發(fā)送后，本次發(fā)送流程結(jié)束。

J1939 Nm

和AUTOSAR其他網(wǎng)絡管理不同，J1939的網(wǎng)絡管理并不是要去處理ECU的睡眠與喚醒，而是給每一個ECU分配一個唯一的地址。

在J1939當中，定義0xEE00這個PGN值用來做Address Claimed（地址聲明，AC），當ECU啟動時ECU發(fā)出此聲明表示自己期待分配某一地址，如果另一個ECU擁有同一個地址并且有更高的優(yōu)先級，那么ECU需要在發(fā)送CannotClaimAddress（AC消息，但源地址為無效值0xFE）后進入靜默狀態(tài)。

?

J1939 Rm

J1939 Request Management用來管理請求消息的接收與發(fā)送，將請求數(shù)據(jù)轉(zhuǎn)發(fā)到其他模塊進行處理，以及對應確認消息的回復。上面提到的診斷功能，同樣需要用到Rm模塊，例如：

V2G/AUTOSAR解決方案

V2G，即Vehicle-to-Grid，現(xiàn)在電動汽車以及充電樁的參與者越來越多，由于充電樁可能會有一套自己的硬件以及軟件邏輯，如何能讓充電應用能夠無縫地集成到基于AUTOSAR的ECU當中，顯得尤為重要。

類似于我們將AUTOSAR集成到某一個芯片上，往往需要芯片廠家提供硬件以及必要的底層驅(qū)動給到AUTOSAR軟件開發(fā)商去進行集成驗證，充電樁的廠家除了部署自己的充電樁以外，也可以提供驅(qū)動以及必要的軟件棧給到軟件開發(fā)商，由他們將這些軟件集成到AUTOSAR軟件當中，這樣對于使用了AUTOSAR軟件的電池應用開發(fā)者來說，能夠節(jié)省大量時間以及成本。

以歐洲使用的ISO 15118規(guī)范為例，由某些嵌入式廠家將軟件（下圖藍色部分）預集成了在Elektrobit的Classic AUTOSAR軟件當中，這樣開發(fā)者就只需進行必要的定制化配置，就能直接與充電樁進行數(shù)據(jù)交換并進行充電。

不過這套方案是基于以太網(wǎng)的，對于國標使用的J1939，筆者還不太清楚國內(nèi)是否有相關(guān)的專業(yè)軟硬件提供商做這一塊的工作，并且是否與各家AUTOSAR軟件供應商有合作也未知。如果有知道的歡迎評論留言進行交流。

?

參考資料

電動汽車傳導充電系統(tǒng)第1部分:通用要求?

http://c.gb688.cn/bzgk/gb/showGb?type=online&hcno=6B88C3BF988E5F977875DBBD175A1E96
電動汽車非車載傳導式充電機與電池管理系統(tǒng)之間的通信協(xié)議http://c.gb688.cn/bzgk/gb/showGb?type=online&hcno=2240DB3BCD0A1C5712DCDE65D177BDA3
新國標充電適配器?https://www.tesla.cn/support/adapters
新版GB/T充電接口曝光 CHAdeMO與中國共同制定新標準即將落地https://chejiahao.autohome.com.cn/info/4121790
J1939協(xié)議簡介

https://www.kvaser.cn/about-can/higher-layer-protocols/j1939-introduction/
J1939 Explained - A Simple Intro [2021]

https://www.csselectronics.com/pages/j1939-explained-simple-intro-tutorial
J1939 Diagnostics - Part 1?https://embeddedflakes.com/j1939-diagnostics-part-1/

?

作者：

陳謙

Elektrobit中國團隊的軟件工程師

專注于Classic AUTOSAR

最美情侣中文字幕电影,在线麻豆精品传媒,在线网站高清黄,久久黄色视频