POWER SYSTEM AUTOMATION.pdf

7/29/2019 POWER SYSTEM AUTOMATION.pdf

1/42

Small Boats Harbours Project 16428/1 Power System Automation

SECTION 16428

POWERSYSTEMAUTOMATION

1.0 General

1.1 INTRODUCTION

The system proposed to North and South Harbour KOC marine facilities isdesigned to handle the control command functions and visualisation for theMarine Facilities of the electric power distribution network for the North andSouth Harbour Power facility. All KOC standards and codes should befollowed along with products from approved vendor list.

The solution should be based on standard products easily available in themarket having a proven track record in similar systems. The proposed systemparts and support should be available for a minimum of 10 years. A List ofcurrent installations with a brief description and time of operation should besubmitted.

Standard communication systems are to be implemented (ModbusTCP/IP, RS 485). This ensures that system components from othervendors (electric generator units, un-interruptible power supplies) can beconnected to the system.

Data processing components should be standard Microsoft based(Windows XP PRO, Vista, ODBC, OPC....) and standard principles

(client/server layout) support data from or to other systems or tools(spreadsheets), avoiding the need to develop functions.

The computer hardware should be from standard manufacturer with atleast 3 years warranty from date of delivery.

The solution should be easy to update due to a modular architecture. Addingsoftware functions and hardware extensions is made possible by:

Connecting new protection relays onto existing communication lines,

Adding new data concentrators,

Adding new PLCs, I/O racks,

Extending the existing network, Adding new operator workstations,

Adding front ends if new substations are added.

The main consequences of the above mentioned characteristics are:

If the site or system is extended, the initial investment is not lost,

The initial cost can be spread over a number of steps.


2/42


The system must be able to:

Monitor MV/LV data from electro-technical equipment (generators,transformers, MV/LV devices, motors etc.)

Perform electric power consumption management functions (load

shedding, sending start orders to backup generators, monitor generatorstatus etc.) to optimise electric power network availability and reliability,

Ensure communication with HMI system Monitor Incomer feeders Transformer feeders Motor Feeders Line feeder to other substations Transformer feeders to busbar Aircircuit Breakers Circuit breaker Bus-ties, Reserve feeders

1.2 APPLICABLE CODES & STANDARDS

The proposed system should follow the latest standards and certifications asa minimum or as mentioned in this documentation.

1. IEC2. BSA3. DIN4. ISA5. ISO6. UL7. CE

1.3 DOCUMENTATION

1. The Contractor shall generate/ furnish all related Documents/ Drawings,of Design, Detail Engineering, Testing, Construction, etc. in EnglishLanguage for Companys review/approval.

2. Wiring Diagrams.

3. Control Panel Layout and description.

4. System Architecture with communication addresses.

5. Detailed PLC Loop Diagrams.

6. Module Data Sheets.


3/42


7. Module Index.

8. GUI Screens in coloured hard copies.

9. I/O List.

10. Process Interlock Diagrams.

11. Inspection, testing reports.

12. Pre-Commissioning Procedures.

13. Commissioning Procedures.

14. As-Built Documentation/ Drawings (Hard copy & Electronic copy on KOCapproved software 2 copies).

15. Operation & Maintenance Manual.

16. Other relevant Drawings/Documents.

1.4 General System Principles

The proposed system is based on the following principles:

All of the data required for electric power network control and command

purposes is centralised via the a Redundant PLC controller with singularI/O system, redundant communication links, redundant servers and HMI ateach substation having their own redundant I/O racks located in the localbuildings under its command and subsequently connected via a redundantlink to the central servers.

The Human-machine interface uses PC and/or server based workstations.

Depending on the required response time, specific functions are run byHMI equipment or the PLCs.

The system components are linked by redundant communication networksusing standard protocols like TCP MODBUS. If necessary, interfaces canbe set up with other systems.

1.4.1 Level 2 and HMI

The HMI system

A station should typically consist of the concept set out below:


4/42


Communication server Profile: It handles the interface with sitedevices that communicate the database and a local HMI. There should be2 servers located in the central location working in redundant mode.In South Harbour Main server will be located in Craft Building andredundant server will be located in Engineering Building. Fibre optic link

will be provided between the two locations. In North Harbour Main Serverwill be located A Building and redundant server will be located inCraft Building. Fibre optic link will be provided between the two locations.Fibre optic link will be provided between the two locations.

Clientprofile: It handles general site control functions and the HMI. Itdoes not handle the acquisition of data from devices, but acquires data viaa station with a server profile.

"Engineer" profile: It offers maintenance functions (possible options:setting protection functions, disturbance recording, simulation for trainingpurposes and sequence management). Note these functions are onlyaccessible from a station with an "engineer" profile. The engineeringstation may be in a combination with a client profile.

Historical Data System (HDS) server profile: It manages the recordingof data inside an standard server database like SQL and a local HMI.Historical data of minimum one year should be available in the system atall times. This server may be in combination with the communicationserver profile.

1.4.2 Typical System

A server PC (DB hosting) and n number of clients (operator workstations).Server performs the communication server functions between the local HMIand control system. It is completed by one printer used for alarms/events logsand one printer for reports.Redundant ethernet switches with fiber optic ports.

A Local HMI station should be available at the 3 substations for localmonitoring only.

1.4.3 Communication Network

The link between the server PC and communicating control devices uses anEthernet TCP/IP network with redundant Fiber optic medium. The localoperator stations will connect using copper network.

The Substation Controller (PLC / Smart RTU) allows hardwired I/Os to beconnected and should also have option to connect smart field devices viaModbus, TCP/IP etc.


5/42


A redundant link between all servers, workstations and the SubstationController (PLC / Smart RTU) is implemented. If one of the networks fails theother one should still work.

1.5 Functional Description

This section briefly describes the functions to be provided by the proposedsystem.

1.5.1 Monitoring Functions

Supervision of current state of electric network (animated single linediagrams).

Alarms and status management (generated by devices connected to thesystem).

Accurate Time stamping Management which allows the operator todetermine the initial event that triggered a fault (Sequence Of Events).

Analogue measurement acquisition from devices connected to the system.

Analogue archiving for trend display purposes.

Electric power supply network control assistance functions:

Operator command management.

Operator access rights management.

Dynamic colour animation management in electrical links in the mimics.

Simulation mode and sequence editor.

Electric power distribution network maintenance functions: Maintenance data monitoring by device.

Tagging management by device.

IEDs protections management display and writing.

IEDs Disturbance recording download and display with analysis tool

Cost metering.

Managing power quality.

These functions should be available via a user friendly Human-MachineInterface which is suitable for electric power distribution needs.

1.6 Electrical Process Automation Functions

The following specific functions are required:

Fast Load Shedding in case of a power source or generator supply lost.This function includes also adjusting parameters from an operatorworkstation.

Automatic Transfer Switch to reduce the power break time affecting onehalf busbar when the other half busbar is still working.

Automatic/manual generator set start orders if the main generator trips.


6/42


Start permission after load shedding. This function stops the operatorfrom restarting a major power user until sufficient power is available.

Synchronism monitoring, to warn the operator when synchronism isachieved between two sources.

Manual synchronisation control to adjust the voltage or frequency toallow bus-ties to close.

Load regulator management (OLTC), automatic and manual modevoltage adjustment.

Homopolar generator management in order to prevent abnormalsituations (bus section without homopolar generator or bus section withseveral homopolar generators connected).

Load sharing, when several generators are operated in parallel, thepurpose of this function is to calculate set-points and to send them to thegenerator panels to prevent unbalance.

HV loop management, on a loop with an opening point. When a faultoccurs, this function can be used to locate the fault, isolate it and re-supplythe sections.

1.7 APPROVED MANUFACTURERS

1. Schneider Electric2. ABB3. Siemens4. As per approved KOC Vendor list or Equivalent.

2.0 PRODUCTS

2.1 Detailed Hardware Supply

This section describes the complete hardware and software supply.

2.1.1 Description of Level 1 Equipment

2.1.1.1 Hardware PLC

The number of extension boards installed should match the number ofinputs/outputs defined in ELECTRICAL SCHEDULE OF POINTS FORPOWER AUTOMATION SYSTEM and have 20% additional wired I/O and20% additional space free for future expansion.

