The incredibly hard fuel level monitoring problem and Fleetx’s industry leading solution: Sentinel
We have all used beakers in some form or another. Markings on a beaker tell you the level of fluid inside them. Now, let us apply this to a fuel tank. You have a fuel tank of, say, 400 litres. You decide to put in a digital scale, which keeps measuring the level in the tank and reports it every second. Seems simple. What could go wrong? Well, turns out almost everything.
Why is it such a difficult problem? The height of the tank can be anything around 1 foot to 2 feet, i.e., 30 to 60 cm. Let’s calibrate our digital ruler to have 1 mm markings. So, 600 markings spread over 400 litres, i.e., 1 mm represents 0.8 litres. Now, vehicles being vehicles, they will move, travel on Indian roads (though not as bad as before! We have very surprising mileage increase data available with us), move from hilly areas to plains in a trip, move from humid to dry areas in a day. Also, please note that the fluid being measured is diesel here; density of diesel changes with temperature and atmospheric pressure. Change in density can cause diesel to expand or contract, causing changes in fuel level. Also, our digital scale is a capacitive fuel rod sensor, which is essentially two concentric cylinders that measure capacitance difference within the two layers caused by presence and absence of fuel. This fuel rod sensor can have its own noise; fuel can get stuck in between the two layers and get “unstuck” on its own whim. All the while, the sensor will be sending anomalous values.
Recall, 1 mm of length of the fuel rod sensor corresponds to 0.8 litres, i.e., a fluctuation in reading of 1–2 cm can cause an error of roughly 15 litres. Actual fuel thefts are normally around 10–15 litres. A fuel fill event with a ±15-litre error is actually not acceptable. And a trip giving fuel consumption with a ±15-litre margin is also not of much use either. If you have reached here, and I have been able to put my point across, you might have come to realize the futility of this exercise. “Why are we even doing this?” has been asked by multiple engineers in our team (and some clients too 😛).
Sentinel: Fleetx’s Fuel Monitoring Solution
Our fuel monitoring solution operates at multiple levels in terms of recency:
Real-time: We normalize fuel level readings at run time. This step must be wary of overfitting, as it can lead to missing the peaks and troughs of the graph
Delay Thresholds: Once we detect a fill or theft, we need to decide whether to push the alert immediately or to “hold” it for further confirmation. This decision is based on a confidence score, which we will discuss in detail later in this post. Over time, we have identified patterns that indicate whether immediate action is warranted or if further evaluation is necessary (i.e. a “close watch” needs to be taken over the event, hence the name, Sentinel) .
Post-Process/Recall: Sometimes, even after a sufficient delay, the alert event may still be inconclusive. In such cases, we may choose to either discard the event or notify the client. However, we revisit these events later when more time has passed and additional information around the event’s legitimacy may be available.
Our Algorithm works in the below sequence:
1. Fuel Normalization and Smoothening:
Fuel normalization and smoothening is done immediately after the tcp packet hits our netty server. Normalised packets are pushed to a kafka queue to be consumed later by a spark consumer.
2. Fuel Event Detection:
A sudden rise or drop in fuel level starts a possible fuel event(fill or theft) . Then once fuel level is stabilised it marks the end of the event. The difference in start and end fuel level will be the quantum of the theft/fill. This event detection is done in a spark handler.
3. Fuel Validation i.e Pattern Matching:
Our clients report fuel fill logs both manually and via integrations from fuel providers like BPCL etc. They also report actual fuel thefts to our support teams. This means that we have a verifiable trail for both the quantum and detection accuracy of our fuel events. This has enabled us to find various scenarios which are characteristically of a fuel fill or theft event. Theoretically too, a sensor sending noisy data would behave very differently from a sensor whose fuel is being stolen. Given enough data, these patterns can be identified with a lot of certainty. For instance, a fill event, immediately followed by a theft event is most likely a sensor anomaly, however a fill event of a large value with a swift rise can straight away be considered a valid event.
4. Confidence Scoring:
Confidence score is generated over validated fuel events received from step 3, using every individual vehicles own scores. Some validated fuel events can get discarded here.
Confidence Score Parameters:
For every vehicle, we maintain parameters like:
- variationThreshold: measure of how much variation is observed in fuel level readings in individual vehicles. If the theft event is very close to the variationThreshold, it is a low confidence event. For e.g. a theft event of 5 litres in a vehicle where avg magnitude of variation in readings is 5 litres is a low confidence event.
- discardToAcceptRatio: This measures the ratio of discarded events to accepted events historically. A vehicle with a discard to accept ratio nearing zero is less likely to report a false alert. This also takes into account actual feedback from clients and our support teams.
- tankLevelThreshold: If a vehicle has low variationThreshold and low discardToAcceptRatio, we can call out alerts as low as 1% of the fuel tank. In fact, we call out a lot of thefts as low as 5 litres with sufficient accuracy. We can also detect fuel fills of 5 litres in gensets etc.
- delayThreshold: This is a time threshold after which a call to either discard or notify the event has to be taken. When the delayThreshold is reached we fetch a lot of raw data, analyse all possible patterns on it and then push the alert to discard queue or notify queue.
5. locationScore: Since location intelligence is already a part of our primary analytics, we utilize it to complement our algorithm. When we determine that a vehicle is actually at a fuel station, it is highly probable that the increase in fuel level indicates an actual fuel fill event. Similarly, when a vehicle is in a “risky area” (these are theft-prone areas self-reported by clients), we can assign a score to the theft event. We also have account-level heatmaps for areas where thefts/fills are likely or unlikely. For example, thefts are almost always unlikely within the client’s own geofences; however, fuel fills are very likely within their own loading geofences since they may have inhouse fuel stations or fuel tankers.
As we keep getting data from these vehicles, we keep on updating the score of the above parameters, and over time are able to generate fuel events with high confidence scores. We have also done parameter tuning to decide what weight should these parameters have for our confidence score.
In vehicles identified for a case study, we detected Rs 4500 per week of actual theft on average. With our fill accuracy around 99%, clients also ensure that amount of fuel being filled is same as amount of fuel being paid for. These saving alone pay for the capex involved in one month. Also, since consumption starts getting measured accurately, there is an opportunity for streamlining operations across the fleet. When consumption of a vehicle is abnormally high, our clients are able to identify the root cause with our other products like driver scoring, DTC’s, wasted fuel and detailed fuel analytics. 70% of our clients, who start a POC, keep on increasing the coverage of fuel sensors in their fleet incrementally as the value add is pretty obvious.
I think, above is enough peek under the hood of our watchdog Sentinel. We can go into further detail in subsequent posts. Please feel free to comment and ask questions around this in comment section or reach out to us here. We will follow this post with details of our newly released Pilferage Alarm, an industry first alarm detecting fuel thefts in running vehicles.
