22-05-2013, 01:03 PM
SCADA TECHNOLOGY
SCADA TECHNOLOGY.pdf (Size: 355.21 KB / Downloads: 755)
Introduction
Widely used in industry for Supervisory Control and Data Acquisition of industrial
processes, SCADA systems are now also penetrating the experimental physics
laboratories for the controls of ancillary systems such as cooling, ventilation, power
distribution, etc.
SCADA systems have made substantial progress over the recent years in terms of
functionality, scalability, performance and openness such that they are an alternative to in
house development even for very demanding and complex control systems as those of
physics experiments.
What does SCADA MEAN?
SCADA stands for Supervisory Control And Data Acquisition. As the name indicates, it
is not a full control system, but rather focuses on the supervisory level. As such, it is a
purely software package that is positioned on top of hardware to which it is interfaced, in
general via Programmable Logic Controllers (PLCs), or other commercial hardware
modules.
SCADA systems are used not only in industrial processes: e.g. steel making, power
generation (conventional and nuclear) and distribution, chemistry, but also in some
experimental facilities such as nuclear fusion. The size of such plants range from a few
1000 to several 10 thousands input/output (I/O) channels. However, SCADA systems
evolve rapidly and are now penetrating the market of plants with a number of I/O
channels of several 100 K: we know of two cases of near to 1 M I/O channels currently
under development.
SCADA systems used to run on DOS, VMS and UNIX; in recent years all SCADA
vendors have moved to NT and some also to Linux.
Architecture
Hardware Architecture
One distinguishes two basic layers in a SCADA system: 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 that are proprietary (e.g. Siemens
H1), or non-proprietary (e.g. Profibus). 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. Fig.1. shows typical
hardware architecture.
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.
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 defined 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.
Alarm Handling
Alarm handling is based on limit and status checking and performed in the data servers.
More complicated expressions (using arithmetic or logical expressions) can be developed
by creating derived parameters on which status or limit checking is then performed. The
alarms are logically handled centrally, i.e., the information only exists in one place and
all users see the same status (e.g., the acknowledgement), and multiple alarm priority
levels (in general many more than 3 such levels) are supported.
It is generally possible to group alarms and to handle these as an entity (typically filtering
on group or acknowledgement of all alarms in a group). Furthermore, it is possible to
suppress alarms either individually or as a complete group. The filtering of alarms seen
on the alarm page or when viewing the alarm log is also possible at least on priority, time
and group. However, relationships between alarms cannot generally be defined in a
straightforward manner. E-mails can be generated or predefined actions automatically
executed in response to alarm conditions.
Logging/Archiving
The terms logging and archiving are often used to describe the same facility. However,
logging can be thought of as medium-term storage of data on disk, whereas archiving is
long-term storage of data either on disk or on another permanent storage medium.
Logging is typically performed on a cyclic basis, i.e., once a certain file size, time period
or number of points is reached the data is overwritten. Logging of data can be performed
at a set frequency, or only initiated if the value changes or when a specific predefined
event occurs. Logged data can be transferred to an archive once the log is full. The
logged data is time-stamped and can be filtered when viewed by a user. The logging of
user actions is in general performed together with either a user ID or station ID. There is
often also a VCR facility to play back archived data.