The proposed system should be field proven and a reference list ofinstallations should be provided preferably in Kuwait. Spares and hardwaresupport for the system parts to be available for the next 10 years. A letterstating this from the manufacturer to be attached in the proposal. The MTBFand MTTR of the main PLC components to be also attached.

The control system should consist of two identical PLC racks the primaryand secondary racks. The primary shall execute the program and control the


7/42


I/O while the standby PLC shall stay in the background ready to execute theprogram in case of failure in the primary. The changeover shall happen incase of power failure, rack failure, communication failure etc in the primaryrack. The changeover shall be bumpless and transparent to the process.

The CPU should support Hot Redundancy functions built in to the systemfirmware. The redundancy should be achieved by using fiber opticsynchronization cables. Program changes in one CPU should update in theother CPU. On change over from one CPU to the other the same CPUaddress should be maintained in the redundant CPU.

The CPU should support high end IEC 61131-3 programming languages likeSFC or Grafcet . It should be possible to modify the program in RUN mode. A

PLC simulator should be built in with the programming software for testing ofloops offline. Integrated system diagnostics upto and including each I/Ochannel should be available in the software. The CPU should feature at leasttwo communication ports built-in. A status and diagnostic LCD displayproviding PLC status, communication parameters and system informationshould be available on the CPU for easy reference.

As a standard the CPU should store the application program in a batterybacked internal RAM. To protect the application program from inadvertentchanges during operation the processor should feature a key switch to protectthe memory.To protect the processor from being stopped from run mode a protection keyshould be provided to prevent accidental stoppage.

Minimum built in RAM of the CPU should be 1MB expandable up to 8MB ormore. All application data like comments should be stored in the CPUmemory. The CPU should be able to support a minimum of 31 remote I/Oracks using industry standard field bus communication.

The CPU and I/O modules shall be rack mounted. The power distributionbetween modules and control signals should be distributed through rack

backplane. No addressing switches should be required for any of themodules. All addressing will be through software.

All PLC hardware should be compliant to IEC 61131-2 as a minimum. Theoperating temperature of the hardware shall be 0-60C meeting that of IEC60068-2.

The main CPU rack shall consist of redundant power supplies having 230VACas their operating input. In case of failure a status bit should be available tomonitoring system as alarm.


8/42


Input/Output board characteristics:

Type ofboard

Max Number ofchannels

Channel characteristics Comments

Digital inputs 32 24 VDCDigitaloutputs

32 24 VDC 0.5 A2A relays wired in thecabinet

Ana. inputs 8 4-20 mA

Ana output 8 4-20 mA

Type ofboard

Polarity Type of contact Equipped reserve

Digital inputs 220VAC /24VDC 20%

Digitaloutputs

24VDC NO/NC 20%

Ana. inputs 4-20mA 20%

Ana output 4-20mA 20%

2.1.1.2 The Main Controller

Mounted in a control cabinet at each substation, main 100% redundant CPUrack, I/O rack comprising of inputs and outputs, redundant Modbus/Ethernetcommunication card, required redundant power supply.

Each sub building will have a remote I/O rack communicating with theredundant CPU in the corresponding substation building for it.

2.1.2 Description of Level 2 Equipment

2.1.2.1 Hardware

This part defines the precise characteristics of the PCs, printers and cabinetswhere the computer equipment is installed


9/42


Basic PC, each workstation has the following characteristics:

Equipment Characteristics

Operator Workstation

Type: HP/Compaq or Dell or equivalentPresentation: Mini-towerProcessor: Intel Core 2 Duo latest processorHard disk drive 1: >=180 GBRAM: >= 3GBDVD ROM >= x 8Communication ports: 1serial, 1 parallel, 2 USB, Ethernet, 1 ModbusDisplay: LCD 21" TFT, 3 PCI slots freeKeyboard: QwertyOperating system: MS Windows

ServerType: HP/Compaq or Dell or equivalentPresentation: Mini-towerProcessor: Intel Core 2 Duo latest processorHard disk drive 1: >=1 TBRAM: >= 3GBDVD Burner >= x 8Communication ports: 1serial, 1 parallel, 2 USB, Ethernet, 1 ModbusDisplay: LCD 19" TFT, 3 PCI slots freeKeyboard: QwertyOperating system: MS Windows

Events log printerType: Epson, Oki or equivalentCharacteristics: Black and white, dot matrix, 132 columns

Report printer

Type: HP LaserJet A4 size or equivalent

Ethernet

Industrial Ethernet Switches :10/100/1000 MBPS, 1610/100 ports, 8 fiber ports or as per requirementPatch Panels: RJ45 and fiber as required

Patch Chords: Factory crimped as required

Note: The characteristics set out above are the minimum required. Due to rapidlyimproving computer performance levels, the configuration supplied may havesuperior characteristics.


10/42


2.1.2.2 Software

Software Reference Quantity:

Windows OS XP PRO, Vista or latest 5

HMI license (Client) Run time version 5

HMI license Development version 1PLC/ RTU Software with Laptop Development version 1

Windows Server EditionMS Latest Server

Edition2

I/O Server, Historian, DatabaseLatest Edition as

required for the Server2


11/42


2.2 General SCADA Software Requirements

The SCADA software shall consist of a human machine interface (HMI)system with support for supervisory and process control, real-time dataacquisition, alarm and event management, historical data collection, report

generation, local or remote telemetry communications to PLC's/RTU's, andinternet/intranet access. The software shall be easy-to-use, with an object-oriented graphics development environment and shall have an openarchitecture, which utilizes the latest in Win2000/WinXP Professional andTablet /Win2003 Server client/server and peer to peer networking technologyfrom Microsoft. The system shall have the built-in flexibility to permit easyconfiguration of the system in accordance with the specific end userrequirements as well as quick and easy modification by the end user in thefield.

The software shall consist of a suite of off-the-shelf modular components from

a single software manufacturer that are tightly integrated together to performall SCADA system functions. The suite shall contain an HMI for processvisualization, Real-Time relational database for historical data collection, clienttools for trending and reporting within the HMI and as standalone andcommunication drivers for PLC/RTU's. It shall be scaleable so that a small,single, stand alone application can easily be expanded into a large distributedcontrol network with either single or redundant database servers, single orredundant communication servers providing information to multipleworkstation clients. The software shall also have the ability to easily interfacewith CMMS, LIMS and GIS systems.

2.3 Development Environment Software Requirements

This section describes the engineering database development requirementsof all system software functions in any combination as follows:

2.3.1 Multi-User Development Environment

The Development Environment shall provide a simultaneous, multi-user development environment, where users are subject to securitypermissions based on individual system-wide roles.

2.3.2 Object Model

The Development Environment shall utilize the concept of ApplicationObjects. These Objects may represent real world devices such as PIDloops, Motors, Pumps, Valves, etc, or informational objects such asexternal database readers and writers, XML readers and writers, etc.Application objects shall closely model the physical representation ofplant equipment and devices and not be bound to a tag-only topology.This shall include the ability to create complex, multi-variable datastructures.


12/42


2.3.3 Object and Code Re-UseThe Development Environment shall promote code re-use throughstandard templates, which may be customized to create new objectinstances, while still maintaining parent-child relationships of the object

definitions.

2.3.4 Object Repository

The Development Environment shall utilize a centralized repository fortemplates and application objects, object hierarchy, deploymentconfiguration, and genealogy.

The Development Environment shall allow users with configurationrights to view objects and ensure that only one person can check outfor change a specific template or application object at any one time.

The repository shall be used only for configuration and as such may bedisconnected from a running system without affecting the operation ofsaid system.

2.3.5 Object Templates

The Development Environment shall provide a mechanism to developObject Templates. These object templates shall be used to create theindividual instances of the objects that perform the SCADA tasks.Object Templates shall be able to contain other object templates in ahierarchical relationship. Objects shall contain general objectconfiguration, Input/Output definitions, internal attribute definitions,internal documentation for configuration help, user defined attributedefinitions, alarm definition, history definition, and contained scripts.

The Development Environment shall expose Base Templates providedby the software manufacturer. An Object Toolkit shall be available toallow user to create new base objects using Visual C++ and Visual C#.

