Skip to content

J1939 Source Address Assignment Behavior

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
Byte number in CAN messageContents/Meaning
0Identity number, LSB
1Identity number
2Bits 0-4: Identity number, MSB
Bits 5-7: Manufacturer code, LSB
3Manufacturer code, MSB
4Bits 0-2: ECU instance
Bits 3-7: Function instance
5Function
6Bit 0: Reserved bit
Bits 1-7: Vehicle system
7Bits 0-3: Vehicle system instance
Bits 4-6: Industry group
Bit 7: Arbitrary address bit

 

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:

CAN identifier:0xCF00401
Data Bytes:0xFF FF 82 DF 1A FF FF FF

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 bytesFFFF82DF1AFFFFFF
Position12345678

 

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.

Network Management under J1939 is primarily represented by the Address Claiming Process. While other higher layer protocols based on Controller Area Network (CAN) do not support dynamic node address assignments per default, the SAE J1939 standard provides this ingeniously designed feature to uniquely identify ECUs and their primary function.

SAE J1939/81 prefers the use of CA (Controller Application) rather than ECU (Electronic Control Unit). In all consequence one ECU can run multiple CAs. Each Controller Application will have one address and associated NAME. The following chapters will continue using the term ECU, which is a synonym for CA.

Address Claiming Procedure Overview

Each ECU in a J1939 vehicle network must hold at least one NAME and one address for identification purposes. Single electronic units are allowed to control multiple names and addresses.

The 8-bit ECU address defines the source or destination for messages.

The ECU NAME includes an indication of the ECU’s main function performed at the ECU’s address. A function instance indicator is added in cases where multiple ECUs with the same main function share the same network.

The J1939 standard allows up to 253 ECUs with the same function to share the same network, where each ECU is identified by their individual address and NAME.

The CAN standard in itself does not support node (ECU) addresses, only message IDs, where one node may manage multiple messages. However, the message ID must be hard-coded in the application program. Also, in a standard CANopen network the node address is usually hard-wired or mechanically adjustable (e.g. per dip switch).

SAE J1939 defines a 64-bit NAME, as shown in the picture below, to uniquely identify each ECU in a network.

While the 64 bit NAME is certainly appropriate to uniquely identify nodes (ECUs) and their function in a J1939 network, it will nevertheless necessitate unreasonable resources to maintain standard communications.

In order to provide a more efficient solution, the SAE J1939 Standard defines an address claim procedure, where each ECU utilizes an 8 bit address to identify the source of a message or to access (destination address) another ECU in the network. The address claim procedure is designed to assign addresses to ECUs right after the network has been initialized and thus assuring that the assigned address is unique to the ECU. For instance, an engine may be assigned the address 0 while another engine is present, which will be assigned another address (e.g. 1) and instance.

In addition, the SAE J1939 Standard defines Preferred Addresses to commonly used devices in order to minimize the rate of multiple devices demanding the same address and consequently optimizing the address claim process. ECUs will generally use their assigned Preferred Address immediately after the power up process, but in order to prevent any address claim conflicts, each ECU must first announce which addresses it intends to claim.

The address claim feature considers two possible scenarios:

  • Sending an Address Claimed message

This first scenario addresses a standard J1939 network startup. Upon powering up (or when requested), an ECU will send an Address Claimed message into the CAN bus in order to claim an address. All ECUs receiving the address claim will record and verify the newly claimed address with their internal address table. In case of an address conflict, i.e. should two or more ECUs claim the same address, the ECU with the lowest NAME value will succeed and use the address as claimed. The remaining ECUs must claim a different address or stop transmitting to the network.

  • Request for Address Claimed message

Requesting an Address Claimed message from all nodes in the network and, as a result, determining addresses claimed by other ECUs, is the necessary procedure for ECUs powering up late for various reasons, but especially transitional ECUs. Such transitional ECUs may be diagnostics tools, service tools, and trailers, etc. This approach allows the ECU to determine and claim an available address or to find out which ECUs are currently on the network.

Addresses

The J1939 protocol utilizes an 8 bit device (ECU) address, which, theoretically, would allow the operation of 256 nodes in the same network. It can only be assumed that the SAE was trying to keep the bus traffic on a low level by restricting the maximum number of nodes to 30. 

In all consequence, the ECU address is really a Controller Application address in a situation where each ECU may accommodate several Controller Applications. The 253 addresses (Address 254 is reserved for Network Management, Address 255 is used for global addressing) are assigned (claimed) for the Controller Applications, not the actual ECU.

The following picture shows an example, where, for instance, ECU A accommodates three controller applications.

The picture also demonstrates that ECUs of the same function (ECU A) can co-exist in a J1939 network without address collision. J1939 features a very ingenious feature, the Address Claim procedure which automatically assigns addresses to each Controller Application. In case of an Address Claim conflict, the Controller Applications are able to claim another free address.

NULL Address

The address 254, the so-called NULL Address, is reserved for network management, and it is used for the Cannot Claim Source Address message.

Global Address

The Global Address (255) is exclusively used as a destination address in order to support message broadcasting (sending a message to all network nodes).

Address Claim Procedure

The address claim feature considers two possible scenarios:

  • Sending an Address Claimed message

This first scenario addresses a standard J1939 network startup. Upon powering up (or when requested), an ECU will send an Address Claimed message into the CAN bus in order to claim an address. All ECUs receiving the address claim will record and verify the newly claimed address with their internal address table. In case of an address conflict, i.e. should two or more ECUs claim the same address, the ECU with the lowest NAME value will succeed and use the address as claimed. The remaining ECUs must claim a different address or stop transmitting to the network.

  • Request for Address Claimed message

Requesting an Address Claimed message from all nodes in the network and, as a result, determining addresses claimed by other ECUs, is the necessary procedure for ECUs powering up late for various reasons, but especially transitional ECUs. Such transitional ECUs may be diagnostics tools, service tools, and trailers, etc. This approach allows the ECU to determine and claim an available address or to find out which ECUs are currently on the network.

After completing their Power On Self Test (POST) ECUs (Controller Applications) claiming addresses in the 0 to 127 or 248 – 253 range may initiate their regular network activities immediately, while other ECUs should not begin until a time of 250 ms after claiming an address. This allows competing claims to be resolved before the address is being used.

In the event that two ECUs attempt to claim the same address, the ECU with the lowest NAME value will succeed and use the address as claimed. The remaining ECUs must claim a different address by sending another Address Claimed message containing a different address or send a Cannot Claim Address message.

The destination address for an address claim is always the global address (255) in order to address all nodes in the network.

A node, that has not yet claimed an address, must use the NULL address (254) as the source address when sending a Request for Address Claimed message.

The following flowchart demonstrates the address claim procedure in detail:


A Comprehensible Guide to J1939

SAE J1939 has become the accepted industry standard and the vehicle network technology of choice for off-highway machines in applications such as construction, material handling, and forestry machines. J1939 is a higher-layer protocol based on Controller Area Network (CAN). It provides serial data communications between microprocessor systems (also called Electronic Control Units - ECU) in any kind of heavy duty vehicles. The messages exchanged between these units can be data such as vehicle road speed, torque control message from the transmission to the engine, oil temperature, and many more.

The information in this book is based on two documents of the SAE J1939 Standards Collection: J1939/21 - Data Link Layer J1939/81 - Network Management A Comprehensible Guide to J1939 is the first work on J1939 besides the SAE J1939 standards collection. It provides profound information on the J1939 message format and network management combined with a high level of readability.

=> Read More...