Best Practices for Using SCADA Systems in Small to Medium Treatment Plants
Supervisory control and data acquisition platforms have moved from being optional luxuries to everyday necessities at treatment works serving coastal suburbs, inland towns and outer metropolitan catchments. In Australia, where Water Services Association of Australia members operate more than 600 sewage treatment plants between them, the gap between paper log sheets and a fully networked control system is closing as budgets allow and standards tighten. Smaller facilities in places like Warrnambool, Albany or Cairns are now expected to deliver the same compliance evidence as their metropolitan cousins in Sydney or Brisbane.
Small to medium treatment plants carry their own peculiar pressures. Operators often cover multiple sites, rosters are tight, and the engineering support a major utility can afford is not always on hand. A well planned SCADA system can lift a lean crew out of reactive firefighting, yet only when it is designed with realistic staffing, reliable communications and maintainable hardware in mind. Peer networks, including the committee that coordinates technical presentations across the water sector, show how shared lessons shorten the learning curve for everyone.
Matching SCADA Architecture to Plant Scale and Complexity
A common temptation is to scale down a major utility's design by simply removing features, yet the discipline should run the other way. A small membrane bioreactor outside Geelong handling under five megalitres a day does not need the same redundant server pair as Melbourne Water's Western Treatment Plant, but it still benefits from the same logical separation between the process network and any business or public facing layer. Architecting around a single server with virtualised redundancy, a managed network switch and a clearly defined remote access path keeps capital costs in line while leaving room to grow.
Medium plants typically sit between five and fifty megalitres a day and often blend older RTUs with modern PLCs. For this class, a tiered server approach with a primary and hot standby historian, paired with segregated engineering and operations VLANs, pays dividends during outage events. Choosing an architecture that reflects actual staffing levels matters more than ticking boxes on a vendor brochure.
Building a Clean, Sustainable Tag Database and HMI
The heart of any supervisory system is its tag database, and the discipline that goes into naming, grouping and documenting tags determines whether the platform will be a daily aid or a constant source of frustration. A consistent prefix convention such as site code, process area and instrument function lets a relief operator at three in the morning find the right value without guesswork. Standardised engineering units, alarm limits and equipment hierarchies should be agreed before any HMI screen is drawn.
Mimic screens that mirror the physical flow of the plant rather than the controller's internal structure help new operators settle in quickly. Investing time in high resolution process graphics, clear colour conventions and trend overlays reduces the cognitive load during incidents. Photographs of recent site upgrades, such as those shared in the gallery of completed projects, are a useful reality test of intended mimic layouts.
Alarm Management That Operators Actually Trust
Alarm floods remain the single most common complaint from operators on shift, and the cure is a written alarm philosophy that ranks events by consequence and time criticality. The ISA 18.2 approach and the equivalent IEC 62682 framework work just as well for a ten thousand EP plant in Bendigo as for a major Sydney Water facility. Each alarm should have a defined operator response, an associated priority and a documented rationalisation review at least once a year.
Shelving nuisance alarms during planned maintenance, suppressing duplicates and routing high priority events directly to pagers or mobile devices helps maintain attention. Operators should be encouraged to log bad alarms without fear of blame, and the resulting data should feed a continuous improvement loop rather than gather dust in a shared drive.
Cybersecurity for Operational Technology Networks
Operational technology used to be isolated by geography, yet that is no longer the case in Australia. Remote access for vendors, integration with corporate email for reporting and the proliferation of IIoT sensors mean the air gap is essentially gone. A defence in depth model with network segmentation, managed switches, role based access control and carefully controlled vendor jump hosts is now the baseline expectation, even for a modest treatment works.
Regular patching of workstations, multifactor authentication on remote sessions and removal of default credentials on PLCs and RTUs address the everyday entry points attackers exploit. SA Water and TasWater have both published guidance that smaller councils can adapt without paying for bespoke consulting. Logging and monitoring of the OT network, even with modest open source stacks, provides early warning when something unusual begins to happen.
| Aspect | Small plant under 5 ML/day | Medium plant 5 to 50 ML/day |
|---|---|---|
| Server architecture | Single server with virtualised redundancy | Primary plus hot standby historian |
| Network design | Flat with managed switch, clear VLANs | Segmented OT network, separate engineering VLAN |
| Remote access | Single managed jump host with MFA | Role based access for vendors and corporate |
| Alarm philosophy | Documented, simple priority tiers | Full ISA 18.2 rationalisation programme |
| Operator coverage | Often multi-site, fewer than four per shift | Dedicated shift plus day support |
| Documentation depth | Site specific operating manual | Layered engineering and operating manual |
| Cybersecurity tooling | Layered MFA and patching routine | SOC style monitoring, optional SIEM |
| Spares holdings | Critical spares on the shelf | Spares plus swap out repair contract |
Telemetry and Communication with Remote Sites
Many Australian plants operate across wide catchments, with pump stations and reuse schemes strung out over dozens of kilometres. Cellular 4G and 5G, private LTE, licensed microwave and even satellite backhaul are all in use, each with its own latency, cost and resilience profile. Selecting the right media comes down to redundancy requirements, terrain and the criticality of the controlled process. A sewage transfer pump on the outskirts of Perth may tolerate a brief outage, while a UV channel at a drinking water facility cannot.
Standardising on a small set of telemetry protocols, polling intervals and heartbeat checks makes the wider network easier to diagnose. When the same RTU firmware runs from Kwinana to Lismore, field technicians only need to carry one set of spares and one mental model. Keeping a radio path test on a routine schedule catches tree growth and new building obstructions before they cause a fault.
Lifecycle Planning, Spares and Documentation
Hardware and software lifecycles in operational technology environments typically run between seven and fifteen years, longer than in corporate IT. A written lifecycle register, refreshed each year, lets asset owners budget for controller replacements and operating system upgrades rather than scrambling when a vendor declares a product end of life. Holding critical spares such as power supplies, communication modules and a spare PLC rack is a small insurance policy against the kind of supply chain delays seen across Australia in recent years.
Documentation is the unglamorous backbone of any reliable system. Network diagrams, control narratives and I/O lists should live in a version controlled repository, not on a personal drive. Walking through the documentation with operators after every significant change builds a shared understanding that pays off the next time an unfamiliar alarm has to be interpreted under pressure.
Training Operators and Building Institutional Knowledge
A control system is only as capable as the people using it, and operator competency deserves the same attention as the hardware itself. Structured induction programmes, regular simulator sessions covering both routine and upset conditions, and a buddy system for new starters build a confident team. WSAA aligned competency frameworks provide a useful scaffold, particularly when combined with on-site demonstration days hosted by neighbouring utilities.
Encouraging operators to attend technical presentations, vendor demonstrations and community events keeps their skills current and reconnects lapsed practice with new ideas. Recognition programmes, awards banquets and peer events all play a quiet role in retaining experienced staff, which in turn protects the institutional memory that keeps a SCADA platform healthy long after the original integrator has moved on.
A well designed supervisory control and data acquisition platform pays for itself many times over when it is matched to plant scale, documented with care and operated by people who understand both the screens in front of them and the biology underneath. The most reliable sites in Australia tend to be those that treat the system as a long term operational asset, plan for its renewal and invest steadily in the people who depend on it every shift.