Example of Diagnosis of Network Issues on GM Vehicles with Gateway Modules

Isolated Networks, incorporating "Gateway Modules" have become a topic of interest lately. So, what does this mean for a diagnostic technician faced with diagnosing a vehicle that exhibits issues?

As the old saying "You can't get there from here", it seems to be the situation or at least a belief by some technicians. The fairly recent introduction of modules having names such as "Serial Data Gateway Module" or, "Central Gateway Module" is simply for the purpose of cyber security. We can thank the "hackers" for this added layer of security, which may make the diagnosis slightly more challenging or at least interesting and labour intensive than before.

So, let's explore what is really happening, by considering how data bus communication diagnostics have been conducted for some time now. This post will describe only GM products, since that is my exclusive focus. Your mileage on other manufacturer offerings may vary. Feel free to post for comparison.

For an example of a non-gateway protected network, I will use a 2014 Chevrolet Cruze with a suspected Low Speed GM LAN communication issue. Using GM SI, Identifying the pathway from the Diagnostic Starting Point - Diagnostic System Check - Vehicle (DSC-V) - Power and Signal Distribution - Data Communications - Diagnostic Information and Procedures, we arrive at the options for diagnosis of the affected network. We view: the typical "Scan Tool Does Not Communicate with" options for:

Chassis High Speed GM LAN Device 

High Speed GM LAN Device 

Low Speed GM LAN Device

Selecting "Scan Tool Does Not Communicate with Low Speed GMLAN Device", leads to doc # 2709024 that includes a diagnostic fault table, plus a host of scripted diagnostic steps and expected results.

As is usual with networks, it is necessary to verify power, ground and the data bus integrity by performing some routine circuit tests with a Digital Multi-Meter (DMM), (or insert your tools of choice here) to achieve these very basic tests and analyze the results. Of course, LS GM LAN does require a momentary wake-up signal. 

Now, I do realize that GM utilizes a single wire LS GM LAN, in contrast to twisted pair LS CAN that some other manufacturers use. The actual step by diagnosis is not the focus here, but rather how we can "see" the modules on the bus with the tools that we have in our arsenal.

The easiest condition to deal with, is when a single module is not communicating, but not affecting the rest of the activity on the bus. Now, the vehicle in question has 13 modules directly connected to the LS GM LAN and all are wide open for circuit testing directly from the vehicle X84 Data Link Connector. So, if an intrusion attempt with corrupt data is successful via access through the radio using simple brought in media, the system can be grossly and adversely affected.

In the example used above and as has traditionally been the case, LS GM LAN diagnostics can at least initially be performed directly at DLC terminal # 1 to identify the type of fault affecting the bus. Beyond the above model with a non-secure network, for comparison we will now use a 2018 Chevrolet Cruze as an example of a vehicle fitted with a Serial Data Gateway Module (SDGM) and demonstrate how the information is displayed during a typical Vehicle DTC Check using GDS 2.

Any corrupt software, whether brought into the vehicle in media format through the infotainment system or via telematics, must be "quarantined" and prevented from negatively impacting vehicle control systems.

So, let's see how the 2018 Cruze differs to the 2014 model. Following a similar path, Power and Signal Distribution - Data Communications - Diagnostic Information and Procedures, we arrive at three new diagnostic opportunities for consideration in addition to the traditional pathway: Scan Tool Does Not Communicate with High Speed or Low Speed GM LAN Device. 

Scan Tool Does Not Communicate with Gateway Expansion High Speed GM LAN 

Device Scan Tool Does Not Communicate with Gateway Isolated High Speed GM LAN Device 

Scan Tool Does Not Communicate with Gateway Expansion Low Speed GM LAN Device

These new options are supported by DTCs, U007B, U007C and U007D respectively:

"Scan Tool Does Not Communicate with Gateway Isolated Expansion HS GM LAN / HS GM LAN/ LS GM LAN Devices, requires a different approach. With modules behind a secure "gate", the scan tool cannot access modules on the "dirty" side of the network. The only side of the network accessible in the traditional way from DLC terminal 1 is the "clean" side. The word “dirty” is simply used to describe points readily accessible via infotainment and telematics etc.

If something results in an issue on the isolated side of the network beyond the K56 SDGM, the scan tool will receive and display some information. However, unlike the previous example of a wide open network, "you can't get there from here" using the DLC terminal 1 and the DMM to diagnose circuit integrity.

