CAN Bus Architecture in Fleet Vehicles: What Telematics Devices Actually See

Your telematics device is not reading your truck. It's reading a carefully rationed excerpt of what your truck knows about itself.

That distinction carries real operational weight. A Class 8 tractor running a Cummins X15 or PACCAR MX-13 may have four to six discrete communication networks operating simultaneously, each carrying data at different baud rates, managed by different controllers, and governed by different access policies. Your aftermarket telematics hardware — regardless of brand — connects to one gateway point and receives whatever the OEM decided to broadcast there. Everything else stays internal.

Fleet managers who treat telematics data as a complete picture of vehicle health are making maintenance and replacement decisions against an incomplete dataset. The implications range from missed prognostic signals to incorrect fault attribution to budgeting errors that compound across a multi-unit fleet.

How the Network Is Actually Structured

Modern heavy-duty commercial vehicles are not built on a single CAN bus. They run a layered network topology that typically includes:

• J1939 (250 kbps) — the primary powertrain backbone, carrying engine, transmission, and brake system data using SAE's standardized PGN/SPN framework
• J1587/J1708 — legacy diagnostic bus still present on pre-2016 vehicles and some body systems on newer platforms
• Proprietary high-speed CAN networks — manufacturer-specific buses running at 500 kbps or 1 Mbps that carry transmission control module (TCM) internal calibration data, aftertreatment system closed-loop logic, and advanced driver assistance system (ADAS) processing
• LIN bus — low-speed (20 kbps) networks for body electronics: mirrors, HVAC controls, door modules
• Ethernet backbone (100BASE-T1 or 1000BASE-T1) — increasingly present on vehicles built after 2020 for camera systems, OTA update channels, and infotainment

The J1939 Diagnostic Connector (9-pin) is your telematics device's entry point. It sits at the intersection of these networks, acting as a gateway — but it only exposes what the OEM's gateway ECU decides to forward. Think of it as a controlled API, not a direct database connection.

What J1939 Actually Broadcasts

The J1939 standard defines Parameter Group Numbers (PGNs) that broadcast specific Suspect Parameter Numbers (SPNs) at defined intervals. These are the parameters your telematics platform can request or passively receive. Common examples:

• SPN 190 / FMI 0 — Engine Speed, overspeed condition
• SPN 91 — Accelerator Pedal Position (0–100%)
• SPN 110 — Engine Coolant Temperature
• SPN 3226 — Aftertreatment 1 Outlet NOx, critical for DEF system diagnostics
• SPN 1569 — Engine Protection Torque Derate, indicating the engine is actively reducing power to protect itself
• SPN 4334 — Diesel Particulate Filter (DPF) differential pressure

These are publicly specified and any compliant telematics device can read them. The problem is that this standardized broadcast layer represents roughly 30–40% of the total diagnostic information generated by a modern powertrain. The rest lives on proprietary segments.

What Stays on the Proprietary Network

OEMs protect competitive calibration data, emissions compliance logic, and warranty-relevant parameters by keeping them off the public J1939 broadcast. Specifically, what typically does not cross the gateway:

Aftertreatment internal loop data. The SCR system's closed-loop NOx conversion efficiency calculations, DEF quality estimation, and injector duty cycle compensation values are computed internally by the aftertreatment control module (ACM) and not exposed via standard PGNs. You'll see SPN 3226 (outlet NOx) and SPN 3216 (inlet NOx), but not the ACM's internal correction tables that indicate a catalyst is degrading before it fails an emissions test.

Transmission internal calibration shifts. Allison's proprietary CAN network carries shift energy, clutch pack wear indices, and adaptive calibration counters that Allison's own diagnostic software (Allison DOC) reads directly. The J1939 broadcast will show output shaft speed and transmission temperature, but not the adaptive shift data that predicts clutch pack failure 6,000–9,000 miles before a transmission fault code appears.

ADAS sensor fusion data. Mobileye-based systems on newer Kenworth, Peterbilt, and Freightliner platforms process camera and radar data on a dedicated Ethernet segment. Your telematics device may receive a FCWS (Forward Collision Warning System) event flag, but not the raw confidence scores or sensor health metrics that tell you whether the system is gradually degrading.

Injector trim data. On high-pressure common rail systems (PACCAR MX-13 runs at up to 2,500 bar injection pressure), individual injector balance rates — the correction values that compensate for injector wear — are stored on the ECM's internal memory and accessible only through proprietary dealer diagnostic tools. A telematics device will capture SPN 651–658 (injector control) faults when they cross the DTC threshold, but not the drift pattern that precedes the fault by weeks.

This is the core architectural reality: telematics devices are excellent at capturing what has already become a problem. They are structurally limited in their ability to detect what is becoming one.

The Gateway ECU as Gatekeeper

The gateway ECU — sometimes called the Vehicle Interface Module (VIM) or Data Gateway Module — is the physical point where proprietary and public networks intersect. On Freightliner Cascadias built after 2019, this is the Vehicle Electronic Control Unit (VECU) running Detroit's proprietary software stack. On Kenworth and Peterbilt platforms, PACCAR's telematics box (PTX) serves a similar function.

