作者 |小懶

小編 | 不吃豬頭肉

SAE J1939協議概述

SAE J1939協議是由美國汽車工程師協會（SAE，Society of Automotive Engineers）定義的一種用于重型車輛和工業(yè)設備中的通信協議，主要應用于車輛和設備之間的實時數據交換。J1939基于CAN（Controller Area Network）總線技術，使用29bit的擴展標識符和擴展數據幀，CAN通信速率為250Kbps，用于車載電子控制單元（ECU）之間的通信和控制。小北同學在之前也對J1939協議做過掃盲科普【科普系列】SAE J1939協議解讀。

表 1例如1939-71 文件中定義了一些PGN（參數組），用于描述報文中待發(fā)送的參數，以及關于報文優(yōu)先級和傳輸速率的信息。今天主要聊聊J1939診斷功能。提起車載診斷，想必大家最熟悉的就是UDS（ISO 14229-1）了，通過UDS中定義的服務可以獲取車輛的參數、故障信息等。那J1939協議中又是如何定義的診斷呢？大家可以帶著疑問走進J1939-73一探究竟。

J1939-73車輛診斷2.1 J1939-73的基本概念

J1939-73中定義了診斷故障代碼（DTC）、診斷消息（DM）等信息，當車輛存在故障時，需要根據發(fā)送的故障相關信息，獲取故障原因并對車輛進行診斷維修。

2.2診斷故障代碼（DTC）

DTC（Diagnostic Trouble Codes）是J1939-73中的核心概念，代表診斷故障代碼，由SPN(Suspect Parameter Number)、FMI (Failure Mode Identifier) 、OC（Occurrence Count）及CM（SPN Conversion Method）四部分組成：

SPN：表示故障發(fā)生的具體參數/系統/部件，是一個19位數字；

FMI：表示故障的具體類型/模式，是一個5位數字；

OC：DTC從活動的狀態(tài)轉變?yōu)橄惹盎顒拥臓顟B(tài)的次數（先前活動的DTC：故障發(fā)生過但當前沒有發(fā)生，活動的和先前活動的狀態(tài)是互斥的,故障不能既是活動的又是先前活動的狀態(tài)）；

CM：表示SPN的轉換方式；

表 2

例如

油壓預濾器參數，可疑參數數值（SPN＝1208） 故障模式標志（FMI）為 3 發(fā)生次數（OC）為 10 所有的DTC以Intel格式傳送（最小有效字節(jié)優(yōu)先） SPN 1208 ＝4B8 ＝000 00000100 10111000（19 位） FMI 3 ＝3 ＝00011（5 位） OC 10 ＝A ＝0001010（7 位） 可疑參數編號的轉化方式(CM) ＝0（1 位）

整體的DTC數據如下圖：

圖 1-SAEJ1939-71-2006（來源）

如下圖數據流中DTC為0x10B0209,根據上面介紹的J1939-73協議中定義的DTC格式，可以得知SPN為0x209，FMI為0x0B，CM為0，OC為0x01。有了這些信息則可以根據對應故障碼表格，定位故障。

圖 2-J1939報文

2.3診斷消息（DM）

在J1939-73中還定義了很多診斷信息（DM），由不同的診斷信息（DM）實現了實時故障監(jiān)控、歷史故障讀取、氧傳感器檢測等功能。下圖為J1939-73中定義的部分DM內容，可以根據自己的需求選擇對應功能的DM。

圖 3-SAEJ1939-71-2006（來源）常用到的診斷消息有DM1、DM2和DM3等：

DM1：獲取當前活動故障代碼（包括與排放系統相關的DTC）；

DM2：獲取歷史故障和相關的故障代碼；

DM3：清除先前活動的DTC故障數據或復位；

今天主要解讀一下DM1

每當DTC變?yōu)榛顒庸收蠒r，就發(fā)送DM1消息，此后以1次/s的更新速率傳輸。如果一個不同的DTC在1秒的更新周期內改變了狀態(tài)，則傳輸一個新的DM1消息來反映這個新的DTC及指示燈（故障指示燈、紅色停止燈、琥珀色警告燈和保護燈）的狀態(tài)。為防止頻率非常高的間歇性故障導致消息率過高，建議每個DTC每秒傳輸的狀態(tài)變化不超過1次。DM1相關參數如下：Extended Data Page: 0 Data page: 0 PDU Format: 254 PDU Specific: 202 Default Priority: 6 Parameter Group Number: 65226 (0x00FECA)

圖 4-DM1報文結構

當傳輸數據超過8個字節(jié)時，需要使用由SAE J1939-21中定義的多包報文傳輸協議進行分包傳輸。如下圖中，當存在5個激活的DTC時，需要傳輸共22個Bytes(DTC共占20個Bytes，加上2個Bytes的故障燈狀態(tài)）的數據，拆分為4包數據進行傳輸。通過TP_CM連接報文可知即將傳輸報文的PGN為0xFECA、所有傳輸數據長度為22個Bytes、數據被拆分為4個包。TP_DT傳輸報文中第一個字節(jié)表示序列號，Bytes2-7為傳輸的數據內容。如果最后一包數據≤7個Bytes,則可以設置填充位進行填充。

圖 5-多包報文傳輸

J1939診斷應用

CANoe作為一個總線開發(fā)與測試工具，可以提供J1939、FMS通用數據庫文件，也集成了J1939的NM、TP以及基于UDS/J1939-73的診斷功能。實現通過DTC監(jiān)控功能捕獲和分析故障代碼，幫助工程師了解系統問題并進行故障排查。那該如何在CANoe中應用呢？

首先需要根據項目需求，選擇J1939總線，搭建好工程；

接下來可以導入創(chuàng)建好的對應J1939總線的DBC文件；

圖 6-J1939 DBC創(chuàng)建

導入DBC文件之后，可以通過IG模塊發(fā)送仿真J1939報文，也可以使用CAPL腳本發(fā)送J1939報文。

使用IG模塊仿真報文

圖 7-CANoe中IG模塊設置

使用CAPL函數發(fā)送DM01報文

圖 8-CAPL示例及發(fā)出報文

總結

在當前汽車電子快速發(fā)展的背景下，J1939-73協議不僅能夠滿足傳統商用車輛的診斷需求，還可以支持新能源汽車等領域的診斷應用。結合CANoe等專業(yè)工具的強大功能，開發(fā)人員可以更加高效地進行協議一致性測試、診斷通信驗證等工作。

注：文中部分圖片來源于Vector及SAE 1939-73-2006協議。