SCADA as a Service in the Cloud

As I have pointed out earlier, infrastructure should not become reliant upon other infrastructure. The reason is to avoid common failure modes and to make restoral more straightforward and less inter-reliant.

This is why I have been looking at the SCADA-as-a-Service (SaaS) and Cloud SCADA with great skepticism. Let’s start with some obvious questions.

  1. Are they really doing things any better than you’d do them, given what you’re paying for the service?
  2. How responsive are they? What recourse do you have if things aren’t quickly restored?
  3. What dependencies do they have? What other infrastructure do they serve?
  4. Do you have plans for various types of security breeches?
  5. How do you communicate with this service?

The communications is actually my first and foremost objection. Sure, the internet itself is almost impossible to bring down. But how about your ISP? Or the fiber-optic cable that you use to get to the ISP?  How about the source of power for the ISP? How robust is the HVAC for the ISP?

Consider the cloud provider. The theory is that they can make the system work more resiliently and more reliably than you can. However, you should read the fine print. What counts as an outage? Some providers can be down for as much as ten minutes before the event is counted as an outage.

Suppose they’re down. Do they owe you anything for the screw up? What about your overtime? Doesn’t that count for something? What about the gap in your records and the need to estimate for your reports to the public and the government?

Perhaps this might not be the best solution for a large utility. But what about the small ones?  I’ll concede that if there are only half a dozen sites, a few pickup trucks and maybe as many technicians, this may not be a huge issue. The SCADA system’s existence in that case is more of a convenience and a minor financial savings than a necessity. However, as things scale up, the need for SCADA and the intolerance for downtime goes up too.

So how well can you transition from a cloud SCADA provider to your own SCADA system? Does the transition include the RTUs? What sort of communications and security does it use? Are the local controls part of the RTU or are they separate?

Finally, what media do they use to communicate? Common Carriers? What happens when those common carriers are hacked or denied? Conversely, if they’re licensed radio systems, do they have some way to locate interference sources?  If they’re unlicensed radio systems, what do they do when things stop working?

In other words, given not just the routine failure modes, but the additional dependencies on other systems that have been shown to fail, how good are they at staying online? Remember that SCADA systems are needed most when things are running poorly, not on pretty days when nothing goes wrong. So how well can the SaaS vendor do this stuff and how resilient are they?

If they don’t have concrete, no-nonsense answers, walk away and talk to someone else.

With more than 30 years experience at a large water/wastewater utility and extensive experience with control systems, substation design, SCADA, RF and microwave telecommunications, and work with various standards committees, Jake still feels like one of those proverbial blind men discovering an elephant. Jake is a Registered Professional Engineer of Control Systems. Note that this blog is Jake's opinion ONLY. No Employers, past or present were ever consulted with regard to these posts. These are Jake's notions. Don't blame anyone else for them.