A Broad Overview of SCADA

1 SCADA Definition

SCADA stands for supervisory control and data acquisition. It is a term that is part of a family of
acronyms very commonly associated with industrial operations. The purpose of SCADA is to ensure
that those operations of a facility that can be handled with automation are able to be monitored
and controled as needed.

1.1 SCADA Elements

SCADA systems are made up of several pieces. Paraphrasing from the OPC UA wiki (a common protocol for SCADA comms),
and adding a few extra categories, here are the large parts of a SCADA system.

When considered in a distributed context, like almost all modern facilities what you are left with is basically the entire
field of systems engineering and computing wrapped up into one acronym. This is why SCADA problems are so hard.

1.1.1 Security

SCADA systems are responsible for access and control of some of the most expensive systems in the world.
For this reason, security is supposed to be a large part of their focus. Unfortunately, security is often
one of the most neglected pieces of the infrastructure in these systems. Vendors often treat this as a problem
of legacy systems but even the most cutting edge protocols like mqtt show signs of serious security vulnerabilities if not
handled correctly.

Often the “answer” to these security concerns is to isolate them from all other networks. Like most isolation strategies,
they work fine until that wall is breached. Ransom Ware and other non-target system attacks are a constant threat to even
modern SCADA systems.

1.1.2 Information Model

SCADA is often responsible for defining the informational model of the data being captured. This can be
specifying a machine, a sensor or some other conglomerate of equipment. The major problems with information
specification are the tensions of too much structure against too rigid a structure. For years the tendency has
been to make things too rigid. Lately, the rise of IOT and other IT friendly protocols are probably swinging
this the other way. There is no shortage of systems that are overly specified.

Ideally a system should allow temlatizing and automation of data in a variety of ways. There should be support for new ways being easily added.

1.1.3 Data Access

The SCADA system often defines who can make changes to the operations of a facility at the automation level. That is, who can change
the parameters of a machine and who can see the data coming from that machine. The requirements here can be bogglingly complicated.
For instance, access that is location and time dependant.

1.1.4 Alarms and Conditions

One of the most important roles of a SCADA system is deciding when it is time to let someone know some piece of information.
Lights, sounds On Screen pop-ups, calls, texts, emails and every other conceivable notification have been added as responsibilities
of a SCADA system at one time or another.

1.1.5 Programs

Some SCADA systems monitor what programs are running on what machines, allowing meta control of changes and supervising maintenance
of devices in addition to the devices themselves.

1.1.6 Historical Access

Machine historians, event trackers, change logs and other forms of historical record are usally the provinence of a SCADA system.
It is not uncommon for 100s of Gb of data to be logged in a SCADA platform.

1.1.7 Discovery and Global Services

As the device count and facility count of an organization grows, SCADA systems become responsible for discovering new
fields that can be pulled, and associating tags regionally or through some other mechanism.

1.1.8 AP I and external access

Eventually data needs to leave a SCADA system and become part of the many other software systems in a modern operation.
This is handled with database access, api or other sorts of system combination layers. Again almost every technique used in
computing is seen here.

1.2 Common SCADA Arhitectures

When a SCADA integrator assembles a system they tend to pull from a common tool box.
They have to pick computation and sensor architectures, data flow architectures
and security architectures as well as innumerable other decisions.

1.2.1 Common SCADA Computation and Sensor Architectures

It is very common for a mix of all these strategies to occur in a facility, to add to the fun!

  1. Dumb Sensors Smart Device

    This is probably the most common sort of SCADA system (as of 2020). A
    set of sensors and control devices only communicate an analog signal to a PLC or other computational
    decision making device. This device is polled by the SCADA system or pushes its data to the SCADA
    in an event based system.

    The advantages of this system are the relatively less expensive sensor costs as well as the comprehensibility
    and testability of its design.

  2. Smart Sensors Smart Device

    Another common approach is to have sensors with a directly addressable computer. They then transmit a
    digital reading to a PLC this device compares what is happening to the sensor with what is happening elsewhere
    and sends back commands or sends the data onto the SCADA system.

    While the individual devices are more costly, the networking and data captue portions of the system are often
    reduced considerably in cost. Plus early conversion to digital makes for a more reliable set of values to be
    transmitted.

  3. Smart Sensors Direct Path

    As the sensors in a system become more and more capable computationally the need for a centralized decision
    maker starts to become less important. The SCADA system itself is often tasked with multi-condition evaluation
    and the sensors are hooked straight into the network for evaluation by this system.

  4. Which one is right?

    All of these systems might be the right one, depending on existing equipment and the enviornment.
    But where possible, I think pairing Smart Sensors with Low Cost PLC’s tends to produce the most flexible
    and inexpensive outcomes.

1.2.2 Data Flow Architectures

The way data moves through devices, from

  1. Data Direction

    Top Down Polling versus Bottom up broadcasting are
    the common decision factors that have to be selected in a SCADA Network

    1. Top Down Polling

      A primary system is tasked with reaching out to a set of data locations it knows about
      and asking them to report what information they have. One of the major advantages of
      a system like is that it is easy to troubleshoot. Unlike the usually more complex
      designs of broadcast systems, you can often stand at the primary and understand
      large parts of the system. They can also be nice designs for controlling
      SCADA systems when bandwidth on a network is limited.

      There can be multiple polling primaries though this is very uncommon.

    2. Bottom up Broadcast

      Bottom up broadcast “flips” the control of message delivery from the primary system
      to the remote devices. This allows a system to only transmit data as needed. It can
      also allow a system to bypass the idea of a primary device alltogether. The complexity
      of this architecture can be quite staggering and thought to troubleshooting should be
      consdiered in the planning stages.

  2. Data Responsibility

    In addition to (though often commonly conflated with) data direction, there is
    data responsibility. What part of a system is responsible for say, storage and
    delivery of a piece of data. This is often divided along the same lines of data direction.
    With broadcast systems making delivery the responsibility of the broadcast locations. And
    polling systems making delivery the responsibility of the polling device.

    Regardless of choice, it is important to be able to quickly know where to look when a system
    does not have the message expected.

  3. Data Destination

    The data has to end up somewhere, is that somewhere on premises, in a data room, or in the
    cloud?

    1. On Premisis Data Storage

      If done correctly, on premisis can be the most secure method of storing data. If using this
      method for long term storage, at least one of the systems doing backup should be isolated enough
      that you don’t have to worry about malware moving through the network and causing damage.
      For sophisticated systems, a team may be required to work on such a system. A common
      problem with on prem system designs are the falling behind of security systems
      and the lack of to date machines. In addition to security problems,
      new features and new connections to other systems often lag other options.
      The last major problem can be that the network reliability at a facility is poor
      if this is the case it might be very costly to improve it.

    2. Data Warehouse

      A data room is a secure facility with nice networks where a customers computers can
      be stored. This approach can be less expensive than cloud storage in some cases.
      It suffers from most of the problems of the On Prem system except the network reliability
      is usally much better.

    3. Cloud Systems

      Cloud systems use cloud servers to store the facilities configurations and data.
      They usually are the least vulernable to system level attack but as with all systems
      must be implemented correctly. Often they are paired with what are known as edge devices.
      These devices gather information locally before transmitting it to the cloud.
      This hybrid, cloud-local system has started being called a fog system or fog computing.

      Cloud systems tend to be continually developed and usually don’t suffer from the sort of
      feature lag that is seen in other sorts of deployments. This is especially true if
      3rd party Cloud SCADA services are implementing the system as they usually have on staff development
      teams and continuous deployment strategies.