So, let's take a look at how a healthy LS LAN appears on this vehicle with a SDGM in Figure 1. below There's green check marks for modules that are communicating and red circles with a line through identifying modules with no communication. Perhaps we should first qualify whether those red circles are identifying non-communicating modules, or whether those modules are not fitted to this particular vehicle.

Using the vehicle RPO code list or whatever means we have, we can review which modules the vehicle was built with. In this case, the vehicle is not optioned with the modules that are listed with "No Communication". This is where identifying the vehicle build is essential.

You will see that the modules are listed is in random order. We can re-organize the modules for better viewing, since LS GM LAN on terminal # 1 is the focus.

Clicking on the "DLC Pin" button will put the modules in an organized list from Pin # 1 as shown in Figure 2.

Now, we can take a look to see how many modules that GDS 2 is able to "see". It appears that there are six modules on the LS LAN. These modules would be accessible using traditional testing means in the event of a failure.

However, let's "back the bus up a bit" and take a good look at the LS GM LAN. The list does not look complete to me since I'm familiar with the options, but what can we do to see if GDS 2 is not telling the truth?

Circa 2014, GM introduced a handy little piece of software in the form of the Data Bus Diagnostic Tool (DBDT). I've posted elsewhere about the value of this tool and it should not be overlooked. Let's see if it can shed any light on the suspicion that something is missing. Without using the tool, the bus schematics and RPO codes will provide some clues, but the DBDT is ready at hand. So, let's turn it on and set the DBDT to view DLC terminal 1 as shown in Figure 3. All ready to go! Click on the green check mark and we’re on our way...... Through the "eyes" of the DBDT, we now have a different and more comprehensive list of our "healthy" LS LAN than with GDS 2, as shown in Figure 4. We clearly now are viewing nine modules actively communicating on the bus!

Now, we can view the modules that are beyond the SDGM on the “dirty” side.

Let's see how the DBDT reacts when we introduce a fault onto the bus on the "dirty" side (the modules that GDS 2 did not identify) as shown in Figure 5.

We now have three modules that are "Missing In Action" (MIA) and the clock is ticking for the time that they are no longer communicating. You will notice that the BCM also has a time stamp. The BCM is able to communicate on both LS and HS GM LAN and thus is still able to report an issue. 

Repairing the fault which was a simple wire chafed on a metal frame, restored the modules presence on the bus that were "MIA" and the time to return to activity is shown.

So, while GDS 2 could not display all modules on the healthy GM LAN, the Data Bus Diagnostic Tool could display those on the clean side (DLC to SDGM) and those on the Isolated LS GM LAN ”dirty” side.

Well, that's all fine and dandy, but we still need some form of diagnostic information when there are issues on the bus. Using the same fault that was introduced on the Isolated side of the LS GM LAN, let's see how GDS 2 reacted when the fault occurred.

In Figure 6. we can see some yellow triangles, indicating when DTCs set. Consider for a moment that these were all modules on a healthy bus a few moments ago, but now have associated DTCs. At least these modules are still communicating, since they generated DTCs! Let's click on the "Details" button in the lower right of the display in Figure 6. for more information. A fairly extensive list of the affected modules is now displayed in Figure 7. Sifting through the list, these are all common to the modules on the "dirty" side of the system on the other side of the Serial Data Gateway Module.

So, taking DTC U007D as the DTC of interest and researching SI, we can establish a diagnostic path. "Scan Tool Does Not Communicate with Gateway Isolated Low Speed GMLAN Device" doc # 4337920, for those who like to trace the paths for themselves.

The Data Link References document # 4865502 will play a useful supporting role. The diagnostic path will require accessing circuits and possibly devices on the "dirty" side of the system beyond the K56 SDGM. The actual diagnosis is no different from physical tests and inspections anywhere on the vehicle, using conventional tools to obtain results that identify common circuit failures such as shorts to ground, shorts to voltage, open circuit/high resistance etc.

Justifying exactly why we may need to perform some significant disassembly of tight fitting and somewhat fragile plastic dashboard components to access the circuits beyond the SDGM may be achieved, by using GDS 2 and the Data Bus Diagnostic Tool. Beyond this it is basically down to performing some routine electrical circuit tests with our tools of preference.