I remember one of the very first times I used a scan tool. It was on a 1982 GM vehicle equipped with the Computer Command Control system. At the time, these new layers of technology presented the dawn of a new era and interesting challenges. I began to imagine how this was going to change the way the technician would be addressing certain vehicle anomalies and what the future of automobile service was going to look like. Although the data stream was very cool, I had no idea as to how this information was being transmitted and displayed. I remember trying to connect the same tool to another manufacturer and discovering that this operation required different adapters and software cartridges. Once I connected, I was disappointed to find that the live data stream found on the GM vehicle was not available on another domestic OEM. My disappointment, however, was primarily my own fault for not having the proper service training on that vehicle system. At that point in time, I realized that I needed to acquire and consume as much training as I possibly could, and to this day, that hasn’t stopped. Reflecting on this I can honestly say that we have come a long, long way.
Service Technicians
Service technicians need to have a good foundational knowledge base around how a particular scan tool works and what the limitations are. For example, some tools may be very quick to connect to a vehicle and access the specific data the technician is laser-focused on. However, that specific tool may not be good at performing other functions, such as running a full vehicle scan or health check and producing a comprehensive report. Some tools are excellent at logging every action performed on the vehicle, which can be used to document how much time went into the analysis on the vehicle, in addition to providing module part numbers and software version levels. (Figure 1.)
The different tools on the market all have their strengths and weaknesses, and technicians need to be aware of each tool’s capabilities in order to get to the bottom of a problem. Some tools can only read generic OBD-II standardized information, which might be fine, however, there could be more generic data the tool can't display. The same goes for tools possessing the ability to display OEM proprietary data: Some are more capable than others and your mileage may vary (more on that later).
Controller Area Network (CAN)
Beginning with 2008 models, the CAN protocol was mandated for all passenger vehicles and light trucks sold in the United States. This standard was implemented to help unify data communications between the various modules or nodes populating the vehicle. At the time, most vehicles only had a handful of modules sharing data across this network. Back then, many of the legacy scan tools were unable to communicate with the new CAN standard unless hardware and software changes were implemented. Today, however, vehicles coming off the assembly line possess dozens of modules which may not all be on the same network or communicating using the same protocols. (Figure 3) In order for communication between them to take place, specialized modules are equipped with the hardware and software that allow them to act as a gateway device. These gateway devices are often tasked with translating data communicating on one protocol and servicing it up on another. This is where the service technician’s knowledge of the various network topologies provides an advantage during troubleshooting events (Figure 2).
Also, due to the Right to Repair legislation passed in Massachusetts several years ago, vehicles built since 2018 are more accessible than ever. All a service technician needs are a compliant J2534 interface, such as those offered by Drew Technologies (now Opus IVS), and a computer meeting the specifications outlined by the OEM. Armed with those items they will be able to purchase a subscription to access the vehicle using OEM software. Additionally, many of the operations such as reprogramming and advanced driver assistance systems (ADAS) calibrations are readily available as well. Furthermore, access to secure areas of the vehicle may require additional credentials, such as a Vehicle Security Professional (VSP) license issued through the National Automotive Service Task Force (NASTF).
Evolution of OBD-II
Since its introduction back in 1996, the OBD-II standard has evolved. Some of the features we typically rely on, including Mode$06, Mode$09 and Mode$0A, were not always around or implemented in the same way. Take Mode$06, for example. This mode is useful for examining how the onboard monitoring system is grading performance of the various onboard diagnostic routines, but it has its limitations. This information can only be fully leveraged if the technician is equipped to master using it.
Security
Even prior to the implementation of CAN, the ranking of security was not remarkably high for many OEMs. Today, we are witnessing huge movements by many of the OEMs focused on adding layers of protection barriers to these networked systems, which is understandably necessary. Given the federal mandate driving OBD-II, access to the generic operations cannot be blocked by these security measures. For the rest of the vehicle, however, we are starting to see more driver assistance systems that can support semi-automated driving support operations with the eventual goal of moving the vehicle to a fully autonomous Level-5, according to the SAE J-3016 standard. The hardening of these systems is extremely important. Today, most of us have probably witnessed the decision by FCA (now Stellantis) to include a secure gateway on 2018+ MY vehicles. One of the primary drivers of this stemmed from the work of two “white-hat” hackers by the name of Chris Valasek and Charlie Miller. (For more information on this, refer to my column in the May 2021 issue.)
FCA worked with the folks behind AutoAuth to enable a trust factor solution. According to their website, “AutoAuth provides a service for independent operators to unlock vehicles to securely provide service to their customers. New vehicles will come enabled with the latest cyber security features to protect vehicle owners from cyber-attack. AutoAuth works with independent tool vendors to ensure the tools independent operators use to do their jobs are AutoAuth certified tools. This will allow independent operators to continue to service cyber enabled vehicles. AutoAuth provides the registration service and ‘unlock codes’ to Independent Operator’s service tools to unlock vehicle gateways to perform day to day service.”
Software
While the generic OBD-II standard mandates access to emission related information and operations, each OEM can implement additional layers of data tooling that they deem necessary for supporting their service operations. Most of these OEMs offer scan tool manufacturers the opportunity to license access to these layers so that they can be implemented accurately within their tools. However, some may choose to go the route of reverse engineering during the development of their tools. Service personnel must be aware that the OEM does not always produce error-free applications. In fact, I have personally witnessed events where the OEM tool failed to accomplish a task where an aftermarket tool had to be used to realize success. And of course, the inverse has been experienced as well. As vehicles become more and more software defined, unfortunately, these errors are to be expected.
Data
Given the number of nodes on the vehicle and the vast amounts of data available, the diagnostic technician’s knowledge and skill set must be at the highest levels. The modern technician must be able to interpret service information and engineering data when addressing vehicle faults (Figure 3).Additionally, having some computer science knowledge can be highly beneficial. Some OEMs have incorporated service information right within their diagnostic scan tools through guided fault-finding operations. Some aftermarket tools are also offering similar operations as well (Figure 4). Nevertheless, technicians can benefit tremendously by staying tuned in to emerging trends and best practices through networking opportunities via communities, such as the Diagnostic Network.
In general terms, one diagnostic scan tool is likely not going to be enough unless you are only working on one vehicle carline. All tools have their strengths and weaknesses, and one must be able to recognize them in order to succeed. With the emergence of PC-based applications, multiple scan tool applications installed on a single machine may not be ideal and for some, may be impossible. With the growing focus on security at all levels, safe computing assessments should be implemented. An auxiliary vehicle power supply should be available and used especially when performing any programming/software updates.
The modern automobile is one of the most complicated devices most humans will ever interact with, and as the vehicle evolves into a software defined machine, the skill set demands of the technician will continue to evolve. In my opinion, next generation technicians possessing these unique skillsets will be in high demand well into the future.
