Will SCADA Evolve to the Cloud?

One of the most common applications for real-time data in manufacturing and process industries is SCADA, supervising remote processes over a network.  With the growing popularity of cloud computing, many engineers and managers in the automation sector are looking at the possibility of using the cloud for SCADA.  Are they being realistic, or just dreaming in technicolor?  Is it possible that SCADA will somehow evolve to the cloud?

The acronym “SCADA” stands for Supervisory Control And Data Acquisition.  SCADA systems connect sensors and devices in the field or factory floor to an HMI (human-machine interface), allowing plant operators and engineers to view the data in their industrial processes in real time.  This interface often supports a supervisory level of coordination and control, such as uploading new recipes to a candy-making machine, changing global settings on a wind turbine, or acknowledging a high pressure alarm for a boiler.

SCADA systems have evolved over time. The first generation systems were “monolithic”, running on mainframe computers, connecting to field devices over proprietary wide-area networks (WANs).  The second generation did “distributed” processing, using mini computers communicating with each other over a local-area network (LAN).  Communication to the field was still by proprietary protocols on WANs.  The current, “networked”, generation uses PCs and open standards such as TCP/IP and open protocols for wide-area networking.  Thus it is now possible to access SCADA systems and data from the Internet.

Do you see where this is going?  Since SCADA systems have followed the progress of computing in general, and as many view cloud computing as the next logical step in this evolution, enthusiastic visionaries foresee a fourth, “cloud” generation of SCADA, where an entire control system would be running in the cloud.

Back here on earth, most industry experts agree it would be foolish to put the primary control of a power plant, water treatment system, or railyard switching system on the cloud, as it is right now.  These kinds of mission-critical control tasks require rugged, reliable data networks and extremely fast response times.  Advocates of cloud computing may hope that Internet speed and reliability will eventually support this level of SCADA, but we have no guarantees of that today.

That said, there are other ways of using SCADA, and other uses of process data that lend themselves to real-time cloud applications.  Designed properly, with the core requirements for real-time cloud systems in mind, it is possible to put live data from SCADA systems on the cloud in a secure, reliable way.  Using specially-designed middleware that supports high data rates and low latency on a data-centric infrastructure, perfectly acceptable real-time performance can be achieved for many types of applications.

Cloud computing can be implemented in different ways.  As we explained a few months ago, a private cloud option can be implemented on-site to maximize security, or off-site to reduce costs and gain other benefits associated with the cloud.  Another possibility is a hybrid cloud, a combination private and public clouds.  With the right kind of infrastructure in place, any of these options could support a system to meet the growing demand for providing access to data from a SCADA system to local or remote users, in real time.

Evolution is a gradual process.  It takes time, and it goes step by step.  A first step in the evolution towards cloud-based SCADA may well be some kind of cloud-enhanced SCADA.  We will talk about that in an upcoming blog, but first we need to clear up some of the fear, uncertaintly and doubt surrounding the discussion about SCADA and the cloud.

Cloud-Capable “Real Time”

Our review of definitions for “real time” over the past couple of weeks has brought us to the point where we are now ready to answer the question: Is the cloud capable of real-time performance, and if so, how?  We have reviewed some of the technical definitions for “real time,” and considered some expert advice on a practical, realistic definition of “real time”.  Now let’s see whether or not the cloud really is capable of supporting real-time computing, according to these definitions.

To sum up E. Douglas Jensen at Time-Critical Technologies, real-time computing in the real world means achieving optimal system performance within given time constraints.  So, what is optimal system performance for a cloud system?  And what time constraints are we considering here?

Each cloud application has its own time constraints.  What seems uselessly slow for one set of users may be perfectly acceptable for others.  For example, in many business applications data that is just a few seconds old is considered real time.  In fact, many executives would boast about having access to up-to-the-minute data.  Managers and analysts running certain industrial applications like inventory control or end-of-shift reports have similar requirements.  When these users talk about real-time data in the cloud, delays of a few seconds or even minutes might be perfectly fine.

Fast moving lightsOn the other hand, most operators working at a control panel in a plant expect to see things happen immediately.  When they click a button, the light should come on right away, not after a few seconds, or even one second later.  Values should update as they change in the process.  Trend lines should be smooth curves drawn on the page, not jagged peaks that appear intermittently.  As far as we are concerned, a cloud system that claims to be real time should be able to emulate that experience very closely.  For our purposes, then, we can define “real time” for the cloud as follows:

“Real-time” cloud: Remote accessibility to data, with local-like immediacy.

Of course, the remote aspect of any cloud application will always have an impact.  The Internet and other networks inescapably introduce latencies into the data flow.  This kind of delay in delivering the data brings to mind the US Defense Department Military Dictionary definition of “real time,” which is: “Pertaining to the timeliness of data or information which has been delayed only by the time required for electronic communication. This implies that there are no noticeable delays.”

