Decoding automobile network communication challenges

Network communications are an essential part of modern vehicle operations. Most vehicles today possess multiple modules that use shared information across different networks with some network protocols being different. Certain modules are responsible for linking these devices and other electronic systems in the vehicle together. However, when communication faults occur, they can surface various problems, from erratic vehicle operation to warning messages annunciated on the instrument cluster, along with decreased vehicle performance and potential safety deficiencies. In this article, we will discuss the common causes of automobile network communication faults and troubleshooting techniques.

We’ll go over some of the basic methods used in troubleshooting network problems such as using an ohmmeter to quickly assess an HSCAN network’s wiring connection integrity and how to go about checking for an intermittent high resistance condition you suspect the vehicle of having. We’ll also discuss how using a lab scope can be especially useful when inspecting live network communication signals, as well as some alternate diagnostic methods utilizing different tools that may prove to be beneficial not only for troubleshooting but for growing your knowledge on this topic as well.

Today, the service technician responsible for troubleshooting network communication problems must possess a unique set of skills that will allow him or her to navigate complex vehicle systems and drill down to locate and rectify trouble. In some cases, the vehicle may have an intermittent network problem, and this is where the job can become the most difficult and time-consuming.

In my opinion, network communication faults will require the technician to possess the following at a minimum:

Network basics: An understanding of the distinct types of networks which each require a different approach. For this article, we’ll be focusing on HSCAN (high-speed controller area network) which is typically operating at 500kbps, and we’ll also briefly discuss local interconnect network (LIN) which is a popular choice for low-speed, non-mission critical communication due to its low cost.

Electrical fundamentals: An understanding of ohms law, basic circuits, power, ground, voltage drop, and the ability to understand and decipher wiring diagrams and knowing where else to source information to establish a sound understanding of the system you’re currently addressing.

Tool awareness: Understand how to assess a tool’s strengths and weaknesses and how to apply them to make the best use of the tool when the time is right. Possessing basic DVOM skills will go a long way toward helping the technician get on the right track to success, especially regarding circuit resistance testing.

Diagnostic scenarios can be classified as either a hard fault (good) or an intermittent fault (bad). We'll go over both.

For the most part, faults caused can be placed into three buckets:

1. Connections
2. Module failure
3. External influence

Within these buckets, we can tie the following conditions to each. 

Connections

Connectors are potential failure points and can serve as potential test and isolation points. Connection problems can be caused by conditions such as terminal fretting, or they could have been influenced by previous service events or external influences such as moisture or improper testing (otherwise known as maintenance-induced failure). Accurate wiring diagrams and connector locator tools are essential for proper troubleshooting (Figure 1).

Some manufacturers do an excellent job of locating network junction points which can be extremely useful for diagnostics such as shown in Figure 2.

Module failure

Verification of bucket #1 is an absolute must before condemning a module and possessing a solid understanding of how a module is powered and commanded to wake up is essential. Additionally, understanding where relevant messages originate, which modules are complaining, and when their complaints surface will greatly assist the technician in assessing the situation.

External influence

External influence is always a possibility, and this is why performing visual inspections is a must. I recommend following this pathway so that your initial visual inspection isn’t influenced by any specific fault. I find myself picking up potentially useful information when taking a quick look under the hood, under the dash, seats, and cargo areas, especially when looking for any add-on communication devices. Additionally, I like to walk around the vehicle inspecting for evidence of collision repair or other service events that may have introduced problems. This provides a global view of the vehicle I can use during the next phases of diagnostics, greatly enhancing the decision-making processes to come. Your front office staff should always be questioning your clients for clues that might prove to be useful. I have an example to share with you later in this article about a scan tool that induced a communication fault (U0235) that stayed active even after the tool was disconnected.

HSCAN circuit basics

