GFS For Power Industry For Consultants

SCADA System Software
(for Electrical Distribution monitoring and control)
Guide Form Specification
3/1/2006
2004 GE Fanuc Automation, Inc.
SCADA System Software - Specification

1 March, 2006 Page 2of 53
Table of Contents 1 INTRODUCTION ............................................................................................................................ 5 1.1 STANDARD SOFTWARE PRODUCTS ............................................................................................ 5
OPERATIONAL FACILITIES.................................................................................................................. 6 1.2 DISPLAYS ................................................................................................................................. 6 1.2.1 Pan, zoom and declutter .................................................................................................... 6 1.2.2 Real-time and historical trends .......................................................................................... 6 1.2.3 Tabular information lists..................................................................................................... 7 1.2.4 Tabular displays of database points .................................................................................. 8 1.2.5 Tabular displays for secondary points ............................................................................... 9 1.2.6 Operator Notes .................................................................................................................. 9 1.3 DISPLAY NAVIGATION.............................................................................................................. 10 1.3.1 Menu system.................................................................................................................... 10 1.3.2 Display links ..................................................................................................................... 10 1.4 USER INTERFACE DIALOG ....................................................................................................... 10 1.5 OPERATOR CONTROL ............................................................................................................. 11 1.5.1 Select before operate....................................................................................................... 11 1.5.2 Control interlocking .......................................................................................................... 12 1.5.3 Other control requirements .............................................................................................. 12 1.6 MANUAL OVERWRITE .............................................................................................................. 12 1.6.1 Applying a manual overwrite............................................................................................ 12 1.6.2 Display of manual overwrites........................................................................................... 13 1.6.3 Manual overwrite list ........................................................................................................ 13 1.6.4 Altering or removing an existing manual overwrite.......................................................... 13 1.7 CONTROL TAGGING ................................................................................................................ 14 1.7.1 Applying a control tag ...................................................................................................... 14 1.7.2 Attempts to control a control tagged device..................................................................... 14 1.7.3 Removal of a control tag .................................................................................................. 14 1.7.4 Control tag list .................................................................................................................. 15 1.8 INFORMATION TAGGING .......................................................................................................... 15 1.8.1 Applying an information tag ............................................................................................. 15 1.8.2 Information tag list............................................................................................................ 15 1.8.3 Removal of a information tag........................................................................................... 16 1.9 SCAN CONTROL...................................................................................................................... 16 1.9.1 Display of off scan points ................................................................................................. 16 1.9.2 Off-scan List..................................................................................................................... 16 1.10 ALARMS ................................................................................................................................. 16 1.10.1 Alarm types.................................................................................................................. 17 1.10.2 Alarm priorities and filters ............................................................................................ 17 1.10.3 Alarm areas ................................................................................................................. 17 1.10.4 Alarm destinations ....................................................................................................... 18 1.10.5 Auto alarm manager .................................................................................................... 18 1.10.6 Alarm notification ......................................................................................................... 18 1.10.7 Alarm acknowledgment ............................................................................................... 18 1.10.8 Other alarm requirements............................................................................................ 19 1.10.9 Alarm disabling ............................................................................................................ 19 1.10.10 Alarm summary display ............................................................................................... 20 1.11 OFF NORMAL LIST .................................................................................................................. 20 1.12 EVENTS ................................................................................................................................. 20 1.12.1 Sequence of events..................................................................................................... 21 1.12.2 User events.................................................................................................................. 21 1.12.3 Event storage .............................................................................................................. 21 1.12.4 The events list ............................................................................................................. 22 1.12.5 Reviewing historical events ......................................................................................... 22 1.13 DATA ARCHIVING & REPORTING .............................................................................................. 22 1.13.1 Data file handling......................................................................................................... 22
gfs for power industry for consultants

1.13.2 Archive configuration ................................................................................................... 22 1.13.3 Displaying archived data ............................................................................................. 23 1.13.4 Reporting options ........................................................................................................ 23 1.14 PRINTING ............................................................................................................................... 23 1.15 ONLINE HELP ......................................................................................................................... 23 1.15.1 Program help ............................................................................................................... 23 1.15.2 Context sensitive help ................................................................................................. 23 1.15.3 Custom help................................................................................................................. 23 1.16 DOCUMENTATION ................................................................................................................... 23 2 AUTOMATION FACILITIES ......................................................................................................... 25 2.1 CALCULATIONS FACILITIES ...................................................................................................... 25 2.1.1 Math operators................................................................................................................. 25 2.1.2 Boolean operators............................................................................................................ 25 2.1.3 Timer ................................................................................................................................ 25 2.1.4 SQL data.......................................................................................................................... 26 2.2 COMMAND/SCRIPTING LANGUAGE ........................................................................................... 26 2.2.1 Scripting language requirements ..................................................................................... 26 2.2.2 Object hierarchy overview................................................................................................ 27 2.2.3 Renaming, duplicating and moving objects ..................................................................... 27 2.2.4 Global scripts and variables............................................................................................. 27 2.3 TIME AND EVENT TRIGGERED ACTIONS .................................................................................... 27 3 CONFIGURATION FACILITIES ................................................................................................... 29 3.1 INTRODUCTION ....................................................................................................................... 29 3.2 GENERAL REQUIREMENTS ...................................................................................................... 29 3.3 DATABASE.............................................................................................................................. 29 3.3.1 Database point configuration ........................................................................................... 29 3.3.2 Database point types ....................................................................................................... 30 3.3.3 Point attributes ................................................................................................................. 34 3.4 BASELINE DISPLAY EDITOR REQUIREMENTS ............................................................................ 34 3.4.1 General capabilities ......................................................................................................... 34 3.4.2 Display creation ............................................................................................................... 35 3.4.3 Color support ................................................................................................................... 36 3.4.4 Graphic toolbox................................................................................................................ 37 3.4.5 Display animation............................................................................................................. 38 3.4.6 Display refresh rate.......................................................................................................... 39 3.4.7 Sources of data for object animation ............................................................................... 39 3.4.8 Bitmaps ............................................................................................................................ 40 3.4.9 Support Microsoft Excel and Word documents ............................................................... 40 3.5 AUTOMATION OF GRAPHICS CONFIGURATION ........................................................................... 40 4 ADMINISTRATIVE FACILITIES................................................................................................... 42 4.1 STARTUP AND SHUTDOWN ...................................................................................................... 42 4.2 SECURITY MANAGEMENT ........................................................................................................ 42 4.2.1 Security areas .................................................................................................................. 42 4.2.2 Security manager............................................................................................................. 42 4.2.3 Securing the Microsoft Windows GUI environment ......................................................... 43 4.2.4 Limiting login time ............................................................................................................ 43 4.2.5 Automatic and manual logging in and out........................................................................ 43 4.3 MULTI-LINGUAL SUPPORT ....................................................................................................... 43 5 6 COMPUTER HARDWARE ........................................................................................................... 44 5.1 6.1 6.2 7 MULTIPLE MONITOR SUPPORT ................................................................................................ 44 LAN CONFIGURATION AND EXPANSION .................................................................................... 45 LAN ERROR DETECTION, RECOVERY, AND DIAGNOSTICS ......................................................... 45 LOCAL AREA NETWORKING (LANS) ....................................................................................... 45
SCADA SYSTEM ARCHITECTURE ............................................................................................ 46

7.1 STANDALONE SYSTEMS .......................................................................................................... 46 7.2 NETWORKED AND DISTRIBUTED SYSTEMS ............................................................................... 46 7.3 DATA REDUNDANCY................................................................................................................ 46 7.3.1 Redundancy with dual ported I/O devices ....................................................................... 46 7.3.2 Redundancy with single port I/O devices......................................................................... 46 7.4 TERMINAL SERVER CLIENTS .................................................................................................... 47 7.5 REMOTE ACCESS ................................................................................................................... 47 7.5.1 Via the network ................................................................................................................ 47 7.5.2 Via modems ..................................................................................................................... 47 8 SOFTWARE ARCHITECTURE .................................................................................................... 49 8.1 OPERATING SYSTEM ............................................................................................................... 49 8.2 SCADA SOFTWARE GENERAL ................................................................................................ 49 8.3 PROGRAM LANGUAGE ............................................................................................................. 49 8.4 SOFTWARE STANDARDS ......................................................................................................... 49 8.4.1 VBA .................................................................................................................................. 49 8.4.2 OLE, OPC and ActiveX support....................................................................................... 49 8.4.3 ODBC............................................................................................................................... 50 8.4.4 DDE.................................................................................................................................. 50 8.5 SCADA DATABASE ................................................................................................................ 50 8.6 I/O DEVICE COMMUNICATIONS ................................................................................................ 50 8.7 COMMUNICATIONS DIAGNOSTICS ............................................................................................. 51 8.8 DISPLAY-ONLY COMMUNICATIONS ........................................................................................... 51 8.9 ERROR DETECTION AND RECOVERY ........................................................................................ 51 8.10 I/O & OPC SERVER DRIVER TOOLKIT ...................................................................................... 51 9 10 SYSTEM EXPANSION ................................................................................................................. 52 9.1 SYSTEM SIZING ...................................................................................................................... 52 Bus coloring ................................................................................................................. 53 Portable grounds ......................................................................................................... 53 Drawing tools ............................................................................................................... 53 Library of compounds .................................................................................................. 53 POWER INDUSTRY SPECIFIC ................................................................................................... 53 10.1.1 10.1.2 10.1.3 10.1.4

1 Introduction
1.1 Standard Software Products
The vendor is to provide a highly functional, generally available (i.e. non-custom) software system for data acquisition, monitoring and control. The vendor shall only propose proven, standard software products that meet the requirements of this specification without: a) Development of new functionality b) Significant custom configuration using for example custom calculations and/or scripts The vendor shall clearly indicate wherever new development and/or customization using calculations, scripts, VBA or other mechanisms is proposed to meet this specification. Systems that require new software development and/or significant customization by the vendor or system integrator will not be accepted. The vendor shall be able to provide references where the functionality required by this specification is already proven and currently in use by other customers.

Operational Facilities
1.2 Displays
The SCADA software graphics package must provide a means of creating and displaying color graphic displays that will be used by the user for monitoring and control. Real-time values being read from the field devices shall be capable of being displayed in a variety of user-configurable formats. The types of SCADA displays required are described below.
1.2.1 Pan, zoom and declutter

SCADA displays shall support pan, zoom and layering (clutter/declutter) including at least the following features: a) Ability to easily zoom into a specific area on a display using the mouse, by for example dragging a rectangle over the current display using the mouse, then releasing the mouse to cause the view to zoom in to the extent of the rectangle. b) Ability to smoothly and continuously zoom in/out using the mouse, by for example holding a mouse button down while dragging the mouse up/down the screen. c) Pan in any direction by dragging the display across the window using the mouse. d) Whichever mechanism for pan and zoom is offered it shall be easy and intuitive, shall not require use of the keyboard and shall not require any need manual configuration during preparation of the displays. e) At least 30 visibility layers per display. Each layer used shall be configurable with a zoom range over which static and dynamic objects belonging to the layer will be visible. As users zoom in or out objects shall automatically appear and disappear at the appropriate zoom levels. This mechanism shall provide effective declutter (removing detail on zoom out) and clutter (adding detail on zoom in) to maximize the clarity and effectiveness of the users interface. f) Every object on a display shall be configurable to belong to one of more of any of the 30 picture layers g) Objects shall be scaled during zooming
1.2.2 Real-time and historical trends

a) Standard SCADA displays shall be configurable to include any number of trend graphs of user-defined size and properties. a) A trend graph shall be able to recall archived data (section 1.13) from the disk to be displayed in graphical format, along with real-time data, OPC data, data from any object in a picture including 3rd party ActiveX controls, alarm counters and any data programmatically added to the graph. c) It shall be possible to configure objects in graphic displays that, when selected, fetch predefined historical trend data from disk and display it to the user. d) The display of archived data shall be user-configurable and shall provide at the following facilities: ) Ability to edit the attributes of the trend graph pens during runtime ) Support unlimited variables to be displayed on the same time/value axis simultaneously. ) For each entry in the display list, the user shall be able to assign a given point name and marker to a particular line color selected from palettes of unlimited colors. ) Display engineering units ranges to cause scaling of the display ) Multiple different y-axis engineering units ) Bi-directional trending and scrolling ) A movable, vertical line shall act as a time cursor on the display. This cursor can be moved by dragging it with the mouse. The date, time, and values of the trends corresponding to that time shall be displayed. ) The grid of the trend object shall be scrollable ) The trend shall be easily shifted forward or backward in time ("panning"). New data shall be fetched from the historical file as appropriate.

) )
) )
Display historical data with current (real time) data on the same chart The user shall be easily able to "zoom" in on any section of the trend display with the mouse. The zoom mechanism should be consistent with the zoom facility on standard displays described above. The software shall automatically re-scale both the y-axis and time axis and shall fetch the appropriate data for the time period selected. The trend object must have selectable refresh rates in 0.1 second increments from a minimum of 0.10 seconds to at least 1800 seconds. The trend graphic display must be printable to a black and white or color printer via the standard Microsoft Windows Print Manager.
1.2.3 Tabular information lists

