Notes On J1939 Address Claim (Single Application): Notes

In 2010, many questions were raised about address claim, including how to "release" an address (of which no process exists within the J1939 specification) and how the API/VDA handles multiple addresses (more importantly - multiple RTS/CTS Transport Protocol sessions for multiple addresses). These questions led to an incorrect solution statement (although never making into a balloted version of RP 1210) by asking that the APIA/DA drop any previously held address when the Protect_J1939_Address command was issued. This incorrect solution implied that a VDA would only "handshake" for one set of TP messages destined for a single address that had been claimed by the VDA. This could have caused major application issues if a client wanted to use multiple J1939 addresses. For example, someone may want to write an engine/transmission/ABS simulator program (Addresses 0, 3, 11) that supports RTS/CTS on each address.

As mentioned in Required High-Level Functionality (Single Application) , a VDA shall support the protection/claiming of [VendorInformation] . Jl939 Addresses different addresses (from one or more clients) and the handling of RTS/CTS and BAM messages for those addresses.

BAM is being handled differently in RP 1210D in an effort to clarify different VDA behaviors. BAM messages will be allowed to be sent using any address, and BAM messages will be passed to the application without having to claim an address (they are "generic messages," just larger "generic messages").

The following text describes the correct handling of address claiming situations:

On startup, a VDA will not handshake for an RTS/CTS session for any address that has not been claimed/protected by a client (per J1939/81). Attempting to send any TP message (RTS/CTS or BAM) without claiming will result in the error ERR_ADDRESS_NEVER_CLAIMED being returned on the call to RP1210_SendMessage ( ). This was always implied in all versions of TMC RP 1210.
Separate clients can protect the same address (most use 249 or 250 anyway), resulting in those clients receiving all TP messages destined for that address (or the global address 255). It is up to the application to process or ignore these messages and determine if it was the correct recipient.
1. If the NAME for any claim of an address has a higher priority, then the APIA/DA will use that NAME and go through the J1939 Address Claim process again. This will not cause any "bumping/releasing" of PC client addresses (ERR_ADDRESS_LOST) because "IT IS" a shared address situation.
2. On successful claiming of a J1939 address using the highest priority NAME, the APIA/DA will handshake for TP messages destined to that address or the global address.
3. The VDA will respond to the address request message with the address and NAME of the highest priority NAME for each address it has protected.
An APIA/DA will maintain a list of [VendorInformation].J1939Addresses , J1939 addresses/NAMEs that the APIA/DA will handshake TP messages for "simultaneously." Any claim attempts over 16 would result in ERR_ADDRESS_CLAIM_FAILED.
An application/client can release a J1939 address by using the RP1210_SendCommand (RP1210_Release_J1939_Address), even though there is not an equivalent J1939 message/procedure.
1. If this is the last instance/usage of that address by a client, then the VDA stops handshaking or transmitting of any TP, RTS/CTS messages for that address (this was also assumed in all prior versions of RP 1210). The node appears to have "just gone away" in terms of RTS/CTS traffic.
2. If it is not the last instance, then the VDA sends the address claim messages using the next highest priority NAME.
3. When a client disconnects, the "reference count" for all addresses claimed will be decremented. If this was the last instance, see Item 4a above.

Since this is a relatively new concept, applications that are going to perform a critical function such as reflashing should prevent other clients and/or applications from connecting to the databus through the call to RP1210_SendCommand (RP1210_Disallow_Further_Connections ). They should also alert the user to disconnect any other applications that may be already running.

A new variable [VendorInformation].J1939Addresses has been created in the vendor INI file. This will allow applications to know if the VDA API supports only one (INI variable not found), or up to 16 J1939 addresses.

NOTE: Any scenario concerning multiple addresses through one hardware device creates concerns. This is primarily with regards to multi-application (MA/MC) uses cases. First, regarding above statement, if multiple clients claim the same address, with the RP 1210 drivers settling on the highest priority Name as the Name for that address, then a subsequent Request for Address Claimed PGN would result in drivers putting out address/Name combination that one or more clients would not recognize, prompting those clients to presume that they have lost the address. Users and software application providers should note the multiple possibilities for failure in this regard.