SCADA systems are used to monitor and control industrial processes and facilities. A SCADA system gathers real-time data from the field using devices like programmable logic controllers, analyzes the data, and displays organized information at a central control room. SCADA systems have become more advanced over time and are now used in demanding applications like large particle physics experiments to monitor systems like cooling, ventilation and power distribution.
SCADA systems are used to monitor and control industrial processes and facilities. A SCADA system gathers real-time data from the field using devices like programmable logic controllers, analyzes the data, and displays organized information at a central control room. SCADA systems have become more advanced over time and are now used in demanding applications like large particle physics experiments to monitor systems like cooling, ventilation and power distribution.
SCADA systems are used to monitor and control industrial processes and facilities. A SCADA system gathers real-time data from the field using devices like programmable logic controllers, analyzes the data, and displays organized information at a central control room. SCADA systems have become more advanced over time and are now used in demanding applications like large particle physics experiments to monitor systems like cooling, ventilation and power distribution.
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
&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