01 前言
在网络通信设计领域大家讨论比较多的是CAN(FD)、Ethernet，但是对于J1939协议的讨论比较少，但J1939协议在目前的商用车及工程机械行业却在大范围应用，在乘用车领域J1939协议栈也有使用，比如GB/T 27930-《电动汽车非车载传导式充电机与电池管理系统之间的通信协议》规定充电桩与BMS之间的通信协议就是采用SAE J1939，关于J1939在GB/T 27930标准中的应用我们在下面着重介绍，同时结合工程实践介绍CANoe.J1939的常用功能，并对J1939 DM1报文及多帧传输方式进行介绍，最后介绍了下AUTOSAR架构中的J1939协议栈，希望对J1939协议的初学者有所帮助。
02 J1939 协议介绍
整个SAE J1939协议组包含如下标准：
- SAE J1939 Serial Control and Communication Heavy Duty Vehicle Network-Top Level Document;
- SAE J1939-21 Data Link Layer;
- SAE J1939-31 Network Layer;
- SAE J1939-71 Application Layer;
- SAE J1939-73 Application Layer-Diagnostic;
- SAE J1939-74 Application-Configurable Messaging;
- SAE J1939-75 Application Layer-Generator Sets;
- SAE J1993-81 Network Management;
整个标准的内容比较多，我也没有深入研究，只是站在项目使用的角度对SAE 1939-21(数据链路层)PDU格式、参数组概念、传输协议，以及J1939-71（应用层）规定的SPN（可疑参数编号）、PGN(参数组)，还有J1939-73中规定的DM1报文、DTC格式等有所了解。下面我们就站在项目实际使用过程需要掌握的基本概念角度为大家介绍如下内容：
2.1 帧结构
J1939采用29位ID的扩展帧格式，其整个帧格式相对CAN标准帧在ID域有较大差异外，其他域基本一致，都包含帧起始、仲裁场、控制 场、数据场、CRC场、ACK场、帧结束。
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（212）中参数组，加上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中的应用
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:多帧传输的连接关闭报文
04 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界面
05 AUTOSAR架构中J1939协议栈
在整个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模块。
06 总结
因为商用车、工程机械行业不像乘用车具有很大的体量，同时其车品品类有很多，零部件供应商不可能针对每个OEM都定制开发，所以采用标准化的J1939协议可以尽量将PGN、SPN标准化，降低开发工作量及成本，提供零件的通用化率。但是这样同样带来了信息安全的风险，所有的通信都是明文公开的，所以现在智能商用车架构中，J1939协议只在底盘域、动力域使用，在座舱域、车身域、智驾域、网联域等已经很少用到，但是作为商用车企业的通信设计人员还是需要深入研究下J1939协议的。
END
作者：窦明佳
文章来源：汽车电子与软件
推荐阅读
更多汽车电子干货请关注汽车电子与软件专栏。欢迎添加极术小姐姐微信（id:aijishu20)加入技术交流群，请备注研究方向。
