Fleet Fueling Management System for a Top-5 U.S. Metro: Case Study
❓ What was breaking in the city's fueling operation before this project?
The city was running a legacy fueling system that had accumulated years of unindexed transaction data. At the scale of 130,000 fueling events per quarter, that accumulation made the system progressively slower until daily delays became routine. Terminals timed out. Transactions failed to log accurately. Fuel dispensed did not always match what the database recorded, which created billing discrepancies and exposed the city to audit risk.
The underlying security architecture compounded the problem. Every time a vehicle was added, a fuel allowance changed, or a site was edited, the system retransmitted the entire vehicle whitelist to all sites. Unencrypted. In full. Across cellular connections. Data costs were high, the sync traffic was redundant, and the exposure was real. There was no dashboard showing tank levels or system health across the network. Each site operated in isolation.
For a fleet this size, these were not inconveniences. Emergency responders, sanitation crews, and transportation vehicles all depend on fueling access around the clock. A system that crashes or loses transaction data is a liability problem, not just an IT problem.
🛠️ What did PCG actually build, and how does it work?
PCG engineered the platform in .NET Core from the ground up. The architecture handles three things simultaneously: ruggedized hardware integration at each pump, encrypted real-time communication between sites and the central server, and a centralized dashboard that shows the entire operation at once. Each layer was designed so that a failure in any one does not take down the others.
PCG built RFID vehicle identification directly into the terminal, with manual scan keys for backup authentication. Coil ring sensors verify nozzle engagement before dispensing can occur. The hardware is weather-resistant and designed for 24/7 outdoor use at unmanned fueling stations.
Standard AES-256 encryption increases payload size. PCG developed a dual-layer protocol that compresses and encrypts simultaneously, reducing payload sizes by 50-60% before transmission. The city's cellular data costs dropped 80% as a direct result. This was not an off-the-shelf approach. It required custom engineering specifically for this problem.
The old system retransmitted the entire vehicle whitelist on every change. PCG replaced that with delta sync: only what changed gets transmitted, compressed, and encrypted. A single vehicle update no longer triggers a citywide data event.
Each site can operate independently if the network goes down. Transactions queue locally and sync automatically when connectivity restores. No fueling operations lost. No manual reconciliation required afterward.
Access is controlled by department, user, vehicle, and site. The central dashboard shows real-time tank levels via Veeder Root integration, live system health, and fueling activity across all 65 locations. What previously required manual site visits to check is now visible from a single screen.
The data cost problem was not primarily a network problem. It was a protocol design problem. The city was paying cellular rates on redundant full-whitelist transmissions that could have been eliminated with delta sync from the start. Security and efficiency are usually treated as trade-offs. On this project, the compression-encryption layer made both better at the same time.
Fleet fueling systems fail quietly before they fail visibly. Transaction logging errors accumulate in the background for months before an audit surfaces them. The diagnostic work at the start of this engagement found data discrepancies that predated the visible crash symptoms by over a year.
🚀 What changed after the new system went live?
The most immediate change was operational stability. A system that had been crashing daily ran at 99.5% uptime from deployment forward. The 300% improvement in transaction speed was measurable at the terminal level within the first week.
| Outcome | Result | How it was achieved |
|---|---|---|
| System uptime | 99.5% | Standalone site mode, offline queuing, performance-optimized SQL |
| Transaction speed | 300% faster | Indexed SQL, optimized data flow, high-efficiency query architecture |
| Cellular data costs | 80% reduction | Proprietary compression-encryption + delta sync replaced full whitelist retransmission |
| Fuel theft and misuse | Effectively eliminated | RFID authentication, AES-256 encryption, real-time audit logs, per-vehicle fuel limits |
| Departmental billing accuracy | 100% transaction attribution | Every fueling event linked to department, vehicle, and user at point of transaction |
| Tank monitoring | Real-time across all 65 sites | Full Veeder Root integration replaced manual site-by-site retrieval |
The financial impact extended beyond data cost reduction. Real-time audit logs with encrypted user validation eliminated the fuel theft and misuse that had been difficult to quantify under the old system. The city recovered the cost of the project in the first year through a combination of direct theft prevention and accurate departmental billing that replaced a system of estimated allocations.
💰 Financial and operational benefits
The performance numbers are the visible part. The financial impact runs deeper, across three areas that the old system had no way to measure or prevent.
Real-time auditing, encrypted user validation, and per-vehicle fuel limits eliminated theft and misuse that had been accumulating undetected. The city recovered hundreds of thousands of dollars annually once every transaction was tied to a verified user and vehicle at the moment of dispensing.
Every fueling event is now attributed to the correct department, vehicle, and user at the point of transaction. The estimated allocations that had generated billing disputes across 50+ city departments were replaced with usage-based records that hold up to audit review without reconciliation work.
Fuel consumption patterns surfaced vehicles consuming significantly more than their fleet class average. That data fed directly into maintenance scheduling and replacement planning, reducing the time between a performance problem appearing and a decision being made about it.
The proprietary compression-encryption protocol cut cellular transmission costs by 80%. For a 65-site operation running continuous sync across a cellular network, that reduction is a recurring annual saving, not a one-time gain. The protocol paid for its own development cost within the first operating year.
💡 Does this apply if your fleet is smaller than a top-5 metro operation?
The architecture scales down as well as up. A municipal fleet running 500 vehicles across 8 sites faces the same core problems: authentication gaps, inaccurate transaction logging, data that is difficult to audit, and hardware that fails in outdoor environments. The engineering decisions on this project, particularly the standalone site mode and the delta sync model, are directly applicable to operations an order of magnitude smaller.
What makes this project transferable is not the scale. It is the problem class. Any operation where fuel is dispensed without real-time verification and logging is carrying risk that accumulates invisibly until an audit, an investigation, or a budget review forces the question. By that point, years of discrepancies are on the table.
PCG has built fueling systems for municipal operators since before most of the platforms now marketed as fleet management solutions existed. The work documented here is not a proof of concept. It is a production system managing one of the largest municipal fleets in the country, running continuously since deployment.
🔍 Technology stack
| Component | Technology |
|---|---|
| Frontend | ASP.NET Razor, Bootstrap |
| Backend | .NET Core, Entity Framework, LINQ |
| APIs | RESTful JSON APIs, JWT authentication, HTTPS |
| Security | AES-256 encryption, client certificates, RBAC |
| Networking | Encrypted TCP socket services, proprietary compression-encryption protocol |
| Database | SQL Server with partitioning, replication, and indexing |
| Hardware | RFID boards, manual scan keys, coil ring sensors |
| Hosting | On-premise Windows Server cluster with redundancy |
Frequently asked questions about custom fleet fueling software
Allison has been building custom software since the early 1980s, including work as a data analyst for the U.S. Air Force before founding PCG in 1995. The fleet fueling work documented here is one of more than 500 custom applications PCG has delivered across municipal operations, industrial safety, healthcare staffing, and environmental compliance. Her direct involvement in every project is not a policy. It is how PCG operates. When you call, she answers.
All performance metrics cited in this case study are drawn from PCG's internal project documentation for this engagement.
PCG founded 1995. Allison Woolbert's personal experience in software development predates PCG's founding.