ARM Edge Hardware for District Heating & CHP Networks 2026 — Substation Monitoring, Heat Meters & Leak Detection

A district heating network is a strange piece of infrastructure to instrument. Unlike a factory, which is one site, a heat network is a city: hot water leaves a combined-heat-and-power plant or a heat-only boiler house, travels through insulated mains, and fans out into hundreds of district and building substations where heat exchangers deliver energy to each customer. The physical asset is enormous and distributed, the data volume is tiny, and the value sits almost entirely in what can be inferred from a few temperatures, flows and pressures read at each node.

This is a case where the hardware choice is governed by quantity and environment rather than by bandwidth. There may be hundreds or thousands of substations, most of them are in a kiosk outdoors, and the useful computation at each one is modest. That combination points toward a small, low-power, network-attached controller at the substation and a real computer only at the plant and the control room. This guide covers the network as a distributed compute problem, the workloads worth running at the substation, and the specification rules that decide whether a kiosk controller survives a decade of city winters.

The Network as a Distributed Compute Problem

Heat networks have a natural three-tier architecture, and the compute tiers follow the water. The plant already has a DCS or SCADA that owns generation; the substations are the many cheap nodes; the control room owns analytics and billing. The mistake to avoid is treating the substations as miniature data centres. What each one needs is enough compute to read its meters, close a local weather-compensation loop, detect local anomalies and forward a small result.

The arithmetic is what makes this tiering obvious. A heat meter reports a handful of registers — energy, volume, forward and return temperature, flow, instantaneous power. Even sampled once a minute that is a few kilobytes per substation per day, so a thousand substations produce well under a megabyte a day of genuinely useful telemetry. No link in the city needs to be fast; the hard problems are coverage, power and the environment, which is precisely the profile an ARM-class gateway solves well.

The Workloads and Where the Compute Sits

A heat network produces slow data everywhere and fast data almost nowhere, which is the opposite of a factory floor. Nothing on a district heating substation needs microsecond latency, so the compute can be small and cheap — but it must be reliable, remotely manageable and present at every node.

The clearest case where the network's own structure decides the design is leak detection, which is largely a communication and coverage problem rather than a sensor-quality one. A heat network loses water through many small faults, and a burst appears as an imbalance between the flow into a district-metered area and the flow out. Seen at one substation that imbalance is noise; seen across a zone with synchronised timestamps it is a signal. The hardware requirement that follows is not more compute, it is a reliable communications path and a common clock across the zone so the balance can actually be computed. This is why IEEE 1588 PTP or a disciplined time source matters even on a network whose data rates are trivial.

It is equally important to say where this must not sit. Substation control and leak detection are seconds-to-minutes decisions, not real-time control. The genuinely fast and safety-critical functions — pressure-relief, temperature limits, electrical protection and any customer-safety interlock — belong in local protection and the plant DCS, not in an IP-connected gateway. The correct relationship is one-way: the gateway reads, judges locally and reports, and never closes a safety function across a WAN.

Selection Rules for a District Heating Kiosk

Sizing the hardware is mostly a matter of refusing to compromise on the environment and on remote manageability, because hundreds of nodes mean a truck roll for every failure. The table below lists the specifications worth writing into a purchase order.

• Put cheap, reliable compute at every substation; keep the real computers at the plant and the control room.
• Read standard meters — EN 1434 / EN 13757 M-Bus — rather than locking the design to one meter vendor's protocol.
• Close the weather-compensation loop locally so comfort does not depend on a WAN link staying up.
• Treat leak detection as a coverage and clock problem: synchronise timestamps across a zone before buying more compute.
• Keep pressure-relief, temperature limits and electrical protection in local protection; never close a safety function over the network.
• Specify remote management and signed updates up front, because a fleet of hundreds means every failure is a truck roll.
• Design for a kiosk with no HVAC: wide temperature, condensation control and surge protection are the reliability budget.
• Size storage for local buffering through an outage, so a communications gap does not become a billing gap.

QSCompute supplies the compute and storage that sit behind the instruments: compact, wide-temperature ARM gateways and embedded controllers for substation kiosks, M-Bus and Modbus interfaces, edge nodes for larger plant rooms, and power-loss-protected industrial storage for local buffering. Send us the network layout, the meter and sensor list and the reading intervals, and we will size the node that fits each tier of the network.