The failure mode with OBD-II in a mixed fleet is not that it stops working. It is that it appears to work. Some heavy-duty trucks expose limited data on the familiar 16-pin connector, so a dongle plugs in, readings appear on a dashboard, and everyone assumes the truck is covered. It is not. OBD-II defines roughly 100 standardised parameters, most of them emissions-related, while the heavy-duty standard defines more than 8,000 covering every major control unit on the vehicle — around eighty times the data. Engine torque, diesel exhaust fluid level, aftertreatment health, transmission slip and brake pressure exist only on that second bus. If your Class 8 tractors are reporting through an OBD-II adapter, the parameters most likely to predict an expensive failure are the ones you cannot see. Send us your vehicle list with weight ratings and we'll mark which protocol each unit actually needs — it takes one session and it is worth doing before any hardware order.
Integration · OBD-II & Heavy-Duty Diagnostics
OBD-II Telematics Integration for Fleet Diagnostics
Right protocol per vehicle class, both feeding one maintenance system — because a dongle that connects is not the same as a dongle that sees anything useful.
A Hundred Parameters Against Eight Thousand
The single comparison that should govern every hardware decision in a mixed fleet.
OBD-II
~100
standardised parameters, mostly emissions-related
Mandatory across US light-duty vehicles since 1996, on a standardised 16-pin connector under the dash. Fleets typically work with a subset of around 47 in practice. Genuinely capable for what it was designed to cover.
80×
J1939
8,000+
standardised parameters across every major control unit
The heavy-duty standard, on a 9-pin connector. Used not only for diagnostics but for real-time operational control between units — synchronising torque requests between engine and transmission, for instance. Manufacturers can add proprietary parameters on top.
Worth knowing why that gap exists rather than treating it as vendor positioning. Before the heavy-duty standard, each engine maker ran its own system — one manufacturer's diagnostics, another's, a third's — and a shop needed a different tool and cable for every brand. J1939 exists to unify that, which is why it covers so much more ground than an emissions-driven light-duty standard ever needed to.
What You Lose on a Heavy Truck
Not an abstraction. These are the specific parameters that live only on the heavy-duty bus, and they are the ones that predict expensive failures.
Aftertreatment healthThe single most expensive failure category on a modern diesel, and the one most amenable to early intervention. Invisible through a light-duty adapter.
Diesel exhaust fluid levelA derate event caused by fluid level is entirely preventable with visibility and entirely unpredictable without it. This alone justifies the protocol decision on most Class 8 fleets.
Engine torqueActual load on the driveline rather than inferred from speed — the basis for understanding whether a unit is working harder than its schedule assumes.
Transmission slip and statusDeveloping transmission problems announce themselves here long before they announce themselves on the road.
Brake pressureBoth a safety parameter and a maintenance one, and absent from the light-duty parameter set entirely.
PTO operationEssential for anything where the work happens stationary — tippers, mixers, utility bodies, refuse. Hours spent driving and hours spent working wear a vehicle differently.
Read that list against your own failure history. If your expensive unplanned events cluster around aftertreatment, fluid derates and transmissions, then a light-duty adapter on those units is monitoring the cheap failures and missing the costly ones — which is a worse position than having no data at all, because it feels covered.
The Dangerous Middle
Three situations, and the second is where fleets get caught.
Clear
Light-duty vehicle, OBD-II device
Under 14,000 lb gross weight, standardised port, full access to what the standard defines. Nothing to think about — this is the case the connector was built for.
Trap
Heavy truck, OBD-II adapter, data appearing
Adapters exist and they connect. Some heavy trucks expose limited data on the 16-pin connector too. But an adapter translates only a small subset of the available parameters — so the dashboard populates, nobody investigates, and the gap is discovered during a breakdown rather than during procurement.
Clear
Class 4 to 8, J1939 device on the 9-pin port
Published guidance is unambiguous: deploy the heavy-duty protocol directly on these vehicles. Hard-wired to the 9-pin connector, with access to the full parameter set rather than a translated fragment.
Fifteen-minute audit
List every unit
with its GVWR
Then check which connector its device is plugged into
Any heavy unit on a 16-pin port is a coverage question
It may be fine — some fleets deliberately accept limited data on certain assets. What matters is that it was a decision rather than an assumption. Send us the list and we will mark each vehicle with the protocol it should be on and what you are currently missing, so the next hardware order is specified correctly rather than uniformly.
Deciding Per Vehicle, Not Per Fleet
A single hardware choice across a mixed fleet is wrong in one direction or the other. Here is the split.
Swipe to see all columns
On the cost difference: heavy-duty installation adds somewhere around $50 to $200 because the device hard-wires rather than plugging in, with subscriptions commonly cited at $25 to $55 per vehicle per month. The gap between the two year-one figures is roughly the cost of one aftertreatment repair — which is the comparison worth making rather than treating it purely as a hardware line item.
The 2027 Transition Nobody Is Mentioning
If you are specifying OBD-II hardware this year, this belongs in the conversation.
What is changing
Vehicle diagnostics are moving from the legacy protocol to a newer framework built on Unified Diagnostic Services, commonly referred to as the OBDonUDS transition and dated to 2027.
What it requires
Telematics platforms will need to support the newer framework for full vehicle data access. A device or platform built only for the legacy protocol will progressively see less of newer vehicles as they enter your fleet.
What to do about it
Ask every prospective supplier a single question in writing: does this hardware and platform support the newer diagnostic framework, and from when. Hardware bought in 2026 on a multi-year subscription will still be in service when this matters.
This is a cheap question with an expensive answer if you skip it. A fleet replacing light-duty telematics hardware in 2026 is buying equipment that will be reading 2028 and 2029 vehicles — and a platform that has not planned for the transition will quietly lose visibility on exactly the newest, most warranty-relevant units.
The Codes Do Not Look the Same Either
A practical consequence for anyone running maintenance workflow across a mixed fleet.
Light-duty
P · C · B · U prefixes
Familiar four-character fault codes with a letter prefix by system group. Readable by a sub-$50 consumer tool on any compliant vehicle, which is part of why the format is so widely understood.
Heavy-duty
SPN / FMI pairs
A suspect parameter number identifying what, paired with a failure mode identifier describing how — FMI 5 meaning current below normal or an open circuit, for example. More precise, and completely different to interpret, route and report on.
Which matters operationally rather than academically. A maintenance system that only understands one format will mishandle the other — usually by storing heavy-duty faults as unparsed text that cannot be trended, grouped by severity or matched against previous occurrences. If you run both vehicle types, ask any platform how it handles both code structures before you ask about anything else.
Inside Fleet Rabbit: One Record, Either Protocol
The mixed-fleet problem stated as two columns and one shared spine.
From the light-duty side
Fault codes in the familiar prefix format, parsed rather than stored as text
Odometer read from the control unit, not estimated
Engine hours, speed, coolant temperature, fuel trim
Plug-in deployment, minutes per vehicle
From the heavy-duty side
Suspect parameter and failure mode pairs, interpreted and grouped by severity
Aftertreatment, fluid level and derate warnings
Transmission, brake and torque parameters
PTO hours separated from road hours for scheduling
Both arrive at the same place
One asset record per vehicle, whatever it is plugged into
Work orders raised from either code type, with history attached
Intervals on mileage, engine hours or PTO hours as the asset requires
Inspections, parts, labour and cost per asset across the whole fleet
A van and a tractor unit have nothing in common at the diagnostic layer and everything in common at the maintenance layer. That is the division worth designing around: let the protocol differ per vehicle and keep the record identical.
The practical benefit shows up in reporting rather than in the dashboard. Cost per asset, downtime and PM compliance become comparable across vehicle classes when both sides land on the same record — which is the thing a mixed-fleet manager usually cannot produce, because the light vehicles and the heavy vehicles live in different systems and get measured differently.
Specifying Hardware Without Regret
Five questions to put to any supplier, in this order.
1Which protocol does this device actually read, natively?Not which vehicles it will physically connect to. Reading a subset through an adapter and reading the bus natively are different products sold with similar language.
2On our heavy units, which specific parameters will we see?Ask for aftertreatment, fluid level, transmission and torque by name. A supplier who answers "full engine diagnostics" without naming those has not answered.
3Does the platform support the newer diagnostic framework, and from when?The 2027 transition question, asked in writing. Your hardware will outlive the change.
4How are heavy-duty fault codes stored and interpreted?Parsed into parameter and failure mode, or dumped as text? The answer determines whether you can trend faults or merely read them.
5What is the installed cost per vehicle, by class?Hard-wired heavy-duty fitting adds labour that plug-in deployment does not. A blended quote hides which units are actually expensive to cover.
Put one van and one tractor on it and compare what each reports
Free on three vehicles, no card, no time limit. Connect one light-duty unit and one heavy unit and look at what actually arrives from each — parameter coverage, code formats, how faults group, whether the heavy truck surfaces aftertreatment and fluid data or stops at the emissions basics. That comparison on your own vehicles settles the protocol question faster than any specification sheet will.
Frequently Asked Questions
Can an OBD-II device work on a heavy truck?
It can connect, and that is exactly the problem. Some heavy-duty trucks expose limited data on the 16-pin connector, and adapters exist for heavy-duty vehicles — but they translate only a small subset of the available parameters. The dashboard populates, so nobody investigates. Published guidance is that Class 4 to 8 fleets should deploy the heavy-duty protocol directly rather than adapting.
How much more data does the heavy-duty standard provide?
Roughly eighty times. OBD-II defines around 100 standardised parameters, most of them emissions-related, while J1939 defines over 8,000 covering every major control unit on the vehicle. It is also used for real-time operational control between units rather than diagnostics alone, and supports proprietary manufacturer extensions on top of the standard set.
What exactly can't we see through an adapter?
The parameters that predict expensive failures: engine torque, diesel exhaust fluid level, aftertreatment health, transmission slip and brake pressure, plus PTO operation. Those live on the heavy-duty bus and require the 9-pin connection. If your costly unplanned events cluster around aftertreatment and fluid derates, an adapter is monitoring the cheap failures and missing the expensive ones.
What does each option cost?
Reported year-one all-in figures run $206 to $595 per vehicle for light-duty OBD-II against $550 to $1,460 for heavy-duty, with installation adding roughly $50 to $200 on heavy units because the device hard-wires to the 9-pin port, and subscriptions commonly at $25 to $55 per vehicle per month. The gap between the two is approximately one aftertreatment repair, which is the more useful comparison.
What is the 2027 change we should know about?
Vehicle diagnostics are moving from the legacy protocol to a newer framework built on Unified Diagnostic Services, referred to as the OBDonUDS transition. Telematics platforms will need to support it for full vehicle data access. If you are specifying hardware now on a multi-year subscription, ask every supplier in writing whether their devices and platform support the newer framework and from when — the equipment you buy this year will be reading vehicles built after the change.
Do the fault codes differ between protocols?
Completely. Light-duty uses familiar four-character codes with P, C, B and U prefixes. Heavy-duty uses suspect parameter number and failure mode identifier pairs — one number saying what, another saying how, with FMI 5 meaning current below normal or an open circuit for instance. A maintenance platform that only parses one format will store the other as unstructured text you cannot trend or group by severity.
How do we run a mixed fleet without two systems?
Let the protocol differ per vehicle and keep the maintenance record identical. Light units on OBD-II, heavy units on J1939, both parsed properly and both landing on one asset record — so work orders, intervals, inspections and cost per asset are comparable across classes. That comparability is usually what a mixed-fleet manager cannot produce today. Connect one of each free and compare the output side by side.
Connecting Is Not Covering
A device that plugs in and shows readings has not told you whether it can see the things that break your heavy trucks. Specify per vehicle class rather than ordering uniformly, ask suppliers to name the specific parameters rather than accepting "full diagnostics", get the 2027 framework question answered in writing, and check that heavy-duty fault codes arrive parsed rather than as text. Then let both protocols land on one maintenance record, because the diagnostics differ per vehicle and the workshop does not.
