How We Built a Real-Time AIoT Fuel Monitoring System Using CAN Bus and a Mobile-First Data Pipeline

Every Liter Has a Story. Most Companies Can't Read It.

The client's finance team knew their monthly fuel spend. That was the full extent of their visibility.

They could see the total. They could not see which vehicle consumed what, which driver authorized which fill, or whether the volume purchased at any given station matched the vehicle's actual deficit. The expense line was real. Everything beneath it was a guess.

Standard GPS trackers, which the client already had, made this worse in a specific way: they created the impression of visibility without delivering it. A vehicle pinned to a petrol station on a map at 14:32 tells you nothing about what happened at the pump.

Closing that gap required reading data that only the vehicle itself holds.

The Constraint That Defined Everything

The client had two non-negotiable requirements that shaped the entire system.

First, the vehicles could not be physically modified. No aftermarket in-tank sensors, no inline fuel flow meters, nothing that touched the fuel system itself. The vehicles had to remain factory-stock. This ruled out the most direct measurement approaches immediately.

Second, the OBD hardware could not carry its own cellular connection. No SIM card, no independent uplink. Whatever the device read had to travel to the cloud through the driver's smartphone.

These were not presented to us as design preferences. They were hard limits. The architecture either worked within them or it didn't work at all.

The OBD-II Port: The Only Viable Entry Point

What the CAN Bus Actually Is

Every modern vehicle runs an internal communications network. The engine control module, transmission controller, instrument cluster, body control module and others all share a two-wire differential bus called the Controller Area Network, standardized under ISO 11898.

Traffic on this bus is continuous, hundreds of frames per second, each with an identifier and up to 8 bytes of payload, carrying data about engine state, sensor readings, switch positions and everything else the vehicle monitors about itself. Fuel level data is already there in most modern post-2010 consumer vehicles. Getting to it cleanly is a different matter.

The OBD-II port, mandatory on passenger vehicles since 2001 in the EU, provides physical access to this bus. A dongle plugged into that port can read CAN frames directly, without any modification to the car.

The Parameter ID Problem Is a Hard Problem to Solve

OBD-II defines a set of standardized Parameter IDs under Service 01. PID 0x2F is the standard fuel tank level input: one byte, 256 discrete steps, 0% to 100%.

On a 60-liter tank, each step is roughly 235 milliliters. That resolution is workable for detecting a fill event but it is not precision measurement. Anyone presenting two-decimal-place liter figures from a standard OBD PID is overstating what the hardware can actually deliver for a regular consumer vehicle.

The bigger issue is that many manufacturers route their high-fidelity fuel sensor data through proprietary CAN frames rather than the standardized PID. These frames have undocumented identifiers. Decoding them requires either manufacturer cooperation, a reverse engineering process using a CAN bus analyzer during controlled fill and drain cycles, or access to fleet-specific PID databases built up over years of empirical testing.

Even if the car uses CAN FD or a newer CAN variant, which theoretically handles more precise data, it does not help when the fuel sensor itself does not take advantage of it.

For this project, the client's fleet was uniform: a single set of vehicle models. After analysis, we confirmed that these specific models exposed fuel level through accessible PIDs with sufficient resolution for event detection. That finding was specific to these vehicles. It does not generalize. At the same time, we never needed such precise monitoring in the first place, so we were in the clear. Anyone telling you their solution works across all makes and models without qualification is selling you something.

Decoding a Fuel Level Frame

Once the correct frame identifier is known, the dongle queries or passively listens for it. The raw payload is decoded using a signal definition: bit offset, bit length, scale factor, and offset. For the standard PID:

Fuel Level (%) = (raw_byte / 255) × 100

Proprietary frames require the signal definition to be derived from empirical logging. The dongle polls at a configurable interval and stores timestamped readings in a local ring buffer on the device.

The Phone as the Data Pipeline

BLE Pairing Architecture

The OBD dongle communicates with the driver's phone over Bluetooth Low Energy. On initial setup, the dongle is paired using a secure bonding procedure, with the dongle's BLE peripheral address and service/characteristic UUID registered in the app's configuration store.

During a driver's shift, the app maintains a persistent BLE connection. The dongle streams fuel level readings as GATT notifications to the app's characteristic subscription.