The SCADA system shall provide a number of tabular data displays, or lists, to summarize key SCADA information to the user. It is highly desirable that these lists share a consistent look and feel, and wherever appropriate, provide the same functionality in the same way. At least the following lists shall be provided: List a) Database b) Notes c) Manual overwrite d) Control tags e) Information tags f) Off scans g) Disabled alarms h) Off normal i) Events Function A dynamic display of all points in the SCADA database A list of all points that have an associated Operator Note All points that have been manually overwritten All points that have a control tag (control lock) applied All points that have an information tag applied All points that currently have scanning disabled All points that currently have alarm processing disabled All points currently not in their defined normal state A chronological list of all SCADA events Reference 1.2.4 1.2.6 1.6 1.7 1.8 1.9 1.10 1.11 1.12
The specific requirements for each list are described elsewhere in this specification. The following requirements are common to all SCADA lists: a) It shall be possible to add a list to any SCADA display. It is expected that all summary lists will be provided as a single common ActiveX control that can be inserted in any SCADA display. b) Lists shall be able to be configured to any height and width, and located anywhere on a SCADA display. The list shall be sized by dragging its edges to be any height and width, and positioned by dragging it with the mouse. c) If either the list height or width is inadequate to display all the information in the list, then the list shall automatically provide horizontal and or vertical scroll bars as necessary. d) If the list includes data that updates dynamically (for example Events list) then dynamic updating shall be the default mode of the list. e) It shall be possible to pause any dynamic list (i.e. stop dynamic updating). f) At the time of configuring a list into a SCADA display it shall be possible to: ) Choose the function of the list (e.g. Off Normal or Control Tags) from a pull down menu. ) Optionally add one more filters, to display a subset of the complete list. At a minimum filtering should allow at least selection based on a subset of SCADA database points. g) If the list displays items for which user interaction is appropriate, then this shall be possible from the list. For example: ) It shall be possible to click on a single row in a manual overwrite list to display the appropriate manual overwrite dialog. From this dialog the user can change or remove the manual overwrite. This interface dialog shall be identical in look and operation to that shown to the user from the main SCADA displays. ) It shall be possible to click on a single row in a notes list to display the appropriate note, edit and save the note. This ability to operate from lists shall be provided for all lists in a manner that is appropriate and accurate for each list. The ability for users to operate from each type of list shall be able to be enabled or disabled.

h) Ability to sort the entire list on the alphabetical order of items in any single column. This shall be achieved by a single-click in the column heading to cause an A to Z sort. Each subsequent click on a column heading shall reverse the current sort (e.g. Z>AA>Z etc). i) Provide a dialog for easy sorting of a list based on multiple sequential parameters (i.e. first sort on column A, then Band so on). j) Provide easy filtering of the list on one or more parameters. The filter shall enable a user to apply multiple filters, each using wild-cards, with AND, OR and NOT operators defining the relationship between the multiple parameters. k) Ability to re-size columns by dragging column borders with the mouse. These changes shall be local to each computer workstation in a network, and shall be preserved if the list is closed then re-opened. l) Ability to move easily re-order columns by dragging column headers with the mouse. These changes shall be local to each computer workstation in a network, and shall be preserved if the list is closed then re-opened. m) A standard Microsoft Windows status bar on the list shall display at least the following information about the state of the list: ) List title e.g. Control Tags or Events ) Current mode. For example Run while dynamically updating, or Paused ) Total number of entries (rows) in the list ) Description of any filter currently in effect ) Description of any sort currently in effect n) Date format shall be as defined in the local settings of the target computer (the computer where the list application is currently installed). o) Time shall be in 24-hour format. p) Ability to print the list
1.2.4 Tabular displays of database points

The SCADA system shall include a tabular, dynamic display of all points in the SCADA database. This list shall have all the list facilities described in 1.2.3, plus: a) Each entry in the list shall provide at least the following information about individual database points: ) Name of the SCADA server providing the data ) Point name, description and type ) Alarm area (if defined) ) Current value/state b) The ability for a user to operate on the points on the list. The user shall be able to click on a point in the list to display a interface dialog for whichever of the following functions are appropriate for the point: ) Device control ) Manual overwrite ) Control tagging ) Information tagging ) Alarm acknowledgement, alarm disable and display of alarm states/values c) As far as possible this interface dialog shall match the interface used from graphical displays. d) The system shall include the ability to enable/disable the ability to access interface dialogs from this list, and therefore enable/disable user operations from this list e) Logon security requirements must be met to perform operations from this display. This database display shall thereby provide a useful facility for monitoring and control of any database points, without dependence on manual configuration of graphical SCADA displays. This facility shall be used during testing, commissioning and/or diagnosis of the system and/or new plant. a) Like all lists described in section in 1.2.3, this database display shall be capable of being added to any SCADA display, plus it shall be possible to add configure-time and/or runtime filters to produce tabular displays of subsets of the database. The objective of this mechanism is to provide a facility to easily add tabular displays of any subset of the SCADA database into any graphical display.

1.2.5 Tabular displays for secondary points

The SCADA system shall include a facility to automatically (without manual display configuration) provide tabular data screens for the display of secondary points associated with key indications. Secondary points are those digital and analog indications that provide qualifying information to the user about a main or primary indication. Examples would include: Primary indication Circuit breaker status Secondary indications o 3 x feeder current analogs o Local/remote switch o Ground fault alarm o Instantaneous over current alarm o Vibration alarm o Bearing temperature ...and/or o Bearing high temperature alarm
Pump run/stop status
The level of configuration automation required is that when the user configures the primary indication on a SCADA display, the system should automatically add a tabular display of all related secondary points. The method by which the SCADA system shall determine which database points are the secondary indications related to a primary indication is flexible. However it shall meet the following requirements: - It shall work for any size database - It shall not limit the number or type of points that can be defined as secondary points - Use of a point naming convention to link primary and secondary points is acceptable, however the system shall be adaptable to accommodate the customers existing point naming convention. This facility shall meet the following objectives: b) Greatly reduce display configuration time c) Reduce screen clutter by removing secondary indications from main displays. d) The user shall click on the point name of the primary indication to cause display of the secondary points display. e) Tabular displays must be consistent in format and layout. Ideally the system shall use only one format, with as few minor variations as required to meet the varying number of secondary indications associated with primary points. f) Tabular screens shall accommodate as few as 2 secondary indications and at least as many as 50 secondary indications.
1.2.6 Operator Notes

The SCADA system shall provide users with a facility to record detailed text notes about important items of equipment. Requirements of this notes facility are: a) The system shall automatically configure that primary indications (as defined in section 1.2.5) displayed on a SCADA display, shall have a notes record. b) It shall be possible to add notes that are not associated with a database point. For example notes related to a particular area of plant or a specific display (system notes). c) The Notes Editor shall provide a sizeable text entry window with at least the following word processing facilities: ) File functions (save, delete, new, print) ) Edit functions (cut {Ctrl+X}, copy{Ctrl+C} paste{Ctrl+V}) ) Text format functions (font type, size, style, color) ) Print setup (standard Microsoft Print Manager) and Print d) It is acceptable to limit the maximum size of notes to preserve disk space, though each note shall be able to be at least 5KB in size. The maximum note size shall be defined. e) The Notes Editor shall retain a history of at least the last 20 saved versions of each note associated with each device. Each version shall include a record of who created/edited/saved the note, the save date and time, and the workstation computer name the version was saved from. All previous versions of a note can be viewed.

f) It shall NOT be possible to edit any but the current version of a note g) It shall NOT be possible for any user to access any hard drive, other storage device, or any network device from the Notes Editor. 1.2.6.1 Notes List The SCADA system shall automatically maintain a tabular list that summarizes all notes currently in the system: a) Clicking on a single row (i.e. a single note record) in the Notes List shall start the Notes Editor with this notes opened, providing the same editing capabilities as if the note is accessed from the relevant point display. a) The Notes List shall provide all the standard list functions described in section 1.2.3.
1.3
Display Navigation
Navigation method(s) that are fast, easy and highly intuitive are fundamentally important requirements for the SCADA system. It is expected that navigation will be achieved entirely with the mouse. Navigation dependent of the use of function keys is unacceptable. Navigation methods shall include at least:
1.3.1 Menu system

The required features of the menu system are: a) A single menu system should provide navigation to all displays. The menu system shall automatically extend to incorporate any number of new displays created using the SCADA display editing tools. Preference will be given to systems that provide flexible and automatic methods to categorize and sort displays, thus avoiding a single menu pull-down containing every single display. b) The single menu shall also include access to the following core SCADA functions, though execution of some of these functions will be limited by security logon: ) Alarms, Events and other SCADA lists ) Acknowledge all alarms on the current display ) Silence and enable the alarm horn ) Access to all other operational facilities ) Access to all configuration facilities, for users with appropriate security access ) A Window function that lists all open windows (SCADA displays and other SCADA application windows) and enable a user to select any open window, bringing the selected window to the foreground. ) System shutdown ) Online help
1.3.2 Display links

The SCADA display editor shall enable adding of an unlimited number of on-screen display link buttons to any display. When clicked on during runtime mode, a display link button shall cause the display of another SCADA display. These picture link buttons shall be flexible as to action (picture to display), size, color, font and text content.
1.4
User Interface Dialog
The interface for users to interact with the SCADA system is of critical importance. If must meet the following important requirements: - Highly intuitive, easy to use - Fast and efficient to use - Consistent throughout the system - Be optimized for the safe operation of the plant at all times The preferred method of user interface is pop-up dialog box. The preferred method to display an interface dialog is by single left-button mouse click on a display symbol or other item where user interaction is appropriate. The dialog that appears shall:

a) Provide a single, structured and standardized interface for all user interaction with a device. b) Not include facilities that are inappropriate for the device. For example if a device is not controllable, then control options must not appear. c) Be completely consistent throughout the system. For example the dialog for a specific type of device should be identical for all instances of that device. The dialog shall provide the user with at least all of the following services, but only when these are appropriate to the specific device: a) Operator control (see section 1.5) b) Manual overwrite (see section 1.6) c) Control tagging (see section 1.7) d) Information tagging (see section 1.8) e) Enable/disable alarm processing for the point f) Acknowledge an alarm for the individual point g) Display alarm states for digital devices, or alarm limits for analog devices h) Provide an optional capability for users to change alarm limits for the point without opening the main database editor e) Stop/start scanning for an individual point (see section 1.9) f) Set scan time (seconds) (see section 1.9) g) Access to user notes (see section 1.2.6) l) Provide context sensitive help Input dialogs shall support at least the following data entry methods: a) Numeric keyboard input for analogs b) Slider for analogs c) Arrow up/down toggles to increment/decrement analogs d) Pushbutton for digitals e) Alphanumeric input for text
1.5
Operator Control
1.5.1 Select before operate

The system shall provide a safe and accurate select before operate control sequence for a user to initiate a control: a) The user clicks once on the device symbol on a SCADA display a) The user interface dialog (section 1.4) shall appear alongside but not obscuring the device symbol. c) For devices that can be controlled, then the control interface shall be the default information displayed in the dialog. That is, the single click required to display the dialog shall be all that is required to see the control options. d) The dialog shall show all the possible control option buttons for the device (for example Trip and Close are the possible controls for a circuit breaker). Only control options that are appropriate for the device shall be displayed. e) The user shall click on the required control operation button (e.g. Trip). The button must visually change when clicked, to clearly show the user which control operation has been chosen. f) Once the control option button is clicked, then an Operate (or equivalent) button used to start the control, must visually change (for example change color) to show a specific control operation has been selected and the control is now ready to progress. g) The user clicks once on the Operate button to proceed with the control h) A final confirmation dialog box shall appear that displays a final confirmation message equivalent to Do you wish to proceed with this control and Yes or No buttons. i) The user shall click on Yes to complete the control or No to cancel the control and close the dialog.

1.5.2 Control interlocking

Only one user shall be able to display the interface dialog for a single device at one time. If another user clicks on another display of the same device, then instead of the normal interface dialog, the SCADA system shall display a warning with text equivalent to This device is already under control This warning shall also include at least: a) The logon name of the user that is currently displaying the device dialog (i.e. The user that currently has control of this device). b) The name of the computer the controlling user is logged on to. This process shall effectively prevent simultaneous control of a single device by more than one user. 1.5.2.1 Interface dialog timeout To prevent inadvertent permanent lock-out of device from control, the interface dialog shall automatically disappear if the left idle for a preset time. The device shall become available for control by other users as soon as this timeout occurs. The duration of this timeout shall be user configurable in seconds.
1.5.3 Other control requirements