The Object Template shall allow the configuration of historical datastorage without using a separate tool.

The Object Template shall allow configuration of a connection to analarm sub-system that supports condition-oriented alarms (LoLo, Lo,Hi, HiHi, Rate-of-Change Deviation, etc.), event-oriented alarms(True/False, Fail to Open, Fail to Close, Command Disagree, etc) withpre-defined tools that will step the developer through the process ofdefining the configuration.


13/42


2.3.6 Object Template Application Logic Scripts

Scripts contained by an Object Template shall utilize Microsoft .NET(dot NET) technology and compile to the .NET Common LanguageRuntime. The scripting shall be easy to program using English-likestatements and shall not require any knowledge of any other

programming logic. The user shall be able to edit or modify the logicscripts while the system is monitoring the process. The scriptinglanguage shall include selection boxes and pull-down menus to permitstatements to be created without having to type tag names or specificcommands. The software shall support basic commands andoperations such as IF, THEN, ELSE, ELSE IF, AND, OR, NOT, ADD,SUBTRACT, MULTIPLY, DIVIDE, EQUAL TO, NOT EQUAL TO,GREATER THAN, and LESS THAN. Additionally there shall be a fulllibrary of more complex math and system script functions available. Avalidate button shall be included to ensure proper syntax and provideindication of errors to eliminate any problems at runtime. On-line helpfor each script function shall include actual working examples that canbe copied and pasted into the script editor. Dot NET functions providedby Microsoft shall utilize documentation provided by Microsoft.

System logic shall support configuration of objects to automaticallyperform functions such as increase set points, perform totalization, andcheck the status of process parameters to take action appropriateaction.

System Logic shall support the configuration of objects to monitor the

status of each tagname/hiearchical name attribute in the system andperform specific functions based on the type and status of an alarmcondition.

System shall support the configuration of objects that performapplication control to change the state of discrete points, showwindows, download recipes, etc. This application logic shall also startand stop other application programs such as Excel, Word and otherapplications likeCrystal Reports.

The system shall be able to configure scripts to be executed when aninstantiated object starts up, when the instantiated object goes onscan, on a condition on true, while true, on false, and while false,periodically, when the instantiated object goes off scan, and when aninstantiated object shuts down.

2.3.7 Conditional Control and Data Change Logic

The system shall support the configuration of objects that performapplication control based upon a user definable state of an object andattribute or the result of an expression involving multiple object tagnames/hierarchical names; including discrete object tag

names/hierarchical names on/off state, alarm states such as lo, lo-lo,hi, hi-hi, or equivalence to a specific value. It shall be possible to


14/42


define Condition Logic scripts that execute once when the conditionexpression becomes true, once when the condition expressionbecomes false or while the condition is true or while the condition isfalse at a user definable rate of 50 milliseconds minimum, or when thevalue changes.

The Development Environment shall provide a communicationmanager of I/O Server Application Objects to provide remote serverinstallation, configuration activation, and operations, and extensiveprotocol diagnostic troubleshooting.

2.3.8 Template Derivation, Object Instantiation and Inheritance

New templates shall be derived from existing templates, base (suppliedby the software manufacturer) or user defined. A template shall inheritthe entire configuration of the parent object when generating a newtemplate instance. Templates may contain other templates in a

hierarchy. Templates may be derived from templates. Derivedtemplates shall maintain any hierarchy that the parent templatecontains.

The Development Environment shall be able to lock specific attributesto allow changes to the parent template to pass through to the newinstance and all children of the new instance.

2.3.9 Development Environment Views

The Development Environment shall have the ability to organize Object

Templates into user configurable Template Toolboxes.

The Development Environment shall have the ability to view andconfigure the application from a plant model perspective.

The Development Environment shall have the ability to view andconfigure the application from an Application Object deploymentperspective.

The Development Environment shall have the ability to view andconfigure objects showing the genealogy of the object from the object

back to its parent template(s) and back to the base object, no matterthe length of the parent to child relationship.

2.3.10 Import/Export Utility

The Development Environment shall include a utility to support importor export into a human readable file format such as .CSV (commaseparated file format) for editing in a spreadsheet application such asMicrosoft Excel. It shall be possible to instantiate templates andapplication objects from the .CSV load by only populating theappropriate columns in the spreadsheet that are required for theinstantiation/configuration of the desired objects.


15/42


2.3.11 Deployment of Application Objects

The Development Environment shall utilize the concept of deployment.Deployment shall be defined as the remote installation of anyApplication Object, its children, dependencies, and any other softwarerequired and bound by the Application Object for the Application Object

to successfully operate.

All instantiated Application Object components shall be configured anddeployed from the Development Environment to target workstationsand servers.

The Development Environment shall provide visual feedback as to thedeployed status of any Application Object.

The Development Environment shall provide visual feedback as to thestatus of any Application Object that has a change pending.

2.4 Security

The Development and Runtime Environments shall be capable of utilizingMicrosoft operating system security, for example Active Directory Domains, toallow users access to view, configure, or modify templates and ApplicationObjects.

The security system shall support an object based, hierarchical model. Thismodel shall allow for the creation of Security Groups that containConfiguration Database Application Objects. The model shall allow for the

creation of Operator Roles that can be assigned to Security Groups. OperatorRoles shall allow for the assignment of configuration database permissions,and for runtime operational permissions, and access to visualization of certainwindows. At a minimum, runtime operational permissions shall allow for:

The access or denial of the ability to acknowledge an alarm in the runtimeenvironment. The modification of configuration attributes which allows usersto configure the attributes value (for example, a PLC register that defines adiscrete input).

The modification of operational attributes which allows users with operational

permissions to do certain normal day-to-day tasks like changing set point,output and control mode for a PID object, or commanding a Device object. Toopen and view a process or application window.

The modification of tune attributes which allows users to tune the attribute inthe runtime environment. Examples of tuning are attributes that adjust alarmset points and PID sensitivity.Users assigned to Operator Roles shall inherit all parameters that wereassigned to the Role and Security Group.


16/42


Runtime changes to object values shall be subject to security authorization.Permissions that are configured using the Development Environment shall beautomatically checked at runtime for authorization including verification ofidentity and access permission related to the originator of the runtime changerequest.

Users shall log in before any change to any object attribute that has beenconstrained is allowed.

The runtime architecture shall conform to the object attribute security modeldefined in the configuration environment.

2.5 Audit Trail

The Development environment shall provide an audit trail of Check Out/CheckIn, and revision history for each template or application object that includesuser ID, time and date stamp, and a detailed summary of the changes made.

Any runtime changes to a variable so configured shall provide an audit trail ofuser ID, full user name, previous value, and new value. Attributes configuredfor Verification shall provide an audit trail of user ID, full user name, verifierusername and full user name, previous value, and new value.

2.6 Run-time Environment

This section describes the various user interface functions of the system inthe runtime mode in any combination as follows:

2.6.1 Alarm ManagementAlarms shall be detected and reported by an Alarm Manager service.The Alarm Manager service shall support no less than two hundred(200) simultaneous alarm client displays. In the event of an alarmstorm (hundreds or thousands of alarms detected within one second),the Alarm Manager shall report and the client shall be capable ofdisplaying up to one thousand (1000) new alarms within ten (10)seconds of the detection of the alarms.System shall be able to alarm system resources (CPU utilization,memory, etc).

Alarms shall be logged to a Microsoft SQL Server or MSDE (MicrosoftDatabase Engine). Alarm events to be recorded shall include alarminstantiation, alarm return-of-normal, and alarm acknowledgment.Items to be logged in addition to the alarm event shall include date andtime of alarm event, Alarm Group, Alarm Tag name, Alarm Tag Type(real/integer/Boolean), Alarm Type (LoLo, Lo, Hi, HiHi, ROC, Deviation,disc, etc), Operator Name and Operator Node of alarmacknowledgement, and Alarm Priority An Alarm Purge service shall beprovided to automatically purge and optionally archive alarms that areolder that a user defined period of days online.


17/42


Alarms may be printed to a locally connected or network printer. Thealarms printed from a particular node may be all alarms, onlyunacknowledged alarms, only acknowledged alarms, alarms from aparticular alarm group or groups, alarms from a particular priority to aparticular priority, or alarm from multiple alarm providers.

