Site Information

 Loading... Please wait...

The Two Elements of the SAE J1939 Protocol Stack

Posted by Wilfried Voss on

SAE J1939 ECU Programming & Vehicle Bus Simulation with Arduino

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:

  1. Each control application (CA) must be capable of providing its unique 64-bit NAME.
  2. CAs must successfully claim an address prior to sending messages (other than those for claiming an address) into the network.
  3. The inability to successfully claim an address must be handled and reported to the network.
  4. The CA must follow the network initialization associated with the address claiming process.
  5. The CA must support a minimum set of network management requirements, including required responses to power interruptions.

For more information, see:

SAE J1939 Starter Kit And Network Simulator

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).

More Information...