AI ELD
Mar 4, 2026
Fleet managers deal with fault codes regularly, but the response to them varies widely. Some teams pull a truck from service over a stored code that could have waited for a scheduled shop visit. Others keep a vehicle running through an active fault that ends in a roadside breakdown or an out-of-service order. Neither approach is grounded in what the code is actually communicating.
This article covers how truck fault codes work, what the most common ones mean in day-to-day fleet operations, how to separate urgent from non-urgent, and where the ELD fits into this process. It also covers what happens when a fault code touches hours-of-service compliance, which is where a mechanical issue can quickly become a regulatory one.
When a fault code appears on a truck, it means the vehicle's control system has detected a parameter operating outside its programmed limits. The code is generated by the Engine Control Module or by another control unit monitoring a specific system, such as the transmission or aftertreatment module.
These modules run continuous checks across sensors throughout the engine and emissions system: fuel pressure, temperatures, boost levels, DEF system performance, NOx sensor readings, and more. Each sensor has a defined operating range. Each check has logical rules built into the software. When a reading falls outside those limits, stays out of range for a defined duration, or fails to make sense in relation to other data, the ECM identifies a fault condition.
At that point the ECM assigns a standardized diagnostic trouble code, logs it in memory, records the operating conditions at the time of the fault, activates a warning light if the severity threshold requires one, and in serious cases triggers a protective response such as engine derate. In heavy-duty trucking the standard format is SPN/FMI under the J1939 protocol, where SPN identifies the parameter with the fault and FMI describes the type of failure condition.
The key point is that a fault code is not random. It is the truck's control system documenting that a specific, named parameter has moved outside normal operating conditions. That documentation is what makes structured fault code management possible.
Most fault codes that fleets encounter in day-to-day operations fall into a few predictable categories: aftertreatment system faults, sensor communication faults, and emissions-related issues. Brake and safety-system codes appear as well but tend to be less frequent and more immediately obvious to drivers through drivability symptoms.
Four codes appear with particular frequency across heavy-duty fleets.
SPN 3364 FMI 9 relates to the aftertreatment DEF dosing unit and typically indicates a communication issue between the DEF dosing module and the ECM. In practice, the engine is not receiving consistent data from the DEF system. Causes include wiring faults, a failing DEF pump, or module communication errors. If the code remains active without attention, it can progress to an emissions-related derate.
SPN 5246 FMI 0 is one of the most frequently seen codes in fleet operations. It indicates that the SCR system is not reducing NOx emissions to the expected level. Contributing causes include low-quality DEF fluid, a failing NOx sensor, dosing system faults, or prior codes that were not addressed. This code typically triggers progressive engine derates if the underlying issue goes unresolved.
SPN 157 FMI 18 indicates that fuel rail pressure is reading above the expected range. It may point to a sticking pressure regulator or a sensor fault. Drivers may not notice immediate drivability symptoms, but unresolved fuel rail pressure anomalies can affect engine performance over time and should not be deferred indefinitely.
SPN 102 FMI 18 relates to intake manifold pressure reading above normal, which generally points to turbocharger or boost system issues: a sticking turbo actuator, a sensor problem, or an airflow restriction. Depending on severity it may produce reduced power or fuel efficiency changes that the driver notices before the fleet manager sees the code.
The pattern across all four is consistent with what fleets experience broadly. Emissions and aftertreatment codes dominate because those systems are heavily monitored, tightly regulated, and sensitive to both maintenance gaps and DEF fluid quality. Many of these codes are not catastrophic failures on their own. But they escalate quickly when ignored.
The single most important distinction in fault code management is whether a code is active or inactive. An active code means the fault condition is present right now. An inactive or stored code means the condition occurred at some point in the past but is not currently detected.
Active codes should be prioritized, particularly when they affect safety, drivability, or emissions compliance. Stored codes indicate something worth investigating and scheduling for service, but they do not necessarily require removing the vehicle from operation immediately.
The malfunction indicator lamp behavior adds another layer of context. A flashing MIL signals a severe condition that requires immediate action. A solid MIL indicates a confirmed fault that should be addressed soon but is not necessarily a stop-now situation. If there is no active warning light and only a stored code, urgency is generally lower.
The third factor is operational impact. If the fault has produced an engine derate, a speed limitation, a shutdown countdown, or a condition that puts the vehicle in an active emissions inducement stage, the vehicle is approaching out-of-service territory and needs to be handled before continuing the route.
In short: active faults with warning lights, especially flashing ones, require immediate action. Faults that affect braking, steering, or safety systems require immediate action regardless of whether a light is present. Stored codes without drivability impact or MIL activation can generally be scheduled for the next maintenance interval.
Both an ELD and a dedicated diagnostic scan tool connect to the ECM, but they serve different purposes and access different data.
The ELD hardware connected to the truck's engine control module reads the data streams required for hours-of-service compliance and operational visibility: vehicle movement, ignition status, engine hours, odometer readings, and basic fault code indicators. This is enough to document compliance records accurately and to surface high-level fault signals in the fleet dashboard, but it is not designed to access the full depth of diagnostic data available from the ECM.
A dedicated diagnostic scan tool goes considerably further. It can retrieve detailed fault information including manufacturer-specific codes that are not part of the standard J1939 set, freeze-frame data showing operating conditions at the moment of fault, sensor readings across all monitored parameters, aftertreatment performance metrics, and regeneration status. It also enables advanced functions: forced regens, parameter resets, and specific system tests that require direct ECM communication.
The practical implication for fleet operations is that the ELD provides early visibility into fault conditions, and that visibility has operational value. A fault that appears in the fleet compliance dashboard can trigger the right conversation before a driver is three hours from the nearest shop. But the ELD is not a replacement for a diagnostic scan tool when the root cause of a fault needs to be confirmed and repaired. It is an earlier layer in the process, not the final one.
The response to a fault code should follow a structured sequence on both sides. Unstructured responses, where the driver keeps driving without reporting or the fleet manager sees an alert and takes no action, are where small issues turn into expensive ones.
On the driver side, the first step is acknowledging the alert and checking the dashboard for warning lights and any change in vehicle behavior. The driver should note whether the MIL is solid or flashing, whether there are signs of derate or performance change, and whether the vehicle feels safe to continue operating. That assessment should be reported to fleet management immediately per company policy, and if the severity indicators suggest it, the vehicle should stop.
One step that is often skipped: annotating the fault in the ELD where the system supports it. The driver logbook creates a timestamped record of the driving day. A fault annotation in that record connects the mechanical event to the compliance timeline, which matters if the fault later becomes part of an inspection or audit review.
On the fleet management side, the process runs in parallel. The fleet manager sees the fault code and vehicle status in the dashboard, assesses whether the code is active, evaluates severity and operational risk, and issues clear direction to the driver: continue to the destination, route to the nearest shop, or take the vehicle out of service. The instruction needs to be specific, not general. "Keep an eye on it" is not a structured response to an active SCR fault with a progressive derate pattern.
Most fault codes are mechanical in nature and do not directly involve hours-of-service compliance. Some, however, create compliance risk in ways fleet operators may not anticipate.
The most direct HOS-related risk comes from faults that disrupt the connection between the ELD and the ECM. Loss of ECM connectivity, power supply issues, or data integrity errors can prevent the ELD from recording drive time accurately. Incomplete or inaccurate logs discovered at a roadside inspection create compliance violations regardless of whether the driver's actual hours were within legal limits. Understanding how the ELD system for trucks handles ECM connectivity faults and what gets recorded when that connection is interrupted is worth reviewing with your ELD provider.
From an out-of-service standpoint, certain fault categories draw immediate attention during inspections. Brake system faults, particularly ABS or air brake system issues, are high-priority out-of-service criteria. Engine derate and shutdown-related faults signal that the vehicle's protective systems have intervened in ways that may make continued operation unsafe or non-compliant. Severe emissions system faults that have reached an active inducement stage may not legally or practically allow the vehicle to complete a route.
The emissions inducement progression is worth understanding specifically. SCR-related faults like SPN 5246 FMI 0 do not trigger an immediate out-of-service order on their own in most cases, but if prior faults in that same chain were ignored and the vehicle is now in an active inducement stage with derate engaged, the operational and compliance picture changes. Inspectors look at the active fault state and the MIL status, not just the code number.
Traditionally, when a fault code appears, someone has to look it up, work through OEM documentation, and then translate that into an operational decision. That process takes time and requires technical knowledge that fleet managers and dispatchers do not always have readily available, particularly with heavy-duty truck codes that can be manufacturer-specific and require context to interpret correctly.
AI-assisted fault code interpretation, as built into the AI ELD diagnostic assistant, changes that process from code lookup to decision support. The system does not simply display a code. It interprets it: translating the code into plain language, identifying which component or system is involved, outlining likely causes, and indicating the severity level including whether the code may lead to derate or out-of-service risk. That information is available without opening a service manual or waiting for a shop to weigh in.
For fleet operations, the practical value shows up in four places. Triage becomes faster because the dispatcher or fleet manager understands the situation without a delay. Communication between the driver, dispatcher, and maintenance team becomes more consistent because everyone is working from the same interpretation. Downtime caused by uncertainty, where a vehicle sits because no one is sure whether it is safe to drive, is reduced. And decision-making across the fleet becomes more consistent because the interpretation is not dependent on which manager happens to be on shift.
The limits of AI interpretation are worth being clear about. It does not replace a certified diagnostic scan tool or a qualified technician. It cannot run physical system tests, confirm root cause, or account for the specific maintenance history of that vehicle the way a full diagnostic process can. What it provides is guidance and context that helps the fleet get to the right next action faster, while the final mechanical confirmation stays with the proper diagnostic process.
As one way to frame it: AI shifts the question from "What does this code mean?" to "What should we do next?" Those are different questions, and getting to the second one faster has real operational value.
The most consistent mistake is treating every fault code the same way, either overreacting to minor stored codes or ignoring active and recurring faults because the truck is still running.
Fleets that overreact pull vehicles from service for non-critical stored codes that could have been scheduled for routine maintenance, adding unnecessary downtime and shop cost. Fleets that underreact keep vehicles on the road through active or repeating faults because there is no immediate breakdown, until the derate engages, the vehicle stops moving on a loaded run, or an inspector finds an active emissions fault and issues an out-of-service order.
The second common mistake is focusing on the code number without considering the context. Whether the code is active or stored, whether it is recurring across multiple days or appeared once, whether it is tied to a safety system or an emissions system, and what inducement stage the vehicle is in: these factors determine the operational response more than the code number alone.
The fleets that handle fault codes well do not just react to them. They triage. They have a defined process for assessing severity, communicating between driver and fleet, and deciding whether the response is immediate action, route-to-shop, or schedule-for-maintenance. That structured approach is what keeps small issues from becoming expensive downtime. If your current ELD system does not surface fault code information in a way that supports that kind of triage, the AI ELD support team can walk through what the diagnostic visibility looks like in practice.
For questions about how AI ELD handles fault code visibility and diagnostic interpretation across your fleet, feel free to contact us.
A truck fault code is a standardized diagnostic identifier generated by the engine control module or another vehicle control unit when a monitored parameter falls outside its programmed operating range. In heavy-duty trucks, the most common format is SPN/FMI under the J1939 protocol. The SPN identifies which parameter has a fault and the FMI describes the nature of the failure condition.
An active fault code means the fault condition is currently present and the ECM is detecting it in real time. An inactive or stored fault code means the condition occurred at some point in the past but is not currently detected. Active codes require a prioritized response. Stored codes should be reviewed and scheduled for service but do not always require removing the vehicle from operation immediately.
Yes, in certain cases. Fault codes related to brake systems, safety-critical systems, or emissions systems that have reached an active inducement stage can create out-of-service risk. Faults that disrupt ELD-to-ECM data connectivity can also produce incomplete log records that create HOS compliance violations during an inspection.
An ELD captures operational data required for compliance: vehicle movement, ignition status, engine hours, odometer readings, and basic fault code indicators. A dedicated diagnostic scan tool accesses significantly more: detailed fault data including manufacturer-specific codes, freeze-frame data, sensor readings, aftertreatment performance metrics, and the ability to run active diagnostic tests. The ELD provides earlier visibility into fault conditions. The scan tool provides the depth needed to confirm root cause and authorize repair.
Aftertreatment and emissions-related codes dominate in day-to-day fleet operations. Commonly seen codes include SPN 5246 FMI 0 (SCR system not reducing NOx emissions effectively), SPN 3364 FMI 9 (DEF dosing unit communication fault), SPN 157 FMI 18 (fuel rail pressure above expected range), and SPN 102 FMI 18 (intake manifold pressure above normal). These codes often do not represent immediate catastrophic failures, but they escalate if not addressed in a structured, prioritized way.