A modern vehicle’s buses already carry speed, RPM, fuel, faults and dozens of other signals. Fleet telematics is largely the problem of tapping that safely, decoding it correctly across makes, deciding on the device what counts as an event, and shipping only that — without disturbing the bus or opening a security hole.
| Aspect | OBD-II port | Direct CAN |
|---|---|---|
| Access | Standard diagnostic connector | Wire into the vehicle bus |
| Coverage | Standardised diagnostic PIDs | Full set of vehicle signals |
| Effort | Plug in, retrofit in minutes | Integration per vehicle type |
| Risk | Read-only, inherently safer | Must not interfere with the bus |
| Best fit | Light fleets and retrofit | Heavy vehicles and OEM builds |
| Decoding | Common PIDs, some gaps | Proprietary, needs a DBC per make |
The first rule of putting a device on a vehicle bus is that it reads and never writes. The bus carries messages that operate the vehicle, and a telematics unit that injects traffic — even by accident, even with good intent — is a safety problem. So the tap is read-only by design, and on a direct CAN connection it has to be electrically and logically incapable of disturbing the traffic it listens to.
The second problem is that the signals are not standard. OBD-II defines a set of diagnostic parameters, but the rich data — the signals a fleet actually wants — lives in manufacturer-specific messages that differ by make, model and year. Decoding them means maintaining a library of definitions (DBC files and proprietary parameter maps) and matching the right one to the vehicle, which is a maintenance commitment, not a one-time effort. Getting it wrong produces plausible-looking numbers that are quietly incorrect.
The third is that most of the value is created on the device, not in the cloud. The bus produces far more data than any fleet wants to pay to transmit, so the device applies the rules locally — harsh braking, excess idling, a geofence breach — and uplinks the resulting events with a trusted timestamp, not the raw frames. That also makes the device an attack surface: something with access to the vehicle bus and a network radio has to be isolated and hardened, because it sits at the boundary between the fleet’s network and the vehicle’s.
OBD-II is a standard port, read-only and quick to retrofit, which suits light fleets and aftermarket installs but exposes only standardised diagnostic parameters. Direct CAN reaches the full set of vehicle signals and suits heavy vehicles and OEM builds, but it is an integration per vehicle type and must be engineered so it cannot disturb the bus. Many fleets use OBD-II where it is enough and direct CAN where the extra signals justify the work.
Because the bus produces far more data than a fleet wants to transmit or pay for, and because the connection is intermittent. Detecting harsh braking, idling or a geofence breach on the device means the vehicle uplinks a handful of meaningful events with trusted timestamps rather than a continuous stream of raw frames, which is cheaper, works through coverage gaps, and is what the fleet actually acts on.
It can be, which is why it is engineered not to be. A device with access to the vehicle bus and a network radio sits on the boundary between two networks, so it is kept read-only toward the bus, isolated so it cannot inject traffic, and hardened against compromise from the network side. Treating it as an attack surface from the start is the difference between a data tap and a way in.
Written for engineers. Share it with one.
Tell us the specification, the constraint and the deadline. Programmes that cross silicon, radio, embedded and AI are where Faststream is strongest.