a) The system shall support at least the following types of control: ) Control of two and four state digital devices. Control buttons shall only appear for those states that it is appropriate to control to. ) Control of analog devices (i.e. analog set point controls). b) Control buttons must be accurately labeled. For example the control dialog for a circuit breaker should provide buttons with appropriate text labels (such as Close and Trip) while the control dialog for a pump should provide buttons labeled something like Run and Stop. The text labels for these control buttons shall be user defined within just one location the SCADA database. c) Control dialogs for all instances of identical devices shall look and behave exactly the same way. d) Only devices defined as control enabled in the SCADA database shall present control options to the user. a) It shall not be possible for users to display a control dialog for devices that currently have control facility locked out (i.e. that are currently control tagged as per section 1.7).
1.6
Manual Overwrite
A manual overwrite facility shall enable a user to overwrite the telemetered state/value in the SCADA database with a manually entered state or value. This shall be used typically when a transducer is faulty, not yet installed, or has been removed for servicing. So long as the manual overwrite remains in place, the SCADA database retains this user-entered value/state, and ignores the value/state provided by the telemetry system. a) This facility shall be available for analog inputs and both single-bit and two-bit digital inputs. b) The ability to enter, change and remove a Manually Overwrite shall be a runtime facility. c) Manually overwritten values shall be processed by the SCADA system in the same way as normal measured information, including at least: ) Generation of alarms ) Recording of changes in the events list ) Processing in any equations or secondary block processing ) Historical storage if defined for these points
1.6.1 Applying a manual overwrite

The process to apply a manual overwrite shall be: a) The user clicks on the device symbol on a SCADA display, causing the display of the user interface dialog (section 1.4). If manual overwrite is an appropriate option for this device, then the dialog shall have a manual overwrite option. i) The manual overwrite dialog for analog devices shall provide at least the following mechanisms to perform a manual overwrite:

i. Type in a new analog value using the numeric keys on the keyboard ii. Use the mouse to control a slider to increase or decrease the current value iii. Use the mouse to incrementally toggle the current value up or down The manual overwrite dialog for digital devices shall provide a button for each possible state that the device can be manually overwritten to. j) The dialog shall clearly display the new value/state to the user before the user completes application of the manual overwrite. k) An Apply button or equivalent shall enable the user to apply the change once the new value/state has been entered. l) manual overwrites may only be applied by users with logon level equivalent or higher to that required to perform control operations.
1.6.2 Display of manual overwrites

The presence of a manual overwrite shall be clearly indicated by at least: a) The font color for overwritten analog values shall change to the manual overwrite color. b) The border color, fill color (or both) used to display the state of a digital shall change to the manual overwrite color. c) The choice of the manual overwrite color shall be user configurable. The default color shall be cyan. d) The manual overwrite symbol shall appear alongside a manually overwritten device. The choice of the manual overwrite symbol shall be user configurable. The default symbol shall be the single letter M. e) Applying a manual overwrite shall be recorded as a single event in the SCADA events list with at least the following information: ) Date and time the manual overwrite was applied or changed ) Name of the device/point ) Computer name and logon name of the user applying the manual overwrite ) New value/state forced by the manual overwrite
1.6.3 Manual overwrite list

The SCADA system shall automatically maintain a tabular list that displays all manual overwrites currently in the system. This list shall provide all the facilities described in 1.2.3. Each entry in the list shall provide at least the following information about an individual manual overwrite: a) Date and time the manual overwrite was applied b) Name and description of the manually overwritten device c) Computer name and logon name of the user applying the manual overwrite d) New value/state forced by the manual overwrite
1.6.4 Altering or removing an existing manual overwrite

a) The manual overwrite interface dialog shall enable facilities to ) Change the state or value of an indication with a manual overwrite applied ) Remove a manual overwrite. b) Manual overwrites may only be changed or removed by users with logon level equivalent or higher to that required to perform control operations. c) Changing or removing a manual overwrite shall be recorded as a single event in the SCADA events list with the same level of information as when a manual overwrite is first applied. d) Changing or removing a manual overwrite shall update the manual overwrite list. e) Removing a manual overwrite shall remove all indications of the manual overwrite from all displays on all workstation screens. f) Removing a manual overwrite shall cause the display of the current value/state being measured by the SCADA system from the remote devices (PLCs/RTUS etc), using the appropriate color and other attributes that reflect a current measured value/state is being displayed.

1.7
Control Tagging
A control tag (or control lock) facility is required to enable users to block control operations on devices that are currently unavailable. a) The control tagging facility shall prevent both automatic (software driven) and manual (user driven) controls. b) Control tagging shall be achieved entirely in runtime mode.
1.7.1 Applying a control tag

The process to apply a control tag shall be: a) The user clicks on the device symbol on a SCADA display, causing the display of the user interface dialog (section 1.4). If control Tagging is an appropriate option for this device, then the dialog shall have a Control Tag option. b) The control tag dialog for a device shall provide at least the following: ) A facility for the user to select a control tag Type from a pull down list. The Types in this list shall be user defined text, at least 20 characters long. The system shall support at least 50 possible Types. It shall be user configurable to make selection of Type either optional or mandatory. ) A facility for the user to enter at least 150 characters of text to describe the reason for the control tag. It shall be user configurable to make this tag reason either optional or mandatory. ) Control tags may only be applied by users with logon equivalent or higher to that required to perform control operations. c) Applying a control tag shall be recorded as a single event in the SCADA events list with at least the following information: ) Date and time the control tag was applied ) Name of the device being tagged ) Computer name and logon name of the user applying the control tag ) Tag type ) Tag reason text d) The presence of a control tag applied to a device shall be clearly visible on all SCADA displays that include a display of the device by display of the letter T alongside the symbol of the control tagged device.
1.7.2 Attempts to control a control tagged device

When a user clicks on a device symbol that has a control tag in place: a) The interface dialog shall display the following information about the control tag: ) Date and time the tag was applied ) Computer name and logon name of the user that applied the tag ) Tag type ) Tag reason text b) The device dialog shall NOT display or otherwise provide any facilities that enable for control of the device. There shall be no other mechanism to enable a user to control a control tagged device from within the SCADA software system.
1.7.3 Removal of a control tag

The user interface dialog shall provide a Remove option for control tags. Control tags may only be removed by users with logon level equivalent or higher to that required to perform control operations. Removing a control tag shall: a) Re-enable control capability for the device from any display of the device b) Remove the T indication from any displays showing the device. c) Be recorded an event in the SCADA events list with at least the following information: ) Date and time the tag was removed ) Name of the device having the tag removed ) Computer name and logon name of the user removing the tag d) Remove the entry for the control tag list (see below).

1.7.4 Control tag list

The SCADA system shall automatically maintain a tabular list that displays all control tags currently in the system. This list shall provide all the general list facilities described in 1.2.3. Each entry in the list shall provide at least the following information about an individual control tag: ) Date and time the tag was applied ) Name and description of the tagged device ) Computer name and logon name of the user applying the tag ) Tag Type ) Tag text
1.8
Information Tagging
An information Tagging facility shall be provided to display a warning or advice to a user before they try to control a device. That is, when a user clicks on a device that has an information tag applied, then the tag information (defined below) is automatically displayed to the user, before the control options are made available. However unlike a control tag, an information tag shall not prevent a user from issuing a control. That is, the system shall still provide the user with the interface dialog required to proceed with issuing a control. It shall be possible to apply both an information tag and a control tag to a single device. If both tags are applied, then the control tag text message is displayed in preference to the information tag message when a user clicks on the device symbol on a display. Removing either of these tags shall not remove the other tag. Information tagging shall be achieved entirely in runtime mode.
1.8.1 Applying an information tag

The process to apply an information tag shall be: a) The user clicks on the device symbol on a SCADA display, causing the display of the user interface dialog (section 1.4). If information Tagging is an appropriate option for this device, then this dialog shall have a Information Tag option. b) The information tag dialog for a device shall provide at least the following: ) A facility for the user to select a information tag Type from a pull down list. The Types in this list shall be user defined text, at least 20 characters long. The system shall support at least 50 possible Types. It shall be user configurable to make selection of Type either optional or mandatory. ) A facility for the user to enter at least 150 characters of text to describe the reason for the information tag. It shall be user configurable to make this tag reason either optional or mandatory. c) Information tags may only be applied by users with logon level equivalent or higher to that required to perform control operations. d) Applying an information tag shall be recorded as a single event in the SCADA events list with at least the following information: ) Date and time the tag was applied ) Name of the device being tagged ) Computer name and logon name of the user applying the tag ) Tag type ) Tag text
1.8.2 Information tag list

The SCADA system shall automatically maintain a tabular list that displays all information tags currently in the system. This list shall provide all the general list facilities described in 1.2.3. Each entry in this list shall provide at least the following information about an individual information tag:

) ) ) ) )
Date and time the tag was applied Name and description of the tagged device Computer name and logon name of the user applying the tag Tag type Tag text
1.8.3 Removal of a information tag

The process of removing an information tag shall mirror the process of removing a control tag as far as is appropriate.
1.9
Scan Control
A facility shall be provided within the standard user interface to enable users to remove/return individual telemetered points from communications polling (scanning). Other requirements for this scan control facility are: a) It shall be provided for both analog and digital telemetered points. b) This option shall not appear in the user interface for any points where turning scanning on/off is inappropriate. c) If supported by the communication protocol, the scan control interface shall also display the scan interval on a point by point basis. d) If supported by the communication protocol, the scan control interface shall provide users with the ability to change this scan interval for any point. e) Scan control shall require user security level equivalent or higher to that required to perform control operations. f) Turning scan off or on shall be recorded as a single event in the SCADA events list with at least the following information: ) Date and time the scan status is changed ) Name of the device being scan controlled ) Computer name and logon name of the user applying the scan on/off control ) Appropriate text to describe the operation e.g. Scanning Disabled or Scanning Enabled g) Scan off/on control shall be achieved entirely in runtime mode.
1.9.1 Display of off scan points

Points that are currently off scan shall be clearly identified to users on all displays, using a display convention equivalent to: a) Display the letter S alongside the device symbol or value b) Replace analog values with ??? to clearly indicate that the current value is unknown c) Replace digital symbols with ?, or embed ? within the symbol to clearly indicate that current state is unknown
1.9.2 Off-scan List

The SCADA system shall automatically maintain a tabular list to display all points in the system that currently have scanning turned off. This list shall provide all the facilities described in 1.2.3. Each entry in the list shall provide the following information about off scan points: ) Date and time the point was taken off scan ) Point name and point description ) Name of the computer and logon name of the user that took the point off scan
1.10 Alarms
Alarms shall be used to report potentially harmful conditions requiring a response from the user. The system shall be capable of detecting and generating alarm conditions based on various changes in the states/values of the database points. Other key requirements: a) The alarm conditions shall be detected even if the variables causing alarms are not currently on the display.

b) It shall be possible to filter alarms based upon location, priority and other user-selectable criteria. c) When a new alarm is detected, all SCADA computers shall immediately see the new alarm. d) If the alarm is acknowledged on one SCADA computer, then all SCADA computers shall see that it was acknowledged. e) Alarm limits shall be expressed in engineering units. f) Alarm limits can be entered by the user at configuration time or from the user's display during run-time. The ability to change alarm limits at runtime shall be a user configurable option.
1.10.1 Alarm types

Analog input variables shall have at least the following alarm types: a) High High b) High c) Low d) Low Low e) Time rate-of-change f) Bad input from I/O g) Alarm Disable h) Off Scan i) Deadband Digital input variables shall have at least the following alarm types: j) None k) Change of state l) Open m) Close 3-term (PID) control functions shall have the following alarm types (in addition to the alarm types associated with the analog input or alarm block providing the measurement): Statistical data points shall support "out of control" alarming on the following limits: n) X bar, range and standard deviation control limits o) 2 Sigma X bar p) 3 Sigma X bar q) Range r) Trend of runs s) Length of runs t) Critical runs u) Standard Deviation (SBAR)
1.10.2 Alarm priorities and filters

The system shall support at least 3 alarm priorities for each alarm type: High, Medium and Low. A filtering mechanism shall be provided so that the user can adjust the system alarm priority. The handling shall be as follows: If priority level is: Then messages shall be sent to alarm destinations for points with: Low High, medium, and low alarm priorities Medium High and medium alarm priorities High High alarm priorities Special alarm messages (such as I/O failure) shall be non-maskable and shall always print.
1.10.3 Alarm areas

In order to logically divide the system into smaller units, the SCADA shall enable unlimited, named, user-defined individual alarm areas. Alarm areas are used to determine which destinations receive each alarm. Other requirements: a) Alarm areas shall be user definable for each individual database point b) All alarm areas must be accessible by each point.

c) The system must support multiple alarm areas per point. d) The method of alarm distribution over a network must be session-based in order to guarantee alarm distribution and reception. Broadcasting of alarms on the network shall not be permitted. 1.10.3.1 Alarm Counters
The system shall provide counters to display the number, type, and priority of alarms in any alarm area. It shall be possible to use these counters in mathematical and Boolean expressions to display, for example, the number of high priority unacknowledged alarms in a user-specified number of alarm areas. The alarm counters must also be accessible as directly addressable I/O points in the point database. The alarm counters in any alarm area shall include:
a) b) c) d) e) f)
Total number of acknowledged alarms Total number of unacknowledged alarms Running total of alarms Number of acknowledged High, Medium, & Low priority alarms Number of unacknowledged High, Medium, & Low priority alarms Number of disabled High, Medium, & Low priority alarms
The system shall also be able to display a summary of all of the above alarm counters for all areas on a given node.
1.10.4 Alarm destinations

