SAEJ1939协议解析及工程实践

2.1帧结构

J1939采用29位ID的扩展帧格式，其整个帧格式相对CAN标准帧在ID域有较大差异外，其他域基本一致，都包含帧起始、仲裁场、控制 场、数据场、CRC场、ACK场、帧结束。

 

图1：CAN标准帧格式

 图2：CAN扩展帧格式

2.2 协议数据单元（PDU）

每个CAN数据帧报文一个协议数据单元PDU(Protocol Data Unit),根据J1939-21的定义协议数据单元由7个部分组成，分别是优先级、保留位、数据页、PDU格式、PDU特定、源地址和数据域，具体详见如下定义：

图3：J1939 PDU结构

ØP（优先级）：优先级包含3位，位于ID的最前面，用来优化报文传输中的传输延迟，一条报文的优先级可以从最高0设置到最低7；

ØEDP(扩展数据页)：备今后开发使用，当前均设置为0；

ØDP(数据页):应用层在分配参数组编号PGN时，DP=0中的报文分配完以后，允许分配DP=1中的报文，当前所有报文的DP都设置为0，即所有报文的PGN都分配在DP0页中；

ØPF(PDU Format)：PF域一共8位，它的取值确定了一条报文的PDU格式。PDU格式一共有两种：PDU1和PDU2，当PF的值在0~239（0x00-0xEF）,则表明为PDU1格式，若PF的值在240~255（0XF0-0xFF）之间，则标明为PDU2格式；

ØPS(PDU Specific)：PS场一共8位，PS场的内容取决于PF场的取值，若为PDU1格式，则该场表示的为帧的目标地址，若为PDU2格式，则表明为组扩展GE（用于扩展PGN的个数）

ØGE(组扩展)：当PF场为PDU2格式，及PF场的高四位全部置位1（PF≥240），则PS场即为GE(组扩展)，其与PF场的低四位一起可提供每个数据页4096（2¹²）中参数组，加上PDU1格式的240个参数组，因为对于数据页0共有4096+240=4336个参数组。

ØDA(Destination Address):目标地址，对于单播报文可指定目标地址，任何源地址与该目标地址不同的节点可忽略此报文，当DA场定义为FF时，则为全局目标地址，则要求所有节点对该报文都要做出监听和响应。

ØSA(Source Address)：源地址，给定的一个源地址在网络中应当只有一个设备与其对应，在SAE J1939-71中对商用车常用控制器的源地址进行了定义，在J1939通信设计时可以参考，若目前网络拓扑中定义的节点标准中未规定可在128-247范围内来自定义。

ØData（数据域）：J1939的数据域长度可以定义超过8个字节，超过8个字节可通过传输协议的连接管理能力来建立和关闭多包参数组的通信。

2.3 参数组编号(PGN)

PGN是J1939标准中的唯一帧标识符，在SAE J1939-71中通过PGN可唯一标识一帧报文，PGN的长度为18位，包含扩展数据页、数据页、PDU格式以及PDU特定字段值。

图4：J1949 PGN结构

2.4 可疑参数编号SPN

可疑参数编号（SPN）是SAE分配给参数组（PGN）中特定参数的编号，它们用作数据字节中CAN信号的标识符，SPN 是一个 19 位数字，其范围从 0 到 524287。从520192到524287的范围被保留给专有参数。除字母数字数据外，SPN 解释始终从 LSB 为 MSB（从右到左）。SPN 可能存在于多个 PGN 中。PGN对 SPN 进行分组。

图5：SAE J1939-71 对PGN、SPN的定义示例

03

J1939协议在GB/T 27930中的应用yHIednc

GB/T 27930 规定充电机与BMS之间的通信物理层采用SAE J1939-11 -《商用车控制系统局域网CAN通信协议 第11部分：物理层，250Kbit/s,屏蔽双绞线》，规定数据链路层选用的是PDU1格式，同时规定PGN的第二字节PDU格式（PF）高字节和低字节均为00H，同时规定充电机的源地址为56H（86），BMS的源地址为F4H（244）,并规定该地址固定在ECU的程序代码中，包括服务工具在内的任何手段不能改变其源地址。

有了上面的定义，结合标准中对充电过程中各个阶段报文的PGN定义，就可以得到对应的报文ID，因此标准通篇没有提及报文的ID，都是给的PGN。例如如下充电握手阶段的报文：

 

 图6：GB/T27930 充电报文

3.1  J1939 DBC编辑

在编辑GB/T 27930的DBC文件时，如果CANoe带J1939配置，可在CAN DB++Editor直接编辑PGN、Source、Priority、Destination从而自动生成报文ID。

图7：CANdb++Editor J1939 DBC编辑界面

3.2 J1939多帧传输

但是对于数据长度超过8个字节的报文，例如上面BMS和车辆辨识报文BRM数据长度为49个字节时，需要用到SAE J1939-21的传输协议，传输协议的功能分为两个部分：消息的拆包与重组，连接管理。

图8：BMS和充电机辨识报文BRM

