SAE J1939只使用扩展帧格式全面定义了标准化的通信 ,SAE J1939设备必须使用扩展帧格式。
标准帧格式消息可以在网络中存在，但只能以本文档所描述的方式。
标准帧设备不响应网络管理消息，不支持标准化通信。
表1—SAE J1939和CAN的仲裁域与控制域的对照表
29位标识符 CAN | 29位标识符 SAE J1939 |
帧位位置 | 11位标识符 CAN | 11位标识符 SAE J1939（1） |
SOF | SOF(2) | 1 | SOF | SOF(2) |
ID28 | P3 | 2 | ID11 | P3 |
ID27 | P2 | 3 | ID10 | P2 |
ID26 | P1 | 4 | ID9 | P1 |
ID25 | R1 | 5 | ID8 | SA8 |
ID24 | DP | 6 | ID7 | SA7 |
ID23 | PF8 | 7 | ID6 | SA6 |
ID22 | PF7 | 8 | ID5 | SA5 |
ID21 | PF6 | 9 | ID4 | SA4 |
ID20 | PF5 | 10 | ID3 | SA3 |
ID19 | PF4 | 11 | ID2 | SA2 |
ID18 | PF3 | 12 | ID1 | SA1 |
SRR(r) | SRR(2) | 13 | RTR(x) |
|
IDE(r) | IDE(2) | 14 | IDE(x) | RTR(2) (d) |
ID17 | PF2 | 15 | r 0 | IDE(2) |
ID16 | PF1 | 16 | DLC4 | DLC4 |
ID15 | PS8 | 17 | DLC3 | DLC3 |
ID14 | PS7 | 18 | DLC2 | DLC2 |
ID13 | PS6 | 19 | DLC1 | DLC1 |
ID12 | PS5 | 20 |
|
|
ID11 | PS4 | 21 |
|
|
ID10 | PS3 | 22 |
|
|
ID9 | PS2 | 23 |
|
|
ID8 | PS1 | 24 |
|
|
ID7 | SA8 | 25 |
|
|
ID6 | SA7 | 26 |
|
|
ID5 | SA6 | 27 |
|
|
ID4 | SA5 | 28 |
|
|
ID3 | SA4 | 29 |
|
|
ID2 | SA3 | 30 |
|
|
ID1 | SA2 | 31 |
|
|
ID0 | SA1 | 32 |
|
|
RTR(x) | RTR (2)(d) | 33 |
|
|
r 1 | r 1(2) | 34 |
|
|
r 0 | r 0(2) | 35 |
|
|
DLC4 | DLC4 | 36 |
|
|
DLC3 | DLC3 | 37 |
|
|
DLC2 | DLC2 | 38 |
|
|
DLC1 | DLC1 | 39 |
|
|
多组 数据传输
所有与特定多组响应相关的所有CAN数据帧必须置DLC为8。所有没用的字节应置为“不可用”（见SAE J1939-71）。每组中的字节数目是固定的，但是，SAE J1939将会规定组数目是可变的和（或）固定的多组消息。动态诊断码的参数群编号即是多组消息中组数目可变的一个例子。只有当发送的字节数超过8时，那些被定义为多组的参数群才使用传输协议进行传输。
Protocol Data Unit (PDU):协议数据单元
应用层或网络层会对PDU进行处理。SAE J1939协议数据单元由7部分组成，他们分别是优先级、保留位、数据页、PDU格式、PDU细节（可以是目标单元地址、组扩展或所有权）、原地址和数据段。这7个部分会被封装成一个或多个CAN数据框架并且通过物理层发送给其他的网络设备。每一个CAN数据框架只有一个PDU。需要注意的是一些PGN定义需要多个CAN数据框架去发送相应的数据。
CAN数据框架中的一些段并没有定义在PDU里面，因为他们是由CAN规格定义的，对于数据链接层之上的OSI层是不可见的。这些字段是由CAN协议定义的在SAE J1939里面没有改变。这些字段包括：SOF、SRR、IDE、RTR、CRC、ACK、EOF。
在图3中显示了这7个字段。在PDU中的每一个字段在后来的应用中都有定义。
图3
P：优先级
R：保留位
DP：数据页
PF：PDU格式
PS：PDU细节
SA：原地址
Date Field：数据字段
P优先级：有三个位用来表示信息发送到总线的优先级。对于接收者来说这三个位应该都认为0，被忽略掉。信息的优先级可以设置为0，最高，或者7，最低。所有控制信息默认的优先级是3，所有的其他的优先级默认为6。
R保留位：SAE为了以后应用保留下来的，暂时无意义。
DP数据页：对于参数组描述选色一个辅助的页。请参考图4。
PDU Format(PF)：协议数据单元格式。PF是一个8位的字段，由这8个位决定了PDU的格式。这8个位是决定PGN参数组代码字段的一部分。PGN参数组代码是用来确定或者标志命令、数据、一些请求、应答或不应答。PGN参数组代码确定或标志的信息要求一个或多个CAN数据框架发送这些信息。如果多于8个字节的需要描述的话就需要发送多个CAN数据。如果是8个或者少于8个字节可以描述的信息，则只需要一个CAN 数据即可。一个PGN参数组代码可以描述一个或多个参数信息。当然一个PGN参数组信息可以只描述一个参数，但是推荐尽可能将一个CAN数据的8个字节全都用上。
PDU Specific(PS)协议数据单元细节：PS是一个8个位字段描述，它由PDU FORMAT格式决定。由PF决定PS是目的单元地址还是组扩展。如果PF字段的值小于240，PS字段表示的是目的单元地址。如果PF字段的值是240～255，PS字段表示组扩展值。见表3，参考图4 PGN参数组代码范围。
| PDU格式（PF）段 | 特定PDU（PS）段 |
PDU1格式 PDU2格式 | 0-239 240-255 | 目标地址 群扩展 |
PDU1格式允许CAN数据定向到特定目标地址（设备）。
PDU2格式只用于无特定目标地址（设备）的CAN数据帧的传输。
使用两种不同PDU格式是为了在通信中提供更多参数群编号的组合。
消息类型
目前支持五种类型消息，分别为：命令、请求、广播/响应、确认和群扩展。
RTR位（在CAN协议远程帧中定义）不可用于隐性状态（逻辑1）。因此，远程传输请求（RTR=1）在SAE J1939中不适用。
网关
网关除了可以实现路由器能实现的所有功能外，还能提供消息重新封装的功能。通过向（从）消息中加入（去除）某些参数，该功能使得包含多个电控单元的车辆子网象一个设备一样，与车辆网络的其他部分协同工作。该功能还简化了电控单元的开发，因为各电控单元不再需要知道车辆子网中的其他电控单元的特定信息（地址）。
