SCADA system Architecture

Scada ARCHITECTURE

A SCADA System usually consists of the following subsystems:

  • A Human-Machine Interface or HMI is the apparatus which presents process data to a human operator, and through this, the human operator monitors and controls the process.
  • A supervisory (computer) system, gathering (acquiring) data on the process and sending commands (control) to the process.
  • Remote Terminal Units (RTUs) connecting to sensors in the process, converting sensor signals to digital data and sending digital data to the supervisory system.
  • Programmable Logic Controller (PLCs) used as field devices because they are more economical, versatile, flexible, and configurable than special-purpose RTUs.
  • Communication infrastructure connecting the supervisory system to the Remote Terminal Units.

A. Hardware Architecture

Basic layers in a SCADA system can be classified in two parts generally: the “client layer” which caters for the man machine interaction and the “data server layer” which handles most of the process data control activities. The data servers communicate with devices in the field through process controllers.

Process controllers, e.g. PLCs, are connected to the data servers either directly or via networks or fieldbuses. Data servers are connected to each other and to client stations via an Ethernet LAN. The data servers and client stations are NT platforms but for many products the client stations may also be W95 machines.

Remote Terminal Unit (RTU); The RTU connects to physical equipment. Typically, an RTU converts the electrical signals from the equipment to digital values such as the open/closed status from a switch or a valve, or measurements such as pressure, flow, voltage or current. By converting and sending these electrical signals out to equipment the RTU can control equipment, such as opening or closing a switch or a valve, or setting the speed of a pump.

Supervisory Station; The term “Supervisory Station” refers to the servers and software responsible for communicating with the field equipment (RTUs, PLCs, etc), and then to the HMI software running on workstations in the control room, or elsewhere. In smaller SCADA systems, the master station may be composed of a single PC. In larger SCADA systems, the master station may include multiple servers, distributed software applications, and disaster recovery sites. To increase the integrity of the system the multiple servers will often be configured in a dual-redundant or hot-standby formation providing continuous control and monitoring in the event of a server failure

B. Software Architecture

The products are multi-tasking and are based upon a real- time database (RTDB) located in one or more servers. Servers are responsible for data acquisition and handling. (E.g. polling controllers, alarm checking, calculations, logging and archiving) on a set of parameters, typically those they are connected to. However, it is possible to have dedicated servers for particular tasks, e.g. data logger a SCADA architecture that is generic for the products that were evaluated.

C. Human-Machine interface (HUI)

A Human-Machine Interface or HMI is the apparatus which presents process data to a human operator, and through which the human operator controls the process. An HMI is usually linked to the SCADA system’s databases and software programs, to provide trending, diagnostic data, and management information such as scheduled maintenance procedures, logistic information, detailed schematics for a particular sensor or machine, and expert-system troubleshooting guides. The HMI system usually presents the information to the operating personnel graphically, in the form of a mimic diagram. This means that the operator can see a schematic representation of the plant being controlled.

D. Communications

Internal Communication:

Server-client and server-server communication is in general on a publish-subscribe and event-driven basis and uses a TCP/IP protocol, i.e., a client application subscribes to a parameter which is „owned‟ by a particular server application and only changes to that parameter are then communicated to the client application.

Access to Devices:

The data servers poll the controllers at a user define polling rate. The polling rate may be different for different parameters. The controllers pass the requested parameters to the data servers. Time stamping of the process parameters is typically performed in the controllers and this time-stamp is taken over by the data server. If the controller and communication protocol used support unsolicited data transfer then the products will support this too. The products provide communication drivers for most of the common PLCs and widely used field-buses, e.g., Modbus. Of the three fieldbuses that are recommended at CERN, both Profibus and Worldfip are supported but CANbus often not [3]. Some of the drivers are based on third party products (e.g., Applicom cards) and therefore have additional cost associated with them. VME on the other hand is generally not supported.

A single data server can support multiple communications protocols: it can generally support as many such protocols as it has slots for interface cards. The effort required to develop new drivers is typically in the range of 2-6 weeks depending on the complexity and similarity with existing drivers, and a driver development toolkit is provided.

E. Interfacing

Application Interfaces / Openness The provision of OPC client functionality for SCADA to access devices in an open and standard manner is developing. There still seems to be a lack of devices/controllers, which provide OPC server software, but this improves rapidly as most of the producers of controllers are actively involved in the development of this standard. OPC is currently being evaluated by the CERN-IT-CO group [4]. The products also provide:

  • an Open Data Base Connectivity (ODBC) interface to the data in the archive/logs, but not to the configuration database,
  • an ASCII import/export facility for configuration data,
  • a library of APIs supporting C, C++, and Visual Basic (VB) to access data in the RTDB, logs and archive.

The API often does not provide access to the product‟s internal features such as alarm handling, reporting, trending, etc. The PC products provide support for the Microsoft standards such as Dynamic Data Exchange (DDE) which allows e.g. to visualize data dynamically in an EXCEL spreadsheet, Dynamic Link Library (DLL) and Object Linking and Embedding (OLE).

Database:

The configuration data are stored in a database that is logically centralized but physically distributed and that is generally of a proprietary format. For performance reasons, the RTDB resides in the memory of the servers and is also of proprietary format. The archive and logging format is usually also proprietary for performance reasons, but some products do support logging to a Relational Data Base Management System (RDBMS) at a slower rate either directly or via an ODBC interface.

F. Scalability

Scalability is understood as the possibility to extend the SCADA based control system by adding more process variables, more specialized servers (e.g. for alarm handling) or more clients. The products achieve scalability by having multiple data servers connected to multiple controllers. Each data server has its own configuration database and RTDB and is responsible for the handling of a sub-set of the process variables (acquisition, alarm handling, archiving.

G. Redundancy

The products often have built in software redundancy at a server level, which is normally transparent to the user. Many of the products also provide more complete redundancy solutions if required.