2.6.2 Communications ArchitectureThe run-time environment shall be based on distributed, peer-to-peersystem architecture. It shall be possible to scale the architecture from asingle, self-contained node, to over 500 nodes. The architecture shallcontain a multi-computer model that is seen as a single distributednamespace in the run-time environment and does not requirereplication of data from one node to another.

Application Objects and their attributes shall be accessible by theobjects Hierarchical Names, or globally unique Tag names.

The architecture shall allow for remote re-deployment of

communication application programs without manually re-installing software.

The Architecture shall allow for remote re-deployment ofapplication objects and associated programs without re-loadingsoftware

The architecture shall be based on a publish and subscribecommunications methodology versus poll-based to minimizenetwork traffic and to ensure portability of objects uponredeployment.

The architecture shall allow centralized administration and control

of the runtime state of the distributed system. The architecture shall operate in real-time and be able to handle

millisecond transaction and event speeds.

The architecture shall be able to monitor and respond to highvolumes of asynchronous data and event messages at a rate ofthousands of messages per second. It shall be capable ofsupporting one million (1,000,000) IO and five hundred (500)nodes

Application Objects shall have the ability to connect to any IOserver utilizing the protocols of DDE/NetDDE, Suitelink, and OPC.IO shall be defined as any input and/or output variable, including

individual data acquisition points and any variable parametergenerated for exchange between objects in the system. At aminimum, the data types that shall be supported are Boolean,Float, String, Internationalized String, Integer (8, 16, and 32 bit,signed and unsigned), Time, and Elapsed time

2.6.3 Runtime Data Viewer

The runtime environment shall provide a utility to view the real-timestatus of any Application Object Attribute.


18/42


2.6.4 SCADA System Failover

The SCADA system software shall provide redundancy for all functionswithin a normal SCADA controls environment. The specificcomponents that require redundancy within the SCADA system areApplication Object/Application Object Hosting, PLC/RTU

communications, alarm reporting, and logging of historical processdata. In redundant configuration, there shall be a Primary and aBackup system object that manages contained Primary and Backupobjects. The system shall execute active objects and synchronizeactive objects with standby objects. In the event of detection of anyfailure in active object execution or communication with the activeobject, standby objects shall begin executing and communicating withinthe system.

2.6.5 Defined Failure Events

The SCADA system shall detect the following events within the SCADAsystem and network objects:Communications failure to a single RTU/PLCCommunications failure to multiple RTU/PLC(s)Communications failure to Communications ServerApplication Logic FailureAlarm Printer Failure (Off-line, out of paper)Alarm Manager FailureData Historian rate of collection deviationLow Disk Space on any data historian on the network

The SCADA System shall detect any or all of the possible failures andallow client data recovery without operator intervention.

2.6.5.1 Application Redundancy

The system shall provide for the execution of standby applicationobjects that become active upon the failure of execution of activeobjects or failure to communicate with the active objects. Separateconfiguration of standby objects is not required. Objects are allocatedto a Primary object manager engine, which in turn insures thatcontained Backup objects are created and deployed as standby. Innormal operation, the Primary engine along with its contained objects

shall be active. The backup engine and contained objects shall be keptin standby and shall be synchronized with their active partners on auser configurable time base. Configuration of application redundancyshall be by configuration by check-box and drag-and-drop.

2.6.5.2 Alarm Redundancy

The system shall provide for the handling of alarms from standbyapplication objects that become active upon the failure of execution ofactive objects or failure to communicate with the active objects.Separate configuration of alarms in standby objects is not required. Aswith application redundancy, objects are allocated to a Primarymanager object that in turn insures that contained standby objects arecreated and deployed as standby for handling of alarms.


19/42


2.6.5.3 Communications Redundancy

The SCADA System shall monitor the status of communications to theCommunications Server(s) and the status of the CommunicationsServer to each PLC/RTU. In the event of a communications failure theSCADA System shall transfer communications responsibility to a

designated standby communications server.

2.6.5.4 Data Historian Redundancy

The system shall provide for historization of data values from activeobjects. Upon the failure of execution of active primary objects, standbyobjects shall be activated and assumed the task of providing data forhistorization. Separate configuration of historization for standby objectsshall not be required. If the Historian is off-line or unreachable, theengines servicing active objects shall store the historized data locally,and forward the buffered data to the Historian when the historian serveris available. Primary and standby object engines shall synchronize anybuffered historization data. If the Historian is off-line or unreachableand the primary object engine fails, the failover engine shall assumethat task of storing the historized data locally, and forward the buffereddata to the Historian when the historian server is available. There shallbe no practical limit, other than disk space, as to the size of thehistorized data stored locally.

2.6.5.5 Terminal Services Fail-Over

Terminal Services thin clients shall be capable of automatically failingover to a redundant terminal server. No operator intervention shall be

required. The system shall support execution of the visualizationsoftware and the engineering development tools in Terminal Servicessessions while enforcing the configured operating system securitymodel.

2.7 RTU/PLC and DCS Communications Server

The SCADA system shall include broad range of communications servers forestablishing the I/O interface between field devices such as RTUs, PLC's,DCS systems and the data historian.

2.8 General Purpose I/O Communications Servers

General-purpose communication I/O servers shall be available for all majorPLCs from Allen Bradley, GE, Modicon, Siemens etc, plus various RTUs andDCS systems. The PLC communication servers shall support interfaces viadirect serial, local control network such as data highway plus and ModbusPlus or via TCP/IP Ethernet. There shall be support for several hundredvarious devices utilizing the protocols of DDE, Suitelink, and OPC. An I/Oserver toolkit shall be available for third parties to develop custom I/O servers.

2.9 Multi-Protocol Communications Gateway Server

A utility shall exist to translate DDE, Suitelink, and OPC to DDE, Suitelink, and

OPC protocol to support legacy or third-party servers. The gateway shall allowan in-process DDE conversation on one computer to be seen as OPC on


20/42


another computer without the use of NetDDE or DCOM as a transport. Thisutility shall operate under Windows NT4, Windows 2000 Workstation orServer, Windows XP Professional or XP Tablet, or Server2003.

2.10 Full Function Operator Workstation (HMI)

The SCADA system operator shall be able to execute all monitoring andsupervisory control functions from this workstation. Typical operatorcommands include modifying set points for control loops, alarmacknowledgment and set point adjustment, auto/manual switching and on/offcontrol of field devices and taking points or devices on/off scan. The operatorshall be able to access all SCADA tag name/hierarchical names or graphicdisplays from any workstation on the network without knowing which datahistorian or server the point or display resides on. The system software shallinclude an object-oriented color graphics display generator with full animationcapabilities to provide users with a realistic visualization of the systemprocess. All graphical editing operations shall be point-and-click; selectingicons from a floating and docking tool bars, pull down menus or keyboardcommands. It shall be possible to perform a functional test of any graphicdisplay by switching to the runtime mode with a single mouse click. Thegraphics editor shall include a broad library of complex objects and processsymbols such as meters, pushbuttons, sliders, gauges, pumps, motors, tanks,valves, trends, alarms, and controller faceplates. All complex objects shall bescaleable to any size and may include animation links to provide dynamicresponse based on real-time data or user action. This workstation shall utilizethe Win2000 Workstation /Server, WinXP Professional/XP Tablet, orServer2003 operating system.

2.11 Runtime User Interface (HMI) Software Requirements

The software shall be licensed to support any of the following operatingsystems on appropriate hardware in any combination as follows:Server, workstation or desktop PC running Microsoft Windows 2000Workstation or Server, Windows XP Pro/XP Tablet, or Windows 2003 Server.Thin client, with diskless PCs running sessions served by Microsoft Windows2000/2003 Terminal Server.Hand held devices running Windows CE or Embedded XP.

2.12 Display Navigation

Operators shall interface to all process and SCADA activities througheasily recognized icons, pull down or full screen menus.

The system runtime software shall support operator access to multipledisplays at one time, including split screens where the operator may viewmore than one process area at a time. In addition, the system shallsupport unlimited use of pop-up displays for additional help or diagnosticinformation.

The system runtime software shall support multiple CRT monitorsthrough the use of commercially available multiple monitor cards.

