The short answer
What a Small Utility Should Ask Before Buying SCADA
Before buying SCADA, a small utility should ask who will maintain it at two in the morning, what the licensing costs in year ten, whether the history and configuration can be exported, how it fails over, how operators reach it from home securely, and what leaving it would take. Feature lists all look alike; those six answers separate a system the utility runs from a system that runs the utility.
Key points
- Buy the system your staff and your local integrators can maintain, not the one with the longest feature list.
- Model the licensing over the life of the system, including the second server, the clients, and the tags you will add.
- Insist on data portability: history and configuration exported in a standard form, tested before purchase.
- Redundancy, backups, and remote access are design decisions to settle before the purchase order, not after.
- Write the exit plan while nobody needs it; the vendor will not.
A SCADA purchase at a small utility is rarely a bad product. It is a good product bought for the wrong reasons: because the neighboring utility has it, because the integrator likes it, because the demonstration was impressive, because the first-year price was low. Twenty years later the utility is still on it, paying for it, and hoping the one person who understands it does not retire. The questions below are the ones that would have changed the decision, and none of them is on a feature comparison sheet.
Who will maintain it
The honest first question is who fixes it when it breaks on a Saturday. If the answer is a vendor two states away, the utility is buying a support contract with a product attached. If the answer is a local integrator, ask how many of their people know the platform and what happens when the one who built the system leaves. If the answer is the utility staff, ask whether the platform can be learned by a good operator with a week of training, or whether it needs a programmer. A platform that a utility can maintain itself, with an integrator for the big changes, is worth more than one that does everything if only someone were there to make it.
What it costs in year ten
| Cost | What to ask | Why it matters |
|---|---|---|
| Server license | Perpetual or subscription; what stops if the subscription lapses | A lapsed subscription that blanks the screens is a hostage situation |
| Tag count | What counts as a tag; the cost of the next tier; the tags a new lift station adds | Utilities add sites; a tier boundary turns a lift station into a license upgrade |
| Clients | Per seat, per concurrent user, or unlimited; web and mobile clients | Two operators, a supervisor, a phone, and a screen in the shop is five clients |
| Redundancy | The second server license, and whether it is full price | Redundancy that costs double is redundancy that does not get bought |
| Historian | Included or separate; licensed by tags, by data rate, or by retention | History is the part with regulatory value |
| Drivers | Which controller and protocol drivers are included and which cost extra | The one driver you need is always the extra one |
| Support and updates | Annual maintenance percentage and what it buys | Skipping maintenance strands the system on an old version |
| Integrator time | Hours to add a site, a screen, a report | The largest cost over the life is labor |
Model all of it over ten years with the sites the utility expects to add. The cheapest first year is often the most expensive decade.
Whether the data is yours
The history in the historian is the record of every permit parameter, every pump runtime, and every alarm. The configuration is the sum of years of engineering. Ask, before buying, for a demonstration of exporting both in a standard form, a comma-separated file of history and a readable export of the tag database and screens, and ask what it would take to import the history into another product. A vendor who cannot answer is a vendor who owns your data. Ask also where the data lives: on servers the utility owns, on a vendor cloud, or both, and what the contract says happens to it when the contract ends.
How it fails
Servers fail, networks fail, and the utility is judged by what happens to the plant while they are down. Ask how the platform fails over, how long that takes, what the operator sees during it, and what it costs. Ask what the controllers do with the server gone, which is a question about the controller design as much as the SCADA, and whether the platform buffers history at the collectors so an outage leaves no gap. Ask what the backup consists of and ask for a restore to be demonstrated on a spare machine during the evaluation. A platform that has never been restored from backup has no backup.
How operators reach it from home
Every small utility wants the on-call operator to see the plant from home, and every one of them will eventually be offered a shortcut: a web client exposed to the internet, a remote desktop tool on the server, a cellular router at a lift station with a public address. Ask the vendor how remote access is meant to work, and accept only an answer that includes a virtual private network with multi-factor authentication and a jump host in a demilitarized zone. Ask how vendor support connects, and require the same path with per-session enablement. The platform that makes secure remote access easy is the one that will be used securely.
What leaving would take
Nobody buying a system wants to think about leaving it, and that is exactly when to write the exit plan. It is a page: where the history is and how it exports, where the configuration is and what format it is in, which controller programs and drivers would need to change, and what the licensing says about termination. Writing it forces the questions above to be answered in the contract rather than discovered in year twelve. It also makes the vendor relationship healthier, because a customer who can leave is a customer who gets support.
A short list for the evaluation
- 01Name the people who will maintain it and confirm they can, with training if needed.
- 02Get the ten-year cost with the expected growth, in writing.
- 03Export history and configuration during the evaluation and look at the files.
- 04Watch a failover and a restore from backup.
- 05See the remote access design and the vendor access procedure.
- 06Call two utilities of similar size that have run it for ten years, and ask what they would do differently.
- 07Write the exit plan and put it in the contract file.
None of this is about which platform is best. Several are excellent. It is about buying one for reasons that will still be true in twenty years.
Frequently asked questions
- Should a small utility consider a hosted or cloud SCADA?
- It can, with the same questions asked harder: where the data lives, what runs locally when the internet is down, how the field connection is secured, and what the contract says at termination. Local control must never depend on the cloud, and the security review is the decision.
- How much should we budget for the integrator?
- More than the software. Over the life of the system the labor to add sites, change screens, and build reports exceeds the license cost at most utilities. Choose a platform with an integrator base within driving distance and ask for hourly rates for routine changes.
- Is unlimited licensing always better?
- It removes the tag and client anxiety and it also removes the incentive to keep the system tidy. It is better for a utility that will grow and worse for one that will let a system sprawl without standards. The standards matter more than the license model.
- We already own a platform we do not like. Replace it?
- Ask the six questions of the current system first. If the answers are acceptable, the problem may be the implementation, not the platform, and a rebuild on the same product with standards is cheaper than a migration. If the answers are not acceptable, plan the migration with the exit plan you should have had.
Related topics
- Other PlatformsThe SCADA and HMI products a water utility may meet beyond the common ones: Siemens WinCC, distributed control systems, independent SCADA products, hosted lift station monitoring, and open-source tools, and the questions that decide whether one belongs.
- SCADA RedundancyWhat redundant SCADA servers protect against and what they do not, how failover works for tags, alarms, history, and clients, the network and controller layers beneath it, and why an untested failover is not redundancy.
- VPN DesignHow a VPN fits remote access for a control system: it terminates in the DMZ and lands on a jump host, never the control network; site-to-site tunnels carry telemetry; user tunnels require multi-factor and individual accounts; the concentrator is patched fast.
- SCADA BackupsWhat a SCADA backup must contain to bring a system back: the project export, an image of each server, the databases, historian archives, licenses, certificates, scripts, and network device configurations, with frequency, retention, and the restore procedure.
- Long-Term StorageKeeping historian data for years: a retention policy by data class that follows the record rules, tiered storage from online to offline copies, downsampling, archive management, exports that outlive the historian, and the annual proof that old data reads.
- VTScadaField notes on VTScada, the Trihedral platform widely used by municipal water utilities: the all-in-one design with historian, alarm notification, and thin clients built in, server redundancy, application versioning, telemetry drivers, and licensing by tags.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.