Diagnostic Trouble Codes (DTCs) are not Root Cause Codes
- Tyler Betthauser
- May 17
- 5 min read
Auto repair is bifurcating into two different camps when it comes to the quality of a shop. There are what we call in the industry 'parts swappers' and technicians. Parts Swappers tend to be shops that will use replacement of parts as a form of diagnostics. If the issue goes away, then the root cause was that part. However, a technician that appreciates diagnosis will see the diagnostic or a malfunction indicator lamp (MIL) as a symptom that needs to be investigated further before replacing a part. Certainly, there are patterns which develop over time The arrival of vehicles that are 'software defined' makes diagnosis an even more important skill in our trade. That is why problem solving strategies are focused on so heavily at The Car Conservatory. Quality repairs are an output of replacing the right part at the right time. Choosing a shop that prioritizes a proper diagnosis is important for saving money and maintaining a reliable vehicle.
In a modern vehicle, DTCs are one of the first clues presented when a vehicle rolls into the shop. Typically, a MIL light is what prompts a customer to come into the service bay--although not always. Regardless of the presence of a MIL, a technician has as part of their process a step to plug in a scan tool to retrieve data about the DTCs being thrown. What is a DTC? A DTC is the output of an algorithm that a figure of merit has exceeded a threshold or some behavior has occurred which indicates a failure to operate within some specification. These are not necessarily an indication of root cause. While a DTC for an ignition coil indicates that pre-detonation might have occurred (usually causing a knocking sound in the engine), it does not mean that it was the coil. It could mean that the coil is bad, but it could also mean that oil has fouled the plug or coil. And, even if you do find a fouled plug or coil, there needs to be an investigation into why there is oil outside of the cylinder head.

If DTCs do not indicate a root cause and point to a part that needs replacement, what exactly are they? DTCs can either be treated as clues or imply a specific failure with a given part. Meaning, the algorithm can be narrow in its interpretation or it can simply be a warning that some operating parameter fell out of a threshold that needs to be investigated elsewhere. For example, B101D is categorized as an 'internal' failure to the module--usually some corrupted data. Typically, these parts are not recoverable in service and the module needs to be replaced. However, a mass airflow (MAF) sensor that is reading too high or low of pressure might have nothing to do with the sensor itself. It is on the technician to understand why the MAF is displaying these errant value.
A DTC goes through a similar design process that other algorithms might go through in other parts of software engineering. In a perfect world, a document called the design-failure-effects-analysis (DFMEA) is drafted to start. DFMEAs contain the expected failures, how they are detected, and remediation. A design is evaluated to understand the potential issues which might occur according to its use by the customer. There are also onboard diagnostic (OBD) requirements defined by standards and government organizations that also have to be added as well. Once a DFMEA is complete, and OBD specifications defined, engineers can create the heuristics which define how a DTC is going to be detected in the vehicle system. Most times, engineers can get away with using boolean logic gates to detect failures. However, engineers might be required to use more sophisticated mathematical and temporal calculations to set the DTC (think, averages over ignition cycles). It is important to keep the logic as simple as possible! Most modules in the car are not replete with memory and storage to do complex calculations. Engineers are prioritizing down to the byte, memory block, and process.

Presentation of a DTC almost always is correlated with other symptoms. With cars it can be useful to document the sights, smells, noises, things that can be seen and touch. These clues aren't always helpful, but some kinds of problems can be detected without DTCs at all. Technicians need to be capable of using their senses effectively because DTCs can be erroneously set which causes diagnosticians to chase their tails. Not only are they sometimes set improperly, there are codes which make it into production that are not even supposed to be tripped at all. Validation can miss that a DTC is presenting that is only to be used for debugging during the development process. It's important to remember that just because the vehicle is showing a light or a diagnostic, that does not mean a catastrophic problem exists.
Once the DTC is set and a technician has some idea of the other symptoms, usually the next step is to consult the service manual and circuit diagrams. At least, hopefully. Bu, these diagrams and service information is done primarily once. Rarely are these diagrams or diagnostic procedures revisited once they are initially validated and approved. Computer aided engineering diagrams and an engineer who didn't design the part create the documents--the real world is not necessarily used to stress the heuristics of the diagnostic. Also, when they validate the DTCs and documents, they are simply re-creating the hypothetical environmental factors that trigger the DTC or condition in the first place. Vehicles are deterministic, but determinism becomes obfuscated when the rules (meaning the software) become complex and diffused across different modules and systems. So, technicians must be aware of frameworks for problem solving not necessarily just doing what they are told to do in the service manual. Understanding the design and physics is critical to determining a root cause effectively. You can use Shainin (RedX) Problem solving, strategy-based diagnostics, and many other frameworks to achieve consistent results.
At The Car Conservatory, a core value of ours is to prioritize quality wherever possible. Part of offering a quality product and experience is to ensure our team is always looking past individual symptoms--remaining focused on fixing an issue at its root. Design related issues preclude us from doing this in every case since sometimes designs lead to poor function. However, customers will notice that our writeups for each repair are meticulously documented with regards to the suspected root cause and the steps we took to reach that conclusion.
Stop guessing what Your Car is doing
Get a quote from us on your next repair to gain confidence it will be the right repair the first time


Comments