Scantec Automotive’s Ross Kemp returns this month with another diagnostic case study, which he believes demonstrates the need for the correct tooling, training, data and knowledge in carrying out a professional diagnosis.
I feel that the following example highlights the fact that to be successful in the art of vehicle diagnosis, you need not only the correct tools, but access to manufacturer technical data, ongoing training and, more importantly, product knowledge.
The vehicle in question was a BMW 5 Series, which was brought in by a customer complaining of multiple dash warnings, multiple fault codes and an intermittent battery drain. Initial visual checks confirmed that multiple dash warning lights and messages were present. Battery testing confirmed a low state of charge but good battery health on what appeared to be a fairly recently fitted, new battery. Once we had confirmed that the battery was in fact the correct fitment for this vehicle, we moved on to our initial diagnostic assessment.
Initial diagnostic analysis of the vehicle network, basic communication, and stored and historic fault entries confirmed initially that all modules (except the infamous Telephone module) were present and responding.
We noted a mere 64 fault codes either stored and/or present across the vehicle. Now this is where those that change parts based on fault codes may come a little unstuck. It’s important to remember here that although we don’t currently know the cause of the issues, one thing we do know categorically at this stage is that the battery goes flat. Understanding the product you are working on (or in this case the network) is going to be key to a prompt and correct diagnosis. When we analysed the 64 fault codes, there was a common thread of communication and/or missing network messages across multiple control modules.
At this stage, we needed to know: was a battery drain causing battery voltage to drop to a sufficient enough level that control modules would become ‘offline’, causing those still ‘online’ to post missing packet faults? Or was it a network-related fault causing the vehicle to stay awake and/or reawaken, causing the battery drain?
Use of the correct manufacturer diagnostic tools aided us initially in our diagnostic direction here, as we were able to run battery management testing to confirm that over a 100-minute monitoring period, the vehicle was actually woken some 97 times – therefore confirming to us that the problem we needed to tackle first was that of what was causing the vehicle’s network to be woken so many times.
Considering that the wake or sleep command to most of the vehicle’s control modules on this vehicle is carried over the communication network, it was clearly time to monitor this network for some further direction.
A quick look at the CAN network activity demonstrated that we clearly had a hard network fault, showing that CAN-H and CAN-L were in fact shorted together and not the expected ‘mirror image’ of each other (see below). Now, if we were going to expect this vehicle to not only communicate correctly but to be able to send shut down/sleep commands successfully, we were clearly going to have to deal with this issue first. However, it does go to show just how fault tolerant these CAN networks are, as we were still able to communicate with all the connected modules – even with the network in this state!
Using manufacturer data, we could confirm that there were some 22 control modules located all around the vehicle that were directly connected to this CAN network, so knowing that this could be any one of those 22 modules and/or the wiring between them causing this issue, we needed some direction.
It’s fairly common practice to isolate one module at a time while monitoring the network, but where to start? Again, product knowledge comes into play and depending on the specification of the vehicle, three or four of these modules are located in a nice easy- to-get-at location in the bottom of the spare wheel well and are known to suffer water damage. A quick inspection confirmed water was in fact present.
Whilst still monitoring the CAN network, we disconnected (one by one) the Micro power module, the PDC module and the EHC module and, as can be seen, we noted when disconnecting the EHC (Electronic Height Control) module that the network then started to operate correctly, confirming to us the water damaged module was the cause of our network issue (see below).
Leaving the EHC module disconnected from the network, we reconnected to the vehicle, cleared down all stored faults and carried out a further global vehicle scan, confirming on completion that all modules were present and correctly communicating (other than the disconnected EHC module of course) but more importantly, we now had no fault codes in any control module other than those reporting lost packets from the disconnected EHC module. Only then could we correctly monitor the vehicle’s shut down procedure and resulting final battery draw. Further testing confirmed the expected battery draw profile during the 16 minute shut down with a final battery draw of approx. 180 mAmps.
This complete and accurate diagnosis process from start to finish was achieved within a couple of hours. I would question that without the correct diagnostic tools, would we have known about the 97 wake up events? Would we have known which control modules were linked to this network and/or their locations within the vehicle without the correct technical data? Without the right test equipment (and training on how to use it) would we have been able to analyse the CAN network as quickly and easily? Would we have been able to find the affected EHC module as quickly without the product knowledge? Or would we still be stripping the car down now, trying to gain access to the other 19 modules that weren’t in the spare wheel well?
I would like to think that the above job goes some way to show that professional diagnosis is achieved by having the right tools for the right test, applied at the right time, with the right knowledge and data to interpret them. It’s definitely not changing parts based on fault codes and/or solely about having the right tool.
