基于J1939協議的重型車OBD診斷儀軟件設計

黃名云

摘 要：J1939協議是國標規定的柴油車的OBD協議，外部診斷設備要與車輛通信，必須滿足J1939協議的要求。文章對一種基于J1939協議的診斷儀的軟件設計進行了說明。分析了J1939協議報文的特點，對請求報文的發送，廣播報文的接收，多幀報文的傳輸協議，故障碼的解析等進行了實例說明，并設計了整個程序處理流程。實際使用中能正確讀取車輛數據，實時性好。關鍵字：J1939協議;OBD;傳輸協議;故障碼中圖分類號：G255.54 ?文獻標識碼：B ?文章編號：1671-7988（2020）11-42-04

Abstract：?J1939 protocol is the OBD protocol of diesel vehicle stipulated by the national standard. If the external diagnostic equipment wants to communicate with the vehicle， it must meet the requirements of J1939 protocol. In this paper， I described the software design of an OBD scanner based on J1939 protocol. I analyzed the characteristics of J1939 protocol message， illustrated the sending of request message， the receiving of broadcast message， the transmission protocol of multi-frame messages， the analysis of DTC， and designed the whole program processing flow. In practice， it can read the vehicle data correctly and has a good real-time performance.Keywords： J1939 Protocol; OBD; Transmission Protocol; DTCCLC NO.：?G255.54 ?Document Code： B ?Article ID： 1671-7988（2020）11-42-04

引言

GB18285-2018和GB3847-2018分別對汽油車和柴油車增加了OBD檢查的內容，適用于新車下線，注冊登記及在用車檢驗，標準規定，若OBD檢查不合格，判定排放檢驗結果不合格[1][2]。這說明我國已將車載OBD技術作為機動車尾氣排放控制的重要手段。作為OBD技術的基礎，診斷通信協議是關鍵的一環。目前，輕型車使用比較多的是ISO 14230和ISO 15765，即基于K線的KWP2000和基于CAN總線的診斷協議。重型車OBD技術起步較晚，由于ISO 15765經過多年的發展和應用已非常完善和成熟，因此也被廣泛應用到重型車中。國家環境保護部發布的《HJ 437-2008車用壓燃式、氣體燃料點燃式發動機與汽車車載診斷（OBD）系統技術要求》，允許生產商可以自由選擇ISO15765和SAE J1939[3]。實測中東風天錦、天龍、江鈴凱銳、帥鈴等車型的OBD系統都是采用SAE J1939協議。

1 J1939協議介紹

SAE J1939協議是美國汽車工程師協會（SAE）提出的基于CAN2.0B的高層網絡通信協議，用于為中重型道路車輛上電子部件間的通訊提供標準的體系結構[4]。協議不但規定了ECU之間如何通信，也包括了故障診斷。SAE J1939網絡遵循7層OSI結構，用不同的文件描述每個實現的層，表1列出了SAE J1939協議的構成。

SAE J1939-11的物理層要求由CAN控制器完成，無需操心。本文中的診斷儀設計主要參照SAE J939-13的技術要求來設計診斷接口，參照SAE J1939-21數據鏈路層來設計報文的通信方式，參照SAE J939-71應用層來解析實時數據流，參照SAE J1939-73來讀取故障碼，凍結幀等與排放有關的故障信息。下面分別對這幾部分進行說明。

2 診斷接口及地址定義

SAE J939-13中定義的診斷接口為9針圓形接口，而機動車檢測站對2018年7月1日以后生產的柴油車檢測中，OBD采用SAE J1939協議的車輛，其診斷接口使用的也是ISO15031-3規定的標準16針梯形接口，尚未碰到9針圓形接口。因此備用一個9針轉16針的轉換器以備不時之需。

SAE J1939-81推薦發動機模塊的地址為0x00，外部診斷儀的地址為0xF9。本診斷儀使用推薦地址。

3 協議數據單元（PDU）

SAE J1939-21數據鏈路層采用的是CAN2.0擴展幀29位ID，通訊速率為250K ，并對29位ID進行了重新分配，將其分為：優先級（P）、保留位（R）、數據頁（DP）、協議數據單元（PDU）格式（PF）、PDU特定域（PS）和源地址（SA）[6]。如下圖所示。將CAN報文幀格式封裝成PDU協議格式進行傳輸。

其中R、DP、PF、PS組成了參數組（PGN），PF<240時，協議數據單元為PDU1格式，此時PS代表目標地址，PGN的低字節置0，保留位始終為0;PF≥240時，協議數據單元為PDU2格式，此時PS代表組擴展GE，它是PGN的低字節。PDU1格式用于發送包含一特定目的地址的報文，當目的地址為0xFF時，代表是全局地址;PDU2格式則只能用于廣播發送[6]。

4?報文請求和廣播接收

J1939協議的消息類型有5種：命令、請求、廣播/響應、確認、組功能[6]。診斷儀要想從車輛獲取與排放相關的信息，主要處理兩種類型的消息，即請求和廣播。請求需要診斷儀向發動機模塊發送請求報文才能獲得相應的信息，而廣播則是發動機模塊按一定的時間間隔主動往總線上發送的消息，如當前故障碼即為發動機模塊每隔一秒便在總線上廣播一次，對于這類消息只需設定好濾波器直接接收就好。表2分別列出了部分需要請求，及廣播接收的消息。

4.1?請求類型消息的實現

請求可以向特定目的地址請求，也可向全局范圍內請求，請求報文的參數組編號（PGN）為0x00EA00（59904），優先級為6，報文定義如圖2所示[6]。

例：診斷儀（地址為0xF9）向發動機模塊（地址為0x00）請求就緒狀態信息（PGN為65230（FECE）），則發送的請求報文為：18EA00F9 ?CE FE 00 FF FF FF FF FF

