If GPS tracking is the A of vehicle monitoring, fuel management is probably B.
For many telematics businesses, the first customer request is to know the vehicle's location. The next is often to understand how to spend less on fuel. That need was relevant ten years ago and remains just as important today, especially in 2026, when fuel prices have been going up and up. In July, fuel and lubricant prices across the EU were 16.9% higher than a year earlier.
The basic tasks of fuel monitoring have not changed much over the past years: fleets still need to monitor refuelings, drains, consumption, and discrepancies. What has changed is the technology used to solve those tasks.
For this retrospective, we spoke with experts from both sides: Gurtam, representing the telematics software providers' perspective, and our long-time partners at Escort Monitoring Systems, representing the hardware side.
We asked them to look back at the past decade and explain how fuel monitoring has changed in practice, from sensors and installation to data processing and the division of work between hardware and software.
Same business problem, different system around it
– If the core tasks of fuel monitoring have stayed largely the same, what has actually changed over the past ten years?
Artiom Romanovskiy, Technical Growth Manager at Wialon, Gurtam
What has changed over the past ten years? Quite a lot. From a technology perspective, fuel level sensors themselves have become more advanced. Wireless sensors (e.g., BLE) have emerged, eliminating the need for a wired connection to the tracker. Calibration tables can now be stored directly in the sensor, with peak-value filtering applied as well.
Fuel monitoring systems have become more accurate and more comprehensive. Technologies now make it possible to process data in real time and immediately generate notifications about refuelings and drains, including not only conventional drains while the vehicle is stationary, but also those that happen while the vehicle is moving or equipment is operating.
At the same time, the differences between markets have become more pronounced. In some countries, fuel control remains a major issue, while in others it has become much less relevant. A colleague from Nairobi once described Dubai to me this way: “Sure, you can steal fuel — but what are you going to do with it afterward? It is almost impossible to sell, and the cost of getting caught is enormous: deportation.”
In more developed markets, meanwhile, the idea of “fuel monitoring” is expanding to electric vehicles, with a focus on battery charge, remaining range, and charging events. So while many markets started with roughly the same set of needs, those needs have become much more differentiated over time.
Arslan Rakhmatullin, Head of Technical Support at Escort Monitoring Systems
Fuel level sensors (FLS) are one of our core areas of expertise at Escort Monitoring Systems. In this segment, one of the most significant changes in recent years has been the shift from wired solutions to Bluetooth Low Energy (BLE) in the late 2010s. In some developed markets, we have noticed that wireless FLS now account for up to 80% of all FLS installations.
For installers, the practical impact was significant. With traditional wired sensors, they had to run and protect the cable between the sensor and the GPS tracker or gateway, and connect the sensor to the vehicle’s power supply – often a time-consuming job on special-purpose machinery. Self-powered BLE sensors removed both the signal cable and the connection to onboard power.
BLE also changed the approach to configuration and servicing: a separate wired configurator is no longer required, as the sensor can be accessed directly from a smartphone. This has made initial setup and field diagnostics much easier.
And the change went beyond fuel monitoring. BLE has since spread to other types of transport-monitoring sensors, including tilt sensors and temperature-and-humidity sensors. What started as a new approach to fuel-level monitoring has become a broader standard for telematics hardware.
BLE simplified a large part of the installation process, but it did not eliminate the vehicle's physical constraints. Tank geometry, access, and installation points can still turn a standard job into an engineering challenge.
The last meter still belongs to the human
– Talking about easy installation, what are the most challenging FLS installation cases you have encountered, and which of these challenges are easier to solve today?
Arslan Rakhmatullin:
Sometimes the main challenge is simply reaching the fuel tank. On some special-purpose machinery, installers may have to dismantle part of the cab to gain access to it. On buses, reaching the top of the tank can also require removing panels or creating an access opening in the floor.
Tank design can make the job even more complicated. A good example is a case involving a large tractor with an L-shaped fuel tank. Its internal geometry turned out to be more complex than could be determined from an external inspection: there was a horizontal baffle inside. During drilling, the installers went straight through it and eventually beyond the fuel tank itself, so the tank had to be removed, flushed, and repaired.
Modern calibration tools can eliminate some of the routine work. However, software cannot compensate for an incorrectly selected installation point or an unknown internal tank structure. On non-standard assets, the installer’s experience and a thorough preliminary assessment of the equipment remain critical.
Artiom Romanovskiy:
Yeah, tank designs can be the most complicated. I remember a forklift tank shaped like an inverted saddle. The first time you see something like that, your reaction is basically: “What am I supposed to do with this?”
Then you start experimenting, testing different options, and working with the installation engineer to find a combined hardware-and-software solution. At the end, one very proud engineer showed me a sensor he had bent in a vise because he was convinced it “should work.” And it did.
What is interesting is that situations like this are still solved in much the same way as they were ten years ago: with a smart, sometimes bold engineering solution, backed by proper data processing.
Even a well-installed sensor does not produce perfectly clean data in every operating condition. This is where the software layer becomes critical: it has to filter, validate, and interpret what comes from the sensor without losing useful information.
What software can fix, and what it can't
– What can software realistically improve in imperfect FLS data, and where does it reach the limits of the sensor, installation, or calibration?
Artiom Romanovskiy:
Software can do a surprising amount to improve data quality and produce reports with sufficient accuracy. We can discard error codes, extreme peaks, and zero values to remove the most obvious outliers. Then we apply and fine-tune filtering, and the graph stops looking like it was drawn by a shaking hand and becomes much smoother.
Did filtering “eat” three to five liters from every refueling or drain because of all that smoothing? We can calculate event volumes from raw data and bring those liters back into the report. We can filter out fuel-level spikes after the vehicle starts moving, refine refueling detection, configure drain detection while the vehicle is in motion, and catch cases where fuel is being siphoned through the return line. We can also compare consumption using tank and engine data, along with standard rates. Together, all of this helps the platform build a much more accurate picture and provide the data.
But there is a limit to what software can do. At some point, we run into the physical world. Water or debris in the tank can cause sensor faults and produce clearly incorrect readings. If the sensor was cut incorrectly, blind zones appear. If the tank was calibrated using only two points, the system simply does not have enough information about the tank geometry.
There are always physical conditions, sensor quality, installation, and configuration to consider. Ultimately, the result still depends on the quality of the data you start with, and then on the software you use.
Software itself can compensate for imperfect data. It cannot manufacture information that was never measured correctly.
– How has fuel-data processing in Wialon changed over the past ten years? Which changes have made the biggest difference in practice?
Artiom Romanovskiy:
The most significant upgrade was the introduction of real-time data processing. Previously, to receive a notification about a drain or refueling, the system had to process the data on a schedule, for example, once an hour, which meant there could be a delay before anyone reacted. Today, you can simply enable notifications to receive an SMS or push message about the event immediately.
Another important step was adaptive filtering. It allowed users to leave the filtering of sharp spikes and drops in fuel data to the system instead of selecting the smoothing level manually. And if you do not want to rely on automation, you can still return to manual settings. Another example is separate fuel-consumption monitoring for different engines connected to the same tank, which can be useful on special-purpose machinery with multiple engines.
- What can installers check and diagnose in an FLS today without removing the sensor?
Arslan Rakhmatullin:
One of the biggest changes is that FLS is becoming diagnosable, and a significant part of the initial diagnostic process can now be performed directly on a smartphone. For example, using the Escort Configurator, users can check the current fuel level, CNT value, temperature, battery voltage, calibration parameters, sensor settings, and the received BLE signal strength.
This significantly reduces the number of "blind" diagnostics and the number of cases in which equipment must be removed simply to identify the source of a problem. If diagnostics indicate mechanical damage to the sensor, incorrect installation, or another physical issue, however, the equipment will still need to be inspected directly.
Over time, both sides have become more capable. Sensors can now handle more of the work related to measurement quality and diagnostics, while platforms have become better at processing data in context. That makes the boundary between the device and the software less fixed than it was ten years ago.
Where should the intelligence live?
– Could more data processing be moved into the FLS itself? Where does this make practical sense, and where is it better to leave processing to the software?
Arslan Rakhmatullin:
Some processing makes sense directly at the FLS level – particularly anything related to measurement quality. This includes signal processing, filtering, temperature compensation, and monitoring the parameters that affect accuracy.
Escort’s TD-Q correction module, for example, can compensate for changes in the dielectric properties of the fuel before the data reaches the platform. Without such correction, these changes can affect the readings of a capacitive FLS.
Other tasks require the context of the entire telematics system and are better handled by software. Detecting refuelings and drains while taking vehicle movement into account, using FLS data together with GPS, CAN, and other sources, generating reports, and performing analytics all require information that an individual sensor does not have.
The roles of hardware and software, therefore, complement each other: hardware should provide reliable data at the source, while software should interpret that data in the context of a particular vehicle or the fleet as a whole.
Artiom Romanovskiy:
More realistically, hardware may eventually evolve to the point where it can detect all fuel events on its own and send software already processed data, taking into account factors such as engine operating mode, vehicle tilt, and ambient temperature.
But that is not going to happen tomorrow or the day after. Today, this kind of contextual processing still largely happens on the software side, which already makes it possible to generate accurate and detailed reports.
Ten years later, fuel monitoring is still answering many of the same questions. What has changed is how the answer is produced. Hardware has taken over more of the work around installation, measurement quality, and diagnostics; software has become better at handling imperfect data and adding vehicle and fleet context. For now, neither side replaces the other, and the boundary between them is still moving.
