Executive summary
- Vehicles drive through tunnels, basements, rural roads and borders. A telematics unit that only works while connected will lose exactly the data fleets care about most.
- We separate the device into two controllers: one dedicated to the vehicle bus, one to connectivity and storage. A failure or delay on the network side never blocks reading the vehicle.
- Every record is written to local storage first and published second. When the link returns, buffered records are replayed in order, and the cloud must accept duplicates safely.
- What the device collects — which signals, how often, with what change threshold — is configuration, not code, so it can change without a firmware release.
- Firmware for both controllers can be updated in the field, with a bootloader that keeps a device recoverable if an update is interrupted.
1. The coverage problem
Telematics data is only useful if it is complete. A missing ten minutes can hide a harsh-braking event, a fault code or the exact place a vehicle stopped. Yet mobile coverage is never guaranteed: underground car parks, depots with metal roofs, remote highways and cross-border trips all interrupt the link.
Many simple trackers treat the network as always available and drop or overwrite data when it is not. Our design starts from the opposite assumption: the network will fail regularly, and the device must behave correctly when it does.
2. Two controllers, one job each
The LIDAVI vehicle unit uses two microcontrollers with clearly separated responsibilities:
| Controller | Owns | Never does |
|---|---|---|
| Domain controller | The vehicle bus: CAN 2.0A/B, OBD-II PID polling, UDS diagnostics and J1939; aggregation of signals into records | Network I/O, storage, cloud protocols |
| Cloud controller | Wi-Fi, cellular modem, Bluetooth LE, SD-card storage, MQTT publishing, firmware distribution | Direct access to the vehicle bus |
CAN 2.0A and 2.0B are the standard and extended frame formats of the CAN specification,2 and UDS is the diagnostic service layer standardised in ISO 14229.5 This split has practical benefits. Bus timing on the vehicle side is never disturbed by a slow modem or a TLS handshake. Each controller has a smaller, testable code base. And either side can be replaced — for example a Linux-class connectivity processor for higher-end units — without touching the other.
3. A simple, robust internal link
The controllers talk over a serial UART using a small framed protocol: a sync byte, a length, an operation code, the payload and a checksum. Operation codes cover heartbeats, device details, configuration, telemetry, diagnostics, events and entering the bootloader.
Configuration travels as typed blocks (CAN, telemetry and diagnostics settings) with strictly increasing version numbers, so each side can tell whether it holds the latest settings and stale configuration is never applied over newer configuration.
Keep the internal link boring. Fixed framing, explicit lengths, a checksum and versioned configuration are easy to test, easy to log and easy to reimplement on a new controller.
4. Store and forward
The core of the design is that every record is stored before it is sent. The cloud controller writes records to the SD card, organised per vehicle, and publishes them when a link is available.
- Write first, publish second. A record exists on the card before any attempt to send it, so a crash or power loss mid-transmission does not lose data.
- Ordered replay. After an outage, buffered data is replayed to the cloud in small chunks, oldest first, so the cloud rebuilds the timeline in order.
- Bounded storage. Log files rotate at a configured size, a fixed number of files is kept, and a minimum free-space threshold protects the card from filling up.
- Unknown vehicles. If the vehicle identification number cannot be read within a set time, data is still recorded under a placeholder so nothing is lost.
With MQTT quality-of-service level 1, a message is delivered at least once, so duplicates are possible after reconnects.1 A store-and-forward device must therefore be paired with a cloud that de-duplicates, for example by device identifier and record timestamp.
5. Connectivity failover
The cloud controller prefers Wi-Fi where available (depots, workshops) and fails over automatically to the cellular modem on the road. Bluetooth LE is used for onboarding a new device from a phone and for reading live data locally, even with no internet at all. Because storage sits underneath all three links, the choice of link affects only when data arrives, never whether it arrives.
6. Acquiring the right data
Collecting every signal at maximum rate wastes bandwidth and storage. Collecting too little misses events. We make acquisition configurable on the device through a JSON file on the SD card. A trimmed example:
- Per-signal intervals poll fast-changing values often and slow ones rarely.
- Deadbands suppress readings that changed less than a set amount.
- Windows aggregate readings into one record per period instead of one per sample.
- Trips and fault codes are detected on the device: a trip ends after the engine has been off for a set time, and diagnostic trouble codes are scanned periodically.
The parameter identifiers above are standard OBD-II PIDs (vehicle speed and engine speed), defined in SAE J1979.4 On CAN they are carried using the ISO 15765-2 transport protocol.3
7. Updating devices safely
A fleet cannot be recalled to the workshop for every firmware change. Both controllers can therefore be updated remotely:
- Firmware images are stored in the cloud and fetched by the cloud controller.
- The domain controller has its own bootloader. The cloud controller instructs it to enter the bootloader and transfers the new image over the internal link.
- The bootloader stays resident, so a device whose update is interrupted can still be re-flashed rather than becoming unusable.
8. The cloud side
Devices publish to MQTT topics addressed by device identity, separated into status, events, commands and responses. An ingest service batches incoming records into a time-series database; an API serves portals and apps; an identity service handles sign-in; and an object store holds firmware images and archives. The same stack runs locally in containers with a simulator that publishes vehicle telemetry, so features can be tested end to end without a vehicle.
Because device data may arrive late and more than once, ingest must be idempotent: a record already stored for the same device and time should be ignored, and late records inserted in their correct place in the timeline.
9. Lessons learned
- Keep the specification next to the code. In our first generation, the binary format evolved faster than the written specification. We now keep protocol definitions, architecture decisions and a SysML v2 system model in the same repository as the code.
- Design the outage path first. Test with the network deliberately removed, not only in the office.
- Prefer configuration to code. Which signals to collect, and how often, varies from fleet to fleet. Making it configurable avoids a firmware release for each change.
10. Conclusion
Reliable telematics comes less from any single component than from a few disciplined choices: separate the vehicle side from the network side, store before sending, accept duplicates in the cloud, make acquisition configurable and keep devices updatable. These are the principles behind the LIDAVI telematics platform, from its first generation to the current one.
References
- OASIS (2014). MQTT Version 3.1.1. OASIS Standard. http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html
- Robert Bosch GmbH (1991). CAN Specification, Version 2.0.
- ISO 15765-2:2016. Road vehicles — Diagnostic communication over Controller Area Network (DoCAN) — Part 2: Transport protocol and network layer services. International Organization for Standardization.
- SAE J1979 (2017). E/E Diagnostic Test Modes. SAE International.
- ISO 14229-1:2013. Road vehicles — Unified diagnostic services (UDS) — Part 1: Specification and requirements. International Organization for Standardization.
This white paper is provided for information. Figures labelled “Established” or “Peer-reviewed” are taken from the cited sources; figures labelled “Industry claim” have not been independently verified by LIDAVI; anything labelled “Design target” or “Hypothesis” is LIDAVI’s own and must be confirmed in a site-specific feasibility study. Nothing here is a performance guarantee.