转载自 http://www.cankau.cn/support/help/can-vs-j1939.html
CAN2.0 是一种总线规范，是数据链路层的技术。J1939 是 SAE（美国汽车协会）定义的基于 CAN 总线的规范，目的是解决不同发动机厂商、不同 ECU 厂商的兼容性问题。
1、J1939 和 CAN2.0 的关系
J1939 是在 CAN2.0B 的基础上，对仲裁场部分的 29 位 ID 的重新解释；其它部分完全一样。
29 位 ID 分为：3 位的优先级、8 位的 PF（帧格式）、8 位的 PS（帧扩展）、8 位的 SA（源地址）、1 位的 DP（Data Page 数据页）、1 位的保留位。
其中 1 位的 DP、8 位的 PF、8 位的 PS 组成了 PGN；
PGN 是 Parameter Group Number；是参数组列表。
在 J1939 中，将消息分为了 PDU1 和 PDU2 两种格式。
PDU1 格式的消息发送给特定地址的 ECU，地址用 8 位的 PS 记录；PDU2 格式的消息则发送给所有的 ECU，8 位的 PS 用于扩展。
当 PF 的值在 0-239 时，表示该消息为 PDU1 格式，PS 为 DA（目地地址）。
当 PF 的值在 240-255 时，表示该消息为 PDU2 格式，PS 为扩展地址。
2、J1939 的物理特性：
总线最大长度为 40M；最大支持 30 个节点；节点最大长度为 1M；传输速率最大为 250Kbps；3 根线（CAN_H、CAN_L、GND)
J1939 的分层：
J1939/11：物理层：物理介质、总线设计、长度、节点；
J1939/21：数据层：PGN 信息、帧格式；
J1939/31：网络层；
J1939/71/73：应用层；信息分享、控制、广播、故障诊断；
3、PGN
PGN 是 Parameter Group Number 的简称。J1939 中最大支持（240+16×256）×2 个 PGN。
当消息为 PDU1 格式时，PGN=DP×256×256+PF；
当消息为 PDU2 格式时，PGN=DP×256×256+PF*256+PS;
在 J1939 中，消息的传递以参数组的形式，每个参数组中有若干参数，每个参数是一个 SPN；
4、SPN
SPN:Suspent Parameter Number：特定的参数编号；例如：SPN 190 表示发动机转速。
5、CAN2.0 与 J1939 的关系、J1939 与特定的厂商协议的关系
CAN2.0 是一种总线规范，是数据链路层的技术。J1939 是 SAE（美国汽车协会）定义的基于 CAN 总线的规范，目的是解决不同发动机厂商、不同 ECU 厂商的兼容性问题。J1939 定义了 一系列的 PGN 和 SPN，这些 PGN 包含了发动机、变速器、车轴等汽车上各部件的信息；对参数的表示方法（状态和值）又定义了 SLOT（Scaling 比例、Limit 界限、Offset 偏移、Transfer 传送）。ECU 厂商都应该遵循这个规范。ECU 模块的功能不同，厂商不同，在 J1939 的基础上，又表现出其多样性：支持或者不支持某些 PGN、SPN 和 SLOT；新增了某些 J1939 未定义的 PGN 和 SPN。
6、PDU 消息包在 CAN2.0 上的拆包和重组
CAN2.0 的数据场最多支持 8 字节的数据，如果 PDU 的数据小于等于 8 字节，1 个 PDU 用 1 个 CAN2.0 帧传输即可；如果 PDU 的数据大于 8 字节，就需要在发送时进行拆包，在接收时进行重组。接收端如何识别是否需要重组以及怎么重组呢？J1939 的做法是在拆包的情况下，将 8 字节的数据区的第一个字节用于表示拆包后的序号（1-255）；因此，最长的 PDU 为 255×7 字节。
7、PDU 的内容解析
PDU：Protocol Data Unit：协议数据单元。
在数据链路层 CAN 之上的就是 PDU，包含了 CAN2.0 中仲裁场、控制场和数据场部分的内容。对 J1939 协议的解析其实就是对 PDU 的协议解析，先对接收到的包进行重组，构建一个完整的 PDU 包；再从 PDU 中数据包中提取出 PGN 和 SPN 对应的值。
J1939是在CAN2.0的硬件基础上（数据链路层），又做了一个封装（应用层？）。实际在网络上跑的数据包还是以CAN的形式再跑，只是接收端（发送端）在接收到（发送前），对一个J1939格式的数据包，进行整合（拆分）处理。
NI 上有一篇简单介绍，还不错。https://forums.ni.com/t5/Example-Program-Drafts/J1939-Transport-Protocol-Reference-Example/ta-p/3984291?profile.language=en
Description
1. J1939 Overview
J1939 is set of SAE standards commonly used in diesel-powered applications for communication and diagnostics between application components. The J1939 standard is defined in multiple documents corresponding to five of the seven OSI layers. J1939-11 defines the physical layer, J1939-21 defines the data link and transport layer, J1939-31 defines the network layer, and J1939-71/73 defines the application layer. J1939-81 describes network management.
The goal of this document is not to explain all these standards in detail. For this, please consult the SAE standards. Instead, we will look at the construction and transmission of messages as defined by J1939-21 using NI-CAN and supported hardware.
2. J1939 Message Construction
J1939 messages are built on top of CAN 2.0b and make specific use of extended frames. Extended frames use a 29-bit identifier instead of the common 11-bit identifier. J1939-21 defines fields within this 29-bit identifier as shown below.
Figure 1. J1939 29-bit Identifier Fields
The first three bits are the priority field. This field sets the message’s priority on the network and helps ensure messages with higher importance are sent/received before lower priority messages. Zero is the highest priority.
The next bit is reserved for future use. This field should be set to zero.
The next bit is the Data Page field. This is used to expand the maximum number of possible messages.
The next eight bits make up the Protocol Data Unit Format (PDU F) field. This is used to determine if the message is intended for a specific device on the network or if the message is intended for the entire network. If the value of PDU F is less than 240, the message is meant for a specific device. If the value is 240 or greater, the message is intended for all devices.
The next eight bits make up the Protocol Data Unit Specific (PDU S) field. The definition of this field is based on value of the PDU F field. If PDU F is intended for a specific device (less than 239), PDU S is interpreted as the address of that specific device. In this case, the PDU S field is referred to as the Destination Address field. This format is referred to as PDU 1. If PDU F is intended for all devices (greater than or equal to 240), PDU S is interpreted as a Group Extension field. This group extension is used to increase the number of possible broadcast messages. This format is referred to as a PDU 2.
Both formats are described below in picture form.
Figure 2. PDU 1 Format
Figure 3. PDU 2 Format
The last eight bits identify the address of the device that transmitted the current message. This is known as the Source Address Field.
On standard CAN networks, identifiers are used to uniquely define each message. This concept exists within J1939 as well. Because the priority and source address fields can change, they are not used for this purpose. This leaves the reserve, data page, PDU F and PDU S fields. This new combination of fields is referred to as the Parameter Group Number (PGN). Each message in J1939 must have its own unique PGN. The J1939-71 standard is responsible for assigning these unique PGNs to standard messages.
3. Addressing
Each device on the network has to have a unique address ranging from 0 to 254. These addresses are mainly used for PDU 1 messages and requests. In most cases, these addresses are static and pre-defined by the user. However, the J1939-81 standard does define a method of dynamic addressing.
4. Special Messages
Although J1939 uses the PDU F field mainly to specify if the message is PDU 1 or PDU 2, there are a few special values set aside for features like requests, dynamic addressing, and transport protocol. These values override the greater than/less than rules for PDU 1 and PDU 2 formats. Requests are used as an example below.
Figure 4. Request PGN
Notice in this example that PDU Format is set to 234. Normally, this would be handled as a PDU 1. However, because this is a special message, the device knows to handle the message differently. In this specific case, it knows it has to respond to the originator of the request in a particular format as defined by the J1939-21 standard.
5. Transport Protocol
The J1939 standard allows single messages to have more than eight bytes of data, however, the CAN specification only supports eight byte data transfers. Therefore, the message must be sent in multiple packets. J1939-21 defines how to package, send and reassemble these messages within the constraints of the CAN specification. J1939-21 calls this transport protocol and specifies two types The first is Broadcast Announcement Message (BAM) which is similar to PDU 2 in that it is intended for the entire network. The second is called Connection Mode and is similar to PDU 1 in that it is intended for a specific device.
Both transports protocols work in a similar fashion. They use two special messages to facilitate these multi-packet transfers. The first is known as a Transport Protocol Connection Management message (TP.CM). The data in a TP.CM message contains connection commands (also called Control Byte), the PGN identifier of the multi-packet message and information about how to reconstruct the message. The second is called a Transport Protocol Data Transfer message (TP.DT). The data of a TP.DT message contains a sequence number in the first byte and uses the remaining seven bytes for the data of the multi-packet message.
6. BAM Messages
As mentioned above, Broadcast Announcement Messages are intended for the entire network. Therefore, no handshaking with other devices is required. The originating device first sends a TP.CM message with a control byte BAM (32). Next the originator starts sending all the data through the TP.DT messages until all the data has been sent. Below is an example to show the flow of a BAM message. Here, PGN 65260 is 20 bytes and is being transferred via BAM in 3 TP.DT packets.
Figure 5. BAM Data Transfer Example
7. Connection Mode Messages
Connection Mode is a peer to peer transfer. Therefore, handshaking and message acknowledgements are used to guarantee successful data transfer. First, the originating devices sends a TP.CM message with a control byte Request to Send (16). This is the originator asking the receiver if it is capable of receiving data. The receiver can then respond in various ways but normally it is with a TP.CM message containing control byte Clear to Send (17). The data of the TP.CM Clear to Send message contains the current sequence number to transfer as well as the number of TP.DT packets allowed. The originator then sends TP.DT messages starting at the sequence requested and stops after reaching the number of TP.DT messages allowed. This process continues until all the data is transferred. The receiving device then has to send a TP.CM message with control byte EndofMsgACK (19) confirming that all the data was successfully received. Here is an example to illustrate a typical Connection Mode message. Here PGN 65259 is a 27 byte message requiring 4 TP.DT messages.
Figure 6. Connection Mode Data Transfer Example
Note: It is acceptable to send a TP.CM Clear to Send message indicating that zero packets can be transferred. This doesn’t mean the connection is invalid. Instead it means the receiving device isn’t ready for the data. It is also acceptable to send a TP.CM Clear to Send message with a sequence number that has already been sent. This is often used when the receiver thinks the previous TP.DT messages were corrupt.
版权属于：CraZyMoNk
本文链接：https://blog.peacharc.com/archives/497.html
转载时须注明出处及本声明