Not all HSCAN networks are the same, but they all have terminating resistance. Terminating resistance is used in high-speed networks to minimize signal reflections that result from rapidly changing voltage levels. Many HSCAN systems utilize two terminating resistors which are typically located at the ends of the network. There are many network construction guidelines manufacturers follow regarding the overall length of the wiring, number of modules, and network message load. It’s quite common to see two 120-ohm terminating resistors used at the end of each network backbone but it isn’t always the case. General Motors typically uses passthrough wiring for its two-wire CANBUS systems. This allows the technician to troubleshoot network wiring integrity more effectively than other systems that use stub harnesses to link modules to the network. With GM’s circuit, a technician can truly assess total wiring integrity by leveraging terminating resistors where some other manufacturers are different.

For example, Volkswagen Audi Group, (VAG) will utilize a single module to serve as the primary termination point and this is usually done by using a resistance value of about 60 ohms. Additionally, the other modules will also be equipped with a higher level of termination between CANH and CANL, typically 2k-3k ohms. The design of the network is usually driven by the manufacturer and their component suppliers. The technicians will need to familiarize themselves with this information so it can also be leveraged during diagnostics. Missing termination will result in high signal reflection and improper communication. However, some vehicles may use multiple resistors so beware and never assume that the network design is the same from one vehicle to another. VAG vehicles use shorter wiring stubs between their modules which allows them to minimize signal reflection, allowing the use of a centralized primary resistor in the ECM. You may have also noticed that HSCAN wiring utilizes a twisted pair wiring, and this is because any electromagnetic interference on the harness will affect both CANH and CANL electrical signals equally so that the voltage difference between the two is unaffected if such a condition were to occur. Additionally, you may not always find the exact info you need within service information. Often, I find myself researching training documents offered by the OEM or aftermarket resources for additional insight.

Error reporting

HSCAN messages are broadcast on the network and are received by modules that have a responsibility to report any errors they receive. This is done via the CRC (cyclic redundancy check). A CRC is a common method used for validating digital messages. If you’ve ever scoped an HSCAN circuit, you will have likely observed a one-bit spike at the very end of the message. This is an acknowledgment bit and the reason it is elevated is because it is a sum of all the modules acknowledging the message at the same time. If the CRC doesn’t match, then this is where the tracking of error messages kicks in. Managing these errors can assist in telling an offending module to switch offline temporarily and then come back online after a brief period. Essentially, the design and function of this is complex and will take an accumulation of errors to cross a threshold before advising a module to switch off. What this means is that there may be a few errors on a bus over time that won’t result in any negative operation of the vehicle. The tools we commonly use today do not show us error messages statistically but there are tools out there that can (Figures 3 and 4).

Troubleshooting

You may be presented with a vehicle containing a fault from one module stating that it can no longer communicate with another module. This may be one of the simplest types of failures and here’s why. The modules deployed on the vehicle from the factory designed to be part of a network have been engineered to work under very robust conditions. The language they all speak has been carefully refined and has been designed to look out for each other. In the event that a module drops offline, their counterparts are at the ready to raise awareness of their visibility or lack thereof. When you’re presented with such a problem you will need to know a few things about that module which are as follows:

• Module location (inside or outside of the vehicle)
• Power and ground supply points
• Any connections between the module and the rest of the vehicle
• How the module is activated for action

Armed with that information you would now want to find the most efficient way to analyze the situation. If this device has a single power source protected by a fuse that isn’t responsible for supplying power to any other components on the vehicle, then you have the upper hand. From this single fuse, you may be able to learn more about this module quickly. If I’m presented with such a scenario, I’ll not only check for voltage on either side of the fuse, but I’ll install a fused current loop in place of the fuse so I can measure current flow since this will give me a sense of whether the module is able to power up and attempt to work or is the device down for the count. If I find the protected supply voltage is sufficient at the fuse and has zero energy being consumed, I am now interested in validating the ground side of the module. And from there I’ll be looking into how the module is activated for service, and now I’m prepared to properly analyze the module.

At the module armed with an accurate connector pin-out diagram, I’m ready to test.