BLE introduces real operational constraints worth naming. Range is limited to roughly 10 meters in clean conditions and less through vehicle body panels. If a driver leaves their phone in a jacket in the back seat rather than the cab, the connection can drop. The more persistent issue was that devices do not reliably auto-reconnect after a dropped session, which required dedicated reconnection logic in the app rather than relying on the OS to handle it.

Local Buffering and Cloud Sync

Every incoming BLE frame is written to an on-device SQLite store before anything else happens. Each record is tagged with the authenticated driver's identity token and the vehicle ID from the paired dongle's registered serial number, then GPS coordinates are attached from the device's location service, sampled at the same cadence.

If the phone loses internet connectivity, data accumulates locally. When connectivity returns, the app replays the buffered sequence to the cloud ingestion endpoint in order, with deduplication keys preventing double-counting on retry.

This is not a novel pattern but it works under the constraint. The mobile is responsible for pairing, buffering, enriching each record, and managing the uplink.

One edge case that required specific handling: drivers who close the app manually between stops. Background process management on both Android and iOS will eventually terminate an app that is not actively running. The solution was a persistent foreground service notification on Android and a background processing entitlement on iOS, combined with aggressive reconnection logic on app resume. Both operating systems are hostile to long-running background processes by design, and working around that hostility without draining the driver's battery was its own engineering problem.

The QR Code Layer: Intent Before the Fill

CAN bus data tells you what happened to the fuel level. It does not tell you whether the driver intended to be at that station, or whether anyone verified they were there before the pump opened.

We added a QR code check-in step at each approved fuel station to address both of those things at once.

How It Works

Each station in the client's approved network has a physical QR code posted at the pump or on the station wall. Before fueling, the driver scans it through the same app already running on their phone. The scan records three things at the moment it happens: the station's registered ID encoded in the QR payload, the driver's authenticated session token, and the phone's GPS coordinates at scan time.

That record is sent to the cloud immediately as a REFUEL_INTENT event, independently of any CAN bus data.

{
  "event_id": "intent_20240914_1428_VH042",
  "type": "REFUEL_INTENT",
  "vehicle_id": "VH042",
  "driver_id": "DRV_0187",
  "station_id": "STN_019",
  "timestamp_utc": "2024-09-14T11:28:43Z",
  "location": { "lat": 23.8101, "lng": 90.4122, "accuracy_m": 21 }
}

Why This Matters for the Detection Pipeline

The QR scan creates an expected fueling window. The event engine knows that vehicle VH042, driven by DRV_0187, declared intent to refuel at station STN_019 at 11:28 UTC. When the CAN bus data produces a confirmed positive fuel delta at 11:32 UTC at coordinates that match that station, the two records are correlated and the event confidence score rises.

If a fuel delta is detected with no preceding intent record, the event is still logged but flagged for manual review. If an intent record exists with no subsequent fuel delta within a reasonable time window, that is also flagged. Neither of those scenarios requires an automated accusation. They require a conversation, which is what the client wanted.

The Limitations Worth Stating

QR codes can be photographed. A driver could theoretically scan from a photo taken by someone else at a different time. The mitigation is that the GPS coordinates at scan time must fall within a configured radius of the station's registered location. Scanning a photo of a QR code while sitting in a different city does not pass that check.

QR codes also get damaged. Stickers deteriorate, particularly at outdoor fuel stations in humid or high-traffic environments. The client's operations team maintains the codes and replaces them on a scheduled basis. When a code is unreadable, the driver has a fallback: a station ID manual entry flow that requires manager approval before the fueling session is marked as authorized. It is slower, it is intentionally slower, and that is the point.

The QR layer is not a fraud-proof system. It is a friction point that makes the intent-to-refuel a declared, timestamped act rather than something reconstructed after the fact from sensor data alone. For the client's operational requirements, that distinction was exactly what they needed.

Detecting a Fueling Event

Raw fuel level percentages are a time series. A fueling event is a discrete occurrence that has to be inferred from that signal, and the inference is less straightforward than it sounds.

The Detection Algorithm

The event engine processes the incoming fuel level stream per vehicle and applies the following logic:

• A rolling baseline is calculated from the median of recent readings before any anomaly window.
• A fueling event is triggered when fuel level rises by more than a configurable threshold, sustained across multiple consecutive readings, not just a single spike.
• Debouncing is critical. Road vibration, sensor polling variance, and BLE retransmission timing all introduce noise into the signal. Single-sample spikes are discarded.

