Top 10 SCADA Systems Manufacturers for Water and Wastewater

Introduction

One of the most frequent points of failure in modern water and wastewater infrastructure is not the mechanical failure of a pump or the structural collapse of a clarifier, but the loss of visibility caused by an inadequate Supervisory Control and Data Acquisition system. A significant share of unscheduled downtime in automated treatment facilities stems from control system lockups, communication failures, or interface inefficiencies that delay operator response.

For municipal engineers and plant directors, the SCADA system is the central nervous system of the utility. It dictates how efficiently operators manage lift stations, monitor turbidity compliance, and balance distribution pressures. Yet specifications for these systems are often copied from decade-old projects, resulting in proprietary systems that lock utilities into high lifecycle costs and obsolete hardware.

This article provides an engineer-to-engineer analysis of SCADA platforms for water and wastewater. Unlike general automation guides, this discussion focuses on the specific hydraulic and regulatory demands of the water sector. From distributed telemetry networks requiring DNP3 store-and-forward capabilities to complex treatment plants necessitating high-availability redundancy, proper selection defines the operational success of the facility.

We examine the architectural differences between platforms, analyze the shift toward open standards, and provide decision matrices to help engineers specify systems that offer reliability, security, and long-term maintainability.

Two corrections to the platform list. First, AVEVA and Schneider Electric’s Geo SCADA share a corporate parent — Schneider took full ownership of AVEVA in 2023. The two products are genuinely different platforms serving different duties, so both belong on the list, but an engineer should understand they are not independent suppliers when assessing vendor concentration risk. Second, ownership of the iFIX and CIMPLICITY software line has changed following the separation of GE’s businesses; confirm current ownership and support arrangements before specifying either product.

Note also that this site carries several overlapping automation roundups. This guide sits within our coverage of SCADA system manufacturers and integrators; see also our guides to automation systems OEMs, PLC and control platform OEMs, and SCADA and HMI platform OEMs. The set is a consolidation candidate.

Editorial note: an unsourced statistic attributing a specific percentage of unscheduled downtime to control system problems has been replaced with a qualitative statement, and cost ranges that age quickly have been removed.

How to Select and Specify SCADA Platforms

Selecting a SCADA platform requires a departure from standard mechanical specification practice. While pumps are specified by head and flow, SCADA systems must be specified by data throughput, architectural openness, and disaster recovery capability.

Duty Conditions & Operating Envelope

• Tag Count and Scalability: Define the current input and output count and apply a growth factor. Some platforms excel at small systems but suffer latency issues at enterprise scale.
• Polling Frequencies: Water systems generally tolerate slower polling for remote sites compared to manufacturing, but critical process loops in filtration or chemical dosing require sub-second refresh rates.
• Network Latency: For collection systems relying on cellular or radio telemetry, the software must handle high-latency, low-bandwidth connections robustly without timing out or losing data.

Architecture & Compatibility

• Centralized vs. Distributed: Does the utility require a single server at the main plant, or independent nodes at remote facilities reporting back to a central historian?
• Protocol Support: The system must natively support water-industry protocols without expensive third-party drivers. Essential protocols include DNP3 for telemetry integrity and time-stamping, Modbus TCP, and increasingly MQTT for distributed data.
• Database Integration: Modern specifications should require SQL-native architectures where historical data is stored in non-proprietary formats to facilitate reporting and compliance auditing.

Interface Standards

The graphical interface directly impacts operator efficiency and safety. Specifications should reference ISA-101 for high-performance interface design.

• Situational Awareness: Move away from diagram-on-a-screen designs. The platform must support high-performance graphics using muted backgrounds, with color reserved to indicate abnormal conditions.
• Vector Graphics: Vector-based graphics ensure resolution independence across screen sizes, from control room video walls to tablets.

Reliability, Redundancy & Failure Modes

• Server Redundancy: Specify the type of failover required. Hot standby, meaning near-instantaneous switchover with no data loss, is standard for treatment plants.
• Device Redundancy: The software must support redundant communication paths to controllers and remote telemetry units.
• Historian Buffering: If the SCADA server goes down, local controllers or intermediate collectors must buffer data and backfill the historian once communication is restored.