The operator shall be able to have access to context sensitive on-line

help or instructions from any display at any time during operation of thesystem with a single keystroke or mouse click.


21/42


The operator shall be able to access displays via a pointing deviceand/or soft key menus with a choice of function keys, cursor control keys,or any single key on the keyboard. Display navigation shall not normallyrequire the use of typing text commands into an alphanumeric keyboard.Supported pointing devices shall include a mouse, touch screen, light

pen, or trackball. The operator shall be able to easily identify which objects are selectable

from any display by simply dragging the pointing device over the object.Displaying a halo around the object shall provide confirmation that anobject can be selected. Typical objects include process device symbols(pumps, motors, etc.) controller faceplates, buttons or switches orsliders.

2.13 Operator Security

The Operator Workstation shall utilize the security model defined by theconfiguration database.The software shall utilize data level security where the ability to modify a setpoint or other value is determined in the configuration database. Any changesto the data level security model shall be seen by all operator stations withoutany modifications to the operator stations.The security system shall be capable of disabling access to all MicrosoftWindows controls (file menu, close, minimize, etc.) and keyboard commands(Ctrl-ESC, Alt-Tab, and Ctrl-Alt-Del).

2.14 Windows Service Support

The operator interface workstation shall be able to be run as a Microsoft

Windows service. This provides windows service capabilities for key HMIcomponents such as historical logging, alarms and I/O communications. Theservice capabilities allow continuous operation through operating systemlogons and logoffs such as operator shift changes.

All SCADA software shall support running as a windows service so thatfollowing a power failure or when the machine is turned on, an automaticstart-up to the runtime mode will occur. This function assures unmannedstation start-up without compromising operating system security.

2.15 Logging Operator Actions

All operator actions shall be logged to an event logger. The event logger shallkeep track of each new operator log-on, log-off, set point change, or devicecontrol.

Each event log shall record the date, time, operator logged in and the type ofaction taken (set point change, state change, etc.).Value Change Event Logging

Any configured Integer, Real, discrete, or String tag may also be configuredas an event. The point shall be logged as an event any time its valuechanges.


22/42


Events shall be logged to a Microsoft SQL Server or MSDE (MicrosoftDatabase Engine). Items to be logged in addition to the event itself shallinclude date and time of the event, and Event Priority.

2.16 Alarm Management Functions

The operator shall be able to view current and historical alarm informationfrom a full screen alarm-summary display or on a small scrolling region andthe bottom of any display. The alarm information shall be displayed inchronological order with the most recent alarm at the top. The informationcapable of being displayed for each alarm shall include the time and date,description, tag name, alarm state, alarm type (lo, lo-lo, hi, hi-hi, rate-of-change, etc.), value, acknowledging operator , acknowledging node prioritylevel, alarm or process area group name, and class.

It shall be possible for the operator to filter the alarm display based on prioritylevel, alarm groups or process area. In distributed network systems, alarms

shall be viewed and acknowledged from any workstation and the informationshall be distributed to all clients. The name of the operator and the nodeacknowledging the alarm shall be capable of being displayed in the AlarmSummary

It shall be possible to configure the system such that the operator is notified ofan alarm no matter which display the operator is currently viewing.Notification shall include the option of a pop-up alarm display window, aflashing process symbol such as a process vessel, an alarm text messagethat is available on each display, or a dedicated alarm display windowanywhere on the screen. A configurable audible signal shall be provided.

The alarm summary display shall provide the built-in horizontal and verticalscroll bars to page through alarms. The display of these scroll bars shall beuser-configurable.

The alarm summary display shall allow for dynamic re-sizing at runtime of thecolumn widths simply by selecting a column line and dragging it to set thecolumn width.

The alarm display shall support up to eight different combinations of colors

based on the priority of the alarm and whether it is acknowledged orunacknowledged. The colors shall be user-selectable via configuration from atotal of 256 colors.

The system shall provide a method of notifying the user when a new alarmhas occurred. The alarm display object shall automatically scroll to a newalarm when the user has scrolled down the alarm list from the top.

The alarm display shall retrieve alarm information by submitting an alarmquery to the alarm server. The alarm query shall allow specifying a priorityrange, alarm acknowledge state, alarm group, alarm history or summary.

Combinations of the parameters can be specified for the query to produceselected results.


23/42


The operator shall be able to create new alarm queries, at runtime, and savethe queries for re-use.

The operator shall be able to select and acknowledge alarms individually, by

group or process area. The operator shall also be able to acknowledge onlythose alarms visible in the display, only those selected, only the most recentalarm or all alarms in the system. The alarm display shall allow alarms to beselected by clicking on them with the mouse at runtime.

The operator shall be able to suppress alarms on the local display.Suppressing alarms on one operator interface shall not affect the display ofalarms on another operator interface. Un-suppressing previously suppressedalarms shall be via simple mouse click.The operator shall be able to select an alarm from the alarm summary displayand the system shall switch to the corresponding screen as to the particular

section of the control system where the alarm originated.

It shall be possible to inform the operator of an alarm condition via an audibletone, a pop-up display, or any combination of animation types on the screen.

Power System Automation server should transfer all the alarm generated tothe Facility Management server.

2.17 Thin Client Operator Workstation

The SCADA system operator shall be able to execute all monitoring andsupervisory control functions from a thin client workstation or environment. NoSCADA HMI software shall be required to be installed on a Thin ClientOperator Workstation. This workstation shall require only the firmware orsoftware required to initiate a Windows 2000 or 2003 Terminal Servicessession. The SCADA HMI shall support Windows 2000 or 2003Server/Advanced Server/Data enter Server with Terminal Services enabled inApplication Server Mode utilizing native Remote Desktop Protocol (RDP), orCitrix Metaframe utilizing Independent Computing Architecture (ICA) protocol.The SCADA HMI shall support up to twenty-five (25) sessions of the HMIsoftware running on a single Terminal Server.No modifications to the SCADA HMI configuration shall be required to allow

running in a thin client configuration. The exact same application running on aFull Function Operator Workstation (thick client) shall run in a Windows2000or 2003 server terminal services session (Thin Client).The thin client shall run as its host operating system Win3.1, Win95, Win98,WinME, WinNT3.51, WinNT4.0, Win2000, WinXP, Embedded XP, WinCE, orLinux.The SCADA HMI shall support Microsoft Terminal Services Advanced Clientrunning in Microsoft Internet Explorer.


24/42


2.18 Process Data Analysis Workstation

The SCADA system software shall include a set of easy-to-use client softwaretools for real-time and historical data analysis and system reports. This clientanalysis software may be used by engineering, maintenance or supervisorypersonnel who need information from the SCADA system but do not require

access to graphic displays. The client tools shall be able to access data frommultiple data historians on the SCADA system network. Users shall berequired to log in with a password to access the database server. The usershall not have to know the location of the server on the network, only thename of the server. The data analysis software shall include tools foradvanced trending analysis, X-Y plotting of tag names, and viewing of reportsin spreadsheet or free form format. All tools shall support full right mouse-click capability for quick menu selection of available functions. The clienttools shall be available as a stand-alone program or as an ActiveX control forimbedding into the SCADA so that any full function or view only operatorworkstation may have the same capability, or any user interface that supportsActiveX.

2.19 Real-Time and Historical Trend Analysis Tool

A client tool shall be included that allows users to view any or all of the tagnames in either a trend chart or tabular format. The client tool shall have auser interface that allows for easy selection of tag names using a WindowsExplorer-like browser with a search filter to quickly find tag names in a datahistorian with thousands of points. The user shall be able to create folders forselected groups of tag names and plot them individually or in groups bydragging them into the trend area. The user shall be able to save trend files

for recall at a later time. It shall be possible for the user to switch from thereal time to the historical viewing mode using a simple check box. The usershall be able to toggle from viewing trends either in the superimposed or thestacked mode. In the superimposed mode, all trends overlap and are in asingle scale range based on the largest vertical scale range in the group. Inthe stacked mode, each trend has its own vertical scale range. Trend plotsshall automatically be scaled based on the widest vertical range of the tagname or optimized based on the maximum and minimum range within theselected time period.

2.19.1 Real-time Trend Viewing