The system shall provide a means for placing an alarm message in one or more of the following locations: a) Alarm summary display b) Alarm printer. The use of multiple alarm printers shall be supported to allow routing of alarms from different alarm areas to different printers c) Alarm message file on disk
Alarm messages shall be independently user-configurable as to what information is provided and its sequence within the message. The following shall be among the available choices:
d) e) f) g) h) i) j)
Time of the alarm Name of the point causing the alarm Alarm condition code Engineering units value when the alarm occurred Descriptor text assigned to the point Engineering units of the point Directly to a relational database
1.10.5 Auto alarm manager

The system must support implementation of a method for alarms to be acknowledged from a central location, via modem. The connections from the remote computer to the central computer must only be live during an alarm condition and shall use Microsofts Remote Access Service (RAS).
1.10.6 Alarm notification

a) When a new alarm condition is detected, an alarm message shall be generated. b) If the symbol, value or state text of the point is on any display(s), then the symbol/value/text shall flash until the alarm is acknowledged. c) The system must be capable of "freezing" the highest alarm status value on the display until acknowledgment is made. Once acknowledgment is made, the system shall display the current alarm status text.
1.10.7 Alarm acknowledgment

a) Alarm acknowledgment shall be performed from the user's keyboard or with the mouse with minimal keystrokes or mouse clicks. b) The interface dialog shall provide a facility to easily acknowledge an alarm for a single point. c) The system shall provide a facility to easily acknowledge all alarms on a display

d) It shall be possible to configure remote acknowledgment by for example, a button to be depressed by the user which closes a digital point and acknowledges one or more alarm conditions, as configured by the user.
1.10.8 Other alarm requirements

a) Alarm suspension: Shall allow the user to specify digital points, that when closed, cause alarms not to be generated for one or more alarm conditions. This is useful, for example, during the start-up phase of a project to avoid nuisance alarms. b) It shall be possible for the user to easily and quickly enable/disable the alarm horn. c) Re-alarm time: Shall allow the system to re-generate an alarm after a user-configurable amount of time, should the alarm condition still exist. d) Delay time: Shall allow the user to specify a period of time for which an alarm condition must remain before an alarm is generated. This is useful if certain conditions cause a temporary, but acceptable fluctuation beyond alarm limits, and the generation of alarms is not desired. e) Close contact on alarm. This shall allow the user to specify digital points that become closed when certain alarm conditions occur. These points can then be used to take actions, such as sounding a horn or initiating a sequence of instructions. Also, the user can specify the conditions under which these digital points are re-opened, including the following: ) When the alarm is acknowledged ) When the alarm is cleared ) When the alarm is acknowledged and cleared ) Never (it must be re-opened by a different function) f) For analog values, re-alarm time, delay time, and close contact on alarm capabilities shall be supported, not just on a point by point basis, but for the following individual alarm types within a point: ) High High ) High ) Low ) Low Low ) Rate of change ) Deviation from target value ) All other
1.10.9 Alarm disabling

The system shall provide a facility for users to easily disable/enable alarm processing on a point by point basis. Other requirements: a) It shall be provided for both analog and digital telemetered points. b) Disabling/enabling an alarm shall be recorded as an event in the SCADA events list with at least the following information: ) Date and time the alarm was disabled/enabled ) Name of the point being disabled/enabled ) Computer name and logon name of the user applying the disable/enable ) Appropriate text to describe the operation e.g. Alarming Disabled or Alarming Enabled c) This option shall only appear in the user interface dialog when it is inappropriate for the point. d) Point alarm disable/enable shall be achieved entirely in runtime mode. 1.10.9.1 Disabled alarms list The SCADA system shall automatically maintain a tabular list to display all points in the system that currently have alarm processing disabled. This list shall provide all the facilities described in 1.2.3. Each entry in the list shall provide at least the following information about disabled alarms: a) Date and time the point was taken off scan b) Name and description of the point c) Name of the computer and logon name of the user that disabled the alarm

1.10.10
Alarm summary display
The SCADA system shall automatically maintain a tabular list that displays all Active Alarms currently in the system. a) The alarm summary display shall be a pre-defined, customizable, ActiveX control within the graphics package. b) The list shall dynamically update as new alarms are detected and existing acknowledged alarms are cleared. a) In addition to being able to configure the placement of the information (point name, current value, descriptor, time of alarm, and alarm status), the user shall be able to specify the color codes to be used to indicate the various alarm conditions. b) Alarms can be acknowledged from the alarm summary display either individually (by clicking on an alarm acknowledgment field) or for all alarms in the queue. c) The alarm summary display must provide sorting and filtering capabilities. The user shall be able to filter on node name, alarm area(s), alarm status and alarm priority. The user must be able to sort on time, point, alarm area, alarm priority and alarm status. The user must be able to display field or fields about the alarm point in a column format and do complex filtering. d) The alarm summary object must also be to trigger a VBA event to indicate the presence of new alarms or that the list has changed.
1.11 Off Normal List

The SCADA system shall automatically maintain a tabular list that displays all points in the system that are currently in an off normal state. Note that the off-normal condition shall differ from the alarm condition in the following ways: a) The off-normal list shall not take note of the acknowledgement state. For example, a cleared alarm condition (state/value returned to normal) should remain in the alarm list until a user has acknowledged the alarm. A cleared alarm condition should immediately be removed from the off normal list. b) The off-normal list should not take note of whether alarm processing is currently enabled or disabled. A point with alarming disabled that enters its alarm state shall appear on the off-normal list, but not the alarm list. The off normal list shall provide all the list facilities described in 1.2.3. Each entry in the list shall provide at least the following information about off normal points: ) Date and time the point entered the off normal condition ) Name and description of the point ) Current value/state ) Alarm acknowledged/unacknowledged state ) Alarm area ) Alarm priority The color of each off normal entry (row) shall be the same coloring scheme used within the alarm summary list.
1.12 Events
The SCADA system shall automatically maintain a tabular list that displays all events in the SCADA system. This event list shall be as a complete as possible record of all changes in the system including at least the following: a) All changes to and from alarm conditions b) All digital changes of state, including those not defined as alarm changes of state c) User actions including ) User controls ) Adding and removing points ) Applying and removing manual overwrites ) Alarm disable and alarm enable ) Scan on and scan off controls d) System events including at least: ) System start up

) User log on ) Loading of a SCADA database ) The state of a network session changes ) A communications driver detects an error ) Database point errors ) Run-time or system errors e) Sequence of Events (see below) f) User messages (see below)
1.12.1 Sequence of events

Sequence of Events (SOE) are a special category of event that provide a precise record of the order of events in the SCADA system. The SCADA master station software shall support SOE processing and display for use when it is supported and implemented in the remote IO devices (RTUs, PLCs, IEDs etc) and communications protocol. The requirements for supporting SOE include: a) SOE time is determined and recorded within the remote IO device (RTUs, PLCs, IEDs etc) and relayed to the SCADA master station via the communications protocol. SOE time must NOT be determined by the SCADA master station system. b) SOE time is recorded to 1millisecond resolution by the remote IO device and this time is to be accurately retained and displayed within the SCADA master station software event list. c) SOE time is transmitted to the SCADA master station software via the communications protocol. The SCADA master station must support the extraction of the SOE information from the communications protocol for at least the DNP 3.0 protocol. The SCADA master station software must be able to be reasonably extended to support SOEs via other protocols if required. d) The SCADA master station shall support time synchronization via external time source such as GPS time clock. The SCADA software shall be able to receive and utilize time synchronization messages via NTP (Network Time Protocol). e) SOEs shall be merged with other events in the events list, with all events being displayed in correct chronological order. f) SOEs shall be clearly identified in the Events list, as for example a separate type of event called SOE. g) A facility shall exist for users to easily filter the events list to produce a subset only displaying SOEs.
1.12.2 User events

The system shall provide a runtime facility for users to easily enter text messages into the Event list. The user events facility shall be accessible either: a) From the main menu b) Directly from the Event List display The system shall automatically add the following information to each of these user messages: a) Date and time the message was entered b) Computer name and logon name of the user who enters the message
1.12.3 Event storage

The system shall store all events permanently on the SCADA server(s) hard disk until they are deliberately removed (archived) from the system. a) Events shall be stored in a separate computer file for each day. b) The name of these files shall be automatically generated by the system and shall include the date, for example YYYYMMDD.xxx or equivalent. c) The number of events stored and the length of time that events are stored on the SCADA server(s) shall only be limited by the capacity of the storage media (e.g. hard disk drive).

1.12.4 The events list

The event list shall provide the list facilities described in 1.2.3, except that the event list shall always be chronologically ordered, therefore the event list should not support sorting. New events will enter at the top of the list, while older events are scrolled down the screen. Each event entry in the list shall provide at least the following information: a) Date and time. Time shall be to at least 0.1 second resolution for all events except SOEs (Sequence of Events) which shall be displayed to 1 millisecond resolution. b) Events source identifier, including at least the following sources: ) Alarm: all SCADA alarms ) Event: all changes of state that are not considered alarm changes ) Operator: user actions ) System: System, software, database, communications messages ) SOE: Sequence of Event c) Name and description of the point, when the event source is Alarm or Event d) Digital state or analog value, when the event source is Alarm or Event e) Alarm priority, when the event source is Alarm f) Computer name and logon name when the event source is Operator.
1.12.5 Reviewing historical events

The system shall provide a user-friendly mechanism for users to view events from previous days, weeks, months and/or years. a) Viewing of historical events shall be achieved from within the standard event list described above. b) This facility shall include at least a multi-parameter filter facility, so that a user could easily choose to see events from a specific time and on a specific topic. For example the user may wish to: - Review events from a specific 4-hour period, on a specific day, 18 months in the past - but only see events related to a particular area of the plant or an individual point - and may want to further restrict the list to show events from some specific sources such as Alarms and/or Operator
1.13
Data Archiving & Reporting
The system must provide a facility for automatically collecting, storing and recalling data. Recalled data shall be made available to a trend display program, a report generation program and to userwritten programs.
1.13.1 Data file handling

a) Data shall be stored in a compressed format. Compression shall be performed through a user-supplied dead band. Entries containing time, name, value and status shall be made in the file whenever the real-time value exceeds the previously-stored value by the dead band limit. A dead band value of zero shall cause an entry in the file each time the realtime value is examined. b) Files shall be organized according to time and shall contain values for multiple, named variables. The file can be placed on the hard disk or a floppy disk, and can be placed on a file server if LAN server software is installed. c) A mechanism for on-line maintenance and automatic purging of files must also be provided. d) The system must support third party applications for ODBC queries.
1.13.2 Archive configuration

The data to be collected by the archiving program shall be identified through an interactive, menubased configurator. The user shall enter the point name, collection rate, and data compression dead band value. The following collection rates are required: 1, 2, 10, 20 and 30 seconds 1, 2, 10, 20 and 30 minutes

The collection task can be run on any one or more computers on the network. The task shall have the ability to access data from the memory-resident point list in its own computer and/or any computer(s) on the network. The task shall allow the collection of groups of points to be turned on and off automatically based on an alarm on discrete value in any networked database with no scripting required.
1.13.3 Displaying archived data

The user shall be able to recall archived data from the disk to be displayed using the graphical trend facility described in section 1.2.2.
1.13.4 Reporting options

The system shall make all of its historical and real time data available via ODBC drivers, enabling the user to use the reporting tool of their choice.
1.14 Printing
Printing shall utilize the standard Microsoft Windows print dialog. The user shall select the destination printer before printing the current display. Printing shall also provide that: a) Black and white colors are swapped, i.e. black is printed as white, and white as black b) An optional setting to allows the (configurable) background color to not be printed (i.e. shown as white)
1.15 Online Help

Deleted:
1.15.1 Program help

a) An on-line help facility based upon Microsoft Windows standard hypertext shall provide useful, context-sensitive information on the operation of the package. b) This help facility shall be capable of being invoked on-line through a point-and-click operation. c) The help facility must support the ability to perform full text word search, add custom comments, bookmark topics, copy and pasting into another application, printing, and use of system fonts and colors.
Deleted: " Deleted: "
1.15.2 Context sensitive help

Key dialogs, such as the primary user interface dialog shall provide context sensitive help to explain usage of all important fields.
1.15.3 Custom help

a) The system should be capable of incorporating a user-built Microsoft Windows standard help file (*.hlp) into the graphic displays without any scripting or code. For example, by pressing the Shif+F1 key the mouse will change to a pointer with a question mark (with no scripting). b) When the user clicks on an object, a window displays a corresponding entry in a Microsoft Windows help file, with no scripting or custom code. c) The system should provide the tools to the developer to convert standard documents and procedures written in any popular word processing program (e.g. Microsoft Word or WordPerfect) into a compiled Windows help file with a table of contents, index and search capabilities.
1.16 Documentation
a) The system shall provide complete user documentation, explaining how to both configure (setup) and operate the system.

b) The documentation must be in electronic format, HTML based with the ability to search for topics by keyword or search for specific text.

2 Automation Facilities
The SCADA system shall meet the majority of the requirements of this specification without requiring significant customization by the use of calculations and/or scripts. The facilities described below are principally required to ensure the SCADA system has the tools and capability to ensure it can be adapted and extended to meet the customers possible future requirements.
2.1
Calculations Facilities
The system shall provide comprehensive calculation services that support: a) Inclusion of any mix of telemetered, previously calculated and/or numeric values into calculations b) Store calculation outputs in standard SCADA database point records. c) Enabling chaining of calculations, starting either from telemetered or other points, and incorporating multiple chain links. Calculation services shall provide at least the following functions:
2.1.1 Math operators

