While the SCADA human-machine interface usually allows operators to view the state of any part of the plant equipment, most operator interaction with the system is driven by alarms. Alarms are automatically detected abnormal conditions in the plant equipment that require operator attention, and may require operator intervention to keep things running smoothly.
SCADA master computers typically run on top of a third party operating system. Nearly all SCADA products run on either a UNIX variant or HP OpenVMS, although many vendors are beginning to provide Microsoft Windows as a host operating system option. More "open" platforms such as Linux are not as widely used due to the highly dynamic development environment and because a SCADA customer that is able to afford the field hardware and devices to be controlled is also usually able to also purchase UNIX or OpenVMS licenses.
SCADA systems typically implement a distributed database which contains data called points. A point represents a single input or output value monitored or controlled by the system. Points can be either "hard" or "soft". A hard point is representative of an actual input or output connected to the system, while a soft represents the result of logic and math operations applied to other hard and soft points.
The human-machine interface package for the SCADA system typically includes a drawing program which the operators or system maintenance personnel use to change the way these points are represented in the interface. These representations can be as simple as a on-screen traffic light which represents the state of an actual traffic light in the field, or as complex as a multi-projector display representing the position of all of the elevators in a skyscraper or all of the trains on a railway. The interface is usually 2D and is displayed using the X Windows Protocol, although some vendors provide immersive 3D interfaces and support for other display APIs such as Win32 GDI/DirectDraw.
Since the early 1990s the role of SCADA systems in large civil engineering solutions has changed, requiring them to perform more operations automatically. Solutions sold as SCADA also often have Distributed Control System (DCS) components. Use of "smart" RTUs or PLCs (programmable logic controllers), which are capable of autonomously executing simple logic processes without involving the master computer, is increasing. A functional block programming language, IEC 61131-3, is frequently used to create programs which run on these RTUs and PLCs. Unlike a procedural language such as the C programming language or FORTRAN, IEC 61131-3 has a minimal training requirements. This allows SCADA system engineers to perform both the design and implementation of a program to be executed on a RTU or PLC.
For example, instead of relying on operator intervention, or master station automation, RTUs may now be required to operate on their own to control tunnel fires or perform other safety-related tasks. The master station software is required to do more analysis of data before presenting it to operators including historical analysis and analysis associated with particular industry requirements. Safety requirements are now being applied to the system as a whole, and even master station software must meet stringent safety standards for some markets.
SCADA systems have traditionally used combinations of radio and direct serial or modem connections to meet communication requirements, although Ethernet and IP over SONET is also frequently used at large sites such as railways and power stations.
This has also come under threat with some customers wanting SCADA data to travel over their pre-established corporate networks, or to share the network with other applications. The legacy of the early low-bandwidth protocols remains, though. SCADA protocols are designed to be very compact and many are designed to send information to the master station only when the master station polls the RTU. Current standard SCADA products include Modbus, Conitel, and Dnp3. Many of these protocols now contain extensions to operate over TCP/IP, although it is good security engineering practice to avoid connecting SCADA systems to the Internet so the attack surface is reduced.
See also: