When I talk to technicians and shop owners about “remote diagnostics,” I find that there are many different levels of understanding as to what that term means. It’s clear that for many, the perception is that remote diagnostics means the ability to read codes. Well, if that is all we are talking about, it is true that a number of cars can generate a health report that includes things like DTCs, mileage and oil life.
I think most techs’ ultimate goal is to be able to diagnose a car that is not physically in their shop. One thing to note is that for this type of diagnosis to occur, some capabilities of control modules need to expand. For example, many PCMs or TCMs have a series of PIDs that display “desired” readings. This is the control module telling you what it was trying to accomplish and effectively showing you the specs it was targeting. This strategy also shows you the “actual” outcome of its efforts.
By comparing these readings, PIDs like input and output shaft speeds, and the Clutch Volume Index (CVI) alongside DTCs, a remote technician could do a pretty good job of determining what is going on inside a transmission, for example. Driveability problems are more complex now because we have fewer components that have the ability to self-test and display their strategy. As new sensors come to the market (and they are), granular data will be more available along with even the part numbers of the component that allow it to be checked against software and part updates.
These sensors will not be diagnosed with a lab scope. They will generate multiple PIDs digitally over a single wire and will effectively be modules that will generate U-codes when they fail to communicate. One of these technologies is SENT, or Serial Edge Nibble Transmission. These new sensors can be found in 2016 models, as carmakers are already dipping their toes into this type of communication technology. All of these new technologies are going to make remote diagnostics far more feasible, but let’s look at one more consideration.
There are a number of “dongles” out there that can hang off the OBD-II port and use Bluetooth and the customer’s phone service to generate certain scan tool PIDs. These could allow you to create a small data set to see what is going on. The trick with these is working out a way to have it in your customer’s car when it is needed. It is certainly not practical to put a $40-$100 device in every customer’s car “just in case.” For practical purposes, this type of hardware is going to be something you put in the car when you have a problem and you want to be able to watch it over time.
NETWORK VULNERABILITY
By installing a device that opens up a communication port into the vehicle network, the shop is also opening up an attack surface into that vehicle’s systems and creating a liability situation for themselves at the same time. It has been well-publicized that a vehicle’s Controller Area Network (CAN) is pretty easy to upset through the OBD-II port, so let’s just table that discussion and focus on cost and practicality for the sake of this article.
If it were your desire to put these “dongles” on a whole bunch of your customers’ cars, where is the “win” for your customer? One could argue that you could diagnose their car when it breaks, but it seems that for this “you sell an OBD port dongle” model to work, there needs to be some other daily-use-type features that are compelling to vehicle owners. If I had that nailed down, it is a safe bet I would be off selling it right now. I am certainly not saying that these devices do not have value or a place in the diagnostic routine, but what I have seen is that many devices promise things that are not realistic. Which leads me back to the question, “Why remote diagnostics?”
I think we can all agree that diagnostic work is quite possibly the highest cost service we offer, which mystifies me when I see a shop giving it away so that they can replace a part that takes 0.3 labor hours and often has a margin of 30% or less if you go with the MSRP.
Therefore, if you have someone in the future who calls and says, “My check engine light is on,” are you going to grab one of your technicians, take them away from their work, have them log in to a car remotely (when that becomes possible), and ask them to provide a diagnosis when you don’t even know if this caller will turn into a customer? My guess is probably not.
So, what could we do with this technology when it becomes mainstream? We might be able to have a customer push us a vehicle health report with DTCs that would help us know how to allocate our precious diagnostic resources. It looks highly likely that as these systems mature, we will be able to receive some predictive data that allows us to anticipate a failure, such as worn-out brakes or bald tires before they result in a breakdown. We can already use some of the products out there to advise a customer if his/her light is a 911 or 411.
The things that are coming down the road are very exciting (and sometimes scary), but I think if you take the time to read between the lines, you can determine if you are ready to bring these new technologies into your business.