Operator a) ABS(input) b) SQRT(input) c) EXP(input) d) LOG(input) e) LOG10(input) f) INT(input) g) h) ^ i) * j) / k) + l) m) < n) > Function Absolute value Square root Anti-log Natural log Base-10 log Changes floating point values to integers Unary minus (example, -A) Raise to power, exponential Multiply Divide Add Subtract (example, A-B) Less than Greater than
2.1.2 Boolean operators

Operator a) NOT b) AND c) NAND d) OR e) XOR f) Equal g) Not Equal Description Inverts the incoming value. If A is true, -A is false. Evaluates to true if all inputs are true. If any input is false, the output is false. Evaluates to true if all inputs are false. Otherwise the output is false. Evaluates to true as long as one or more of the inputs are true. If all inputs are false, the output is false. Evaluates to true if one input is true and the other false. If both inputs are true or false, the output is false. Evaluates to true if A equals B. Otherwise, the output is false. Evaluates to true if A does not equal B. Otherwise, the output is false.
2.1.3 Timer
a) The timer shall function as a time counter by incrementing or decrementing its value, based on the status of a digital or Boolean input. b) The timer shall raise an alarm when a target value is reached, and shall be able to be paused or reset.

2.1.4 SQL data

c) The SQL data function shall identify data to read or write when an SQL trigger executes. d) The SQL Data function shall transfer data between the SCADA database and a relational database. e) After reading the data, the SQL Data function shall be able to write it to either database depending on the SQL command that executes: If the SQL command is. . . SELECT INSERT, or DELETE f) UPDATE, The function. . . Reads values from the relational database and writes them to the SCADA database. Writes SCADA data values to the relational database
A SELECT command with a Where clause shall instruct the function to read and write data to both databases. g) For values in the Where clause, the function shall read from the SCADA database and write to the relational database. h) For the values not in the Where clause, the function shall read from the relational database and writes to the process database.
2.2
Command/Scripting Language
The customer wishes to utilize widely-adopted, industry leading tools as far as possible. It is also important that the SCADA system includes the capability to be easily adapted to meet unseen future requirements. Accordingly the SCADA system scripting language shall be Microsofts Visual Basic for Applications (VBA), version 6.2 or later. Proprietary scripting languages are unacceptable, including proprietary scripting languages that are similar to Microsoft Visual Basic. a) Scripts can be simple or complex, and shall allow users to automate operator tasks, and create their own automation solutions. b) Scripts must be capable of running in either the configuration environment (draw or edit) or the runtime environment (view). c) The scripting language must use Microsofts IntelliSense feature, exposing all properties, methods and events of graphic objects. This includes 3rd party ActiveX controls. d) Script editing shall be with the Visual Basic Editor (VBE), which is part of VBA.
2.2.1 Scripting language requirements

Comprehensive integration of Microsofts VBA into the SCADA system is required to provide a broad capability to expand and extend the system. This is required to ensure that the SCADA system has the power to be adapted or enhanced to meet any special current or future requirements. Accordingly VBA must be integrated to enable its use for: a) Animation of objects in pictures b) Automatic generation of pictures or objects c) Read from, write to, and create database points d) Automatically run other applications e) Incorporate custom security features f) Create custom prompts and messages for operators g) Access ODBC or ADO data sources h) Incorporate and communicate with third party and custom Active X controls i) Trap bad or misbehaving Active X controls to prevent crashes j) Write custom wizards for frequently performed tasks k) Allow use of global scripts and global variables l) Scripts become part of the graphic screen. m) The VBE must allow import and export capability n) There must be a link between the graphics editor to the VBE o) VBA or the VBE is lunched from within the system, without any commands

p) All properties, methods, and events of graphic objects created within the graphic editor, or third party ActiveX controls used in the graphic screen, must be exposed to VBA.
2.2.2 Object hierarchy overview

The system shall provide the following object categories: a) Global level objects: Are available to all other objects and contain application-wide information. b) Document level objects: Contain other objects. Example a graphic screen object containing a shape object, and a toolbar object containing a button object. c) Shapes and user objects: Visible objects, such as shapes, bitmaps, charts, and Active X objects, which can be drawn or inserted in pictures. d) Hidden Objects: Have no graphic representations in graphic screens, however are available and work with any other object, and perform specific functions. Example would be a timer object.
2.2.3 Renaming, duplicating and moving objects

a) If an object is renamed in a graphic screen the name shall be changed automatically in the VBA script of the object. b) When an object is duplicated in a graphic picture the script, form and module shall also be duplicated and a new name reference shall automatically happen to for the new object, form, module, and script. c) When an object is moved between pictures the form, module and script shall move with it. If the object is placed into a graphic screen that already is using the same name, the renaming mentioned above must take place for the object, form, script, and module.
2.2.4 Global scripts and variables

The system shall provide the ability to have scripts and variables available across all graphic screens. These global scripts and variables must get loaded when the system is started.
2.3
Time and Event Triggered Actions
The SCADA system shall include a facility to enable users to automate events or actions based on certain conditions. a) Actions may be based on a database point changing its current state. For example if point x changes state, then change the state of point z. b) Actions may be time based. For example to print out a set report every day at a set time, excluding weekends. The following time-based triggers are required: c) One Shot d) Continuous e) Daily f) Monthly The following event-based triggers are required: g) On Change h) On True i) On False j) While True k) While False List of possible actions/operations required in response to a trigger: l) Open, Close or toggle the state of a digital point m) Write or Ramp a value n) Print a report o) Enable/Disable an alarm

p) q) r) s) t) u) v)
Set a database points Scan to On, Off or Toggle the Scan Set a database point to Auto or Manual or Toggle Auto/Manual Alarm Horn Open, Close or replace a picture Acknowledge an alarm Acknowledge all alarms Run a custom script (e.g. VBA script)
General Requirements w) It shall be possible to utilize valid VBA code in this facility. x) The system shall support a script-authoring wizard for events. The wizard will generate a VBA script tied to the appropriate event. Once this script is created, editing must be allowed from the wizard or the supplied Visual Basic Editor (VBE). y) The facility must be able to run as a background service in the Microsoft environment to allow scripts to run irrespective if an operator is logged in, or if the graphics application running.

3 Configuration Facilities
3.1 Introduction
The SCADA system will provide configuration services that meet two main objectives: a) Configuration of the core elements of the system, being the database and the common SCADA displays, requires tools that ensure: ) Common, repetitive tasks shall be automated as far as possible to reduce configuration time and costs. ) The resulting configuration shall be inherently consistent, without the need for micro-management. ) Ongoing maintenance and/or extension of the system shall be inherently simple to reduce maintenance costs and retain system integrity. ) Configuration shall not require specialist software expertise b) Configuration of unique or unusual requirements, either now or in the future, can be met by a combination of a highly open software architecture and inclusion of very flexible and powerful configuration tools.
3.2
General Requirements
a) Source code modifications, re-assembly or recompilation must not be required for implementing user-level system changes. No programming, compiling or linking shall be required to configure the system. b) All configuration changes shall be capable of being made on-line. That is, new function and database point assignments can be added while the system is performing data acquisition and control operations. Data definitions, operator displays, etc. shall be capable of being modified, added or deleted without having to interrupt the data acquisition. c) The entire system should be able to be generated automatically through the use of its scripting language. d) The software shall be configurable by any user on the system who has appropriate security access. The system shall provide a mechanism for accepting configuration input either directly from the keyboard, via a mouse, or as appropriate, indirectly through ASCII files that are created by an external text editor or relational database program. e) The database editing must be able to be accessed locally or across the network. One computer shall be able to edit a database on another networked computer while online.
3.3
Database
3.3.1 Database point configuration

a) Various input/output hardware assignments, as well as processing functions, shall be assigned to named points (otherwise called I/O tags, tags or blocks). b) It shall be possible to link multiple points in chains to perform more complex functions. c) During the configuration process, the program shall be capable of checking the point structures for correct linkages, appropriate names, and so on. d) The scan processing program shall also be capable of detecting and handling configuration errors at run-time. Any errors encountered shall generate messages to the user. e) The user shall be able to perform point configuration (adding, modifying, deleting, viewing) in several ways, as follows: ) Directly from the graphics editor, so that points can be configured as graphics are developed. ) Via an interactive spreadsheet-style database builder program that uses a fill-inthe-blank menu methodology. The database builder program shall provide the following editing functions: Cut/Copy/Paste points Duplicate points

Generate multiple points from a given pattern Sort points Query points Display points in user-configurable formats Via the importation of a CSV text file developed in another program as input for point creation. ) The database builder program shall also be able to import and export the current point listing as CSV, GDB and tab delimited text files. ) Point duplication and generation of multiple points shall be completely independent of the creation of graphics displays. Use of a programming language, such as Visual Basic, C or a C-like language, shall not be required. f) Database verification. The package must also allow for database configuration verification. This task will allow for verification of configuration errors on a local database or a database on another node. Errors shall be reported in a dialog box and a user must be able to make the corrections from this dialog box. g) Point Database Editing. The database shall allow for editing from a graphic editor, from within the building of a graphic operator screen, or from within a VBA script.
3.3.2 Database point types

Functions shall be available in the database to support the following point types:
a) b) c) d) e) f) g) h) i) j) k) l) m) n) o) p) Analog Input Analog Alarm Analog Output Analog Register Boolean Logic Calculation Device Control Digital Input Digital Alarm Digital Output Digital Register Multi-State Digital Input Event Action Fanout Program Real-Time Trend q) r) s) t) u) v) w) x) y) z) aa) bb) cc) dd) ee) ff) Text Timer Totalizer PID Lead/Lag Dead Time Ratio/Bios Ramp On-Off Control Signal Selector SQL Data SQL Trigger Pareto Statistical Data Statistical Control User-Created custom point
A description of each point type is given below: Analog Input. This point shall read an analog value (time, temperature, voltage, pressure, level, etc.) either directly from an A/D converter or from a register within an I/O device such as an RTU or PLC, and automatically scales the raw data to engineering units (seconds, rpm, MW, degrees, etc.) An Analog Input point must also support write outs. Analog Alarm. This shall provide enhanced alarming capabilities to the Analog Input, including alarm suspension, remote acknowledgment, delay time, re-alarm time, close a contact based on an alarm condition, etc. An Analog Alarm point must also support write outs. Analog Output This point shall write an analog value (set point, output, speed, etc.) either directly to a D/A converter or to a register within an I/O device, such as a programmable controller. Analog Register This point shall access multiple analog I/O points for read or write functions with a single I/O point. The number of addresses is dependent upon the I/O device used. Boolean Logic This point-type takes up to eight (8) inputs, typically logical or digital values, and performs Boolean arithmetic on them. The result can then be passed to or used by other points or applications within the system. The operators must include: a) OR b) AND

c) EQUAL d) NOT EQUAL e) NOT
f) XOR g) NAND h) Parentheses
Calculation This point-type takes up to 8 variables or constants and performs an arithmetic calculation on them. The result can then be passed to or used by other points or applications within the system. The operators must include: i) Add p) Exponentiation j) Subtract q) Natural log k) Multiply r) Base-10 log l) Divide s) Relational operations (greater m) Parentheses than, less than) n) Absolute value t) Change floating point values to o) Square root integers Device Control This supports 16 digital inputs and 8 digital outputs, each with random (i.e. not necessarily contiguous) addresses. A set of statements within the point shall provide the ability to perform pattern checking, interlocking, and timing. Digital Input This senses the logical on/off state of a switch, relay, pushbutton, etc. either directly from the I/O hardware or from a bit within the memory of an I/O device, such as a programmable controller. The value shall be displayed in a user-selected format (0/1, open/close, false/true, etc.) A Digital Input point must also support write outs. Digital Alarm This provides enhanced alarming capabilities to the Digital Input, including alarm suspension, remote alarm acknowledgment, delay time, re-alarm time, close a contact based on an alarm condition, etc. A Digital Alarm point must also support write outs. Digital Output This sets a logical on/off state in an output relay either directly in the I/O hardware or in a bit within the memory of an I/O device, such as a programmable controller. The value shall be accepted in a userselected format (0/1, open/close, false/true, etc.) The Digital Output point must also provide outputreverse handling and the ability to specify an initial cold-start position. Digital Register This accesses multiple digital I/O points for read or write functions with a single I/O point. The number of addresses is dependent upon the I/O device used. Multi-state Digital Input This point combines up to three (3) digital values and outputs a value of 0-7 based upon the status of the values in sequence (000 = 0, 001 = 1, 010 = 2, 011 = 3, 100 = 4, 101 = 5, 110 = 6, 111 = 7). Event Action This point-type monitors the value or alarm conditions of an I/O point and, based upon TRUE/FALSE conditions, performs one of two operations. These operations include starting or stopping the processing of another point or opening or closing a digital point. Fanout This point passes the value it receives to up to five points within the same database. Program This function provides the user with a procedural language for sequencing, monitoring, and controlling typical process operations. The programming function shall execute within the databases scan cycle and is separate from the HMI scripting language. Program functions shall include: a) If/Then go to another step b) Wait until a process condition occurs