In the scenario where you have multiple modules reporting communication faults with other modules, then a close look at an accurate wiring diagram is step number one. When analyzing the diagram take note of where each module is located (inside or outside) on the vehicle, how it is wired into the network, and how termination is provided. Some wiring diagrams do an excellent job of calling out terminating resistors and their values while others require more research to surface this information. Understanding how the system is wired is crucial since you may find a module serving as a pass-through device (Figure 5) potentially offering up a convenient testing location.

In the condition where the faults are intermittent (non-hard fault) you may need to deconstruct the series of DTCs initially encountered and compare those to new faults that may have been set after a code clear. Using this information can aid the technician with enough evidence to hold against a module you suspect as being the source of the intermittent failures.

For example, we recently had a 2015 Volkswagen Eos arrive at the shop with the following complaints:

“The customer drove the vehicle in. The customer states that the MIL steering and EPC light came on yesterday. The ABS light intermittently came on for about a week and the brake light flashed. Inspect and advise on repairs.”

The initial inspection revealed the following list of faults:

Engine control module 1 

• U1017:00/532 71:000 / ABS brake control module read out DTC (active/static)
• U1017:00/532 71:000 / ABS brake control module read out DTC (passive/sporadic)
• U0415:00/501 97:000 / Invalid data received from anti-lock brake system control module (active/static)
• P0501:00/012 81:000 / Vehicle speed sensor 'A' range/performance (active/static)

Transmission electronics 

• 17106:000 / Output speed sensor circ., no signal (passive/sporadic)
• 18201:000 / Transmission output speed sensor 2, no signal (passive/sporadic)
• 18255:000 / Read DTC memory of ABS CM (passive/sporadic)

Brakes 

• 03840:000 / Right front speed sensor, incorrect signal (passive/sporadic)
• 00285:003 / Right front ABS wheel speed sensor, mechanical malfunction (passive/sporadic)
• 00285:012 / Right front ABS wheel speed sensor, electrical error in circuit (passive/sporadic)
• 00283:012 / Left front ABS wheel speed sensor, electrical error in circuit (active/static)

Air conditioning 

• U111300 / Function limitation due to received malfunction value (passive/sporadic)

Electronic central electric 

• 01038:000 / Central locking overheating protection (passive/sporadic)

Airbag 

• 01316:008 / Brake control module, implausible signal (passive/sporadic)

Power steering 

• 01316:013 / Brake control module, please read DTC (passive/sporadic)

Tire pressure monitoring 

• 02801:002 / Hard warning 1, lower limit not reached (passive/sporadic)

Looking at the list above and correlating the results might have one thinking that there is a problem with the ABS control module and the reason for this is that the following list of modules is reporting that the ABS control module isn’t doing its job:

• Engine
• Transmission
• Air conditioning
• Airbag
• Power steering

The first thing I observed while looking at this diagram (Figure 6) is that this network is isolated from the J1962 OBD-II diagnostic port. Secondarily, I see that this vehicle has a Data Bus Diagnostic Interface (J533) that serves as a gateway between three different two-wire busses and a LIN bus and could serve as a potential test point. The next question I have is, 'How is termination performed on this network?' I started reading within service information (SI) and found the following when searching for “terminating resistor” (Figure 7).

What I found with this system is that the engine controller possesses the main terminating resistor while all the other modules on the circuit have high resistance (about 2.7k ohms) between their high and low circuits. What this means is that there is an overall 60-72 ohms of bus terminating resistance in this circuit. If the ECM BUS connections had high resistance, then my measurements would be much greater than this.