The user shall be able to trend up to 256 different tag names in realtime including analog, discrete, string or event tag names within thesame trend. The user shall pick tag names from the browser. Thetime span and vertical range of the trend shall be user configurableat run time. Standard time spans shall be configured for the last 5,10, 30 or 60 minutes or the last 2, 4 or 8 hours. The user shall beable to adjust the range of the tag names in run time.

2.19.2 Historical Trend Viewing

The user shall be able to plot historical data for any tag name orgroups of tag names in the database based any user-selected startand stop time. Two hairline cursors may be turned on and draggedacross the trend area to provide the user with the exact value for


25/42


each trended tag name at the point of intersection. The time spanand the value between the cursors shall also be displayed. It shallbe possible to overlay data from different start/end times tocompare the performance of equipment / compare the process fordifferent time intervals. It shall be possible to overlay live trends

onto history traces to compare performance. The trend tool shalldisplay statistical data for each trended analog tag name within thetime period selected. Statistical values shall include the minimum,maximum, average, and standard deviation. Icons or menu pulldown commands shall be available for analyzing the data such ashorizontal, vertical or rubber band zooming pan left or right andzoom between the hairline cursors. It shall also be possible for theuser to create text annotations anywhere on the trend. Theseannotations shall be visible from other workstations on the networkwith the same trend tool. It shall be possible to export the data inthe trend area into a CSV file. Printing of the trends with all

statistical data shall be supported.

2.19.3 ActiveX Tools

The data analysis software shall provide ActiveX objects for theTrend and Query clients so that they may be imbedded into SCADAHMI or any other ActiveX container. A query client shall beincluded to allow the user to execute SQL queries that returns aresult set from any SQL server database into a tabular data grid.The query ActiveX tool shall support multiple data server sourcesfor simultaneous display of the data. An ActiveX trend object shallalso be provided and support the same functions such that anoperator trained on one tool is trained on the other tool.

2.19.4 HTML Reporting Client Tool

A client tool shall be included that allows users to generate reportson any tag names. The client tool shall have a user interface thatallows selection of tag names and previously created reports andreport formats. The report tool shall allow you to set up, modify,and generate reports that present report data professionally andreliably. Types of information supported shall include historical andcurrent data values, tag name configuration information, graphs,

statistics, annotations, event and summary information and resultsfrom a query. Reports shall be generated based on data storedover a specified time period in minutes, or hours, days, weeks ormonths. It shall also be possible to generate reports on demand bythe user at runtime. Finished reports shall be formatted in HTML sothat they can be viewed with a Web Browser, stored on the serverdisk or sent to a printer.

2.19.5 Excel Reporting Tool

The data analysis software shall be included that allows users toeasily select tag names and historical values from the real time or

historical database via a browser and then utilize them in astandard Microsoft Excel spreadsheet for reporting or presentation


26/42


to management. The selection of tag names shall be accomplishedby use of drag and drop or point and click commands. It shall notbe required to write any macros to retrieve the data. The tag valuesselected can be output to specific cells in the spreadsheet andprocessed as number data types. The user shall be able to select

historical data for the most recent values or go back and select anystart or stop time as far back as the data is available. The historicaldata can be recalled at the granularity that it was stored or in aselected number of data points over a period of time. The usershall be able to retrieve raw historical data or summarized datasuch as the minimum, maximum or average over a predeterminedtime period. Updates to the current values once they are in thespreadsheet shall be refreshed with a single click of the mouse.The quality of the data shall be analyzed and displayed. The usershall be able to select if poor quality data is to be displayed orreplaced with an interpolated value. The user shall be able to

specify relative or absolute value choices.

2.19.6 Word Reporting Tools

The data analysis software shall be included that allows users toeasily select tag names from the real time or historical database viaa browser and then utilize them in a standard Microsoft Worddocument for reporting. The selection of tag names shall beaccomplished by use of drag and drop or point and clickcommands. It shall not be required to write any macros to retrievethe data. The tag names selected can be output to specific valuesor arrays using standard Word tables. The user shall have thechoice of selecting real time, absolute, relative or configurable basedates and times. The user shall be able to retrieve raw historicaldata, summarized data such as the minimum, maximum or averageover a predetermined time period or data stored in the historianevent system. The user shall be able to select if poor quality data isto be displayed or replaced with an interpolated value.

2.20 View-only Graphics Display Workstation

The SCADA system software shall support view-only graphics workstationsfor managers or supervisory personnel who wish to have access to all

displays and trends but do not have process control or alarmacknowledgement responsibilities. No modifications to the SCADA HMIconfiguration shall be required for this functionality. The view only graphicsdisplay HMI shall be capable of running in a terminal services session.

2.21 HMI Development Software Requirements

This section describes the engineering development requirements of allSCADA system software functions. This includes development of colorgraphic displays, configuration of the real-time and historical database,alarms, I/O communications to field devices and application setup of clientsand servers on the SCADA network. All development and configuration shallbe persisted in one or more common file or database repositories that providesingle point of configuration. Furthermore, there shall be a common naming


27/42


convention for objects and tag names that is enforced by the developmenttools. The software shall be licensed to support any of the following operatingsystems on appropriate hardware in any combination as follows: Windows2000 Workstation or Server, Windows XP Pro/XP Tablet, or Windows 2003Server, Thin client, with diskless PCs running sessions served by Microsoft

Windows 2000/2003 Terminal Server.

2.22 Graphics Display Development

The SCADA system software shall include an object-oriented color graphicsdisplay generator with full animation capabilities to provide users with arealistic visualization of the SCADA system process. All graphical editingoperations shall be point and click selecting icons from a floating and dockingtool bars, pull down menus or keyboard commands. It shall be possible toperform a functional test of any graphic display by switching to the runtimemode with a single mouse click. The development environment shall becapable of running in a Terminal Services Session. The display editor shall

include the following tools for display drawing, linking and animation.

2.23 Graphical Objects

The graphics editor shall include a set of basic drawing tools to create simpleor complex objects. Selecting an icon on the drawing toolbar shall easilycreate simple objects, which include lines, rectangles, polygons, ellipses,circles, and filled shapes or text. Any of these objects can be assigned variousattributes such as line color, fill color, size, and orientation and can be madestatic or dynamic. Text objects shall be scaleable and use true fonts in bolditalic or underline. All objects shall be scaleable and moved in any direction

one pixel at a time or dragged with a mouse.

The graphics editor shall support standard object manipulation functions suchas cut, copy, paste and delete. Alignment tools shall be included to simplifyproper placement and arrangement of objects. Align commands shall beincluded to align objects based on justification to the left, right, center, top orbottom. Object commands shall also be included to space them vertically,horizontally, move to back, move to front, rotate or group and ungroup.

The graphics editor shall include a broad library of complex objects andprocess symbols such as meters, pushbuttons, sliders, gauges, pumps,

motors, tanks, valves, trends, alarms, controller faceplates and bitmaps. Allcomplex objects shall be scaleable to any size and may include animationlinks to provide dynamic response based on real time data or user action

2.24 Object Animation

Objects shall be animated based on the following attributes:

Color change of the object. Up to 256 colors, 128 standard colors and up to128 user-defined colors. A user defined color palette can be created,exported and imported. The color palette shall be based on 16.7 millioncolors. System must also support the user choosing transparent colors for all

graphical objects and backgrounds.


28/42


Percentage of fill for objects up, down, left or right direction based on a tagname/hierarchical Name.

An object may blink based upon any Boolean expression, alarm, event, orupon a designated group of alarms. The blink shall be adjustable to slow,

medium or fast.

Each object shall have a visibility attribute option allowing for visibility of theobject based upon the status of a discrete point, alarm, or operator securitylevel.

The system shall support animation of objects via re-sizing, moving, and/orrotating based upon a change in a tag name/hierarchical name

Objects shall be animated based upon any user-defined criteria made up oftag names in the system. This includes the use of expressions containing

mathematical functions and the status of analog and discrete values in thesystem

Graphics Editor shall allow layering of objects to activate specific objectsbased upon conditions in the process.

Graphics development tools shall allow object placement via a snap-to-gridfeature with configurable grid spacing.

