Understanding J1939 SAE Protocol: The Complete Guide to Communication in Commercial Vehicles part-4.
Published: 2024-03-05 04:08:44

Hello Readers, 👋😃
My name is Aravind B. N., and I work at Luxoft India as a junior software developer. Luxoft has given me several opportunities to work on various projects, which has inspired me to discuss the important processes involved in learning the SAE J1939 communication protocol [Part-3](https://dev.to/arvind_b_n_luxoft/understanding-j1939-sae-protocol-the-complete-guide-to-communication-in-commercial-vehicles-part-3-4hh9) This is part 4 of the SAE J1939 communication protocol. Here we will discuss the Network Access and Solution and Configurations.

## Network Access
**Network Admission**
In J1939, the term network management should not be confused with that of network management in general automotive settings. In the automotive domain, network management is used to put the ECUs (Electronic Control Units) of a network into a defined “agreed upon” idle state without losing any bus information.

As, per the J1939 standard this term pertains to controlling access to communication (entry to the network) and managing device addresses, in networks. This is where properties such as device address and NAME come into play (see chapter Names and Addresses[[part-2]](https://dev.to/arvind_b_n_luxoft/understanding-j1939-sae-protocol-the-complete-guide-to-communication-in-commercial-vehicles-part-2-1bbc)).

**Address Claiming**

The simplest form of J1939 network management is when every ECU sends “Address Claimed” right after booting, before they start communicating. By using the 'Address Claimed' parameter group (PGN‎ 0x00EE00) it is possible to reveal the 'Address Claim' which includes the devices name and a standard reset device address. Mainly in static networks this is done so as to unveil the topology of a network. Therefore, an example would be diagnosing tools that will determine whether or not there is presence of retarder in vehicle.

**Conflict Resolution**

Similarly “Address Claim” also applies to dynamic networks. Furthermore, the network management can be used to address any address conflict that occurs here. These may occur, for instance, when an ECU is subsequently joined to a network (already in operation) and this ECU uses a predetermined address already utilized on the network. This conflict must be resolved as all addresses within the network should be unique and non-repetitive.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/oo0de8mynpyu1gbagdp1.png)

Fig: Address Claim Static

This figure appears like a representation of some events in a communication process between Electronic Control Unit (ECU) and Network possibly in automotive domain. ECUs are computerized controllers that handle many functions such as engine control/transmission/brake systems in vehicles. It is a simple timeline of how ECU gets initialized before communicating with the network.

**Here is what each section means:**

_Initialization:_ The dotted line on the left side titled ‘Initialization’ shows where ECU A starts its start-up sequence from. This could entail self checks, software booting up and getting ready to communicate over the network.

_250 ms delay:_ At the beginning, there is a 250-millisecond delay. This waiting sequence may be an own built-in ECU wait time before it tries to communicate on network to ensure that it is fully operational prior sending any messages or it does not conflict with others ECUs are starting up.

_Address Claimed (SA = 20)_: After the pause, ECU A claims an address on the network. It means Source Address, and this refers to a unique identifier for an ECU on the network; in such cases, this particular ECU is claiming number 20.For successful communication through a network, all other devices must identify data sent by ECU A and accordingly deliver responses.

_Standard Messages (SA = 20)_: Having claimed its address, standard messages start emanating from the ECU A via Its Source Address (SA = 20). They can represent any kind of information including data readings, status updates or control commands which are being handled by this specific ECU. The dotted vertical dash lines indicate that there are some messages transmitted one after another over a period of time to the network.

**Network:** The line, on the right labeled "Network" represents the network itself which could be a vehicles Controller Area Network (CAN) bus or any other type of communication system used for ECUs to exchange information. The arrows pointing from ECU A to the network indicate the direction of communication showing that ECU A is sending messages to the network.

The timeline at the bottom, with "t" likely signifies time illustrating the progression from the initialization phase through the communication phase.

In essence this diagram provides a high level overview of an ECU booting up obtaining a network address and then commencing its operation of transmitting messages to the network at set intervals.

## Solution & Configurations
**Priority**
The identifier is utilized to settle disputes and to prioritize addresses. Therefore when an address conflict arises through the "Address Claim " the devices, in question must compare their identifiers. This comparison process is conducted bit by bit commencing from the Significant Bit (MSB). Following the principle as CAN arbitration a zero takes precedence over a one. The identifier with the numerical value triumphs in the conflict resolution allowing the associated ECU to utilize that address. The behavior of the ECU possessing the lower priority identifier in this scenario is contingent upon its setup. There are four setups for ECUs in this context;

1.**Self-configurable**
Following address loss the device autonomously seeks an address, within the range of 128 to 247 and endeavors to secure it.
The animation depicts a scenario where two Electronic Control Units (ECUs) named ECU A and ECU B are initializing and vying for addresses on a network. It also showcases a conflict resolution process, for address claiming. Here's a breakdown of the events shown in the diagram;

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/x8kql11nciwep42fvu36.png)
Fig: Address claimed Dynamic.

1. **Initialization**: Both ECU A and ECU B begin their initialization process as shown by the dashed lines at the top of each line. This is where each ECU conducts self checks and gets ready to communicate on the network.

2. **Address Claimed by ECU A**:  ECU A secures an address on the network with the Source Address (SA) of 20. Is known as NAME A. This marks the step in establishing communication, on the network.

3. **Address Claimed by ECU B**: At the time ECU B also attempts to claim the same address, on the network (SA = 20) and is recognized by NAME B. This situation arises because two devices are competing to use the source address.

4. **Name comparison**: To resolve this conflict a comparison of names is carried out. Each ECU compares its NAME identifier to determine which one holds priority in claiming the address. In this scenario NAME A emerges as the higher priority choice over NAME B.

5. **Address Reclaimed by ECU A**: Following the name comparison process, ECU A successfully reclaims the address SA = 20 with its designated name, NAME A having secured priority, in the naming comparison evaluation.

6. **ECU B Searches for a New Address**: ECU B is now seeking an address after losing priority in the name comparison. It successfully secures an address SA = 128 under the name B. This enables ECU B to communicate on the network without any address conflicts.

7. **Continued Operation**: As, per the diagram following the address claiming process and conflict resolution both ECUs are seen to continue operating on the network with their addresses. ECU A maintains its usage of SA = 20 while ECU B now operates using SA = 128.

The vertical lines depict the two ECUs while the horizontal lines show the sequence of events, over time (t) for each ECU. The diagram illustrates how each ECU is assigned an address on the network for seamless communication and operation within a networked system like in automotive settings where multiple ECUs collaborate, without disruptions.

This concept will be covered more in the [next article](https://dev.to/arvind_b_n_luxoft/understanding-j1939-sae-protocol-the-complete-guide-to-communication-in-commercial-vehicles-part-5-a3o), with examples.
Do let me know if you have any queries in the comments below.

Thanks for reading.