A real-time cloud system should have no noticeable delays, or at least, no more than absolutely necessary.  Any intermediate software running on the cloud should support high-speed data throughput.  Latencies should be no more than a few milliseconds over the network latency.  The infrastructure should almost certainly be data-centric, minimizing the need to convert between HTML, XML, SQL, or other data formats.

Broadly speaking, when people are working with the system, we can aim high and set a goal for our time constraints at human response time.  The user should feel like he or she is working on a local system.  Any extra processing time over and above network communication time should be kept to an absolute minimum.  And what about in M2M (machine to machine) applications?  Here again, there should be as little delay as possible beyond any networking latencies.

Although the debate about the definition of “real time” may continue for years to come, we can glean enough for our purposes.  For our real-world applications on the cloud, we can define “real time” as achieving optimal system performance within given time constraints.  So, if we define our time constraints to be human response time, and accept the limitations of networking latencies on system optimization, then we can confidently assert that the cloud is capable of supporting real-time systems.

Realistic “Real Time”

As we look over the technical definitions for real-time computing, it is clear that there is no way the cloud can support hard real time performance.  The cloud is not deterministic.  Despite advances in networking technology, there will always be delays and network breaks, making it impossible to implement any kind of hard real-time system where missing a deadline would cause a total system failure.  If we want to talk about real-time data in the cloud, we need to be clear on what we mean by real time.  We need a realistic definition of “real time” for the cloud.

Someone who has done a lot of thinking about how to define “real time” is E. Douglas Jensen.  Jensen has spent over 30 years developing real-time systems for industrial and military applications in institutions like Carnegie Mellon University, Hewlett Packard, and Honeywell.  More recently he has worked as a consultant for MITRE and the U.S. Department of Defense, as well as in his own consulting practice, Time-Critical Technologies (TCT).

According to Jensen, once you step away from the clear-cut definition of “real time” as hard real time, things get vague.  His experience is that researchers and academics working in the lab have created good theoretical models for real-time computing, but when we attempt to apply those theories in real-world situations, they are often not practical. This is particularly true in distributed systems, and the cloud is the ultimate distributed system.

On his website, Real-time for the Real World, Jensen offers a new approach to thinking about real-time systems in a realistic way.  First, he says that anything other than the concept of “hard real time” has been difficult to pin down and define, even by the experts. Second, it is tough to do any kind of experimental research on real-time systems in the real world because they are typically big, complicated, expensive, and mission-critical.  He then offers a reformulation of the idea of real time that has enabled him to construct highly complex real-time computing systems.

Jensen boils the issue down to two concepts: 1) time constraints (or deadlines) and 2) achieving acceptably optimal system performance within those constraints.  He says, “Real-time computing is about satisfying time constraints acceptably well with acceptable predictability—according to application- and situation-specific acceptability criteria, given the current circumstances.”

As in real life, time constraints can vary in immediacy and importance.  Some deadlines might be like catching a plane flight—not immediate, but important.  You may have some time to get to the gate, but when the plane takes off, you’d better be on board.  Other deadlines might be more like a phone call, which is always immediate but may not be important.  You get no advance warning when the phone rings, but if you don’t answer until the third or fourth ring, no problem.  Who is calling determines the importance, and sometimes even letting it go to voice mail may be just fine.

Also in real life, many things can happen at once.  While you are rushing to catch the flight, you realize that you left your ticket at home.  Just then your phone rings, someone bumps you from behind, you drop your bag, and then you notice that your wallet is missing.  What to do first?

Real-time computing systems are often put under similar demands, and need to respond in the best possible way.  An optimized system would meet all hard deadlines as often as possible, and minimize the number of soft deadlines missed and/or minimize the lateness of the response time.  Generally speaking, this is what it means to achieve optimal system performance within given time constraints.

A realistic approach to real-time establishes that each system, large or small, fast or slow, will have its own particular time constraints and acceptable level of optimal performance. Naturally, that can include cloud systems.  Taking this approach, we are now ready to look at the demands of some typical real-time systems, and how they can best be met when moved to the cloud.

Technically “Real Time”

For the past few months we’ve been talking about cloud computing, and how it might be able to support the flow of data in real time.  We’ve examined some of the different kinds of clouds, and highlighted their benefits, but we haven’t yet touched on the idea of “real time”.  What exactly does the “real-time” in “Real-Time Cloud” mean?  Is it really even possible to implement cloud computing for real-time data?

Technically speaking, a real-time computing system is 100% predictable and deterministic.  It guaratees a response within very narrow time constraints.  A missed deadline results in total system failure.  For example, the computer controlled anti-lock braking system in your car is a real-time system.  If the signal is processed too late, you could lose control of the car, resulting in serious damage or injury.

Aircraft and missle defense systems often use real-time computing.  According to Answers.com, the US Defense Department Military Dictionary defines “real time” like this: “Pertaining to the timeliness of data or information which has been delayed only by the time required for electronic communication. This implies that there are no noticeable delays.”