1)消息拆包与重组：大于8字节的数据不能通过一个单独的CAN数据帧来传输，需要被拆分为多个数据包，使用单独的数据帧一次传送，接收者则负责按编号将多个数据包重组为长数据，并传给应用程序。

2)连接管理：连接管理包含三个过程，建立连接、数据传输、连接关闭。

图9:J1939-21 多帧传输流程

Ø建立连接：当某个节点要传输一组大于8字节的数据时，就会发起请求连接，请求中包含整个数据包的大小，要传送消息的帧数，以及它设定的参数群编号，然后等待接收方做出响应。

图10:多帧传输传输层建立连接报文

Ø数据传输：当建立连接之后，当发送者接收到允许发送的信号后，发送者将按顺序将拆装后的数据一次发送到CAN网路上，数据帧的第一个字节用于表示当前数据包的编号。

图11:多帧报文数据传输报文

Ø连接关闭：当数据被正确发送后，接收方会回传一个数据包，数据包内容包括：结束应答编号、整个消息的大小、接收的帧数以及参数组编号。

图12:多帧传输的连接关闭报文

04yHIednc

J1939 DTC

4.1 J1939 DM1报文格式

对于商用车的诊断，不像乘用车UDS被广泛使用，现在很多商用车的控制器没有做UDS诊断，其故障发送机制大部分会按照SAE J1939-73 DM1报文的格式发送，DM1报文的PGN固定为00FECA16，如下为DM1报文的格式定义：

图13:DM1报文结构

图14：DM1报文中DTC的格式定义

激活诊断故障码DM1的发送规则为有DTC激活时，DM1就会立即发送，此后每秒发送一次，如果在1秒内发生新的DTC，则DM1应立即发送且发送先于原DTC，以反应新的DTC，DM1发送应包含当前所有的DTC。当有多个DTC存在时，a=灯状态，b=SPN,c=FMI,d=CM和OC，则报文的格式为a,b，c,d，b,c,d……使用传输协议，存在0个DTC时，字节1=0，字节2=0xFF，字节3——6=0，字节7-8=0Xff。

图15：CANoe DM1报文Trace

4.2 J1939 DM1报文多帧传输

当节点的当前激活故障码DTC数量大于1时，就需要用到SAE J1939-21的传输协议了，它首先发送一条广播公告消息（BAM），BAM消息包含了即将广播的长消息的参数组编号、消息大小和它被拆的数据包数目，然后使用PGN=60160来发送相关的数据。

                 图16：J1939 DM1报文多帧传输CANoe Trace

4.3 CANoe.J1939 DTC Monitor

CANoe.J1939 会有DTC Monitor可提供简单接口监控诊断协议，不需要程序设计即可显示/查询故障码，同时可显示MIL灯、DTC历史、激活DTC、DTC、冻结帧、设置等。

图17：CANoe.J1939 DTC Monitor界面

05yHIednc

AUTOSAR架构中J1939协议栈yHIednc

在整个AUTOSAR CP的架构中包含J1939相关的模块由J1939DCM，J1939 Nm、J1939 Rm、J1939 TP。

图18：AUTOSAR CP软件模块

5.1 诊断通信管理DCM(Diagnostic Communication Manager)

负责UDS和SAE J1939-73通信路径和诊断服务的执行，从而处理来自外部测试人员或OBD系统的诊断请求，它转发来自外部扫描工具的请求，并进一步负责封装响应的消息（DTC、状态信息），这些消息随后将传输到外部诊断扫描工具。

图18：AUTOSAR 诊断相关模块

5.2 J1939网络管理

和AUTOSAR其他网络管理不同，J1939的网络管理并不是去处理ECU的睡眠与唤醒，而是给每一个ECU分配一个唯一的地址，在SAE J1939-81中定义0xEE00这个PGN值用来做地址声明，当ECU启动时ECU发出此声明表示自己期待分配某一地址，如果另一个ECU拥有同一个地址并且有更高的优先级，那么ECU需要在发送CannotClaimAddress后进入静默状态。

5.3 J1939 请求管理RM

J1939 Request Management用来管理请求消息的接收与发送，将请求数据转发给其他模块处理，以及对应确认消息的回复。上面提到的诊断功能，同样需要用到RM模块。

06yHIednc

总结yHIednc

因为商用车、工程机械行业不像乘用车具有很大的体量，同时其车品品类有很多，零部件供应商不可能针对每个OEM都定制开发，所以采用标准化的J1939协议可以尽量将PGN、SPN标准化，降低开发工作量及成本，提供零件的通用化率。但是这样同样带来了信息安全的风险，所有的通信都是明文公开的，所以现在智能商用车架构中，J1939协议只在底盘域、动力域使用，在座舱域、车身域、智驾域、网联域等已经很少用到，但是作为商用车企业的通信设计人员还是需要深入研究下J1939协议的。

END

添加微信”btighteast”加入微信交流群

（仅限专业人士，添加备注单位+姓名）

责编：Demi