Introduction

J1939 is a set of standards defined by SAE (there’s an overview here). They are used in heavy-duty vehicles such as trucks and buses, mobile hydraulics, etc. In many ways, J1939 is similar to the older J1708 and J1587 standards, but J1939 is built on CAN.

The physical layer (J1939/11) describes the electrical interface to the bus. The data link layer (J1939/21) describes the rules for constructing a message, accessing the bus, and detecting transmission errors. The application layer (J1939/71 and J1939/73) defines the specific data contained within each message sent across the network.

Quick Facts

• Higher-layer protocol built on CAN
• Used in heavy-duty vehicles
• The speed is nearly always 250 kbit/s or 500 kbit/s
• For a discussion specifically of the J1939 DBC file, click here.

Related Products

Message Format and Usage (J1939/21)

Most messages defined by the J1939 standard are intended to be broadcast. This means that the data is transmitted on the network without a specific destination. This permits any device to use the data without requiring additional request messages. This also allows future software revisions to easily accommodate new devices (address assignments). When a message must be directed to a particular device, a specific destination address can be included within the message identifier. For example, a request for a specific torque value from the engine instead of a specific torque value from the brake controller.

J1939 uses the 29-bit identifier defined within the CAN 2.0B protocol shown in Figure 1. The identifier is used slightly different in a message with a destination address (”PDU 1”) compared to a message intended for broadcast (”PDU 2”).

PDU stands for Protocol Data Unit (i.e. Message Format).

The SOF, SRR, and IDE bits are defined by the CAN standard and will be ignored here. The RTR bit (remote request bit) is always set to zero in J1939.

The 29-bit identifier used in J1939 is structured in the following way.

The first three bits of the identifier are used for controlling a message’s priority during the arbitration process. A value of 0 has the highest priority. Higher priority values are typically given to high-speed control messages, for example, the torque control message from the transmission to the engine. Messages containing data that is not time critical, like the vehicle road speed, are given lower priority values.

The next bit of the identifier is reserved for future use and should be set to 0 for transmitted messages.

The next bit in the identifier is the data page selector. This bit expands the number of possible Parameter Groups that can be represented by the identifier.

The PDU format (PF) determines whether the message can be transmitted with a destination address or if the message is always transmitted as a broadcast message.

The interpretation of the PDU specific (PS) field changes based on the PF value:

• If the PF is between 0 and 239, the message is addressable (PDU1) and the PS field contains the destination address.
• If the PF is between 240 and 255, the message can only be broadcast (PDU2) and the PS field contains a Group Extension.

The Group extension expands the number of possible broadcast Parameter Groups that can be represented by the identifier.

The term Parameter Group Number (PGN) is used to refer to the value of the Reserve bit, DP, PF, and PS fields combined into a single 18 bit value.

Example: The ID 0xCF004EE can be divided into the following fields in table 2.

Table 2. PGN example.

• PGN = the R, DP, PF and PS fields – in this case 0x0F004.
• PF = 0xF0 = 240, i.e. this is a PDU2 (broadcast) message
• PS = 0x04, i.e. the Group Extension = 4

The last 8 bits of the identifier contain the address of the device transmitting the message. The address is the label or “handle” which is assigned to provide a way to uniquely access a given device on the network. For a given network, every address must be unique (254 available). This means that two different devices (ECUs) cannot use the same address.

Addresses and Names (J1939/81)

The Name is a 64 bit (8 bytes) long label which gives every ECU a unique identity. The Name is composed of 10 fields and has the following structure shown in table 3.

Table 3. Structure of the Name.

1. Arbitrary address bit
2. Industry group, length 3 bits
3. Vehicle system instance, length 4 bits
4. Vehicle system, length 7 bits
5. Reserved bit
6. Function, length 8 bits
7. Function instance, length 5 bits
8. ECU instance, length 3 bits
9. Manufacturer code, length 11 bits
10. Identity number, length 21 bits

The main purpose of the Name is to describe an ECU. The lower Function field values, 0 to 127, are pre-assigned to “standard” functions or devices. The values 128 to 254 are dependent on the Industry Group and the Vehicle System values. This dependence makes it possible to have the same arrangement of functions in different vehicles. This system also allows devices such as trailers and agricultural equipment to limit their search for an available address and thus minimize the time and difficulty of dynamically claiming an address. When claiming an address, the Name is used to determine which ECU has higher priority and therefore will get the address that was claimed.

Each device on the network will be associated with at least one Name and one address. However, multiple device Names and multiple addresses may coexist within a single ECU. For example, an engine and engine brake (retarder) residing in a common device with a single physical bus connection. The device address defines a specific communications source or destination for messages. The Name identifies the functionality and adds a unique instance number of that functionality when multiple devices of the same type coexist on the network. Only 254 different devices of the same type can coexist on the network due the address limit. Address 255 is reserved as a global address for broadcast and address 254 is reserved as the “null address” used by devices that have not yet claimed an address or failed to claim an address.

Address Claim

In general, most addresses are pre-assigned and used immediately upon power up. In order to permit J1939 to accommodate future devices and functions which have not yet been defined, a procedure has been specified for dynamically assigning addresses. Each device must announce which address it is associated with. This is the identification (address claim) feature. Two options are available:

1. Send an Address Claim message to claim an address.

When a device sends an Address Claim message to claim an address, all devices compare this newly claimed address to their own table of devices on the network. If the address is already claimed by a device with a higher priority, that device transmits an Address Claim message indicating that the address is already in use. The Name, which is sent as data in the Address Claim message, determines which device has higher priority.

2. Send a Request for Address Claim.