c) d) e) f) g) h) i) j) k) l) m) n) o) p)
If time-out go to another step Go to another step Set a point to a value or the value of another point Open/Close a digital point Set Auto/Manual status of a point Set On Scan/Off Scan status of a point Add/Subtract a value to/from a point Print a message Call other program blocks as subroutines Run other program blocks in parallel Stop other program blocks Pause or delay a number of seconds Play a .WAV sound file Run an executable program
The current step being processed must be capable of being displayed on the operator's CRT. In addition, a debug mode shall be provided to facilitate program checkout. Real-time Trend This point shall take as its input an analog or calculated value and save up to six hundred (600) values. Averaging of accumulated input values will be provided to extend the amount of time represented by the trend block. The data within the point can be graphically depicted on operator displays. Text This function reads or writes text of up to eighty (80) characters from or to a device. Timer This point performs a counting operation. It counts in either the up or down direction, from a pre-set value to a target value. Upon reaching the target or time-out condition, a contact may be closed. This point also supports conditional next block processing. It shall time up to one (1) year. The timer may be started, stopped, reset or resumed based on a sensed condition or operator command. Totalizer This point-type maintains a floating point total for values passed to it from other database points. PID (3-term) control This point will provide a modulated output based on the standard PID algorithm. The output will be positional and will be capable of being used as the setpoint term for cascaded loops. Setpoints can be provided from the CRT keyboard or from other points or programs. The input to this point can be from an analog input, a calculated value from another point, or from a program. Lead/lag This point will provide the transfer function necessary for feed-forward control. Dead time This will delay a signal by a selectable time period from 1-255 seconds to compensate for transportation delay. Ratio/Bias The output of this point will be a linear function (y=mx+b) of the input. Ramp The output of this point is a linear increase/ decrease to a selected target value over a selected time period. This function will support up to three (3) individual ramps to targets with user-defined hold times between the ramping action. On-Off Control

This function provides a convenient means of receiving an analog value and sending a digital value (ON or OFF) corresponding to the analog (HI/LO) limits. Two (2) contact outputs are allowed per analog input. Signal Selector This can take up to six (6) input signals (sensor-based, calculated or numeric constants) and output a single signal as selected by the user: a) - High, Low, Average, or Sum of the signals b) - First good signal c) - First, Second, Third, Fourth, Fifth, or Sixth signal SQL (Structured Query Language) Points. This shall consist of two (2) database point-types, the SQL Data and SQL Trigger, which facilitate the transfer of information bi-directionally between the data acquisition system and a relational (or other) database management system, based on event, time or both. It shall utilize Microsofts 32-bit Open Database Connectivity (ODBC) for connection to the external ODBC-compliant database. The capability to transact among multiple databases and multiple rows within a database is required. Also, "Stored Procedures" shall be able to be invoked in the relational database. In the event that the database server is "down" (not available) at the moment that a query is executed, the system shall provide a built-in capability to back up the SQL commands and data to user-definable primary or secondary hard drives. The system shall automatically detect when the database server comes back on-line, and, at that time, shall execute all of the transactions that it has backed up. Support of communication to multiple relational databases simultaneously is also required. SQL Data This point defines the data which is to be transferred between the data acquisition system and the relational database, and also, the direction of information flow. SQL Trigger This point defines the conditions (triggers) under which the transfer of data will take place. Pareto This point-type will accept up to eight (8) inputs and will sort these inputs and their associated descriptors in one of the following ways: ascending, descending, none. Statistical Data This point will take its input either manually (from the operator's keyboard), automatically (from a sensed input elsewhere in the system) or externally (from another program). It must provide the following types of alarms whenever: a) A user-configurable number of consecutive X-bar values is outside the control limits. b) A user-configurable number of X-bar values is outside the warning limits (67% of the control limits). c) A user-configurable number of range values is outside the control limits. d) A user-configurable number of consecutive ascending or descending X-bar values occurs. e) A user-configurable number of consecutive X-bar values is above or below the control limits. f) Not enough (user-configurable) X-bar values cross the X-axis (non-randomness). Statistical Control This takes the output of a statistical data point (the X-bar value) and applies rate and deviation factors to calculate an adjustment to a specific process variable. In this mode, the block performs control based on statistical inputs. Batch Support The system will provide blocks for state-driven, sequenced, interlocked, batch control operations. The software development company meeting this specification must be able to offer a fully integrated Batch package for future considerations. The functions shall include. a) Device Control. For coordination of opening and closing digital devices based upon userdefined conditions. b) Program. For running short programs for batch operations or to increase the degree of automation in an application.

Custom features. The ability to add optional function blocks that will co-exist with the standard function blocks and have all the same configuration access as the standards block. The optional blocks are to be built by a toolkit offered by the software development company.
3.3.3 Point attributes

a) Each point will have an alphanumeric name of up to 30 characters. b) All other application programs will use this point name as their sole reference to the data element assigned. c) For points assigned to actual hardware points, they shall also contain fields for: ) Hardware device name ) Hardware address ) Hardware specific parameters ) Signal conditioning requirements d) Simulation points can also be created that receive their values from the operator's keyboard, other internal calculations, or other programs. e) Points shall be processed periodically, with the fastest scan rate being fifty (50) milliseconds. Scan rates shall be able to be set independently for each appropriate point. Longer scan rates of up to once per twenty-four (24) hours shall also be supported. A mechanism for load-leveling, or phasing, the time-based processing of points is also required. f) Alternatively, the user may elect to have points processed on an exception basis. This choice shall be allowed on a point-by-point basis. g) Any input point may also be configured as a "one-shot". This will cause it to fetch the value from the I/O device just one time when the system is started or the point is brought on scan. h) All points must have a description field. i) Each point associated with a hardware address or capable of causing an alarm condition shall have a means of displaying a descriptive message on the alarm printer. The descriptor shall be at least 40 characters in length. j) The system shall provide built-in signal generators, including sine waves, ramps and pseudo-random random numbers, that can be used for process simulation purposes. k) Any output or control block must be able to log a "time stamp" when an operator changes a value.
3.4 Baseline Display Editor Requirements

This section describes the general purpose capability required within the display builder package. It covers the following core requirements: a) An open, object-based development environment b) A comprehensive range of drawing primitives that provide the customer with complete flexibility to achieve a high standard of data-visualization, incorporating a wide variety of data. c) A development environment that is immediately familiar to Microsoft Windows users. This is followed in section 3.5 by a description of the advanced graphics configuration tools required to automate the process of display generation, thus reducing the time and cost of display generation for the majority of the SCADA application.
3.4.1 General capabilities

a) The SCADA display builder package must provide a means of creating and displaying color object-oriented graphical displays that will be used by the operator to monitor and control the system. Real-time values being read from the field devices shall be capable of being displayed in a variety of user-configurable formats. b) Graphic displays shall be standard Microsoft Windows files and shall be able to be stored on the system disk, a floppy diskette, virtual (RAM) disk or file server, based on userentered selections. There shall be no limit (other than physical disk size) to the number of displays that can be developed and accessed on-line.

c) Support for displays larger than the size of the monitor shall be provided. If used, scroll bars shall be provided to allow the user to move to other areas of the display. d) Display screens need to be based on objects and not individual pixels. The object graphics will consist of an image and image attributes, such as size, color, and position that will define the properties of the object. The user will use tools menus and dialog boxes to change object properties. An object is defined as anything that can be created with drawing tools from within the package, an image imported into the package, or any 3rd party ActiveX control. e) All properties, events, and methods of the object, including 3rd party controls, must be exposed to the system and available for the developer. f) The system must support changing individual graphic files (displays) at any time with no additional configuration, or requiring the system to be stopped, or restarted. g) The system shall support the pre-loading (caching) of pictures to improve display performance. The use shall be able to set a list of pictures to be pre-loaded when the system starts, or select a maximum number of pictures to be automatically cached in memory as the system runs.
3.4.2 Display creation

The system shall provide an interactive object-oriented editor or workspace that allows creation of graphical displays using a mouse or other pointing device. a) A facility shall be provided that quickly toggles, via a mouse click or hot-key, between the graphic building and graphic runtime modes to speed display animation verification during the development process. b) The software must be designed with the ability to make changes to the displays while the system is running. Shutting down the system shall not be required to make changes. If the display files are stored on a network file server then all machines will see the effect of any changes the next time the display is viewed. c) Once an object is created, the object shall be automatically be placed on directory tree similar to Microsofts Explorer program. 3.4.2.1 Object properties a) A properties window, exposing all properties for an object, must visible on the graphics development workspace. b) The properties window must support edit functions for any object selected. c) All properties are to be available in both the graphic workspace and the scripting language. Object duplication a) Object properties must be passed when an object is copied. b) Copying should be able to occur from the tree browser or workspace. c) All properties must be passed on to the duplicated object and the name properties must automatically get changed. Example: When an object with the following properties Name: OVAL; Foreground Color: RED 024 gets duplicated the new objects properties are Name: OVAL1; Foreground Color: RED 024. d) If an object is copied all of its scripts shall be copied with it. If the script refers to a property of the object (or any item grouped within the object), the new copy shall correctly refer to its own copy of the object. Object drill down The system shall allow the developer to drill down into any sub or grouped objects within any other object and change any property, script, or animation without the need to ungroup or otherwise modify the main object. Tile & cascade a) Display screens that are opened in configuration mode must support tiling and cascading. b) Tiling must have horizontal and vertical support and no overlapping when the graphic screens are viewed in this manor. c) The only limit on the number of graphic screens opened at one time is by the amount or RAM in the computer.
3.4.2.2
3.4.2.3
3.4.2.4

d) Cascading is defined as a method to staggered pictures so they can be selected from their title bar. 3.4.2.5 Display sizing a) Size shall be based on logical units; not pixels and any logical unit may be used. b) Displays designed at one resolution must be able to run at a different resolution. c) A full screen option as well as the ability to add sizing borders to any display shall be supported. d) Displays must have an option to enable the display to always be on top and a title bar enabled / disabled option. ActiveX support a) Displays must be active X documents and have the ability to have third party ActiveX OCX, controls dropped in. b) The system must be capable of containing any control that is placed onto a display. If a third party control crashes or misbehaves the system must be able to shut down the control while the display, system and computer remains running. Running third party controls out of the process is not a suitable for this protection. Relational database support a) The display builder package shall provide the ability to insert tables, queries, views and procedures from any ODBC or OLE-DB database (Access, SQL Server, Oracle, dBase, etc.) into a picture. b) The system shall include list-boxes, combo-boxes, grids, and data controls to interact with and query the database. c) All of these controls should have the ability to be linked together so that, for example, the user can select a batch number from a list-box and the grid control automatically updates, with no scripting required of any kind. d) The data control should have a wizard to automatically create SQL queries without the user knowing SQL. However, the user should have the ability to view and modify the SQL created by the wizard. e) The data control must support asynchronous data transfer to/from the database so that large queries can be executed without adversely impacting performance. f) The data control must support reading and writing to a database using the built-in procedures of the database. In addition, if connecting to a procedure the control should indicate the number and type of variables that the procedure requires.
3.4.2.6
3.4.2.7
3.4.3 Color support

The display builder package shall provide support for an unlimited choice of colors with 256 colors supported at any one time. The user shall have the ability to create, save, and restore custom color palettes. Each color must have an associated name so users can selected from the color from the name of the color. 3.4.3.1 Color palettes The system must come with a standard, rainbow color palette as well as several standard, shades of color palettes. Each shade palette needs to have 256 shades. The following standard shade palettes must be supplied. a) Cyan e) Red b) Gray f) Yellow c) Green g) Blue d) Magenta
3.4.3.2 Color changes Color changes must be selectable from editing the individual foreground, background, or edge color property for each object. A "modeless" color box must float on the workspace to allow the user to change color on as many objects as they wish and choose which property of an object or objects they wish to change.

3.4.3.3 Global colors The system shall allow for a global or universal color table selections. This table is based on exact match, or range compression, or a value. The colors in the tables will appear on any graphic screen when the value for the data source of the object matches the table. Changes to color tables must be independent of the displays and not require the user to compile or pass the display through the display builder package or mode for changes to take place. Changes to global color tables must be supported in runtime mode.
3.4.4 Graphic toolbox

a) The system must provide configurable toolboxes that the graphics developer can customize as to what tools it contains and their position in the toolboxes. b) The Toolboxes must be a Window where its shape, size and location can easily be changed with the mouse. c) Toolboxes shall contain a method, like the ToolTips within Microsoft Word, to describe the function of each tool when the mouse cursor is positioned on a particular tool. d) Once configured, the state of the toolboxes shall be automatically saved when the drawing session is completed. It shall be returned to that same condition when the next drawing session is started. e) Users shall have the ability to define their own buttons. 3.4.4.1 Graphic objects
At a minimum, the following basic object drawing tools must be supported: a) Rectangle/Square b) Rounded Rectangle/Rounded Square c) Oval/Circle d) Straight Line e) Polylines (two or more connected line segments) f) Polygons g) Arcs (curved line segments) h) Chords (a curved line connecting a line segment) i) Pie Shapes (wedges of a circle) j) Text 3.4.4.2 Display development operations
Operations that may be performed on objects or groups of objects must include the following: a) Select/Select All b) Deselect/Deselect All c) Change Color d) Move e) Nudge (move a single pixel at a time) f) Cut, Copy, Paste g) Clear h) Duplicate i) Group/Ungroup (objects within a group must be selectable without ungrouping) j) Align (left, right, top, bottom, vertical center, horizontal center) k) Space Vertically/Space Horizontally l) Grid, Snap-to-Grid m) Reshape n) Zoom In/Zoom Out (50%, 100%, 150%, 200 %) o) Send to Back/Bring to Front p) Choice of line and fill styles q) Reshape (add/delete/move points) r) Flip horizontally/Flip vertically (mirror image) s) Search and Replace point names (including the use of wildcards) t) Undo (the number of levels shall be user-configurable up to 50) u) Cursor position (optionally on the display for exact object placement) v) Rotation (center of rotation selectable from any part of the screen)

