Any SAE J1939 hardware must support SAE J1939/1x and SAE J1939/21; otherwise, they’re useless because these standards describe the CAN bus physical layer and the basic protocol features.
That part is sufficiently covered (i.e., for demonstration purposes) by our CAN shield, while the cabling and connectors may not necessarily J1939-compliant.
A fully functional SAE J1939 protocol software must support one mandatory element, SAE J1939/81 (address claim process), and, if needed, SAE J1939/21 (transport of up to 1785 bytes per message).
Note: The Transport Protocol (TP) implementation, i.e., the transport of up to 1785 data bytes in a message, is highly application-specific. Some ECUs and their control applications (CAs) will need it; some won’t.
In the following, I will cover the basics of the SAE J1939/21 Transport Protocol (TP) and the Address Claim Procedure according to SAE J1939/81.
SAE J1939/21 - Transport Protocol (TP)
Even though highly effective in passenger cars and small industrial applications, Controller Area Network (CAN) alone was not suitable to meet truck and bus communications requirements, mainly since its communication between devices is limited to only eight bytes per message. However, it is possible to extend the size of a CAN message by implementing additional software, i.e., so-called higher layer protocols. J1939 is such a higher layer protocol, and it supports up to 1785 bytes per message.
In order to support a size of more than eight bytes, the message needs to be packaged into a sequence of eight-byte size messages. Consequently, the receiver of such a multi-packet message must re-assemble the data. Such functions are defined as Transport Protocol (TP) Functions, and they are described in SAE J1939/21.
In order to package CAN messages into a sequence of up to 1785 messages (as well as to re-assemble the CAN frames into one data package), the J1939 Transport Protocol defines the following:
- Each multi-packet message is being transmitted by using a dedicated Data Transfer PGN (60160, TP.DT = Transport Protocol Data Transfer), i.e. all message packets will have the same ID.
- The flow control is managed by another dedicated PGN (60146, TP.CM = Transport Protocol Communication Management).
- The message length must always be 8 bytes (DLC = 8).
- The first byte in the data field contains a sequence number that ranges from 1 to 255.
- The remaining 7 bytes are filled with the data of the original long (> 8 bytes) message.
- All unused data bytes in the last package are being set to 0xFF.
The method of using a sequence number plus the remaining seven data bytes yields a total of (255 packages times 7 bytes/package) 1785 bytes per multi-packet message.
As it is the case with regular 8-byte CAN messages, multi-packet messages (i.e., messages longer than eight bytes) can be transmitted as a broadcast message (BAM = Broadcast Announce message) or peer-to-peer (RTS/CTS = Request to Send / Clear to Send).
Note: The SAE J1939/21 Standard requires that an ECU supports one BAM and one RTS/CTS session simultaneously.
For more information, see:
SAE J1939/81 - Address Claim Procedure
While other higher layer protocols based on Controller Area Network (CAN) do not support node address assignments per default, the SAE J1939 protocol provides yet another ingeniously designed feature to uniquely identify Electronics Control Units (ECU) and their primary function.
Note: As a reminder, a J1939 network node is usually called an “ECU.” Each ECU can maintain more than one “Control Application (CA).” For that reason, the technical requirements generally refer to a CA rather than an ECU.
The SAE J1939/81 Standard lists a number of technical requirements for the address claiming process:
- Each control application (CA) must be capable of providing its unique 64-bit NAME.
- CAs must successfully claim an address prior to sending messages (other than those for claiming an address) into the network.
- The inability to successfully claim an address must be handled and reported to the network.
- The CA must follow the network initialization associated with the address claiming process.
- The CA must support a minimum set of network management requirements, including required responses to power interruptions.
For more information, see:
- SAE J1939 Address Claiming Procedure Overview...
- SAE J1939 Address Management Messages (Address Claim PGNs)...
SAE J1939 Starter Kit And Network Simulator
The JCOM.J1939 Starter Kit And Network Simulator is designed to allow the experienced engineer as well as the beginner to experiment with SAE J1939 data communication without the need of connecting to a real-world J1939 network, i.e., a diesel engine.
In order to establish a network, you need at least two nodes. That fact applies especially to CAN/J1939, where the CAN controller will shut down after transmitting data without receiving a response. For that reason, our jCOM.J1939 Starter Kit And Network Simulator consists of two J1939 nodes, namely our jCOM.J1939.USB, an SAE J1939 ECU Simulator Board With USB Port.
The jCOM.J1939.USB gateway board is a high-performance, low-latency vehicle network adapter for SAE J1939 applications. The board supports the full SAE J1939 protocol according to J1939/81 Network Management (Address Claiming) and J1939/21 Transport Protocol (TP).
The following is an excerpt from A Comprehensible Guide To J1939 by Wilfried Voss. Certain parameter groups may require more than the eight data bytes supported by the CAN standard. The SAE J1939 standard, namely the Transport Protocol Function, supports message lengths up to 1785 bytes. If a program group requires more than eight data bytes (9…1785 bytes) and [...]
The following is an excerpt from A Comprehensible Guide To J1939 by Wilfried Voss. Even though extremely useful in passenger cars and small industrial applications, CAN alone was not suitable to meet the requirements of truck and bus communications, mainly since its communication between devices is limited to only 8 bytes per message. However, it is possible [...]
This post is part of a series about SAE J1939 ECU Programming & Vehicle Bus Simulation with Arduino. Note the time stamps from line 3 through line 5 of the screen shot (look at the last four numbers indicating the time in tenth of milliseconds; for instance 352.4 milliseconds in line 3). SAE J1939/21 requires a packet frequency between 50 [...]
This post is part of a series about SAE J1939 ECU Programming & Vehicle Bus Simulation with Arduino. Test items include: Basic function Timing controlNaturally, for the RTS/CTS session we will need two SAE J1939 nodes. In my setup that means communication between the Arduino Uno and the Mega 2560 ECUs. [...]
This post is part of a series about SAE J1939 ECU Programming & Vehicle Bus Simulation with Arduino. Test items include: Basic function Timing controlThe initial test of the BAM session requires only one ECU, in this case I am using the full protocol running on the Arduino Mega 2560 [...]
This post is part of a series about SAE J1939 ECU Programming & Vehicle Bus Simulation with Arduino. Proving the capability of the most basic task of sending and receiving regular 8-byte (CAN) messages must be seen as an unnecessary test, since that had already taken place in previous chapters. Things change, however, with the transmission and reception of J1939 [...]
This post is part of a series about SAE J1939 ECU Programming & Vehicle Bus Simulation with Arduino. The communication of destination specific (peer-to-peer) multi-packet messages is subject to flow-control. Connection Initialization – The sender of a message transmits a Request to Send message. The receiving node responds with either a Clear [...]
This post is part of a series about SAE J1939 ECU Programming & Vehicle Bus Simulation with Arduino. Even though extremely effective in passenger cars and small industrial applications, the CAN Bus technology alone was not suitable to meet the requirements of truck and bus communications, especially since its communication between devices is limited to only 8 bytes per message. [...]
This post is part of a series about SAE J1939 ECU Programming & Vehicle Bus Simulation with Arduino. In order to broadcast a multi-packet message, a node must first send the Broadcast Announce Message (BAM), which contains the following components: Parameter Group Number (PGN) of the multi-packet message Size of the multi-packet message Number of packagesThe BAM message allows all [...]