During a recent consultation about an ECU reprogramming issue with an erstwhile competitor, this writer was privy to a conversation between a young technician and a service writer/advisor at the competitor’s premises. The conversation involved a late model Ford Ranger with an illuminated MIL lamp and some minor power loss issues. The service writer wanted the technician to fit the job into his schedule for the day, but the technician demurred because the workshop did not have a Ford-specific scan tool. The conversation went round in circles for a while until the vehicle’s owner intervened by thanking everybody involved for their time, but since the workshop seemed to have neither the time nor the equipment to help him, he’d take his vehicle to a dealership instead.
We’ll gloss over the details of who said what to whom when the owner of the workshop was made aware of the situation, but suffice to say that the conversation highlighted a common misconception among many young technicians- a misconception that states that factory scan tools are always better at diagnosing “MIL” aka, “CHECK ENGINE” issues than generic scan tools. In this article, we will take a closer look at this misconception, and attempt to illustrate that generic scan tools are often just as effective in diagnosing “MIL” issues as factory scan tools are. Let us start with stating-
If you are an experienced diagnostician, you will no doubt know that many diagnostic, programming and calibration jobs on many new vehicles can only be performed with factory scan tools. However, if you are new to OBD II diagnostics, you may not be aware that this is because many control, monitoring, and/or calibration thresholds for systems like ADAS (Advanced Driver Assist Systems) and others are based on proprietary algorithms and look-up tables that car manufacturers are not obliged to share with manufacturers of generic scan tools.
These types of technical/service information are commonly referred to as “captive technology” or “captive information” and in some markets, such as Australia (among others), this information is shared with neither the independent repair industry nor with manufacturers of scan tools that have a presence in these markets.
Moreover, while some types or classes of OEM captive service information can be obtained via expensive subscriptions to third-party sources, many cheap generic scan tools are limited in the number of communication protocols they support. In practice, this often means that even if you are prepared to pay for OEM service information/programming, the generic scan tool you have may a) not be able to accept the download, and/or b), be incompatible with one or more communications protocols in use on the vehicle.
The above encapsulates the main differences between the capabilities of factory scan tools and generic scan tools, but in this article, we are not dealing with proprietary service information. We are dealing with ordinary OBD II codes that illuminate "MIL" lamps, which only happens when OBD II codes that have the potential to affect exhaust emissions are set and stored, which brings us to-
NOTE: While what follows might appear to be a digression from the main topic of this article, it is necessary to understand the background against which generic scan tools must be judged. This is also important because except for slight differences to accommodate localised environmental factors, most regulatory bodies in automotive markets in North America, South America, the EU, Asia, Japan, Australia, and New Zealand have adopted SAE Standard J2012 verbatim. Note though that the Chinese market follows different and sometimes-unfathomable rules, which largely explains why so many cheap Chinese-made scan tools only seem to work on Chinese-made vehicles.
The history and development of SAE Standard J2012 and its many amendments/improvements is a long and convoluted one, and limited space precludes a comprehensive discussion of it here. However, there is a short version available, and it simply states that the primary reasons why OBD and later, OBD II systems were implemented were a) to reduce exhaust emissions in the US domestic market, and b), to standardise the test and monitoring systems that car manufacturer were legally obliged to install on vehicles to reduce said exhaust emissions.
Leaving aside the limitations of OBD systems aside for the moment, the overarching purpose of OBD II systems is to monitor all aspects of fuel and engine management systems on all vehicles. Monitoring happens either continuously, or at regular intervals not only to ensure continued compliance with emissions regulations, but also to record all faults, failures, malfunctions, and/or defects in engine/fuel management systems that have the potential to increase exhaust emissions, which is the primary driver behind “MIL lamp illuminations.
Therefore, to ensure consistency in monitoring and fault reporting protocols, the SAE (Society of Automotive Engineers) in the USA developed a codified alphanumeric system that assigns specific trouble codes (aka DTC's) to specific faults, failures, malfunctions, and/or defects in engine/fuel management systems that have the potential to increase exhaust emissions. The principal expression of this standardisation effort was early iterations of Standard J2012, which has now been expanded to include several thousand so-called “generic” codes, which largely describe faults, failures, malfunctions, and/or defects in engine/fuel management systems on all vehicles made and sold by all manufacturers in the US domestic market. SAE Standard J2012 expresses this legal obligation thus in article 5.2-
"....ISO/SAK Controlled Codes (Core DTCs) — ISO/SAE controlled diagnostic trouble codes are those codes where industry uniformity has been achieved. These codes were felt to be common enough across most manufacturers' applications that a common number and fault message could be assigned. All unspecified numbers in each grouping have been reserved for future growth. Although service procedures may differ widely amongst manufacturers, the fault being indicated is common enough to be assigned a particular fault code. Codes in this area are not to be used by manufacturers until they have been approved by ISO/SAR. ..." [Emphasis added]
Source: https://archive.org/stream/gov.law.sae.j2012.2002/sae.j2012.2002_djvu.txt
There is more to know, however. For instance, manufacturers of generic scan tools who wish to sell their products in the North American market are legally obligated to ensure that their products can communicate with all control modules in all vehicles that are made and sold in this market. This requires that scan tools can both read and transmit data over communication protocols that include, but are not limited to, CAN, Flex CAN, UART, Keyword 2000, MOST, BEAN, LIN, LAN, CCD, UDS, Byteflight, Flexray, and PCI, among others, which brings us to-
The image aboveshows a smart-phone posing as a code reader. These kinds of devices typically operate on rudimentary programs that have a limited ability to extract some fault codes from a vehicle's fault memory, and while some apps can display limited amounts of live data, the data a phone-based code reader can display is typically not sufficient to make definitive diagnoses. We are all familiar with these devices, and while they might be of some use to some home users, they have no value as diagnostic tools in professional environments, and therefore, we need not spend any more time discussing them.
Nonetheless, there is a second class of code readers, and at first sight, these might be attractive options to young mechanics on tight budgets. These devices typically resemble proper scan tools, but appearances can be deceiving and despite their impressive “technical specifications”, their absurdly modest prices are always an indication of low quality and severely limited capabilities. These devices abound on many online portals, and since we are familiar with them also, we will not discuss them further.
Proper mid-, to high-level generic scan tools, on the other hand, are or should be able to communicate in all the currently used communication protocols, as well as having at least some graphing capabilities. Other desirable properties include-
There are some other desirable qualities worth mentioning, such as 24/7 technical support, but due to space limitations, we cannot mention or describe them all here. However, and as a practical matter, what does all of this mean for a technician that has to diagnose a flashing “MIL” lamp on a late model vehicle with a generic scan tool that he thinks may or may not be up to the task? Let us look at this question in some detail, starting with stating that if a reasonably competent technician cannot diagnose a flashing “MIL” lamp with a generic scan tool with the capabilities described above-
We can state with a fair degree of confidence that all experienced technicians will agree that an efficient diagnostic process consists of series of steps that follow each other in a logical order and that extracting faults codes from a vehicle comes very early on in that process, as opposed to extracting fault codes constituting almost the entire process. However, this writer has (over many years) observed many mechanics and even senior technicians diagnosing issues by extracting fault codes, and then following up either by randomly checking/testing circuits, or sometimes, simply by throwing parts at the problem until something “sticks”.
This writer has also observed many technicians make the mistake of seeing the OBD II systems on vehicles as diagnostic systems, when OBD II systems are actually emission control systems that can detect and report faults and defects in the engine, fuel, and transmission control and management systems that have the potential to increase emissions to unacceptable levels. From a diagnostic perspective, this is an important distinction because it allows manufacturers of generic scan tools to leverage the high level of standardisation of OBD II faults called for by SAE Standard J2012. So this being the case, how do so many technicians get simple diagnostic processes wrong?
It's simple. Since OBD II standards are constantly evolving, OBD II systems are also constantly developing and changing to accommodate changes in emissions regulations. However, since many engine, fuel, and transmission management/control functions occur in different parts of the overall OBD II system, some data sets within the OBD II system are transmitted over different communications networks within the OBD II system. This requires that a high-end generic scan tool be able to access all the communications networks within an OBD II system to extract all the available information about a particular emissions-related fault code.
As a practical matter, the various parts of OBD II systems are separated into a minimum of ten “layers” or groupings, each of which contains specific information, or are capable of performing specific functions when commanded to by a scan tool with bi-directional controls. These “layers” or groupings are called “diagnostic modes”, and it is only by accessing and/or interrogating all relevant modes that it is possible to extract sufficient diagnostic information from an OBD II system to formulate a targeted diagnostic strategy. To illustrate this point, we will list and briefly describe the ten legally required diagnostic modes* below, but note that the “$” symbol merely indicates a hexadecimal value that is used in communications between computers-
*Note that while all high-end generic scan tools can access all ten diagnostic modes, access to these modes differ between scan tools. On some tools, they can be accessed through various drop-down menus, while on other tools access is though expanded menus displayed on various screens.
Mode $01
This mode requests current and live power train diagnostic data. In practice, this mode extracts or relays live data from sensors, actuators, and other components in real-time, and therefore, this data does not include desired or expected values.
Mode $02
This mode requests freeze frame data, which in a practical sense, is all the data (typically, operating conditions) that obtained when a particular emissions-related fault code was set and stored. Note though that in some cases, SAE Standard J2012 allows for the inclusion of some manufacturer-specific data into freeze frame data, such as, for instance, the freeze frame and failure records stored by GM products, which typically exceed the minimum requirements of freeze frame data as defined by various standards besides SAE Standard J2012
Mode $03
This mode allows scan tools access to fault codes that are stored in emissions-related control modules. Thus, failure to initiate Mode $03 with some generic scan tools could a) produce a “No Faults Found” message, or a failure to extract active fault codes stored in one or more emissions related control modules.
Mode $04
This mode allows a scan tool not only to clear emissions-related fault codes but also to clear/erase associated freeze frame data from implicated control modules. Note that this mode also allows a scan tool user to erase all stored test data, to reset all monitors, and to extinguish an illuminated "MIL" lamp.
Mode $05
This mode allows direct access to all oxygen sensor test/monitoring data stored in the engine control module. Note though that while this information can also be obtained via Mode $06, Mode $05 can typically not access this information on vehicles using CAN (Controller Area Network) communications systems. Therefore, this information must be accessed using Mode $06 on CAN equipped vehicles.
Mode $06
This mode allows access to test results of components/systems that are monitored continuously, such as misfire detection, and non-continuously, such as EVAP system operation. However, it should be noted that test methods and/or monitoring standards vary widely between manufacturers and even between models within a specific model range. Therefore, Mode $06 information must be compared to relevant service information if the scan tool in use cannot “translate” this data into a usable or understandable format.
Mode $07
This mode allows access to stored trouble codes that had occurred during either the current or the previous drive cycle. More specifically though, Mode $07 allows access to "pending" codes, which are typically codes that set immediately after resetting an engine control module.
Mode $08
This mode allows the bi-directional controls of a scan tool to actuate or test some emissions-related components and/or systems. This function is typically used either to seal off or to pressurise EVAP systems to test the integrity of EVAP systems.
Mode $09
This mode allows access to the vehicle’s VIN number, as well as to the calibration numbers and/or information of all emissions related control modules on the vehicle. This information is particularly important in situations where one or more control modules must be replaced.
Mode $0A
This mode specifically allows access to “permanent” codes, which are codes that remain stored in some control modules even though these codes may have been cleared using Mode $04. As a practical matter, these types of codes can only be cleared by affected control modules after the completion of a specified number of start and/or drive cycles without the original fault, defect, failure, or malfunction that had set these codes being present.
While the above descriptions of the basic functionalities a proper generic scan tool should have are necessarily brief, these brief descriptions should nevertheless make it abundantly clear even to novice scan tool users that using all or most diagnostic modes is required when formulating a diagnostic strategy, which leaves us with this-
While the need to use diagnostic modes might appear to be an intimidating prospect, the truth is that not using these modes leaves you almost blind, diagnostically speaking. Moreover, while you may need a factory scan tool to reprogram some control modules, or to perform some kinds of calibrations and relearning procedures on non-OBD II systems, OBD II control module failures are relatively rare. In practice, this means that in at least 85% of emissions-related issues, a mid-, to high-end generic scan tool can and will give you the same information that a factory scan tool will.
Also, given the above, we hope that this article has inspired you to explore and test the functionalities of your generic scan tool- functionalities you might not have known your scan tool possesses in the first place. After all, the level of service you provide to both your customers and your employer is as much as a function of your theoretical knowledge, as it is a function of your skill in leveraging the abilities and functionalities of the diagnostic tools you have at your disposal.
