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

According to SAE J1939/81, network management procedures are used to “collectively manage the network”. The chapters on network management have no logical structure (Again, explaining the function of an automobile, starting with the details of the fuel injection system); they explain the address claim messages first in detail and then follow up with the actual procedure.

In all consequence, the network management is all about the Address Claim procedure and this procedure utilizes three messages and their PGNs:

• Request Message (PGN 59904)
• Address Claimed / Cannot Claim (PGN 60928)
• Commanded Address (PGN 65240)

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.

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.

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 picture demonstrates two possible address claim scenarios.

Both scenarios basically show the same: Two nodes, A and B, are claiming the same address; node A has a NAME of higher priority. Node B, in the left scenario, is not a self-configurable ECU, meaning it requires external actions to claim another address.

In the right scenario, node B is a self-configurable ECU and eventually will claim another source address.

The following describes the steps in detail:

• Node A starts initialization and Power-On Self Test (POST) some time ahead of node B.
• While node B is going through initialization and POST, node A sends out it address claim message.
• Node B, after having finished initialization and POST, attempts to claim the same source address as node A.
• In response node A, having determined that its NAME has higher priority, resends the address claim message.
• Node B receives the address claim message, determines that node A’s name has higher priority.
• In the left scenario, node B sends a Cannot Claim message. In the right scenario it claims another address by sending another Address Claim message.

The scenario as mentioned may happen when two ECUs try to claim the same source address at exactly the same time. The following picture demonstrates this possibility.

In this example, both nodes, A and B, are powered up at the same time, their Power-On Self Test (POST) takes the same time and both nodes send out their Address Claim message at the same time. The probability for such a situation taking place may be extremely low, but the consequences can be serious.

The CAN standard does not allow a situation where two nodes use the same message ID. This scenario will create a CAN error frame and both nodes will attempt to claim the same source address repeatedly, until both nodes switch into the Error Passive mode which in turn will limit their network communication capabilities. Experience has shown that both nodes will eventually return to normal operation, but the time it takes is first of all unpredictable and proper network function cannot be guaranteed.

SAE J1939/81 recommends an Address Claim Bus Collision Management. The procedure is to check the occurrence of an error frame and to use different delays in both ECUs before they claim their address again. The transmit delay should be calculated by producing a “pseudo-random” delay value between 0 and 255.

Note: SAE J1939/81 explains that, during this process, both nodes would go eventually into BUS OFF mode. However, this statement is not backed up by either the CAN standard (which categorically does not allow two messages with the same ID) or empirical tests.

Tests (not accomplished by the SAE) have shown that the two competing nodes will go into Error Passive mode and both nodes will eventually return to the regular Error Passive mode. However, the time until both nodes return to regular activities is unpredictable and so are the consequences for the application.

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