Additional Information

Site Information

 Loading... Please wait...

Guide To SAE J1939 - Address Claiming Procedure Overview

Posted by Wilfried Voss on

The following is an excerpt from A Comprehensible Guide To J1939 by Wilfried Voss.

A Comprehensible Guide to SAE J1939

While other higher layer protocols based on the CAN Bus do not support dynamic node address assignments per default, the SAE J1939 standard provides yet another ingeniously designed feature to uniquely identify ECUs and their primary function.

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

Each ECU in a J1939 vehicle network must hold at least one NAME and one address for identification purposes. Single electronic units are allowed, however, 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.

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.

Note: ECUs designed to accept destination specific commands may require multiple addresses, each with their corresponding NAME, in order to distinguish the required action. For instance, the torque from the engine as commanded by the transmission must be separated from the torque commanded by the brake.

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.

Note: The request for an Address Claimed message supports primarily self-configurable ECUs. The self-configurable addressing feature is not a requirement for all ECUs, i.e. it is optional, but it is highly recommended for those ECUs for which an address claiming conflict is considered to be highly probable.

There are several options to resolve the situation where an address claim conflict is being detected and they depend on the ECU’s capabilities. The address claim capability is categorized into two classes:

  1. Single Address Capable ECUs
  2. Arbitrary Address Capable ECUs

Note: The definition of Address Claiming Capabilities in SAE J1939/81 is somewhat vague, since (according to SAE J1939/81) “the classifications are not necessarily mutually exclusive”.


SAE J1939 ECU Simulator Board With USB Port

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. It allows any host device with a USB COM port to monitor SAE J1939 data traffic and communicate with the SAE J1939 vehicle network.

The board supports the full SAE J1939 protocol according to J1939/81 Network Management (Address Claiming) and J1939/21 Transport Protocol (TP). It is also supported by an extensive programming interface for Windows and Linux/Ubuntu applications, including full C/C++/C# source code for short time-to-market developments.

The strength of the board lies in the fact that the entire SAE J1939 protocol, including all timing requirements, is stored on-chip, thus taking the burden off the main system. The board uses a USB COM port to communicate with the main system, i.e. all data transfer is handled through a standard COM port access. 

The communication protocol between the board and the main system is well documented and thus allows a porting to any computer system with a USB connection. Working source code libraries exist for Windows (C# under Visual Studio 2012/2013), Linux and its derivatives (C++ using Code::Blocks), and Raspberry Pi (C using the standard gcc compiler).

More Information...