Routly.

Engineering · 6 min read

Fuel theft detection is a rule, not magic

The difference between a drain and a shift of ordinary burn is a rate of change. The thresholds we use, the false positives they cause, and how to tune them.

Fuel theft detection is a rule, not magic — Routly

Fuel loss is the feature that most often pays for a fleet platform inside a quarter, and it is also the one most often sold as if it were clever. It is not clever. It is a threshold on a rate of change, and the useful thing to know is which thresholds and why.

The signal you are working with

A level sensor reports litres, or a percentage you convert to litres, every time the tracker sends a message. That is the entire input. Everything else is interpretation.

Two things make interpretation harder than it sounds. Level sensors are noisy — fuel sloshes, so a moving vehicle produces a sawtooth around the true level. And they are irregularly sampled — a message every thirty seconds while moving, then nothing for eight hours in a yard, then one message that is the first news you have had all night.

The rule

Strip it back and there are four numbers. These are the ones Routly ships with:

ParameterValueWhat it does
Minimum drop5 litresBelow this, it is noise or a slosh
Sudden window5 minutesA drop inside this window is a drain; slower is consumption
Maximum drop200 litresAbove this, the sensor glitched
CooldownPer vehicleStops one event firing repeatedly

The logic that follows from them is short enough to say in a sentence: a decrease of at least five litres, arriving within five minutes of the previous reading, and not larger than a tank, is a drain. Everything else is consumption.

The time condition is the one doing the work. Eighty litres disappearing over a six-hour shift is a lorry doing its job. The same eighty litres between two readings four minutes apart is somebody with a hose.

Why each number is where it is

Five litres, not one. Sloshing on a partly full tank routinely moves a reading by two or three litres. Set the floor below the noise and you generate an alert every corner, which trains people to ignore alerts — the worst outcome available, because it disables the feature without switching it off.

Five minutes, not thirty. This is the boundary between “physically implausible as consumption” and “possible on a hard climb”. An engine burning eighty litres in five minutes would be remarkable. In thirty, a heavily loaded truck uphill is merely thirsty.

Two hundred litres as a ceiling. Not because larger thefts do not happen, but because a reading that jumps by more than a typical tank is almost always a sensor fault, a power cycle, or a unit change — and reporting it as theft sends someone to accuse a driver on the strength of a broken wire. Losses above the ceiling should surface as a sensor health warning, which is a different message to a different person.

A cooldown per vehicle. After a drain fires, the level is now low. Without a cooldown, the next few readings can re-trigger on the same event and one theft becomes fourteen alerts.

The false positives you will get anyway

Expect these, and expect to explain them:

Refuelling followed by a drop. A fill takes the level up sharply; if the sensor overshoots and settles, the settle looks like a drop. Suppress drains for a window after a fill.

Tank geometry. Level sensors are rarely linear. The same centimetre of depth is a different volume near the top of a saddle tank than near the bottom, so a constant burn produces a varying litres-per-minute. If your fleet reports a cluster of drains at one particular level, that is geometry, not thieves.

Parked on a slope. A vehicle parked nose-down all night and driven off in the morning produces a step change at the moment it levels out.

The gap after a coverage hole. Two readings eight hours apart with a large difference between them are not a five-minute event, and the time condition correctly rejects them — but only if you compare against the previous reading’s timestamp rather than assuming a fixed interval. Getting this wrong is the most common implementation bug in the category.

What to do with a detection

A drain event is a lead, not a verdict, and the difference matters both practically and legally.

Route it to a person, with the context that makes it checkable: which vehicle, what time, where — with the position, because “in the depot at 02:14” and “at a service station at 14:20” are different stories — how much, and the level trace either side. Someone looks. Sometimes it is a fill logged as a drain because the sensor was reconnected. Sometimes it is a driver siphoning.

Do not automate a consequence. Behavioural inference about a named driver is personal data with its own compliance weight, and an automated decision with a significant effect on someone brings Art. 22 into play. Human in the loop, every time.

Tuning it for your fleet

The shipped numbers are a starting point tuned for trucks with sizeable tanks. Two adjustments are common:

Vans and cars. A 60-litre tank makes five litres a large fraction of it, and thefts are proportionally smaller. Lower the minimum to two or three litres and accept a higher false positive rate, or accept that small siphoning goes undetected. There is no setting that gives you both.

Refrigerated units and generators. These burn while stationary, which breaks the assumption that a parked vehicle should not be losing fuel. Either exclude them or give them their own threshold set.

The honest way to tune is to run detection in a reporting mode for a month before anyone is alerted, then look at what it caught and what people already knew about. Adjust once against reality rather than repeatedly against complaints.

What good looks like operationally

The measure of this feature is not how many events it produces. It is whether the litres per hundred kilometres for the fleet moves after you start acting on them. If detection is on for a quarter and consumption is unchanged, either there was no theft — good news, and worth knowing — or the alerts are going somewhere nobody reads.

Routly separates the two numbers on purpose in the fuel screen: consumption against cost per vehicle, with sudden drops flagged as a distinct count rather than folded into the month’s total. A drain buried inside a monthly consumption figure is invisible, which is exactly how it stays profitable for whoever is doing it.

Frequently asked

Do I need a dedicated fuel sensor?

Not necessarily. CAN-bus fuel level works on many vehicles and needs no extra hardware. A capacitive or ultrasonic probe in the tank is more accurate and more expensive, and it is what you want if you are building a case that will be disputed.

How accurate can it be?

Accurate enough to catch a theft of five or more litres and to reject most noise. Not accurate enough to be a fuel meter — for litres actually burned, use consumption over distance rather than level differences.

Will it work with a fuel card integration?

That is a different and complementary control: fuel card data catches a fill that never reached the tank, level sensing catches fuel leaving the tank. Fleets exposed to both usually want both.

Can I see the rule in the demo?

The fuel screen in the demo shows consumption, cost and a drain count on generated data. The thresholds above are the ones the software ships with, and they are configuration rather than a rewrite.

Talk to us

Tell us what you are running now

Tell us what you run today and how many vehicles are on it — whether that is one fleet or thirty customers’ worth. We answer within one working day.

Or look around first — the demo needs nothing from you. Open it.

Across every fleet you run, if you run more than one. The total decides what the infrastructure costs you to run, which is the first thing we will tell you.

We answer within one working day.