With the vehicle powered off (sometimes requiring a battery disconnect) a DVOM can be deployed to begin interrogating of the network connectivity by assessing terminating resistance. However, this is highly dependent on network wiring. In most cases, the technician can assess network wiring integrity and then begin performing connector integrity (wiggle) testing but only after they have a solid understanding of the wiring and termination strategy. But you may ask, how do I verify the integrity of the other modules on the network, and can I leverage the fact that there is a 2.7k ohm in the other modules? With the ECM disconnected and measuring the resistance between CANH and CANL, your measurement would reflect the entire parallel resistance of the circuit. The number of modules on the circuit would dictate the value however, with the meter in sight, one could start wiggling suspect connectors looking for a change in resistance. Another test to perform is the resistance test from CANH and CANL to ground and B+. Obviously, either of those with continuity would result in a major network failure.

On the VW example, all connections were found to be problem-free and after clearing all the DTCs and road testing the vehicle on several occasions over the course of a couple of days, the problem resurfaced which occurred right after startup. Not all the previously reported DTCs were set but enough information was gathered which pointed to a module fault. In this case, it was the brake control module that was suspected to be at fault in the beginning.

U0235 case study

Recently, one of my apprentices informed me that his friend's 2019 Toyota Tacoma was exhibiting an error message on the cluster stating that the pre-collision system was disabled and a U0235 was stored. This seemed to surface after they were using a scan tool on the vehicle at school. After performing some research, we discovered that this code was set when they entered test mode and then immediately exited that mode. Toyota’s service information provides more detail as to why this is. See Figures 8 and 9.

Tools for testing

DVOM: We’ve already discussed leveraging the power of the ohmmeter for testing but what about using the voltmeter or the scope? The voltmeter can serve a purpose by measuring CANH and CANL referenced to the ground. Since the non-dominant voltage level for each ride is at 2.5V, depending on how much traffic (bus load) there is the CANH will measure slightly higher than 2.5V and the CANL will measure slightly lower.

Scope: While the scope is a powerful tool, it must be used with caution since it can take the technician down the wrong pathway if he or she doesn’t know what to expect. An example of this is shown in Figure 6 where normal message arbitration is taking place. It’s entirely possible that a technician seeing this for the first time may begin to suspect that this is an anomaly and decide to research further. The higher levels shown are simply because at least three different modules started to communicate their message IDs (during the arbitration period) with one (or more) dropping off at the next bit until the message with the lowest ID won and was then able to continue to broadcast its message (Figure 10).

Sniffers: CANBUS sniffers may also provide support for network troubleshooting as they can provide additional information such as bus traffic (load) and other statistical data such as the number of errors and other data metrics (See Figures 3 and 4). Knowing the bus load could prove to be helpful in cases where aftermarket devices have been unknowingly added to the network and may be the source of the problems you’re researching. One that I’ve been using is CANCapture from eControls as mentioned earlier. Another tool is the PhysiCAN SnS GRIP Tester from Sital (Figure 11) which comes with Windows software. This tool requires specific network configuration information so it can leverage its proprietary time domain latency algorithms to identify trouble. I know a technician who works for Rivian who uses this tool regularly for troubleshooting.

Other networks

A local interconnect network (LIN) bus is a single-wire network that typically operates at a much lower speed and has a 0-12V digital signal. This network will have one master module and can have a maximum of 16 nodes connected. Any messages on this bus that need to be shared with other non-LIN modules the transfer of this info will be carried out via a gateway module. I have a video sharing how I was able to leverage a breakout junction on a 2013 Chevrolet Volt to diagnose a faulty module that was pulling the LIN bus down. The diagnostic steps utilizing the oscilloscope begin here: youtu.be/YAKJsiy4rh4?t=176.

Conclusion

This article discussed vehicle network fault troubleshooting and highlighted some of the causes of network communication faults, such as poor connections, damaged wiring, and malfunctioning control modules. We also discussed various tools and techniques that can be used to troubleshoot and diagnose these faults, including digital multimeters, scan tools, oscilloscopes, and CANBUS sniffing tools. Overall, just remember the importance of following the vehicle manufacturers' recommended procedures for scanning the vehicle so one doesn’t inadvertently inject a problem into a vehicle during service.