Graphics development tools shall support an undo/redo feature with aconfigurable number of levels and command displays.

The system shall support a library of self configuring objects that changeproperties based on dialog box entries made during development. Forexample, consider a standard set point loader object that has a graduatedscale and a default range of 0 to 100.0. Dialog box entries shall allowchanges to the range of the set point loader, the number of major and minordivisions on the scale, and change the text font used for the labels. Theobject shall then redraw itself with new number of tick marks, new spacing,new labels, and new font.

The system shall support the import of .DXF files with the drawing elementsimported as native objects. It shall be possible to animate these objects usingthe full set of object animation properties as specified in earlier sections

Graphics editor shall also allow the user to import drawings and images inBMP, JPEG, PCX and TGA file format.

The graphics development environment shall support the copy of single ormultiple animated graphic objects and symbols with just two keystrokes, andimmediate substitution of tag names for the duplicated object shall be possiblewithout leaving the graphics editor.


29/42


The graphics development environment shall support the copy of single ormultiple animated graphic objects and symbols from one window or display toanother retaining all of the animation characteristics, links and attributes. Thisfunction will eliminate duplication of effort.In addition it shall be possible to import windows from another application in

this same fashion.

User shall have the capability to add tag name/hierarchical name entries whilebuilding a display without exiting the graphics editor.

On-line context sensitive help shall support display building. Users shall beable to obtain immediate help on all configuration subjects by pressing asingle function key.

The user shall be able to define graphic screens while the system ismonitoring the process

2.25 Compound Symbols

Using a Compound Symbol Manager, application developers shall be able tocreate groups of symbols that then comprise a single named CompoundSymbol that may be expressed as a named Template. There shall be nopractical limit to the number of graphic symbols that can comprise a singleCompound Symbol, up to, and including an entire window of symbols. Thesetemplates shall connect either to Object Database objects, to local HMI tagsor to HMI tags through remote references. Changes to the Compound SymbolTemplate shall propagate to all instances of the template. Libraries of re-usable Compound Symbols may be created and managed by the SymbolManager.

The Symbol Manager shall allow for the creation and deletion of a hierarchicaltree of folders. Compound Symbols may be moved between folders via drag-and-drop.

The Symbol Manager shall allow for the import and export of CompoundSymbols.

The Symbol Manager shall allow for the renaming of Compound

Symbols/Templates.

A Compound Symbol shall be instantiated in the HMI window by selecting thesymbol in the Symbol Manager and selecting OK. The selected CompoundSymbol shall invoke a dialog to allow for browsing and selecting new tags orattributes from the Object or Tag Database, and to allow for creating entirenew named objects in the object database. The Symbol may then be resizedby dragging the corner of the symbol to the desired size.

The Symbol Manager shall allow for the editing of a Compound Symbol. Atthe completion of the editing process a dialog shall be displayed that allows

the changes to be committed, aborted, or return to editing. The Dialog shallalso display all of the windows that contain children of the Compound Symbol


30/42


Template. Committing the edit shall propagate all changes to the CompoundSymbol to all children of the Compound Symbol Template.Breaking the Compound Symbol shall break the inheritance chain with theCompound Symbol Template. The broken Compound Symbol can then be re-made as a new Compound Symbol Template that starts a new inheritance

chain.

The tags/objects attributes of a Compound Symbol may be changed or re-directed to an alternate set of tags/object attributes at runtime via a singlescript command.

2.26 Alarm Summary/Alarm History Object

Alarms shall be displayed by configuring a user-defined alarm summaryobject, which may be placed by itself or along with other objects in a window.The object can be sized and then double-clicked to launch a configurationdialog. Default alarm object configurations shall be displayed with the option

of changing any configuration parameter for runtime viewing. The alarm objectconfiguration shall include parameters with check boxes to select and enableor disable how the alarms appear at runtime. Alarms shall be color codedaccording to the state and priority of the alarm including an acknowledgedalarm, unacknowledged alarm, and an alarm that has returned to normal butis not yet acknowledged. The user shall be able to choose from 256 differentcolors for display of each of these alarm states. The alarm display object shallalso support event display, with the color used for events also being one ofthe 256 different colors.

2.27 ActiveX Support

The SCADA software shall provide extensibility by providing integratedsupport for OLE Controls (OCXs) technology. The SCADA software shall bean ActiveX container supporting methods, properties and events of ActiveXobjects. The support of ActiveX technology shall provide applicationdevelopers immediate access to hundreds of OCXs developed by dozens ofIndependent Software Developers. Registering an OCXs for use within anapplication system shall be an automatic process. Registered OCXs shall bedisplayed in a dialog box for adding/removing OCXs to/from the application.OCXs added to the application shall be contained within a dialog box to bequickly added to new and/or existing applications. At design time, the user is

focused on selecting an OCX for placement, mapping OCX properties, eventsand methods to tag names and writing logic to control OCX behaviour viaOCX properties and methods.

2.28 MI Application Manager

Each application shall include an application manager with a WindowsExplorer-like browser to simplify management of windows (displays), scripts,tag names, alarms and application documentation. A tag name cross-referencing index shall provide and efficient means identifying where all tagnames, links and objects are used throughout all windows in the application.The application manager shall provide the capability to dynamically change

the resolution of the application windows. This will allow graphic displays to be


31/42


developed on workstations with different display resolutions and convert themto the desired resolution quickly so that they are all consistent in look and feel.

2.29 Distributed Network Application Management

The SCADA software shall provide standard functionality that will simplify the

configuration, operation, troubleshooting and maintenance of the applicationby providing means of distributing the application in network environments.The Distributed Network Application (DNA) management software shalladhere to client-server architecture while allowing a single master applicationto be developed and maintained on the network. The DNA manager shallautomatically distribute the master application to all nodes on the SCADAcontrol network.

a) Application Locations

Master applications shall be maintained on a server that each client nodecan access, which provides ease of maintenance and unrestrictedediting. The DNA manager will allow client nodes to access theapplication from the server and it will distribute the server application to auser-defined location that each client node may specify. This approachinherently provides the client-based advantage of redundancy.

b) Notification of Application Changes to Client

When a client node loads an application from the network server, theclient shall maintain a copy of the application on its local hard drive andbecome registered as a user of that application. When a change to theserver application is detected, each registered user node shall be notified

of the change. The DNA manager shall allow the user to define how theclient node is notified of the change in the application. The client nodeshall either automatically load the new application, prompt the user toload changes or ignore, or automatically ignore such changes. If anetwork failure occurs between the server and client, then the client shallcontinue to run the last distributed application. When the network isrestored and the server application has changed, the DNA manager willdistribute the server application to the client.

1. Application Log Files

Application log files shall reside on the local hard drive for a user-

defined number of days. Each network node shall maintain anindependent log file for the applications that are unique to each node. Anew log file will be created and archived daily according to the userspecified time and location. The viewer shall support color distinctionsfor different threads, processes or programs. The log file viewer shallsupport viewing remote node application log files.

2. HMI Application Control Logic

The SCADA system software shall include a scripting language thatallows execution of commands and mathematical and logicaloperations based on specified system conditions or user actions. The

scripting shall be easy to program using English-like statements andshall not require any knowledge of any other programming logic. The


32/42


user shall be able to edit or modify the logic scripts while the system ismonitoring the process. Furthermore, it shall not be necessary toinvoke any other application to compile the changes. The scriptinglanguage shall include selection boxes and pull-down menus to permitstatements to be created without having to type tag names or specific

commands. Buttons shall be available for easy selection of basiccommands and operations such as IF, THEN, ELSE, ELSE IF, AND,OR, NOT, ADD, SUBTRACT, MULTIPLY, DIVIDE, EQUAL TO, NOTEQUAL TO, GREATER THAN, and LESS THAN. Additionally thereshall be a full library of more complex math and system script functionsavailable. A validate button shall be included to ensure proper syntaxand provide indication of errors to eliminate any problems at runtime.On-line help for each script function shall include actual workingexamples that can be copied and pasted into the script editor.

3. HMI Application Logic Scripts

