Introduction
Any controller application, or CA, that transmits on a J1939 network must successfully claim an address before transmitting. If a CA is only listening to bus traffic and not transmitting, it does not need to have or claim an address. When a CA does transmit a message on the network, the transmitting CAs address appears in the message ID of every message sent by that CA. The last byte of the 29-bit message ID is the always the source address, or the claimed address of the CA that is sending the message. For example, if the vehicle's transmission control module is sending PGN 0xFEF1 using its source address of 0x03, that message ID would be 0x18FEF103. You can see the last two hexadecimal characters 0x03 here representing the source address of the transmission controller, which is defined as 0x03 by SAE J1939. This is a quick and easy way to determine where a message is originating from. This also makes it possible for several different CAs to broadcast the same PGN without duplicating the message ID.
Each CAs address must be unique. That means that two controllers on a network cannot share the same source address. If two CAs attempt to claim the same address, only one of them can rightfully claim and use the desired address. The other must try to claim a different address that hopefully isn't already claimed by another CA. How does a CA determine if it should yield to a contending claim for an address? The NAME (SAE J1939-81 4.2.1) is used to determine which CA gets priority when claiming an address.
The NAME is a unique 64-bit identifier that is comprised of 10 fields. These fields are set based on characteristics of the CA, for example the industry group, vehicle system, function, manufacturer code, etc. The combination of these fields is unique for each CA, with the last field being used for a serial-specific identifier. The NAME is designed such that the fields that determine the CAs priority are in the more significant bit positions. For example, the field in the most significant position is set to zero if the CA can only have the one address it is attempting to claim. If the CA is flexible and can switch to a different address, this value is set to one. That way, the CA that cannot change its address has a NAME with a lower numeric value, and therefore is a higher priority than the CA that is capable of changing its address. The lower the numerical value of the NAME, the higher the priority it has during an address claim.
So what does an address claim look like? An address claim is initiated by sending a CAN message with the PGN designated for address management and the source address your CA is attempting to claim. For example, if you are attempting to claim address 0x32, the message ID would be 0x18EEXX32 (ref SAE J1939-81 4.5.8 for value of XX). The data fields are populated with your CAs NAME, but in reversed byte order with D0 holding the least significant bits and D7 holding the most significant bits. If another CA is already using the address your CA is attempting to claim, the NAME can be pulled from the data field and compared to determine if the address should be yielded to the contending claim.
There are three possible scenarios when claiming an address:
- Address Claim with No Contention - No other controllers want to use the address you are attempting to claim.
- Address Claim with Contention of Lower Priority - Another controller is attempting to use the address you are attempting to claim, and your NAME gives your CA a higher priority.
- Address Claim with Contention of Higher Priority - Another controller is attempting to use the address you are attempting to claim, and your NAME gives your CA a lower priority.
Address Claim with No Contention
This is the simplest scenario. We will send an address claim for a known, unused address and then start transmitting normally once that claim is successful. In the case of no contention, we still need to wait a few hundred milliseconds to allow other nodes to respond to our claim. Once our claim is successful, we will send message 0x18FEF1XX (arbitrarily chosen) with our source address (XX). The CAN transcript can be used to determine the amount of time delay between our address claimed message and the first transmission of 0x18FEF1XX. Table 1 is a sample of a CAN transcript from an address claim with no contention.
| MSG ID | DLC | Data |
|---|---|---|
| 18EEFF32 | 8 | FF 4E E0 9C 00 83 00 10 |
| 18FEF132 | 8 | FF FF FF FF FF FF FF FF |
Table 1. CAN transcript from an uncontested address claim for 0x32 on a vehicle network.
We can see the initial broadcast of our address claim message 0x18EEFF32 with our NAME, followed by a regular message sent using our newly claimed source address.
Address Claim with Contention of Lower Priority
In this scenario, another CA on the network will attempt to claim the same address we want to claim, but the contending CAs NAME is a lower priority than ours. Therefore, our application should prevail and claim the address and begin transmitting normally a few hundred milliseconds later. The challenging CA will need to try a new source address, or send a cannot claim message (ref SAE J1939-81 4.5.8).
The CAN transcript below shows two CA's trying to claim address 0x32. In this case, the CA with the data field D6 of 0x00 has the lower NAME value, and therefore wins the address claim. The CA with the data field D6 of 0x02 sends a cannot claim message, and our CA is allowed to continue transmitting normally with address 0x32.
| MSG ID | DLC | Data |
|---|---|---|
| 18EEFF32 | 8 | BC 80 26 03 00 1A 02 10 |
| 18EEFF32 | 8 | FF 4E E0 9C 00 83 00 10 |
| 18EEFFFE | 8 | BC 80 26 03 00 1A 02 10 |
Table 2. CAN transcript from a contested address claim for 0x32 on a vehicle network.
Address Claim with Contention of Higher Priority
In this scenario, we will attempt to claim an address but lose contention due to our NAME's numerical value being higher than the other CA that already claimed the address. Our CA will attempt to claim address 0x21, which is already claimed by the body controller. Since the body controller's NAME is a higher priority than ours, our application will either try a new address or send a cannot claim. In this example, we will just give up and send a cannot claim message. If we did want to try to claim a different address, we would just send another address claim using the new address. The cannot claim message should not be sent until all possible address claims have been attempted and lost and our CA is truly giving up on transmitting to the network.
Table 3 is the CAN transcript of our attempt to claim address 0x21 with a lower priority NAME than the BHM. We see the BHM's address claim (NAME ending in 0x10) followed by our address claim (NAME ending in 0xF0) followed by our cannot claim message (ID 0x18EEFFFE and NAME ending in 0xF0). Our CA can no longer transmit messages, but it can still read incoming messages in listen-only mode.
| MSG ID | DLC | Data |
|---|---|---|
| 18EEFF21 | 8 | FF 4E E0 9C 00 83 00 F0 |
| 18EEFF21 | 8 | BC 80 26 03 00 1A 02 10 |
| 18EEFFFE | 8 | FF 4E E0 9C 00 83 00 F0 |
Table 3. CAN transcript of a failed attempt to claim address 0x21.
Conclusion
If you are planning on sending CAN messages on a J1939 network, your CA must have a NAME and successfully claim an address. The J1939 standard is designed to grant the most important CAs their desired addresses, while still allowing less important CAs a chance to get on the network and transmit. The CAs address is used every time a message is sent to identify the source of the message. Because the address is unique, if your CA receives messages using its own rightfully claimed address, it can set a fault code to alert the operator that there is an impostor CA on the network. Conversely, your CA should never transmit regular messages using another CAs claimed address.
If you would like to learn more about the address claim procedure and NAME construction, read SAE J1939-81.