Real-time processing is sometimes distinguished from batch processing.  In batch processing, a number of tasks are gathered by a system and then processed together, in a batch.  In contrast, in real-time processing, each task is processed immediately, in a continual flow of input, processing, and output.  This mode of processing is generally expected to produce output in synch with real time.

Clock and speed image.Another aspect of real-time processing in some systems deals with regulating the rate of computation to go exactly the same speed as time passes in our physical reality–neither slower nor faster.  Like a video that can be sped up or put into slow motion, such real-time systems are designed to synchronize with the actual rate of time experienced by the system they model.

People also speak about real time with varying degrees of hardness.  A real-time system where missing a deadline results in total system failure is often referred to as “hard” real time.  However, there are many real-time systems in which being a little late occasionally does not spell absolute disaster.  If a deadline can be missed every now and then, a system may be referred to as “firm” real time.  Or if a slightly late response is still somewhat useful, and not a complete loss, then the system is sometimes known as a “soft” real-time.

Along these lines, Answers.com gives another entry from the US Defense dictionary for “near real time,” defining it as follows: “Pertaining to the timeliness of data or information which has been delayed by the time required for electronic communication and automatic data processing. This implies that there are no significant delays. Also called NRT.”

How does all of this apply to cloud computing?  Clearly, with the unpredictability of the Internet, we would be pretty far stretched to categorize a real-time cloud system as hard real time.  So what is real-time cloud computing, then? Is it soft real time?  Or near real time?  Or something else?  Next week we’ll see what one highly-regarded expert in the field of real-time systems has to say about real-world real time.

CEO Perspectives 4: Leading the Transformation

Is cloud computing inevitable?  Some people seem to think so.  Try typing the words “cloud,” “computing,” and “inevitable” into Google and you’ll get millions of hits.  Last year cloud computing reached a peak on the Gartner Hype Cycle.  While the more conservative players are willing to sit back and take a wait-and-see approach, a growing number of companies are diving in, and leading the transformation.

According to Andrew McAfee in his article What Every CEO Needs to Know About the Cloud, there is a gradual but inevitable shift toward the cloud.  He expects those who get in early to be in an increasingly better position as time passes, while those who linger to be put at a greater and greater disadvantage, until they either join or get lost in the dust.  McAfee gives some general guidelines for starting a move into the cloud, which can be used by anyone interested in putting real-time data on the cloud.

Know Your Responsibilities
To start with, McAfee suggests becoming aware of legal implications.  Clouds in the sky have no respect for man-made concepts like country borders, but your data does not have the same luxury.  Some countries limit what kinds of data can be moved or stored outside their borders.  For example, the EU Data Protection Directive restricts data on personal status from passing through countries that do not provide an “adequate level of protection” for the data.  Other countries have  strict privacy laws for any data transmitted on a public network or stored in a cloud server.  You will need to verify that your system meets the legal requirements of all countries in which you expect it to function.

Understand the Risks
We talked about security risks last week, pointing out that they may be different than common wisdom would suggest.  Questions about cost and reliability were addressed in an earlier blog.  McAfee advises executives to become informed of the risks and limitations of cloud computing, involving their general counsels and compliance departments early on.  There are a few areas, such as data subject to export regulations or related to personal health information, that may warrant a conservative approach, but in general he advocates boldly moving forward.  Plant managers and engineers will of course need to take a close look at their specific circumstances to decide what parts of their data sets can be made available in a cloud application.

Evaluate Attitudes
As with any new undertaking, there will be different levels of interest and willingness to change, both within the organization and outside.  Those most eager to implement a real-time cloud system will need to gauge its appeal among key decision makers and managers who are expected to implement it.  McAfee says, “a CIO’s lack of enthusiasm about the cloud these days is about as red a flag as a factory manager’s disinterest in electrification would have been a century ago.”

At the same time, consider software vendors.  What is their attitude toward cloud computing?  What plans do SCADA suppliers and other providers of software for real-time applications have in place to support a move to the cloud?  Some may add the word “cloud” to their networked process control software, but does it really meet the core requirements for a real-time cloud system?

Experiment
Having done your homework, you are ready to try it.  McAfee suggests starting small.  Experiment.  He talks about non-real-time business systems, but the principle is the same.  Don’t expect to immediately move a whole SCADA system onto the cloud.  Maybe you can implement a web-based HMI to present a limited data set to selected customers.  Or possibly connect remote field devices to a cloud server for monitoring in a web browser.  As you gain experience, you may want to set up a private or a hybrid cloud.  Then, as time passes and cloud computing goes even more mainstream, you’ll be in a position to consider expanding further.

It is still too early in the history of cloud computing to know with absolute certainty that this is indeed the way of the future.  But things have reached a point where it would probably be wise to consider it seriously.  As consumer and business applications increasingly move into the cloud, real-time solutions won’t be far behind.  Somewhere between head-in-the-sand and off-the-deep-end, McAfee suggests a cautious, realistic, small-scale, try-and-see attitude to gain experience and build capabilities that may prove valuable in the near future.