The system shall have the ability to execute user defined logic scripts.Logic scripts shall be created in a statement based programmingenvironment. No compilers or linkers shall be required.The system logic shall be able to automatically perform functions suchas increase set points, perform totalization, and check the status ofprocess set points to take action.The system Logic shall be able to monitor the status of each tag namein the system and perform specific functions based on the type andstatus of an alarm condition. Alarm type may be lo, lo-lo, hi, hi-hi,deviation or rate of change. Alarm status may be acknowledged orunacknowledged.The system shall have the capability to perform application control toturn on/off discrete points, show windows, download recipes, etc. Thisapplication logic shall also start and stop other application programssuch as Excel, Word and other applications like Crystal Reports.The system shall have the ability to execute user definable logic on theparameters of On Application Start-up, While Application Running andOn Application Shutdown.

4. HMI Conditional Control Logic

System shall have the capability to perform application control based

upon a user definable state of a tag name or the result of anexpression involving multiple tag names; including discrete tag nameon/off state, alarm states such as lo, lo-lo, hi, hi-hi, or equivalence to aspecific value. It shall be possible to define Condition Logic scripts thatexecute once when the condition expression becomes true, once whenthe condition expression becomes false, while the condition is true, orwhile the condition is false at a user definable rate of 50 millisecondsminimum.

5. HMI Keyboard Control Logic

System shall have the capability to perform application control

whenever a user presses a key on the keyboard. This includeswhenever the key is pressed, released, or while the key is held down at


33/42


a definable interval. The system will support any of the keys on astandard PC-compatible keyboard.

6. HMI Data Change and Window Logic

System shall have the ability to execute System Logic when the value

of a tag name changes. System shall have the ability to execute aWindow Logic script upon a user definable state of a tag name or theresult of an expression.

7. HMI Function Logic

The system shall support creating of logic blocks and saving the logicas a function. These function scripts shall be capable of running on aprocess thread independent of the HMI process. Function scripts shallrun on a separate process thread and not impact the performance ofthe HMI operations. Function scripts shall be able to be called from anyof the logic types defined in earlier sections including a call from afunction script to another function script.

8. Data Historian

The SCADA system software shall provide a real-time relationaldatabase historian for long-term storage of process data. The DataHistorian shall provide for the storage of real-time and historical datafor each analog, discrete or string tag name. The data historian shallalso store summary, event, alarm and configuration data. Thedatabase engine for the historian shall be based on a full licensed copyof Microsoft SQL Server and supports client/server architecture. The

user shall not be required to know Microsoft SQL Server to install andimplement the historian. The data historian database shall acquire andstore process data at full resolution. The data historian database shallinclude normalized extension tables for real time data and include a setof client tools for data analysis and reporting such as those describedin earlier sections. The Data Historian shall be capable of running in astand-alone mode without connection to, or configuration from, theSCADA systemWhile there are always physical limiting factors such as disk space,there shall be no programmatic limit to the amount of data that may bestored on-line. Additionally, there shall be no performance penalty for

long-term data storage. There shall be no discernable difference inretrieval speed of data based on the age of the data. For example, theretrieval of two hours data stored two years prior shall be the same asfor two hours of data stored one day ago.

9. Data Compression

The database shall support high-speed data acquisition and efficientdata compression. The data compression for the data historian shallnot use any algorithms that do not allow for the storage of the tag dataat their scanned rate. The stored data records shall be able to recreatethe process data in a loss-less format. Below are the data storagetechniques to be employed for the various types of data.


34/42


10. Discrete Storage Requirements

Each discrete stored value written to the Data Historian shall useapproximately 7 bytes of space.

11. Delta Analog Storage Requirements

Each delta stored analog value written to the Data Historian shall useapproximately 10 bytes of space.

12. Cyclic Storage Requirements

Each Cyclic stored analog value written to the Data Historian shall useapproximately 10 bytes of space.

13. String Storage Requirements

Data shall be capable of storing string, or text, data. Each string maybe up to 512 characters in length. With each string value stored, a

quality field shall be stored as well.

14. Standardized Database Tables

The process of setting up the database tables shall be automaticallyconfigured and require no database engineering. Data definitionsincluding the creation of database objects, such as tables, indexes,constraints, defaults, rules, stored procedures, triggers, and views shallfollow a standard, published and readily available database schema.This standard database schema shall outline the relationship betweentables, table columns, keys and indexes and shall allow for third partydevelopment of client applications. Database device sizes shall be

dynamically allocated during database installation depending on thenumber of tag names to be stored within the data historian.

15. Single Configuration of Data Historization

The historization of data from SCADA objects shall be entered once atthe time of configuration of those objects using the correspondingobject editor in the SCADA System. The Data Historian shallautomatically acquire those configuration historization parameters upondeployment of the configured Application Objects

16. Historical Data Point Configuration

The data historian shall include a database editor to modify theparameters of any tag name without using the SCADA database editoras an option. It shall be possible to configure the data storage rate foreach point based on a user-defined rate frequency (cyclic storage) orupon change (delta storage). Cyclic storage rates shall be configurableper point from 1 second up to hours. The historian database shallsupport a 5-millisecond resolution for tag names configured with deltastorage.


35/42


17. Historian Data Acquisition and Retrieval

The data historian shall acquire data via automatic and manualmethods. Automatic data acquisition shall be through industry-standarddata transports. Data Acquisition via Dynamic Data Exchange (DDE)and OLE for Process Control (OPC), in addition to proprietary

transports, shall be supported. The method for retrieving data shall beStructured Query Language (SQL). It shall be possible to store data atone resolution and query at another. Methods shall exist to query andretrieve data cyclically, with millisecond resolution, no matter thestorage mode. It shall be possible to query and retrieve data in delta,with user selected dead-band criteria and millisecond resolution, nomatter the storage mode. It shall be possible to query and retrieveevenly spaced data over long periods of time where the criteria are arow count, no matter the storage mode.

18. Dynamic Configuration and Bump-less Data Initialization

The historian shall automatically begin to acquire tag data immediatelyafter a tag configuration has been committed to the database. Adding asingle or multiple tags to an existing historian database shall not affectthe data acquisition of previously defined tag names. Clientconnections will not be affected during reconfiguration due to dynamicconfiguration. Additionally, there will be no loss of data for tags wheredata acquisition configuration is not changed. Tags that require achange in data acquisition configuration will obviously lose data duringthe period of their re-initialization

19. Manual Data, Out-of-Sequence Data, and Superceded DataThe historian shall support Manual Data, Out-of-Sequence Data, andSuperceded Data. Manually entered data such as Lab Data and Out-of-Sequence Data such as batched history data from a RemoteTerminal Unit (RTU) shall be treated by the retrieval engine as if thedata were stored automatically. Any historized data may besuperceded by manually inserting the correct data value and a flagdenoting that the previous data has been superceded. The originaldata shall not and cannot be modified or destroyed. An SQL client toolmay request original data, superceded data, or both. Manual Data,Out-of-Sequence Data, and Superceded Data shall be inserted into the

Historian via an SQL Insert statement, or in bulk via Comma SeparatedVariable (CSV) file. Only users with proper login credentials shall beallowed to manually insert or modify data.

20. Data Quality

All stored data shall contain data quality attributes. The primary DataQuality attribute shall reflect Data Quality as defined in OLE forProcess Control (OPC). Additional quality attributes shall be used forinitial data (startup flag) and superceded data.


36/42


21. Event System Configuration

The data historian shall contain an event sub-system to monitor,record, and or respond to process or system events and to triggersome type of action when the event is detected. The event systemshall detect an event occurrence using pre-defined and configurable

criteria; historically log when an event occurs and trigger designatedconfigurable event actions based on the event detection. Eventattributes shall be logged to the database and will include the date,time that the event occurred, and the event criteria that were satisfied.

22. Event Configuration

Using a point and click approach, the system shall allow users tocreate/define event tag names and associate event tag names to eventdetectors and the resulting actions. The user shall be able to insert atime delay in milliseconds before the event action is triggered andestablish the priority of the event as normal or critical. It shall bepossible to detect an event based on scheduled time interval, a specificanalog value crossing a threshold or a discrete value going from 0 to 1(leading edge), 1 to 0 (trailing edge), or both. An event editor shall beprovided to support complex SQL event detectors and event actions.

23. Event action

The data historian event detectors shall determine that an event hasoccurred a