Water utilities face many challenges, whether it is pressures to adopt new technologies with shrinking resources, aging infrastructure or obsolete technology. To succeed in this environment, a utility’s approach to their Supervisory Control and Data Acquisition (SCADA) system is critical.
The conventional thinking about SCADA is that the technology is a closed system that will be used for 15 to 20 years until it needs to be replaced, said Kent Melville, sales engineering manager at Inductive Automation. Requirements inevitably change, however, and utilities often look for short-term, budget-friendly fixes. This can lead to haphazard add-on technologies and hardware from multiple vendors, often resulting in expensive, long-term consequences.
“What might have been a really fast, cohesive system at the beginning, by the end is so convoluted with all this different hardware that it's impossible to maintain,” Melville said. The utility then needs to replace the SCADA system, and the process starts over again.
Instead of using a rip-and-replace approach with short-term solutions in between, Melville recommends a sustainable architecture that enables the SCADA systems to adapt and grow over time. Through the five incremental steps below, utilities can save time and money while improving uptime and reliability.
Step 1: Collecting data from remote sites more efficiently
The first step toward a more sustainable SCADA system is to set a standard protocol for PLCs. By choosing equipment that supports a certain protocol, everything can speak the same protocol, and software can swap in more easily. To ensure flexibility, Melville recommends an open protocol like OPC, MQTT or Modbus, rather than a proprietary protocol.
In addition to choosing a new standard protocol, address issues like bandwidth, latency, and connection that can impact data collection from remote sites. Melville strongly recommends installing edge devices at remote sites to poll locally and report by exception. That way, data is not lost when the network goes down, because it can buffer data that is polling locally.
Step 2: Saving time and money with a server-centric architecture
A sustainable SCADA system should have a server-centric architecture, Melville said. Rather than maintaining many installs across many machines, a server-centric system only requires that software be installed on a centralized server. Since all data collection and visualization go through that server, it is a single point of failure, so redundancy is key to maintain uptime in the event of a server failure.
A big feature of server-centric architecture is the licensing possibilities they present, with the system being licensed by the server and unlimited for everything else. There are currently multiple options for SCADA systems that are licensed by the server. Melville recommends you speak with your SCADA provider to get a system that will meet specific sizing needs.
Step 3: Avoiding upgrade headaches with cross-platform SCADA
Traditional SCADA systems that are tied to specific operating systems can cause challenges for utilities when these versions reach their eventual end of life and force organizations to make costly upgrades.
To avoid this issue, Melville recommends leveraging a SCADA system that is fully cross-platform. The system can then run on Linux, Mac or on any version of Windows. “In a sustainable SCADA architecture, the OS and the SCADA should both be able to be upgraded independently,” Melville said.
To achieve this, Melville said, leverage newer versions of .NET, Java or other programming languages that are cross-platform out of the gate. “Then they’re running in a virtualized environment on the computer rather than running directly against the iOS,” he said. “With each version of the iOS that comes out, they’re already doing testing on their side to make sure that the virtualized environment is still consistent and compatible with the programming language that’s being used behind the scenes. Since it’s running against the virtualized environment rather than the actual OLS, now you’ve got some more flexibility, and so things don’t break as much.”
Step 4: Getting more data with IIoT
The Industrial Internet of Things (IIoT) is all about how you get your data. Getting large amounts of data from remote sites connected over radio, satellite or cellular requires a lightweight protocol. That’s where MQTT comes in, Melville said.
By using edge devices, the system can publish data with MQTT, an ultralight protocol that has only a two-byte overhead. MQTT is very secure and uses a pub/sub protocol that publishes by exception. It also uses the Sparkplug specification for store-and-forward and auto-discovery of tags.
Centrally it requires an MQTT broker, where data is published and then line-of-business applications (including SCADA) can subscribe to it. The result is really powerful, Melville said, since you can decouple your data backbone from your applications.
“If your SCADA system gets replaced, gets swapped out, or any other application gets swapped out, you didn't break your chain of that data backbone, because you once again decoupled your infrastructure from your applications,” Melville said.
Step 5: Sustaining your system with alarming and reporting tools
A sustainable SCADA approach requires a quick response when something goes wrong. The best notification is a text message or phone call, since staff can be notified immediately whether they are on-site or at home. Melville also recommends an alarm pipeline that elevates notifications if alarms are not responded to in a specific timeframe.
Reporting efficiency is also an important key. Many organizations still utilize manual reporting of data, which can be rife with human error, Melville said.
Automatic reporting reduces errors and allows you to receive reports immediately, saving time. Organizations can still perform manual checks to ensure the machines are collecting data correctly. However, if an organization chooses this path, Melville recommends having staff use a tablet where they can directly input data into the system instead of writing information down and transferring the information to reduce the number of steps in the process.