The GPS coordinates at the timestamp of the delta's inflection point are attached as the location of the fueling event. The vehicle's registered tank capacity is used to convert the percentage delta into an estimated volume in liters.

The Temperature Problem

Fuel volume as reported by the sender unit changes with fuel temperature. On a hot day, a parked vehicle can show a measurable apparent rise in fuel level with no actual fueling. It is a known and documented problem in tank-level telematics.

Our handling was to require that the engine had been running for a minimum period before a positive delta was treated as a candidate event, filtering out the thermal expansion signature that occurs when a cold engine warms a partially full tank. It works under most conditions. It is a known limitation and the client was made aware of it directly.

GPS Accuracy at the Pump

Petrol station canopies are metal structures. Metal structures cause GPS multipath interference. This is the exact environment where fueling events occur, and it is exactly where GPS accuracy degrades.

In testing, we measured accuracy figures ranging from 6 meters to over 30 meters depending on station layout and satellite geometry at the time of the event. For the client's use case, locating a vehicle to within a city block was sufficient. For any application requiring precise station-level attribution, this would need augmentation, potentially with cell tower triangulation or a curated geofence database of known fuel station locations.

What an Event Record Actually Contains

{
  "event_id": "evt_20240914_1432_VH042",
  "vehicle_id": "VH042",
  "driver_id": "DRV_0187",
  "timestamp_utc": "2024-09-14T11:32:07Z",
  "location": { "lat": 23.8103, "lng": 90.4125, "accuracy_m": 18 },
  "fuel_level_before_pct": 18.4,
  "fuel_level_after_pct": 81.7,
  "estimated_volume_liters": 38,
  "volume_uncertainty_liters": 2.1,
  "intent_event_id": "intent_20240914_1428_VH042",
  "event_type": "REFUEL"
}

The volume figure is an integer. The uncertainty field is explicit. The intent event ID links this confirmed fill back to the driver's QR scan four minutes earlier. That chain is what makes the record auditable.

Cloud Ingestion

Raw telemetry frames arrive at a high-throughput ingestion API authenticated per driver session token. Frames are written to a time-series store and queued for the event detection service. Confirmed fueling events are published to a message broker and fanned out to the real-time dashboard, the push notification service, and the data warehouse.

End-to-end latency from physical fueling event to notification delivery is a function of the BLE poll interval, the debouncing window, cellular signal quality, and processing queue depth. Under good conditions in testing, we saw 90 to 150 seconds. That is the realistic figure. Claims of sub-60-second delivery for a system with a multi-sample debouncer are arithmetically difficult to defend.

The Management Interface

The executive-facing app was designed around a single priority: a manager who receives a push notification at 14:32 should be able to confirm or question that event without opening a laptop.

What the Dashboard Shows

• A live vehicle map with current GPS positions of active vehicles.
• A chronological fueling event feed, each entry showing vehicle ID, driver name, reverse-geocoded location, estimated volume, and timestamp.
• Per-vehicle fuel level indicators updated from the telemetry stream.
• Intent-to-fill events that did not result in a confirmed fuel delta, surfaced as a separate review queue.

Push Notifications

Every confirmed fueling event triggers a push notification to subscribed management accounts. The notification contains vehicle, driver, volume estimate, and location. Managers can configure filters by vehicle, by driver, or by volume threshold.

The notification is the primary interface for most managers, not the dashboard. That shaped how much information had to be in the push payload itself.

Historical Reporting

The reporting module provides fuel consumption per vehicle and per driver over configurable date ranges, a location-based view of where fueling events cluster, and CSV export for integration with existing ERP systems.

The per-driver view was the feature the client's finance team used most. Being able to attribute fuel spend to an individual for the first time, rather than to a vehicle or a cost center, was what the client described as the actual outcome they had been trying to reach.

Book a Discovery Call

If your fleet is producing operational data that your current tools cannot attribute, the gap is usually not hardware. It is the software layer that sits between the hardware and the people who need to act on the data.

We design and build custom IoT vehicle telematics and mobile applications for logistics operators, enterprise fleet managers, and mobility companies, from initial architecture through production deployment.

We will look at your specific vehicles, your operational constraints, and your reporting requirements, and tell you honestly what is and is not possible.

Reach us directly at contact@cortextech.dev

Tags: AIoT fleet management · real-time fuel tracking · CAN bus data extraction · custom mobile app development · IoT vehicle telematics · software-defined fleet · OBD-II · BLE gateway · enterprise fleet monitoring