KEY TAKEAWAYS
Understanding Diagnostic Trouble Codes (DTCs) code formats, severity levels, and status types helps fleet managers prioritize maintenance more effectively. Instead of treating every alert the same, fleets can differentiate between critical faults that require immediate action and lower-priority issues that can be scheduled. This structured approach reduces downtime and improves maintenance planning. Explore how interpreting DTC codes correctly helps fleets move from reactive fixes to more informed, data-driven decisions.
What if you could detect vehicle faults the moment they begin to develop, instead of finding out after a breakdown disrupts your operations?
Advances in vehicle diagnostics and fleet telematics have made it possible to capture fault signals directly from vehicles in real time. Platforms like Intangles build on this by translating raw diagnostic data into clear, actionable insights, helping fleets respond faster and plan maintenance more effectively.
If you’re a fleet manager, Diagnostic Trouble Codes (DTCs) are one of the most important signals your vehicles generate. These codes are triggered when sensors detect abnormal conditions, giving you a structured way to understand what is happening across engines, transmissions, emissions systems, and more.
Today, as fleets generate increasing volumes of real-time data, DTCs have become a core part of modern fleet management—improving visibility, reducing downtime, and enabling faster decision-making.
In this first part, we break down what DTC codes are, how they work, and how to interpret them correctly across different vehicle types.
What are DTC codes? And how do they work in Modern Fleets?
Few things disrupt fleet operations faster than an unexpected check engine light.
A driver receives an alert mid-route. The vehicle may need to slow down or stop. Operations teams adjust routes, reschedule deliveries, and manage delays. These situations increase operational cost and reduce fleet availability.
Telematics adoption continues to expand rapidly, with a growing percentage of vehicles generating real-time operational data streams across global fleets.
In most cases, the root issue started earlier. That dashboard alert is triggered by a Diagnostic Trouble Code (DTC). When a sensor detects a value outside its normal operating range, the vehicle’s onboard computer—the ECU (Electric Control Unit) or PCM (Powertrain Control Module)—logs a fault code and activates the Malfunction Indicator Lamp (MIL).
This is where modern fleet systems change the equation. With telematics in place, DTCs are transmitted in real time to your fleet management platform. Instead of waiting for a vehicle to return to the depot, fleet managers can detect faults as they occur and take action before they escalate.
Two diagnostic standards every fleet uses
Fleet vehicles report DTCs using two primary standards:
OBD-II for light and medium-duty vehicles
- Standards across vehicles since 1996
- Universal 16-pin connector
- 5-character fault code format (e.g., P0301)
- Works across all manufacturers
This standardization is what enables scalable telematics across mixed fleets.
SAR J1939 for heavy-duty vehicles
- Used in trucks, buses, and heavy equipment
- Runs on CAN bus networks
- Uses SPM (what failed), FMI (how it failed), OC (how often)
Heavy-duty systems generate more detailed data, but require translation before they become operationally useful.
A single vehicle can generate multiple DTC events in a month. Without real-time visibility, many of these remain unaddressed until scheduled maintenance—by which point the issue may have already escalated.
Understanding OBD systems in fleet vehicles
Before you can act on DTC data, you need to know which diagnostic system your vehicles are running. Not all fleet vehicles use the same diagnostic standard. The system generating your fault codes determines the format, the tools required to read them, and the level of detail available for diagnosis.
OBD-I: The starting point
OBD-I was the first generation of onboard diagnostics, introduced in the 1980s. It could detect basic faults, but there was no standardisation across manufacturers. Each OEM used its own codes, connectors, and communication protocols.
For fleets operating multiple vehicle brands, this created operational complexity. Different scan tools were required for different vehicles, making it difficult to manage diagnostics at scale. While it marked an important step forward, OBD-I was not practical for modern fleet operations.
OBD-II: Standardised diagnostics for light-duty vehicles
OBD-II addressed the lack of standardization. Mandated in the United States from 1996 for all light and medium-duty vehicles, it introduced a universal 16-pin connector, standard communication protocols, and a consistent five-character fault code format across manufacturers.
This means a vehicle from Ford, Toyota, or Mercedes follows the same diagnostic structure. That consistency enables fleet-wide visibility through a single telematics system. For light-duty fleets, OBD-II makes it possible to monitor vehicle health using one device type, one data format, and one unified dashboard.
SAE J1939: Diagnostics for heavy-duty fleets
SAE J1939 is designed for heavy-duty trucks, buses, and industrial equipment. It operates over a Controller Area Network (CAN) bus and reports faults using three key parameters. These include SPN, which identifies the component or parameter at fault, FMI, which defines how the failure occurred, and OC, which tracks how often the fault has been triggered.
Heavy-duty ECUs monitor a large number of parameters simultaneously, and J1939 is built to support that level of complexity. Unlike OBD-II, these codes are not immediately intuitive in their raw form. To act on them efficiently, fleets need either detailed reference tables or a system that translates them into clear, actionable insights.
| Feature | OBD-I | OBD-II | SAE J1939 |
| Introduced | 1980s | 1996 (mandated US) | Late 1990s |
| Code format | Proprietary/variable | 5 character (e.g. P0301) | SPN + FMI + OC |
| Vehicle type | Light-duty (older) | Light & medium-duty | Heavy-duty (26,001+ lbs) |
| Connector | Manufacturer-specific | Universal 16-pin DLC | 9-6 pin CAN bus port |
| Code standardisation | None — proprietary | Full SAE/ISO standard | SAE J1939 standard |
| Telematics suitability | Limited | High — fleet-ready | High — with translation layer |
How to decode DTC codes for faster fault diagnosis
Identifying that a DTC is present is only the first step. The ability to read and interpret the code correctly is what enables faster and more effective decision-making. OBD-II and J1939 follow defined structures that make fault codes consistent and interpretable across vehicles.
OBD-II: The five-character format
OBD-II codes follow a standard five-character format across all light and medium-duty vehicles. Once you understand this structure, it becomes easier to interpret unfamiliar codes without relying on external references.
Each character in the code represents specific information, including the system affected, whether the code is standard or manufacturer-specific, the subsystem involved, and the exact fault. For example, a code like P0301 can be broken down step by step to identify the issue precisely.
| Position | Character | What It Represents | Possible Vales |
| 1st | Letter | System identifier | P = Powertrain (Engine, transmission, fuel) B = Body (Airbags, climate, seats) C = Chassis (ABS, steering, suspension) U = Network/ CAN bus/ module communication |
| 2nd | 0 or 1 | Code origin | 0 = SAE/generic standard code 1 = Manufacturer-specific code |
| 3rd | 1 to 9 | Subsystem | 1 = Fuel & air metering 2 = Fuel injector circuit 3 = Ignition/ misfire 4 = Auxiliary emissions controls 5 = Vehicle speed & idle control 6 = Computer output circuit 7-9 = Transmission |
| 4th – 5th | 00 – 99 | Fault index — the specific fault within that subsystem | “01” in P0301 = Cylinder 1. Two digits that pinpoint the exact failure point |
This standardised format allows fleet managers to quickly understand faults across different vehicle makes using a single diagnostic framework.
J1939: SPN, FMI, and OC
Heavy-duty vehicles use a different diagnostic structure based on the J1939 standard. Instead of a single code, faults are represented using three parameters that together define the issue. Here is what each component means:
| Component | Full Name | What It Tells You | Example |
| SPN | Suspect Parameter Number | Which parameter or component is at fault. SAE defines thousands of SPNs covering every monitored system on a heavy-duty vehicle. | SPN 190 = Engine RPM |
| FMI | Failure Mode Identifier | How the parameter failed. 0-31 possible values. FMI 0 = Above normal range. FMI 1 = Below normal. FMI 4 = Voltage too low. | FMI 0 = RPM reading above normal operating range |
| OC | Occurrence Count | How many times has this fault been triggered since the last clear. A rising OC on the same fault means it is getting worse, not better. | OC 3 = Fault has triggered 3 times |
These parameters provide more detailed insight into vehicle performance, but they are not immediately intuitive in their raw form. To interpret them efficiently, fleets typically rely on reference tables or systems that translate the data into clear, actionable information.
Common DTC codes every fleet manager should know
While fleets encounter a wide range of DTCs over time, certain codes appear more frequently than others. These are the faults most likely to impact operations, affect compliance, and increase repair costs if not addressed in time. It is not necessary to memorise every code, but recognising common ones and understanding their urgency helps fleet managers respond faster and make better maintenance decisions.
Most common OBD-II codes for light and medium-duty fleet vehicles
These commonly occurring OBD-II codes account for a significant share of fault events in mixed light and medium-duty fleets. Each code is associated with a severity level, which indicates how quickly action is required. This helps prioritize repairs, and reduces the risk of minor issues developing into larger failures.
| DTC Code | Description | Common Cause | Severity |
| P0171 | System too lean (Bank 1) | Vacuum leak, failing MAF or O2 sensor, clogged fuel injector | Moderate |
| P0300 | Random / multiple cylinder misfire | Worn spark plugs, faulty ignition coils, low fuel pressure | High |
| P0301 – P0312 | Cylinder N misfire detected | Specific cylinder ignition or fuel delivery failure | High |
| P0420 | Catalyst system efficiency below threshold (Bank 1) | Failing catalytic converter, O2 sensor, oil burning | Moderate |
| P0401 | EGR flow insufficient detected | Clogged EGR value or passages, faulty DPFE sensor | Moderate |
| P0128 | Coolant temp below thermostat regulating temperature | Failing thermostat (stuck open) | Moderate |
| P0442 | EVAP system small leak detected | Loose or damaged fuel cap, cracked EVAP hose | Low |
| P0455 | EVAP system large leak detected | Missing fuel cap, failed purge valve, cracked lines | Moderate |
| P0505 | Idle control system malfunction | Dirty or failed idle air control valve, vacuum leak | Moderate |
| P0700 | Transmission control system malfunction | TCM fault — refer to secondary transmission codes | High |
| P0562 | System voltage low | Weak battery, failing alternator, corroded terminals | High |
| P0087 | Fuel rail/system pressure too low | Failing fuel pump, clogged filter leaking injector | High |
| P0113 | Intake air temperature sensor circuit high | Failed IAT sensor, broken wiring harness | Low |
| P0325 | Knock sensor 1 circuit malfunction | Failed knock sensor, wiring issue, engine detonation | Moderate |
| B1000/U0100 | ECU malfunction/ lost comm. With ECM/PCM | Module failure, CAN bus fault, wiring fault | High |
Common J1939 codes for heavy-duty trucks
In heavy-duty fleets, certain SPN and FMI combinations appear more frequently in telematics dashboards. While many platforms translate these codes into plain language, understanding the underlying structure helps fleet teams validate the diagnosis and communicate more effectively with technicians and workshop teams.
| SPN | Patameter | Common FMIs | What It Means | Urgency |
| SPN 110 | Engine coolant temperature | FMI 0 = Above normal | Engine overheating — immediate attention required | Critical |
| SPN 190 | Engine speed | FMI 0/ FMI 1 | RPM over/under limit — possible governor or sensor fault | High |
| SPN 100 | Engine oil pressure | FMI 1 = Below normal | Low oil pressure — risk of engine seizure | Critical |
| SPN 3031 | DPF differential pressure | FMI 0 = Above normal | DPF approaching blockage — forced regen required | Moderate |
| SPN 4334 | Aftertreatment SCR system | FMI 2 / FMI 14 | DEF quality or dosing fault — emissions non-compliance risk | High |
| SPN 91 | Accelerator pedal position | FMI 3 / FMI 4 | Throttle sensor circuit fault — vehicle may derate | High |
| SPN 84 | Wheel-based vehicle speed | FMI 2 / FMI 8 | VSS signal error — affects ABS, cruise control, tachograph | Moderate |
| SPN 1569 | Engine protection torque derate | FMI 31 | Engine actively reducing power to prevent damage | Critical |
| SPN 3719 | DPF soot load percent | FMI 0 | DPF soot above threshold — regen required soon | Moderate |
| SPN 5246 | NOx sensor downstream of SCR | FMI 0 / FMI 4 | Emissions failure — potential regulatory non-compliance | High |
For a complete and searchable list of DTCs, refer to a comprehensive DTC code reference database. For vehicle-specific fault descriptions, tools such as DTC Decode allow you to search by vehicle make, model, and code to access OEM-level information.
Critical vs non-critical codes: how to prioritize fault alerts
A check engine alert does not always indicate a critical issue. In some cases, the vehicle can continue operating safely. In others, immediate action is required to prevent serious damage. The challenge is that both situations often appear identical at the driver level.
Without a clear prioritization framework, fleets either delay action on critical faults or respond too aggressively to minor ones. Both scenarios impact operations, either through avoidable breakdowns or unnecessary vehicle downtime.
DTCs already contain built-in severity signals. The key is applying a consistent framework to interpret and act on them.
A practical severity framework for fleet operations
Level 1: critical
These faults require immediate action. The vehicle should be stopped as soon as it is safe to do so, and recovery or technical assistance should be arranged.
Typical examples include:
- Engine overheating
- Low engine oil pressure
- Engine protection derate activation
- Transmission failure affecting drivability
- Brake system faults with active warnings
These conditions carry a high risk of severe damage or safety issues if the vehicle continues to operate.
Level 2: moderate
The faults do not require immediate stoppage but should not be ignored. The vehicle can complete the current trip or shift, but a workshop visit should be scheduled within a defined timeframe, typically within 48 to 72 hours.
Common examples include:
- DPF nearing blockage
- EGR system faults
- Fuel trim imbalances
- Catalyst efficiency issues
- Charging system irregularities
Addressing these issues early helps prevent escalation into critical failures.
Level 3: advisory
Advisory-level faults have minimal immediate impact on vehicle performance. These can be logged, monitored, and resolved during the next scheduled maintenance cycle.
Typically cases include:
- Minor EVAP leaks
- Non-critical sensor faults
- Ambient or intake air temperature issues
- Body or network-related codes
- Historical or non-active fault codes
While these do not require urgent action, tracking them helps maintain long-term vehicle health.
Understanding DTC status: active, pending, and permanent
In addition to severity, every DTC carries a status that indicates where it sits in the fault lifecycle. Misinterpreting this status is a common reason for repeated faults and inefficient maintenance decisions.
Active codes
Active codes indicate that the fault is currently present and has been confirmed by the ECU across multiple drive cycles. These typically trigger a dashboard warning.
These codes should not be cleared without proper diagnosis and repair. Clearing them prematurely removes valuable diagnostic context without resolving the issue.
Pending codes
Pending codes represent early detection. The system has identified an anomaly, but it has not yet been confirmed as a persistent fault.
Some pending codes may resolve on their own. Others may escalate into active faults if the underlying issue persists. Monitoring these closely, especially in high-usage vehicles, helps identify developing problems early.
Permanent codes
Permanent codes indicate that a fault has been confirmed and cannot be cleared manually using a scan tool. The system will only remove these codes after verifying that the issue has been resolved through a successful drive cycle.
This mechanism ensures that faults are genuinely fixed rather than cleared without repair.
Looking beyond individual faults
DTC should not be evaluated in isolation. Patterns across vehicles often provide more meaningful insights than individual fault events.
If the same active fault appears across multiple vehicles of the same type, it may indicate a broader issue. This could be related to component quality, recent software updates, or operating conditions such as fuel quality at a specific location.
In such cases, the focus should shift from individual vehicles to fleet-level investigation.
Why permanent code patterns matter
An increase in permanent DTCs across the fleet is a strong signal that underlying issues are not being fully resolved. These codes cannot be cleared through standard methods and require confirmed repairs followed by a successful drive cycle.
Tracking these patterns helps identify gaps in maintenance processes and ensures that recurring issues are addressed at the root level rather than reportedly managed at the surface.
Why DTC data matters for fleet operations
A DTC does not mark the beginning of a problem. It indicates that a threshold has already been crossed.
Fleets that respond only when codes appear operate in a reactive model. In contrast, fleets that track patterns, frequency, and escalation trends use DTC data to anticipate failures before they disrupt operations.
This shift has a measurable impact. It helps reduce unplanned downtime, avoid emergency repairs, and minimize operational disruptions. At the same time, it improves fleet availability, strengthens maintenance planning, and brings greater control over costs.
Understanding DTC codes is the starting point. The real value comes from how consistently and effectively that data is used to prioritize faults, identify risk early, and guide maintenance decisions across the fleet.
At a practical level, this is where the difference begins to show. Instead of reacting to isolated alerts, fleet teams start seeing patterns across vehicles, routes, and usage conditions. Fleet maintenance becomes more predictable, and fewer vehicles are taken off the road unexpectedly.
The global fleet management market continues to expand, driven by increasing adoption of AI, IoT, and predictive analytics in fleet operations.
Intangles is built on this foundation by connecting DTC data with vehicle telemetry, usage patterns, and historical trends. This allows fleets to move beyond individual fault alerts and start managing overall vehicle health in a more structured and proactive way.
If you are looking to move beyond basic fault alerts and start using DTC data to improve fleet reliability and maintenance planning, continue to Part 02, where we break down how preventive and predictive maintenance strategies work in practice and how to apply them across your fleet.
You can also explore Intangles’ fleet health solutions or speak to our team.
KNOW MORE
Frequently Asked Questions
What is a DTC code in fleet vehicles?
A Diagnostic Trouble Code (DTC) is generated when a vehicle sensor detects a value outside its normal operating range. The onboard computer logs this code and may trigger a dashboard warning. Each code points to a specific system and fault, helping identify issues quickly.
What is the difference between OBD-II and J1939 DTC codes?
OBD-II is used in light and medium-duty vehicles and follows a standard five-character format. J1939 is used in heavy-duty vehicles and reports faults using SPN, FMI, and occurrence count. Both serve the same purpose but differ in structure and level of detail.
Do all DTC codes require immediate action?
No. DTCs vary in severity. Some indicate critical issues that require the vehicle to stop immediately, while others can be monitored and addressed during scheduled maintenance. Prioritisation based on severity is essential to avoid unnecessary downtime.
How can fleet managers prioritize DTC alerts effectively?
A structured severity framework helps. Critical faults require immediate action, moderate faults can be scheduled within a short timeframe, and advisory codes can be monitored. This approach ensures that resources are focused on issues that impact operations the most.
Can DTC codes indicate patterns across the fleet?
Yes. When the same fault appears across multiple vehicles, it often points to a broader issue such as component quality, operating conditions, or maintenance gaps. Identifying these patterns helps address root causes at the fleet level.
Why is it important to understand DTC code structure?
Understanding how codes are structured allows fleet managers to interpret faults without relying entirely on external tools. This speeds up diagnosis, improves communication with technicians, and supports faster decision-making.
We’re looking forward to meeting you