直流充電網GB/T 27930協議CAN報文解析方法
本文非原創,原文章地址如下:直流充電網GB/T 27930協議CAN報文解析方法 (ofweek.com)
之所以放在這里,是作為我學習積累的見證。
本文以國標GB/T 27930—2015《電動汽車非車載傳導式充電機與電池管理系統之間的通信協議》為基礎,講述了直流充電網協議報文解析方法。主打實用,對於偏理論的部分僅作淺層敘述。文章主要囊括:
-
直流充電網CAN報文結構介紹
-
CAN報文分析方法
報文組成
一條報文主要由ID(標識符)、數據幀等組成,在通常應用中主要關注的是報文ID、數據內容、發送周期,此處僅對此三項進行分析。關於CAN報文的詳細定義可參照GB/T 27930—2015文件中的“2 規范性引用文件”中所述。
下圖是車輛直流充電握手階段的報文,以第一條報文“序號0”行為例,這是直流充電網的第一條報文(CRM),在插槍並啟動充電櫃后由充電櫃發送。主要信息如下:
注:
報文中的數字不區分大小寫;
獲取的報文數據均為十六進制(為簡便起見,未用符號表明);
數字前方的“0x”符號表示此數字為十六進制;
數字后方的“H”符號也表示此數字為十六進制;
數字后方的“b”表示此數字為二進制;
本文中十進制數字均省去符號位。
時間標識 |
0x0068214a |
報文ID |
0x1826f456 |
報文數據 |
01 01 00 |
時間標識
通過時間標識可看出該條報文的發送時刻、時間間隔。
時間標識算法:
上圖為十六進制,以0x182656f4(CRM)前兩條為例,其時間標識為0x0068214a和0x00682b10,換算成十進制則分別為6824266和6826768(單位為0.1ms)。取二者差值2502,即時間差為250.2ms,符合國標對CRM要求的250ms周期(偏差0.2ms,在允許范圍內)。
若為系統時間,則計算更簡潔,直接將兩個北京時間取差值即可。(系統時間存在極少量偏差,如無需進行精確分析,可忽略此偏差)
也有設備顯示的原始時間標識直接為十進制,這樣更直觀。
報文ID
報文ID相當於一條報文的身份證。下圖為國標中對協議數據單元(PDU)的定義,此處以CRM報文為例,其ID為0x1826f456,可分為四部分0x18、0x26、0xf4、0x56.
報文ID解析:
⚫ 0x18,包含優先權P(3位)、保留位R(1位)、數據頁DP(1位)三項內容。R和DP均為0
〰 首先將0x18轉換為二進制:11000B,分為三部分
〰 優先權P:110B,換算成十進位為6,表示此條CRM報文的優先權為6
〰 保留位R:0
〰 數據頁DP:0
⚫ 0x26,為此條報文的PF,可用來查詢此條報文的參數。直流充電網中每條報文具有惟一的PF,相當於身份證號。
⚫ 0xf4,目標地址PS,即此條報文是發給地址為0xf4的節點的。國標中車輛BMS的地址為0xf4,充電櫃的地址為0x56
⚫ 0x56,源地址SA,即此條報文是地址為0x56的節點發出來的。
參照國標“9 報文分類“,該處定義了每條報文的代號、名稱、PGN、優先權、報文周期、數據長度、源-目標地址,可直接根據此處所列找到對應報文ID.這是報文目錄,分析充電網報文時會經常用到。
以參數配置階段的BRO報文為例
其優先權為4,則二進制P、R、DP一起為10000B,換算成十六進制為0x10;
其PGN為000900H,則PF為0x09;
目標地址為充電機0x56;
源地址為BMS 0xf4;
組合起來其ID便為0x100956f4.
后續分析報文時看其PGN中間兩個數(如0x01、0x07、0x0A等)即可篩選出對應ID.(組幀報文例外,具體見下方組幀報文部分描述)
數據幀
CAN網絡中一幀報文的數據最長為8個字節,若報文的數據長度不超過8個字節,則在CAN網絡中以一幀報文發出(如下圖中的BCL報文0x181056f4、CCS報文0x1812f456、BSM報文0x181356f4這三條)。若數據長度超過8個字節,則以組幀形式發送(如下圖中的0x1cec56f4、0x1cecf456、1ceb56f4,具體格式及解析方式見下方“組幀傳輸“)。
如上圖,excel中數據列有8列,從左往右依次為報文的第1、2…8字節。如BCL(0x181056f4)報文數據長度為0x5,則其數據列對應如下
報文ID |
一 |
二 |
三 |
四 |
五 |
0x181056f4 |
8C |
19 |
3C |
0F |
02 |
組幀報文傳輸
當報文的數據長度超過8個字節時,在CAN網絡上將會按照組幀報文格式進行傳輸。直流充電國標中,在充電的每個階段最多有一條數據長度超過8的報文,均為BMS發送出來的。下圖是直流充電網中的BRM、BCP兩條報文。
(不同組幀報文,傳輸過程中其ID均用同一組,需要從數據內容中區分)
以BCP報文為例,組幀報文傳輸主要關注下面這段BCP報文中標注顏色的部分即可。
報文ID |
一 |
二 |
三 |
四 |
五 |
六 |
七 |
八 |
0x1cec56f4 |
10 |
0D |
00 |
02 |
FF |
00 |
06 |
00 |
0x1cecf456 |
11 |
02 |
01 |
FF |
FF |
00 |
06 |
00 |
0x1ceb56f4 |
01 |
9D |
01 |
00 |
00 |
73 |
09 |
04 |
0x1ceb56f4 |
02 |
1A |
6A |
DE |
03 |
98 |
17 |
|
0x1cecf456 |
13 |
0D |
00 |
02 |
FF |
00 |
06 |
00 |
組幀報文雖稍復雜,但應用時只需關注其主要特征點,可參照以下對話框模擬示意。
BCP報文詳細規則
上述對話框簡圖已涵蓋分析數據時需關注的點和方法,接下來將詳細描述組幀報文傳輸規則。
BMS請求
BMS發送組幀報文時,會先發送一條ID為0x1cec56f4的報文,用來告知充電櫃開始組幀報文的傳輸。實際應用時直接看第七字節內容即可識別此組組幀報文所對應的的PGN。
報文ID |
一 |
二 |
三 |
四 |
五 |
六 |
七 |
八 |
0x1cec56f4 |
10 |
0D |
00 |
02 |
FF |
00 |
06 |
00 |
0x1cec56f4報文字節解析如下:
第一字節。第一字節為控制字10,內容固定;
第二、三字節。為數據長度,BCP報文的數據長度為13,因此換算成十六進制為0xD,用兩個字節表示為0x000D,其中低字節填入第二字節0x0D,高字節填入第三字節0x00;
第四字節。為數據包個數,即接下來會以兩幀報文(ID 為0x1ceb56f4)來傳輸13個字節的數據內容;
第五字節。預留,默認發0xFF
第六、七、八字節。即BCP報文的PGN,為000600H
充電櫃回應
充電櫃接到這條報文后會回復一條ID為0x1cecf456的報文,用於告知BMS充電櫃已准備好接收。此條報文一般可忽略。
報文ID |
一 |
二 |
三 |
四 |
五 |
六 |
七 |
八 |
0x1cecf456 |
11 |
02 |
01 |
FF |
FF |
00 |
06 |
00 |
0x1cecf456報文字節解析如下:
第一字節。11為控制字,內容固定;
第二字節。02,即告知BMS,充電櫃可以接收2個數據包;
第三字節。01,即將接收的這個數據包編號為“01“;
第四、五字節。默認發0xFFFF;
第六、七、八字節。即BCP報文的PGN,為000600H.
數據傳輸
接下來BMS就開始以0x1ceb56f4報文來正式發送數據。每條報文可發送7個字節(第1字節為序號),BCP長度為13,因此用兩條報文來發送。
這個ID的報文承載了所有需要傳輸的數據,重點關注這一塊。
報文ID |
一 |
二 |
三 |
四 |
五 |
六 |
七 |
八 |
0x1ceb56f4 |
01 |
90 |
01 |
00 |
00 |
73 |
09 |
04 |
0x1ceb56f4 |
02 |
1A |
6A |
DE |
03 |
98 |
17 |
0x1cec56f4報文字節解析如下:
第一條0x1ceb56f4報文
第一字節為序號01,即第一條數據包
第二到八字節依次為要發送的第1、2…7字節數據
第二條0x1ceb56f4報文
第一字節為序號02,即第二條數據包
第二到七字節依次為要發送的第8、9、10、11、12、13字節數據
充電櫃確認
發送且接收完畢后,充電櫃則回復一條0x1cecf456報文,用來告知BMS,充電櫃已完成接收。一般可忽略不看。
報文ID |
一 |
二 |
三 |
四 |
五 |
六 |
七 |
八 |
0x1cecf456 |
13 |
0D |
00 |
02 |
FF |
00 |
06 |
00 |
0x1cecf456報文字節解析如下:
第一字節13:控制字,表示已接收完畢;
第二、三字節000D:表示接收到的數據為13個字節;
第四字節02:接收到的數據分兩個數據包;
第五字節FF:默認填充;
第六、七、八字節。即BCP報文的PGN,為000600H.
最后,附上幾張學習筆記。