w) Space objects evenly (vertical & horizontal) x) Make objects same size (height, width and both) y) Layers (for building and viewing, up to 30 layers supported)
3.4.5 Display animation

The display builder package shall provide the ability to configure elements in SCADA displays that dynamically update (animate). Configuration of animation shall be provided by an easy-to-use, mouse driven tool. The system shall include at least the following pre-defined dynamic link elements: a) Data link b) Time link c) Date link d) System information link e) Summary List link f) Pushbutton link g) Multi-pen Chart link h) OLE objects Displays alphanumeric values (numeric values may be displayed in whole number, decimal, or scientific notation) Displays current time Displays current date Displays diagnostic information Reference 1.2.3 Execute a script, reference 2.2 Reference 1.2.2 Display a third part OLE object
3.4.5.1
Dynamic properties for objects a) Dynamic (animation) properties that may be assigned to an object or group of objects shall include at least the following: Color changes: ) Foreground Color ) Edge Color ) Background Color Fill percentage: ) Horizontal (Left/Right) ) Vertical (Up/Down) Position/animation: ) Horizontal (X) ) Vertical (Y) ) Rotate ) Scale Script language: ) Commands on down (mouse button or key) ) Commands on up (mouse button or key) ) Commands on mouse click ) Commands on mouse double click ) Commands on mouse move ) Commands on edit Fill style: ) ) ) ) ) ) Solid Hollow Horizontal Vertical Downward Diagonal Upper Diagonal

) )
Cross Hatch Diagonal Cross Hatch
Edge style: ) Solid ) Hollow ) Dash ) Dot ) Dash Dot ) Dash Dot Dot ) Null ) Inside Frame b) It shall be possible to assign more than one dynamic property to an object. c) Objects within groups may have individual dynamic properties, in addition to those dynamic properties assigned to the overall group. d) For properties other than "Commands", configuration shall be by "point and click" operations; scripting or programming shall not be required to define animation. e) Positioning property changes must support a method to get screen coordinates and automatically fill in the required coordinates for positioning. f) The user customizable dialog boxes or forms must be customizable through VBA. The system must supply the following pre built forms: ) Fill ) Open Picture ) Rotate ) Close Picture ) Position ) Replace Picture ) Scale ) Open Digital Tag ) Visibility ) Close Digital Tag ) Edge Color ) Toggle Digital Tag ) Foreground Color ) Toggle Digital Tag ) Background Color ) Acknowledge Alarm ) Data Entry
3.4.6 Display refresh rate

The refresh rate shall be user-definable on a per object basis with the fastest rate being fifty (50) milliseconds, although it is recognized that achieving this performance is dependent upon the overall system configuration.
3.4.7 Sources of data for object animation

a) The animation of the graphics and objects with dynamic properties shall be able to be linked to any of these types of data: ) Data acquired by the local system and stored in its SCADA database ) Data acquired by another networked system and stored in its SCADA database ) OPC data source ) Variables declared in the scripting language ) Local and networked relational databases using SQL/ODBC ) 3rd party ActiveX controls (without creating temporary or dummy tags) b) The system shall provide a wild card supported filter for assigning a data source. c) The system must provide an expression builder that is accessible from the display builder workspace. The expression builder will allow an expression to be assigned to the data source. Functions required in the expression builder are: ) Addition + ) Subtraction ) Multiplication * ) Division / ) Left & Right Parenthesis () ) Equal To = ) Not Equal To <> ) Greater Than >

) ) ) )
Less Than > Greater Than or Equal To >= Less Than or Equal To <=
3.4.8 Bitmaps
The system must allow for bitmaps created by other packages to be imported into the graphics, Bitmaps must support a transparent mode and Metafiles must import as objects not just bitmaps. At a minimum the system must support .bmp, .msp, .jpg, wmf, pcx, ico, cur, psd, epr, and wpg.
3.4.9 Support Microsoft Excel and Word documents

Microsoft Excel and Word documents must be able to live within a display screen. The documents will run within the display, not as an external call. The Microsoft Excel or Word toolbars will get inserted as part of the display toolbars for editing.
3.5
Automation of Graphics Configuration
The previous section describes baseline display configuration capability expected within the SCADA. This section describes the advanced tools required to automate the process of display generation, thus reducing the time and cost of display generation for the majority of the SCADA application. The majority of components within SCADA displays are repeated many times. This reflects the repeated use of identical or similar devices in the field. These devices are functional units as recognized by the customer, such as circuit breakers, transformers, motors and valves. Each of these devices are usually represented by multiple points within the SCADA database. For example what the customer considers as a transformer may include a transformer tap position control, MW and MVAR analogs, Ground fault alarm, oil temp trip and perhaps 20 other indications and alarms related to the transformer. Similarly a motor may include motor state indications, motor controls, RPM, bearing temperature(s) and so on. a) The system shall include a library of compounds that accurately and completely represent these real-world devices. b) The system shall also include the capability for the customer to modify these compounds to make new variants for new real-world devices. c) Using a compound from the library shall only require: ) Drag and drop from the library to the display ) Selection of the name of the primary device from a database menu pull down In some instances minor other configuration may be required to define specific application of the compound: For example the user may need to select left and right voltages for a transformer. If required these shall be provided from pull-down menu. d) Each compound shall automatically define at least the following properties of their respective real-world device: ) Graphical representation of the real-world device, including automatic selection and display of all SCADA database components that are part of the compound, including all their animation properties in all conditions. i) The separate layering visibility properties of each database point within the compound to ensure the correct clutter/declutter appearance of each point within the compound during zoom in and zoom out (section 1.2.1). For example the state of a circuit breaker may be visible at all zoom levels, while the 3 feeder current analogs associated with the circuit breaker may only become visible when the user is zoomed in. ii) Graphical representation of key SECONDARY points associated with the main device, including their animation properties in all conditions. Examples of primary and secondary points are shown in section 1.2.3 iii) All the content of the user interface dialog (section 1.4), for the primary and all secondary points. The dialog for every point shall be specific, accurate and complete for the requirements of each individual point within the compound. iv) A notes record (section 1.2.6) for the device.

) ) )
A link to a Tabular display of all secondary points related to the main device. The system shall automatically populate this tabular display with all secondary points. The interface dialog for all secondary points, whether on the primary display or on the tubular display. The dialog for every point shall be specifically accurate and complete for the requirements of each individual point. This automation system shall by its design ensure that all instances of the same type of device look and operate in the same way throughout the system.

4 Administrative Facilities
4.1 Startup and Shutdown
a) The normal configuration shall be for SCADA server(s) to automatically starts all the necessary SCADA services on power-up, and similarly for any dedicated SCADA clients to automatically start SCADA client services on power-up. b) SCADA system operations may be shutdown by menu selection in the main menu. Proper system security and access privileges shall be required to access this option. c) The SCADA system shall automatically retain important settings during shutdown and restart including at least: ) Manual overwrites ) Control and information tags ) Alarm disable settings ) Off/On Scan status ) The status of any simulated points
4.2
Security Management
The software shall provide a user-based security system that provides: a) If enabled, the security system must allow for the creation of users with certain rights and/or privileges. b) The ability to allow/deny users access to change values, such as set points on an individual point basis. c) Groups of users, such as Operators or Supervisors, can be created and granted rights. All users assigned to a group obtain the rights of the group, although they are still tracked by the system by their individual ID. Individual members of a group may also be assigned additional rights. d) The security system shall support either centralized or distributed security file management. e) The system shall support using Microsoft Windows 2000/XP security in lieu of, or in addition to the packages own security system. If using the 2000/XP security, the system shall authenticate a user on any security domain without requiring the system to be restarted. f) When user-based security is enabled, an audit trail will be generated in the system which will tag every operator action with a user identification (ID). g) Systems that use a numeric level-based security methodology shall not be acceptable.
4.2.1 Security areas

a) The system must support up to 254 separate security areas. b) Security areas shall be assignable on a per point basis. Each point can be assigned all of the available security areas, none of the available security areas, or up to three individual security areas. c) Only users with clearance for those security areas shall have the ability to change parameters. d) Security area names may be up to twenty characters in length.
4.2.2 Security manager

The following functions must be supported within a security manager application: a) Enable/Disable user-based security b) Define users, passwords and login names c) Define groups to which users may belong d) Define user and/or group rights/privileges e) Define security area names f) Define system auto-start user

4.2.3 Securing the Microsoft Windows GUI environment

The ability to "lock" an operator or other user into the runtime graphics environment shall be provided. Specifically, disabling any combination of the following shall be supported, as configured by the user: a) Starting other applications b) Switching to other applications that may be running c) Exiting from the system d) Restarting the computer using <Ctrl><Alt><Delete> e) Opening unauthorized graphic screens f) Closing the current display g) Using the system menu. h) Switching to the configuration environment
4.2.4 Limiting login time

The system shall allow for a login timeout setting for each user account. This variable setting will logout an operator when the time interval expires.
4.2.5 Automatic and manual logging in and out

The system shall support manual login and logout as well as automatic login. In addition security information must be customizable through VBA scripting.
4.3
Multi-Lingual Support
The software shall support translation into different languages. This shall include support for extended character sets like Asian and Arabic, using either Unicode or MBCS to represent characters that are not in the ASCII set.

5 Computer Hardware
The system shall be capable of operating on current models of Intel based personal computers (PCs). The system shall support a variety of input devices, including: a) Mouse or Trackball b) Touch-screen c) Keyboard (standard or function-style) The support for and use of any of these entry devices shall be as provided within Microsoft Windows or by the manufacturer of the input device. As appropriate, simultaneous support for multiple of these devices shall be provided.
5.1
Multiple Monitor Support
Workstations shall support one, two, three or four monitors with appropriate video adapter. Multiple monitors shall behave like one large desktop. For example three monitors of 1280x1024 resolution provide an effective desktop of 3840x1024 (3 x 1280 = 3840). The multi-monitor support system shall: a) Operate with one mouse and keyboard b) Enable the mouse to move freely between all monitors c) Enable users to drag and drop pictures onto any monitor d) Enable users to stretch pictures within one monitor e) Enable pictures to be configured to pop-up on any monitor and any size f) Enable users to easily send pictures to the monitors adjacent to the current monitor

6 Local Area Networking (LANs)

a) The system shall be capable of supporting the following network configurations: ) Ethernet Network Adapters ) NetBIOS and TCP/IP network protocols b) The system must provide session-oriented communications for data transfer. Each computer station must be capable of establishing up to 100 sessions with other stations. c) The system must be capable of distributing different files and functions on file servers and network resources other than a stand-alone computer to ease system management. For example, historical data may be saved on one server, graphic (display) files on a different server and so forth. d) The SCADA software shall also be capable of running simultaneously with other LAN users who are not operating the data acquisition system software (but who might be using a LAN manager or file transfer software).
6.1
LAN Configuration and Expansion

a) The system will provide an on-line installation and configuration program for configuring the various computers on the network. This configuration program will allow assigning unique node names to each computer as well as selecting the functions that the machine will perform. b) The system will allow additional computers to be added to the network while on-line, without disrupting the operations of the other machines.
6.2
LAN Error Detection, Recovery, and Diagnostics

a) The system shall provide on-line diagnostics that display the current status and operation of the LAN and its computers. The diagnostic display must include the LAN adapter status for the computer showing the display, as well as the current number of messages, errors and retries. b) An additional display shall show the current session status (established, pending, off-line) of all computers on the LAN. A session monitor program that automatically monitors and recovers communications shall be supplied with the system. c) Should network communications errors be detected the software shall automatically indicate that the data (on graphic displays, in historical files, etc.) is no longer valid and shall replace the invalid data with any user defined characters or the ability to alter the color or font of the text. The system shall automatically attempt to re-establish communications, and, if successful, shall then replace the characters with valid data. This capability shall be built-in to the software and shall not require any user programming or other user-dependent actions to implement. It shall be customizable by the user whether the last known good value remains on the screen, with, or without different colors to indicate an error condition, or to have the user-defined characters discussed above used instead.

7 SCADA System Architecture

