From CAN Bus to Cloud: A Practical Telematics Architecture

A telematics system that works has four moving parts and one honest constraint. The parts: a gateway on the machine reading the bus, edge software that turns raw frames into meaning, a transport that survives bad coverage, and a cloud that stores and serves the result. The constraint: the machine does not stop producing data when the network drops, so the gateway has to hold its own.

This guide follows the path a single signal takes, from a CAN frame on the drivetrain to a row in a cloud database, and names the decisions that actually matter at each hop. The hardware here is an embedded Linux gateway, because owning that layer is what lets you change any of these decisions later.

CAN is a broadcast bus. Every controller puts frames on the wire and every node sees them; nothing is addressed to you. A gateway taps in, usually in listen-only mode so it cannot disturb the vehicle network, and pulls frames at the bus rate, commonly 250 kbit/s or 500 kbit/s on heavy equipment.

Raw frames are not data yet. On a J1939 network (the standard over CAN for trucks and off-highway machines) a 29-bit identifier carries a PGN (Parameter Group Number), and inside the payload sit individual signals addressed by SPN (Suspect Parameter Number): engine speed, coolant temperature, fuel rate, hydraulic pressure. Decoding them means applying a scale and offset to specific bits, the mapping a DBC file describes. Where a machine speaks a proprietary CAN dialect instead, you reverse-engineer or license that mapping. The gateway filters hard at this stage: of the hundreds of PGNs on a busy bus, a telematics use case usually wants a few dozen.

Decoding gives you values. Edge processing decides which ones leave the machine, and how often. A 500 kbit/s bus can offer thousands of signal updates per second; shipping all of it over cellular is pointless and expensive. So the gateway samples and aggregates: engine RPM might go up as a one-second average, a fault code the instant it appears, GPS every few seconds, a door switch only on change.

This is also where data earns trust. Unit conversion, range checks that drop a physically impossible reading, and a deduplication pass so a signal that has not moved does not generate traffic. Two patterns split the bandwidth question. Polling samples on a fixed clock and is simple to reason about. Report-by-exception sends only when a value crosses a threshold or changes state, which on industrial signals cuts volume sharply. Most real deployments use both, by signal.

The link is the part you cannot assume. Cellular (LTE, increasingly 5G, with LTE-M or NB-IoT for low-rate sensors) covers most mobile assets; Wi-Fi or Ethernet suit depots and fixed installs; satellite is the fallback where nothing else reaches. None of them are continuous in the field, which is the whole design problem.

MQTT is the usual transport, and for good reason: it is lightweight, publish-subscribe, and its QoS levels map onto what telematics needs. QoS 0 for high-rate samples you can afford to lose, QoS 1 for events that must arrive at least once. The gateway buffers locally (a small on-disk queue) and forwards on reconnect, so a tunnel or a dead zone delays data instead of losing it. Every connection runs over TLS, ideally with a client certificate per device, so a compromised gateway can be revoked without touching the rest of the fleet.

On the far side, a broker or ingestion endpoint authenticates the device, accepts the stream, and writes it down. Time-series storage fits the shape of the data; the payload is usually compact JSON or a binary schema keyed to the same field definitions the gateway used, so a value means the same thing end to end.

From there the data feeds the things people actually wanted: live dashboards, utilization and maintenance KPIs, alerts, and an API into the customer's own systems. The detail that quietly decides whether any of this is trustworthy is timestamping. Stamp readings at the edge, when they happen, not on arrival, or buffered data replayed after an outage will land out of order and corrupt every average computed from it.

A demo on one machine on a bench is easy. A thousand machines in the field for ten years is the actual job, and a few decisions decide which one you have built. Run the edge on open embedded Linux you control, so a new PGN or a changed threshold is a firmware build on your schedule, not a vendor ticket. Make OTA updates safe from day one: signed images and an A/B partition scheme that rolls back automatically if a boot fails, because you will not be standing next to the gateway when an update goes wrong.

Design for the bad day, not the demo. Assume the network drops, the storage wears, and the bus goes quiet, then decide what the gateway does in each case before it ships. Get the field layer right and the cloud is mostly configuration. Get it wrong and no amount of cloud cleverness recovers data that was never captured correctly.