Power System Automation PDF

SECTION 16428 POWER SYSTEM AUTOMATION 1.
0 General
1.1 INTRODUCTION The system proposed to North and South Harbour KOC marine facilities is designed to handle the control command functions and visualisation for the Marine Facilities of the electric power distribution network for the North and South Harbour Power facility. All KOC standards and codes should be followed along with products from approved vendor list. The solution should be based on standard products easily available in the market having a proven track record in similar systems. The proposed system parts and support should be available for a minimum of 10 years. A List of current installations with a brief description and time of operation should be submitted. Standard communication systems are to be implemented (Modbus TCP/IP, RS 485). This ensures that system components from other vendors (electric generator units, un-interruptible power supplies) can be connected 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 at least 3 years warranty from date of delivery.
The solution should be easy to update due to a modular architecture. Adding software 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.
Small Boats Harbours Project
16428/1
Power System Automation
The system must be able to: 1.2 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 generator status 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
APPLICABLE CODES & STANDARDS The proposed system should follow the latest standards and certifications as a minimum or as mentioned in this documentation. 1. 2. 3. 4. 5. 6. 7. IEC BSA DIN ISA ISO UL CE
1.3
DOCUMENTATION 1. The Contractor shall generate/ furnish all related Documents/ Drawings, of Design, Detail Engineering, Testing, Construction, etc. in English Language for Companys review/approval. Wiring Diagrams. Control Panel Layout and description. System Architecture with communication addresses. Detailed PLC Loop Diagrams. Module Data Sheets.
2. 3. 4. 5. 6.
16428/2
7. 8. 9.
Module Index. GUI Screens in coloured hard copies. 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 KOC approved 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 singular I/O system, redundant communication links, redundant servers and HMI at each substation having their own redundant I/O racks located in the local buildings under its command and subsequently connected via a redundant link 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 by HMI equipment or the PLCs. The system components are linked by redundant communication networks using standard protocols like TCP MODBUS. If necessary, interfaces can be 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:
16428/3
Communication server Profile: It handles the interface with site devices that communicate the database and a local HMI. There should be 2 servers located in the central location working in redundant mode. In South Harbour Main server will be located in Craft Building and redundant server will be located in Engineering Building. Fibre optic link will be provided between the two locations. In North Harbour Main Server will be located A Building and redundant server will be located in Craft 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. It does not handle the acquisition of data from devices, but acquires data via a station with a server profile. "Engineer" profile: It offers maintenance functions (possible options: setting protection functions, disturbance recording, simulation for training purposes and sequence management). Note these functions are only accessible from a station with an "engineer" profile. The engineering station may be in a combination with a client profile. Historical Data System (HDS) server profile: It manages the recording of data inside an standard server database like SQL and a local HMI. Historical data of minimum one year should be available in the system at all times. This server may be in combination with the communication server 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 HMI and control system. It is completed by one printer used for alarms/events logs and one printer for reports. Redundant ethernet switches with fiber optic ports. A Local HMI station should be available at the 3 substations for local monitoring only. 1.4.3 Communication Network The link between the server PC and communicating control devices uses an Ethernet TCP/IP network with redundant Fiber optic medium. The local operator stations will connect using copper network. The Substation Controller (PLC / Smart RTU) allows hardwired I/Os to be connected and should also have option to connect smart field devices via Modbus, TCP/IP etc.
16428/4
A redundant link between all servers, workstations and the Substation Controller (PLC / Smart RTU) is implemented. If one of the networks fails the other one should still work. 1.5 Functional Description This section briefly describes the functions to be provided by the proposed system. 1.5.1 Monitoring Functions Supervision of current state of electric network (animated single line diagrams). Alarms and status management (generated by devices connected to the system). Accurate Time stamping Management which allows the operator to determine 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-Machine Interface 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 operator workstation. Automatic Transfer Switch to reduce the power break time affecting one half busbar when the other half busbar is still working. Automatic/manual generator set start orders if the main generator trips.
16428/5
Start permission after load shedding. This function stops the operator from restarting a major power user until sufficient power is available. Synchronism monitoring, to warn the operator when synchronism is achieved between two sources. Manual synchronisation control to adjust the voltage or frequency to allow bus-ties to close. Load regulator management (OLTC), automatic and manual mode voltage adjustment. Homopolar generator management in order to prevent abnormal situations (bus section without homopolar generator or bus section with several homopolar generators connected). Load sharing, when several generators are operated in parallel, the purpose of this function is to calculate set-points and to send them to the generator panels to prevent unbalance. HV loop management, on a loop with an opening point. When a fault occurs, this function can be used to locate the fault, isolate it and re-supply the sections.
1.7
APPROVED MANUFACTURERS 1. 2. 3.
4.
Schneider Electric ABB Siemens As per approved KOC Vendor list or Equivalent.
2.0 2.1
PRODUCTS 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 of inputs/outputs defined in ELECTRICAL SCHEDULE OF POINTS FOR POWER AUTOMATION SYSTEM and have 20% additional wired I/O and 20% additional space free for future expansion. The proposed system should be field proven and a reference list of installations should be provided preferably in Kuwait. Spares and hardware support for the system parts to be available for the next 10 years. A letter stating this from the manufacturer to be attached in the proposal. The MTBF and MTTR of the main PLC components to be also attached. The control system should consist of two identical PLC racks the primary and secondary racks. The primary shall execute the program and control the
16428/6
I/O while the standby PLC shall stay in the background ready to execute the program in case of failure in the primary. The changeover shall happen in case of power failure, rack failure, communication failure etc in the primary rack. The changeover shall be bumpless and transparent to the process.
The CPU should support Hot Redundancy functions built in to the system firmware. The redundancy should be achieved by using fiber optic synchronization cables. Program changes in one CPU should update in the other CPU. On change over from one CPU to the other the same CPU address should be maintained in the redundant CPU. The CPU should support high end IEC 61131-3 programming languages like SFC 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 of loops offline. Integrated system diagnostics upto and including each I/O channel should be available in the software. The CPU should feature at least two communication ports built-in. A status and diagnostic LCD display providing PLC status, communication parameters and system information should be available on the CPU for easy reference. As a standard the CPU should store the application program in a battery backed internal RAM. To protect the application program from inadvertent changes during operation the processor should feature a key switch to protect the memory. To protect the processor from being stopped from run mode a protection key should be provided to prevent accidental stoppage. Minimum built in RAM of the CPU should be 1MB expandable up to 8MB or more. All application data like comments should be stored in the CPU memory. The CPU should be able to support a minimum of 31 remote I/O racks using industry standard field bus communication. The CPU and I/O modules shall be rack mounted. The power distribution between modules and control signals should be distributed through rack backplane. No addressing switches should be required for any of the modules. All addressing will be through software. All PLC hardware should be compliant to IEC 61131-2 as a minimum. The operating temperature of the hardware shall be 0-60C meeting that of IEC 60068-2. The main CPU rack shall consist of redundant power supplies having 230VAC as their operating input. In case of failure a status bit should be available to monitoring system as alarm.
16428/7
Input/Output board characteristics:
Type of board Digital inputs Digital outputs Ana. inputs Ana output
Max Number of channels 32 32 8 8
Channel characteristics 24 VDC 24 VDC 0.5 A 4-20 mA 4-20 mA
Comments 2A relays wired in the cabinet
Type of Polarity board Digital inputs 220VAC /24VDC Digital 24VDC outputs Ana. inputs Ana output 2.1.1.2 The Main Controller
Type of contact
Equipped reserve 20%
NO/NC 4-20mA 4-20mA
20% 20% 20%
Mounted in a control cabinet at each substation, main 100% redundant CPU rack, I/O rack comprising of inputs and outputs, redundant Modbus/Ethernet communication card, required redundant power supply. Each sub building will have a remote I/O rack communicating with the redundant 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 cabinets where the computer equipment is installed
16428/8
Basic PC, each workstation has the following characteristics: Equipment Operator Workstation Type: Presentation: Processor: Hard disk drive 1: RAM: DVD ROM Communication ports: Display: Keyboard: Operating system: Server Type: Presentation: Processor: Hard disk drive 1: RAM: DVD Burner Communication ports: Display: Keyboard: Operating system: HP/Compaq or Dell or equivalent Mini-tower Intel Core 2 Duo latest processor >=1 TB >= 3GB >= x 8 1 serial, 1 parallel, 2 USB, Ethernet, 1 Modbus LCD 19" TFT, 3 PCI slots free Qwerty MS Windows HP/Compaq or Dell or equivalent Mini-tower Intel Core 2 Duo latest processor >=180 GB >= 3GB >= x 8 1 serial, 1 parallel, 2 USB, Ethernet, 1 Modbus LCD 21" TFT, 3 PCI slots free Qwerty MS Windows Characteristics
Events log printer Type: Characteristics: Report printer Type: Ethernet
Epson, Oki or equivalent Black and white, dot matrix, 132 columns HP LaserJet A4 size or equivalent Industrial Ethernet Switches :10/100/1000 MBPS, 16 10/100 ports, 8 fiber ports or as per requirement Patch Panels: RJ45 and fiber as required Patch Chords: Factory crimped as required
Note: The characteristics set out above are the minimum required. Due to rapidly improving computer performance levels, the configuration supplied may have superior characteristics.
16428/9
2.1.2.2 Software Software Windows OS HMI license (Client) HMI license PLC/ RTU Software with Laptop Windows Server Edition I/O Server, Historian, Database Reference XP PRO, Vista or latest Run time version Development version Development version MS Latest Server Edition Latest Edition as required for the Server Quantity: 5 5 1 1 2 2
16428/10
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 data acquisition, alarm and event management, historical data collection, report generation, local or remote telemetry communications to PLC's/RTU's, and internet/intranet access. The software shall be easy-to-use, with an objectoriented graphics development environment and shall have an open architecture, which utilizes the latest in Win2000/WinXP Professional and Tablet /Win2003 Server client/server and peer to peer networking technology from Microsoft. The system shall have the built-in flexibility to permit easy configuration of the system in accordance with the specific end user requirements as well as quick and easy modification by the end user in the field. The software shall consist of a suite of off-the-shelf modular components from a single software manufacturer that are tightly integrated together to perform all SCADA system functions. The suite shall contain an HMI for process visualization, Real-Time relational database for historical data collection, client tools for trending and reporting within the HMI and as standalone and communication drivers for PLC/RTU's. It shall be scaleable so that a small, single, stand alone application can easily be expanded into a large distributed control network with either single or redundant database servers, single or redundant communication servers providing information to multiple workstation clients. The software shall also have the ability to easily interface with CMMS, LIMS and GIS systems.
2.3
Development Environment Software Requirements This section describes the engineering database development requirements of all system software functions in any combination as follows: 2.3.1 Multi-User Development Environment The Development Environment shall provide a simultaneous, multiuser development environment, where users are subject to security permissions based on individual system-wide roles. 2.3.2 Object Model The Development Environment shall utilize the concept of Application Objects. These Objects may represent real world devices such as PID loops, Motors, Pumps, Valves, etc, or informational objects such as external database readers and writers, XML readers and writers, etc. Application objects shall closely model the physical representation of plant equipment and devices and not be bound to a tag-only topology. This shall include the ability to create complex, multi-variable data structures.
16428/11
2.3.3 Object and Code Re-Use The Development Environment shall promote code re-use through standard templates, which may be customized to create new object instances, while still maintaining parent-child relationships of the object definitions. 2.3.4 Object Repository The Development Environment shall utilize a centralized repository for templates and application objects, object hierarchy, deployment configuration, and genealogy. The Development Environment shall allow users with configuration rights to view objects and ensure that only one person can check out for change a specific template or application object at any one time. The repository shall be used only for configuration and as such may be disconnected from a running system without affecting the operation of said system. 2.3.5 Object Templates The Development Environment shall provide a mechanism to develop Object Templates. These object templates shall be used to create the individual instances of the objects that perform the SCADA tasks. Object Templates shall be able to contain other object templates in a hierarchical relationship. Objects shall contain general object configuration, Input/Output definitions, internal attribute definitions, internal documentation for configuration help, user defined attribute definitions, alarm definition, history definition, and contained scripts. The Development Environment shall expose Base Templates provided by the software manufacturer. An Object Toolkit shall be available to allow user to create new base objects using Visual C++ and Visual C#. The Object Template shall allow the configuration of historical data storage without using a separate tool. The Object Template shall allow configuration of a connection to an alarm 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) with pre-defined tools that will step the developer through the process of defining the configuration.
16428/12
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 Language Runtime. The scripting shall be easy to program using English-like statements and shall not require any knowledge of any other programming logic. The user shall be able to edit or modify the logic scripts while the system is monitoring the process. The scripting language shall include selection boxes and pull-down menus to permit statements to be created without having to type tag names or specific commands. The software shall support basic commands and operations 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 full library of more complex math and system script functions available. A validate button shall be included to ensure proper syntax and provide indication of errors to eliminate any problems at runtime. On-line help for each script function shall include actual working examples that can be copied and pasted into the script editor. Dot NET functions provided by Microsoft shall utilize documentation provided by Microsoft. System logic shall support configuration of objects to automatically perform functions such as increase set points, perform totalization, and check the status of process parameters to take action appropriate action. System Logic shall support the configuration of objects to monitor the status of each tagname/hiearchical name attribute in the system and perform specific functions based on the type and status of an alarm condition. System shall support the configuration of objects that perform application control to change the state of discrete points, show windows, download recipes, etc. This application logic shall also start and stop other application programs such as Excel, Word and other applications like Crystal Reports. The system shall be able to configure scripts to be executed when an instantiated object starts up, when the instantiated object goes on scan, on a condition on true, while true, on false, and while false, periodically, when the instantiated object goes off scan, and when an instantiated object shuts down. 2.3.7 Conditional Control and Data Change Logic The system shall support the configuration of objects that perform application control based upon a user definable state of an object and attribute or the result of an expression involving multiple object tag names/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
16428/13
define Condition Logic scripts that execute once when the condition expression becomes true, once when the condition expression becomes false or while the condition is true or while the condition is false at a user definable rate of 50 milliseconds minimum, or when the value changes. The Development Environment shall provide a communication manager of I/O Server Application Objects to provide remote server installation, configuration activation, and operations, and extensive protocol diagnostic troubleshooting. 2.3.8 Template Derivation, Object Instantiation and Inheritance New templates shall be derived from existing templates, base (supplied by the software manufacturer) or user defined. A template shall inherit the entire configuration of the parent object when generating a new template instance. Templates may contain other templates in a hierarchy. Templates may be derived from templates. Derived templates shall maintain any hierarchy that the parent template contains. The Development Environment shall be able to lock specific attributes to allow changes to the parent template to pass through to the new instance 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 and configure the application from a plant model perspective. The Development Environment shall have the ability to view and configure the application from an Application Object deployment perspective. The Development Environment shall have the ability to view and configure objects showing the genealogy of the object from the object back to its parent template(s) and back to the base object, no matter the length of the parent to child relationship. 2.3.10 Import/Export Utility The Development Environment shall include a utility to support import or export into a human readable file format such as .CSV (comma separated file format) for editing in a spreadsheet application such as Microsoft Excel. It shall be possible to instantiate templates and application objects from the .CSV load by only populating the appropriate columns in the spreadsheet that are required for the instantiation/configuration of the desired objects.
16428/14
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 any Application Object, its children, dependencies, and any other software required and bound by the Application Object for the Application Object to successfully operate. All instantiated Application Object components shall be configured and deployed from the Development Environment to target workstations and servers. The Development Environment shall provide visual feedback as to the deployed status of any Application Object. The Development Environment shall provide visual feedback as to the status of any Application Object that has a change pending. 2.4 Security The Development and Runtime Environments shall be capable of utilizing Microsoft operating system security, for example Active Directory Domains, to allow users access to view, configure, or modify templates and Application Objects. The security system shall support an object based, hierarchical model. This model shall allow for the creation of Security Groups that contain Configuration Database Application Objects. The model shall allow for the creation of Operator Roles that can be assigned to Security Groups. Operator Roles shall allow for the assignment of configuration database permissions, and for runtime operational permissions, and access to visualization of certain windows. At a minimum, runtime operational permissions shall allow for: The access or denial of the ability to acknowledge an alarm in the runtime environment. The modification of configuration attributes which allows users to configure the attributes value (for example, a PLC register that defines a discrete 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. To open and view a process or application window. The modification of tune attributes which allows users to tune the attribute in the runtime environment. Examples of tuning are attributes that adjust alarm set points and PID sensitivity. Users assigned to Operator Roles shall inherit all parameters that were assigned to the Role and Security Group.
16428/15
Runtime changes to object values shall be subject to security authorization. Permissions that are configured using the Development Environment shall be automatically checked at runtime for authorization including verification of identity and access permission related to the originator of the runtime change request. Users shall log in before any change to any object attribute that has been constrained is allowed. The runtime architecture shall conform to the object attribute security model defined in the configuration environment. 2.5 Audit Trail The Development environment shall provide an audit trail of Check Out/Check In, and revision history for each template or application object that includes user 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 of user ID, full user name, previous value, and new value. Attributes configured for Verification shall provide an audit trail of user ID, full user name, verifier username 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 in the runtime mode in any combination as follows: 2.6.1 Alarm Management Alarms 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 alarm storm (hundreds or thousands of alarms detected within one second), the Alarm Manager shall report and the client shall be capable of displaying 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 (Microsoft Database Engine). Alarm events to be recorded shall include alarm instantiation, alarm return-of-normal, and alarm acknowledgment. Items to be logged in addition to the alarm event shall include date and time 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 alarm acknowledgement, and Alarm Priority An Alarm Purge service shall be provided to automatically purge and optionally archive alarms that are older that a user defined period of days online.
16428/16
Alarms may be printed to a locally connected or network printer. The alarms printed from a particular node may be all alarms, only unacknowledged alarms, only acknowledged alarms, alarms from a particular alarm group or groups, alarms from a particular priority to a particular priority, or alarm from multiple alarm providers. 2.6.2 Communications Architecture The run-time environment shall be based on distributed, peer-to-peer system architecture. It shall be possible to scale the architecture from a single, self-contained node, to over 500 nodes. The architecture shall contain a multi-computer model that is seen as a single distributed namespace in the run-time environment and does not require replication of data from one node to another. Application Objects and their attributes shall be accessible by the objects Hierarchical Names, or globally unique Tag names. The architecture shall allow for remote re-deployment of communication application programs without manually reinstalling software. The Architecture shall allow for remote re-deployment of application objects and associated programs without re-loading software The architecture shall be based on a publish and subscribe communications methodology versus poll-based to minimize network traffic and to ensure portability of objects upon redeployment. 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 high volumes of asynchronous data and event messages at a rate of thousands of messages per second. It shall be capable of supporting one million (1,000,000) IO and five hundred (500) nodes Application Objects shall have the ability to connect to any IO server 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 parameter generated for exchange between objects in the system. At a minimum, 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 Runtime Data Viewer The runtime environment shall provide a utility to view the real-time status of any Application Object Attribute.
2.6.3
16428/17
2.6.4
SCADA System Failover The SCADA system software shall provide redundancy for all functions within a normal SCADA controls environment. The specific components that require redundancy within the SCADA system are Application Object/Application Object Hosting, PLC/RTU communications, alarm reporting, and logging of historical process data. In redundant configuration, there shall be a Primary and a Backup system object that manages contained Primary and Backup objects. The system shall execute active objects and synchronize active objects with standby objects. In the event of detection of any failure in active object execution or communication with the active object, standby objects shall begin executing and communicating within the system. Defined Failure Events The SCADA system shall detect the following events within the SCADA system and network objects: Communications failure to a single RTU/PLC Communications failure to multiple RTU/PLC(s) Communications failure to Communications Server Application Logic Failure Alarm Printer Failure (Off-line, out of paper) Alarm Manager Failure Data Historian rate of collection deviation Low Disk Space on any data historian on the network The SCADA System shall detect any or all of the possible failures and allow client data recovery without operator intervention.
2.6.5
2.6.5.1
Application Redundancy The system shall provide for the execution of standby application objects that become active upon the failure of execution of active objects or failure to communicate with the active objects. Separate configuration of standby objects is not required. Objects are allocated to a Primary object manager engine, which in turn insures that contained Backup objects are created and deployed as standby. In normal operation, the Primary engine along with its contained objects shall be active. The backup engine and contained objects shall be kept in standby and shall be synchronized with their active partners on a user configurable time base. Configuration of application redundancy shall be by configuration by check-box and drag-and-drop. Alarm Redundancy The system shall provide for the handling of alarms from standby application objects that become active upon the failure of execution of active objects or failure to communicate with the active objects. Separate configuration of alarms in standby objects is not required. As with application redundancy, objects are allocated to a Primary manager object that in turn insures that contained standby objects are created and deployed as standby for handling of alarms.
2.6.5.2
16428/18
2.6.5.3
Communications Redundancy The SCADA System shall monitor the status of communications to the Communications Server(s) and the status of the Communications Server to each PLC/RTU. In the event of a communications failure the SCADA System shall transfer communications responsibility to a designated standby communications server. Data Historian Redundancy The system shall provide for historization of data values from active objects. Upon the failure of execution of active primary objects, standby objects shall be activated and assumed the task of providing data for historization. Separate configuration of historization for standby objects shall not be required. If the Historian is off-line or unreachable, the engines servicing active objects shall store the historized data locally, and forward the buffered data to the Historian when the historian server is available. Primary and standby object engines shall synchronize any buffered historization data. If the Historian is off-line or unreachable and the primary object engine fails, the failover engine shall assume that task of storing the historized data locally, and forward the buffered data to the Historian when the historian server is available. There shall be no practical limit, other than disk space, as to the size of the historized data stored locally. Terminal Services Fail-Over Terminal Services thin clients shall be capable of automatically failing over to a redundant terminal server. No operator intervention shall be required. The system shall support execution of the visualization software and the engineering development tools in Terminal Services sessions while enforcing the configured operating system security model.
2.6.5.4
2.6.5.5
2.7
RTU/PLC and DCS Communications Server The SCADA system shall include broad range of communications servers for establishing the I/O interface between field devices such as RTUs, PLC's, DCS systems and the data historian. General Purpose I/O Communications Servers General-purpose communication I/O servers shall be available for all major PLCs from Allen Bradley, GE, Modicon, Siemens etc, plus various RTUs and DCS systems. The PLC communication servers shall support interfaces via direct serial, local control network such as data highway plus and Modbus Plus or via TCP/IP Ethernet. There shall be support for several hundred various devices utilizing the protocols of DDE, Suitelink, and OPC. An I/O server toolkit shall be available for third parties to develop custom I/O servers. 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 allow an in-process DDE conversation on one computer to be seen as OPC on
2.8
2.9
16428/19
another computer without the use of NetDDE or DCOM as a transport. This utility shall operate under Windows NT4, Windows 2000 Workstation or Server, 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 and supervisory control functions from this workstation. Typical operator commands include modifying set points for control loops, alarm acknowledgment and set point adjustment, auto/manual switching and on/off control of field devices and taking points or devices on/off scan. The operator shall be able to access all SCADA tag name/hierarchical names or graphic displays from any workstation on the network without knowing which data historian or server the point or display resides on. The system software shall include an object-oriented color graphics display generator with full animation capabilities to provide users with a realistic visualization of the system process. All graphical editing operations shall be point-and-click; selecting icons from a floating and docking tool bars, pull down menus or keyboard commands. It shall be possible to perform a functional test of any graphic display by switching to the runtime mode with a single mouse click. The graphics editor shall include a broad library of complex objects and process symbols such as meters, pushbuttons, sliders, gauges, pumps, motors, tanks, valves, trends, alarms, and controller faceplates. All complex objects shall be scaleable to any size and may include animation links to provide dynamic response based on real-time data or user action. This workstation shall utilize the Win2000 Workstation /Server, WinXP Professional/XP Tablet, or Server2003 operating system. 2.11 Runtime User Interface (HMI) Software Requirements The software shall be licensed to support any of the following operating systems on appropriate hardware in any combination as follows: Server, workstation or desktop PC running Microsoft Windows 2000 Workstation or Server, Windows XP Pro/XP Tablet, or Windows 2003 Server. Thin client, with diskless PCs running sessions served by Microsoft Windows 2000/2003 Terminal Server. Hand held devices running Windows CE or Embedded XP. Display Navigation Operators shall interface to all process and SCADA activities through easily recognized icons, pull down or full screen menus. The system runtime software shall support operator access to multiple displays at one time, including split screens where the operator may view more than one process area at a time. In addition, the system shall support unlimited use of pop-up displays for additional help or diagnostic information. The system runtime software shall support multiple CRT monitors through 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 the system with a single keystroke or mouse click.
2.12
16428/20
The operator shall be able to access displays via a pointing device and/or soft key menus with a choice of function keys, cursor control keys, or any single key on the keyboard. Display navigation shall not normally require 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 an object can be selected. Typical objects include process device symbols (pumps, motors, etc.) controller faceplates, buttons or switches or sliders.
2.13
Operator Security The Operator Workstation shall utilize the security model defined by the configuration database. The software shall utilize data level security where the ability to modify a set point or other value is determined in the configuration database. Any changes to the data level security model shall be seen by all operator stations without any modifications to the operator stations. The security system shall be capable of disabling access to all Microsoft Windows controls (file menu, close, minimize, etc.) and keyboard commands (Ctrl-ESC, Alt-Tab, and Ctrl-Alt-Del). 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 HMI components such as historical logging, alarms and I/O communications. The service capabilities allow continuous operation through operating system logons and logoffs such as operator shift changes. All SCADA software shall support running as a windows service so that following a power failure or when the machine is turned on, an automatic start-up to the runtime mode will occur. This function assures unmanned station start-up without compromising operating system security.
2.14
2.15
Logging Operator Actions All operator actions shall be logged to an event logger. The event logger shall keep track of each new operator log-on, log-off, set point change, or device control. Each event log shall record the date, time, operator logged in and the type of action taken (set point change, state change, etc.). Value Change Event Logging Any configured Integer, Real, discrete, or String tag may also be configured as an event. The point shall be logged as an event any time its value changes.
16428/21
Events shall be logged to a Microsoft SQL Server or MSDE (Microsoft Database Engine). Items to be logged in addition to the event itself shall include 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 information from a full screen alarm-summary display or on a small scrolling region and the bottom of any display. The alarm information shall be displayed in chronological order with the most recent alarm at the top. The information capable 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-ofchange, etc.), value, acknowledging operator , acknowledging node priority level, alarm or process area group name, and class. It shall be possible for the operator to filter the alarm display based on priority level, alarm groups or process area. In distributed network systems, alarms shall be viewed and acknowledged from any workstation and the information shall be distributed to all clients. The name of the operator and the node acknowledging the alarm shall be capable of being displayed in the Alarm Summary It shall be possible to configure the system such that the operator is notified of an alarm no matter which display the operator is currently viewing. Notification shall include the option of a pop-up alarm display window, a flashing process symbol such as a process vessel, an alarm text message that is available on each display, or a dedicated alarm display window anywhere on the screen. A configurable audible signal shall be provided. The alarm summary display shall provide the built-in horizontal and vertical scroll bars to page through alarms. The display of these scroll bars shall be user-configurable. The alarm summary display shall allow for dynamic re-sizing at runtime of the column widths simply by selecting a column line and dragging it to set the column 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 or unacknowledged. The colors shall be user-selectable via configuration from a total of 256 colors. The system shall provide a method of notifying the user when a new alarm has occurred. The alarm display object shall automatically scroll to a new alarm when the user has scrolled down the alarm list from the top. The alarm display shall retrieve alarm information by submitting an alarm query to the alarm server. The alarm query shall allow specifying a priority range, alarm acknowledge state, alarm group, alarm history or summary. Combinations of the parameters can be specified for the query to produce selected results.
16428/22
The operator shall be able to create new alarm queries, at runtime, and save the 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 only those alarms visible in the display, only those selected, only the most recent alarm or all alarms in the system. The alarm display shall allow alarms to be selected 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 of alarms on another operator interface. Un-suppressing previously suppressed alarms shall be via simple mouse click. The operator shall be able to select an alarm from the alarm summary display and 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 audible tone, a pop-up display, or any combination of animation types on the screen. Power System Automation server should transfer all the alarm generated to the Facility Management server. 2.17 Thin Client Operator Workstation The SCADA system operator shall be able to execute all monitoring and supervisory control functions from a thin client workstation or environment. No SCADA HMI software shall be required to be installed on a Thin Client Operator Workstation. This workstation shall require only the firmware or software required to initiate a Windows 2000 or 2003 Terminal Services session. The SCADA HMI shall support Windows 2000 or 2003 Server/Advanced Server/Data enter Server with Terminal Services enabled in Application Server Mode utilizing native Remote Desktop Protocol (RDP), or Citrix Metaframe utilizing Independent Computing Architecture (ICA) protocol. The SCADA HMI shall support up to twenty-five (25) sessions of the HMI software 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 a Full Function Operator Workstation (thick client) shall run in a Windows2000 or 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, or Linux. The SCADA HMI shall support Microsoft Terminal Services Advanced Client running in Microsoft Internet Explorer.
16428/23
2.18
Process Data Analysis Workstation The SCADA system software shall include a set of easy-to-use client software tools for real-time and historical data analysis and system reports. This client analysis software may be used by engineering, maintenance or supervisory personnel who need information from the SCADA system but do not require access to graphic displays. The client tools shall be able to access data from multiple data historians on the SCADA system network. Users shall be required to log in with a password to access the database server. The user shall not have to know the location of the server on the network, only the name of the server. The data analysis software shall include tools for advanced trending analysis, X-Y plotting of tag names, and viewing of reports in spreadsheet or free form format. All tools shall support full right mouseclick capability for quick menu selection of available functions. The client tools shall be available as a stand-alone program or as an ActiveX control for imbedding into the SCADA so that any full function or view only operator workstation may have the same capability, or any user interface that supports ActiveX. Real-Time and Historical Trend Analysis Tool A client tool shall be included that allows users to view any or all of the tag names in either a trend chart or tabular format. The client tool shall have a user interface that allows for easy selection of tag names using a Windows Explorer-like browser with a search filter to quickly find tag names in a data historian with thousands of points. The user shall be able to create folders for selected groups of tag names and plot them individually or in groups by dragging 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 the real time to the historical viewing mode using a simple check box. The user shall be able to toggle from viewing trends either in the superimposed or the stacked mode. In the superimposed mode, all trends overlap and are in a single scale range based on the largest vertical scale range in the group. In the stacked mode, each trend has its own vertical scale range. Trend plots shall automatically be scaled based on the widest vertical range of the tag name or optimized based on the maximum and minimum range within the selected time period. 2.19.1 Real-time Trend Viewing The user shall be able to trend up to 256 different tag names in real time including analog, discrete, string or event tag names within the same trend. The user shall pick tag names from the browser. The time span and vertical range of the trend shall be user configurable at 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 be able to adjust the range of the tag names in run time. Historical Trend Viewing The user shall be able to plot historical data for any tag name or groups of tag names in the database based any user-selected start and stop time. Two hairline cursors may be turned on and dragged across the trend area to provide the user with the exact value for
2.19
2.19.2
16428/24
each trended tag name at the point of intersection. The time span and the value between the cursors shall also be displayed. It shall be possible to overlay data from different start/end times to compare the performance of equipment / compare the process for different time intervals. It shall be possible to overlay live trends onto history traces to compare performance. The trend tool shall display statistical data for each trended analog tag name within the time period selected. Statistical values shall include the minimum, maximum, average, and standard deviation. Icons or menu pull down commands shall be available for analyzing the data such as horizontal, vertical or rubber band zooming pan left or right and zoom between the hairline cursors. It shall also be possible for the user to create text annotations anywhere on the trend. These annotations shall be visible from other workstations on the network with the same trend tool. It shall be possible to export the data in the 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 the Trend and Query clients so that they may be imbedded into SCADA HMI or any other ActiveX container. A query client shall be included to allow the user to execute SQL queries that returns a result set from any SQL server database into a tabular data grid. The query ActiveX tool shall support multiple data server sources for simultaneous display of the data. An ActiveX trend object shall also be provided and support the same functions such that an operator trained on one tool is trained on the other tool. HTML Reporting Client Tool A client tool shall be included that allows users to generate reports on any tag names. The client tool shall have a user interface that allows selection of tag names and previously created reports and report formats. The report tool shall allow you to set up, modify, and generate reports that present report data professionally and reliably. Types of information supported shall include historical and current data values, tag name configuration information, graphs, statistics, annotations, event and summary information and results from a query. Reports shall be generated based on data stored over a specified time period in minutes, or hours, days, weeks or months. It shall also be possible to generate reports on demand by the user at runtime. Finished reports shall be formatted in HTML so that they can be viewed with a Web Browser, stored on the server disk or sent to a printer. Excel Reporting Tool The data analysis software shall be included that allows users to easily select tag names and historical values from the real time or historical database via a browser and then utilize them in a standard Microsoft Excel spreadsheet for reporting or presentation
2.19.4
2.19.5
16428/25
to management. The selection of tag names shall be accomplished by use of drag and drop or point and click commands. It shall not be required to write any macros to retrieve the data. The tag values selected can be output to specific cells in the spreadsheet and processed as number data types. The user shall be able to select historical data for the most recent values or go back and select any start or stop time as far back as the data is available. The historical data can be recalled at the granularity that it was stored or in a selected number of data points over a period of time. The user shall be able to retrieve raw historical data or summarized data such as the minimum, maximum or average over a predetermined time period. Updates to the current values once they are in the spreadsheet shall be refreshed with a single click of the mouse. The quality of the data shall be analyzed and displayed. The user shall be able to select if poor quality data is to be displayed or replaced 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 to easily select tag names from the real time or historical database via a browser and then utilize them in a standard Microsoft Word document for reporting. The selection of tag names shall be accomplished by use of drag and drop or point and click commands. It shall not be required to write any macros to retrieve the data. The tag names selected can be output to specific values or arrays using standard Word tables. The user shall have the choice of selecting real time, absolute, relative or configurable base dates and times. The user shall be able to retrieve raw historical data, summarized data such as the minimum, maximum or average over a predetermined time period or data stored in the historian event system. The user shall be able to select if poor quality data is to be displayed or replaced with an interpolated value.
2.20
View-only Graphics Display Workstation The SCADA system software shall support view-only graphics workstations for managers or supervisory personnel who wish to have access to all displays and trends but do not have process control or alarm acknowledgement responsibilities. No modifications to the SCADA HMI configuration shall be required for this functionality. The view only graphics display HMI shall be capable of running in a terminal services session. HMI Development Software Requirements This section describes the engineering development requirements of all SCADA system software functions. This includes development of color graphic displays, configuration of the real-time and historical database, alarms, I/O communications to field devices and application setup of clients and servers on the SCADA network. All development and configuration shall be persisted in one or more common file or database repositories that provide single point of configuration. Furthermore, there shall be a common naming
2.21
16428/26
convention for objects and tag names that is enforced by the development tools. The software shall be licensed to support any of the following operating systems on appropriate hardware in any combination as follows: Windows 2000 Workstation or Server, Windows XP Pro/XP Tablet, or Windows 2003 Server, 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 graphics display generator with full animation capabilities to provide users with a realistic visualization of the SCADA system process. All graphical editing operations shall be point and click selecting icons from a floating and docking tool bars, pull down menus or keyboard commands. It shall be possible to perform a functional test of any graphic display by switching to the runtime mode with a single mouse click. The development environment shall be capable of running in a Terminal Services Session. The display editor shall include the following tools for display drawing, linking and animation. Graphical Objects The graphics editor shall include a set of basic drawing tools to create simple or complex objects. Selecting an icon on the drawing toolbar shall easily create simple objects, which include lines, rectangles, polygons, ellipses, circles, and filled shapes or text. Any of these objects can be assigned various attributes such as line color, fill color, size, and orientation and can be made static or dynamic. Text objects shall be scaleable and use true fonts in bold italic 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 such as cut, copy, paste and delete. Alignment tools shall be included to simplify proper placement and arrangement of objects. Align commands shall be included to align objects based on justification to the left, right, center, top or bottom. 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 and process symbols such as meters, pushbuttons, sliders, gauges, pumps, motors, tanks, valves, trends, alarms, controller faceplates and bitmaps. All complex objects shall be scaleable to any size and may include animation links 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 to 128 user-defined colors. A user defined color palette can be created, exported and imported. The color palette shall be based on 16.7 million colors. System must also support the user choosing transparent colors for all graphical objects and backgrounds.
2.23
16428/27
Percentage of fill for objects up, down, left or right direction based on a tag name/hierarchical Name. An object may blink based upon any Boolean expression, alarm, event, or upon 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 the object based upon the status of a discrete point, alarm, or operator security level. The system shall support animation of objects via re-sizing, moving, and/or rotating based upon a change in a tag name/hierarchical name Objects shall be animated based upon any user-defined criteria made up of tag names in the system. This includes the use of expressions containing mathematical functions and the status of analog and discrete values in the system Graphics Editor shall allow layering of objects to activate specific objects based upon conditions in the process. Graphics development tools shall allow object placement via a snap -to-grid feature with configurable grid spacing. Graphics development tools shall support an undo/redo feature with a configurable number of levels and command displays. The system shall support a library of self configuring objects that change properties based on dialog box entries made during development. For example, consider a standard set point loader object that has a graduated scale and a default range of 0 to 100.0. Dialog box entries shall allow changes to the range of the set point loader, the number of major and minor divisions on the scale, and change the text font used for the labels. The object 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 elements imported as native objects. It shall be possible to animate these objects using the full set of object animation properties as specified in earlier sections Graphics editor shall also allow the user to import drawings and images in BMP, JPEG, PCX and TGA file format. The graphics development environment shall support the copy of single or multiple animated graphic objects and symbols with just two keystrokes, and immediate substitution of tag names for the duplicated object shall be possible without leaving the graphics editor.
16428/28
The graphics development environment shall support the copy of single or multiple animated graphic objects and symbols from one window or display to another retaining all of the animation characteristics, links and attributes. This function 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 while building a display without exiting the graphics editor. On-line context sensitive help shall support display building. Users shall be able to obtain immediate help on all configuration subjects by pressing a single function key. The user shall be able to define graphic screens while the system is monitoring the process 2.25 Compound Symbols Using a Compound Symbol Manager, application developers shall be able to create groups of symbols that then comprise a single named Compound Symbol that may be expressed as a named Template. There shall be no practical limit to the number of graphic symbols that can comprise a single Compound Symbol, up to, and including an entire window of symbols. These templates shall connect either to Object Database objects, to local HMI tags or to HMI tags through remote references. Changes to the Compound Symbol Template shall propagate to all instances of the template. Libraries of reusable Compound Symbols may be created and managed by the Symbol Manager. The Symbol Manager shall allow for the creation and deletion of a hierarchical tree of folders. Compound Symbols may be moved between folders via dragand-drop. The Symbol Manager shall allow for the import and export of Compound Symbols. The Symbol Manager shall allow for the renaming of Compound Symbols/Templates. A Compound Symbol shall be instantiated in the HMI window by selecting the symbol in the Symbol Manager and selecting OK. The selected Compound Symbol shall invoke a dialog to allow for browsing and selecting new tags or attributes from the Object or Tag Database, and to allow for creating entire new named objects in the object database. The Symbol may then be resized by dragging the corner of the symbol to the desired size. The Symbol Manager shall allow for the editing of a Compound Symbol. At the completion of the editing process a dialog shall be displayed that allows the changes to be committed, aborted, or return to editing. The Dialog shall also display all of the windows that contain children of the Compound Symbol
16428/29
Template. Committing the edit shall propagate all changes to the Compound Symbol to all children of the Compound Symbol Template. Breaking the Compound Symbol shall break the inheritance chain with the Compound Symbol Template. The broken Compound Symbol can then be remade as a new Compound Symbol Template that starts a new inheritance chain. The tags/objects attributes of a Compound Symbol may be changed or redirected to an alternate set of tags/object attributes at runtime via a single script command. 2.26 Alarm Summary/Alarm History Object Alarms shall be displayed by configuring a user-defined alarm summary object, 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 configuration dialog. Default alarm object configurations shall be displayed with the option of changing any configuration parameter for runtime viewing. The alarm object configuration shall include parameters with check boxes to select and enable or disable how the alarms appear at runtime. Alarms shall be color coded according to the state and priority of the alarm including an acknowledged alarm, unacknowledged alarm, and an alarm that has returned to normal but is not yet acknowledged. The user shall be able to choose from 256 different colors for display of each of these alarm states. The alarm display object shall also support event display, with the color used for events also being one of the 256 different colors. ActiveX Support The SCADA software shall provide extensibility by providing integrated support for OLE Controls (OCXs) technology. The SCADA software shall be an ActiveX container supporting methods, properties and events of ActiveX objects. The support of ActiveX technology shall provide application developers immediate access to hundreds of OCXs developed by dozens of Independent Software Developers. Registering an OCXs for use within an application system shall be an automatic process. Registered OCXs shall be displayed 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 be quickly added to new and/or existing applications. At design time, the user is focused on selecting an OCX for placement, mapping OCX properties, events and methods to tag names and writing logic to control OCX behaviour via OCX properties and methods. MI Application Manager Each application shall include an application manager with a Windows Explorer-like browser to simplify management of windows (displays), scripts, tag names, alarms and application documentation. A tag name crossreferencing index shall provide and efficient means identifying where all tag names, 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
2.27
2.28
16428/30
developed on workstations with different display resolutions and convert them to 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 application by providing means of distributing the application in network environments. The Distributed Network Application (DNA) management software shall adhere to client-server architecture while allowing a single master application to be developed and maintained on the network. The DNA manager shall automatically distribute the master application to all nodes on the SCADA control network. a) Application Locations Master applications shall be maintained on a server that each client node can access, which provides ease of maintenance and unrestricted editing. The DNA manager will allow client nodes to access the application from the server and it will distribute the server application to a user-defined location that each client node may specify. This approach inherently provides the client-based advantage of redundancy. Notification of Application Changes to Client When a client node loads an application from the network server, the client shall maintain a copy of the application on its local hard drive and become registered as a user of that application. When a change to the server application is detected, each registered user node shall be notified of the change. The DNA manager shall allow the user to define how the client node is notified of the change in the application. The client node shall either automatically load the new application, prompt the user to load changes or ignore, or automatically ignore such changes. If a network failure occurs between the server and client, then the client shall continue to run the last distributed application. When the network is restored and the server application has changed, the DNA manager will distribute the server application to the client. Application Log Files Application log files shall reside on the local hard drive for a userdefined number of days. Each network node shall maintain an independent log file for the applications that are unique to each node. A new log file will be created and archived daily according to the user specified time and location. The viewer shall support color distinctions for different threads, processes or programs. The log file viewer shall support viewing remote node application log files. HMI Application Control Logic The SCADA system software shall include a scripting language that allows execution of commands and mathematical and logical operations based on specified system conditions or user actions. The scripting shall be easy to program using English-like statements and shall not require any knowledge of any other programming logic. The
b)
1.
2.
16428/31
user shall be able to edit or modify the logic scripts while the system is monitoring the process. Furthermore, it shall not be necessary to invoke any other application to compile the changes. The scripting language shall include selection boxes and pull-down menus to permit statements to be created without having to type tag names or specific commands. Buttons shall be available for easy selection of basic commands and operations 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 full library of more complex math and system script functions available. A validate button shall be included to ensure proper syntax and provide indication of errors to eliminate any problems at runtime. On-line help for each script function shall include actual working examples 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 programming environment. No compilers or linkers shall be required. The system logic shall be able to automatically perform functions such as increase set points, perform totalization, and check the status of process set points to take action. The system Logic shall be able to monitor the status of each tag name in the system and perform specific functions based on the type and status of an alarm condition. Alarm type may be lo, lo-lo, hi, hi-hi, deviation or rate of change. Alarm status may be acknowledged or unacknowledged. The system shall have the capability to perform application control to turn on/off discrete points, show windows, download recipes, etc. This application logic shall also start and stop other application programs such as Excel, Word and other applications like Crystal Reports. The system shall have the ability to execute user definable logic on the parameters of On Application Start-up, While Application Running and On Application Shutdown. 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 an expression involving multiple tag names; including discrete tag name on/off state, alarm states such as lo, lo-lo, hi, hi-hi, or equivalence to a specific value. It shall be possible to define Condition Logic scripts that execute once when the condition expression becomes true, once when the condition expression becomes false, while the condition is true, or while the condition is false at a user definable rate of 50 milliseconds minimum. HMI Keyboard Control Logic System shall have the capability to perform application control whenever a user presses a key on the keyboard. This includes whenever the key is pressed, released, or while the key is held down at
4.
5.
16428/32
a definable interval. The system will support any of the keys on a standard 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 a Window Logic script upon a user definable state of a tag name or the result of an expression. HMI Function Logic The system shall support creating of logic blocks and saving the logic as a function. These function scripts shall be capable of running on a process thread independent of the HMI process. Function scripts shall run on a separate process thread and not impact the performance of the HMI operations. Function scripts shall be able to be called from any of the logic types defined in earlier sections including a call from a function script to another function script. Data Historian The SCADA system software shall provide a real-time relational database historian for long-term storage of process data. The Data Historian shall provide for the storage of real-time and historical data for each analog, discrete or string tag name. The data historian shall also store summary, event, alarm and configuration data. The database engine for the historian shall be based on a full licensed copy of Microsoft SQL Server and supports client/server architecture. The user shall not be required to know Microsoft SQL Server to install and implement the historian. The data historian database shall acquire and store process data at full resolution. The data historian database shall include normalized extension tables for real time data and include a set of client tools for data analysis and reporting such as those described in earlier sections. The Data Historian shall be capable of running in a stand-alone mode without connection to, or configuration from, the SCADA system While there are always physical limiting factors such as disk space, there shall be no programmatic limit to the amount of data that may be stored on-line. Additionally, there shall be no performance penalty for long-term data storage. There shall be no discernable difference in retrieval speed of data based on the age of the data. For example, the retrieval of two hours data stored two years prior shall be the same as for two hours of data stored one day ago. 9. Data Compression The database shall support high-speed data acquisition and efficient data compression. The data compression for the data historian shall not use any algorithms that do not allow for the storage of the tag data at their scanned rate. The stored data records shall be able to recreate the process data in a loss-less format. Below are the data storage techniques to be employed for the various types of data.
7.
8.
16428/33
10.
Discrete Storage Requirements Each discrete stored value written to the Data Historian shall use approximately 7 bytes of space. Delta Analog Storage Requirements Each delta stored analog value written to the Data Historian shall use approximately 10 bytes of space. Cyclic Storage Requirements Each Cyclic stored analog value written to the Data Historian shall use approximately 10 bytes of space. String Storage Requirements Data shall be capable of storing string, or text, data. Each string may be up to 512 characters in length. With each string value stored, a quality field shall be stored as well. Standardized Database Tables The process of setting up the database tables shall be automatically configured and require no database engineering. Data definitions including the creation of database objects, such as tables, indexes, constraints, defaults, rules, stored procedures, triggers, and views shall follow a standard, published and readily available database schema. This standard database schema shall outline the relationship between tables, table columns, keys and indexes and shall allow for third party development of client applications. Database device sizes shall be dynamically allocated during database installation depending on the number of tag names to be stored within the data historian. Single Configuration of Data Historization The historization of data from SCADA objects shall be entered once at the time of configuration of those objects using the corresponding object editor in the SCADA System. The Data Historian shall automatically acquire those configuration historization parameters upon deployment of the configured Application Objects Historical Data Point Configuration The data historian shall include a database editor to modify the parameters of any tag name without using the SCADA database editor as an option. It shall be possible to configure the data storage rate for each point based on a user-defined rate frequency (cyclic storage) or upon change (delta storage). Cyclic storage rates shall be configurable per point from 1 second up to hours. The historian database shall support a 5-millisecond resolution for tag names configured with delta storage.
11.
12.
13.
14.
15.
16.
16428/34
17.
Historian Data Acquisition and Retrieval The data historian shall acquire data via automatic and manual methods. Automatic data acquisition shall be through industry-standard data 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 be Structured Query Language (SQL). It shall be possible to store data at one resolution and query at another. Methods shall exist to query and retrieve data cyclically, with millisecond resolution, no matter the storage mode. It shall be possible to query and retrieve data in delta, with user selected dead-band criteria and millisecond resolution, no matter the storage mode. It shall be possible to query and retrieve evenly spaced data over long periods of time where the criteria are a row count, no matter the storage mode. Dynamic Configuration and Bump-less Data Initialization The historian shall automatically begin to acquire tag data immediately after a tag configuration has been committed to the database. Adding a single or multiple tags to an existing historian database shall not affect the data acquisition of previously defined tag names. Client connections will not be affected during reconfiguration due to dynamic configuration. Additionally, there will be no loss of data for tags where data acquisition configuration is not changed. Tags that require a change in data acquisition configuration will obviously lose data during the period of their re-initialization Manual Data, Out-of-Sequence Data, and Superceded Data The historian shall support Manual Data, Out-of-Sequence Data, and Superceded Data. Manually entered data such as Lab Data and Outof-Sequence Data such as batched history data from a Remote Terminal Unit (RTU) shall be treated by the retrieval engine as if the data were stored automatically. Any historized data may be superceded by manually inserting the correct data value and a flag denoting that the previous data has been superceded. The original data shall not and cannot be modified or destroyed. An SQL client tool may 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 Separated Variable (CSV) file. Only users with proper login credentials shall be allowed to manually insert or modify data. Data Quality All stored data shall contain data quality attributes. The primary Data Quality attribute shall reflect Data Quality as defined in OLE for Process Control (OPC). Additional quality attributes shall be used for initial data (startup flag) and superceded data.
18.
19.
20.
16428/35
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 trigger some type of action when the event is detected. The event system shall detect an event occurrence using pre-defined and configurable criteria; historically log when an event occurs and trigger designated configurable event actions based on the event detection. Event attributes shall be logged to the database and will include the date, time that the event occurred, and the event criteria that were satisfied. Event Configuration Using a point and click approach, the system shall allow users to create/define event tag names and associate event tag names to event detectors and the resulting actions. The user shall be able to insert a time delay in milliseconds before the event action is triggered and establish the priority of the event as normal or critical. It shall be possible to detect an event based on scheduled time interval, a specific analog 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 be provided to support complex SQL event detectors and event actions. Event action The data historian event detectors shall determine that an event has occurred and trigger an associated action. Event detectors shall scan for events at the user-defined rate for each event. The user shall be able to select from any one of four actions when an event is detected. Event actions shall include 1) execution of an SQL statement to perform an SQL query on the database; 2) taking a snapshot and recording the time stamp and values of one or more selected analog or discrete tags; 3) sending a Microsoft Exchange e-mail message to designated recipients and 4) change the cyclic time and/or value delta storage rate for one or more analog tag names. The ability to modify the storage rate based on an event allows fast logging of data to gather more valuable process data to assist in troubleshooting. Database Summary System The data historian shall provide user configurable data summary tables for any analog tag name and to automate the collection of aggregate historical information based on a declared event. The summary system shall support minimum, maximum, average and summed calculation types for Minute, Hourly, Daily, Weekly and Monthly frequencies. The summary system shall store the tag name, value, type of calculation, and frequency as defined for each tag name.
22.
23.
24.
16428/36
25.
Historian Interface to Other Relational Databases The data historian shall utilize Microsofts Data Transformation Services to simplify the transfer of historical process data with other SQL Server databases like Microsoft SQL Server or Oracle. The historian database shall include an OLE DB Provider (Object Linking and Embedding for Databases) so that any other SQL client can access the real-time or historical process data from the data historian. Disk Storage Management The data historian shall not require specialized tools for disk storage management. It shall be possible to archive and retrieve historical data files using standard Windows copy techniques. It shall be possible to retrieve select portions of archived data without retrieving all archived data. Retrieval of the archive data shall automatically place this data on-line and available for retrieval by the data historian. Additionally, the data historian shall approach zero-administration as nearly as possible. The data historian shall provide for a mechanism whereby current files on a disk drive that is nearly full will automatically be moved to a secondary device. The files and available space on the secondary drive shall be monitored as well such that when a userdefined threshold is reached, the oldest files may be automatically deleted to preserve the integrity of the system. Historical files shall never be deleted from the primary storage device if an appropriate secondary device is configured.
26.
27.
SCADA System Software Installation and Licenses The SCADA software shall be easily installed from a single CD or a set of CDs using a standard install program. During the installation procedure, the user shall be able to select the features and functions required for each workstation or server in the SCADA system. While loading the selected software, it shall be possible to redirect the location of the software components. The SCADA software shall be licensed using software license files that can be easily restored to the system in case of hard drive failure. No hardware keys shall be required to run the software.
28.
Software Warranty, Maintenance and Support The software vendor shall provide software maintenance and support program to ensure that the user receives full benefit of the software for the duration of its life cycle. The program shall provide for basic warranty coverage and include an extended warranty for priority support and software upgrades as they are released. Telephone support shall be available through a toll free number during normal business hours. Support shall also be available via fax, email or through a technical support website.
16428/37
29.
Warranty Support The software vendor shall warrant the products for a period of one year after delivery. During the warranty period, the vendor shall offer free technical telephone support during normal business hours through a toll free number. All software defects shall be resolved in a timely manner. Extended Warranty Annual Software Maintenance and Support After the one year warranty period, the user may continue to receive technical support via fax, email or access the technical support website. In order to ensure that the user always has access to the latest software releases, long-term warranty and technical support, the vendor shall offer an extended support program for a fixed annual fee that entitles the user to receive the following: Software Upgrades: The extended support program shall entitle the user to receive the latest SCADA system software releases and version upgrades, as they become available. In order to ensure quality support for all users, all software licenses at the site must be maintained at the same version level. Priority telephone support: The extended support program shall include telephone support during normal local business hours. A technical support engineer who has been certified by the software vendor based on a certified support testing program shall provide telephone support. An actual live person when calling during normal business hours shall provide unlimited telephone support. A voice-mail tech support system shall not be acceptable.
30.
31.
Electronic Support: The extended support program shall include e-mail support within one business day at a higher priority than non warranty support users, and will forward them to the nearest certified technical support center. Electronic support shall also include expanded access to advanced services on our technical services web page. The extended support program shall include real-time access to current and past issues in a call tracking database, as well as the ability to create new issues, which shall be immediately assigned to a technical support engineer for resolution. Electronic File Download: The extended support program shall include access to a secure web site for electronic file downloads. Service packs, patch fixes, updated IO Servers and other support files shall be available for support users from the secure web site. Newsletter and Tech Support CD: The software vendor shall provide a newsletter and a technical support CD with tech notes to all users on the extended support program a
32.
33.
16428/38
minimum of three times per year. The technical support CD shall include a comprehensive summary of technical notes, technical alerts, applications, application utilities, diagnostic utilities, ActiveX controls, drivers, scripts, script functions, wizards and helpful hints that can streamline application development. Glossary and Abbreviations AI AO ATS CB CD CPU DAT DB DB WS DCS DI DO EMCS EPDC GD GDS GE GPS HD HVA HVB LAN LR LS LV HMI IED MB MTBF MTTR OLTC OWS PC PCS PLC RAM RIO RTU UPS Analogue Input Analogue Output Automatic Transfer Switch Circuit Breaker Compact Disk Central Processing Unit Digital Audio Tape Database Database WorkStation Distributed Control System Digital (discrete) Input Digital (discrete) Output Electrical Monitoring and Control System Electrical Power Distribution Control system Generator - Diesel powered Generator - Diesel powered backup Generator Global Positioning System High Density High Voltage (> 63 kV) High Voltage (< 63 kV) Local Area Network Load Restoration Load Shedding Low Voltage (< 1000V) Human-Machine Interface Intelligent Electrical Device Megabyte Mean Time Between Failure Mean Time To Repair On Load Tap Changer Operator WorkStation Personal Computer Power Control System Programmable Logic Controller Random Access Memory Remote Input Output Remote Terminal Unit Un-interruptible Power Supply
16428/39
3.0
EXECUTION INSPECTION AND TESTING The Contractor shall be responsible for inspection, calibration and testing of all inputs, outputs, alarms, communication and HMI mimics including set point settings.
3.1
Inspection 1. All installation material and equipment furnished shall be subject to the Companys inspection and prior approval before despatch. This inspection shall not relieve the Contractor of any obligation to fulfill all the conditions of this specification. The responsibility for inspection during installation rests with the Contactor. 2. Waiver of any inspection by the Company does not relieve the Contractor of the responsibility for proper installation. This responsibility shall continue until the instruments are in satisfactory operating condition.
3.2
Communication and Mimics 1. The Contractor shall install, test and commission the Works to the satisfaction of the Clients Representative. Error between actual and theoretical calibration figures shall not exceed those specified by the manufacturer. The testing and calibration work shall include but not be limited the items listed below: Checking and adjusting zero, span and linearity of all indicating/ transmitting instruments and devices on the mimics. Checking and setting of all switches on the mimics.
2. Calibration and Testing Procedures and report formats shall be prepared by the Contractor and approved by the Company. 3. Prior to requesting the Superintendents Representative for the witnessing of testing after installation at site, the Contactor shall have performed the following tests: Connectivity between the servers, work stations and all network switches. All electrical circuits checked for continuity, tagging, operability through operator stations. All instruments shall be checked against data sheets and if any discrepancies found by the Contractor, he shall promptly inform the Company.
16428/40
Alarm/ trip/ control circuit tested for correct operation through the mimics. All symbols and nameplates mimics checked for correct spelling, tagging, size, and the like. Data logging and report printing
4. The Contractor shall give the Company sufficient advance notice so that its representative may be present to witness the testing and calibration. The Company reserves the right to request additional testing as deemed necessary to assure functionality at no additional cost to the Company. 3.3. LOOP CHECKING/ PRE-COMMISSIONING The Contractor shall be responsible for checking all the loops from field instruments to the control room operator stations and back for proper operation prior to commissioning of the equipment/ plant. Loop checking shall include but not limited to the following: Switch on power to the instrument loops and check the calibration/setting of the instruments and devices including shutdown system. Proper operation of the PLC redundancy, I/O and other modules. Communication network redundancy test.
The detailed procedure for loop checking shall be developed by the Contractor and approved by the Company. All loops checking and testing shall be properly recorded by the Contractor and witnessed and approved by the Company. 3.4. MAINTENANCE & WARRANTY The system should be provided with 2 year free maintenance & warranty period from the date of system completion. 3.5 SPARE PARTS Vendor supply shall include all spare parts necessary for pre-commissioning and commissioning activities of various equipment included in the supply, in accordance with the KOC Standard No. KOC-G-009 Spare Parts and Maintenance Data.
16428/41
3.6.
COMMISSIONING The Contractor shall carry out commissioning after completion of all the activities above under the supervision and to the satisfaction of the Superintendents Representative.
3.7 A.
DEMONSTRATION AND TRAINING Engage a factory-authorized service representative to train KOC's maintenance personnel to adjust, operate, and maintain Power System Automation system and related software.
END OF SECTION
16428/42

Power System Automation PDF

Uploaded by

Document Information

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

Power System Automation PDF

Uploaded by

Copyright:

Available Formats

SECTION 16428 POWER SYSTEM AUTOMATION 1.

Small Boats Harbours Project