Controls & Automation Interfaces

• Alarm Management: The system must support ISA-18.2 alarm management, allowing shelving, suppression, and rationalization to prevent alarm floods during upset conditions.
• Remote Access: Secure browser-based clients are preferred over legacy terminal services or thick-client installations for remote access by on-call operators.

Lifecycle Cost Drivers

• Licensing Models: Platforms vary between tag-based licensing, server-based licensing with unlimited tags, and client-based licensing. Unlimited models generally offer better long-term value for growing municipalities.
• Support & Upgrades: Evaluate the cost of annual support and the technical complexity of version upgrades. Some platforms require complete re-engineering to upgrade, while others maintain backward compatibility.

Comparison Tables

Table 1: SCADA Platform Comparative Analysis

Table 2: Application Fit Matrix

Engineer & Operator Field Notes

Commissioning & Acceptance Testing

• The Failover Test: During site acceptance, physically disconnect the network cable from the primary server. Verify that the secondary server assumes control within the specified timeframe without loss of data or operator control.
• Alarm Storm Simulation: For telemetry systems, use software tools to simulate hundreds of alarms triggering simultaneously, to verify that the server database does not freeze and that operators can still acknowledge critical safety alarms.
• Historian Backfill: Disconnect a remote telemetry unit for an hour. Reconnect it and verify that locally buffered data is automatically uploaded to the central historian.

O&M Burden & Strategy

• Patch Management: Operating system updates are a leading cause of SCADA downtime. Specify that the manufacturer or integrator must provide a validated list of patches that are safe to install on SCADA servers.
• Backup Strategy: A simple file copy is insufficient. Bare-metal backup allows total disaster recovery of the SCADA server in the event of ransomware or hardware failure.
• Integrator Dependency: Some platforms require certified integrators for changes; others are more accessible for utility staff to perform minor tag modifications. Decide which model fits your staffing before selecting.

Troubleshooting Guide

• Slow Graphics: Often caused by inefficient database queries attached to visual objects. Check whether a trend chart is attempting to load years of high-resolution data every time a page opens.
• Intermittent Communications: In radio telemetry, check retry and timeout settings. Aggressive settings will cause communication failures on functional but slow radio networks.

Design Details: Sizing and Architecture

Sizing Logic & Methodology

Engineers must calculate tag count accurately to determine licensing costs on tag-limited platforms.

Estimation guidance:

• Simple discrete device (valve or gate): roughly 5 to 10 tags covering open, closed, fault, commands, mode, run time and starts.
• Analog device (flow meter or level): roughly 5 to 8 tags covering raw value, scaled value, alarms and signal fault.
• Complex equipment (variable speed pump): 30 to 50 tags covering current, voltage, frequency, speed reference, temperature, vibration, plus the standard discrete and analog tags.

Example: A lift station with two variable speed pumps, a level transducer and a flow meter comes to roughly 80 tags for the pumps, 8 each for level and flow, and around 20 for general station status covering power, intrusion and communications — approximately 115 to 120 tags for the station.

Design margin: Multiply the calculated total by a contingency factor when purchasing tag-limited software, since scope reliably grows.

Cybersecurity Is a Statutory Requirement, Not a Feature

SCADA specifications routinely treat security as a line item under software features. For US community water systems it is neither optional nor purely technical.

America’s Water Infrastructure Act of 2018 requires community water systems serving more than 3,300 people to conduct risk and resilience assessments and to maintain emergency response plans, on a recurring five-year cycle. Those assessments explicitly cover electronic, computer and automated systems — which is to say, the SCADA system described throughout this article. Water systems are also among the critical infrastructure sectors most frequently targeted by intrusions, and the entry points are consistently the same ones a specification can close.

Four provisions belong in every SCADA specification, and they cost nothing at design stage:

