From Raw Telematics to Actionable Fuel Decisions in Under 60 Seconds
What the Octane processing pipeline looks like from the first OBD frame to a dispatched alert, including the latency budget at each step.
The 60-second target is not a marketing number. It is an engineering constraint that shaped every design decision in our pipeline. When we started building Octane, the first question we had to answer was: what is the minimum time between "siphoning starts" and "fleet manager receives an alert"? The answer determines whether the detection is operationally useful or just an interesting historical record.
This article walks through the actual processing stages, the latency budget at each, and where the assumptions behind that 60-second figure can and do break down.
What the Raw OBD Frame Contains
Every few seconds, the telematics device on a connected truck transmits a data frame. The exact format depends on the device family. A Teltonika FMB140 sends a binary AVL packet over a TCP socket. A Queclink GV300 sends AT command responses serialized as JSON over MQTT. A raw CAN bus reader sends structured binary with PID identifiers.
Regardless of format, the minimum fields we require are: vehicle identifier, device-side timestamp, fuel level percentage from CAN bus PID 0x2F, GPS coordinates with accuracy estimate, current vehicle speed, and engine load percentage. Without all six, the frame cannot be processed reliably for anomaly detection. Frames with missing critical fields are queued for partial processing and flagged for the data quality layer.
The normalization step, mapping each device's proprietary payload into our canonical frame structure, runs in under 50 milliseconds. It is the fastest stage in the pipeline. The consequential work happens afterward.
The Baseline Comparison: Where Real Computation Happens
A single fuel level reading conveys almost nothing by itself. At motorway speed with a loaded cargo truck, fuel consumption runs approximately 30 to 38 liters per 100 kilometers depending on engine type, load, and gradient. At idle with the engine running, it is closer to 2 to 4 liters per hour. A drop from 68% to 65% over 6 minutes needs context to mean anything: was the truck moving, at what speed, on what terrain?
The baseline comparison layer maintains a per-vehicle consumption model built from 90 days of historical driving data. Consumption coefficients are learned separately for high-speed highway segments, urban stop-and-go operation, idle periods, and gradient conditions derived from GPS elevation data. When a new frame arrives, the engine computes the expected fuel level given elapsed time, speed during the interval, load, and the vehicle's learned coefficients. The difference between expected and observed fuel level is the residual.
A residual below the threshold is noise. A residual above the threshold, especially one that accumulates across multiple consecutive frames, enters the scoring window. This lookup and computation runs in under 200 milliseconds per frame, most of which is the database round-trip for baseline parameters rather than the arithmetic.
The Scoring Window and Why Single-Frame Alerts Are Wrong
One of the early design decisions we revisited was single-frame alerting. Our first prototype dispatched an alert any time the residual exceeded a threshold on a single frame. The false positive rate was unusable: ECU resets, brief sensor disconnections, and CAN bus glitches all produce single-frame spikes indistinguishable from a real anomaly.
The current design uses a sliding window of 5 to 8 consecutive frames. Each frame in the window is weighted by the magnitude of its residual and the vehicle's motion state at the time of the reading. A large residual while the vehicle is stationary at a non-depot location gets weighted substantially higher than the same residual observed during normal highway driving, because stationary fuel loss has very few legitimate explanations. Engine idle accounts for at most 2 to 4 liters per hour; a level drop of 12 liters in 10 minutes while the vehicle is parked cannot be attributed to consumption.
When the weighted score in the window exceeds the alert threshold, the event is promoted to a confirmed anomaly. This scoring window adds 40 to 80 seconds to end-to-end latency in the best case, but it is the stage that makes the alerts worth acting on. A 90-second true alert beats a 10-second false one every time.
Alert Assembly and Dispatch
Once an anomaly is confirmed, the alert assembly step runs in under 100 milliseconds: pull the most recent GPS fix for the vehicle, compute the estimated volume lost based on tank capacity and the observed percentage drop, format the alert payload with vehicle ID, event start timestamp, location coordinates and a reverse-geocoded address where available, estimated liters lost, and the confidence score.
The alert is pushed to our notification queue, which fans out to push notification (via Firebase Cloud Messaging) and email simultaneously. FCM delivery under normal cellular conditions takes 1 to 5 seconds. Email delivery adds another 10 to 30 seconds depending on mail server processing on the operator's end.
Total time from the first anomalous frame to notification in the operator's hands: typically 25 to 55 seconds under normal conditions, with the variance driven almost entirely by device polling frequency and cellular round-trip latency rather than server-side processing.
Where the 60-Second Target Breaks Down
This is worth being precise about. The 60-second figure assumes that the telematics device is transmitting continuously and that cellular connectivity is stable. On the Cairo ring road or within urban Giza, that assumption holds. On long-haul routes through the Western Desert between Cairo and the Upper Egypt governorates, it does not.
Devices on routes with significant dead zones buffer locally and upload in bulk when connectivity returns. A siphoning event that occurs in a coverage gap will not generate an alert until the upload completes. We cannot compress this with faster server processing. It is a physical constraint of cellular coverage geography, and we do not try to hide it: when a vehicle has been offline for more than a configured threshold, we flag the operator that coverage was lost and indicate the time window with no real-time guarantee.
We are not claiming that Octane solves every fleet security problem in real time. Coverage-gap vulnerabilities are a real constraint that should inform where operators park vehicles overnight and which routes warrant additional supervision. Knowing where those gaps exist is itself useful intelligence, even if the detection during those windows is necessarily retroactive.
What Alert Latency Actually Enables
Fleet operators sometimes ask whether the speed difference between 45 seconds and 5 minutes matters. The honest answer is that it depends on the operational context. A dispatcher who receives a 2 AM alert about a truck parked at a remote depot may not be able to dispatch security quickly enough to intervene regardless of how fast the alert arrives. In those cases, the investigation capability that follows is what matters most.
What low-latency detection changes is the quality of the follow-up. An alert that arrives 45 seconds after the event begins means the time, location, and estimated volume are accurate. It means the driver is still at or near the location. It means a phone call or radio contact can be made while the event is current, not 3 days later when the driver can no longer recall which stop they made. That is the operational case for the 60-second target: it is not about catching the thief in the act. It is about creating an accurate, time-stamped record that supports real investigation rather than a vague "something happened last week" report.