Downstream Petroleum Transportation Monitoring System

Fuel moves from depots to filling stations by tanker, and some of it can go missing on the way. This project set out to track fuel during that journey.

In Nigeria, most petroleum products travel by road. Keeping track of them still depends largely on phone calls, paperwork and people on the ground, so theft, diversions and tampering are usually discovered only after the loss has happened.

Know where a tanker is and how much fuel it’s carrying throughout the journey, not just at the start and the end, so losses show up while they’re happening.

The best-known existing system tracks tankers with RFID tags, which only register when a tanker passes a reader. Between readers, nothing is known. GPS works anywhere with a view of the sky, and a sensor inside the tank can measure the fuel continuously. Together they cover the whole journey.

This was my first IoT project, and I treated it as a chance to try things out. I hadn’t worked with hardware before, so it meant learning sensors, wiring and device connectivity, alongside building the mobile side of the system in Flutter.

I based the requirements on research by my supervisor, Dr. Salisu Ibrahim Yusuf, into what makes Nigeria’s oil and gas sector adopt new technology: people take up tools they find useful, easy to use and familiar, and cost is a real barrier. That pointed to cheap, off-the-shelf parts (an Arduino and standard sensors) and to using the phone the driver already carries.

The prototype measures location and speed with a GPS module, the fuel level with an ultrasonic sensor, and temperature with a DHT11 sensor, which also feeds into the volume calculation.

An ultrasonic sensor measures distance, not fuel. It sits at the top of the tank and reads the distance down to the fuel’s surface.

To turn that into litres, I modelled the tank as a horizontal cylinder, the way a dipstick chart works. Seen end-on, the fuel’s surface cuts the circle into two parts, and the smaller one is a circular segment. Under half full, that segment is the fuel; at half full or more, it’s the empty space above the fuel, taken away from the full circle. Multiplying by the tank’s length gives the volume, and a small temperature factor then adjusts for expansion relative to 20 °C.

Decision

Send the data over Bluetooth to the driver’s phone, instead of over 4G from the device

Because

The original design put a 4G module (a SIM800L) on the device. But the driver’s phone is in the truck, a short distance from the sensors, and already has a connection. Passing the data to the phone over Bluetooth removed the need for the device to have its own, and worked around the hardware problems I had with the 4G module.

Tradeoff

The data now depends on the driver’s phone being nearby with the app running.

Decision

Stream live readings over MQTT and store them periodically in Firestore

Because

MQTT is light and made for unreliable networks, which suits a moving truck, and it let my teammates’ apps receive readings as they happen. Firestore keeps a record for later analysis.

The Flutter package for talking to the Bluetooth module, flutter_bluetooth_serial, was on GitHub, but it hadn’t been updated in a long time and its dependencies were deprecated, so it didn’t work with the Flutter environment the project required.

Rather than abandon the integration, I forked the repository and modified the package’s source code until it worked.

The project produced a working prototype. To test it, I fixed the sensors to a water-dispenser bottle standing in for the tank and moved it around on a vehicle. With about 4 litres of water in the bottle, the app read 4.3 litres.

• Bluetooth paired reliably, and data transferred steadily
• GPS coordinates were accurate once the module had a lock in open space
• Most updates reached the app in under 3 seconds, against a target of 5
• Volume estimates were generally accurate, with a slight deviation at high temperatures
• After losing power, the GPS module was slow to reconnect and sometimes needed a manual restart

The report set out what a real deployment would need: a housing to protect the sensors in a tanker, alerts for fuel loss or route deviation, end-to-end encryption, and a pilot on real fuel trucks. I didn’t take it further after the project. It had done what I wanted from it, which was to find out how hardware and software fit together.

The biggest lesson was to adapt the design to the situation instead of forcing the original plan. A 4G module looked right on paper, but Bluetooth to a phone that was already in the truck turned out simpler, cheaper and more reliable.

It also showed me how different the practical side of IoT is from the design: a GPS module that’s slow to wake up, readings that drift with heat, and a library that no longer works with the tools around it. I haven’t gone back to hardware since, but that habit of working around what the environment gives you has stayed with me.