• No internet-reachable SCADA servers, controllers or interfaces. State it explicitly. Equipment placed directly on a public address for the integrator’s convenience is the single most common finding in water sector intrusions.
• Remote access through logged, multi-factor authenticated connections that the utility controls — not a vendor-maintained modem or cloud tunnel the utility cannot see or revoke. Require that all remote sessions are attributable to a named individual.
• A documented asset inventory at handover, listing every device, its firmware version and its open ports. A utility cannot patch what it does not know it owns, and this list is also the starting point for the risk assessment the statute requires.
• Default credentials changed and documented before acceptance, with the integrator’s own maintenance accounts enumerated and either removed or brought under utility control at project close.

Protocol choice matters here too. Modbus TCP carries no authentication whatsoever — any device that can reach the port can issue commands. Where DNP3 is used, Secure Authentication exists but must be explicitly specified and enabled; it is not on by default.

Specification Checklist

1. Virtualization: Require the SCADA system to run in a virtualized environment to decouple software from hardware lifecycles.
2. Thin Clients: Specify thin clients for operator stations to reduce maintenance. If a station fails, the hardware is swapped and the session resumes.
3. Historical Data Ownership: Explicitly state that all historical data is the property of the owner and shall be stored in a non-proprietary format accessible via standard database drivers.

Standards & Compliance

• ISA-101: Human machine interfaces for process automation systems.
• ISA/IEC 62443: Security for industrial automation and control systems.
• AWWA M2: Instrumentation and control manual for water utilities.

Frequently Asked Questions

What is the difference between SCADA and a distributed control system in water treatment?

SCADA is generally preferred for systems covering large geographic areas and allows distributed processing where the local controller makes decisions independently if communications fail. A distributed control system is a centralized architecture typically used in complex, high-speed processing plants where the controller and interface are a single integrated ecosystem. In modern water treatment, high-end SCADA platforms paired with capable controllers have largely displaced traditional distributed control systems due to lower cost and open architecture.

How do I determine the right polling frequency for remote lift stations?

For remote lift stations, real-time data is rarely necessary. Polling every 15 to 60 seconds is typical for radio or cellular networks, to manage bandwidth costs and data collisions. However, the system should use exception reporting, where the remote unit immediately pushes data if a critical alarm occurs, bypassing the standard polling cycle. This balances data efficiency with safety.

Which platforms offer subscription licensing?

The industry is shifting toward subscription models, and most major vendors now offer them alongside perpetual licenses. Many water utilities still prefer perpetual licensing to avoid the risk of software becoming unavailable if a payment lapses or a budget cycle is delayed. Verify the specific terms offered at the time of procurement, as licensing models in this sector change frequently.

Why is store-and-forward critical for water telemetry?

Water and wastewater assets are often located in areas with poor connectivity. Store-and-forward ensures that if the communication link is lost, the local controller stores timestamped data internally and uploads the gap once the link is restored. Without this, compliance data such as effluent turbidity or flow totals would be permanently lost during outages.

How much does a typical SCADA software package cost?

Software costs vary substantially with tag count, redundancy, and client count, and licensing models in this sector change frequently enough that published figures age quickly. Obtain current quotations. The more durable planning point is the ratio: integration engineering labor typically costs several times the price of the software itself, and that is the number that governs the project budget.

What is the typical lifespan of a SCADA software version?

While the underlying controllers may last 20 years, SCADA software typically has a useful life of roughly 7 to 10 years before the operating system becomes unsupported or security risks become unmanageable. Utilities should budget for a major software upgrade or migration on that cycle to maintain cybersecurity compliance and compatibility with modern server hardware.

Conclusion

Selecting a SCADA platform is a decision that impacts a utility’s operational efficiency for decades. The industry is moving away from proprietary solutions toward open, interoperable, and secure software platforms.

For engineers, the goal is to specify a system that balances the reliability required for public health with the flexibility needed for future integration. By prioritizing open standards, verifying protocol support, and conducting rigorous lifecycle cost analyses, utilities can implement SCADA infrastructures that serve as operational tools rather than maintenance liabilities.