Case Study · Utilities / Industrial IoT
Eight Years Running a City's Heating Estate
A back-office platform for a municipal district-heating utility: every building it heats, every meter, every reading, every job outstanding.
- 8yrs in production since the 2018 rebuild, still running
- 5,600 residential buildings managed on one platform
- 2 meter protocol generations behind one interface
The Client
A municipal district-heating utility. Every building on its network carries a heat meter that must be read, verified and serviced.
Three teams share the platform: metering, dispatch and billing. Each works on its own slice of the same estate.
The Challenge
- Two generations of meters. Older and newer meters answer different versions of the vendor protocol, and both must keep working.
- Slow, unreliable links. A meter on a GSM connection can take minutes to answer, or never answer at all.
- An estate that changes. Meters get swapped at an address, and their history has to survive the swap.
- A legal schedule. Metrological verification of every meter is a regulatory obligation with deadlines.
What We Built
Heat meters in the field answer the way they were built to. The software above them never needs to know the difference.
Device polling
Heat meters are read directly over raw TCP/IP, behind one connection interface, so no survey code ever touches a socket.
One interface, two protocols
Each protocol generation has its own survey and connection services. Nothing above that layer knows which one it is talking to.
Two survey modes
Instantaneous surveys read a meter's current state; archive surveys pull its stored history. Both run as queued jobs.
An estate model
Heat meters, calculators and temperature sensors are each a type plus an installed instance, so a swapped meter keeps its history.
Verification on schedule
Executors and full verification history are tracked per unit, not in a spreadsheet.
An operations CRM
Work orders with status history and notes, complaints, and role-scoped access for metering, dispatch and billing.
Technical Highlights
-
01
A physical estate in software
Every device is modelled as a type plus an installed instance, so a meter swapped at an address keeps its history.
-
02
Two protocol generations, one interface
Older and newer meters coexist in the field. The survey layer is written once.
-
03
Reads that cannot block
Device surveys are queued jobs, so a meter on a slow GSM link never holds up a request.
-
04
Regulated by schedule
Verification deadlines, executors and per-unit history live in the platform.
-
05
Role-scoped by department
Metering, dispatch and billing each see their own slice of one estate, enforced in the model layer.
Eight Years
Our principal built the platform from its first commit in 2018. Our team maintains it today.
The platform was rebuilt in 2018, and that rebuild has needed no rewrite since.
Built on Laravel 5.6 in 2018 and still on it.
What this client needed was a platform that keeps running, not one that keeps changing.
Results
- In production continuously since 2018, and still maintained
- Heat meters polled directly over TCP/IP across two protocol generations
- Metrological verification tracked to schedule rather than by spreadsheet
- Role-scoped access for three departments on one estate model
- Rebuilt in 2018, with no rewrite needed since
Running something that has to keep running?
Old stack, live devices, a team that needs it working tomorrow. In 30 minutes we will outline our approach.