These gateway modules perform active filtering. They translate proprietary SPN equivalents into J1939-compliant PGNs for specific parameters — usually the ones required for regulatory compliance (emissions, ELD-adjacent data) — and drop everything else. OEMs can and do modify what gets broadcast via software updates, which means a fleet running the same truck model across two different production years may have different data availability from identical telematics hardware.

This also explains why OEM-native telematics platforms (Detroit Connect, PACCAR Connect, Volvo ASIST) consistently outperform aftermarket devices on fault code depth for their respective brands. They have direct ACcess to proprietary bus data that a Geotab GO9 or Samsara VG34 simply cannot reach by design. The tradeoff is obvious: OEM platforms lock you into their ecosystem and offer zero cross-fleet standardization when you're running mixed iron.

For a direct comparison of how aftermarket platforms handle the depth problem differently, the fault code depth analysis comparing Geotab and Samsara's diagnostic PID capture is worth reading before you commit to a platform contract.

A Concrete Case: The Invisible Catalyst Failure

A 47-unit refrigerated carrier in the Midwest ran a mixed fleet of 2020–2022 Freightliner Cascadias with DD15 engines. Their Samsara deployment was fully configured — active fault alerting, DTC parsing, idle reports.

Unit 2247, a 2021 Cascadia with 387,000 miles, began showing elevated SPN 3226 readings (outlet NOx) that stayed below the alert threshold their team had configured at 0.5 g/kWh. No active fault codes were logged. No driver complaints. The telematics dashboard showed the truck as healthy.

Eight weeks later, the truck failed a roadside DEF system inspection. The SCR catalyst's conversion efficiency had been declining for approximately 11 weeks based on ACM data retrieved post-failure by a Freightliner dealer using ServiceLink. The internal ACM logs showed DEF injector duty cycle compensation values climbing to 140% of nominal — the injector was working harder to compensate for reduced catalyst activity. None of that data had ever reached the telematics device.

The repair: SCR catalyst replacement plus DEF injector, approximately $3,800 in parts and labor plus two days of rental. Had the proprietary ACM data been accessible, the degradation trend was visible weeks before the failure threshold crossed.

The alert configuration wasn't the problem — the data simply wasn't there. For context on how threshold logic affects what you actually catch versus what slips through, the discussion on custom fault code alert thresholds and alert fatigue addresses exactly this tradeoff.

What You Can Do Within the Constraints

The architectural limits are real, but there are strategies that extract more signal from the data that is available.

Poll at higher frequency. The default J1939 broadcast interval for many SPNs is 1 second. Some parameters — engine oil pressure, coolant temp — benefit from 100ms polling if your hardware and platform support it. Higher-frequency data improves the statistical model for anomaly detection. The relationship between OBD-II PID polling rates and predictive model accuracy is directly applicable to J1939 configurations as well.

Monitor SPN pairs, not individual signals. SPN 3226 (outlet NOx) is less informative than the ratio of SPN 3216 (inlet NOx) to SPN 3226 over time. A widening gap between the two, even below fault thresholds, is a degradation signature. Telematics platforms that allow custom calculated channels can build this.

Use DM1/DM2 message parsing aggressively. Diagnostic Message 1 (active faults) and DM2 (previously active faults) are the richest publicly accessible fault channels on J1939. FMI codes paired with occurrence counts and timing give substantially more diagnostic context than just the SPN. An SPN 3226 / FMI 0 occurrence that appears briefly and clears is different from one with 47 occurrences over 10 days.

Establish OEM data access agreements. Some OEMs, including Daimler Trucks North America, offer fleet data APIs through programs like Detroit Connect Fleet Management. Access to proprietary telematics data through these channels — even if delayed or filtered — substantially expands what you're working with. The commercial terms vary and require negotiation, but for fleets running 50+ units of a single brand, it's worth the conversation.

The Data You're Actually Using for TCO Decisions

Here's the part that should concern every director of maintenance: most fleet TCO models, replacement triggers, and maintenance interval decisions are built on telematics data. If that data is structurally incomplete — and it is — then the decisions downstream are built on a partial foundation.

That doesn't mean the data is useless. It means the confidence interval on predictive maintenance conclusions should be wider than most platforms represent, and replacement trigger models should incorporate factors that telematics cannot see directly.

---

The Bottom Line

A commercial vehicle's CAN bus architecture is not a single accessible network — it's a layered system with deliberate partitions, and your telematics hardware connects at a gateway point that filters and limits what crosses over. The standardized J1939 broadcast gives you regulatory-relevant parameters, active fault codes, and basic performance data. It does not give you proprietary closed-loop calibration values, internal adaptive shift counters, or the ACM logic that predicts catalyst failure before any DTC fires. Building maintenance decisions, alert logic, or replacement models as if you have full vehicle visibility is the fundamental misuse of fleet telematics data — and it shows up as unexpected failures, mis-timed repairs, and warranty gaps that never get diagnosed correctly.

Routiq gives fleet maintenance teams exactly this kind of fault pattern visibility — cross-referencing SPN pairs, tracking DTC occurrence frequency, and surfacing degradation patterns before they become roadside events. Start a free trial and see what your current platform isn't showing you.