What is SCADA?

Axel Daneels, Wayne Salter , IT/CO

SCADA: Acronym for supervisory control and data acquisition, a computer system for gathering and analyzing
real time data. SCADA systems are used to monitor and control a plant or equipment in industries such as
telecommunications, water and waste control, energy, oil and gas refining and transportation. A SCADA system
gathers information, such as where a leak on a pipeline has occurred, transfers the information back to a central
site, alerting the home station that the leak has occurred, carrying out necessary analysis and control, such as
determining if the leak is critical, and displaying the information in a logical and organized fashion. SCADA
systems can be relatively simple, such as one that monitors environmental conditions of a small office building,
or incredibly comple, such as a system that monitors all the activity in a nuclear power plant or the activity of a
municipal water system.
SCADA systems were first used in the !"#$s.
real time
Last modified: Wednesday, August !, "##!
%ccurring immediately. &he term is used to describe a number of different computer features. 'or eample, real(
time operating systems are systems that respond to input immediately. &hey are used for such tasks as
navigation, in which the computer must react to a steady flow of new information without interruption. )ost
general(purpose operating systems are not real(time because they can take a few seconds, or even minutes, to
react.
Real time can also refer to events simulated by a computer at the same speed that they would occur in real life. *n
graphics animation, for eample, a real(time program would display ob+ects moving across the screen at the
same speed that they would actually move.
computer
Last modified: $riday, %anuary #&, "##"
A programmable machine. &he two principal characteristics of a computer are,
*t responds to a specific set of instructions in a well(defined manner.
*t can eecute a prerecorded list of instructions -a program..
)odern computers are electronic and digital. &he actual machinery (( wires, transistors, and circuits (( is called
hardware/ the instructions and data are called software.
All general(purpose computers require the following hardware components,
memory : 0nables a computer to store, at least temporarily, data and programs.
mass storage de'i(e : Allows a computer to permanently retain large amounts of data. Common
mass storage devices include disk drives and tape drives.
in)ut de'i(e : 1sually a keyboard and mouse, the input device is the conduit through which data
and instructions enter a computer.
out)ut de'i(e : A display screen, printer, or other device that lets you see what the computer has
accomplished.
(entral )ro(essing unit *C+,-: &he heart of the computer, this is the component that actually
eecutes instructions.
*n addition to these components, many others make it possible for the basic components to work together
efficiently. 'or eample, every computer requires a bus that transmits data from one part of the computer to
another.
Computers can be generally classified by size and power as follows, though there is considerable overlap,
)ersonal (om)uter : A small, single(user computer based on a microprocessor. *n addition to the
microprocessor, a personal computer has a keyboard for entering data, a monitor for displaying
information, and a storage device for saving data.
.or/station : A powerful, single(user computer. A workstation is like a personal computer, but it
has a more powerful microprocessor and a higher(quality monitor.
mini(om)uter : A multi(user computer capable of supporting from !$ to hundreds of users
simultaneously.
mainframe : A powerful multi(user computer capable of supporting many hundreds or thousands of
users simultaneously.
su)er(om)uter : An etremely fast computer that can perform hundreds of millions of instructions
per second.
operating system
Last modified: $riday, %anuary #&, "##"
&he most important program that runs on a computer. 0very general(purpose computer must have an operating
system to run other programs. %perating systems perform basic tasks, such as recognizing input from the
keyboard, sending output to the display screen, keeping track of files and directories on the disk, and controlling
peripheral devices such as disk drives and printers.
'or large systems, the operating system has even greater responsibilities and powers. *t is like a traffic cop (( it
makes sure that different programs and users running at the same time do not interfere with each other. &he
operating system is also responsible for security, ensuring that unauthorized users do not access the system.
%perating systems can be classified as follows,
multi0user : Allows two or more users to run programs at the same time. Some operating systems
permit hundreds or even thousands of concurrent users.
multi)ro(essing : Supports running a program on more than one C21.
multitas/ing : Allows more than one program to run concurrently.
multithreading : Allows different parts of a single program to run concurrently.
real time: 3esponds to input instantly. 4eneral(purpose operating systems, such as D%S and 15*6,
are not real(time.
%perating systems provide a software platform on top of which other programs, called application programs,
can run. &he application programs must be written to run on top of a particular operating system. 7our choice of
operating system, therefore, determines to a great etent the applications you can run. 'or 2Cs, the most popular
operating systems are D%S, %S89, and :indows, but others are available, such as ;inu.
As a user, you normally interact with the operating system through a set of commands. 'or eample, the D%S
operating system contains commands such as C%27 and 305A)0 for copying files and changing the names of
files, respectively. &he commands are accepted and eecuted by a part of the operating system called the
command processor or command line interpreter. 4raphical user interfaces allow you to enter commands by
pointing and clicking at ob+ects that appear on the screen.
1 Introdu(tion
%n 9$ Sept. 9$$$, the 'inance Committee approved the proposal to negotiate a contract with 0&) A.4.
-0isenstadt, Austria. for the supply of 2<SS ( 0&)=s SCADA ( for developing the control systems of A;*C0,
A&;AS, C)S and ;>Cb. *n addition the SCADA :orking 4roup, that was set up by the C035 Controls ?oard,
recommends 2<SS as one of the SCADA products for the development of future control systems at C035.
&hese decisions are the accomplishment of around thirteen person(years -'&0. of effort ( spanning over more
than three years ( to identify and evaluate a proper industrial control system that copes with the etreme
requirements of high energy particle physics eperiments such as those of the ;>C.
:idely used in industry for Supervisory Control and Data Acquisition of industrial processes, SCADA systems
are now also penetrating the eperimental physics laboratories for the controls of ancillary systems such as
cooling, ventilation, power distribution, etc. )ore recently they were also applied for the controls of smaller size
particle detectors such as the ;@ muon detector and the 5AAB eperiment, to name +ust two eamples at C035.
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 comple control systems as those of physics eperiments.
"1 What does SCADA 23A4?
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 2rogrammable ;ogic Controllers -2;Cs., 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 eperimental facilities such as nuclear fusion. &he size of
such plants range from a few !$$$ to several !$ thousands input8output -*8%. channels. >owever, SCADA
systems evolve rapidly and are now penetrating the market of plants with a number of *8% channels of several
!$$ C, we know of two cases of near to ! ) *8% channels currently under development.
SCADA systems used to run on D%S, <)S and 15*6/ in recent years all SCADA vendors have moved to 5&
and some also to ;inu.
!1 Ar(hite(ture
&his section describes the common features of the SCADA products that have been evaluated at C035 in view
of their possible application to the control systems of the ;>C detectors D!E, D9E.
!1 5ard.are Ar(hite(ture
%ne distinguishes two basic layers in a SCADA system, the Fclient layerF which caters for the man machine
interaction and the Fdata server layerF which handles most of the process data control activities. &he data servers
communicate with devices in the field through process controllers. 2rocess controllers, e.g. 2;Cs, are connected
to the data servers either directly or via networks or fieldbuses that are proprietary -e.g. Siemens >!., or non(
proprietary -e.g. 2rofibus.. Data servers are connected to each other and to client stations via an 0thernet ;A5.
&he data servers and client stations are 5& platforms but for many products the client stations may also be :"G
machines. 'ig.!. shows typical hardware architecture.
'igure !, &ypical >ardware Architecture
!1" Soft.are Ar(hite(ture
&he products are multi(tasking and are based upon a real(time database -3&D?. 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.
'igure 9, 4eneric Software Architecture
>owever, it is possible to have dedicated servers for particular tasks, e.g. historian, datalogger, alarm handler.
'ig. 9 shows a SCADA architecture that is generic for the products that were evaluated.
!1! Communi(ations
*nternal Communication
Server(client and server(server communication is in general on a publish(subscribe and event(driven basis and
uses a &C28*2 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
&he data servers poll the controllers at a user defined polling rate. &he polling rate may be different for different
parameters. &he controllers pass the requested parameters to the data servers. &ime stamping of the process
parameters is typically performed in the controllers and this time(stamp is taken over by the data server. *f the
controller and communication protocol used support unsolicited data transfer then the products will support this
too.
&he products provide communication drivers for most of the common 2;Cs and widely used field(buses, e.g.,
)odbus. %f the three fieldbuses that are recommended at C035, both 2rofibus and :orldfip are supported but
CA5bus often not D@E. Some of the drivers are based on third party products -e.g., Applicom cards. and therefore
have additional cost associated with them. <)0 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.
&he effort required to develop new drivers is typically in the range of 9(# weeks depending on the compleity
and similarity with eisting drivers, and a driver development toolkit is provided for this.
!1& Interfa(ing
Application *nterfaces 8 %penness
&he provision of %2C client functionality for SCADA to access devices in an open and standard manner is
developing. &here still seems to be a lack of devices8controllers, which provide %2C server software, but this
improves rapidly as most of the producers of controllers are actively involved in the development of this
standard. %2C has been evaluated by the C035(*&(C% group DAE.
&he products also provide
an %pen Data ?ase Connectivity -%D?C. interface to the data in the archive8logs, but not to the
configuration database,
an ASC** import8eport facility for configuration data,
a library of A2*s supporting C, CHH, and <isual ?asic -<?. to access data in the 3&D?, logs and
archive. &he A2* often does not provide access to the product=s internal features such as alarm handling,
reporting, trending, etc.
&he 2C products provide support for the )icrosoft standards such as Dynamic Data 0change -DD0. which
allows e.g. to visualise data dynamically in an 06C0; spreadsheet, Dynamic ;ink ;ibrary -D;;. and %b+ect
;inking and 0mbedding -%;0..
Database
&he configuration data are stored in a database that is logically centralised but physically distributed and that is
generally of a proprietary format.
'or performance reasons, the 3&D? resides in the memory of the servers and is also of proprietary format.
&he archive and logging format is usually also proprietary for performance reasons, but some products do
support logging to a 3elational Data ?ase )anagement System -3D?)S. at a slower rate either directly or via
an %D?C interface.
!16 S(ala7ility
Scalability is understood as the possibility to etend the SCADA based control system by adding more process
variables, more specialised servers -e.g. for alarm handling. or more clients. &he products achieve scalability by
having multiple data servers connected to multiple controllers. 0ach data server has its own configuration
database and 3&D? and is responsible for the handling of a sub(set of the process variables -acquisition, alarm
handling, archiving..
!18 9edundan(y
&he products often have built in software redundancy at a server level, which is normally transparent to the user.
)any of the products also provide more complete redundancy solutions if required.
&1 $un(tionality
&1 A((ess Control
1sers are allocated to groups, which have defined read8write access privileges to the process parameters in the
system and often also to specific product functionality.
&1" 22I
&he products support multiple screens, which can contain combinations of synoptic diagrams and tet.
&hey also support the concept of a FgenericF graphical ob+ect with links to process variables. &hese ob+ects can
be Fdragged and droppedF from a library and included into a synoptic diagram.
)ost of the SCADA products that were evaluated decompose the process in FatomicF parameters -e.g. a power
supply current, its maimum value, its on8off status, etc.. to which a &ag(name is associated. &he &ag(names
used to link graphical ob+ects to devices can be edited as required. &he products include a library of standard
graphical symbols, many of which would however not be applicable to the type of applications encountered in
the eperimental physics community.
Standard windows editing facilities are provided, zooming, re(sizing, scrolling... %n(line configuration and
customisation of the ))* is possible for users with the appropriate privileges. ;inks can be created between
display pages to navigate from one view to another.
&1! Trending
&he products all provide trending facilities and one can summarise the common capabilities as follows,
the parameters to be trended in a specific chart can be predefined or defined on(line
a chart may contain more than B trended parameters or pens and an unlimited number of charts can be
displayed -restricted only by the readability.
real(time and historical trending are possible, although generally not in the same chart
historical trending is possible for any archived parameter
zooming and scrolling functions are provided
parameter values at the cursor position can be displayed
&he trending feature is either provided as a separate module or as a graphical ob+ect -Active6., which can then
be embedded into a synoptic display. 67 and other statistical analysis plots are generally not provided.
&1& Alarm 5andling
Alarm handling is based on limit and status checking and performed in the data servers. )ore complicated
epressions -using arithmetic or logical epressions. can be developed by creating derived parameters on which
status or limit checking is then performed. &he alarms are logically handled centrally, i.e., the information only
eists in one place and all users see the same status -e.g., the acknowledgement., and multiple alarm priority
levels -in general many more than @ such levels. are supported.
*t 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.. 'urthermore, it is possible to suppress alarms either individually or
as a complete group. &he filtering of alarms seen on the alarm page or when viewing the alarm log is also
possible at least on priority, time and group. >owever, relationships between alarms cannot generally be defined
in a straightforward manner. 0(mails can be generated or predefined actions automatically eecuted in response
to alarm conditions.
&16 Logging/Ar(hi'ing
&he terms logging and archiving are often used to describe the same facility. >owever, 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. ;ogging 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. ;ogging of data can be performed at a
set frequency, or only initiated if the value changes or when a specific predefined event occurs. ;ogged data can
be transferred to an archive once the log is full. &he logged data is time(stamped and can be filtered when
viewed by a user. &he logging of user actions is in general performed together with either a user *D or station *D.
&here is often also a <C3 facility to play back archived data.
&18 9e)ort :eneration
%ne can produce reports using SI; type queries to the archive, 3&D? or logs. Although it is sometimes possible
to embed 06C0; charts in the report, a Fcut and pasteF capability is in general not provided. 'acilities eist to be
able to automatically generate, print and archive reports.
&1; Automation
&he ma+ority of the products allow actions to be automatically triggered by events. A scripting language
provided by the SCADA products allows these actions to be defined. *n general, one can load a particular
display, send an 0mail, run a user defined application or script and write to the 3&D?.
&he concept of recipes is supported, whereby a particular system configuration can be saved to a file and then re(
loaded at a later date.
Sequencing is also supported whereby, as the name indicates, it is possible to eecute a more comple sequence
of actions on one or more devices. Sequences may also react to eternal events.
Some of the products do support an epert system but none has the concept of a 'inite State )achine -'S)..
61 A))li(ation De'elo)ment
61 Configuration
&he development of the applications is typically done in two stages. 'irst the process parameters and associated
information -e.g. relating to alarm conditions. are defined through some sort of parameter definition template
and then the graphics, including trending and alarm displays are developed, and linked where appropriate to the
process parameters. &he products also provide an ASC** 0port8*mport facility for the configuration data
-parameter definitions., which enables large numbers of parameters to be configured in a more efficient manner
using an eternal editor such as 0cel and then importing the data into the configuration database.
>owever, many of the 2C tools now have a :indows 0plorer type development studio. &he developer then
works with a number of folders, which each contains a different aspect of the configuration, including the
graphics.
&he facilities provided by the products for configuring very large numbers of parameters are not very strong.
>owever, this has not really been an issue so far for most of the products to(date, as large applications are
typically about G$C *8% points and database population from within an ASC** editor such as 0cel is still a
workable option.
%n(line modifications to the configuration database and the graphics is generally possible with the appropriate
level of privileges.
61" De'elo)ment Tools
&he following development tools are provided as standard,
a graphics editor, with standard drawing facilities including freehand, lines, squares circles, etc. *t is
possible to import pictures in many formats as well as using predefined symbols including e.g. trending
charts, etc. A library of generic symbols is provided that can be linked dynamically to variables and
animated as they change. *t is also possible to create links between views so as to ease navigation at
run(time.
a data base configuration tool -usually through parameter templates.. *t is in general possible to eport
data in ASC** files so as to be edited through an ASC** editor or 0cel.
a scripting language
an Application 2rogram *nterface -A2*. supporting C, CHH, <?
a Driver Development &oolkit to develop drivers for hardware that is not supported by the SCADA
product.
61! O7<e(t 5andling
&he products in general have the concept of graphical ob+ect classes, which support inheritance. *n addition,
some of the products have the concept of an ob+ect within the configuration database. *n general the products do
not handle ob+ects, but rather handle individual parameters, e.g., alarms are defined for parameters, logging is
performed on parameters, and control actions are performed on parameters. &he support of ob+ects is therefore
fairly superficial.
81 3'olution
SCADA vendors release one ma+or version and one to two additional minor versions once per year. &hese
products evolve thus very rapidly so as to take advantage of new market opportunities, to meet new requirements
of their customers and to take advantage of new technologies.
As was already mentioned, most of the SCADA products that were evaluated decompose the process in FatomicF
parameters to which a &ag(name is associated. &his is impractical in the case of very large processes when very
large sets of &ags need to be configured. As the industrial applications are increasing in size, new SCADA
versions are now being designed to handle devices and even entire systems as full entities -classes. that
encapsulate all their specific attributes and functionality. *n addition, they will also support multi(team
development.
As far as new technologies are concerned, the SCADA products are now adopting,
:eb technology, Active6, Java, etc.
%2C as a means for communicating internally between the client and server modules. *t should thus be
possible to connect %2C compliant third party modules to that SCADA product.
;1 3ngineering
:hilst one should rightly anticipate significant development and maintenance savings by adopting a SCADA
product for the implementation of a control system, it does not mean a Fno effortF operation. &he need for proper
engineering can not be sufficiently emphasised to reduce development effort and to reach a system that complies
with the requirements, that is economical in development and maintenance and that is reliable and robust.
0amples of engineering activities specific to the use of a SCADA system are the definition of,
a library of ob+ects -2;C, device, subsystem. complete with standard ob+ect behaviour -script,
sequences, ...., graphical interface and associated scripts for animation,
templates for different types of FpanelsF, e.g. alarms,
instructions on how to control e.g. a device ...,
a mechanism to prevent conflicting controls -if not provided with the SCADA.,
alarm levels, behaviour to be adopted in case of specific alarms, ...
=1 +otential 7enefits of SCADA
&he benefits one can epect from adopting a SCADA system for the control of eperimental physics facilities
can be summarised as follows,
a rich functionality and etensive development facilities. &he amount of effort invested in SCADA
product amounts to G$ to !$$ p(yearsK
the amount of specific development that needs to be performed by the end(user is limited, especially
with suitable engineering.
reliability and robustness. &hese systems are used for mission critical industrial processes where
reliability and performance are paramount. *n addition, specific development is performed within a
well(established framework that enhances reliability and robustness.
technical support and maintenance by the vendor.
'or large collaborations, as for the C035 ;>C eperiments, using a SCADA system for their controls ensures a
common framework not only for the development of the specific applications but also for operating the
detectors. %perators eperience the same Flook and feelF whatever part of the eperiment they control. >owever,
this aspect also depends to a significant etent on proper engineering.
93$3934C3S
Note: this article is based on a very similar one that has been published in the Proceedings of the
7
th
International Conference on ccelerator and !arge "#perimental Physics Control $ystems, held in
%rieste, Italy, & ' ( )ct* +,,,*
D!E A.Daneels, :.Salter, F&echnology Survey Summary of Study 3eportF, *&(C%8"B($B($", C035,
4eneva 9#
th
Aug !""B.
D9E A.Daneels, :.Salter, FSelection and 0valuation of Commercial SCADA Systems for the Controls of
the C035 ;>C 0perimentsF, 2roceedings of the !""" *nternational Conference on Accelerator and
;arge 0perimental 2hysics Control Systems, &rieste, !""", p.@G@.
D@E 4.?aribaud et al., F3ecommendations for the 1se of 'ieldbuses at C035 in the ;>C 0raF,
2roceedings of the !""L *nternational Conference on Accelerator and ;arge 0perimental 2hysics
Control Systems, ?ei+ing, !""L, p.9BG.
DAE 3.?arillere et al., F3esults of the %2C 0valuation done within the JC%2 for the Control of the ;>C
0perimentsF, 2roceedings of the !""" *nternational Conference on Accelerator and ;arge
0perimental 2hysics Control Systems, &rieste, !""", p.G!!.
5o. to (hoose SCADA e>ui)ment
by -anice .ungerford and /anetta 0or1
There are several questions that need to be answered before a final decision is made on the actual components of
a new Supervisory Control and Data Aquisition system.
!. >ow versatile is itM 'or economic reasons, it is usually better to keep as much of the current equipment in the
eisting system as is realistically possible. &he committee set up to design a system must then ask themselves
what kind of connectivity a vendor has with the eisting equipment. *f connectivity is impossible or difficult then
the question of customizing comes into play. *f a system is customized, will that make future changes, upgrades,
and maintenance even more costlyM
9. *s the vendor a recognized companyM 'or most companies, the smart move is to look at nationally known,
proven vendors of Supervisory Control and Data Aquisition equipment. *t is important that they have a history of
success stories behind them, yet also have local distribution and technical support. %nce a vendor is chosen,
listen to their eperts on recommendations for customizing the system.
@. Does it meet the requirementsM %f course, a system can have all the buttons and toys any technical person
could want, but if it doesnNt meet the needs that the evaluation committee has formulated, it isnNt worth having.
0ach department on the committee will be more concerned with one function over another. *t is important that
they rate, on a scale of one to !$, the importance of each feature or need so that an acceptable compromise can
be reached.
A'aila7le te(hnology
3eliable Supervisory Control and Data Aquisition systems are not only used for operations, but for
measurement, forecasting, billing, historical analysis, and planning. &odayNs marketplace is seeing a continued
rise in technological innovations. &he systems required today must meet a whole new level of automation, such
as interface to equipment and a multitude of tools that were not available even five years ago. Along with that we
are seeing hardware prices dropping, standardization of software, a narrowing supplier range, and the compleity
of Supervisory Control and Data Aquisition systems skyrocketing.
:hether you are designing a Supervisory Control and Data Aquisition for the first time or upgrading an eisting
system, it is important to review the system components before you decide on equipment. 7ou will need to
evaluate the following,
!. &he telemetry network. A telemetry network provides the communication pathway in a Supervisory Control
and Data Aquisition system. *t is made up of several components, topology, either point(to(point, point(to(
multipoint, or multipoint(to(multipoint/ transmission modes, the way information is sent and received, -network
topology determines your mode of data transmission./ and link media O hard wire, fiber optics, or radio -micro
wave..
*n order to determine which type is best for your system, ask the following questions,
A. :hat are the data transmission needs of the applicationM
?. :here will the remote sites and control center be locatedM
C. :hat is the distance between sitesM
D. :hat link media services are available in these areasM
0. :hat do you want to spendM
After answering these questions, your system integrator can help you make the appropriate choice for your link
media.
Check protocol. *n order for the host, or master, and the remote terminal units to communicate with each other
there must be a common method of encoding and decoding the messages between them. &his is referred to as the
protocol. *n order to choose the one best suited to your application, consider the following,
A. Avoid proprietary protocols. A closed protocol leaves the end(user with fewer options for integrating
equipment from various vendors.
?. Select equipment that supports well(behaved, open protocols, that are well(documented and supported by
many vendors, such as )odbus.
C. Do you need to connect to eisting equipmentM
)any Supervisory Control and Data Aquisition systems require the )odbus protocol, yet designers may, for
various reasons, choose to install Allen(?radley units which do not support )odbus. &hat is where third(party
protocol suppliers may have the answer to this common problem. &here are a number of third(party protocol
suppliers available that allow eisting protocols to communicate with equipment made by different
manufacturers. 'or instance, 2roSoft &echnology, *nc., specializes in communication solutions for 3ockwell
Automation8Allen(?radley. 2roSoft has recently announced a new line of products called )ulti <endor *nterface
solutions. &hese product offerings will provide off(the(shelf base platforms with software tools to allow
customized solutions for serial communication across 3ockwell AutomationNs 2;C, S;C, Control;ogi, and
';06 platforms. :ith these modules, developing a custom serial communication application will mean an easy
to use, well(supported, and full(feature development environment across all 3ockwell Automation platforms.
9. Data communication equipment. :hatever telemetry network you have chosen will determine the appropriate
data communication equipment you will need. &he equipment is simply the link between a transmission medium
and the data terminal equipment, or it can be viewed as the data transport mechanism between the host computer
system and the remote terminal unit. Data communication equipment can include telephone and radio modems,
microwave, or satellite transmission equipment. 5o matter which communication method is chosen, Supervisory
Control and Data Aquisition systems usually use a communication format called master(slave. &his means that
all conversations are initiated by the master station. &he remote terminal unit, or slave, replies only when it
receives a message. &he master controls all conversations.
An in(rack, or stand(alone, solution is usually more reliable than a 2C(based system due to the greater reliability
of 2;C hardware vs. 2Cs.
@. &he master station. &he master station gathers field data directly from the remote stations, or submaster, and
provides monitoring and control over the entire system through its operator interface. &here are several master
station types available including,
A. <A6 or 15*6(based computer. 1sed in etremely large applications that may also require submaster stations
to gather data, support local operator interface, support logging of alarms and events, communicate with remote
stations, and interface with a larger master station.
?. 2ersonal computer. 1sed in small(to(medium(sized applications. &here are many vendors of Supervisory
Control and Data Aquisition software for the 2C that allow acquisition of data, graphical interface, historical data
storage, and alarming.
C. 2rogrammable controller. *n order to determine whether a 2;C should be used in your application, ask
whether the master station needs to control local input8output, whether the application requires master station
redundancy, and how many remote stations your application requiresM
A. 3emote terminal units. An 3&1 is a microprocessor(based unit, specifically designed for real(time processing
of input and output of data. remote terminal units also log alarms, report status to the master station, and carry
out the commands from the master station. *n order to choose the appropriate device for your application, ask the
following questions,
A. :hat protocol does your application requireM
?. Does it use analog input8outputM
C. >ow many input8output points does it requireM
D. Do you need the remote station to collect data without being told to by the master stationM
0. Do you need online programming, faster ladder logic speeds, and a built(in clock8calendarM
G. Data distribution. *t is also important to evaluate the mechanisms available for data distribution in a
Supervisory Control and Data Aquisition system.
A. :ho needs access to the informationM
?. >ow oftenM
C. :hat network interfaces are possible with the systemM
D. Can the system function as a &C28*2 server to deliver archived data to other users as well as a client to deliver
data to a serverM
%nce you have gone through this check list and have the answers to these questions, you can begin your search
for the appropriate vendor. )ost will begin with the vendors they already use. ?ut, donNt be afraid to do some
homework on competitorsN products. Check out trade magazines, even if they arenNt in your particular industry.
Ceep in mind, for eample, that a Supervisory Control and Data Aquisition system that has been installed in a
water8waste water utility system may have some of the same needs and features that are needed for a gas
pipeline.
Check out the ads, read some articles, then make some phone calls to vendors who seem to fit the criteria you are
looking for.
#. ?udget scope and bidding framework. At this point, the evaluation committee should have a firm grasp of the
requirements and the technology available to put together an efficient Supervisory Control and Data Aquisition
system. *t is then important to communicate this understanding with the bidding companies involved. :hen
preparing a formal bid package, instructions to bidders should specify, in detail, the functionality that is epected
from the new system including, software specifications, hardware specifications, communication needs,
performance standards, training, testing, and technical support.
&he bid package should be specific enough to allow bids to be evaluated on a level playing field. *n other words,
the committee should be able to compare apples to apples. *t should also be remembered that the bids will also
function as the framework for the final contract, so all pro+ect(specific requirements should be included to avoid
problems during implementation. %pen communication with all parties involved is the key to a successful
bidding process.
?uying Che(/ list
&here are some guiding principles to keep in mind when procuring a new Supervisory Control and Data
Aquisition system,
!. &he new architecture must be based on open standards.
9. *t must have the fleibility to integrate new and eisting systems.
@. *t must be reliable and supportable.
A. 1se non(proprietary equipment only.
G. 1se proven technologies when possible and be able to integrate new technologies when advisable.
#. &he ability to implement the new system without causing ma+or disruptions to business operations.
L. Selling the pro+ect to the various departments likely to be affected.
B. ?uild communication and teamwork between the company and suppliers.
+oints to (onsider
Consider the following communications(software questions before making a final decision,
A. Can the system support multiple communications ports with the same field device protocolM
?. Can it support different protocolsM
C. >ow many ports can be used for concurrent communicationsM
D. *s the system capable of supporting concurrent interface to multiple types of communications mediaM
0. 1sing the same communications port, can the system support multiple(vendor protocols to different types of
equipmentM
'. Can the user fine tune communications through configuring command timeouts, retries, and polling
frequencies at the command and device levelM
%nce you have narrowed down your choice of data communication equipment, choose your master and remote
station devices. &hen, you may come back and finalize your transmission system.
2easuring )rogress
During the pro+ect implementation, it will be important to set measurable milestones for the company and the
suppliers involved. &hese should be easy to evaluate through direct observation of the system in its various
stages and should be written into the contract of all suppliers. &hese should include,
!. Software design, all parties should have a good understanding of the pro+ect(critical requirements needed.
Software demonstrations should be completed early in the process.
9. 'actory acceptance before system shipment.
@. Site acceptance to ensure the system is ready for commercial operation.
A. 'inal system acceptance.
%nce the new Supervisory Control and Data Aquisition system is up and running, it is important that a post(
installation analysis be completed to identify pro+ect mistakes and the factors which contributed to the pro+ectNs
success. :ith the new technological advances becoming available each year, this analysis may be beneficial if
and when another revision becomes necessary in the future.
Janice >ungerford and Danetta 7ork represent 2roSoft &echnology, *nc. &his article was adapted from a n
05&0;0C paper and is the second in a three(part series.
Reprinted from Gas Utility Manager Magazine
July 2001
SCADA 5oney4et +ro<e(t: ?uilding 5oney)ots for Industrial 4et.or/s
<enkat 2othamsetty and )atthew 'ranz
Critical *nfrastructure Assurance 4roup-C*A4.
Cisco Systems, *nc.
Lin/s
Download
)ailing ;ist
2;C Simulation Case Study
>oneyd ( a small daemon that creates virtual hosts on a network. &he hosts can be configured to run arbitrary
services, and their personality can be adapted so that they appear to be running certain operating systems
4e.s @ ,)dates
#8$!8$A8-released version $.9. ( 'ied the bug regarding the absense of modbus>drs.py, included sample
nmap %S fingerprints of some 2;Cs, included a test file to generate custom )odbus packets to test the
modbusSrve.py implementation
G8!@8$A ( )a+or cleanup of content
@89$8$A ( 2;C Simulation scripts available for down and 2;C Simulation Case Study complete.
O7<e(ti'es
&he short(term goal of the pro+ect is to determine the feasibility of building a software(based framework to
simulate a variety of industrial networks such as SCADA, DCS, and 2;C architectures. :e plan to document the
requirements and release proof of concept code -in the form of honeyd scripts. so that a single ;inu host can
simulate multiple industrial devices and comple network topologies. 4iven the variety of deployments and the
lack of standard, well(defined architectures for industrial networks, this pro+ect attempts to create the building
blocks so that users can simulate their networks own networks((not make assumptions about what Freal worldF
SCADA8DCS82;C look like. Assuming deployment of FSCADA >oney5etsF ever reach critical mass, the
longer term ob+ective of the pro+ect is to gather information about general attack patterns and specific eploits
that could be used to write signature for commercial and %pen Source *DS products.
Introdu(tion
&here is still little information about SCADA vulnerabilities and attacks, despite the growing awareness of
security issues in industrial networks. As is the case with *& security, owner(operators are often unwilling to
release attack or incident data. >owever, unlike *& products and protocols, there are not the sort of public
repositories of vendor advisories and vulnerabilities in industrial devices. Although some vulnerability research
is being conducted in this area, very little has been released publically and no FSCADA security toolsF -whatever
that might mean. have been released to the public.
&o address these limitations, this goal of this pro+ect is to provide tools and to simulate a variety of industrial
networks and devices. :e see several uses for this pro+ect,
?uild a >oney5et for attackers, to gather data on attacker trends and tools
2rovide a scriptable industrial protocol simulators to test a real live protocol implementation
3esearch countermeasures, such as device hardening, stack obfuscation, reducing application
information, and the effectiveness network access controls
$eature 9e>uirements
?ased on our knowledge of industrial network applications, products, and protocols, we identified the following
requirements,
Indi'idual De'i(e Simulation
&o simulate individual devices, the following functionality is needed,
Sta(/ le'el, &o simulate the &C28*2 stack of a 0thernet(based device device to a script kiddie type
attacker who is scanning the network with %S detection tools such as 5map and 6probe.
+roto(ol le'el, &o simulate industrial protocols for skilled attackers who have the tools which
interrogate protocols and want to do something meaningful using the protocol features
A))li(ation le'el, &o simulate various applications on a SCADA device such as web servers and
management applications such as S5)2 and &elnet.
5ard.are le'el,)any of the SCADA devices use serial interfaces such as modems and 3S9@9
interfaces for both SCADA protocol communication and for management purposes. An attacker who
either Flogs intoF a SCADA device or has access to the serial network, needs to be presented with a
serial device and8or a protocol communication over a serial device.
Simulate 4et.or/
:e need to simulate various entry points so that when an attacker encounters a perimeter device, he will be
presented the same network as a real SCADA network at that particular network entry point
<arious network entry points that we need to simulate include,
!. A router dire(tly (onne(ted to the Internet, Control system networks are typically not directly conne
a control network is located inside a corporate network. Assuming the corporate network as *nternet, we
need to simulate the entry point of a router that seperates the control network and the corporate
network. &he devices that are normally connected to such routers would be *ndustrial 0thernet switches
or industrial devices with an *2 stack, such as some *2 enabled 2;Cs and wireless access points.
9. Dire(t serial de'i(e,Some of the industrial devices have a modem that can be directly dialed into from
a 2S&5. :e need to simulate a Fmodem serverF that can take connections and behaves like a industrial
device or is connected to a industrial device.
@. A 3thernet ena7led industrial de'i(e dire(tly (onne(ted to the Internet, Such a scenario should be
the same as simulating the stack, the protocols and applications on that device and connecting that to
*nternet
A. An 3thernet serial gate.ay dire(tly )lugged into the Internet,An 0thernet serial gateway is a bridge
between the *2 network and the serial interface. &he *2 side of the device would be connected to the
network, either a *ndustrial switch or a router to which other *2 industrial devices are connected to. &he
serial side of the device would be connected to a serial device or a serial network.
G. Wireless, :ireless is one of the entry points into a *ndustrial network. )ost of the *ndustrial wireless
devices use proprietary wireless protocols and some of them use B$9.!b standard. &ypically the serial
interface of the device would be connected to a wireless bridge.
#. 9emote des/to) a((ess and 52Is,&he >uman )achine *nterfaces and the software that
communicates with *ndustrial devices usually run on a :indows machine. Administrators who want
remote access to these devices would typically run a remote desktop viewer, such as <5C or 2C
anywhere. An attacker would normally find it through a port scan = after he gets into the control network
and might get to it using a <5C client. Simulating this would probably need a custom made <5C
protocol simulation.
L. 9emote A((ess Ser'er *9AS-,Another possible entry point into a control network is to dial into the
network using 222 and use the 222 password to authenticate yourself to a 5etwork Access Server and
then directly access the *ndustrial device.
Ca)ture the atta(/er tools and tra(/s
%ur scripts need to capture the attacker tools and tracks. &hat should include keystroke logging and facilities to
capture the tools and binaries he might be up loading, if the attack. %ur scripts also need to capture network
traffic.
9e'ie. of existing te(hnologies and rela'en(y
5oneyd
>oneyd has facilities for easy simulation of &C28*2 stacks and applications.
>oneynet takes 5map and 6probe signatures through configuration files and sends packet responses to scans
matching those signatures. 1sers can set up profiles, mapping *2 addresses that >oneyd should respond to a
corresponding device profile. :hen attackers 5map or 6probe scan the *2 address which >oneyd is taking care
of, he will be returned with packets matching the corresponding device profile.
&herefore using >oneyd, it would be possible to simultaneously simulate stacks of multiple *2 based *ndustrial
devices, provided the corresponding scanning tools -5map or 6probe. has the knowledge of the signature. As of
now, there are no signatures of *ndustrial devices in 5map=s database.
>oneyd allows the user to listen on a port and run a script on that particular port when anybody connects to that
port. As of now, there are many scripts contributed to the pro+ect, which can simulate web pages, :S'&2 servers
and Cisco telnet servers.
1sing this feature on >oneyd, it is possible to write scripts that simulated various *ndustrial 0thernet protocols.
'or eample, it would be possible to simulate a )odbus8&C2 server on port G$9 and 0ther5et8*2 on ports
AAB!B89999.
Serial interfa(e simulation
)any industrial network devices use 3S(9@98ABG for communication. &ypically the serial port of a 2C would be
directly -or indirectly, via a serial 0thernet gateway. connected to the serial port of the device. &here would be a
software running on the 2C, which sends commands to the device over the serial interface. ?y some accounts
there are hundreds of serial protocols in use in SCADA networks. Some of the more common protocols are
)%D?1S and D52.
:e need to simulate those protocols over the serial port, so as to present a protocol interface to an attacker who
connects to the serial port. )any languages support serial interface programming including 2ython and Java. :e
were able to achieve serial communication through a open source 2ython serial programming module
-pyserial.sf.net..
Simulating =#"1
&he >ostA2 driver-http,88hostap.epitest.fi8., replies for B$9.!b management packets and converts a client adapter
an access point. &he driver can be used to simulate an access point which is inside a automation or a SCADA
network
Ca)turing atta(/ tools and (a)turing the atta(/ersA tra(/
&hough not part of >oneyd, there are lots of keystroke loggers available. :e need a mechanism to track the
attacker on the web interface of the device. :e do not know of any tools which can provide that functionality,
however we eplored some possibilities where the the Java applet -running on the FattackersF web browser. is
able to comm
Challenges
De)loyment and Testing
An ideal deployment site for such a script would be a subnet close to a real *ndustrial8SCADA network or a
phone number which belongs to a SCADA8Automation plant. :e are not aware of any active and on(going
SCADA specific attacks, it would be difficult to get a SCADA aware attacker into the honeypot.
Send comments to scadahoneynet(talkPlists.sourceforge.net or ciag(toolsPcisco.com
SCADA 5oney4et
+LC Simulation Con(e)ts, Design, and Im)lementation
<enkat 2othamsetty
Cisco Systems, *nc.
Critical *nfrastructure Assurance 4roup -C*A4.
?a(/ground
2rogrammable ;ogic Controllers -2;Cs. are common in some industrial applications -especially discrete
manufacturing. and increasingly have network interfaces which support 0thernet and &C28*2 protocols as well
as more traditional communication interfaces such as )%D?1S, Device5et, Contrl5et, 'oundation 'ieldbus,
etc.
As is the case with any network device, different vendors implement their own shells on telnet and support
various '&2 commands, depending on their application requirements. &he 0thernet communication module of
the 2;C typically runs an embedded operating system that includes standard network protocol as well as
implementations of industrial network protocols such as )odbus8&C2 or 0ther5et8*2. 'or eample, telnet and
'&2 servers are common and have identifying information which can be used to determine the vendor and
version of software. 0ven on the industrial protocol side, we saw that not all 2;Cs support all commands of a
given industrial protocol, so that implementations can be fingerprinted. Depending on the type -and capabilities.
of the device there may be slight differences in the protocol.
All of these characteristics make it possible for attackers to identify specific versions and vendors of device and
allow us to be able simulate the devices as well.
Im)lementation A))roa(h
:e followed the following approach when simulating a 2;C,
*mplement the generic features so that users can easily change them, add new features and re(submit them
&he feature implementation should be so that the code will serve as eamples for the users to change it
according to their own needs.
%nce the users submit enough code for more implementations, we visualize putting them into templates so
that a generic configurable engine can load them according to a defined configuration
Com)onents 4eeded
&he following are the network components in a 2;C that need to be simulated,
&he &C28*2 Stack of the 2;C
&he simulation of the )odbus8&C2 server implementation.
&he simulation of the '&2 server, that is found on some 2;Cs.
&he simulation of the &elnetd server, that may be found on some 2;Cs.
&he simulation of the management >&&2 server, which increasingly common on 2;Cs and other industrial
network devices.
Note that the scripts above can be used along with honeyd or standalone and need root permissions because
they have to bind themselves to previleged ports below +23&*
Simulating the TC+/I+ Sta(/ of the +LC Communi(ation 2odule
*n order for >oneyd to simulate the &C28*2 stack of a 2;C, adding the &C28*2 signature of the device to the
honeyd=s nmap.prints file would be sufficient. ?ut in oder for the attacker to feel that the stack is a 2;C stack,
the signature has to be in the database of the scanning tool that he is using. &hough we tested that by putting the
signature in nmap(os(fingerprints file -which is 5map=s fingerprint database., we do not know of any scanner
having the signature of any 2;C at the time of writing this document.
Simulation of the 2od7us/TC+ ser'er
&he 2;C can have multiple industrial protocol implementations which will listen at their corresponding ports for
packets from the corresponding clients.
:e decided to simulate the )odbus8&C2 server as a proof of concept because the protocol is simple.
)odbusSrvr.py starts out with listen45 method, which binds port G$9 and waits for client connections. %nce a
client gets connected to it, it initiates a thread to serve the client and continues to listen on the port for further
client connections. &he thread calls the process/ata45 method which etracts the top )odbus >eader data and
calls the method sendResponse45 to send the correct response.
*n )%D?1S protocol, the response depends on the function code of the query. Since we are not the eperts of
the protocol and we do not necessarily epect the users and developers of SCADA honeynet to be eperts on
industrial protocols, we followed and recommend the crude approach of observing and analyzing the
communication packets between some clients and the 2;Cs. ?ased on the observation and analysis we chose to
implement the Ftop responsesF and to send an Ferror codeF for the rest of the queries. &he following are the
observations,
&here are two types of heavily used queries, the writes and the reads, and the target can be either coils
or registers.
'or responses to read requests, the response would be to give back data, equivalent to the number of
bits requested in the read request. *f its read multiple targets, then you usually give multiple modbus
headers.
'or responses to write requests, you give the bit8byte8word c ount of the data written
:e implemented the responses to readQcoil -function code !., write multiple registers -function code !#.,
diagnostics -function code B and the eception response with code !-unknown function code.. :e welcome the
users to study and analyze other responses and implement them. &he script can be found in plc8modbusSrvr.py
file. :e also included our test file, modbusScanner.py, to send modbus packets towards the modbussrvr.py
implementation. &he users should manually go into modbusScanner.py and he can edit values of different
modbus headers.
Simulation of the $T+ ser'er
&he honeyd has shell script based '&2 simulation, we decided to rewrite it in 2ython because it is an easier
language for and we want to add more functionality to it. :e implemented the following commands,
&he user command, when the user gives a username
&he password command, when the user gives the password
&he list command, when the user gives a ls command
&he syst command, which gives the user information about the system
&he port for transferring data for various commands *t has various points where it writes information into the
logfile and the user needs to change that to suite his or her own needs +ust by invoking write;og method and
passing it the string to write. &he write;og methos opens up F8var8log8 scadahoneynet.logF and appends
information to it by default. &he user should change the responses given as variables given at the top -such as
!istCommandResponse and $yst CommandResponse of the file which suites their needs. &he script can be found
in plc8vworks(ftpd.py
Simulation of the Telnet ser'er
:e decided to write a specific telnetd script because most of the 2;Cs run embedded systems and the shell has a
unique set of commands. :e implemented help and ls and cwd commands and the user gets the list of commands
when he +ust hits return. &he script can be found in plc8vworks(telnetd.py
Simulation of the We7 ser'er
'requently the user connects to the web server of the device and a Java applet is downloaded to the client and
runs within the web browser. *n some cases, the applet will them make connection back to the 2;C using
protocols like )odbus8&C2 and '&2 for gathering data. &he concept of an applet tracking the information of the
downloader is new to the >oneynet world, we call them F>oney AppletF. &he problem with applets is that they
would not be allowed to communicate with any other hosts other then the hosts that served the applet
-http,88+ava.sun.com8sfaq8.. So make sure you have the hos*2 variable as the eact hostname tof yours. Since
each 2;C has its own user interfaces, again our design and implementation goals are to write a generic enough
proof of concept code which touches on most of the features in 2;C applets. :e used Java Swing classes to
draw the Applet and we used Java S15=s !.A.9 for development.
&he ?utton, and feature to track button clicks
&he &etfield, and feature to track tet addition and removal
&o connect back to a host on port G$9 and give information back. the user can run netcat like &C2 listener to
get the data back from the applet.
&he connect6ac145 will connect back to the ip described statically in the code, encoded into the variable,
host. :e called connect back when the CA button is pressed or when the test is changed in &ransmitt?utton for
Demonstration purposes
&he use of threads and repaint with changing numbers in tet fields &he script can be found in
plc8StatusApplet.+ava *t needs to be debated whether the Applet can be replaced with a 2>2 script and how much
would an attacker know about it if it were a 2>2 script
Send (oments to s(adahoneynet0tal/Blists1sour(eforge1net or (iag0toolsB(is(o1(om
$C/ software designed by electricity $C/ e#perts,
for electricity industry $C/ operations*
Intuiti'e @ safe o)eration
i2ower is designed specifically for electricity network control. &he i2ower 41* is consistent, clear and
immediately intuitive to electricity SCADA %perators.
$ast im)lementation
4raphics configuration is typically the most time consuming implementation task. i2ower commonly reduces 9$
or more steps into one drag(and(drop, while delivering systems that are inherently consistent and easy to
maintain.
9elia7le
Client(server architecture, distribution of core applications and redundant networking add to a high(reliability
SCADA system.
$uture )roofed in'estment
3unning on top of i'*6 -*ntellution,1SA. i2ower is an investment in a state(of(the(art, open, standards(based
system, delivering the best of the :indows environment, *nternet technology and advanced data(sharing
facilities
O)erational 7enefits:
Consistent display of information
An intuitive interface
Clear, precise operation
'ast and safe operation
2anagement 7enefits
;arge reduction in configuration costs
'ar shorter system implementation time
Consistency without micro(management
;ower maintenance costs
)aintenance without dependence on niche *& skills
As you eplore this site we trust you discover how i2ower intelligently simplifies the installation, use,
ownership and rewards of SCADA for electricity industry businesses.

Intuiti'e, Safe O)eration
i2ower is developed specifically for monitoring and control of electricity systems and networks. &he i2ower
41* is consistent, clear and immediately intuitive to electricity SCADA %perators. i2ower delivers,
Consistent display of information
An intuitive interface
Clear, precise operation
'ast and safe operation

Clicking on a breaker, switch, transformer or other device on your screen pops up precisely the right dialog....
Circuit ?reaker dialog
&ransformer &ap 2osition dialog
C C C C (li(/ on the ta7s in these dialogs to learn more C C
C C

$ample /isplay showing )perator dialogs
click to view -#$k?.
Intelligent Automated Configuration

&he single largest cost when installing a new SCADA is the time taken to configure the system. i2ower includes
*ntelligent Automation Software -*AS. that drastically speeds the configuration process. *AS has the additional
benefit of producing highly consistent systems that are easy to maintain.
1sing *AS is simply a case of dragging the required electricity symbol and dropping it on to the S;D being built.
&his action triggers automation software that eliminates many database and display configuration steps. i2ower
reduces what might in some systems be 9$(@$ configuration steps to a single action.
Consistent Configuration
All devices produced using i2ower *AS look and operate the same way. &he operational benefits are significant
and obvious. *mportantly this consistency is achieved by default rather than by careful management. &his
reduces the burden on ongoing management and training of staff, and separates the viability of the system from
the epertise of key individuals.
+ur)ose07uilt O)erator dialogs
Auto0generated Auxiliary Information S(reens
Auto0generated Auxiliary Information S(reens

)any of the screens commonly required in a SCADA system are tabular displays of similar layout and content.
'or eample every transformer may require an information screen to display the status of the many transformer
alarms, plus other analogues and status tags related to the transformer. *AS further reduces system configuration
time by completely automating the production of these Auiliary *nformation Screens. %nce again, these screens
are entirely consistent throughout a system, helping to make the %perators +ob simpler and safer.
Circuit 6rea1er u#iliary Information $creen
O)en, 9o7ust Ar(hite(ture

Distri7uted 4et.or/ing
i'*6Ns networking design incorporates two basic principles, true distributed processing and on(demand data
transfer.
Distri7uted +ro(essing
)any systems operate in a hierarchical fashion that leave individual computers vulnerable to system failures
anywhere on the network. &he architecture of i2ower allows you to distribute critical functions among nodes on
the network.
*n a distributed processing network, each node independently eecutes the tasks assigned to it. %ne advantage of
this strategy is that nodes can be taken off(line without bringing the whole network down. :hen a node looks for
data from an off(line node, the networking application notifies the requesting node, so that the node handles the
loss of data gracefully. 0ven though each node has integrity as an independent station, nodes can also access data
anywhere on the network. 'or eample, a <iew node can display a picture with links to many different SCADA
nodes.
Sessions
:ith i2ower you can selectively configure which nodes can access data from SCADA nodes on the network. A
communication link between two nodes over a network is called a session.
Dynami( Conne(tions
7ou can also configure your node to automatically make connections online to remote SCADA nodes that are
not specifically configured on your node. &hese connections are called dynamic connections.
On Demand Data Transfer
Some control systems require every node that uses data from a SCADA node to have a copy of the entire
database stored locally. &he resulting network traffic can use significant system resources. &o conserve system
resources for local tasks, i2ower reads and writes data on demand and only moves requested data over the
network.
$ile Storing and Sharing
1sing i2ower and the built(in file sharing capabilities of :indows 5&, you can store data that is needed by
several nodes in one convenient location. 1sing the :indows 0plorer, you can establish a networked drive
connection to any other node in your local network. %nce established, you have instant access to any shared files
on that node, including databases, pictures, and other important files.
CentraliDed +ro(essing
Some applications only need one node to perform the required functions. *t is easy to convert a distributed node
to a stand alone node or a stand alone node to a distributed node. i2ower operates +ust as smoothly in a single
computer environment as it does in a distributed computer environment.
9edundan(y
i2ower includes a powerful redundancy feature that maimizes system performance by recognizing multiple
paths to your data. Should a SCADA node or ;A5 connection become unavailable, i2ower can switch from one
path to another automatically. &he process of switching from one connection to another is known as failover.
'ailover works the same whether you are using backup SCADA or ;A5 redundancy.
3edundancy allows you to connect a <iew node to both primary and backup SCADA nodes that are connected to
the same 3&182;C. *f the connection to the primary SCADA node is lost, i2ower automatically fails over to the
backup SCADA node. :ith ;A5 redundancy, you can establish two physical network connections between a
<iew node and a SCADA node so that if one network path is lost, i2ower automatically fails over to the other
network path. &hese two features can be used together for the highest level of reliability.
Ser'er 9edundan(y 2odule *S920"-
S3)(9 is an additional redundancy module for either i'*6 or i2ower systems.
O)en System Standards
i2ower is a highly open system developed using the best industry standards and practices.

5igh Te(h Ser'i(es
+rodu(tion @ La7oratory Automation
Systems Integration, Consulting, @ Training
SCADA 'actory R ;aboratory Automation Software
%ur definition of SCADA or Supervisory Control and Data Acquisition
software is,
Computer based
Alarms
Data acquisition
%perator interface
5on real(time control
Database and ;og 'iles
3eports and *nformation Sharing

Com)uter ?ased
:e feel that SCADA software must have all possible types of connectivity
and integration. &his means serial ports, 0thernet, 2C* slots, and the ability to
run a wide variety of applications. 2;Cs and simple operator interfaces -i.e.
not based on the regular :indows operating system. are too limited in their
functionality and capabilities. Click for industrial computers or <isual ?asic
and CS.
Alarm and 0vent )onitoring
A SCADA system must be able to detect, display, and log alarms and events. :hen there are problems the
SCADA system must notify operators to take corrective action. Alarms and events must be recorded so
engineers or programmers can review the alarms to determine what caused the alarm and prevent them
happening again.
Data A(>uisition
SCADA must be able to read data from 2;Cs and other hardware and then analyze and graphically present that
data to the user. SCADA systems must be able to read and write multiple sources of data. Click here for more
on data acquisition.

%perator *nterface
A SCADA system collects all of the information about a process. &he SCADA system then needs to display this
data to the operator so that they can comprehend what is
going on with the process. Click here for more on
operator interfaces.




4on 9eal0Time Control
'or simple control requirements, the SCADA system should be able to perform control instead of a 2;C.
>owever, for anything other than simplistic control we prefer a 2;C or soft 2;C to do the real(time control with
SCADA doing the non(real(time control. &he SCADA system is the medium between the operator and the real(
time controller. *t allows the operator to control the system, such as start a new batch, load a new recipe, etc.

Data7ases and Data Logging
)ost applications require recipes, data logging, and other means of reading and writing databases. &he great
thing about SCADA systems is that they can log incredible amounts of data to disk for later review. &his is
helpful for solving problems as well as providing information to improve the process. )any different methods
should be available including, plain tet, binary fied column, Comma Separated <ariable -CS<., 6);, 0cel,
Access, SI;, SI; Server, %D?C, web services.

9e)orts and Information Sharing
:hat good is a SCADA system and all this information if you can=t share it with othersM Some of the reports
overlap with the previous description of databases and data logging. 'or eample, your users might prefer that
you put the results into an 0cel spreadsheet or database so that they can use their own tools for creating the
report. %r the users might want you to create reports in )icrosoft :ord format.
7ou also must share data with other users. Such as windows sockets, web server, and web services. &hese three
methods would allow almost every computer around the world be able to access and use the information
provided they have the correct permissions.


SCADA Soft.are Lin/s
Computer ( 2;C communications
Afcon -2(C*).
Citect
4enesis by *conics
*ntellution
&hink R Do
1S Data 'actory ;ink
<isual ?asic and CS
:onderware