Tank Monitoring and Fuel Dispatch Platforms

Summary

We build tank monitoring and fuel dispatch platforms for bulk suppliers who keep tanks full at the sites they serve without being asked. The software answers two questions continuously: which tanks will run dry soonest, and which truck, driver, and product combination should serve them today. Gauge readings and vehicle telemetry are turned into a ranked work list, which a dispatcher can then approve, reorder, or override.

The Challenge

Volume is not a simple number. Gauges report height, which becomes volume through a strapping table specific to the tank shell, and volume varies with temperature, so gross and net volumes differ and the reporting layer must be explicit about which one it shows. Getting this wrong produces a forecast that drifts with the weather.

Readings arrive irregularly, sometimes hourly and often less, with gaps whenever a device is out of coverage. A tank whose telemetry has gone stale is a distinct state from a tank that is full, and stale data presented as fresh is the failure that matters most. Deliveries have to be detected and excluded from the burn calculation, otherwise a refill reads as negative consumption and corrupts the fit. Every upstream source imposes its own limits worth designing around: rate caps, pagination, eventual consistency after a write, and metered mapping calls. And a ranking model never sees the road closure or the phone call from a site, so it must produce a proposal rather than a command.

The Solution

Domain model

The model starts with a site, its tanks, and the product grade each tank holds. A tank record carries nominal capacity, safe fill capacity, the reorder threshold, and the delivery agreement type, since a keep-full arrangement and an on-request account produce completely different urgency. Readings are stored as a time series, with the raw reading kept alongside the derived value so a later correction to a conversion factor can be replayed rather than lost.

Integrations and data flow

• Automatic tank gauges and telemetry units supply level readings
• A fleet and back-office system supplies order, inventory, pricing, and account data that a delivery posts against
• A telematics provider supplies vehicle position, engine and odometer data, and hours-of-service status
• A mapping service supplies geocoding, travel time, and route distance

The pattern is to pull on a schedule where a source has no push mechanism, subscribe to webhooks where it does, and keep an ingestion log that supports backfill after an outage. Travel times between stable site pairs are cached rather than recomputed on every dashboard refresh.

Forecasting and dispatch logic

Days-to-empty is estimated from a consumption rate fitted over a recent window, adjusted for known seasonality and for site-specific patterns such as operating only on business days. Dispatch suggestions rank candidate stops by urgency, then filter by feasibility:

• Compartment capacity and current load on the truck
• Product compatibility, so grades are not cross-contaminated
• Driver qualification and endorsements for the cargo
• Remaining legal driving hours
• Site access windows

Administrators review, amend, and approve the result.

How we build it

We build the ingestion and normalization layer first and run it against historical readings, which exposes sensor drift and unit inconsistencies before any interface exists. Forecast logic is then validated by backtesting against known past deliveries. The dashboard and map view come last, filtered by account, product, refuel status, and days remaining. Reading age is surfaced everywhere a level is shown, time zones are handled explicitly across sites and drivers, ingestion is made idempotent so a replayed batch does not duplicate readings, and an audit trail records who approved or changed a dispatch.

What This Delivers

Dispatchers work from a ranked, feasible list instead of a spreadsheet and a phone, dry-out risk becomes visible before it becomes an emergency call, and routing decisions account for the load, the grade, the driver, and the site window at the same time. Because readings are normalized behind a single interface, additional telemetry vendors can be added without disturbing forecasting or dispatch.

Technologies and Tools

Automatic tank gauge and telemetry feeds, telematics provider APIs, fleet and back-office system APIs, a mapping and routing service for geocoding and travel time, a time-series store for readings alongside a relational model for sites, tanks, and deliveries, scheduled pull and webhook ingestion with a replayable ingestion log, and a filterable web dashboard with map view.