When this writer was recently invited to consult on a stubborn random misfire problem on an imported (French-made) vehicle at a local independent workshop, he spent a fair amount of time listening to a fiery debate on the pros and cons of generic scan tool data vs. enhanced OEM scan tool data going on in an adjacent bay.
The debate swung back and forth between the two competing schools of thought for more than an hour, but it became clear to this writer early on that both sides were missing the point, which was that both generic and enhanced scan tool data have advantages and disadvantages. We can skip over the details of who said what to whom during this debate, but the gist of the pro-generic school’s argument was that most vehicles can still be diagnosed with existing aftermarket scan tools, while the pro-OEM school held that new vehicles could only be diagnosed with OEM-level scan tools.
Both arguments had merits, but both arguments were also somewhat one-sided and incomplete. For example, the pro-generic data school forgot to mention that not all aftermarket scan tools can diagnose all faults on all “older” vehicles, while the pro-OEM data school could not quite define what constituted a “new vehicle”. Was it a two-year-old vehicle, a three-year-old vehicle, or perhaps a 2021 model? As this writer recalls, this point was never resolved.
Of course, few arguments are ever complete, but where do you stand on the issue of generic vs.OEM scan tool data? Your answer will almost certainly depend on your perspective; if you work exclusively in dealerships, you likely don't ever use generic aftermarket scan tools. On the other hand, if you only work in independent workshops or are a mobile mechanic, you may be under the impression that the impending implementation of the Mandatory Data Sharing Law will compel you to invest in hugely expensive OEM-level software to be able to work at all.
To be sure, there are some things that only OEM-level scan tools and software can do, and you may have to invest in at least some OEM software at some point. For instance, things like ADAS calibrations are high-level procedures that require OEM-level tools, but then again, not many independent workshops do these procedures because they simply do not have the required floor space available.
However, the bulk of our work in independent workshops revolves around diagnosing common problems- things like misfires, no-start conditions, fuel trim issues, excessive fuel consumption, and the like. We have all seen these issues a thousand times before, and they are not going to disappear from new models although these kinds of issues will likely begin to have new causes that are rooted in advanced emission control technologies and/or novel combustion control strategies.
At this point, you may well ask what the point, of all, or any of the above is. There is a point, and it is this; despite the imminent implementation of the Mandatory Data Sharing Law, we will still be able to diagnose many common issues on most existing and new vehicles with our existing diagnostic equipment. Put differently, we won’t necessarily have to buy hugely expensive OEM-level software suites to do much of the diagnostics we do now. However, there is a caveat to this proposition, and it involves the rapid and increasing introduction of-
This is a rather complex topic, so in the interest of brevity, we can quote the most pertinent aspects of this development from this source-
“ In 2018, Fiat Chrysler Automobiles (FCA) installed a firewall in their vehicles, known as the Secure Gateway (SGW). FCA covers Alfa Romeo, Fiat, Chrysler, Jeep, Dodge, and RAM branded vehicles.
Other manufacturers will soon be following suit, as an EU standard valid from 2020 now obliges manufacturers to protect their electronic systems from unauthorised access and tampering.
FCA’s SGW module prevents non-FCA authorised scan tools from communicating with vehicle systems, other than to read fault codes. To ensure your scan tool can navigate around this Firewall, your tool needs to be registered with FCA.
FCA says it has set up a "bridge server" and user management system called AutoAuth that mimics the user and tool authentication process that FCA certified dealerships use with the FCA scan tool. This solution allows the aftermarket scan tools with WiFi to unlock the SGW and perform all the necessary repair procedures.
FCA says all aftermarket scan tool companies that currently have an active scan tool license agreement with FCA have been contacted so they can be provided with this capability.
It explains that once the SGW is unlocked through the authentication process, the aftermarket scan tool has the same capabilities as it did on non-SGW equipped FCA vehicles. The registration is done one time and there is a yearly subscription required. The number of vehicles you can service is unlimited.
To ensure access for your individual scan tool, contact your scan tool provider and ask them for the procedure for their scan tool to allow access to FCA vehicles with the SGW. Automotive Repairers Council of Australia Convener, Mike Smith, reports that Bosch has already built a token into its annual subscription and Snap-on also has new software to link to a subscription site”. (Source: https://www.aftermarket.com.au/overcoming-the-fca-firewall/)
As matters stand now, it appears that 100% of new (2021) vehicles under the FCA umbrella are fitted with gateway modules that make it difficult, if not always impossible to perform even simple diagnostics on these vehicles unless we register our generic scan tools with AutoAuth. Moreover, a quick online search revealed that Ford, Nissan, and other manufacturers that include Honda and some other Asian manufacturers are in the process of also securing their products with gateway modules.
So here is the problem; assuming that a) we all register our scan tools to get around gateway modules, and b) that the Mandatory Data Sharing Law is operative, we will have access to diagnostic information on new vehicles that we will see for the first time. Moreover, it is also likely that FCA-enabled scan tools will display some information differently from how we have become accustomed to seeing it.
One example of this is the way fuel trim data is currently displayed on VAG-group specific scan tools. Instead of displaying fuel trims as a simple percentage as most generic scan tools do, VAG-group specific software displays this data in data blocks in a way that is somewhat reminiscent of a jigsaw puzzle or a Rubik’s cube.
In fact, during a recent series of user tests this writer had performed on a wide range of new-generation generic scan tools, it became clear that more and more scan tools display diagnostic information in different ways. In fact, in a few cases, this writer was forced to contact some tool manufacturers directly not only to get clarification on what some features in some displays meant, but also on how to interpret some display screens.
There are too many examples of these instances to list them all here, but the point is that some new scan tools display information in overly complicated ways- especially with regard to diagnostic flow charts. While having flow charts displayed on a screen is nice, it is less so when one has to navigate between five or six screens to follow a flow chart to its conclusion, which forced this writer to think about ways to-
Reducing, condensing, and extrapolating diagnostic information does not mean some information could be discarded, ignored, or guessed at. Far from it: it means that since car manufacturers and scan tool programmers are not obliged to display enhanced (OEM-specific) diagnostic information in any particular way, it is pointless to attempt to remember how each manufacturer chooses to display its proprietary information.
Also, it helps to remember that regardless of whether (or not) any given vehicle is fitted with a secure gateway module, the SAE J1962 standard obliges all car manufacturers to wire the DLC (Data Link Connector) in ways that are fixed in law. For instance, depending on the communication protocol in use on any given vehicle, all DLC’s in all vehicles using that protocol must be wired in the same way. This means that certain terminals in the DLC must be used for specified purposes, and this wiring scheme is based on things like-
Moreover, according to the current OBD II rules, SAE standard SAE J1979 also compels manufacturers of both cars and scan tools to make all emissions related diagnostic information (and associated PID’s) available on all scan tools. This means that a car manufacturer cannot hide some information, such as, for instance, fuel trim readings, on the enhanced side of a scan tool by claiming that this information is somehow proprietary.
NOTE: This is where the caveat we mentioned earlier appears again. The problem seems to be that while most car manufacturers do make it possible to access emissions-related diagnostic information available (on vehicles with gateway modules) with generic scan tools that are not registered under AutoAuth rules, they make it impossible to erase emissions-related fault codes unless the tool is registered and enabled.
So, by registering a generic scan tool, it is possible to do (almost) everything we were able to do with that tool before the advent of secure gateway modules, because we do not, at least as far as emissions-related diagnostics go, have to consider enhanced OEM-specific data, which brings us to the problem of-
One of the main drawbacks to OEM-specific scan tools data is the fact that even generic data is often (if not always) displayed in wildly different ways. For instance, some OEM-scan tools display PIDs relating to wide-band air/fuel ratio sensors on a voltage scale, while others display the same information using sensor voltage or amperage. Moreover, some manufacturers (Toyota) using the voltage scale will display “stoichiometry” at 3.3 volts, while another (Subaru) will display a value of 1.52 volts as an indication of an ideal air/fuel ratio. From this single example, it should be clear that it is just not feasible to remember what is “normal” for all manufacturers.
By way of contrast, the OBD II rules mandate manufacturers of generic scan tools to display some PIDs, such as those relating to air/fuel ratio sensors, in the same way. More to the point, these kinds of PID's cannot be displayed with substituted values. All data has to be displayed "as is", which means that instead of trying to remember what is “normal” for each manufacturer, we can concentrate on remembering how PID’s that apply to most makes and models are displayed.
We can use the example of the air/fuel ratio sensor data again. Instead of trying to figure out if enhanced data that shows a 3.3-volt value is the same as a 1.52-volt value under similar conditions (but on two different vehicles), we can return to the generic data and use a LAMBDA value instead.
“LAMBDA” is derived from a simple mathematical calculation, in which the stoichiometric ratio of any fuel is divided into the actual, measured air/fuel ratio. This calculation yields a value that is a true reflection of the actual air/fuel ratio under all operating conditions- regardless of the vehicle or fuel used.
In the case of petrol/air mixtures, a stoichiometric ratio would be 14.7 parts of air to 1 part of fuel, and in this ratio, all the air is used to combust all of the fuel. Therefore, a LAMDA value of "1" would indicate that the engine is running with an air/fuel mixture that is stoichiometric. However, this is rarely the case, so a LAMBDA value might be expressed on a scan tool as, for instance, LAMBDA 0.9, which is a rich mixture, or as LAMDA 1.1, which is a lean mixture.
These are merely examples, but the point is that LAMDA values are orange-to-orange comparisons instead of apple-to-orange comparisons of the same data that are expressed differently on different vehicles. Moreover, orange-to-orange comparisons are particularly helpful on V-type engines where an air/fuel metering issue affects only one bank of cylinders.
These engines typically have two catalytic converters, each of which has its own sensors to monitor its operation. Therefore, instead of using enhanced data that may not immediately make sense, using a scan tool that expresses the data from both upstream sensors as LAMDA values will immediately reveal both the affected bank of cylinders and the magnitude of the deviation from stoichiometric for the affected bank of cylinders.
The severity/effect of this kind of fault usually changes under some operating conditions, and performing a proper test drive will almost certainly reveal a trend of these changes. Thus, referencing both the upstream and downstream exhaust sensors on the affected bank to see if both record the lean condition to the same degree, holds valuable diagnostic clues. For instance, if both sensors indicate the lean condition, the sensors are unlikely to be the root cause of the fuelling problem.
If this is taken together with the fact that the problem occurs only on one bank, you can also automatically exclude the “injector pulse width equation”; i.e., incorrect MAF, MAP, ECT, TPS, BARO inputs as the cause of the problem.
In this example, we have condensed lots of data into a kernel of useful diagnostic information. Instead of testing/scoping every possible cause of the fuelling problem on one bank of cylinders, we allowed the basic data to tell a story that has a logical conclusion. However, the problem is how to always recognise the story, but here is-
Bear in mind that computers, including diagnostic computers and control modules, are not smart devices: "smart" in the sense that they can deduce the cause of a problem. However, computers are extremely efficient at crunching numbers, and in the case of automotive diagnostics, the numbers are large volumes of inputs from myriad sensors.
Computers are programmed to interpret inputs in specific ways to produce predictable outputs. Therefore, when a computer processes inputs from sensors, the outputs we see displayed on a scan tool are not the result of some control modules' "thinking" processes. What we see are the results of complex processes that compared inputs to pre-programmed limits, thresholds, and parameters that represent ideal conditions.
For instance, if we consider excessive fuel trims in either direction to be one symptom of many possible problems, as opposed to it being the problem, we can construct a storyline to suit the situation. For instance, to get the complete picture (or all the details that go into the story), we need the story to include all the required elements. In this case, the required elements would be-
In this example, the PCM will receive all inputs, process them, and then compare the processed outputs to pre-programmed “ideal” outputs. However, since a PCM has the ability, albeit a limited ability, to take some corrective action, it might command adjustments to the injector pulse width to address, for instance, an overly lean air/fuel mixture.
However, this storyline has a twist, because, in our example V-type engine, only one bank is affected by a lean condition, which rules out corrective injector pulse width adjustments. Ergo, the storyline in this example leaves us with an air or vacuum leak on the affected bank of cylinders as the most likely cause of the lean condition on the affected cylinder bank, which begs this question-
Sadly, they are not. However, over his long career, this writer has found that it is possible to diagnose most drivability issues without much trouble by using the generic PID's that are the most common to all vehicles simply because current OBD II rules oblige all manufacturers to make these PID's accessible to all scan tools. These PIDs typically include the following-
Harking back to our point that any PCM expects to see certain inputs, further points must be made that a) the inputs outlined above are common to all vehicles and b) that all these PID's can be found on all decent generic scan tools.
However, constructing a viable diagnostic storyline depends on remembering that no single output can, or must be viewed in isolation. Nonetheless, if we understand the purpose of each input, and how it can affect more than one output, it often becomes possible to exclude some causes of some abnormal outputs automatically, as we did on our hypothetical V-type engine above, which leaves us with this-
At the risk of overstating the case, all automotive diagnostics is founded on the input/output principle, in the sense that all inputs must produce outputs. Therefore, in practice, automotive diagnostics is less about finding out what is wrong with a vehicle and more about working out which inputs are not producing the desired outputs.
As a practical matter, however, some input/output equations are only accessible with OEM-level tools and software, but as far as drivability issues go, we largely don't need OEM-level tools and software. Since all the story elements we need are available on our generic scan tools, we can diagnose most drivability issues even on brand new vehicles if we use the story elements intelligently.
Of course, there is the little matter of registering our trusty generic scan tools to get around secure gateway modules, but as far as this writer is concerned, that is a story for another time.
