The OBD-II port was designed to check emissions, not to run a fleet. That distinction survives every product demo and every integration kickoff. The port is a diagnostic keyhole. The CAN bus is the vehicle’s nervous system. They are not the same thing, but telematics marketing frequently collapses the difference.
A light commercial vehicle exposes basic engine codes through the OBD-II port using a request-and-response mechanism. The telematics dongle asks for a parameter, the engine control unit answers. A heavy truck relies on a broadcast network like SAE J1939. Every electronic control unit throws its data onto the physical wire simultaneously. The engine broadcasts fuel rate, the transmission broadcasts gear position, the brake controller broadcasts pedal pressure. The device does not ask for this data; it listens to the bus and filters the noise.
Two trucks, same model year, same telematics device, same firmware. One reports brake pressure. The other does not. The difference is a parameter the second truck’s manufacturer chose not to broadcast. J1939 defines thousands of Suspect Parameter Numbers. Nothing obliges an OEM to broadcast all of them, or to broadcast them at a useful rate. Standardized vocabulary does not guarantee speech.
Fleet IT must choose between three paths to the vehicle, and none of them is the full vehicle.
The first path is an aftermarket device at the diagnostic port. Telematics vendors sell artificial intelligence, but they install Y-splitter cables and zip ties. A mechanic installing a third-party box in a new heavy truck often cannot use the diagnostic port because the maintenance crew needs it open when the truck is in the shop. They use a Y-splitter and zip-tie the wiring harness deep behind the dashboard. Even then, the device only reads what the OEM’s gateway ECU allows to pass through. The gateway filters the internal buses, a limitation documented in service bulletins rather than standard protocol definitions.
The second path is the manufacturer’s factory-installed telematics API. It spares the fleet a hardware installation and promises a clean cloud-to-cloud integration. An OEM API is a lens with someone else’s prescription. The manufacturer decides which parameters leave the vehicle, at what interval, and with what latency. An architecture review board might evaluate an OEM API that promises no aftermarket hardware is required, only to find the documentation shows a polling limit of once every fifteen minutes. If the logistics routing team requires location updates every thirty seconds to feed a warehouse dock scheduling system, the fleet has to install third-party hardware anyway just to get the required frequency.
The third path is an in-cab system connected to vehicle networks and other equipment. It combines vehicle data with driver input but adds installation and support work.
Once the data is moving, the physical reality of the fleet meets the economics of the cloud. A busy J1939 bus at 250 kbps can produce hundreds of megabytes per hour if a device captures every frame. The instinct in modern IT is to capture everything at full rate because storage is cheap, transmit it over cellular because the SIM is already there, and store it in object storage.
This data lake anti-pattern has a specific shape. A data engineering standup might isolate a sudden spike in cloud ingestion costs because a firmware update to the fleet’s telematics gateways accidentally changed the transmission frequency of accelerometer data from reporting only during harsh braking events to reporting continuously at 1Hz. Five thousand trucks spent the weekend streaming useless vibration data over cellular networks into a Kafka cluster. The monthly data cost exceeds the telematics subscription. The fix is a policy change, but the conversation about who approved it takes longer than the fix.
Sampling rate is a budget decision disguised as a technical one. Fuel rate at 10 Hz is not more accurate than fuel rate at 0.1 Hz for calculating monthly cost-per-mile. It is just more expensive to transmit, store, and defend in a procurement review. The architectural challenge is moving the filtering logic to the edge device in the cab. The in-cab device holds the data in local memory, calculates averages and maximums over a time window, and transmits a single compressed payload. High-frequency raw data is only transmitted if triggered by a defined threshold. Event-driven collection beats polling for most operational use cases. The event is the data. The continuous trace is the evidence, and you rarely need it at full rate.
Even when the collection strategy is sound, the semantic layer requires heavy lifting. A mixed fleet guarantees you will maintain distinct data pipelines that only meet at the billing stage. An integration team mapping odometer fields across three OEM APIs will find that OEM A reports total vehicle distance in kilometers as an integer, OEM B reports it in miles with one decimal, and OEM C reports engine hours and a separate trip distance with no lifetime odometer. The canonical schema meeting takes four sessions.
An architect comparing two dashboards—the OEM portal and the aftermarket telematics platform—might see both display engine load. The numbers differ by 12 percent on the same truck, same hour. One is derived from a J1939 parameter the OEM populates. The other is calculated from a different parameter the aftermarket vendor decodes. Neither is wrong. Neither definition is documented in the contract. You must record whether a field came from an ECU, a device sensor, a manufacturer calculation, or a join in your own platform.
This complexity compounds when the fleet is not brand new. Retrofit fleets are archaeological sites. A 2012 tractor, a 2018 tractor, and a 2023 tractor under the same telematics contract will expose different parameter sets. The integration team discovers this in month three, not during vendor selection. Manufacturers frequently change the proprietary hex codes for non-regulated diagnostic data when they release a new model year. The aftermarket vendor has to physically acquire the new vehicle and reverse-engineer the CAN bus chatter to map the new codes.
The vehicle itself is only half the physical reality. The trailer, the tractor, and the driver do not share a permanent identity. A refrigerated trailer arrives at a distribution center with a cargo-temperature excursion. The tractor’s engine data is complete and shows a normal trip. It says nothing conclusive about the trailer compartment. The reefer controller has its own serial or CAN network. Whether it bridges to the tractor’s J1939 network is a per-unit, per-vendor question. The relevant records sit with the reefer controller, temperature probes, and door events, each with its own clock and equipment identifier. The compliance report has a two-minute gap that nobody can explain to the auditor. The reefer is a separate system until proven otherwise.
Granular telemetry also crosses the line from vehicle health monitoring to driver surveillance, which changes the nature of the architecture. In fleets with works councils or union agreements, the question of which signals correlate to driver identity is negotiated, not configured. A European fleet’s works council might review a proposed driver scoring system that correlates GPS location with driver ID and harsh braking events. The council does not object to the data collection. It objects to the retention period and the disciplinary use. Privacy in a fleet is a labor question before it is a data question. If raw data hits the central corporate database before being scrubbed, the organization is usually already in breach of the agreement. Fleet architectures must account for pipelines that intentionally drop or anonymize data at the edge.
A telematics specification might ask for speed, fuel use, fault codes, and braking events. Four fields fit on one line of a procurement document. They do not come from one consistent interface. Start with the decision you need to make, then work backward to the signal. If the maintenance department has no process for handling predictive battery health alerts, paying a premium to extract and stream that specific proprietary CAN code is a waste of bandwidth. The useful answer is a smaller set of dependable signals with known coverage, rather than the largest feed the bus can provide.
Take it with you
Takeaways
- The difference between OBD-II request-response diagnostics and J1939 broadcast networks
- Why OEM telematics APIs and aftermarket devices each expose a different slice of vehicle data
- How sampling rates, edge filtering, and semantic mapping determine whether telematics data is useful or just expensive
Asked and answered
Questions
Why does the same telematics device report different data on two identical trucks?
J1939 defines thousands of Suspect Parameter Numbers, but OEMs are not obliged to broadcast all of them or at a useful rate. A parameter one manufacturer broadcasts may be absent on another truck of the same model year.
What is the data lake anti-pattern in fleet telematics?
Capturing every CAN frame at full rate and streaming it over cellular creates large cloud costs without operational value. A firmware change that shifts accelerometer reporting from event-driven to continuous can make monthly data costs exceed the telematics subscription.
Why does an OEM telematics API sometimes still require aftermarket hardware?
The OEM decides which parameters leave the vehicle, at what interval, and with what latency. If the API polls location only every fifteen minutes but the routing team needs updates every thirty seconds, third-party hardware becomes necessary to meet the frequency requirement.