The 5 mistakes we see most often in SCADA projects

A SCADA project is not technically hard; it takes discipline. Over the years, the mistakes we have seen at different plants have been surprisingly alike. What follows came out of the rules we set ourselves while building the SCADA for a water treatment plant.

We have seen projects where a plant with 400 signals puts all 400 on the main screen. The operator sees none of them. The main screen should show the state of the process and whatever needs action at that moment; detail sits one click below. In the water treatment project the main screen shows the state of the pumps and basins; flow curves and motor currents are on a separate page. What shortened the operator’s response time was not more information, but less.

If alarms are not prioritised, they all go off at once and the operator silences the lot. A week later the alarm screen is a list nobody looks at. We design alarms with priority, delay and grouping logic: a pump failure is red and audible; a level warning is yellow; informational ones only go to the log. If an alarm has no answer to “what exactly will the operator do when this goes off?”, it doesn’t make the list.

If statutory and corporate reports are typed into Excel by hand, you are producing both errors and hours of extra work. Reporting is SCADA’s job: daily, per-shift and monthly reports should run on a schedule and, where needed, go out by email. At the water treatment plant, fully automatic statutory reporting became the part of the project the operators valued most, more than the screens.

Pumps make up a large share of a plant’s energy bill. If the SCADA only does start/stop, an opportunity is lost. Logic that runs pump groups in rotation and efficiently, according to level, demand and tariff, is a few days’ work in software, and a lasting difference on the bill. We see it not as an “extra feature” of SCADA but as its core.

If the SCADA server is a single machine, one day that machine will fail. Historical data, recipes and alarm history go with it. Server redundancy, database backups and separating the OT network from the IT network should be written into the project scope on day one. The same goes for the IP plan: every hour spent on site asking “what was this device’s IP again?” is the most expensive hour of the project.