7.1 Standalone Systems
a) The SCADA software shall be able to operate entirely as a single-computer, nonnetworked application. A single computer system shall be capable of performing all SCADA functions required by this specification including but not limited to: ) Communications, data acquisition and SCADA database management ) Real-time monitoring and operator control using all facilities required by this specification ) Alarm and event processing ) Historical storage, reporting and trending as required by this specification b) Should the customer elect to add additional operator workstations computers at a later time, then reconfiguration or duplication of database points within these new computers shall not be required to make data available to their users.
7.2
Networked and Distributed Systems

a) The system must have a distributed, client/server system architecture based on OPC and Component Object Technology (COM). LAN/WAN shall be used for communicating among computers. b) Each computer may be assigned one or more tasks. For example: ) Computer "A" may be used simply for SCADA monitoring and control ) Computer "B" may be connected to a I/O devices and used for data collection and SCADA database management ) Computer "C" may perform the roles of both A & B a) Additional distinctions in computer role, such as read versus read/write capability shall be provided by the security access system (section 4.2). d) Data shall be available to all computers and individuals on the network that have been provided access. Real-time data shall be available directly across the network from the computer that acquired it from the process hardware. Configurations that require each computer to contain copies of database points it needs to access are not acceptable. b) The system shall be configured such that the failure of any one computer will not affect the operation of others on the network. It is recognized that unless server redundancy (section 7.3) is been implemented, data contained in a failed computer will be unavailable to other computers requesting it.
7.3
Data Redundancy
The SCADA architecture will be able to provide data redundancy in the following situations:
7.3.1 Redundancy with dual ported I/O devices

A dual ported I/O device means a PLC, RTU, IED or other I/O device that in the customers configuration can communicate simultaneously with two or more SCADA servers. For example a PLC with one or more Ethernet interfaces should be able to provide data to two SCADA servers, either using a single or dual LANs. The SCADA servers shall support this communications. Furthermore SCADA client workstations shall be able to: a) Have (user-defined) primary and secondary data sources (servers) b) Be able to automatically fail over to the secondary server in the event the primary data server becomes unavailable.
7.3.2 Redundancy with single port I/O devices

A single ported I/O device means a PLC, RTU, IED or other I/O device that in the customers configuration has a single communications interface, that is only capable of communicating with a single SCADA server at any one time. For example one or more RTUs may share a single serial channel (for example a single radio channel) for communications with the SCADA server computers.

The SCADA architecture shall be able to provide communications and database redundancy in this situation. That is: a) One server (primary) shall normally communicate with these devices b) Failure of the primary server shall automatically cause a second server to begin and maintain communications with these devices. Fail-over shall not require any user intervention. c) Fail-over shall be complete within 30 seconds d) At least the following information shall be automatically maintained between the two or more redundant servers in this configuration, both during fail-over and during shutdown and restart of servers. ) Any control and/or information tags ) Alarm disable settings ) Manual overwrite settings ) Off/On Scan status ) The status of any simulated points ) Alarms and event ) Operator notes e) Fail-over shall cause client workstations to automatically access data from the new server without any user intervention f) There shall be a facility within the SCADA users interface to enable the user to manually switch these communications between two or more servers.
7.4
Terminal Server Clients
In addition to the client/server networking described above, the system shall support the user of terminal server based clients: a) The system shall offer concurrent licensing for terminal server (TS) clients. b) The system software and hardware shall be capable of being expanded to support at least 30 simultaneous TS clients. c) The software and licensing shall support any mix of the following TS client types: ) Monitor only, with no ability to issue controls ) Monitor and control (i.e. full SCADA operations) ) Monitor, control and full SCADA configuration d) TS client software shall serve the standard SCADA displays in a standard web browser running on the client computer. Accordingly the TS client interface shall look and operate the same as dedicated SCADA clients described above. e) TS clients shall operate on Microsoft Windows (2000/XP) Terminal Server platform. f) TS clients shall be true thin clients. That is they shall NOT require installation of any SCADA software on the TS client computers. SCADA software shall reside entirely on the TS server computer.
7.5
Remote Access
7.5.1 Via the network

The system shall have the capability of creating and modifying tags in one node by operating the graphics editor or database builder program in another node. This operation shall be performed online, while the destination node is operating. This new or modified tag data shall immediately be available to all other nodes on the network. The security system will restrict access to the database to authorized users.
7.5.2 Via modems

Similarly, configuration shall also be available via a computer connected remotely via modems. When a remote computer is connected via a modem, the user shall have the same access as though they were at a computer directly attached to the network. The following functions shall be supported: a) Configuring the database points throughout the network b) Viewing graphic displays being updated with real-time data c) Viewing historical trend data

d) Copying files from/to the network

8 Software Architecture
8.1 Operating System
a) The operating system shall be Microsoft Windows 2000 or Windows XP Professional or later. b) The software shall exhibit strong compliance with Microsofts Windows Open Systems Architecture (WOSA) standards, such as in its use of dialog boxes and menus. c) The system must support running as a service under Windows 2000/XP, making it independent of the 2000/XP user login limitations.
8.2
SCADA Software General
The SCADA software shall make maximum use of the Microsoft Windows environment, delivering features that include: a) Feature-rich, windows-based editors b) Standard Microsoft Windows look and feel c) Open, structured file system d) Comprehensive, powerful graphics editor e) Menu-driven, structured database editor f) The SCADA software shall provide pre-emptive multitasking to ensure that common Windows actions do not interfere with I/O communications, processing of data, alarming, and the integrity of the real-time and historical data. These common Windows actions include moving a window with a mouse, opening a file, accessing the hard disk, or printing a graphic display. g) The software shall be written fully 32-bit so that it runs native in the Windows 2000/XP operating systems. Emulation using 16-bit software code is not permitted. h) The SCADA software shall support for standard Microsoft Windows 2000/XP multimedia capabilities, including audio and video, shall be provided. i) The software shall have been designed to be enabled for language translation.
8.3
Program Language
The underlying system must be written predominantly in the C and C++ languages using Microsoft compilers.
8.4
Software Standards
The system shall provide an open architecture that allows interaction with other programs. It must provide a mechanism for other programs to access individual data elements and fields (such as the high alarm limit of an analog input) within database points in real time. File transfer mechanisms are not acceptable; the access must be direct to the memory-resident database. The following industry standards shall be supported:
8.4.1 VBA
The system must have standard Microsoft VBA embedded as part of the development environment. VBA support will be used for pre-built and custom scripts. It must also support search and replace and the ability to copy all forms modules and scripts from one object to the next.
8.4.2 OLE, OPC and ActiveX support

a) The system must support OLE automation of 3rd party applications. That is, for example allow an Excel spread sheet to be created and fully controlled from the SCADA application. The system must support all events, including asynchronous events, of 3rd party ActiveX controls.

b) The system shall function as OPC (OLE for Process Control) client for communicating to any OPC complaint server. c) The system shall function as an OPC server to serve data to any OPC complaint client. d) The system must support OPC data to be directly accessed by the graphics application. e) The system must support the ability to have any third party OCX (Active X control) placed into its container. f) All third party controls must have the right to behave like any object created by the system. g) The system must contain any bad or misbehaving OCX or Active X control and be able to shutdown the control without shutting down the graphic picture, system, or computer. h) The system must not only allow 3rd party ActiveX controls to be inserted into the application, but for the controls to be able to directly access data from any networked machine without the creation of dummy or temporary tags. i) The system must also allow the ActiveX controls to share data with other objects on the same graphic, or on a different running graphic picture.
8.4.3 ODBC
The system shall support Open Database Connectivity (ODBC) for sharing data from its SCADA database and historical archive to any other ODBC complaint database through SQL queries, via an ODBC dynamic-link library (DLL) driver. At a minimum the database shall support communication to Microsoft Access, SQL Server, and Oracle.
8.4.4 DDE
The system must support Microsoft standard Dynamic Data Exchange (DDE) Server and Client functionality to share data with other DDE-aware applications. DDE should only be used when no other communication means is available.
8.5
SCADA Database
a) The SCADA database containing the current value of the data, or point list, shall be memory-resident and of a design that is appropriate for real-time monitoring and control functions. b) Its design shall be optimized for speed, memory usage, data integrity and system security. c) Floating-point arithmetic shall be used in all calculations. d) The database shall be stored as a standard Windows file on the local or network hard disk. e) Upon starting the system, this database is loaded into the computers memory. f) Only computers physically connected to process equipment shall require a database.
8.6
I/O Device Communications

a) The system must support communication with a variety of external input/output (I/O) devices. The devices that can be interfaced to the system must include: ) Remote Terminal Units (RTUs) ) Intelligent Electronic Devices (IEDs) ) Programmable logic controllers (PLCs) ) Intelligent single-loop controllers ) Distributed control systems (DCS) ) Bar code readers and scales ) Analog-to-digital converters ) Remote I/O ) OPC Servers b) The system must be capable of supporting up to four (4) different types of device communications drivers and up to eight (8) serial ports simultaneously. For multiple device and/or for multiple serial port configurations, a communications co-processor, such as a Digiboard, may be employed. c) The preferred communications software architecture for all communication is OPC (OLE for Process Control). The SCADA software shall fully support OPC communications: It

must be able to send and receive data with an OPC server. That is, the SCADA software shall function as an OPC client to the vendors and third-party communications software packages which shall operate as OPC servers. d) The SCADA system must also be capable of serving OPC information to any OPC complaint database. e) The use of Microsoft Windows Dynamic Data Exchange (DDE) for device communications shall be supported by the vendor. However, the use of DDE shall be limited to communications with low-throughput devices, such as barcode readers and scales. It shall not be permitted for use with RTUs, PLCs or other similar devices.
8.7
Communications Diagnostics
The system will provide a diagnostic program capable of running on-line or off-line that can monitor message rates from the communication program. The diagnostic will display the number of new messages, retries, time-outs, and any occurrences of error. For serial drivers, a built-in datascope shall be provided. This datascope function shall allow the user to observe the messages being sent between the computer and the I/O device.
8.8
Display-Only Communications
To facilitate efficient communications the system shall be able to provide display-only communications. Communications to read or write tags (Analog Registers and Digital Registers) will only be established when a graphics display containing these tags is open. When the display is closed, communications will cease.
8.9
Error Detection and Recovery

a) Wherever possible, the device communications program will perform error checking on messages. These error checks will include lost response (time-out) and data error (checksum, LRC, CRC, etc.). b) Should communications errors be detected, the software shall automatically indicate that the data (on graphic displays, in historical files, etc.) is no longer valid. The invalid data should be replaced with any user defined characters or have the ability to alter the color, or font to let the operator know the data may be invalid. In the latter case the system shall display the last known value. c) The system shall automatically attempt to re-establish communications, and, if successful, shall then replace the characters with valid data. These capabilities shall be built-in to the software and shall not require any user programming or other actions to implement.
8.10 I/O & OPC Server Driver Toolkit

a) A toolkit must be available which will allow the creation of I/O drivers by end users, system integrators, and other third part companies. b) This toolkit must be able to develop DLL I/O drivers as well as OPC Servers through easy to use development wizards. c) The toolkit must be able to auto generate documentation.

9 System Expansion
The system will allow additional computers to be added to the network while on-line, without disrupting the operations of the other machines.
9.1
System Sizing
The system software shall be provided in different sizes to meet various application needs. Ideally, the sizes would be for point counts of 150, 300 and no limit for systems with I/O attached. These systems shall be able to display data from and write values directly to other nodes without the need to duplicate the data in the local system. Configurations that are not attached to I/O and do not contain tags shall also be available. These systems shall be available with two types of rights to a point: a) With rights to read and write to points in other nodes. b) With rights to only read points from other nodes. These rights can be controlled by the developer using security

10 Power Industry Specific

The system shall include the following capabilities specifically for power industry applications:
10.1.1 Bus coloring

Bus coloring improves the clarity of the information delivered to operators, further facilitating safe operation. A facility shall be provided to automatically color bus lines according to their status: ground or live and according to the live operating voltage.
10.1.2 Portable grounds

A facility shall be provided to enable users to easily attach a portable ground and automatically recolor the bus to the chosen grounded color. Bus coloring shall work for telemetered information or operator hand-dressed points. Hand-dressing shall be achieved by clicking anywhere on the bus and changing the status from live to grounded or visa versa in the dialog box.
10.1.3 Drawing tools

The SCADA display editor shall include the following drawing tools specifically to accelerate drawing of power-industry single-line diagrams (or one-line diagrams): a) Draw bus lines to customers preferred bus color and thickness b) Click to make a bus line either vertical or horizontal
10.1.4 Library of compounds

The system shall include a library of at least the following common power industry compounds: a) Circuit breakers j) Replace picture keys b) Controllable telemetered switches k) Notes key c) Non-controllable telemetered l) Rack in plug symbols switches m) In cable symbols d) Voltage transformers n) Link symbols e) Power transformers o) Local service transformers f) Analog indications p) Local service contactors g) Digital indications q) Injection plant h) Portable grounds r) DC converter i) Grounds

GFS For Power Industry For Consultants

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

GFS For Power Industry For Consultants

Uploaded by

Copyright:

Available Formats

SCADA System Software

(for Electrical Distribution monitoring and control)

Guide Form Specification

2004 GE Fanuc Automation, Inc.

SCADA System Software - Specification

Table of Contents 1 INTRODUCTION ............................................................................................................................ 5 1.1 STANDARD SOFTWARE PRODUCTS ............................................................................................ 5