深入解析J1939-73：车辆诊断通信的标准与应用

 

作者 | 小懒

 

小编 | 不吃猪头肉

SAE J1939协议概述

SAE J1939协议是由美国汽车工程师协会（SAE，Society of Automotive Engineers）定义的一种用于重型车辆和工业设备中的通信协议，主要应用于车辆和设备之间的实时数据交换。J1939基于CAN（Controller Area Network）总线技术，使用29bit的扩展标识符和扩展数据帧，CAN通信速率为250Kbps，用于车载电子控制单元（ECU）之间的通信和控制。小北同学在之前也对J1939协议做过扫盲科普【科普系列】SAE J1939协议解读。

表 1例如1939-71 文件中定义了一些PGN（参数组），用于描述报文中待发送的参数，以及关于报文优先级和传输速率的信息。今天主要聊聊J1939诊断功能。提起车载诊断，想必大家最熟悉的就是UDS（ISO 14229-1）了，通过UDS中定义的服务可以获取车辆的参数、故障信息等。那J1939协议中又是如何定义的诊断呢？大家可以带着疑问走进J1939-73一探究竟。

J1939-73车辆诊断2.1 J1939-73的基本概念

 

J1939-73中定义了诊断故障代码（DTC）、诊断消息（DM）等信息，当车辆存在故障时，需要根据发送的故障相关信息，获取故障原因并对车辆进行诊断维修。

 

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：表示故障发生的具体参数/系统/部件，是一个19位数字；

FMI：表示故障的具体类型/模式，是一个5位数字；

OC：DTC从活动的状态转变为先前活动的状态的次数（先前活动的DTC：故障发生过但当前没有发生，活动的和先前活动的状态是互斥的,故障不能既是活动的又是先前活动的状态）；

CM：表示SPN的转换方式；

表 2

例如

油压预滤器参数，可疑参数数值（SPN＝1208） 故障模式标志（FMI）为 3 发生次数（OC）为 10 所有的DTC以Intel格式传送（最小有效字节优先） 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）实现了实时故障监控、历史故障读取、氧传感器检测等功能。下图为J1939-73中定义的部分DM内容，可以根据自己的需求选择对应功能的DM。

图 3-SAEJ1939-71-2006（来源）常用到的诊断消息有DM1、DM2和DM3等：

DM1：获取当前活动故障代码（包括与排放系统相关的DTC）；

DM2：获取历史故障和相关的故障代码；

DM3：清除先前活动的DTC故障数据或复位；

今天主要解读一下DM1

每当DTC变为活动故障时，就发送DM1消息，此后以1次/s的更新速率传输。如果一个不同的DTC在1秒的更新周期内改变了状态，则传输一个新的DM1消息来反映这个新的DTC及指示灯（故障指示灯、红色停止灯、琥珀色警告灯和保护灯）的状态。为防止频率非常高的间歇性故障导致消息率过高，建议每个DTC每秒传输的状态变化不超过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个字节时，需要使用由SAE J1939-21中定义的多包报文传输协议进行分包传输。如下图中，当存在5个激活的DTC时，需要传输共22个Bytes(DTC共占20个Bytes，加上2个Bytes的故障灯状态）的数据，拆分为4包数据进行传输。通过TP_CM连接报文可知即将传输报文的PGN为0xFECA、所有传输数据长度为22个Bytes、数据被拆分为4个包。TP_DT传输报文中第一个字节表示序列号，Bytes2-7为传输的数据内容。如果最后一包数据≤7个Bytes,则可以设置填充位进行填充。

图 5-多包报文传输

J1939诊断应用

 

CANoe作为一个总线开发与测试工具，可以提供J1939、FMS通用数据库文件，也集成了J1939的NM、TP以及基于UDS/J1939-73的诊断功能。实现通过DTC监控功能捕获和分析故障代码，帮助工程师了解系统问题并进行故障排查。那该如何在CANoe中应用呢？

首先需要根据项目需求，选择J1939总线，搭建好工程；

接下来可以导入创建好的对应J1939总线的DBC文件；

图 6-J1939 DBC创建

 

导入DBC文件之后，可以通过IG模块发送仿真J1939报文，也可以使用CAPL脚本发送J1939报文。

使用IG模块仿真报文

图 7-CANoe中IG模块设置

 

使用CAPL函数发送DM01报文

图 8-CAPL示例及发出报文

 总结

 

在当前汽车电子快速发展的背景下，J1939-73协议不仅能够满足传统商用车辆的诊断需求，还可以支持新能源汽车等领域的诊断应用。结合CANoe等专业工具的强大功能，开发人员可以更加高效地进行协议一致性测试、诊断通信验证等工作。

 

注：文中部分图片来源于Vector及SAE 1939-73-2006协议。