Multi-Site Pump Station SCADA: Designing a Station Template That Actually Replicates

Five places where replication turns into rework

Once the first station is finished, teams usually assume the method is proven and everything after that is repetition. From station two onward, though, the repetition shows up in a different form: what gets duplicated is not the installation work but the engineering and configuration effort.

List the rework points one by one and they all trace back to the same cause — the output of the first station was never turned into an asset you can pick up and apply on the next site.

• Screens redrawn per station: station types are similar but each process screen is built separately, so aligning one display convention later means editing every station by hand
• Tag naming is not unified: the running status of the same pump is named differently at each site, and fleet-wide roll-ups depend on a mapping table maintained manually
• Alarms defined station by station: the same level excursion carries different priorities, delay times and reset handling at each site, so alarms arriving in the control room cannot be compared across stations
• Permissions and accounts scattered: each station keeps its own local user list, nobody cleans it up after staff transfers, and during an incident review the operator can no longer be traced
• Every new station starts from scratch: the equipment list, register addresses and communication parameters are compiled again each time, and the gateway is configured manually on site

None of the five is a technical obstacle; they are questions of how the engineering work is organised. The direction is equally clear: break the first station's deliverables into inheritable artefacts so that station N starts from replication rather than from design.

The replication pipeline: station template → address table export → gateway onboarding → platform aggregation → alarm and permission inheritance

A replicable approach splits the delivery of a single station into five stages, each producing an artefact the next site can use directly. The output of one stage becomes the input of the next, and manual re-keying in between disappears.

The engineering assets we have accumulated along this chain include a standard pump-group supervision template for a single station (process screens, alarm rationalisation, reports), a gateway with a built-in web configuration page that exports the device address table in one click, ModbusTCP collection paired with dual-channel MQTT/REST cloud delivery, and a certificate scheme covering gateway, client and self-signed certificates.

• Standard station template: one set of process screens, alarm definitions and report layouts per station type (lift station, wastewater station, booster station), with differences inside a type absorbed by parameters instead of screen edits
• Address table export: the equipment list and register addresses are maintained on the gateway's built-in web configuration page and exported in one click, and that table becomes the single input shared by the SCADA side and the platform side
• Gateway onboarding: field devices collected over ModbusTCP, delivered to the cloud over dual MQTT/REST channels with certificate-based channel security; during a network outage data is buffered locally and backfilled automatically once the link recovers
• Platform aggregation: station data enters the platform under one naming convention, so fleet roll-up screens and the historian reuse the same tag structure and adding a station does not change the data model
• Alarm and permission inheritance: priority tiers, suppression rules, reset-and-archive handling and the role permission matrix are inherited from the template, so a new station goes live already carrying a rationalised alarm definition

Which stages deserve standardisation, and what skipping it costs

Deciding whether a stage needs a standard takes one question: at station N, will this work have to be done from scratch again? If the answer is yes, the stage belongs in a template.

Three-dimensional process rendering can be templated the same way: one set each for the aerial, process and security views per station type, so a new site only needs the model and tag bindings swapped rather than the scene rebuilt.

Four things the control room has to design up front

Half of the difficulty in a multi-site programme sits on the control room side. If these four items are left until every station is already connected, the cost of change rises noticeably, because each of them forces configuration changes back at the sites.

• Fleet roll-up screen: define first what the dispatcher sees on a single screen — running and stopped status per station, key levels and flows, communication health — and only then decide how that screen drills down into an individual station's process display
• Alarm grouping and shift handover: when several stations report at once, group by site, priority and type so the list does not flood; unacknowledged alarms and response records must travel with the shift change, and multi-channel push notifications should be split by priority and time of day
• Historical retention policy: which tags are stored at second resolution, which are archived by the minute, how long they are kept and where they go once the period expires — all decided before the database is built, because changing it after the site count grows is expensive
• Backfill for stations that lose connectivity: the gateway buffers locally and forwards after the link recovers, while the platform has to accept out-of-order writes without leaving gaps in historical trends, with report figures recalculated on the completed data

Once these four are settled, adding a station is mostly configuration work rather than a redesign of the control room. Conversely, if control room screens and alarm rules keep changing as the site count grows, the upstream design has not converged yet.

What a template reduces, and what it cannot replace

First, the boundary of what has been delivered. The confirmed field scope is a single pump station: IoT gateway onboarding, ModbusTCP data collection, MQTT cloud delivery and address table planning. Multi-site standard templates, group supervision screens and fleet aggregation are engineering assets and solution capabilities — they do not mean deployment has already been completed across several cities. The two should not be conflated.

What a template reduces is repeated design: screens, alarm definitions, report structures and tag naming, the parts that are nearly identical within one station type. What a template cannot replace is interface verification at each site — whether legacy equipment still has a usable communication port, whether the actual protocol and register map match the drawings, whether power and network conditions are adequate. That has to be confirmed station by station.

Delivery schedule and cost for a specific site therefore have to be assessed against interface conditions, site conditions and acceptance scope, not estimated by dividing the first station's schedule by the number of sites. The same holds for alarm engineering effort: we have carried out priority tiering, reset-and-archive handling and event management on a large project of nearly 30000 alarm points, and that method carries over to a multi-site setting, but each station's alarm list still has to be re-checked against its actual process.