When a device sends a Request for Address Claim, all devices respond by transmitting their Address Claimed messages. This permits transitional devices (tools, trailers, etc.) or devices powering up late to obtain the current address table so that an available address can be selected and claimed. See figure 2.

Dynamic address assignment support is optional and only those devices which might be expected to encounter address conflicts must support this capability. To eliminate the need to support dynamic address assignment and speed up this “identity process”, most ECUs are associated with a preferred address. These preferred addresses are described in the document J1939/71. If the preferred address is already in use by another ECU, the device can attempt to claim another address if self-configuration is supported by the device.

Transmitting Messages (J1939/21 and J1939/7x)

To send a particular data item, a message must be constructed with overhead that describes the data to be sent. Related data items are typically packed together within a message to reduce overhead. J1939/71 defines some standard PGNs which describe the parameters to be sent in a message. The J1939/71 document also includes information about message priority and transmission rate. Note that when a device does not have data available for a given parameter, the byte that should have contained this parameter is set to “not available” (0xFF) so that a receiver knows that the data is missing. Messages which need more than eight bytes of data can be sent as multi-packet messages. Multi-packet messages are transmitted by means of the Transport Protocol Functions defined in J1939/21. However there are two ways of transmitting multi-packet messages:

1. Broadcast Announce Message (TP_BAM)
2. Connection Management (TP_CM)

TP_BAM messages

TP_BAM messages use a global destination address which means that all devices on the network will receive these messages. The transmission is started with a Connection Management (CM) message, PGN = 0x00EC00, with a Control byte indicating TP_BAM. The message data follows in Data Transfer (DT) messages, PGN = 0x00EB00.

TP_CM messages

TP_CM messages are sent point to point between two devices. The transmission starts with a CM message with a Control byte indicating Request To Send (RTS). The receiving device responds with a CM message with the Control byte indicating Clear To Send (CTS). The transmitting device then sends the portion of the data indicated in the CTS using DT messages. This handshake of CTS then DT messages continues until the entire message is transmitted. The connection is terminated at the completion of the message by the receiver transmitting a CM message with a Control byte indicating End Of Message Acknowledgement (EOM). Note that for this process to work, the CM message contains additional data based on what the control byte is. The RTS includes: number of bytes, number of packets and the PGN whose data will be transported. The CTS includes the number of packets the receiver expects next and the packet number to start with.

Receiving Messages (J1939/21 and J1939/7x)

There are various techniques (and chips) available for capturing selected messages off the network. Several general observations can be made, however regarding received messages:

1. If a message is a destination specific request or command, the device must determine if the destination address matches an address claimed by the device. If there is a match, the receiving device must process the message and provide some type of acknowledgment.
2. If a message is a global request, every device, even the originator, must process the request and respond if the data is available.
3. If a message is broadcast, each device must determine if the content is of relevance or not.

ECU Design (J1939/1x, J1939/21, and J1939/7x)

Although every manufacturer will have different performance requirements for the electronic control unit (ECU) contained within their product, several observations should be made regarding the resources needed to support J1939. The current data rate of J1939 is 250 Kbps. A typical message containing 8 data bytes is 128 bits long (excluding bits used for bit stuffing) which in time is approximately 500 microseconds. The shortest message is 64 bits long. This means that a new message could be sent every 250 microsecond. Although not every message is relevant, nor is the bus loading likely to be above 50%, the receiving processor must be able to handle (or buffer) back to back messages for short bursts of time. This will require some RAM space as well as processor time for memory transfers.

Wiring Topology – Physical Layer (J1939/1x)

The J1939 network is intended to be a single, linear, shielded twisted pair of wires running around the vehicle to each ECU. A short stub is permitted between the ECU and the “bus”. This simplifies routing the main bus wiring by not requiring the main bus to connect directly to each ECU. The linear bus is necessary at a data rate of 250 Kbps in order to minimize electrical signal reflections. The termination resistor at each end of the bus also reduces reflections.

The J1939 network may actually be composed of multiple segments, with an in-line device known as a bridge present between them. These segments do not need to be directly compatible with each other. For instance, the segments may run at different data rates or use a different physical medium. The main function of the bridge is to provide electrical isolation between segments. In the event of a break on the wire between the tractor and trailer, the main J1939 segment on the tractor will continue to function. The bridge can also selectively filter which messages need to be stored and forwarded from one segment to another.

Example of how to interpret a J1939 message

This example is intended to provide the principles of how to interpret a J1939 message.
Let’s look at a J1939 message with the following content:

What information does the CAN-ID provide?

First two bytes = 0x0C = 00001100 in binary format. The first 3 bits aren’t used since the identifier only consists of 29 bits. The following 3 bits represents the message priority which in this case is 3. Thereafter follows a reserved bit and then the data page which are used to determine the complete PGN.

The last byte of the CAN-ID is the Source Address (address of the sending device) which in this case is 1.

The PGN = 0x0F004 which corresponds to the Electric Engine Controller #1 (EEC1) according to the J1939/71 document. This document also describes the parameters and their position within the data bytes. The data field consists of the following bytes in this example:

Data bytes 1, 2, 6, 7 and 8 in this example are not available and are therefore set to 0xFF. No raw parameter value (single byte) could have the value 0xFF.

Data byte 3 is the parameter Actual engine percent torque. The raw value 0x82 is 130 decimal. According to the J1939/71 document the scaling 1% per bit and the offset is -125. Therefore, the actual value for this parameter is 5%.

Data bytes 4 and 5 form the parameter Engine speed. The first byte (4) is the least significant (Intel byte order). The raw value 0x1ADF = 6879 decimal. The scaling is 0.125 rpm per bit and the offset is 0. The actual value for this parameter is therefore just under 859.875 rpm.