其中診斷儀為源地址，發動機為目標地址，數據域為要請求的PGN，低字節先發送，高字節后發送。

發動機模塊回復的消息格式為：18FECE00 ?01 04 0F 06 00 08 00，如圖3。

若250ms內沒收到任何消息，則代表無應答，ECU不支持對應的PGN。

4.2?廣播消息的接收

對于主動廣播的消息，需設置CAN屏蔽濾波器，接收對應的PGN。

例：可疑參數編號（SPN）為190的轉速信息，所屬參數組為61444（F00416），實測發動機模塊每隔20ms往外發送一幀消息。

若要接收這廣播消息，可先關閉所有濾波器，不接收任何消息，并清空接收緩沖區，然后精確設置濾波器只接收PGN為61444的消息。每接收一幀消息便關閉濾波器，進入數據處理階段，處理完數據再打開濾波器。

若等待250ms無任何消息，則代表總線上無這類消息傳送。

5?傳輸協議

由于CAN報文的數據域最多為8個字節，若一個PGN傳送的消息的大于8個字節，則需要啟用傳輸協議。傳輸協議分連接管理和多包消息廣播。連接管理是向特定目的地址傳輸多幀數據時使用，即發送者請求發送（RTS）一個分段報文，其包含有多少字節及包數，接收者需響應準備發送（CTS）報文，告訴發送者其能接收的包數和想要從第幾包開始接收。建立這樣一個握手連接后發送者方開始傳輸數據;多包消息廣播則不需要建立連接，由發送者發送一幀廣播公告消息（BAM），通知所有節點要廣播一條長消息，這條公告消息包含了要發送消息的字節數和參數組，接著便開始數據傳輸[6]。兩種傳輸協議詳情可參照文檔J1939-21相關部分說明。下面舉一幀連接管理消息的實例進行說明。

設診斷儀（地址0xF9）為?A 節點，發動機模塊（地址0x00）為?B 節點，A向B請求歷史故障碼信息，PGN= 65227（00FECB16），A與B之間消息傳送如表3所示。

6?故障碼

故障碼在J1939-73文檔中定義，由4個字節組成，包含SPN、FMI、CM和OC四個部分。SPN是可疑參數編號，占19bits，代表診斷項目;FMI是故障模式標志，定義了故障類型，占5bits，CM是可疑參數編號的轉化方式，占1bit，SPN有4種轉化方式，取值1表示按照方案1，2，3進行轉換，詳情見J1939-73文檔。取值0表示按照方案4進行轉換，即19位的SPN均采用英特爾格式。CM推薦取值為0;OC是故障發生次數，占7bits。舉例：

SPN：1208=4B816=00000000100101110002（19位）

FMI：3=316=000112（5位）

OC：10=A16=00010102（7位）

CM：016=02（1位）

因CM=0，所以按方案4轉換，其結果如表4所示[7]。

表3得到的故障碼信息有效數據為18個字節，前兩個字節為故障燈信息，由于一個故障占4個字節，所以剩下16個字節包含4個故障碼，SPN按照表4轉化方式，提取一個DTC，其C語言代碼實現如下：

u32 Temp=0x0000;

Temp =（Temp|（CANRxBuf.Data[4]>>5））<<8;//提取19位SPN的最高3位

Temp = （Temp|CANRxBuf.Data[3]）<<8;//提取中8位

Temp = Temp|CANRxBuf.Data[2]; //19位SPN提取完畢

DTC_SPN =Temp;

DTC_FMI= CANRxBuf.Data[4]&0x1f;

DTC_OC = CANRxBuf.Data[5]&0x7f;

7?軟件設計流程

綜合J1939報文特點，OBD診斷儀需要發送請求消息，接受廣播消息。接收到的消息又有單幀消息和多幀消息之分，對于接收到的RTS消息需要進行CTS連接管理，每次消息的接收都需要設置屏蔽濾波器。消息接收采用中斷模式，每接收到一幀消息便開始計時，若超過規定時間接收中斷再無消息傳來，代表報文已接收完成，之后進入數據處理階段，數據流的解析參照文檔J1939-71，故障碼，凍結幀等與排放相關的數據解析參照文檔J1939-73。軟件程序設計流程如圖4所示。

8?結束語

本文所設計的OBD診斷儀已經在機動車檢測站投入使用，能夠滿足國標對車輛OBD檢查的要求，并且響應迅速，實時性好。J1939協議在重型柴油車國五及國六車輛中是國標規定使用的OBD協議，理解J1939協議對開發車載OBD系統及OBD外接設備都是極其重要的一環，也是車聯網的

基礎。本文對J1939協議的數據傳輸格式，傳輸協議，故障碼等難以理解的部分進行了實例說明，并給出了設計框架及C語言程序的實現，以供學習者參考。

參考文獻

[1] GB 18285-2018，汽油車污染物排放限值及測量方法（雙怠速法及簡易工況法）[S].2018.

[2] GB 3847-2018，柴油車污染物排放限值及測量方法（自由加速法及加載減速法）[S].2018.

[3] HJ 437-2008，車用壓燃式、氣體燃料點燃式發動機與汽車車載診斷（OBD）系統技術要[S].2008.

[4] 周良潤.對當前J1939協議的汽車信息采集系統研討[J].科教導刊-電子版（上旬），2016，（8）：173.

[5] SAE J1939，Recommended Practice for a Serial Control and Comm?-unications Vehicle Network[S].2005.

[6] SAE J1939-21，Data Link Layer[S].2006.

[7] SAE J1939-73，Application Layer-Diagnostics[S].2015.