ATTACHMENT 1 EXHIBIT A SCADA/ENERGY ...

Confidential Page 1 of 93

ATTACHMENT 1 EXHIBIT A

SCADA/ENERGY MANAGEMENT SYSTEM STATEMENT OF WORK


TABLE OF CONTENTS

1.0 INTRODUCTION 8

1.1. GENERAL GUIDELINES 8 1.2 SCOPE 9 1.3. CONTRACTOR GENERAL RESPONSIBILITIES 10 1.4. UTILITIES GENERAL RESPONSIBILITIES 11 1.5. STANDARDS 11 1.6. TERMS, ABBREVIATIONS AND ACRONYMS 12 1.7. HARDWARE/SOFTWARE REQUIREMENTS 14

2.0 TECHNICAL REQUIREMENTS 16 2.1 SYSTEM ARCHITECTURE 16

2.2 DATA ACQUISITION 16 2.2.1 RTU PROTOCOLS 16 2.2.2 PERIODIC SCANS 17 2.2.3 ANALOG DATA PROCESSING 18 2.2.4 STATUS DATA PROCESSING 19 2.2.5 PULSE ACCUMULATOR DATA PROCESSING 20 2.2.6 SEQUENCE OF EVENTS DATA PROCESSING 20 2.2.7 ALTERNATE DATA SOURCES 21 2.2.8 SYSTEM REAL-TIME SNAPSHOT 21

2.3 DATA DISPLAY 21 2.3.1 OPERATOR DISPLAYS 22

2.3.3 PRINTING AND REPORTS 22 2.3.4 DATA TRENDING 22 2.3.5 DISTURBANCE DATA COLLECTION 23

2.3.6 APPLICATIONS DATA PROCESSING 24 2.4 SUPERVISORY CONTROL 24

2.4.1 SWITCHING DEVICES 24 2.4.2 LOAD TAP CHANGING TRANSFORMERS 24 2.4.3 CONTROL INHIBIT 25 2.4.4 LOCAL OUTPUT POINTS 25

2.5 PERIODIC CALCULATIONS AND CONTROL 25 2.5.1 BUILT-IN FUNCTIONS 25 2.5.2 GENERALIZED CALCULATIONS 25 2.5.3 DATA AVERAGING 26 2.5.4 MINIMUM/MAXIMUM 26 2.5.5 METER ERROR 26 2.5.6 AUTOMATED CONTROL SEQUENCES 27

2.6 ALARM PROCESSING 27 2.6.1 ALARM & EVENT USER INTERFACE 28 2.6.2 ALARM INTERACTION 28 2.6.3 ALARM SUPPRESSION 28 2.6.4 ALARM INHIBIT 28 2.6.5 TELEMETRY FAILURE 29 2.6.6. ALARM LOGGING 29 2.6.7 RESPONSES TO ALARMS 39 2.6.8 ALARM ENABLING 39 2.6.9 ALARM NOTIFICATION 30

3.0 HISTORIAN AND ONLINE DATABASE 31

3.1 DATA STORAGE AND ARCHIVAL 31


3.2 DATA ARCHIVAL 31 3.3. DATA DISPLAY AND MODIFICATION 31

4.0 DATA LINKS 32

4.1 ICCP DATA LINK 32 4.2 DATABASE LINKS 32

5.0 AUTOMATIC GENERATION CONTROL 33

5.1 GENERAL CHARACTERISTICS 33 5.2 ACE PROCESSING 33 5.3 UNIT CONTROL MODES 34 5.4 UNIT LIMITS 35 5.5 UNIT DESIRED GENERATION 35 5.6 AGC CONTROL SUSPENSION 36 5.7. AGC PERFORMANCE ANALYSIS 36 5.8 ECONOMIC DISPATCH 37 5.9 PENALTY FACTORS 37 5.10 UNIT INCREMENTAL HEAT RATE CURVES 37 5.11 INTERCHANGE TRANSACTION SCHEDULING 37 5.12 ITS SCHEDULE ENTRY 38 5.13 ITS DISPLAYS 39 5.14 EMERGENCY NET INTERCHANGE SCHEDULE 39 5.15 INADVERTENT INTERCHANGE 39 5.16 PRODUCTION COSTING 40 5.17 RESERVE MONITORING 40 5.18 SHORT-TERM LOAD FORECAST 41 5.19 UNIT COMMITMENT/TRANSACTION EVALUATION 42 5.20 SECURITY ANALYSIS APPLICATIONS (OPTION) 43 5.21 NETWORK TOPOLOGY PROCESSOR 43 5.22 STATE ESTIMATOR 44 5.23 POWER FLOW 45 5.24 PENALTY FACTOR CALCULATION 45 5.25 CONTINGENCY ANALYSIS 45 5.26 SECURITY ANALYSIS APPLICATIONS USER INTERFACE 45 5.27 DISPATCHER TRAINING SIMULATOR (OPTION) 46 5.28 FEATURES AND CAPABILITIES 46

6.0 SYSTEM CONFIGURATION REQUIREMENTS 48 6.1 OPEN SYSTEMS REQUIREMENTS 48 6.2 AVAILABILITY 48 6.3 MAINTAINABILITY 49 6.4 SYSTEM CONFIGURATION 49

7.0 USER INTERFACE REQUIREMENTS 51 7.1 USER INTERFACE CONSOLES 51 7.2 GENERAL UI REQUIREMENTS 51 7.2. SUPERVISORY CONTROL 53 7.3 TAGGING 54

8.0 SOFTWARE REQUIREMENTS 56

8.1 DESIGN CHARACTERISTICS 56 8.2 PROGRAMMING LANGUAGES AND APIS 57


8.3 REAL-TIME DATABASE 57 8.4 HISTORICAL DATABASE 57

9.0 TRAINING REQUIREMENTS 59

9.1 GENERAL TRAINING REQUIREMENTS 59 9.2 TRAINING COSTS 59 9.3 LESSONS 59 9.4 VIDEO RECORDING 59 9.5 TRAINING COMPETENCY VERIFICATION 59 9.6 OPERATOR TRAINING 59 9.7 PRE-INSTALLATION SESSIONS 60 9.8 POST-INSTALLATION SESSION 60 9.9 CONTENT OF CLASSES 60 9.10 PROGRAMMER TRAINING 61 9.10.1 CLASSES 61 9.10.2. CONTENT OF CLASSES 61

10.0 SECURITY 62

10.1 REMOVAL OF UNNECESSARY SERVICES AND 62 PROGRAMS

10.1.1 FAT MEASURES 63 10.1.2 SAT MEASURES 64

10.2 HOST INTRUSION DETECTION SYSTEM 64 10.2.1 FAT MEASURES 65 10.2.2 SAT MEASURES 65

10.3 CHANGES TO FILE SYSTEM AND OPERATING SYSTEM PERMISSIONS 65 10.3.1 FAT MEASURES 66 10.3.2 SAT MEASURES 66

10.4 HARDWARE CONFIGURATION 66 10.4.1 FAT MEASURES 66 10.4.2 SAT MEASURES 66

10.5 HEARTBEAT SIGNALS 67 10.5.1 FAT MEASURES 67 10.5.2. SAT MEASURES 67

10.6 INSTALLING OPERATING SYSTEMS, APPLICATIONS, AND THIRD-PARTY SOFTWARE UPDATES 67 10.6.1 FAT MEASURES 68 10.6.2 SAT MEASURES 68

10.7 PERIMETER PROTECTION 68 10.7.1 FIREWALLS 68 10.7.1.1 FAT MEASURES 69 10.7.1.2 SAT MEASURES 69 10.7.2 NETWORK INTRUSION DETECTION SYSTEM 69 10.7.2.1 FAT MEASURES 70 10.7.2.2 SAT MEASURES 70 10.7.3 CANARIES 70 10.7.3.1 FAT MEASURES 70 10.7.3.2 SAT MEASURES 71

10.8 ACCOUNT MANAGEMENT 71 10.8.1 DISABLING, REMOVING, OR MODIFYING WELL-KNOWN OR GUEST ACCOUNTS 71 10.8.1.1 FAT MEASURES 72 10.8.1.2 SAT MEASURES 72

10.9 SESSION MANAGEMENT 72 10.9.1 FAT MEASURES 73 10.9.2 SAT MEASURES 73


10.10 PASSWORD/AUTHENTICATION POLICY AND MANAGEMENT 73

10.10.1 FAT MEASURES 73 10.10.2 SAT MEASURES 73

10.11 ACCOUNT AUDITING AND LOGGING 73 10.11.1 FAT MEASURES 74 10.11.2 SAT MEASURES 74

10.12 ROLE-BASED ACCESS CONTROL FOR CONTROL SYSTEM APPLICATIONS

74 10.12.1 FAT MEASURES 75 10.12.2 SAT MEASURES 75

10.13 SINGLE SIGN-ON 75 10.13.1 FAT MEASURES 76 10.13.2 SAT MEASURES 76

10.14 SEPARATION AGREEMENT 76 10.14.1 FAT MEASURES 76 10.14.2 SAT MEASURES 76

10.15. CODING PRACTICES 77 10.15.1 CODING FOR SECURITY 77 10.15.1.1 FAT MEASURES 77 10.15.1.2 SAT MEASURES 77

10.16 FLAW REMEDIATION 78 10.16.1 NOTIFICATION AND DOCUMENTATION FROM CONTRACTOR 78 10.16.1.1 FAT MEASURES 78 10.16.1.2 SAT MEASURES 79

10.16.2 PROBLEM REPORTING 79 10.16.2.1 FAT MEASURES 79 10.16.2.2 SAT MEASURES 80

10.17. MALWARE DETECTION AND PROTECTION 80 10.17.1 MALWARE DETECTION AND PROTECTION 80 10.17.1.1 FAT MEASURES 80 10.17.1.1 SAT MEASURES 81

10.18 HOST NAME RESOLUTION 81 10.18.1 NETWORK ADDRESSING AND NAME RESOLUTION 81 10.18.1.1 FAT MEASURES 82 10.18.1.2 SAT MEASURES 82

10.19 DEDICATED LINE MODEMS 82 10.19.1 FAT MEASURES 83 10.19.2 SAT MEASURES 84

10.20 TCP/IP 85 10.20.1 FAT MEASURES 86 10.20.2 SAT MEASURES 86

10.21 VIRTUAL PRIVATE NETWORKS 87 10.21.1 FAT MEASURES 88 10.21.2 SAT MEASURES 88

10.22 INTRA-PERIMETER COMMUNICATIONS 89 10.22.1 FAT MEASURES 89 10.22.2 SAT MEASURES 90

10.23 NETWORK PARTITIONING 90 10.23.1 NETWORK DEVICES 90 10.23.1.1 FAT MEASURES 91 10.23.1.2 SAT MEASURES 91

10.24 NETWORK ARCHITECTURE 92 10.24.1 FAT MEASURES 93 10.24.2 SAT MEASURES 93


11.0 USER INTERFACE REQUIREMENTS 95

11.1 USER INTERFACE CONSOLES 95 11.2 GENERAL UI REQUIREMENTS 95

12.0 QUALITY ASSURANCE AND TESTING 98

12.1 TEST PLANS AND PROCEDURES 98 12.2 TESTING 99 12.2.1 FACTORY ACCEPTANCE TESTS 99 12.2.2 SITE ACCEPTANCE TESTING 100 12.2.3 AVAILABILITY TESTING 100 12.3 VARIANCES 101 Appendix A (software and database sizing). 102

Appendix B (performance and response requirements of the proposed 107


1.0 INTRODUCTION

Colorado Springs Utilities (Utilities) is requesting proposals for the replacement of the SCADA/EMS system. The new SCADA system shall include all hardware, software, system integration and installation for a complete working system to replace the Water, Gas and Electric systems. Materials required to demonstrate compliance with these requirements must be included in the Proposal in order to be eligible for evaluation. These requirements are in addition to those stipulated in the general section of this Statement of Work. 1.1. GENERAL GUIDELINES This Statement of Work (SOW) describes the requirements for a new Supervisory Control and Data Acquisition/Energy Management System (SCADA/EMS) to be purchased by Utilities). This new SCADA/EMS shall replace an existing ABB Network Manager 3 Energy Management System. The current SCADA/EMS system operates and controls Electric, Gas and Water for the City of Colorado Springs. This SOW contains the requirements for the replacement of all three utilities SCADA and EMS applications. Contractors are welcome to bid on all three applications as a single application or separately. The current SCADA/EMS system provides SCADA functions to 93 Electric RTU’s on 64 channels. The RTU’s currently use DNP3 and Vancomm protocols. Utilities is currently replacing the Vancomm units with DNP3. The Electric system requires both SCADA and an Energy Management System (EMS). The EMS uses Automatic Generation Control (AGC) to control 6 generating units. The current SCADA System Provides SCADA applications to 116 Gas RTU’s on 4 channels. Most of the Gas RTU’s read a single pressure point. The RTU’s currently use ModBus RTU protocol. There are 7 Fisher Remote Operation Controller (ROC) in the field that currently use ModBus RTU as a conversion from Fisher ROC Protocol and Utilties would like price information for using this protocol. The current SCADA System Provides SCADA applications to 237 Water RTU’s on 23 channels. The water RTU’s currently use ModBus RTU protocol and there are some plans to upgrade them to DNP 3. All three utilities rely heavily on IEEE floating point numbers and there is extensive use of Point to Point communications. This involves passing all data types from one field device to another. Utilties preference would be to have one solution that encompasses all three utilities with the following conditions: The systems must be independent of each other to the extent that changes made to one application do not affect the other two. The use of separate data bases and servers would be one acceptable method. All aspects of the system must be fully redundant at the primary site and transferable to the offsite backup center.


The system must have capability of making changes and additions to the database without shutting the system down or recompiling the application. The new SCADA/EMS shall be installed in the existing Colorado Springs Utilities System Energy Control Center (SECC) located in Colorado Springs, Colorado. The Colorado Springs Utilities System Energy Control Center (SECC) currently houses the present SCADA/EMS. This shall require that the new SCADA/EMS be installed and commissioned while sharing common building facilities with a fully operational SCADA/EMS. The existing Utilties SCADA/EMS shall be decommissioned and moved out of the Utilties Control Center once the new SCADA/EMS becomes operational and the system cutover is complete. The installation and commissioning of the new SCADA/EMS must be carefully coordinated with Utilties support staff. 1.2 SCOPE The new SCADA/EMS shall utilize modern facilities and techniques to provide the high-speed data collection, data analysis and decision-making processing required in improving system economy and reliability. The SCADA/EMS shall be designed to augment current operating procedures and interface with existing equipment including interfaces for, Historian Data Warehouse, ICCP Link, and Water Information Systems. The new SCADA/EMS shall support an extensive data acquisition and control network to communicate with existing and newly acquired RTU and the hardware and software interfaces associated with same. Required SCADA functions for the new SCADA/EMS include:

Data Acquisition Supervisory Control Periodic Calculations Disturbance Data Collection ICCP Data Link On Line Historian System/Historical Archiving

Required Energy Management functions for the new SCADA/EMS include:

AGC/multi area control Ancillary service dispatch AGC performance monitor Economic dispatch Interchange transaction scheduling Reserve monitoring Production costing Unit commitment/transaction evaluation Load forecasting Topology processor Load flow State estimation Contingency analysis Penalty factor calculation Dispatcher training simulator (Option)

Appendix A contains the system sizing for the initial delivery and ultimate capacity (software and database sizing).


Appendix B contains the performance and response requirements of the proposed SCADA/EMS. System software needs to be sized to initial sizing in Appendix A. The quote shall contain price estimates for expansion to ultimate sizing in Appendix A. The proposed SCADA/EMS shall be designed for ease of expansion and alteration in a cost effective and efficient manner. Expansion includes adding and removing monitored and displayed quantities, adding and removing system functions and altering computer memory and input/output hardware. The SCADA/EMS shall permit the compiling, debugging and integration of new software on-line with no interruption of normal system operations. One-line and tabular displays shall be generated, altered and maintained on-line. The new SCADA/EMS shall be designed for an operating life of not less than ten years with a minimum availability of 99.95%. The Contractor shall demonstrate the availability characteristics of the new SCADA/EMS during field tests conducted after installation. Full operation of the new SCADA/EMS is scheduled for 11/01/2010. 1.3 CONTRACTOR GENERAL RESPONSIBILITIES The Contractor shall assume responsibility for the design, fabrication and startup of the new SCADA/EMS. The Contractor's obligations shall include, but not be limited to, the responsibilities in the following list, and those required performing the system functions described in the SOW:

a) System engineering, software design, development, and integration services necessary for SCADA/EMS implementation.

b) Delivery of all operating system software and application software. c) Delivery of all processors, consoles, printers, local input/output facility, signal and power

cabling, related hardware and the interconnection of all Contractor-supplied equipment in the Utilties control center.

d) Communication hardware, except actual lines or channels. e) Integration of all Contractor-supplied hardware and software. f) Interface with the existing RTUs and other Utilties supplied hardware. Factory must have test

RTU’s on site. g) Factory, field and availability tests. h) Training of Utilties personnel to include System Operators and Administrator Users. i) Engineering, programming and database conversion assistance. j) Supply spare parts and test equipment lists. k) Users guides, drawings and other documentation provided in hard copy as well as electronic.

All drawings must be as built. l) The service and the assurance of the availability of spare parts for a ten-year period from the

date of system acceptance. m) Installation supervision. n) Future maintenance support quotes. o) Shipment, Installation, maintenance, and warranty of the equipment during the different

stages of the implementation p) Database conversion, iterations, validation, and missing information q) Displays and other reports r) Maintenance and warranty responsibilities s) NERC CIP and other cyber security responsibilities t) Project deliverables such as implementation plans, schedules, etc. u) Training


1.4 UTILITIES GENERAL RESPONSIBILITIES Utilties shall supply the following items and services as part of the new SCADA/EMS:

a) Space in Utilties equipment room for new Contractor supplied equipment. b) Power sources at the Utilties System Energy Control Center. c) Air-conditioned environment at the Utilties Control Center. d) Digital Communication circuits and their connection to Contractor-supplied terminal boards. e) Remote Terminal Units (RTU) except those used at factory for testing f) Technical review of Contractor's designs. g) Participation in factory and field acceptance tests. h) Preparation of needed displays and reports. i) Assisting Contractor in converting existing data bases. j) Coordination of Contractor’s activities with the Utilties operating requirements. k) RTU point-to-point testing.

1.5 STANDARDS All work manufactured and/or furnished under any part of this SOW shall satisfy the latest version of the appropriate standards of:

a) American National Standards Institute b) Institute of Electrical and Electronics Engineers c) Instrument Society of America d) American Society of Mechanical Engineers e) National Electrical Manufacturers Association f) Electrical Power Research Institute

Where the above standards differ, the Contractor shall state, which standard applies. Unless modified by provisions of this SOW, these standards apply whether mentioned in the text or not. The Contractor shall also note where existing standards are not satisfied, or only partially satisfied. Where non-standard hardware, software or services are offered, the Contractor shall defend their adequacy in relation to the functions to be performed, and the cost of providing the work that fully satisfies existing standards. NERC CIP North American Electric Reliability Corporation Critical Infrastructure Protection ANSI/ISA-99 Security for Industrial Automation and Control Systems All work shall be performed and materials shall be furnished in accordance with the NEC National Electrical Code, the NESC - National Electrical Safety Code, and the standards established by the following organizations where applicable: ANSI American National Standards Institute ASTM American Society for Testing and Materials AWG American Wire Gauge FERC Federal Energy Regulatory Commission ICEA Insulated Cable Engineers Association IEEE Institute of Electrical and Electronics Engineers NEIS National Electrical Installation Standards NEMA National Electrical Manufacturers Association NFPA National Fire Protection Association


UL Underwriters' Laboratories NERC North American Electric Reliability Corporation ISA Instrumentation, Systems, and Automation Society DOT Department of Transportation PHMSA Pipeline Hazardous Materials Administration 1.6 TERMS, ABBREVIATIONS AND ACRONYMS ACL Access Control List AES Advanced Encryption Standard AH Authentication Header AOR Area of Responsibility ARP Address Resolution Protocol ASCII American Standard Code for Information Interchange BERT Bit Error Test BIND Berkeley Internet Name Domain BIOS Basic Input/Output System BSS Basic Service Set CB Citizen Band CERT Computer Emergency Response Team CIKR Critical Infrastructure and Key Resources CISO Chief Information Security Officer COTS Commercial Off-The-Shelf CPU Central Processing Unit CRC Cyclic Redundancy Check CSV Certified Server Validation DCS Distributed Control System DHCP Dynamic Host Configuration Protocol DMZ Demilitarized Zone DNS Domain Name System DOMSAT Domestic Satellite DoS Denial of Service DVD Digital Video Disc EAP Extensible Authentication Protocol EMS Energy Management System ESP Encapsulating Security Payload FAT Factory Acceptance Test FEP Front-End Processor FTP File Transfer Protocol GAO Government Accountability Office HIDS Host Intrusion Detection System HMI Human-Machine Interface HSRP Hot Standby Routing Protocol HTTP Hypertext Transfer Protocol ICCP Inter-Control Center Communications Protocol ICMP Internet Control Message Protocol IDPS Intrusion Detection and Prevention Systems IDS Intrusion Detection System I/O Input/Output IEC International Electrotechnical Commission IED Intelligent Electronic Device IEEE Institute of Electrical and Electronics Engineers INL Idaho National Laboratory


IP Internet Protocol IPS Intrusion Prevention System IPSec Internet Protocol Security ISA Instrumentation, Systems, and Automation Society ISAC Information Sharing and Analysis Center ISC Internet Software Consortium ISM Industrial, Scientific, and Medical ISO International Standards Organization IT Information Technology KVM Keyboard, Video, Mouse LAN Local Area Network LOS Line-Of-Sight LR- WPAN Low-Rate Wireless Personal Area Networks MAC Media Access Control MAS Multiple Address (Radio) System MCM Manual Control Mechanism MISPC Minimum Interoperability Specification for PKI Components MITM Man-in-the-Middle NAT Network Address Table NERC North American Electric Reliability Corporation NIC Network Interface Card NIDS Network Intrusion Detection System NIPC National Infrastructure Protection Center NIPS Network Intrusion Prevention System NIST National Institute of Standards and Technology O&M Operations and Maintenance OBDC Open Database Connectivity OLE Object Linking and Embedding OPC OLE for Process Control Operator An employee responsible for the operation of a utility console OS Operating System OSI Open Systems Interconnectivity PBX Private Branch Exchange PCS Process Control System PLC Programmable Logic Controller POE Power Over Ethernet PROFIBUS Process Field Bus RAID Redundant Array of Independent Disks PSTN Public-Switched Telephone Network RBAC Role-Based Access Control RFC Request for Comments RFI Remote File Include RPC Remote Procedure Call RTU Remote Terminal Unit/Remote Telemetry Unit SAT Site Acceptance Test SCADA Supervisory Control and Data Acquisition SIS Safety Instrumented System SMTP Simple Mail Transfer Protocol SNMP Simple Network Management Protocol SOP Standard Operating Procedure SQL Structured Query Language SSH Secure Shell Terminal Emulation SSL Secure Sockets Layer SSO Single Sign-On


System Operator An employee responsible for the operation of the electric distribution desk

TCP Transmission Control Protocol TDEA Triple Data Encryption Algorithm Transmission Operator An employee responsible for the operation of the electric transmission

desk UDP User Datagram Protocol USB Universal Serial Bus VLAN Virtual LAN VPN Virtual Private Network VRRP Virtual Router Redundancy Protocol WAN Wide Area Network WiFi Wireless Fidelity WIS Water Information System WPA WiFi Protected Access XML Extensible Markup Language XSS Cross-Site Scripting 1.7 HARDWARE/SOFTWARE REQUIREMENTS Equipment and software shall be designed, coordinated, and supplied by a single manufacturer or supplier, hereinafter referred to as the Contractor. The Contractor shall be regularly engaged in the business of supplying computer-based monitoring, control, and data acquisition systems. The Contractor shall provide all services specified in this Statement of Work and perform all testing, training, and startup activities. 2.0 TECHNICAL REQUIREMENTS This section describes the system architecture and technical requirements and functionality to be supported by the SCADA/EMS. It shall be noted that although it is the intent of Utilties that the Contractor utilizes standard application software to the maximum extent possible, the proposal shall be evaluated by its conformance to the functional requirements of this SOW. Appendix A of this document contains all system and functional sizing. Appendix B contains the performance and response requirements. 2.1 SYSTEM ARCHITECTURE At a minimum the system shall consist of:

a. Fully redundant system at the primary site b. Redundant Standby System at Secondary Site c. Non redundant test system d. Removable media backup at Primary and Secondary Site e. All equipment necessary to fulfill the requirements in Appendixes A&B f. Maximum allowable workstation refresh time three seconds g. Output requests shall be processed first h. The system must be configurable in Areas of Responsibility (AOR). These must be

defined at all levels. Operators must not be able to affect devices, data, or outputs to anything outside their defined AOR.


2.2 DATA ACQUISITION The SCADA/EMS shall process and utilize real-time data acquired from remote terminal units (RTUs) and from data links with other SCADA or SCADA/EMS master stations. The database shall be of sufficient size to accommodate total number of all scanned and calculated data defined in Appendix A and satisfy the functional requirements of this SOW. 2.2.1 RTU PROTOCOLS The SCADA/EMS shall be provided with the capability to communicate to RTUs using the following protocols:

• DNP 3.0 • DNP TCP • Vancomm • ModBus RTU • ModBus TCP • FISHER ROC

All provided protocols except Vancomm must support at least 32 bit devices and IEEE Floating points. (Real Numbers) The Contractor shall provide a list of other available RTU protocols that have been implemented for the SCADA/EMS and indicate which protocols are standard, or provided with the SCADA/EMS. The SCADA/EMS must also be able to provide for selective scanning and control of status, analog, and accumulator points from remotes using the DNP and DNP TCP Vancomm, ModBus RTU, ModBus TCP, FISHER ROC. All protocols must support at least 32 bit devices and IEEE floating points. Report or Scan by exception must be executable on all protocols. The DNP 3.0 and DNP TCP protocols must support Sequence of Events (SOE) data and perform time synchronization between the master and remote stations. The ability to control Select-Before-Operate (SBO) points, direct-operate analog set-point points and AGC raise/lower control points shall be provided as well. Communications using the DNP 3.0, ModBus and Vancomm protocols shall be over 1200 to 9600 baud data modems and digital circuits. This will include communications over RS232. 2.2.2 PERIODIC SCANS The SCADA/EMS shall poll real-time data from RTUs. At a minimum, the SCADA/EMS shall provide scan rates for polling of status and analog data at two (2) second, four (4) second, eight (8) second, ten (10) second, twelve (12) second scan rates. For polling of accumulator data, the SCADA/EMS shall provide periodic scan rates of five (5) minutes, fifteen (15) minutes, and one (1) hour. The accumulator scan cycles shall be synchronized to the system time (for example, the hourly scan occurs at the top of the hour. In addition to the scan rates described above, as needed other scan rates shall be provided for future use by Utilties. All scan cycles shall be on a rigid time basis with any failure to complete a scan within the designated time period resulting in data being marked with a quality code. Communication Failures shall result in an escalating alarm structure ending in a notification of total failure.


The SCADA/EMS shall provide the capability for polling RTU status and analog data using scan-by-exception techniques. However, this feature shall not initially be used and all RTU status and analog data shall be polled using status or analog data function code requests. Scan Inhibit function must allow the operator to suspend scans on a periodic basis. Demand scan functions will allow the operator to demand immediate information for all points associated with RTU. Communications error monitoring shall be enabled using CRC or equivalent and must accumulate the following errors at a minimum: Response too short Response too long No Response Garbled response Bad CRC or equivalent The communications error accumulators must be user resettable. The ability to add, remove or delete communications points from the database must not require a system build or system interruption. Data shall be capable of being passed from one field device (RTU or PLC) SCADA communication drivers. Information written to the receiving device must be identical to information contained in the source device. This function must support IEEE and scaled outputs. An online communication protocol analyzer shall be provided as part of the offered system. The protocol analyzer shall include the capability of saving data for later analysis. 2.2.3 ANALOG DATA PROCESSING The SCADA/EMS shall perform, as a minimum, the following processing of all analog data:

1. Data validity checking 2. Data conversion 16 bit and 32 bit 3. Filtering 4. Limit checking and Rate of Change processing 5. Data storage in the historical database. 6. IEEE data scanning and storage, 16 bit and 32 bit. 7. Scaled output from real values to integers in the field device. 8. Set point outputs must be processed on a higher priority than inputs

The SCADA/EMS shall convert each scanned non IEEE analog point in 16 bit or 32 bit format to engineering units. Both raw and converted data should be able to be stored in the database. As a minimum, this function shall perform the following conversion algorithm: Value = (A * Scanned Value) + B Where ‘A’ and ‘B’ are constants, definable by user entry for each analog point. Each analog value in the SCADA/EMS (calculated and telemetered) shall be compared to all applicable limits, as described below, each time the value is processed.


The reasonability limits of an analog point are defined as unique high and low value limits, representing the extremes of the valid operation of the point's measurement element. The reasonability limit checking function shall be applicable to all calculated and telemetered analog values. A reasonability limit violation shall constitute a telemetry failure of the point in question, and shall generate an alarm. In addition, the reasonability limit checking function shall provide for the database retention of the last valid point value, with appropriate quality code, following a reasonability limit violation. Upon return to a reasonable value of the questionable data, and if the Operator has not removed the point from scan, the new value shall be accepted and a return-to-normal alarm generated. Reasonability limits shall be user adjustable for each point, preferably as a percentage of the point’s full-scale value. No alarm shall be generated for a reasonability limit violation when the Operator has taken the data source, or its associated communication circuit, out-of-scan. All analog values (calculated and telemetered) shall be compared against a minimum of two high and two low operating limits. The number of limits applied to a point must be user configurable. The SCADA/EMS shall normally utilize default values of the operating limits entered by the user, which shall be stored in the database. It shall however, be convenient for the Operator to override any limit via an Operator display. The limit monitoring software shall prevent annunciation of multiple alarms resulting from a point value oscillation about an alarm limit ('alarm chatter’). Rate of change shall be defined on a scan to scan basis and a time function The rate of change, time limits and number of scans will be user definable. 2.2.4 STATUS DATA PROCESSING Status data shall be processed to determine the current status and to report any change of status. The newly acquired status shall be compared against the current status data in the database to determine if changes have taken place. If a change of status is detected that is not the result of a control action, an alarm shall be generated. Commanded and manually entered changes of status shall be recorded as events, with the designation of the console, which initiated the change identified. It shall be possible to define a correspondence between a “normal” condition and the current telemetered status value (e.g. open or closed). Points, which are not in the normal state, shall be included in abnormal summaries. The software shall be capable of inverting the state of a contact input point upon receipt of the telemetered data and before processing in the database. The software shall also be capable of associating either state of a contact input point (open or closed) with either state of the actual device (for example, open or closed breaker). The user shall specify point definitions individually. The SCADA/EMS shall also accommodate non-telemetered points for use by application programs, displays, or reports As a minimum, the SCADA/EMS shall accommodate the contact input data types defined as follows:


Status: Points having two states; typically alarm or normal, or positional (open or closed). Where these points are defined with alarms a process must be in place to prevent excessive alarming when large amounts of changes are generated. Switch: Points having three positional states typically open, closed or in-travel. Where these points are defined with alarms a process must be in place to prevent excessive alarming when large amounts of changes are generated. Momentary Change Detection (MCD): Points subject to multiple operations between scans (e.g. breakers with reclosers). Where these points are defined with alarms a process must be in place to prevent excessive alarming when large amounts of changes are generated. For selected status points that are associated with breakers and switches, a counter shall be maintained to accumulate the number of operations of the device, including all momentary changes. Status with Memory (Vancomm and DNP protocols only) The software must be configurable to read status with memory on defined points. Where these points are defined with alarms a process must be in place to prevent excessive alarming when large amounts of changes are generated. 2.2.5 PULSE ACCUMULATOR DATA PROCESSING The accumulators shall be frozen by a command transmitted from the SCADA/EMS. The freeze command shall be issued at selected time intervals either as a broadcast freeze-command sent to each RTU communications channel or a selective freeze command issued to individual RTUs. The Utilties supplied remote terminal units shall transfer the contents of the accumulators to a buffer register for retrieval by the SCADA/EMS. The freeze command shall not reset the accumulators at the RTUs. Hourly accumulator data shall be retrieved every hour from each telemetered accumulator defined in the SCADA/EMS. Completion of the retrieval process of all accumulator data shall be accomplished during an adjustable time window set by user entry. Initially, the time window shall be set from the top of the hour to one minute after the hour following the freeze request. Hourly accumulator data shall be converted to engineering units using the following algorithm: Value = A * (Current Hour Scanned Value - Previous Hour Scanned Value) Where 'A' is a user entered constant, unique to each defined accumulator point and 'scanned value' is the telemetered hourly raw value. If any accumulator cannot be frozen, or if the accumulator cannot be scanned, the SCADA/EMS shall substitute, if available, the appropriate integrated value from a periodic calculated point and tag the value to identify it as a non-telemetered reading. The Master Station shall also be capable of retrieving and processing sub-hourly accumulator data. The collection of sub-hourly accumulator data shall be at user defined rates from 5 minute to 30-minute intervals.


2.2.6 SEQUENCE OF EVENTS DATA PROCESSING The SCADA/EMS shall provide software for processing of sequence of events (SOE) data from RTUs. This capability shall be provided for RTUs with the DNP and Vancomm protocols. These remotes can be defined with SOE status and/or analog points and a status flag is returned in RTU reply response messages to notify the master station that SOE data is available. To support SOE time tagging the SCADA/EMS shall perform time synchronizing of all RTUs equipped with SOE points. The SCADA/EMS shall collect the SOE data during channel idle time to minimize normal scanning activity. The collected SOE event data from the RTUs shall be stored in an ODBC accessible format for later analysis and report generation. An alarm message shall be generated upon receipt of SOE data to inform the System Operator that data is available. The SOE capability is not to be a substitute for normal status point scanning. The SCADA/EMS shall report status changes for SOE points in the same manner as non-SOE points. 2.2.7 ALTERNATE DATA SOURCES The SCADA/EMS shall provide via Transmission Operator selection, an alternate real-time or calculated data source for a specific analog value. The processing of these multiple source values shall include:

a) Reasonability limit checking of all values b) Ability for the display and storage of data from both the selected and backup source via the

historical information storage function

2.2.8 SYSTEM REAL-TIME SNAPSHOT The SCADA/EMS shall have capabilities to capture, and store a snapshot of the real-time database upon System Operator command, on demand, as well as at periodic bases (e.g. 1 minute). A minimum of 200 full one-minute data base snapshot files need to be maintained. A snapshot file shall be able to be reloaded and viewed from standard one-lines and tabular displays. A playback function shall be able to allow the operator to step through the available snapshot files from a specified starting time to a specified end time. The System Operator shall be able to purge individual snapshots at any time. 2.3 DATA DISPLAY The SCADA/EMS shall provide the capability to display to the System Operator any data value in the SCADA/EMS database via any or all of the Operator displays regardless of the source of the data, the frequency of its collection, or the means used to store it in the database. These requirements shall apply to, but are not limited to, the following types of data:

a) Telemetered data - analog, contact input and accumulator data regardless of scan rate, b) Calculated data - analog and Boolean, c) Data stored in main memory and auxiliary memory, d) Data generated by all application programs.


2.3.1 OPERATOR DISPLAYS Operator displays shall be the primary interface between the System Operator and the SCADA/EMS. As a minimum the display contents shall be selectable from SCADA/EMS database information including any of telemetered, calculated and/or manually entered values. The displayed data shall be presentable by any or all of message, tabular data or annotated schematic presentation formats. The manual control activities performed via a set of associated control devices, including a mouse, function keys and alphanumeric keyboard shall be possible. The Operator displays described in Section 7 of this SOW summarizes the type of menu, overview and tabular displays to be supported by the SCADA/EMS. In addition, the SCADA/EMS shall support one-line displays and world coordinate system based displays for use by System Operators for control and monitoring of the power system. The one-line displays shall be designed and constructed by Utilties personnel following completion of prerequisite training courses provided by the Contractor on site. Operator displays must contain graphics for the utility being displayed: Water Specific Graphics Pipes, tanks, two way valves, multidirectional valves,

orifice meters, rotary meters, ultra sonic meters, ect. Electric Specific Graphics One Lines, transformers, switches, fuses, relays,

wires, ect. Gas Specific Graphics Pipes, tanks, two way valves, multidirectional valves,

orifice meters, rotary meters, ultra sonic meters, etc. 2.3.3 PRINTING AND REPORTS In order to satisfy the functional needs of Utilties, the SCADA/EMS shall be required to generate on-demand and periodic summary reports of data in the System Real-Time database and from data stored by the historical information storage function or any of the SCADA/EMS applications functions. Common tools using ODBC and SQL shall be used to generate reports and logs. Utilties prefers to use Microsoft Excel, Access, and/or Crystal Reports to meet this functionality. Custom reports shall be designed and constructed by Utilties personnel following completion of prerequisite training courses provided by the Contractor and with Contractor’s support and guidance. 2.3.4 DATA TRENDING The SCADA/EMS shall provide a data trending function that allows any data value to be captured, saved and viewed in a graphical trend format on an Operator display. At a minimum, the data trending function shall provide the user with the following capabilities:

a) Continuously capture samples of up to 400 selected data values

b) Support horizontal and vertical trending

c) Selection of any data value in the system real-time or applications data for trending


d) Selection of the sample rate (2 second minimum)

e) Data collection shall run continuously until deactivated by the user

f) Display of multiple trend variables on a trend display

g) Trend axis shall be automatically scaled in time and engineering units based on the data point

under trend

h) Selection of trend color for each data variable

i) Trend displays shall be updated at the fastest trend point sample rate

j) Scrolling forward and backward through all the collected trend samples

k) Panning and zooming through all the collected trend samples

l) Print of trend displays on laser printers (color and black & white)

m) Export of selected trend data in CSV format to a disk file

n) Multiple trend windows with multiple pens in each window

2.3.5 DISTURBANCE DATA COLLECTION The SCADA/EMS shall have a disturbance data collection function that shall collect a user defined set of data points (a minimum of 500 points) with quality codes from the real-time system database. The collection shall be triggered by a status or analog point entering into the abnormal alarm state. The data collection shall be at a minimum 2-second rate for a period of 15 minutes. The ability of the collection software to also retain data samples prior to the trigger time is required. The pre-trigger data samples should include 5 minutes of samples prior to trigger time. The ability to store a minimum of eight buffers on-line should be provided. A set of Operator displays should be provided for viewing, printing and saving the collected data. This display shall also allow purging collection buffers. The capability shall be provided to access the saved data via ODBC and SQL. 2.3.6 APPLICATIONS DATA PROCESSING The Contractor shall provide various application programming interfaces including but not limited to (APIs), ODBC, SQL, DDE, and XML interfaces to allow development of custom applications and to allow direct interface with the real-time database via these industry standard methods. The APIs shall provide a convenient method for the addition of future applications, which could be written by Utilties that permits data exchange from the SCADA real-time database and applications program.


2.4 SUPERVISORY CONTROL Capabilities shall be provided to perform supervisory control operations via any of the RTUs connected to the SCADA/EMS and the external ICCP data links. The SCADA/EMS shall also have capability for output of analog and status point data to a local I/O facility is required. All operator initiated control actions shall be logged. 2.4.1 SWITCHING DEVICES Capabilities shall be provided for Operator selection and operation of any controllable switching device (e.g. circuit breakers and motor operated switches, capacitor and reactor switching devices). The selection and operation of a controllable switching device by the Operator shall require a multi-step procedure to prevent inadvertent equipment operation. The Operator shall have the capability to initiate supervisory control action for any controllable device on any Operator display (Tabular displays or one-lines), given proper authorization. Supervisory control action shall be initiated using a confirmation-of-selection, prior-to-execution technique. Initiation of the control execute step shall occur after the Operator confirms that the correct point and control action have been selected. Following Operator initiation of the control execute step, the SCADA/EMS shall send control message sequences to address the RTU, obtain verification that the correct point has been selected at the RTU, and then execute the control action. In addition, the SCADA/EMS shall recognize differences in device response times (control timeout), and shall provide indication to the System Operator that a control action is in progress. At the completion of the control message exchange sequence, the SCADA/EMS shall report whether the result of the control action with the RTU was completed successfully, or whether the device failed to operate. The SCADA/EMS verification that an Operator initiated control action response has successfully occurred shall be accomplished by monitoring the appropriate indications for the commanded change. At a minimum the control timeout period shall be individually changeable by the user for each controllable point over a two second to one minute range. 2.4.2 LOAD TAP CHANGING TRANSFORMERS Each load tap changing transformer (LTC) shall have two supervisory control points. One point is the Auto (ON)/Manual (OFF) control point for the LTCs local control circuitry. The second point is the Raise/Lower control point for tap position. The LTCs local control logic shall inhibit any raise/lower supervisory control attempted while the local control is in the AUTO or ON position. The SCADA/EMS is not required to recognize or react to this inhibit feature. The tap position control shall be initiated using the confirmation-of-selection, prior-to-execution procedure specified for switching devices. However, it shall be possible to command repeat raise or lower actions without re-selecting the device on the Operator display (Jog Supervisory Control). 2.4.3 CONTROL INHIBIT The SCADA/EMS shall provide the means to inhibit and to enable supervisory control of any controllable point or an entire RTU. In addition, the SCADA/EMS shall provide indication on Operator displays that a controllable point is in a control inhibit state. The control inhibit


indication shall be separate and distinct from the quality flag field for each point. An event message shall be generated each time a control inhibit is initiated or removed. 2.4.4 LOCAL OUTPUT POINTS The SCADA/EMS shall provide the capability for output of status and analog point values from the SCADA/EMS database to a local output device. The Local output device shall convert the status and analog values to the desired output signals as specified in Section 5. The selection of status and analog points to be output shall be user definable through standard data entry procedures. The SCADA/EMS shall output the selected status and analog point values at a 2-second rate through an efficient and reliable block output type message structure. 2.5 PERIODIC CALCULATIONS AND CONTROL The SCADA/EMS shall be able to perform the periodic calculations and control sequences as discussed below. The results shall be incorporated into the database such that the calculated data is indistinguishable (to other software) from telemetered data. 2.5.1 BUILT-IN FUNCTIONS The SCADA/EMS shall provide built-in power system calculation functions for such quantities as MVA, KVA, Power Factor, Amps, etc. that are computed from telemetered MW, MVAR, and KV values. 2.5.2 GENERALIZED CALCULATIONS The SCADA/EMS shall provide capabilities for Utilties to define generalized calculations. The calculations shall use database values as the arguments and simple arithmetic functions as the operations. The following calculation functions shall be provided, as a minimum, for use in generating analog and status calculated points:

1. Algebraic Operations a. Arithmetic operations: +, -, /, * b. Integer c. Modulo d. Exponential e. Sin, cos, tan (radians or degrees) f. Arc sin, arc cos, arc tan (radians or degrees) g. Square root h. Absolute value i. Xy (Exponentiation)

2. Sum, average, and maximum/minimum calculations 3. Boolean functions. These shall include as a minimum:

a. AND b. OR c. NOT d. XOR

4. Structured conditional statements using: a. IF, THEN, ELSE b. Logical operations (>, =>, =, =<, <,≠)


2.5.3 DATA AVERAGING The SCADA/EMS shall provide a calculation function for computing the average value of a database value over a specified time period (i.e. hourly), having fixed start and end points with respect to system time. An appropriate tag shall be attached to any average for, which the database was not being updated for an interval of time exceeding a user adjustable percentage of the period. This function would typically be used for computing integrated MWH and MVARH values produced by integrating telemetered MW and MVAR values. 2.5.4 MINIMUM/MAXIMUM The SCADA/EMS shall provide a calculation function for computing the minimum or maximum, or both, of a database value (calculated or telemetered) during a given time period fixed with respect to system time. The min/max processing shall include the date and time stamp of when the min/max was detected. The Contractor shall provide a description of his proposed method to detect minimum and maximum values. 2.5.5 METER ERROR The Contractor shall provide a calculation function or facility for meter error monitoring for, which Utilties can utilize to compare selected MWH and MVARH telemetered pulse accumulator measurements with the periodic calculated MWH and MVARH integrated values. The function shall calculate the absolute magnitude of the difference between the integrated IN and OUT MWH values and associated telemetered IN and OUT MWH values. An alarm shall be generated if the difference between any integrated and associated telemetered IN and OUT MWH value exceeds a user entered value. The meter error alarm shall be inhibited if an insufficient number of samples have been received for the integration calculation. The Contractor shall provide database entry procedures for adding or deleting points from the meter error monitoring function. 2.5.6 AUTOMATED CONTROL SEQUENCES The SCADA/EMS shall provide a periodic calculation and control function that permits the user to construct an automated control sequence. The function shall test a user specified status or analog point in the SCADA/EMS against a predefined value and to initiate a control to a SCADA point if the test condition is satisfied. The function shall report appropriate event report messages for any control action. 2.6 ALARM PROCESSING The SCADA/EMS shall have the capability of notifying operators of abnormal conditions, required operator intervention or informational system messages. All alarms shall be tied to specific Areas of Responsibility (AOR). Only those alarms related to the specific area of responsibility of each operator shall be shown. Alarms shall consist of but not limited to:

Un-commanded changes of state of status points The failure of a device to respond to a supervisory control action Limit violations of telemetered or calculated values Failure of a critical system component such as a server Rate of change alarms that are based on user configurable values.


Rate of change alarm must show signed amount of change. I.e. Rate of change = current value – last scanned value.

Alarming of stale data. Stale data is defined as telemetered data that has not updated during a user configurable time frame.

Alarm subsystem connectivity monitoring Events shall consist of but not limited to:

Initiation of supervisory control actions Commanded changes of status points Return within limits by an analog value Manual request for system failover or restart Alarm acknowledgement with Operator Identification and timestamp. Operator logon, \logoff

Alarm and event messages shall be saved in an Alarm and event file when generated. The length of the message shall not exceed one printed or displayed line. Also, the message text shall be identical in both the printed and display form. Color, flashing, history retention, email and page attributes, and audible attributes shall be assigned to each alarm or event group to reflect the severity of the alarm or event and to identify whether the alarm or event is acknowledged or unacknowledged. Each alarm group shall be assigned an alarm priority (up to 8) that shall be used to filter the alarms on the various alarm summaries. Alarms and events must be written to the historical database. Alarms must be written out to the Pi historian. 2.6.1 ALARM AND EVENT USER INTERFACE Alarms and events shall be accessible to the operators through the alarm and event summary displays. Summaries shall be a filtered list sorted chronologically. The highest priority and most recent alarm shall be at the head of the list. Summaries for unacknowledged, acknowledged, and other sorted criteria shall exist. The SCADA/EMS shall provide the capability to perform alarm and event searches based on a set of search parameters or filters. An appropriate display shall be available where operators enter the search parameters and obtain the results of a search. 2.6.2 ALARM INTERACTION An Operator shall have the capability of inhibiting alarming for any point in which the Operator has the authority. When an alarm is inhibited, no alarm processing shall occur. The alarm inhibit data quality flag shall be placed on points in which alarming has been inhibited and these points shall be placed in the alarm inhibited summary display. It shall be possible to define a point for alarm inhibit in the database definition for the point. It shall be possible to acknowledge an alarm from any display on which the unacknowledged point or alarm message appears. Operators shall have the ability to acknowledge a single alarm, a page of alarms (such as a page on an alarm summary), or all alarms associated with a particular point. The Operator shall have the capability of deleting alarms either individually or by page. Alarms shall be configurable such that, when acknowledged, the alarm shall be removed from all


summaries and lists, or such that the acknowledged alarm shall remain active until the point has returned to a normal state. The SCADA/EMS shall not permit the deletion of unacknowledged alarms. Points that are in the alarm state shall appear in an off normal summary page. Alarm silencing must be available for any point that is in alarm. Silencing of alarms will be listed and recorded as an event. 2.6.3 ALARM SUPPRESSION The SCADA/EMS shall have the capability of defining a relationship between certain devices that can be used to suppress alarms from related devices or measurements. The relationship shall be defined in such a way as to establish a dependency between one device and others. An example of this relationship would be if a circuit breaker opens, without operator intervention, under voltage alarms associated with that breaker trip would be suppressed for a user defined period. This function shall be selectable by point. 2.6.4 ALARM INHIBIT The SCADA/EMS shall provide capabilities for the Operator to inhibit and enable alarm processing for any point or RTU without effecting the processing of the data. If an alarm condition is detected for a point for, which alarm processing has been inhibited, there shall occur no audible or visual annunciation, message printing or alarm indication on any Operator display. Normal alarm processing shall resume when the point alarm function is again enabled. An alarm inhibit quality code shall be attached to all points for which alarm processing has been inhibited. All points for which alarm processing has been inhibited shall be displayed on an alarm inhibit summary display. 2.6.5 TELEMETRY FAILURE A failure to receive valid data from a data source in response to a scan request command shall cause a software commanded retransmission of data from that source. The number of re-scans to be attempted shall be user adjustable for each scan rate. Manual replacement by Operator action shall be permitted for any telemetered or calculated point value, with database retaining the replacement value until data acquisition and processing of the point is resumed. Operator removal of any point or an entire data source from scan processing shall be permitted with retention of the last data received prior to scan processing suspension, until either scan processing is resumed, or a replacement value is entered by the Operator. Manual replacement displays that include all points with a current manual replaced value shall be provided. A quality code shall be maintained in the database for each telemetered or calculated data value. The quality code shall indicate whether the point is being scanned and the data is valid, the point is experiencing telemetry failure, the point is manually replaced, the point has been alarm or event inhibited, the point has an active alternate value, or the point has been removed from scan by the Operator. Calculated values shall have attached the most severe quality code associated with the data used in the calculation.


2.6.6 ALARM LOGGING Alarm logs shall constitute a soft-copy record saved in the historical database of all alarms, events, and significant operator actions. Alarm displays and alarm log entries shall include the date and time that the alarm was detected, the tag name and description of the alarmed point, and an entry describing the nature of the alarm. Alarms shall be logged on an alarm and event printer and saved in the historical database as they occur. Alarm data, both current and historical, shall be automatically restored to a recovering I/O server and shall not require an operator action for this to occur. 2.6.7 RESPONSES TO ALARMS An audible alarm shall sound at the operator's console at each occurrence of a new alarm event. The audible alarm shall be silenced when it is acknowledged by the operator. The audible alarm shall use an external sound system, such as a sound card and external speakers. 2.6.8 ALARM ENABLING Alarms originating from database entries such as discrete change of state or analog limit violations shall be enabled or disabled on a point-by-point basis. 2.6.9 ALARM NOTIFICATION A customizable alarm notification software package shall be provided. A licensed copy of the software shall be provided for each of the application servers. 3.0 HISTORIAN AND ONLINE DATABASE A commercial database based historian function shall be provided to allow collection of real-time data, archival, for subsequent reports, analysis, Energy Accounting or Data Archiving. The historian function shall provide the capabilities for Utilties to define the utilization of the data stored, including, as a minimum, archival period, printing, Operator display and calculations. A standard relational database management system (e.g. Oracle) shall be utilized as the core of this functionality. The historical database must be able to link to an OSI Soft Pi Historian through one of two means. 1. Through an ODBC compliant link that specifically address the following · Multiple table joins · Response times · Consistency of operations · What happens when the tables have blank lines imbedded in them? · String field length · What happens when the tables live on different machines? 2. Through an embedded OSI Soft Pi historian. These options should be priced separately.


3.1 DATA STORAGE AND ARCHIVAL The SCADA/EMS shall incorporate the OSI SOFT Pi historian and store data on a real time basis. The current historian is of two parts, an embedded Pi Historian and a Pi Data Warehouse in the DMZ. The new system must have connectivity to the existing Pi Data Warehouse in the DMZ. 3.2 DATA ARCHIVAL The SCADA/EMS shall be connected to an existing OSI SOFT Pi historian through an OBDC link or Pi to Pi interface. All data shall be updated to the Data Warehouse with a maximum lag of 15 seconds. 3.3 DATA DISPLAY AND MODIFICATION The historian function shall provide a convenient means for the System Operator to access the data, and by means of a data entry procedure, modify the stored data. The historian function shall also provide capabilities for the System Operator to modify quality codes as well as the data. Standard reporting tools using ODBC connectivity shall be used to access the historical information. Utilties prefers to use Access or Excel as a font-end client to view and update the historical data. 4.0 DATA LINKS The SCADA/EMS shall provide general ICCP and DNP Server data link capabilities as described in the following subsections. In addition, the SCADA/EMS shall have an interface to the WECC (LRCC), WAPA, (WACM), Xcel Energy (PSCo) and Tri State G&T (TSGT) 4.1 ICCP DATA LINK The SCADA/EMS shall have an ICCP data link subsystem to exchange data with other SCADA and SCADA/EMS systems. The ICCP data link shall provide the latest Block 1, 2 and 5 functions. The data link shall provide interactive database editors to define the points to be exchanged with each remote site. The points that can be selected for transfer shall include any status, analog, accumulator SCADA data and applications data. For each remote site, capability shall be provided to define the transfer rate for each group of points to be exchanged. At a minimum, each group of points shall be selectable for transfer at 2, 5, 10, 15, 30, 60-second rates as well as at 5, 15, 30, 60-minute rates. The data link shall process point quality codes for both incoming and outgoing SCADA point data. When a communications failure is detected for an incoming data set the point quality codes shall be set to indicate telemetry failure. The data link function shall provide for redundant operation allowing configuration of up to two communications paths with each remote site. One path shall be designated as a primary path and the second as a secondary path. The data link shall perform communications error monitoring and inform the System Operator of communications link failures with remote sites by issuing appropriate alarms. The data link interface shall have capability for System Operator control of up/down status for a remote site and for manual communications path selection (primary/secondary) to a remote site.


The Contractor will convert the ICCP database. The availably and impact of upgrading to Secure ICCP must be addressed. 4.2 DATABASE LINKS The system shall provide for links to other databases through Oracle or similar application. These links include but are not limited to: Water Information System Outage Management Systems Pi Historian Switching Databases 5.0 AUTOMATIC GENERATION CONTROL The AGC program shall regulate the power output of generators in response to changes in system frequency and tie-line loading, real-time system load, or the relation of these to each other, in order to maintain the scheduled system frequency, scheduled load profile and/or the established net interchange with other companies within predetermined limits. The AGC program shall support the electric single control area operations. 5.1 GENERAL CHARACTERISTICS The AGC program shall execute every 2 seconds, and shall compute and process an area control error (ACE). Unit control logic and the allocation of control to dispatch units shall execute at a rate between 2 and 4 seconds. The AGC ACE calculation control mode shall be selectable by the system operator via an appropriate operator display and at a minimum shall include control modes for constant frequency control, constant net interchange control and tie-line bias control. When in the constant net interchange and tie-line bias mode the AGC program shall have provisions for the system operator to enter a dynamic interchange schedule input value. This value is to be added to the net scheduled Interchange value from the interchange scheduling function to form the total interchange obligation component of the ACE equation. The AGC program shall have the capability to correct for inadvertent interchange. The inadvertent interchange correction function shall operate in either a scheduled payback mode or a no payback mode. The mode shall be selectable by the system operator. The scheduled payback mode shall be activated when a coordinated payback schedule with a control area has been agreed to per the requirements of the system operating guides. The no payback mode disables any inadvertent interchange payback. There shall be no requirement for an automatic payback mode of inadvertent interchange. Payback energy shall be classified as either on-peak or off-peak. The on-peak and off-peak time periods shall be user definable. The payback schedule used in the scheduled payback mode shall not be used in the calculation of inadvertent interchange during the payback period. 5.2 ACE PROCESSING The AGC program shall determine how much, if any, control action should be executed based on the characteristics of ACE/SCE. AGC monitoring and predictive logic shall consider ACE random


variations, integral of ACE, and feed-forward of known generation and interchange changes when AGC is operating permissively. Non-linear filtering techniques, which reduce control action, are required. The type of AGC control utilized shall be determined by comparing the ACE magnitude with certain user definable limits. For small values of ACE, AGC shall utilize command control and for intermediate values of ACE, AGC shall utilize permissive control. For large values of ACE, AGC shall utilize emergency assist action that shall bypass economic considerations and cause all regulating units operating in the On-Control mode to be moved in a direction to minimize ACE. The AGC program shall be capable of either raise/lower pulse outputs or set point output for control signals sent to generating unit controllers. 5.3 UNIT CONTROL MODES At a minimum, the AGC program shall have provisions for the following classes of dispatch units:

a) Not Available - The unit is out of service, and is unavailable to the System Operator.

b) Off Line - The unit is off-line, but available for normal service if needed.

c) Plant Control - The unit is on-line, but under the direct control of the plant operator due to such conditions as running heat rate tests, vibration tests or bringing the unit on-line while waiting for temperatures to stabilize.

d) Off Control - The unit is on-line and being manually loaded by the plant operator, and is

being dispatched economically.

e) On Control - The unit is controllable by the AGC program within the high/low regulating limit settings entered by the plant operator.

f) Fixed Load without Regulation - The unit is being controlled to an Operator entered base-

point and moved at an Operator entered ramp rate.

g) Fixed Load With Regulation - The unit is being controlled to an Operator entered base-point and moved at an Operator entered ramp rate, and participates in power system regulation based on its regulating participation factor.

h) Automatic Non-Regulating - The unit is being controlled to follow the load based on the

unit's economic base-point and economic participation factor calculated by the EDC. The unit does not participate in regulation.

i) Automatic - The unit is under full control of AGC to follow the load based on the unit's

economic base-point and economic participation factor, and participates in regulation based on its regulating participation factor.

The plant operator has the ability to place units on and off AGC control. The plant operator entered AGC control status shall be telemetered to the SCADA/EMS. It shall not be possible for the System Operator to place a unit in the on-control mode unless the plant operator has placed the unit on AGC control. When the plant operator takes a unit off AGC control, the SCADA/EMS shall automatically set the control mode to off-control. When a unit's breaker is open, the unit control mode shall be automatically set to off-line and the megawatt output shall be set to zero.


When the breaker of the unit in the off-line control mode is closed, the unit control mode shall be automatically set to plant control. 5.4 UNIT LIMITS The following unit limits shall be supported:

a) Total Capability - The total capability of the generating unit is the maximum maintainable output.

b) Regulating High Limit - This limit is the highest maintainable output with the equipment in

service at the time. The Plant Operators shall enter this limit. The AGC shall recognize this limit as an absolute high limit.

c) Economic High Limit - The AGC shall recognize this limit as a "soft" limit, representing the

upper limit of generator output during power system "normal" conditions, when economic constraints dominate the AGC control output execution. The System Operator shall enter this limit.

d) Economic Low Limit - The AGC shall recognize this limit as a "soft" limit, representing the

lower limit of generator output during power system "normal" conditions when economic constraints dominate the AGC control output execution. The System Operator shall enter this limit.

e) Regulating Low Limit - This limit is the lowest maintainable output with the equipment in

service at the time. The Plant Operators shall enter this limit. The AGC shall recognize this limit as an absolute low limit.

f) Low Capability Limit - This limit represents the minimum net generating capacity

maintainable without becoming unstable and being forced to shut down.

g) Response Limit - This limit represents the maximum sustained rate-of-change for the unit output.

h) AGC shall include control methods specific to wind generation, solar and hydro generating

units. The AGC shall perform a reasonability check of items a) through h) above to ensure that the relationship of entered values to each other are the same as the order in, which they are listed. If not, an alarm shall be generated and AGC control suspended for the unit until the limits are corrected. 5.5 UNIT DESIRED GENERATION The desired generation for each unit shall be computed as follows: UDG = UEDG + (UEPF * dG) + (URPF * ACE) Where, UDG = Unit Desired Generation UEDG = Unit Economic Desired Generation or manually-entered base-point UEPF = Unit Economic Participation Factor (computed by EDC program)


dG = Change in total generation since last run of ED URPF = Unit Regulating Participation Factor (shall be normalized based on units in Fixed Load with Regulation and Automatic control modes) ACE = Area Control Error The AGC shall model each unit's response characteristics to anticipate unit response and feedback full effects of control outputs. The model shall result in a reduction of control action outputs to each unit, thus avoiding overshoot. In addition, it shall provide the means for determining when a unit fails to respond. Unit dead-bands and other logic shall be utilized to avoid output change request smaller than the control resolution of units, while ensuring control errors do not accumulate. 5.6 AGC CONTROL SUSPENSION The AGC function shall provide automatic initiation of AGC control suspension for a single unit when data cannot be collected from a unit or data indicates the unit is not responding for a period of time exceeding a user adjustable time limit for the unit. The control mode of the offending unit shall be automatically set to off-control and an alarm shall be generated. An AGC control trip shall require manual intervention to restore control. The AGC function shall also provide automatic initiation of AGC control suspension for all units when excessive frequency deviations occur (magnitude of deviation shall be user adjustable) or when excessive ACE magnitude occurs (magnitude of deviation shall be user adjustable. In addition, AGC Control suspension shall occur for telemetry failure of any tie-line (except in constant frequency control mode), or for failure of the primary frequency source (except in constant net interchange control mode). The AGC program shall use a time-out limit for these failed telemetry values before suspending. The time-out limit shall be user adjustable. Automatic tripping shall be prevented and AGC control resumed (with appropriate messages describing all events) if the telemetry becomes valid prior to time-out, the System Operator enters a replacement value, or the System Operator selects a redundant source for telemetry. 5.7. AGC PERFORMANCE ANALYSIS The AGC program shall provide control performance monitoring capabilities based on the current NERC Control Performance Criteria CPS 1 and CPS 2. The AGC program shall also provide the BAAL control performance monitoring capability. In addition the AGC program shall maintain statistics for an AGC performance report that includes how long the AGC program was active and on-control during the past 24 hour period and how long it was in monitor mode, or unavailable. The AGC program shall store the performance statistics on a daily basis in the historian database. 5.8 ECONOMIC DISPATCH The Economic Dispatch (ED) program shall allocate total generation among available dispatch units in such a manner as to optimize a selected system variable as described below. The basic ED algorithm shall minimize the incremental cost of power delivered to meet power system load using unit incremental heat rate (IHR) curves, fuel costs and transmission loss penalty factors.


The ED program shall have the capability to optimize other parameters when expressed in economic terms such as transmission losses, environmental constraints, transmission constraints, or total fuel input. The ED program shall execute every five minutes, or upon the occurrence of any of the following conditions:

a) Significant change in power system load. b) Change in any generating unit control mode. c) Change in any generating unit limit. d) When a new IHR curve is selected for any unit. e) When a new B-matrix is selected. f) System Operator request.

In addition to calculating the incremental cost for each unit, the ED program shall calculate a generation plant incremental cost. The unit incremental cost (UIC) and system incremental cost shall be available for operator displays, calculating variables and for producing reports. 5.9 PENALTY FACTORS ED shall use generator Penalty Factors derived by the Real-time Network Analysis function (if available) or a static set as entered in the database to account for transmission losses. 5.10 UNIT INCREMENTAL HEAT RATE CURVES The incremental heat rate (IHR) curve of each generating unit shall be represented by either a multiple straight-line segments (10 segments, minimum), or by second-order polynomial approximations. The ED function shall support a minimum of four (4) IHR curves for each generating unit and shall allow on-line System Operator selection of the curve as well as automatic switching of curves based on defined criteria. 5.11 INTERCHANGE TRANSACTION SCHEDULING The Interchange Transaction Scheduling (ITS) function shall provide the System Operator with capabilities for entering and maintaining schedules for power system interchange energy with neighboring utilities and for the periodic calculation of total scheduled net interchange for use by the AGC function. The ITS function shall provide the capability for entry of an interchange schedule with permissible start times from immediate to within 30 days of the current day. The function shall have the capability to define schedules with different schedule types and different utilities. Error checking of all altered and/or newly entered data shall be provided. The schedule types and utility identifiers shall be definable by the user through database entry procedures. Modification of both inactive and active schedules shall be provided. Pre-start deletion of scheduled interchanges shall be allowed and termination of scheduled interchanges by AGC automatic action, which shall be subject to manual override by the System Operator for an immediate termination.


The ITS function shall provide schedule file management features that maintains all schedules presently in progress and all transactions scheduled, but not yet started. Completed schedules shall be stored for use by the historical information storage and reporting software. The ITS function shall provide the capability to import/export transaction schedules in XML format. The ITS function shall provide the capability to import (retrieve) schedule information from an e-Tagging system. 5.12 ITS SCHEDULE ENTRY Schedule entry default values, changeable by the user, shall be permitted in order to minimize the time required to enter or modify a schedule. In addition, the System Operator shall be provided the capability to save a schedule action and, by changing the date of the save case, define a new schedule. The ITS program shall be able to accommodate switchover to/from Daylight Saving Time. New transaction entries and modifications to existing transactions (not-yet-active and active) shall require the System Operator inputs listed below. Default values and re-entry of save cases as described above shall be permitted in order to facilitate the following System Operator input requirements.

a) Schedule number b) Transaction date (month and day) c) Utility name (four character abbreviation) d) Transaction type (four character abbreviation) e) Purchase/Sale indication f) Transaction value in MW g) Cost value ($XXX.XXX per MWH) h) Start time (HHMM - 24 hour format) i) Stop time (HHMM - 24 hour format) j) Start/Stop ramp

5.13 ITS DISPLAYS The Contractor shall provide, as a minimum, the following ITS entry and review displays described in this section in order to provide the System Operator with the capability to execute, in a convenient manner, the required ITS functions and features. An ITS index display shall be provided that contains a tabular listing of all Companies schedules that have been entered in the ITS system. The entries shall be arranged such that only one page is required. Cursor select fields shall be provided for the purpose of selecting individual company ITS displays described below and the active ITS display also described below. The ITS index display shall be retrieved by selecting a cursor target or depressing a software defined pushbutton. An ITS company display shall be provided that allows the display of all entered schedules for each company, regardless of schedule type. Each company display shall be capable of presenting the interchange schedules each with the full complement of Operator input data described above. An 'active flag' shall be attached to each schedule currently active. A ITS active display shall be provided that presents all schedules currently active (regardless of company or schedule type), grouped on the basis of company, with each company group ordered


by schedule number. The schedules displayed shall correspond to those schedules tagged with the active flags on the ITS Company displays. The displayed data and format shall be similar to that provided for the ITS company displays, except there is no requirement for data entry fields on the active ITS displays. The ITS active displays shall be retrieved by either cursor selection from the its index display, or by depressing a software defined pushbutton. 5.14 EMERGENCY NET INTERCHANGE SCHEDULE During power system emergencies the System Operator shall be able to override all interchange schedules with a single manually entered emergency net interchange schedule. The emergency schedule entry shall include an Emergency Net Interchange value, and a ramp rate. The AGC System shall ramp to the emergency net interchange value. 5.15 INADVERTENT INTERCHANGE Inadvertent (unscheduled) net interchange, defined as the difference between actual net interchange and scheduled net interchange, shall be computed hourly. This is only applicable for the constant net interchange and tie-line bias mode of AGC operations and not with the ISO. Actual net interchange shall be calculated as the algebraic sum of all telemetered and manually entered tie point interchange values. Scheduled net interchange shall be calculated as the algebraic sum of individual company interchange schedules provided by the ITS function, excluding inadvertent payback schedules. The System Operator shall be able to modify the value of inadvertent net interchange calculated as defined above, by modifying the integrated values of individual Company interchange schedules stored by the historian. The objective of the schedule and inadvertent modification is to provide the System Operator with a convenient means to account for, and ensure future mutual satisfaction of schedules not completed as initially agreed, due to unforeseen changes in system conditions. The modified inadvertent net interchange value shall be made available to the AGC function for inadvertent payback. The Inadvertent Interchange program shall provide the following for display to the System Operator:

a) On-Peak and Off-Peak accumulations of net inadvertent interchange to the end of the last hour.

b) On-Peak and Off-Peak net inadvertent interchange at the previous midnight.

c) Net inadvertent interchange for the current day to the end of the last hour. Each of the data described above shall be subject to modification by the System Operator as described above. On-Peak and Off-Peak clock hours shall be user definable. 5.16 PRODUCTION COSTING The purpose of the production cost function shall be to calculate the hourly production cost for each generating unit, using data collected following each execution of the economic dispatch


program. Three sets of production cost data shall be calculated. The ‘actual cost’ data shall be calculated from the real time data output of the economic dispatch function. The production cost function output shall include the following:

a) Production cost (in dollars/hours) for each unit, and the power system b) Incremental cost (in dollars/MWH) for each unit, and the power system

All the output data shall be displayed on a set of Operator displays and shall be retained for historical retrieval and report generation. 5.17 RESERVE MONITORING The reserve monitoring (RM) function shall calculate and monitor the spinning reserves quantities for the power system generation units. The function shall calculate the unit “spinning reserve” defined as the difference between the unit regulating high limit and the unit actual generation output. The unit “spinning reserve” must be limited by the unit response capability for the specific reserve time period. The RM function shall calculate the system total spinning reserve. The reserve calculation function shall calculate, display and alarm any deficiency in the total required spinning reserve. The system operator shall be able to set the total required spinning reserve value by normal data entry procedures. The system spinning reserve shall be calculated and compared to this system operator entered value at each program execution cycle. Any deficiency in the r spinning reserve shall generate an alarm. The RM function shall provide a flag for each generating unit indicating whether the generating unit is to be included in the reserve calculations. In addition, the function shall utilize the AGC unit control modes to further determine if a unit is to be included in the calculations (only ‘on-line’ units shall be included). The RM function shall maintain for display to the System Operator on an appropriate Operator display, an updated summary listing of all RM flags and calculated data including unit control modes, unit generation output and unit limits. 5.18 SHORT-TERM LOAD FORECAST (STLF) The purpose of the short-term load forecasting function shall be to prepare weather dependent load forecasts for up to 168 hours (one week) into the future for use by the Unit Commitment /Transaction Evaluation (UC/TE) function and other SCADA/EMS functions. The Contractor supplied program shall be adaptive, such that periodically and automatically, the weather sensitive load model(s) shall be adjusted on the basis of a statistical analysis of historical data. The historical data shall comprise forecasted load, actual load and associated weather data. The model(s) adjustment shall minimize the error between loads forecasted using the model and actual loads. The load forecasting function output shall include the following:

a) Forecasted load base component (non-weather-sensitive) for each hour of the forecast period b) Forecasted weather sensitive load component for each hour of the forecast period c) Historical data, including weather parameters, forecasted load and actual load d) Anomalous load behavior

The System Operator shall be able to initiate program execution on demand. Mandatory System Operator input shall be limited to designation of the forecast period and the forecasted weather parameters over the same period. The program shall recognize default weather forecast parameters (user changeable) in order to permit the System Operator to enter any or none of the permissible


weather forecast entries for the designated forecast period. The System Operator shall also be provided the capability to modify input and output program data. The capability to maintain and update (as described above) different load models, for example, Saturdays, Sundays, Mondays, Weekdays, and Holidays. The user shall be able to modify the weather sensitive load model tuning parameters. The load forecasting function shall also support a "similar day" mode of operation. The forecast for a particular day shall be developed by comparing the user specified load and weather pattern for that day (i.e., the model of the day) to the historical database and selecting the historical day whose load and weather patterns best matches the pattern specified (predicted) for the actual day. The STLF should model a single day in terms of its hourly load and the four weather variables, temperature, humidity, wind speed, and cloud cover. The historical database contains this load and weather information for each day of the year, for up to two (2) years. This data shall be stored in database tables by date and day type. In order to obtain a forecast for one or more days, the user must specify the load and weather data described above for each day to be forecasted and any search restrictions. The historical database search can be restricted based on any combination of years, months, and day types. The user can specify, for example, that the similar day matching scheme be restricted to one or more day types instead of comparing the predicted load and weather patterns to all day types in the historical database. The search restrictions should be independently specified for each day to be forecasted. Load forecast function shall allow the following user modifications:

a) Addition of a constant b) Multiplication by a constant c) Specification of new daily peak

5.19 UNIT COMMITMENT/TRANSACTION EVALUATION The purpose of the Unit Commitment/Transaction Evaluation (UC/TE) function shall be to select the combination of generating units that shall supply the Utilties load requirements over a future period of time, at minimum total cost and/or maximized profit, and to satisfy the minimum requirements for responsive spinning reserve or other constraints, as well as providing Economy A and Economy B Transaction Evaluation capability. The UC/TE function shall be executed upon System Operator demand. In addition, the UC/TE function shall provide a start-up and shutdown schedule for generating units over the period covered by the study. The study period shall not exceed 168 hours (one week) in duration. The method utilized to determine an economic commitment of generating units to satisfy the load level specified for the study period, shall provide for recognition of the following commitment constraints:

a) Unit start-up and shutdown cost, b) Operating rules, e.g., minimum run time and minimum shutdown time, c) Each unit’s commitment limits, d) Plant start-up labor constraints, e) De-rated units, f) Units out for maintenance, g) Units becoming available during the study period.


The Contractor is encouraged to propose additional constraints for use by the UC/TE program that would enhance operations in Rocky Mountain Reserve Group (RMRG). In addition, the UC/TE function shall require the input of various power system operating data for program execution. This data shall include the System load forecast, the Spinning Reserve Requirement, the Scheduled interchange transactions, the Generation maintenance schedule (including forced outages and unit de-rations), and the recent history of each generator. The UC/TE function shall recognize, as a minimum, four mutually exclusive classes of units. The first unit class is ‘Unavailable’ in, which the unit must be scheduled to be off-line. The second is ‘Must Run’ in, which must be on-line. The third is ‘Fixed Units’ in, which the unit must be operated at a System Operator designated load point. The fourth class is ‘Cycling Units’ in, which the unit is available for start-up and shutdown as required by the program. In order to reduce the System Operator effort required to set up a commitment case, default values for all input data shall be defined by the user. All data shall be displayed and changeable by System Operator entry. The UC/TE function shall support a minimum number of 50 save cases. The UC/TE program shall run to conclusion, even if power constraints (over or under generation) or reserve requirements cannot be satisfied. The UC/TE function shall flag such problems and report the problem in terms of MW and time. 5.20 SECURITY ANALYSIS APPLICATIONS (OPTION) The requirements of Section 5.20 are to be bid as an option and shall include all hardware and software needed to support the requirements defined. The Security Applications shall be sized to meet the requirements of Appendix A System Sizing. The Security Applications shall provide an integrated group of functions that collectively aid the electric System Operators in continually assessing the general security of the electric system. These functions shall include the following:

Network Topology Processor State Estimator Power Flow Penalty Factor Calculation Contingency Analysis.

The applications shall be fully integrated from the point of view of information exchange between the functions and the user interface. A control capability shall be provided which coordinates the execution of the combined security assessment functions on the occurrence of specific events including:

Changes in network topology, e.g., the outage (either scheduled or forced) of a line or of a transformer Sudden and significant changes in the electric system load Change of transformer tap settings Reactivation of RTUs and/or communication channels Dispatcher request of security assessment functions


The security assessment shall be executed in both real-time and study mode. Execution in real-time shall make use of real-time data to reflect current network conditions. Execution in the study mode shall be based on operator defined power system states. The study mode analysis shall involve only power flow and contingency analysis. 5.21 NETWORK TOPOLOGY PROCESSOR The network topology function shall determine the current configuration of the power system network based on the state of circuit breakers and disconnect switches obtained from the real-time data and from manually entered status information for devices not telemetered. The network configuration function shall handle any general breaker configuration without requiring special user description. The input to the network configuration function shall consist of real-time data and manually entered information. The real-time inputs to the function include the status of circuit breakers, transformer tap settings and selected disconnect switches. Manually entered inputs shall include the status of non-telemetered devices, and device status changes that are not available in the real-time database because of telemetry failures. The output of the network topology function shall be the actual bus oriented model of the power system network. The output shall be placed in the database where it shall be available as input to other functions, for single-line or tabular displays, and for reports and/or reports. The function shall be executed whenever there is a status change detected either in real-time or by manually entered status changes. Provisions shall be made to execute the function periodically, in conjunction with other security functions, or manually, upon operator request. The request for execution of the network configuration function shall be inhibited during switching operations until the system has reached a steady state condition or the switching sequence has been completed. 5.22 STATE ESTIMATOR The state estimation function shall compute a complete power flow solution of the system. The state estimate shall minimize the sum of weighted least squares of the deviations between the measured values and the computed values. The solution technique shall be based on the full weighted least squares or Givens Rotations algorithm and shall use, to the maximum extent, available measurements, pseudo-measurements and manually entered data. Features of the state estimation function shall include:

Input pre-filtering Bad data detection and identification Measurement error analysis which can be executed on demand The ability to determine the extent of the observable network based on the available

measurements. The input data required by the state estimation function shall consist of real-time analog measurements including, where available, real and reactive bus injected power, real and reactive line flows, bus voltage magnitudes, and the current bus oriented model of the observable and unobservable portion of the power system network. Manually entered data pertaining to non-telemetered facilities shall also be used.


The output of the state estimation shall consist of a complete solution for the observable unobservable portions of the power system network including bus voltage magnitudes and angles, real and reactive power flows, and bus real and reactive power injections. The results shall be stored in a format that is directly usable by other application functions or displays requiring state-estimated data. The state estimation shall be executed for any change in the model of the power system network as detected by the network topology function, or periodically, that is, when the elapsed time since the last execution exceeds a pre-specified value, (e.g., every ten minutes), or upon operator request. 5.23 POWER FLOW The power flow function shall calculate bus voltage magnitudes and angles, real and reactive line and transformer power flows, and real and reactive bus power injections in the power system network. Features to be included for the Power Flow function include:

Availability of a full array of change case capabilities including load changes and outages or additions of transmission facilities

The use of a fast decoupled and fully coupled Newton-Raphson solution technique Provisions for storing and accessing study cases Execution by operator request only

The input data required for the execution of the power flow shall consist of stored resident cases or solved cases from the output of the state estimator or contingency analysis function. The output of the power flow shall be stored in the database for subsequent use by other functions, displaying on displays, or for logging. 5.24 PENALTY FACTOR CALCULATION The penalty factor calculation shall compute real-time and study loss penalty factors for all generating buses for use by generation scheduling functions of the SCADA/EMS including AGC/ED, and UC. A set of study penalty factors shall be computed for various load and interchange profile, and stored for use by the UC/TE function. 5.25 CONTINGENCY ANALYSIS The contingency analysis function shall simulate a list of power system contingency outages and solve each one using a load flow algorithm, reporting all violations as a result of the contingency. The input to the contingency analysis program shall be the latest real-time state estimator solution or a solved load flow study case. For a large number of contingencies, a pre-screening or selection algorithm is needed to perform a fast and crude screening of all voltage and flow violations, and hand off only suspected contingencies for a full load flow simulation. The contingency selection algorithm shall be based on a minimum iteration AC load flow technique or an equivalent AC technique. Results of the contingency analysis shall be available in tabular and graphics format.


5.26 SECURITY ANALYSIS APPLICATIONS USER INTERFACE A set of control and result displays, shall be provided to permit flexible interaction by the operator with the Security Applications including:

Data input Summary of results Study case management Execution control Execution monitoring.

Displays shall be comprehensive, logical, and user friendly. Results of the solution shall be presented on single-line diagrams as well as dynamically built tabular displays. Operator interaction with running load flow studies shall be via one-line diagrams. Only one set of one-line diagrams need to be maintained between SCADA and Security Applications for ease of maintenance. 5.27 DISPATCHER TRAINING SIMULATOR (OPTION) The Dispatcher Training Simulator (DTS) shall provide a realistic, hands-on training environment for new and existing Power Dispatchers. In this respect, the trainee may use a dedicated DTS trainee console and be supported by a trainer (instructor) seated at a dedicated DTS trainer console. Alternatively, using any Dispatcher console to be supplied with the SCADA/AGC, the trainee may operate in a self-training mode. This requires the trainee to switch the console to the proper training context. Using DTS facilities, it shall also be possible for one or more dispatchers (such as the Generation and Scheduling Dispatchers) to train together using a common DTS training session. 5.28 FEATURES AND CAPABILITIES DTS (OPTION) The DTS shall include, but shall not be limited to, the following additional features and capabilities:

Creation of training scenarios from pre-stored load curves and event groups, where event groups consist of one or more events occurring at the same time, at different times, or in accordance with other events and power system conditions. Definition of events such as a change of bus load, change of system load, circuit breaker trip/close, line faults resulting in recloser lockout and fault indications at one or more load break switches, loss of RTU data, equipment alarms, etc. Creation, application, and omission of events during an on-going training session without interruption of the training session. Creation of base cases from snapshots and ability to save base cases for later use. DTS initialization from a saved DTS base case. Snapshot review and resume, where a snapshot is used to re-initialize the DTS for review and, at the discretion of the user, to re-start simulation from the snapshot.


The DTS shall provide the trainee a realistic and complete replication of real time system operation. Watermarking on the display background shall indicate to the trainee that he is not in the actual real time system however; all other interactions including advance applications shall be available and act just as if the trainee was in the real time environment 6.0 SYSTEM CONFIGURATION REQUIREMENTS The SCADA/EMS configuration shall be of a cost-effective design and shall possess a high degree of availability, maintainability, dependability, operating effectiveness, and expandability during actual operation. 6.1 OPEN SYSTEMS REQUIREMENTS The configuration of the SCADA/EMS shall have a distributed computing environment with open system architecture. To be recognized as a true open computer system, all internal communications among the SCADA/EMS System processors and all external communications between the SCADA/EMS System and other computer systems shall be based on widely accepted and published international or industry standards, which are appropriate and relevant to the open systems concept. This applies to the operating system, database management system, and display management system, as well as to APIs providing standardized interfacing between systems software and application software. The following design concepts shall be met:

1. The SCADA/EMS configuration shall be based on Open Systems Standards in which the software is totally transparent of the hardware such that any hardware adhering to these standards can be replaced/upgraded with a functionally similar device not necessarily manufactured by the original manufacturer.

2. The SCADA/EMS must be field operational on at least 2 distinct hardware makes and models and 2 distinct operating systems.

3. Major subsystems shall be distributed to different sets of processors, such as SCADA processors, Application processors, and User Interface consoles.

4. All processing units of the SCADA/EMS System shall be interconnected using industry standard Local Area Networks (LANs). The LANs shall support exchange of data from the various system components to include: processors and servers, user consoles, communications processors, terminals, gateways, any stand-alone disks and tape drives, etc.

5. The same revision of a widely accepted operating system shall be used. For Intel-based processors, the Microsoft Windows™ operating system shall be used.

6. All software shall be written in a single cohesive, standard ANSI high-level language. The SCADA/EMS System shall be designed to provide the highest possible level of hardware and software independence through the use of standard products, the use of standard toolkits, and through application modularity.

7. Expandability shall be provided through the use of a hardware and software platform that allows for vertical growth, and a configuration that allows horizontal growth and distributed computer/server support.

6.2 AVAILABILITY The availability design criteria for the SCADA/EMS shall be such that a single component failure shall not cause the loss of any critical system function. For all devices having a high failure rate or


a potentially long repair time, multiple device failures shall not cause the loss of any critical system function. For example, a configuration is desired that permits redundant server computers to operate with a high availability disk drive system for storage of critical System Database using RAID technology. The SCADA/EMS shall have an overall system availability of 99.95% The Contractor shall demonstrate the availability over an extended period of actual system operation (Availability Test). In addition to the availability described above, the Contractor shall provide capability for extensive means of failure and pre-failure detection and automatic substitution of backup devices in order to achieve the required availability level. The availability is defined as RUNTIME / (RUNTIME + DOWNTIME) x 100% Where, RUNTIME shall be the Availability Test time. The SCADA/EMS shall be considered available when the following critical System functions are performing as specified:

Data Acquisition Supervisory Control AGC/ED Data-links User Interface – how many consoles? Historian functionality Network Applications?

6.3 MAINTAINABILITY Following system failure detection, the cause shall be promptly isolated and corrected. As an aid to the diagnosis and correction of hardware problems, the system design shall permit the execution of diagnostic programs with the SCADA/EMS either on-line or off-line. The operation of on-line diagnostics shall not degrade any critical system functions except for device(s) under test or device(s) used in testing. Off-line system maintenance shall utilize off-line diagnostics (provided by Contractor). Off-line diagnostics shall support complete maintenance of all hardware elements and the diagnosis and isolation of any hardware fault. The level of system repair to be undertaken by Utilties maintenance personnel shall be at the unit replacement level or circuit board level for user maintainable hardware. The Contractor's regularly scheduled maintenance training classes shall provide the training of Utilties maintenance personnel in the use of the off-line diagnostics. 6.4 SYSTEM CONFIGURATION The master station shall consist of redundant servers and workstation computers. The server and workstation computers shall have at least a 32-bit (minimum) processor sufficient to perform the system functions and may consist of multiple processors. The proposed servers and workstations shall support a minimum of two local area networks (LANs), multiple large capacity disk and tape drives, large RAM capability and high I/O throughput. Network access equipment such as routers, terminal servers, print servers, etc., shall utilize 100 Base-T network connections.


All servers shall be of industrial grade rack-mount with multiple processor capability. Under normal operating conditions, the SCADA/EMS shall operate with one set of server computers performing real-time functions (Primary System) with the other set of server computers acting as backup (Backup System). In the event of a Primary System failure, the Backup System shall perform all assigned critical system functions without degradation in response times and performance. The functional requirements of each constituent part of the system, presented in the following sections, are provided in order to enable the Contractor to configure the hardware in a matter, which shall provide Utilties with the most cost effective system. The number of peripheral devices indicated in the SOW is based on a redundant system configuration. The SCADA/EMS architecture must include a minimum of 2 LANs and have the ability to be expanded to at least 4 LANs with each LAN supported by its own dedicated LAN hardware card. All LAN hardware shall utilize 100BaseT technology. As a minimum, the servers and workstations must be configured with redundant LAN hardware that shall allow them to communicate concurrently and independently over 2 LANs. The dual LANs shall provide redundancy for high availability. The SCADA/EMS architecture shall be capable of using dynamic traffic balancing techniques to distribute LAN traffic. The Contractor shall describe how the proposed SCADA/EMS accomplishes this and if any additional hardware or software is required. If the Contractor utilizes Front End Processors or RTU servers via a LAN then a separate dedicated LAN shall be provided between these devices and the Primary and Backup System servers. The front end processor or RTU server LAN shall not support other non-real-time communications. The Consoles to be provided shall be for desktop or suitable facility mounting on Utilties provided desk or table or suitable facility. Servers should be rack-mounted in Utilities-provided cabinets. 7.0 USER INTERFACE REQUIREMENTS The User Interface (UI) shall provide a common “look and feel” interface for all users to interact with the SCADA/EMS. All applications, which utilize one-line diagrams (e.g. SCADA, Security Analysis), shall use the same set of one-line diagrams thus minimizing system maintenance as well as maintaining consistency of use for operators, engineers and other users.\ 7.1 USER INTERFACE CONSOLES The primary User Interface between the SCADA/EMS and the user shall be workstation-based consoles. Each console shall be assigned to one or more function partition (Areas of Responsibility), thus limiting the console Operator to only those actions defined within the assigned function partition(s). All defined function partitions shall be assignable to a single or multiple consoles. 7.2 GENERAL UI REQUIREMENTS


The following types of displays shall be supported:

1. One-line diagrams of generating units, power transmission lines, sub-transmission lines, substations, switches and distribution circuits,

2. Tabular displays, many of which also include imbedded graphical data representations,

3. List based/query based displays.

4. Graphical displays of circuits and components including, but not limited to photographs and geographical maps.

5. Graphic to include normal gas and water objects.

A Windows based Full Graphics User Interface system shall be provided which adheres to the Microsoft Windows standards. The following minimum functionality shall be supported:

1. World coordinate system based displays

2. Panning

3. Zooming

4. Decluttering

5. Multiple windows per monitor

6. Navigation window

7. Scrolling

8. Page based tabular displays

9. Support for bit-map pictures

10. Support for a large number of Electrical symbols

11. Support for overlays of geographic information

12. DXF import and export

13. 256 Colors

14. Blinking colors

15. Post it notes

16. Control and data entry dialogs

17. On-line help facilities

18. Dynamic database linkages for value

19. Dynamic database linkages for color

20. Dynamic database linkages for object shape or line thickness

21. Multiple font types and font sizes

22. Support page data entry on tabular displays

23. Ability to support serving of displays via a standard Web browser The UI shall provide a symbolized and/or color-coded “quality” indicator field associated with each dynamic data field. In cases where a multi-quality condition develops for a single variable,


the Contractor shall provide a priority scheme for determining, which condition should be displayed. A blank quality field shall be used for data quality condition in the ‘Good’ state. The UI shall provide symbolized indications for denoting those points for, which control has been inhibited. The control inhibit indicators shall be different from the quality codes described in the previous paragraph. In addition each control inhibit indicator shall alter the color of the device to, which the indicator is attached. The UI shall provide operator guidance for all user interfaces by utilizing feedback for each step of a multi-step procedure through the use of text messages, color changes, blinking, cursor targets, or dialog boxes with soft push buttons to denote permissible options. Feedback shall be provided for all user inputs whether accepted or not accepted. All display screen targets shall be cursor selectable. The term “display screen targets" are defined as areas of each display screen format for, which interactive functions have been defined. The cursor positioning methods shall include the use of forward and backward tab keys, pointing device and cursor control keys. The UI shall provide for extensive error checking of all user entries. Invalid entries (e.g., entering an invalid point value or an illogical sequence of actions) shall be reported to the user on the display screen by an error message that shall be in plain English with no acknowledgement required or reference document required for interpretation. In addition, the invalid entries shall be highlighted. The UI shall provide the capability to correct an error without requiring the entry of data or the performance of actions that were correctly executed prior to the error. Each point in the database including calculated and non-telemetered points shall be assignable to a single partition by the user. For each point assigned to a partition, all permissible operator actions including supervisory control, data entry, alarm control, etc., defined for that point, shall be restricted to only those consoles, which have been assigned the same partition to, which the point has been assigned. Any attempt to select a point for Operator action not assigned to the consoles assigned partition shall result in an error message on the display screen. Hardcopy messages, e.g., alarm and data entry messages for a point shall be printed only on those printers that have been assigned the point’s assigned partition. RTU communications control shall be assigned to partitions that are user configurable to limit the control of communications and all other actions associated with the RTU to only those operators within the area of responsibility. Only consoles with the appropriately assigned console function partition may be permitted to request and view a display that has been defined for that function partition. Methods for user selection of displays must be rapid, convenient and reliable and shall include cursor selection of a display select target area on any display screen format, including menu, graphic and tabular displays. In addition, cursor selection of an alarm message on any alarm summary display or on the alarm lines followed by actuation of a display request pushbutton shall cause a pre-selected display for the point in alarm to appear on the display screen. The UI shall also allow user selection of a display by pressing a dedicated display request pushbutton (hard or soft key). Displays to be selectable by this means shall include but are not limited to menu displays, overview displays and alarm summary displays. Paging through multi-page displays by means of page forward and page backward pushbuttons shall be provided. Display paging shall be user definable by standard display editing procedures. The UI shall provide for a display recall pushbutton that shall cause the display that was on view immediately prior to the current display to be recalled. Displays shall also be accessible by


entering a display identifier. The identifier shall be user definable through standard display editing procedures and shall consist of alphanumeric characters. 7.2. SUPERVISORY CONTROL The UI function shall provide the System Operators with secure interactive procedures that allow performance of the supervisory control functions. As a minimum the following dedicated buttons shall be supported:

a) Open/Off/Manual b) Close/On/Auto c) Execute d) Cancel e) Raise f) Lower g) Tagging h) Control inhibit i) Remote local

Summary displays shall be provided by the SCADA/EMS to include, but not limited to the following: Off-Normal Summary, Out-Of-Scan Summary, Alarm Inhibit Summary, Control Inhibit Summary and Alarm/Event History Summary. The System Operator shall have the capability to initiate supervisory control action for any controllable device on any display the device appears except from the Off-Normal Summary, Out-Of-Scan Summary, Alarm Inhibit Summary, Control Inhibit Summary and the Alarm/Event History Summary displays. Any Operator initiated supervisory control actions shall be by either Select before Operate (SBO), or by Jog supervisory control. The System Operator may cancel a requested supervisory control action at any time prior to depressing or selecting the Execute function pushbutton. For the SBO technique, the user selects the device intended for control action and then depresses the desired control action function pushbutton. The UI function shall acknowledge with a display message that shows the device selected and control action requested. The selected device is highlighted on the display screen from, which control action was initiated. The user can then use the ‘Execute' or ‘Cancel' function pushbuttons for the next step. If the Execute function is selected, the UI shall proceed with the execution of selected supervisory control action and generate an event message describing attempted control action. The UI shall then de-select the device control action and generate an alarm for either a successful device change of state or control action failure following a time-out. If the user selected the “Cancel” function then the UI de-selects the device control action. Jog Supervisory Control is typically used for LTC repositioning. For this supervisory control technique the UI activity and response shall be the same as described for the SBO technique except there shall be no de-selection of the device and control action request following the ‘Execute’ function. The user may continue with multiple depressions of the Execute function pushbutton or de-select the control sequence by the ‘Cancel’ function pushbutton, selecting another point for control or by selecting another display. The UI shall provide a means to inhibit and to enable supervisory control of any controllable point or an entire RTU. The control inhibit/enable procedure shall be similar to that described for supervisory control; except no separate execute step is required. Control inhibit/enable actions shall be processed as events and shall generate a message to the appropriate logger.


The UI procedure for entering the state (e.g., open, closed, etc.) of non-telemetered or out-of-scan status points shall be similar to that described for supervisory control, except no separate execute step is required. 7.3 TAGGING Database values shall be tagged to call the users’ attention to exception conditions for field devices and to inhibit supervisory control actions. It shall be possible to apply a tag to any database point. The SCADA/AGC System shall support at least sixteen tag types. It shall be possible to place up to 10 tags of any type on a single point. If the point is configured for supervisory control, the tag type shall determine what control action is permissible for the point. Each tag type shall be configured by the user to inhibit supervisory control actions as follows:

1) All control allowed. 2) Control in one direction, such as close, inhibited. 3) Control in the other direction, such as trip, inhibited. 4) All control inhibited.

When a user attempts to control a point tagged with a control inhibited tag type, the SCADA/AGC System shall block the control and inform the user of the inhibit condition. The user shall be able to override the control inhibit only by removing the tag.

In addition to control inhibit tags, at a minimum, the following tag types shall be provided:

Alarm inhibit Event inhibit Scan inhibit Information only tag

At the request for the placement of a tag, the SCADA/EMS must require that the user logs in and be recognized as an authorized user for tagging. Each placement of a tag shall result in an entry into a database-ordered Tag List. Each entry shall contain the following information:

Date/Time of Tag Placement Tag Type Station Identifier Device Identifier Comment field (60-character minimum) User who placed the tag

As part of the tag placement process, the SCADA/AGC shall prompt the user to enter alphanumeric comment information to be stored with the tag. The comment field shall be at least sixty characters in length. It shall be possible to modify the tag comment information. Tags shall be individually removed by user command. Each tag placement and removal shall be recorded as an event.


8.0 SOFTWARE REQUIREMENTS This section describes the required characteristics of the SCADA/EMS software, database and software utilities of the SCADA/EMS. It is neither intended nor possible to list all software or all characteristics of the software required in the Contractor's approach to system design. The Contractor is responsible, however, for including all the necessary software to satisfy the SCADA/EMS functional requirements described in this SOW. 8.1 DESIGN CHARACTERISTICS The Contractor shall propose a SCADA/EMS based on its standard product line to the extent possible if the functional requirements of this SOW are met. All software to be provided by the Contractor shall be completely described in the Contractor's proposal. New software, or software modified to satisfy the SOW, shall be considered specially designed for this project. Utilties reserves the right to approve the design of such software without relieving the Contractor of the responsibility to meet the functional requirements of this SOW. All software shall be capable of easy expansion to accommodate ultimate sizing of the SCADA/EMS as the Utilities SCADA/EMS system expands with the addition of new generating units, substations, transmission lines and other equipment. The size and configuration of the SCADA/EMS shall be specified by easily modified parameters contained in the database, not the parameters contained in individual programs. The SCADA/EMS shall grow through the addition of main memory, disk drives, peripherals, RTUs and communication channels. All software shall be designed with sufficient modularity to minimize the time and complexity involved in making a change to any program. The modularity should include the separation of hardware interface modules from other software modules. Logic and data shall be separated into distinct modules. Communication among programs for data or program control shall be symbolic rather than absolute so that a given program is an essentially independent unit. The system design shall minimize changes required in one program because of changes in another. The software shall be well organized in the use of memory. The modularity shall optimize the use of main memory and utilize the protect features of the main and disk memory. Using the software utilities provided by the proposed SCADA/EMS Utilities personnel shall be able to perform minor modifications to the SCADA/EMS such as adding, removing or reconfiguring RTU’s. No Contractor support shall be necessary to modify logic or data within the parameters defined for the ultimate system sizing or the maximum capabilities of the proposed software system. All software contracted under this SOW must be installed, operating and completely documented in final form, including all standard software changes and, field changes initiated by the Contractor and their suppliers, prior to final acceptance of the SCADA/EMS by Colorado Springs Utility. 8.2 PROGRAMMING LANGUAGES AND API’s The SCADA/EMS shall support a full program development environment. Tools provided shall include a version control tool, a C compiler, or a C++ compiler, and a symbolic debugger. At a minimum a programming toolkit shall be provided with compilers, linkers, API, SQL, Java, and XML support and any other system specific software needed.


The following features, at a minimum shall be included in the API provided:

Access to the database, including all point values, description parameters. The ability to generate alarms and events The ability to schedule programs The ability to send and receive messages between programs. The ability to perform calculations

The SCADA/EMS software shall be easily field upgradeable, requiring little or no support from the software supplier. New versions of software shall be well documented and indicate which system files have been changed since the last software release. 8.3 REAL-TIME DATABASE The real-time database shall form the core of the SCADA functions. It shall be structured for optimal performance of RTU polling and operations. The following defines the features required of the real-time database. A proprietary real-time database is acceptable for performance reasons providing an intuitive and user-friendly tool is available for creating and maintaining the database. The real-time database shall also be accessible using SQL calls as well as ODBC interface to transfer data in and out of the database tables. The SCADA/EMS shall utilize a data replication service to transfer data between the hot and standby systems, and between the primary system and the “off-site” backup. The frequency of the data replication shall be configurable and utilize snapshot updates, exception updates, transfer queue updates, and function updates. A database management tool shall provide graphical user interface and forms based facilities for creation and maintenance of all database information within the SCADA/EMS. 8.4 HISTORICAL DATABASE The historical database engine used as part of the historian function shall be a popular and commercially available Relational Data Base Management system (RDBMS). All software licenses including replication and backup functionality for the proposed RDBMS shall be supplied. Utilties prefers the use of the OSI Soft Pi Historian. The vender shall quote the historical database using two methods. 1. The SCADA/EMS System shall write to an embedded Pi Historian. The embedded

historian shall be capable of utilizing a Pi to Pi interface. 2. The SCADA/EMS shall write from a system historian to an existing Pi Data Warehouse

outside of the Electronic Security Perimeter. This would be done through an OBDC link or equivalent.


9.0 TRAINING REQUIREMENTS Training shall be provided on the system provided to allow Utilities’ staff to modify and maintain the SCADA\EMS system. Training shall be conducted by experienced instructors who are familiar with the specific system supplied. 9.1 GENERAL TRAINING REQUIREMENTS Contractor’s standard training courses may be used to meet the training objectives specified. Where standard courses do not meet these objectives, additional coursework shall be developed. Clock hour requirements for each level of training are shall be as listed. A "clock hour" is defined as one hour of instruction or supervised training exercise. Training hour requirements are the number of hours of training to be provided for each student. Additional training time shall be provided if considered necessary to meet the training objectives. Training shall be sufficient to allow Utilities to operate and maintain the SCADA\EMS System once the project is complete. 9.2 TRAINING COSTS All costs associated with the training program shall be the responsibility of Contractor and shall be included in the contract price. 9.3 LESSONS Training lesson plans shall be submitted at least 30 days prior to the start of training. 9.4 VIDEO RECORDING All training sessions shall be video recorded by the Contractor for Utilities’ future use in training other personnel. Video recorded sessions shall be saved to DVD/R media for delivery to Utilities. Pre-recorded videos of Contractor’s standard training programs may be substituted if they cover the same topics and are developed for the same versions of hardware and software. Furnishing videos of standard training programs shall not relieve Contractor from any of the training requirements specified herein. 9.5 TRAINING COMPETENCY VERIFICATION Training sessions shall each include verification that the topics taught have been retained and understood by the staff. Verification shall include conducting a scored test with the results provided to Utilities. 9.6 OPERATOR TRAINING Utilities’ personnel will utilize the system for day-to-day monitoring and control of the facilities. The training program shall provide operators with sufficient knowledge to move from screen to screen within the system, understand the contents of group and detailed point displays, react to and acknowledge alarms, adjust control setpoints and alarm limits, configure and print shift reports, print preconfigured reports on demand, control equipment connected to the system, and react to and resolve minor system errors. Operator training shall be conducted in two sessions to accommodate two shifts of operators.


9.7 PRE-INSTALLATION SESSIONS Each pre-installation training session shall consist of 16 hours of training for 24 students at the Utilities’ facility. 9.8 POST-INSTALLATION SESSION Each class shall consist of 16 hours of instruction using the lesson plan submitted and approved for use. The post-installation sessions may have to be conducted outside normal working hours to accommodate the working schedule of Utilities’ personnel. The post-installation training sessions shall be conducted for 24 of the Utilities’ operating personnel. 9.9 CONTENT OF CLASSES Each session shall cover at least the following topics. a. Power-up and shutdown of all hardware devices. b. Logging on and off the system and the use of passwords. c. Access and interpretation of standard displays and diagnostics. d. Use and care of operator workstations, servers, video displays, printers, and other control

room hardware, including replenishment of supplies and replacement of printer components.

e. Moving from screen to screen within the graphic display environment. f. Interpretation of preconfigured group and detailed point or database displays. g. Response to and acknowledgment of alarms. h. Adjustment of control set points and alarm limits. i. Configuration and printing of shift and other reports by schedule or on demand. j. Control of field equipment and devices connected to the system. k. Manual entries to database points. l. Generation of current (real-time) and historical custom and predefined reports and trend

displays. m. Appropriate responses to software and hardware errors. n. Enabling and disabling individual inputs and outputs. o. Changing scan rates for individual RTUs. p. Access to OSI Pi data from SCADA interface. q. Session on how the operator can use the system as an integrated tool to solve operational

problems and improve efficiency of operations. The operator-training program shall be developed for personnel with no prior experience with the hardware and software provided as part of the project.

9.10 PROGRAMMER TRAINING Programmer training shall be furnished as described in this section. System programming training shall be provided to enable Utilities’ personnel to initially configure and later reconfigure the system. Programming tasks shall include addition or modification to the system database; modification or creation of graphic and tabular display and report formats; and creation and modification of historical archiving groups and data reduction algorithms.


9.10.1 CLASSES Programmer Training shall be conducted in two sessions. Session 1 of the training class shall consist of 40 hours of instruction for 10 students and shall be conducted at Utilities’ facilities prior to establishment of configuration standards. Session 2 of the training shall be conducted two weeks prior to the installation of the new SCADA system and shall consist of 24 hours of instruction for 10 students at the Utilities’ facilities. 9.10.2. CONTENT OF CLASSES Programmer training shall include, but shall not be limited to the following topics: a. Loading of any supplied software into the system. b. Use of basic operating system commands for file management, system startup, and

creation and editing of batch files. c. Creation and editing of database. d. Configuration of printed report formats. e. Creation and editing of tabular and graphic HMI interface display screens. f. Diagnostic routines. g. Creation and modification of control algorithms. h. Addition of new I/O points and new RTUs to the system. i. Historical record retrieval, data reduction, archiving, and disk housekeeping. j. System backup procedures. k. Creating links between the SCADA software and the OSI Pi. l. Rebuilding a server from a blank hard drive to a fully functioning system using

removable media. m. All non contractor work related to security n. System restoration procedures o. System troubleshooting p. Protocol analyzer training and communication troubleshooting. q. Contractor supplied system support systems r. Primary redundant system failover procedures planned and unplanned s. Secondary (backup) system failover procedures planned and unplanned Programmer training shall be designed for personnel who have a general familiarity with control system operation and high-level application programs, but not necessarily with the specific hardware or software furnished for this project. 10. SECURITY System Hardening refers to making changes to the default configuration of a Network Device and its operating system (OS), software applications, and required third-party software to reduce system security vulnerabilities. Contractor acknowledges that Utilities is subject to certain security requirements promulgated by the North American Electric Reliability Council (NERC) therefore all services provided to Utilities will require completion of Utilities’ security training, personal security background checks, strict adherence to Utilities’ security procedures, as well as routine audits concerning these security obligations, which are required as matter of legal compliance, and not as a discretionary policy of Utilities. In addition, Contractor agrees that it will make and keep, and have subject to audit for five (5) years following completion of performance required by this Agreement, all


records concerning Contractor's compliance with all security training, security background checking, and security procedure adherence.

Without limiting contractor’s obligation of confidentiality as further described herein, contractor shall be responsible for establishing and maintaining an information security program that is designed to

a. Ensure the security and confidentiality of the Utilities’ Data

b. Protect against any anticipated threats or hazards to the security or integrity of Utilities’ Data;

c. Protect against unauthorized access to or use of Utilities’ Data;

d. Ensure the proper disposal of Utilities’ Data; and, (v) ensure that all subcontractors of Service-now.com, if any, comply with all of the foregoing.

10.1 REMOVAL OF UNNECESSARY SERVICES AND PROGRAMS Unnecessary services and programs are often installed on network devices. Unused services in a host operating system that are left enabled are possible entry points for exploits on the network and are generally not monitored since these services are not used. Only the services used for control systems operation and maintenance shall be enabled to limit possible entry points. Post-contract award, the Contractor shall provide documentation detailing all applications, utilities, system services, scripts, configuration files, databases, and all other software required and the appropriate configurations, including revisions and/or patch levels for each of the computer systems associated with the control system. The Contractor shall provide a listing of services required for any computer system running control system applications or required to interface the control system applications. The listing shall include all ports and services required for normal operation as well as any other ports and services required for emergency operation. The listing shall also include an explanation or cross reference to justify why each service is necessary for operation. The Contractor shall verify and provide documentation that all services are patched to current status. The Contractor shall provide, within a 30 days unless otherwise agreed in writing, appropriate software and service updates and/or workarounds to mitigate all vulnerabilities associated with the product and to maintain the established level of system security. The Contractor shall remove and/or disable all software components that are not required for the operation and maintenance of the control system prior to the FAT. The Contractor shall provide documentation on what is removed and/or disabled. The software to be removed and/or disabled shall include, but is not limited to: 1. Games 2. Device drivers for network devices not delivered 3. Messaging services (e.g., MSN,h AOL IM, etc.) 4. Servers or clients for unused Internet services


5. Software compilers in all user workstations and servers except for development workstations and servers

6. Software compilers for languages that are not used in the control system 7. Unused networking and communications protocols 8. Unused administrative utilities, diagnostics, network management, and system

management functions 9. Backups of files, databases, and programs used only during system development 10. All unused data and configuration files 11. Sample programs and scripts 12. Unused document processing utilities (Microsoft Word, Excel, PowerPoint, Adobe

Acrobat, OpenOffice, etc.).

10.1.1 FAT MEASURES The Contractor shall verify that the Purchaser requires the results of cyber security scans (as a minimum a vulnerability and active port scan, with the most current signature files) run on the control system as a primary activity of the FAT. This assessment is then compared with an inventory of the required services, patching status, and documentation, to validate this requirement. Other measures provided include: 1. The Contractor shall provide for each networked device or class of device (e.g., server,

workstation, and switch) the following configuration documentation lists:

a. Network services required for the operation of that device. Indicate the service name, protocol (e.g., TCP and UDP) and port range

b. Dependencies on underlying operating system services c. Dependencies on networked services residing on other network devices d. All of the software configuration parameters required for proper system

operation e. Certified OS, driver, and other software versions installed on the device f. Results found by the vulnerability scans with mitigations affected.

2. The Contractor shall install Firmware updates available for the computer or network device certified by the system manufacturer at the time of installation and provide documentation.

3. The Contractor shall provide a summary table overview indicating each communication

path required by the system.

4. The Contractor shall provide a summary table indicating each communication path required by the system. Include the following information in this table: a. Source device name and Media Access Control (MAC) and/or IP address b. Destination device name and MAC and/or IP address c. Protocol (e.g., TCP and UDP) and port or range of ports.

5. The Contractor shall perform network-based validation and documentation steps on each

device: a. Full TCP and UDP port scan on Ports 1–65535. This scanning needs to be

completed during a simulated “normal system operation.


10.1.2 SAT MEASURES The Contractor shall compare the results of cyber security scans run on the system, as a primary activity of the SAT, with an inventory of the required services, patching status, and required documentation. At the conclusion of the SAT and before cutover or commissioning, the above cyber security scans (with the most current signature files) must be run again. 10.2 HOST INTRUSION DETECTION SYSTEM A host intrusion detection system (HIDS) can be installed to perform a variety of integrity checks to detect attempted unauthorized access. In unmonitored systems, it is difficult to detect unauthorized changes or additions to the operating system or application programs. The vulnerability scans suggested in the prior section only identify what is known. Continuous monitoring is necessary to detect emerging unauthorized changes or additions, or unauthorized escalation of process privileges. Post-contract award: The Contractor shall provide a configured HIDS and/or provide the information to configure a HIDS to include, but not be limited to, static file names, dynamic file name patterns, system and user accounts, and execution of unauthorized code, host utilization, and process permissions sufficient for configuring the HIDS. The Contractor shall configure the HIDS such that all system and user account connections are logged. This log will be configured such that an alarm can be displayed to the operator or security personnel if an abnormal situation occurs. The Contractor shall recommend a configuration for the HIDS in a manner that does not negatively impact the operating system functions or business objectives. The Contractor shall recommend log review and notification software tools. The Contractor shall configure devices as “append only” to prevent alteration of records on local storage devices. 10.2.1 FAT MEASURES The Contractor shall verify and provide documentation that for Contractor-supplied HIDS; the Contractor shall run the HIDS during the entire FAT process and periodically interject applicable malware. ‘ The Contractor shall examine log files and validate the expected results. FAT procedures shall include validation and documentation of this requirement. 10.2.2 SAT MEASURES The Contractor shall verify and provide documentation that for Contractor-supplied HIDS, the Contractor shall run the HIDS during the entire SAT process and periodically interject applicable malware. The Contractor shall examine log files and validate the expected results. SAT procedures shall include validation and documentation of this requirement.


The Contractor shall generate a system image at the conclusion of the SAT to be used later as a control baseline. 10.3 CHANGES TO FILE SYSTEM AND OPERATING SYSTEM PERMISSIONS Hardening file system configurations and restricting operating system permissions reduce the vulnerabilities associated with default configurations. Configurations for out-of-the-box operating systems and file systems normally are more permissive than necessary allowing exploitation. The Contractor shall configure hosts with least privilege file and account access and provide documentation of the configuration. The Contractor shall configure the necessary system services to execute at the least user privilege level possible for that service and provide documentation of the configuration. The Contractor shall document that changing or disabling access to such files and functions has been completed. 10.3.1 FAT MEASURES The Contractor shall provide, as a part of the FAT procedures, validation and documentation of the permissions assigned. 10.3.2 SAT MEASURES The Contractor shall provide, as a part of the SAT procedures, validation and documentation of the permissions assigned. 10.4 HARDWARE CONFIGURATION Unnecessary hardware can be physically disabled, removed, or its configuration altered through software. Most control system network devices have multiple communication and data storage capabilities. These can be utilized to introduce vulnerabilities such as viruses, root kits, malware, bots, key-loggers, etc. The Contractor shall disable, through software or physical disconnection, all unneeded communication ports and removable media drives, or provide engineered barriers, and provide documentation of the results. The Contractor shall password protect the BIOS from unauthorized changes unless it is not technically feasible, in which case the Contractor shall document this case and provide mitigation measures. The Contractor shall provide a written list of all disabled or removed USB ports, CD/DVD drives, and other removable media devices. The Contractor shall configure the network devices to limit access to/from specific locations, where appropriate, and provide documentation of the configuration.


The Contractor shall configure the system to allow the system administrators the ability to re-enable devices if the devices are disabled by software and provide documentation of the configuration. 10.4.1 FAT MEASURES The Contractor shall provide, as a part of the FAT procedures, validation and documentation of the disabled or locked physical access and the removed drivers. 10.4.2 SAT MEASURES The Contractor shall provide, as a part of the SAT procedures, validation and documentation of the disabled or locked physical access and the removed drivers. 10.5 HEARTBEAT SIGNALS Heartbeat signals indicate the communication health of the system. Heartbeat signals or protocols can be corrupted, spoofed, or possibly used as an entry point for unauthorized access. The Contractor shall identify heartbeat signals or protocols and recommend whether any should be included in network monitoring. Post-contract award, the Contractor shall provide packet definitions of the heartbeat signals and examples of the heartbeat traffic if the signals are included in the network monitoring. 10.5.1 FAT MEASURES The Contractor shall provide, as a part of the FAT procedures, documentation of the requirements. The Contractor shall create a baseline of the heartbeat communications traffic, to include frequency, packet sizes, and expected packet configurations. 10.5.2.5 SAT MEASURES The Contractor shall provide, as a part of the SAT procedures, documentation of the requirements. The Contractor shall create a baseline of the heartbeat communications traffic and validate the results against FAT documentation. 10.6 INSTALLING OPERATING SYSTEMS, APPLICATIONS, AND THIRD-PARTY SOFTWARE UPDATES Patches and software updates, including those for anti-virus scanners, are required to reduce attack surface. Most successful cyber attacks occur in non-patched systems or applications. The Contractor shall have a patch management and update process. Pre-contract award, the Contractor shall provide details on their patch management and update process. Responsibility for installation and update of patches shall be identified.


Post-contract award, the Contractor shall provide notification of known vulnerabilities affecting Contractor-supplied or required OS, application, and third-party software within a 30 days unless otherwise agreed in writing, after public disclosure. Post-contract award, the Contractor shall provide notification of a patch(es) affecting security within a 30 days unless otherwise agreed in writing as identified in the patch management process. The Contractor shall apply, test, and validate the appropriate updates and/or workarounds on a baseline reference system before distribution. Mitigation of these vulnerabilities shall occur within a 30 days unless otherwise agreed in writing. 10.6.1 FAT MEASURES The Contractor shall install and update all tested and validated security patches prior to the start of the FAT. The Contractor shall verify and provide documentation that all updates have been tested and installed. The Contractor shall perform contractually agreed upon security scans (with the most current signature files) to verify that the system has not been compromised during the testing phase. The Contractor shall provide documentation of the results of the scans. The Contractor shall document the system after the FAT to support future validation of patches. (In many instances, this is referred to as the system baseline. 10.6.2 SAT MEASURES The Contractor shall install and update all tested and validated security patches at the start of the SAT. The Contractor shall provide documentation that all the updates have been tested and installed. The Contractor shall verify system functionality, based upon prenegotiated procedures, at the conclusion of patch updates, and provide documentation of the results. The Contractor shall perform security scans (with the most current signature files) to verify that the system has not been compromised during the testing phase of the results. The Contractor shall document the system after the SAT to support future validation of patches. (In many instances, this is referred to as delivered system configuration. 10.7 PERIMETER PROTECTION Perimeter Protection refers to providing a clear demarcation between the protected internal network and unprotected and untrusted external networks. 10.7.1 FIREWALLS Firewalls are used to stop unauthorized connections, or to allow limited communications between two networks or from a network to a networked device. Firewalls fall into four broad categories:


packet filters, circuit level gateways, application level gateways, and stateful multilayer inspection firewalls. Firewalls can be implemented in software, hardware or a combination of both. The Contractor shall provide firewalls and firewall rule sets between network zones or provide firewall rule sets if the firewalls are not provided by the Contractor. The Contractor shall provide firewall rule sets and/or other equivalent documentation. The basis of the rule set shall be “deny all,” with exceptions explicitly identified by the Contractor. Note that this information is deemed business sensitive and shall be protected as such. Post-contract award, the Contractor shall provide detailed information on all communications (including protocols) required through a firewall, whether inbound or outbound, and identify each network device initiating a communication in accordance with the corresponding rule sets. 10.7.1.1 FAT MEASURES The Contractor shall install the firewall(s) or the configuration(s) and run the firewall(s) continuously during the entire FAT process for Contractor-supplied firewall(s), or Contractor provided firewall configuration(s). The Contractor shall verify that FAT procedures include exercising this functionality, examining the log files, and validating the results. The Contractor shall verify that FAT procedures include validation and documentation of the requirements. 10.7.1.2 SAT MEASURES The Utilities shall run the firewall(s) during the entire SAT process. The Contractor shall verify that SAT procedures include exercising this functionality, examining the log files, and validating the results. The Contractor shall verify that SAT procedures include validation and documentation of the requirements. Any Contractor-configured or manufacturer default usernames, passwords, or other security codes must be changed at this time. 10.7.2 NETWORK INTRUSION DETECTION SYSTEM A network intrusion detection system (NIDS) is used to identify unauthorized or abnormal network traffic. Firewalls or other vulnerabilities may allow unauthorized access, which are detectable by a NIDS. Pre-contract award, the Contractor shall provide a recommended placement of the NIDS within the control system network. The Contractor shall provide traffic profiles with expected communication paths, network traffic, and expected utilization boundaries, for anomaly-based NIDSs. The Contractor shall provide appropriate signatures, for signature-based NIDSs. Post-contract award, the Contractor shall provide a configured NIDS and/or provide the information to configure a NIDS.


10.7.2.1 FAT MEASURES The Contractor shall install the NIDS or the configuration(s) and run the NIDS continuously during the entire FAT process for Contractor-supplied NIDSs, or Contractor-provided NIDS configuration(s). The Contractor shall verify that FAT procedures include exercising this functionality, examining the log files, and validating the results. The Contractor shall verify that FAT procedures include validation and documentation of the requirements. 10.7.2.2 SAT MEASURES The Contractor shall run the NIDS(s) during the entire the SAT process to include exercising this functionality, examining the log files, and validating the results. The Contractor shall document the results of tuning signatures and adjusting thresholds to reduce false positives and minimize false negatives. The Contractor shall verify that SAT procedures include validation and documentation of the requirements. Any Contractor-configured or manufacturer default usernames, passwords, or other security codes must be changed at this time. 10.7.3 CANARIES Honey pots (which analyze unauthorized connections) and/or canary(ies) (which flag that a connection attempt has taken place) have been implemented in certain network configurations to provide passive network monitoring. Canaries enhance network traffic screening since most signatures created for a NIDS are immature and only detect proper protocol versions limiting network-monitoring capabilities. The Contractor shall provide a recommended placement of the canary(ies) within the control system network. The canary(ies) shall be configured with alerting software to indicate unauthorized connection attempts. Post-contract award, the Contractor shall provide a configured canary(ies) or information to configure a canary(ies). 10.7.3.1 FAT MEASURES The Contractor shall install the canary(ies) or the configuration(s) and run the canary(ies) continuously during the entire FAT process for Contractor-supplied canary(ies) or Contractor-provided canary configuration(s). The Contractor shall verify that FAT procedures include exercising this functionality, examining the log files, and validating the results. The Contractor shall verify that FAT procedures include written validation and documentation of the requirements.


10.7.3.2 SAT MEASURES The Contractor shall run the canary(ies) during the entire SAT process. The Contractor shall verify that SAT procedures include exercising this functionality, examining the log files, and validating the results. The Contractor shall verify that SAT procedures include written validation and documentation of the requirements. Any Contractor-configured or manufacturer default usernames, passwords, or other security codes must be changed at this time. 10.8 ACCOUNT MANAGEMENT Account Management is essential to properly maintain and secure a control systems network. Account management regulates who has access, limits permission to only those required, and mitigates vulnerabilities in default accounts. It also covers password management. With careful account management, default accounts and passwords, which typically exist in control systems and pose a substantial risk, can be eliminated or mitigated. Control of user access can be broken into three major topics:

1. Authentication. Is the ability to verify an identity based on the following attributes: “what you have” (i.e., key, digital certificate, or smart card), “what you know” (i.e., username and password), and “what you are” (i.e., biometric iris, fingerprint scan, or fingerprints), and/or “what you do” (i.e. dynamic biometric handwriting scan or voice recognition).

2. Authorization. Is the ability to control user permissions within the system to include network access. Authorization capabilities and processes vary widely between products, from none in the case of an “all-or-nothing” access, to a very specific control of user capabilities in more advanced cases.

3. Accounting. The ability to provide an audit trail of activities within the system. Accounting is typically accomplished through logging activities of significance, such as a login, changing passwords, or making significant system changes. Accounting is related to auditing.

10.8.1 DISABLING, REMOVING, OR MODIFYING WELL-KNOWN OR GUEST ACCOUNTS Disabling, removing or modifying well-known or guest accounts and changing default passwords are necessary to reduce system vulnerabilities. Default accounts and passwords are available on many control systems and are often publicly available in published materials allowing unauthorized system access. The Contractor shall recommend which accounts need to be active and those that can be disabled, removed, or modified. The Utilities shall approve in writing the Contractor’s recommendation. The Contractor shall disable, remove, or modify all the accounts pursuant to the approved recommendation. Post-contract award, the Contractor shall disable or remove all default and guest accounts prior to the FAT. Once changed, new accounts will not be published except that new account information and passwords will be provided by the Contractor via protected media. After the SAT the


Contractor shall disable, remove, or modify all Contractor-owned accounts or negotiate account ownership with the Utilities. 10.8.1.1 FAT MEASURES The Contractor shall verify that FAT procedures include exercising this functionality, examining the log files, and validating the results. The Contractor shall verify that FAT procedures include written validation and documentation of the requirements. 10.8.1.2 SAT MEASURES The Contractor shall verify that SAT procedures include exercising this functionality, examining the log files, and validating the results. The Contractor shall verify that SAT procedures include written validation and documentation of the requirements. 10.9 SESSION MANAGEMENT Weak session practices and insecure protocols exist on many systems for convenience, backwards compatibility, and on legacy systems. Unauthorized access can be achieved through clear-text accounts and passwords along with weak session security practices, remembered account information between login, auto-filling of fields during logins, and anonymous services such as FTP. In many systems, you are your account, and once the account is compromised, the system has no way of knowing who is actually using the account. The Contractor shall not permit user credentials to be transmitted in clear text. The Contractor shall provide the strongest encryption method commensurate with the technology platform and response time constraints. The Contractor shall not allow multiple concurrent logins, applications to retain login information between sessions, provide any auto-fill functionality during login, or allow anonymous logins. The Contractor shall provide user account-based logout and timeout settings. 10.9.1 FAT MEASURES The Contractor shall verify that FAT procedures include validation and documentation of the requirements. 10.9.2 SAT MEASURES The Contractor shall verify that SAT procedures include validation and documentation of the requirements.


10.10 PASSWORD/AUTHENTICATION POLICY AND MANAGEMENT Instant availability requirements in control systems often result in a weak password policy. Weak passwords introduce vulnerabilities to the control systems network. In addition, sometimes passwords are hard-coded into software to facilitate control system internal communications allowing anyone with access to the code/configuration files knowledge of the password(s). The Contractor shall provide a configurable account password management system that allows for selection of password length, frequency of change, setting of required password complexity, number of login attempts, inactive session logout, screen lock by application, and denial of repeated or recycled use of the same password. The Contractor shall not store passwords electronically or in Contractor-supplied hardcopy documentation in clear text unless the media is physically protected. The Contractor shall control configuration interface access to the account management system. The Contractor shall provide a mechanism for rollback of security authentication policies during emergency system recovery or other abnormal operations, where system availability would be negatively impacted by normal security procedures. 10.10.1 FAT MEASURES The Contractor shall verify that FAT procedures include validation and documentation of the password and authentication policy and management. 10.10.2 SAT MEASURES The Contractor shall verify that SAT procedures include validation and documentation of the password and authentication policy and management. 10.11 ACCOUNT AUDITING AND LOGGING Account auditing and logging allow the Utilities/Operator to verify that authorized operations have been maintained. Logging is also necessary for forensic analysis and anomaly detection. Logging and auditing of both active and disabled accounts are useful for anomaly and unauthorized access detection because cyber attackers commonly modify audit logs to cover activities. The Contractor shall provide a system whereby account activity is logged and is auditable both from a management (policy) and operational (account use activity) perspective. The Contractor shall time stamp, encrypt, and control access to audit trails and log files. The Contractor shall ensure audit logging does not adversely impact system performance requirements. The Contractor shall provide read-only media for log creation.


10.11.1 FAT MEASURES The Contractor shall verify that FAT procedures include validation and documentation of the requirements. The Contractor shall record system performance measurements that include the system with and without logging activities. 10.11.2 SAT MEASURES The Contractor shall verify that SAT procedures include validation and documentation of the requirements. The Contractor shall record system performance measurements to verify that logging activities do not adversely impact system performance. 10.12 ROLE-BASED ACCESS CONTROL FOR CONTROL SYSTEM APPLICATIONS Role-based access control (RBAC) refers to the system’s ability to make access decisions based on the role(s) of individual users/processes in the control system environment. Using RBAC results in significant improvements in security. The use of roles to control access can be an effective means for developing and enforcing system wide security policies and for streamlining security management processes. RBAC limits the exposure to risk associated with unauthorized actions by assigning the least privileges corresponding to the assigned duty or function. The use of RBAC for administrative functions is not common on legacy systems. Legacy control systems typically do not have RBAC, which allows any user full access, control, and administrative privileges. Thus if an unauthorized user achieves login, that user would have full access to the system. The Contractor shall provide for user accounts with configurable access and permissions associated with the defined user role. The Contractor shall adhere to least privileged permission schemes for all user accounts, and application-to-application communications. The Contractor shall configure the system so that initiated communications start with the most privileged application controlling the communication. Upon failed communication, the most privileged side will restart communications. The Contractor shall verify that the master network device initiates communications. The Contractor shall inform the Utilities if this condition cannot be met. The Contractor shall verify that a user cannot escalate privileges, under any circumstances, without logging into a higher-privileged role first. The Contractor shall provide a mechanism for changing user(s) role (e.g., group) associations. Post-contract award, the Contractor shall provide documentation defining access and security permissions, user accounts, applications, and communication paths with associated roles.


10.12.1 FAT MEASURES The Contractor shall compare the control system assessment during this period with required documentation to validate the requirements. The Contractor shall baseline user roles and permissions and negotiate agreements on modifications with the system Utilities/Operators. 10.12.2 SAT MEASURES The Contractor shall verify that all additions to the control system, after the completion of the FAT, have the same rigor of documentation that was necessary pre-FAT and appropriate comparisons are required post-SAT to validate the requirement. 10.13 SINGLE SIGN-ON Single sign-on (SSO) refers to a means of user authentication such that a single login allows a user to have authorized role-based access across a network or between programs and systems, without requiring re-authentication to each application. Single sign-on authentication has been commonly designed for convenience, sometimes at the expense of security, and potentially provides an avenue for the introduction of vulnerabilities. However, careful attention to system design can lead to single sign-on schemes that enhance security. The Contractor shall provide an SSO such that RBAC enforcement is equivalent to that enforced as a result of direct login. The Contractor shall provide a means of allowing SSO to a suite of applications via SSH, terminal services, or other authenticated means. This system should be RBAC capable. The Contractor shall provide documentation on configuring such a system, and documentation showing equivalent results in running validation tests against the direct login and the SSO. The Contractor shall protect key files and access control lists (ACLs) used by the SSO system from nonadministrative user read, write, and delete access. Note that SSO must resolve individual user’s logins to each application. 10.13.1 FAT MEASURES The Contractor shall verify that FAT procedures include validation and documentation that the SSO permissions and session management are handled properly. 10.13.2 SAT MEASURES The Contractor shall verify that SAT procedures include validation and documentation that the SSO permissions and session management are handled properly. 10.14 SEPARATION AGREEMENT The Utilities needs to have agreements with Contractors to protect their control systems security posture. Integrators and companies that support control systems are very dynamic and


competitive, resulting in frequent turnover of key support personnel potentially exposing sensitive information. Pre-contract award, the Contractor shall provide a separation agreement to delineate how Contractor employees who have sensitive knowledge of the Utilities control systems and who leave their positions or have responsibilities changed will be prohibited from disclosing that knowledge, where disclosure could lead to a reduction in security. The Contractor shall notify the Utilities within a within 24 hours when key personnel leave or change positions, should it possibly impact control system security. The Contractor shall provide detailed documentation on how the control system security can be maintained and supported in the event the Contractor leaves the business. The Contractor shall return to the Utilities any sensitive data in the Contractor’s possession when the Contractor is no longer able to maintain control of the Utilities products. 10.14.1 FAT MEASURES The Contractor shall verify that FAT procedures include validation and documentation of the ability to change key employee/support personnel access and permissions. 10.14.2 SAT MEASURES The Contractor shall verify that SAT procedures include validation and documentation of the ability to change key employee/support personnel access and permissions. 10.15. CODING PRACTICES Secure coding practices refer to techniques for building and validating high levels of security into software, beginning at the requirements phase, implemented during the coding phase, and finally validated during the FAT and SAT. 10.15.1 CODING FOR SECURITY Standard programming texts generally address data processing, but not security ramifications; this may mislead programmers into writing insecure code. Software flaws are a primary avenue for gaining system access. Many control system security vulnerabilities are the direct result of writing software with inadequate attention to defense against deliberate and persistent malicious attack. These attacks include, but are not limited to: Buffer overflows, in which input fields are populated with long data sequences that overflow program buffers, often yielding program controls to the remote user (providing a useful command prompt in some cases). Data insertion and injection, in which input fields are populated with control or command sequences embedded in various ways that are nevertheless accepted by the application, or possibly passed to the OS, and that allow privileged malicious and unauthorized programs to be run on the remote system. These vulnerabilities are particularly threatening because the control system can be compromised by bypassing normal access control checks, such as firewalls—control system traffic will appear normal as far as the network is concerned. Network protections such as proxies,


which provide some defense against these vulnerabilities, are available for well-known protocols such as Web-based (HTTP) or e-mail (SMTP), but not for some lesser-known protocols. Pre-contract award, the Contractor shall provide documentation of development practices and standards applied to Contractor-written control system software, including firmware, used to ensure a high level of defense against unauthorized access. The Contractor shall provide the results of Code Reviews. Post-contract award, the Contractor shall provide documentation of coding practices used in developing the delivered software. 10.15.1.1 FAT MEASURES The Contractor shall verify that FAT procedures include validation and documentation of the software development process and/or code review. 10.15.1.2 SAT MEASURES The Contractor shall verify that SAT procedures include validation and documentation of the software. 10.16 FLAW REMEDIATION Flaw remediation refers to the actions to be performed and documentation to be produced when flaws are discovered in control system software, hardware, and system architectures created by or under the control of the Contractor. 10.16.1 NOTIFICATION AND DOCUMENTATION FROM CONTRACTOR Flaw remediation is a process by which flaws are documented and tracked for completion of corrective actions. Vulnerabilities exist in control systems when flaws in software and/or hardware configurations are not patched. Many times intended patches are not applied in a timely manner due to operational issues. In many instances, workarounds and temporary fixes may become permanent solutions; however, the vulnerabilities may be reintroduced with future updates, upgrades, patches, and fixes. Awareness of application vulnerabilities, particularly security related flaws, is needed in a timely fashion. Guidance about corrective actions, fixes, or monitoring is needed to mitigate all vulnerabilities associated with the flaw. Auditable history of flaws and remediation steps are required to roll back patches. Vulnerabilities and flaws are normally closely held until remediation becomes available. However, some vulnerabilities are made public before a fix has been developed and then it becomes urgent to mitigate these vulnerabilities. The Contractor shall have and provide documentation of a written flaw remediation process. The Contractor shall provide appropriate software updates and/or workarounds to mitigate all vulnerabilities associated with the flaw within a 72 hour period unless agreed to otherwise in writing.


Post-contract award, after the Contractor is made aware of or discovers any flaws, the Contractor shall provide notification of such flaws affecting security of Contractor-supplied software within a 72 hour period. Notification shall include, but is not limited to detailed documentation describing the flaw with security impact, root cause, corrective actions, etc. 10.16.1.1 FAT MEASURES The Contractor shall verify that for flaws known by the Contractor, the Contractor’s corrective actions follow their process and the process is effective. The Contractor shall verify that FAT documentation of the flaws validation and remediation are provided. The Contractor shall verify that any changes to the core system code, logic, or configuration are analyzed to verify new vulnerabilities are not introduced into the system as a result of the change. 10.16.1.2 SAT MEASURES The Contractor shall verify that for flaws known by the Contractor, the Contractor’s corrective actions follow their process and the process is effective. The Contractor shall verify that SAT documentation of the flaws validation and repair are provided. The Contractor shall verify that any changes to the core system code, logic, or configuration are analyzed to verify new vulnerabilities are not introduced into the system as a result of the change. 10.16.2 PROBLEM REPORTING Vulnerabilities exist in core logic and configuration of control systems. When flaws in software and/or hardware configuration are discovered by users, the Contractor shall have a process in place by which the user can securely report such flaws. A flaw remediation process should be used to track progress of patches, fixes, and workarounds until completion. Zero-day exploits are not defendable and are a primary attack vector. Timely notification of flaws is essential to create defenses for zero-day exploits. The Contractor and the Utilities must communicate flaw information in a secure manner during the mitigations development process. Public release of problem reports could lead to non-defendable exploits. Consequently, knowledge of open flaws should be closely protected. The Contractor shall provide a process for users to submit problem reports and remediation requests to be included in the system security. The process shall include tracking history and corrective action status reporting. The Contractor shall review and report their initial action plan within 24 hours of submitting the problem reports.


The Contractor shall protect problem reports regarding security vulnerabilities from public discloser, and notify Utilities of all problems and remediation steps, regardless of origin of discovery of the problem. The Contractor shall inform the Utilities in writing of flaws within applications and operating systems in a timely fashion, and provide corrective actions, fixes, or monitoring guidance for vulnerability exploits associated with the flaw. The Contractor shall provide an auditable history of flaws including the remediation steps taken for each. 10.16.2.1 FAT Measures None. 10.16.2.2 SAT Measures None. 10.17. MALWARE DETECTION AND PROTECTION Malware is any unauthorized software. Because many control networks are connected to other networks or updated by media, malware can enter into the network and affect process control and/or communications. Malware consist of many different types of software and may include, but is not limited to bots, Trojans, worms, viruses, backdoors, and zombies. Malware detection can occur on a host or a network-based device. 10.17.1 MALWARE DETECTION AND PROTECTION Updates to malware detection software may adversely impact control system behavior. Malicious code such as worms, viruses, and Trojans, can propagate through a control system and potentially impact or curtail operations. The Contractor shall disclose the existence and reasons for any known or identified backdoor codes. The Contractor shall meet one of two conditions:

1. Provide a host-based malware detection scheme for the control system network. The Contractor shall verify adequate system performance for host-based malware detection, quarantine (instead of automatically deleting) suspected infected files, and provide an updating scheme for the signatures. The Contractor shall also test major updates to malware detection applications and provide performance measurement data on the impact of using the malware detection applications in an active system. Measurements shall include, but are not limited to network usage, CPU usage, memory usage, and any other impact to normal communications processing.

2. If the Contractor is not providing the actual host-based malware detection

scheme, the Contractor shall suggest malware detection products to be used and provide guidance on malware detection settings that will work with Contractor products.


10.17.1.1 FAT MEASURES The Contractor shall record system performance measurements that include the system with and without malware detection. The Contractor shall verify all media and equipment is scanned under the most current malware detection versions available prior to onsite transport. The Contractor shall exercise the malware detection system. The Contractor shall document any known or identified backdoor codes. 10.17.1.1 SAT MEASURES The Contractor shall record system performance measurements to verify that malware detection does not adversely impact system performance. The Contractor shall document any known or identified backdoor codes. The Contractor shall provide documentation of the malware detection software retest when significant changes are made to determine possible impacts to performance. The Contractor shall retain malware detection application logs for a 3 years period unless otherwise agreed to in writing for possible forensics tasks. The Contractor shall update malware detection software as required to be effective for the most recent malware released since these signatures are reactive. As the malware variants change, new, more precise or tuned signatures need to be applied. The Contractor shall disclose the existence and reasons for any known or identified backdoor codes. 10.18 HOST NAME RESOLUTION The Domain Name System (DNS) performs a key function in IP networks by providing name resolution services, translating computer names to IP addresses, and translating IP addresses to computer names. Dynamic host configuration protocol (DHCP) is often used in conjunction with the DNS server to assign IP addresses to client computers. DHCP allows the IP allocation to be completed dynamically with the address expiring after a pre-determined length of time. 10.18.1 NETWORK ADDRESSING AND NAME RESOLUTION Each computer in a network has a unique IP address. Remembering each address for each computer in a network is difficult, so addresses are often mapped to host names, which are easier to remember. DNS servers translate the host name used by people to the IP address used by computers. IP addresses can be assigned statically or can be allocated dynamically from a pool of addresses using DHCP. The most widely used DNS software is Berkeley Internet Name Domain (BIND) produced by Internet Software Consortium (ISC), although other packages exist, including Microsoft DNS. DNS servers are susceptible to many types of cyber exploits including spoofing, cache poisoning, and denial of service (DoS) attacks. In a spoofing attack, an attacker who has obtained DNS zone data (the name to IP address mapping) creates packets that appear to come from a valid address. The attacker can then redirect clients by appearing as the legitimate


name server. Cache poisoning involves polluting the cache on the DNS server with erroneous data to redirect traffic to a server under the control of the attacker. In a DoS attack, the attacker floods the DNS server with recursive queries. Eventually, the DNS service is no longer available. Pre-contract award, the Contractor shall provide recommended network addressing and name resolution methodology. The Contractor shall provide a means to verify the integrity of configuration files, zone data, and other DNS files (e.g., such integrity checking may be done with a HIDS). Post-contract award, the Contractor shall provide a configured DNS server(s) or the information to configure a DNS server(s) that meets a prenegotiated standard of security. The Contractor shall consider addressing information as business sensitive and protect it as such. 10.18.1.1 FAT MEASURES The Contractor shall install and run Contractor-supplied DNS servers continuously during the entire FAT process. The Contractor shall verify all domain servers and hosts within the domain involved in testing are resolvable by all client and server systems connected to the network. The Contractor shall document both forward (hostname to IP address) resolution and reverse (IP address to hostname) resolution. 10.18.1.2 SAT MEASURES The Contractor shall run the DNS server during the entire SAT process. The Contractor shall verify all domain servers and hosts within the domain involved in testing are resolvable by all client and server systems connected to the network. The Contractor shall document both forward (hostname to IP address) resolution and reverse (IP address to hostname) resolution. 10.19 DEDICATED LINE MODEMS Modems allow remote access to control system equipment. Modems connected by dedicated lines, also known as nonswitched lines, are often not considered vulnerable since the lines are permanently connected together and do not have phone numbers. While dedicated-line modems are considered more secure than dial-up modems, the devices, like dial-up modems, are not impervious to information discovery and hacking. The Contractor shall provide physical and cyber security features, including but not limited to authentication, encryption, access control, event and communication logging, monitoring, and alarming to protect the device and configuration computer from unauthorized modification or use. The Contractor shall clearly identify the physical and cyber security features and provide the methodology(ies) for maintaining the features including the methods to change settings from the Contractor-configured or manufacturer default conditions. The Contractor shall not permit user credentials to be transmitted in clear text. The Contractor shall verify that the addition of security features does not adversely affect connectivity, latency, bandwidth, response time, and throughput, including during the SAT when connected to existing equipment.


The Contractor shall provide a list including all ports and services required for normal operation and emergency operation and troubleshooting. The Contractor shall provide, within a 72 hour period unless agreed to otherwise in writing, appropriate software and service updates and/or workarounds to mitigate all vulnerabilities associated with the product and to maintain the established level of system security. The Contractor shall verify and provide documentation that the SIS is certified after incorporating the security devices. The Contractor shall remove and/or disable all software components that are not required for the operation and maintenance of the modem and modem security system prior to the FAT. The Contractor shall provide documentation on what is removed and/or disabled. The software to be removed and/or disabled shall include, but is not limited to: 1. Device drivers for network devices not delivered 2. Unused networking and communications protocols 3. Unused administrative utilities, diagnostics, network management, and system

management functions 4. All unused data and configuration files. Post-contract award, the Contractor shall provide documentation detailing all modem configurations, services, and all software/modem device protection configurations and keys, including revisions and/or patch levels. 10.19.1 FAT MEASURES The Contractor shall verify and provide documentation of physical and cyber security features, including but not limited to authentication, encryption, access control, event and communication logging, monitoring, and alarming to protect the device and configuration computer from unauthorized modification or use. The Contractor shall verify and provide documentation that all validated security Updates and patches are installed and tested at the start of the FAT. The Contractor shall verify and provide documentation that all unused software and services are removed or disabled. Post-FAT, the Contractor shall provide Utilities with a baseline of the system communications and configuration including, but not limited to cyber security features, software, protocols, ports, and services and provide documentation describing each item. The Contractor shall verify through cyber security scans of the system and provide documentation that the addition of security features does not adversely affect adequate connectivity, latency, bandwidth, response time, and throughput. The Contractor shall provide a summary table indicating each communication path required by the system. This table should include: Source device name and MAC/IP address Destination device name and MAC/IP address Protocol (e.g., TCP and UDP) and port or range of ports.


The Contractor shall perform network-based validation and documentation steps on each device, including full TCP and UDP port scans. The Contractor shall complete the cyber security scans during a simulated “normal system operation.” The Contractor shall verify that FAT procedures include validation and documentation of the requirements. 10.19.2 SAT MEASURES The Contractor shall verify and provide documentation of and changes to physical and cyber security features, including but not limited to authentication, encryption, access control, event and communication logging, monitoring, and alarming to protect the device and configuration computer from unauthorized modification or use. Post-SAT, the Contractor shall provide Utilities with a baseline of the system communications and configuration including, but not limited to cyber security features, software, protocols, ports and services and provide documentation describing any changes. The Contractor shall perform discovery activities and provide documentation of the results. The Contractor shall verify and provide documentation that any Contractor-configured or manufacturer default accounts, usernames, passwords, security settings, security codes, and other access methods are changed, disabled, or removed at the start of the SAT. The Contractor shall verify through cyber security scans of the system and provide documentation that the addition of security features does not adversely affect adequate connectivity, latency, bandwidth, response time, and throughput when connected during the SAT. The Contractor shall verify that SAT procedures include validation and documentation of the requirements. The Contractor shall provide, within 30 days unless otherwise agreed in writing, Updates and patches as security issues are identified to maintain the established level of system security. The Contractor shall create a baseline of the updated system communications and configuration including, but not limited to cyber security features, software, protocols, ports, and services and provide documentation describing any changes. The Contractor shall verify and provide documentation that any Contractor-configured or manufacturer default accounts, usernames, passwords, security settings, security codes, and other access methods are changed, disabled, or removed. The Contractor shall validate permissions and security settings on the baseline system before delivery of any Updates or replacements to maintain the established level of system security. The Contractor shall supply maintenance capabilities for delivered system security features. The Contractor shall document all additions and changes to the remote access equipment during the warranty/maintenance period.


10.20 TCP/IP The Transmission Control Protocol/Internet Protocol (TCP/IP) protocol stack is the foundation of communication on the Internet and most commercial networks. It is named after its two most important protocols: the IP and the TCP. Other important IP protocols include User Datagram Protocol (UDP), Address Resolution Protocol (ARP), and Internet Control Message Protocol (ICMP). IP operates at the network layer of a network and provides connectionless unreliable communication. IP is responsible for sending and routing packets, but is connectionless and does not guarantee transmission. TCP runs on top of the IP and provides connection-oriented reliable communication. Poor TCP/IP implementations and/or implementations that do not fully comply with TCP/IP Requests for Comments (RFCs) can result in protocol stacks that contain vulnerabilities. Buffer overflows, the inability to handle packet fragmentation, or malformed network traffic are common problems. Intentional or accidental exploitation of vulnerabilities can lead to a device/function being compromised/targeted or can produce a DoS. The Contractor shall provide physical and cyber security features, including but not limited to authentication, encryption, access control, event and communication logging, monitoring, and alarming to protect the device and configuration computer from unauthorized modification or use. The Contractor shall clearly identify the physical and cyber security features and provide the methodology(ies) for maintaining the features including the methods to change settings from the Contractor-configured or manufacturer default conditions. The Contractor shall verify that the addition of security features does not adversely affect connectivity, latency, bandwidth, response time, and throughput, including during the SAT when connected to existing equipment. The Contractor shall remove or disable all software components that are not required for the operation and maintenance of the device prior to the FAT. The Contractor shall provide documentation on what is removed and/or disabled. The Contractor shall provide, within 30 days unless otherwise agreed in writing, appropriate protocol stack updates and/or workarounds to mitigate all vulnerabilities associated with the product and to maintain the established level of system security. The Contractor shall verify and provide documentation that the SIS is certified after incorporating the security devices. The Contractor shall use a TCP/IP implementation that fully complies with the current TCP/IP RFCs. The Contractor shall deliver a product that is IPv6 compatible. The Contractor shall provide the ability to monitor traffic in an encryption scheme. The Contractor shall provide, within a 30 days unless otherwise agreed in writing period, upgrades and patches to the protocol stack as vulnerabilities are identified to maintain the established level of system security. Post-contract award, the Contractor shall provide an independent third-party security validation of the IPv6 implementations (e.g., using fuzzing techniques). Post-contract award, the Contractor shall mitigate all vulnerabilities discovered during the testing of the IPv6 implementations and provide documentation of the results.


10.20.1 FAT MEASURES The Contractor shall verify and provide documentation of physical and cyber security features, including but not limited to authentication, encryption, access control, event and communication logging, monitoring, and alarming to protect the system from unauthorized modification or use. The Contractor shall verify and provide documentation that all validated security Updates are installed and tested at the start of the FAT. The Contractor shall verify and provide documentation that all unused software and services are removed or disabled. Post-FAT, the Contractor shall provide a baseline of the system communications and configuration including, but not limited to cyber security features, software, protocols, ports and services and provide documentation describing each item. The Contractor shall verify through cyber security scans of the system and provide documentation that the addition of security features does not adversely affect adequate connectivity, latency, bandwidth, response time, and throughput. The Contractor shall provide documentation of the results of the independent third-party security validation of the IPv6 implementations. The Contractor shall verify that FAT procedures include validation and documentation of the requirements. 10.20.2 SAT MEASURES The Contractor shall verify and provide documentation of and changes to physical and cyber security features, including but not limited to authentication, encryption, access control, event and communication logging, monitoring, and alarming to protect the system computer from unauthorized modification or use. Post-SAT, the Contractor shall provide a baseline of the system communications and configuration including, but not limited to cyber security features, software, protocols, ports, and services and provide documentation describing any changes. The Contractor shall verify and provide documentation that any Contractor-configured or manufacturer default accounts, usernames, passwords, security settings, security codes, and other access methods are changed, disabled, or removed at the start of the SAT. The Contractor shall verify through cyber security scans of the system and provide documentation that the addition of security features does not adversely affect adequate connectivity, latency, bandwidth, response time, and throughput when connected during the SAT. The Contractor shall verify that SAT procedures include validation and documentation of the requirements. 10.21 VIRTUAL PRIVATE NETWORKS Virtual Private Networks (VPNs) allow for secure or trusted communications over an unsecured or untrusted infrastructure such as the Internet. The advantages of such systems are confidentiality, integrity, and availability. A poorly configured VPN creates easily exploitable vulnerabilities. The


term VPN is a very large category that includes any mechanism that creates a logical division where there is not a physical division of a network, thereby creating a subnetwork that is not accessible by members of the network who are not part of the subnetwork. This large category encroaches on the category of network partitioning. This section will concentrate on the subcategory of VPN limited to the encrypted tunneling of traffic through untrusted networks. Examples of where this type of VPN is useful are: Site-to-site control system communication over an unsecured communication line (i.e., Internet). Non-local Contractor support of a deployed control system. The primary vulnerability of any VPNs is the end-points. If one end-point is compromised, then the entire VPN is potentially compromised. The Contractor shall provide physical and cyber security features, including but not limited to multi-factor authentication (e.g., security token, known key, and/or certificate), encryption, access control, event and communication logging, monitoring, and alarming to protect the system and configuration computer from unauthorized modification or use. The Contractor shall clearly identify the physical and cyber security features and provide the methodology(ies) for maintaining the features, including the methods to change settings from the Contractor-configured or manufacturer default conditions. The Contractor shall verify that the addition of security features does not adversely affect connectivity, latency, bandwidth, response time, and throughput, including during the SAT when connected to existing equipment. The Contractor shall remove or disable all software components that are not required for the operation and maintenance of the device prior to the FAT. The Contractor shall provide documentation on what is removed and/or disabled. The Contractor shall provide, within a 30 days unless otherwise agreed in writing period, appropriate software and service updates and/or workarounds to mitigate all vulnerabilities associated with the product and to maintain the established level of system security. The Contractor shall verify and provide documentation that the SIS is certified after incorporating the security devices. The Contractor shall provide a DMZ outside of the control network for the VPN server to reside. The Contractor shall use different authentication methods for establishing control network access and VPN connection. 10.21.1 FAT MEASURES The Contractor shall verify and provide documentation of physical and cyber security features, including but not limited to multi-factor authentication (e.g., security token, known key, and/or certificate), encryption, access control, event and communication logging, monitoring, and alarming to protect the system and configuration computer from unauthorized modification or use. The Contractor shall verify and provide documentation that all validated security updates and patches are installed and tested at the start of the FAT. The Contractor shall provide a baseline of the delivered system communications and configuration including, but not limited to cyber security features, software, protocols, ports, and services and provide documentation describing each item.


Post-FAT, the Contractor shall provide a baseline of the delivered system communications and configuration including, but not limited to cyber security features, Web-based interfaces, software, protocols, ports, and services and provide documentation describing the functionality of each item. The Contractor shall verify and provide documentation that all unused software and services are removed or disabled. The Contractor shall verify that FAT procedures include validation and documentation of the requirements. 10.21.2 SAT MEASURES The Contractor shall verify and provide documentation of and changes to physical and cyber security features, including but not limited to authentication, encryption, access control, event and communication logging, monitoring, and alarming to protect the device and configuration computer from unauthorized modification or use. Post-SAT, the Contractor shall provide a baseline of the system communications and configuration including, but not limited to cyber security features, software, protocols, ports, and services and provide documentation describing any changes. The Contractor shall verify and provide documentation that any Contractor-configured or manufacturer default accounts, usernames, passwords, security settings, security codes, and other access methods are changed, disabled, or removed at the start of the SAT. The Contractor shall verify through cyber security scans of the system and provide documentation that the addition of security features does not adversely affect adequate connectivity, latency, bandwidth, response time, and throughput when connected during the SAT. The Contractor shall verify that SAT procedures include validation and documentation of the requirements. The Contractor shall provide, within a 30 days unless otherwise agreed in writing period, Updates as security issues are identified to maintain the established level of system security. The Contractor shall create a baseline of the updated system communications and configuration including, but not limited to cyber security features, software, protocols, ports, and services and provide documentation describing any changes. The Contractor shall verify and provide documentation that any Contractor-configured or manufacturer default accounts, usernames, passwords, security settings, security codes, and other access methods are changed, disabled, or removed. The Contractor shall validate permissions and security settings on the baseline system before delivery of any upgrades or replacements to maintain the established level of system security. The Contractor shall supply maintenance capabilities for delivered system security features. The Contractor shall document all additions and changes to the remote access equipment during the warranty and or maintenance period.


10.22 INTRA-PERIMETER COMMUNICATIONS Mechanisms within the perimeter may rely on intra-perimeter communication to ensure secure operation. The communication medium may consist of a physical, electrical (fly-by-wire), or wireless connection. Intra-perimeter communications are commonly overlooked for security concerns. Access to the intraperimeter communication medium constitutes access to the function or device itself with the potential for exploit and damage. The communication path must be physically secured to the same level as the components. The Contractor shall verify and provide documentation that physical communication channels are secured from physical intrusion. The Contractor shall verify and provide documentation that the range of the wireless communications is limited to within the perimeter. The Contractor shall verify and provide documentation that communication channels are as direct as possible. 10.22.1 FAT MEASURES The Contractor shall verify and provide documentation that the range of the wireless communications is limited to the required area. The Contractor shall verify and provide documentation that the physical intrusion of communication channels are detectable. 10.22.2 SAT MEASURES The Contractor shall verify and provide documentation that the range of the wireless communications is limited to within the perimeter. The Contractor shall verify and provide documentation that the physical intrusion of communication channels is detectable. The Contractor shall document the communication channels’ locations and access points. The Contractor shall provide documentation that the implemented security measures are verified according to a 30 days unless otherwise agreed in writing. 10.23 NETWORK PARTITIONING Network partitioning refers to dividing a networked system in to multiple segments to facilitate better security controls. 10.23.1 NETWORK DEVICES Network devices are used to allow communication between other networked devices and networks. The devices used to create, interconnect, segregate, protect, and isolate networks have operating systems (e.g., embedded operating system) and applications (e.g., port security, address blocking) that are susceptible to the same vulnerabilities and exploits found in most computer-based devices. Once deployed and functioning, if patch management for these devices is not rigorous, the devices will be left vulnerable to new exploits.


The Contractor shall provide a method for managing the network devices and changing addressing schemes. The Contractor shall verify and provide documentation that the network configuration management interface is secured. The Contractor shall provide ACLs, port security address lists, and enhanced security for the port mirroring. The Contractor shall remove or disable unused network configuration and management functions on the network devices. The Contractor shall provide firewall rules for inbound and outbound traffic based on deny-all rule sets. The Contractor shall provide NIDS rules and log review tools that verify the function of the firewall and detect anomalous traffic. The Contractor shall provide a NIPS architecture that will work with the communication method. The Contractor shall provide VPN concentrators configured with filters and port security. Post-contract award, the Contractor shall provide documentation on the network devices installed with security settings. 10.23.1.1 FAT MEASURES The Contractor shall validate the method for managing the network devices and changing network addresses. The Contractor shall verify security levels and provide documentation of the network configuration management interface. The Contractor shall verify the ACLs, port security address lists, and describe the enhanced security for the port mirroring. The Contractor shall scan the network ports and document traffic origination and functions for each port. The Contractor shall provide documentation of firewall rules and IDS rules. The Contractor shall verify and provide documentation of the log review tools validating IDS and firewall functions. The Contractor shall verify and provide documentation of the NIPS architecture validating operations with normal and emergency control system communications. The Contractor shall verify and provide documentation of the VPN architecture filters and port security. The Contractor shall provide upgrades and patches to maintain the established level of system security.


10.23.1.2 SAT MEASURES The Contractor shall validate the method for managing the network devices and changing network addresses. The Contractor shall verify security levels and provide documentation of the network configuration management interface. The Contractor shall verify and provide documentation of the ACLs, port security address lists, and describe the enhanced security for the port mirroring. The Contractor shall scan the network ports and document traffic origination and functions for each port. The Contractor shall verify and provide documentation of firewall rules and IDS rules. The Contractor shall verify and provide documentation of the log review tools validating IDS and firewall functions. The Contractor shall verify and provide documentation of the NIPS architecture validating operations with normal and emergency control system communications. The Contractor shall verify and provide documentation of the VPN architecture verifying filters and port security. The Contractor shall provide upgrades and patches to maintain the established level of system security. The Contractor shall provide upgrades and patches to maintain the established level of system security. The Contractor shall validate permissions and security settings on the baseline system before delivery of any Updates or replacements. 10.24 NETWORK ARCHITECTURE Network architecture is how a network is designed and segmented into logical smaller functional sub networks (subnets). Poorly designed network architectures are vulnerable to exploits. The Contractor shall provide and document secure network architecture where the higher-security zones originate communication to less-secure zones. The Contractor shall provide and document the design for all communication paths between networks of different security zones through a DMZ. The Contractor shall verify and document that disconnection points are established between the network partitions and provide the methods to isolate subnets to continue limited operations. The Contractor shall provide and document tailored filtering and monitoring rules for all security zones and alarm for unexpected traffic. The Contractor shall provide and document a DMZ that is restricted to communications where all traffic is monitored, alarmed, and filtered.


The Contractor shall provide and document outbound filtering and alarms for unexpected traffic through security zones. The Contractor shall define all sources and destinations with enforced communication origination even during restart conditions between security zones. The Contractor shall provide and document duel DMZ architectures using different products performing the same functionality running in parallel. The Contractor shall provide and document a mechanism for patching a single DMZ architecture running in a parallel configuration without disruption to the other DMZ running in parallel. Post-contract award, the Contractor shall provide network architecture documentation. 10.24.1 FAT MEASURES The Contractor shall validate and provide documentation that the higher-security zones originate communication to less-secure zones. The Contractor shall document all communication paths, including filtering, monitoring, and staging zones. The Contractor shall verify and provide documentation of disconnection points between the network partitions and validate the continuity of limited operations. The Contractor shall verify and provide documentation of tailored filtering and monitoring rules for all security zones and validate alarms for unexpected traffic. The Contractor shall verify and provide documentation of restricted communications through the DMZ and verify that all traffic is monitored, alarmed, and filtered. The Contractor shall verify and provide documentation of outbound filtering and alarms for unexpected traffic through security zones. The Contractor shall verify and provide documentation of all sources and destinations with enforced communication origination even during restart conditions between security zones. The Contractor shall verify and provide documentation of duel DMZ architectures using different products performing the same functionality running in parallel. The Contractor shall verify and provide documentation of a mechanism for patching a single DMZ architecture running in a parallel configuration without disruption to the other DMZ running in parallel. 10.24.2 SAT MEASURES The Contractor shall validate and provide documentation that the higher-security zones originate communication to less-secure zones. The Contractor shall document all communication paths, including filtering, monitoring, and staging zones.


The Contractor shall verify and provide documentation of test disconnection points between the network partitions and validate the continuity of limited operations. The Contractor shall test and provide documentation of tailored filtering and monitoring rules for all security zones and validate alarms for unexpected traffic. The Contractor shall validate and provide documentation of restricted communications through the DMZ and verify that all traffic is monitored, alarmed, and filtered. The Contractor shall validate and provide documentation of outbound filtering and alarms for unexpected traffic through security zones. The Contractor shall validate and provide documentation of all sources and destinations with enforced communication origination even during restart conditions between security zones. The Contractor shall validate and provide documentation of duel DMZ architectures using different products performing the same functionality running in parallel. The Contractor shall validate and provide documentation of a mechanism for patching a single DMZ architecture running in a parallel configuration without disruption to the other DMZ running in parallel. The Contractor shall provide upgrades and patches as vulnerabilities are identified in to maintain the established level of system security. The Contractor shall reassess permissions and security settings on the baseline configuration before delivery of any upgrades or replacement components. The Contractor shall verify and provide documentation that the network security architecture’s security profile is maintained. 11.0 USER INTERFACE REQUIREMENTS The User Interface (UI) shall provide a common “look and feel” interface for all users to interact with the SCADA/EMS. All applications, which utilize One-line diagrams (e.g. SCADA, Security Analysis), shall use the same set of one-line diagrams thus minimizing system maintenance as well as maintaining consistency of use for operators, engineers and other users. 11.1 USER INTERFACE CONSOLES The primary User Interface between the SCADA/EMS and the user shall be workstation-based consoles. Each console shall be assigned to one or more function partition (AOR), thus limiting the console Operator to only those actions defined within the assigned function partition(s). All defined function partitions shall be assignable to a single or multiple consoles. 11.2 GENERAL UI REQUIREMENTS The following types of displays shall be supported:

6. One-line diagrams of generating units, power transmission lines, sub-transmission lines, substations, switches and distribution circuits,


7. Tabular displays, many of which also include imbedded graphical data representations,

8. List based/Query based displays.

9. Graphical displays of circuits and components including, but not limited to photographs and geographical maps.

10. Graphic to include normal electric, gas and water objects.

A Windows based Full Graphics User Interface system shall be provided which adheres to the Microsoft Windows standards. The following minimum functionality shall be supported:

24. World Coordinate System based displays

25. Panning

26. Zooming

27. Decluttering

28. Multiple windows per monitor

29. Navigation window

30. Scrolling

31. Page based tabular displays

32. Support for bit-map pictures

33. Support for a large number of electrical symbols

34. Support for Overlays of Geographic information

35. DXF import and export

36. 256 Colors

37. Blinking colors

38. Post it Notes

39. Control and data entry dialogs

40. On-line help facilities

41. Dynamic database linkages for value

42. Dynamic database linkages for color

43. Dynamic database linkages for object shape or line thickness

44. Multiple font types and font sizes

45. Support page data entry on tabular displays

46. Ability to support serving of displays via a standard web browser The UI shall provide a symbolized and/or color-coded “quality” indicator field associated with each dynamic data field. In cases where a multi-quality condition develops for a single variable, the Contractor shall provide a priority scheme for determining, which condition should be displayed. A blank quality field shall be used for data quality condition in the ‘Good’ state. The UI shall provide symbolized indications for denoting those points for, which control has been inhibited. The control inhibit indicators shall be different from the quality codes described in the


previous paragraph. In addition each control inhibit indicator shall alter the color of the device to, which the indicator is attached. The UI shall provide operator guidance for all user interfaces by utilizing feedback for each step of a multi-step procedure through the use of text messages, color changes, blinking, cursor targets, or dialog boxes with soft push buttons to denote permissible options. Feedback shall be provided for all user inputs whether accepted or not accepted. All display screen targets shall be cursor selectable. The term “display screen targets" are defined as areas of each display screen format for, which interactive functions have been defined. The cursor positioning methods shall include the use of forward and backward tab keys, pointing device and cursor control keys. The UI shall provide for extensive error checking of all user entries. Invalid entries (e.g., entering an invalid point value or an illogical sequence of actions) shall be reported to the user on the display screen by an error message that shall be in plain English with no acknowledgement required or reference document required for interpretation. In addition, the invalid entries shall be highlighted. The UI shall provide the capability to correct an error without requiring the entry of data or the performance of actions that were correctly executed prior to the error. Each point in the database including calculated and non-telemetered points shall be assignable to a single partition by the user. For each point assigned to a partition, all permissible Operator actions including supervisory control, data entry, alarm control, etc., defined for that point, shall be restricted to only those consoles, which have been assigned the same partition to, which the point has been assigned. Any attempt to select a point for Operator action not assigned to the consoles assigned partition shall result in an error message on the display screen. Hardcopy messages, e.g., alarm and data entry messages for a point shall be printed only on those printers that have been assigned the points assigned partition. RTU communications control shall be assigned to partitions that are user configurable to limit the control of communications and all other actions associated with the RTU to only those operators within the area of responsibility. Only consoles with the appropriately assigned console function partition may be permitted to request and view a display that has been defined for that function partition. Methods for user selection of displays must be rapid, convenient and reliable and shall include cursor selection of a display select target area on any display screen format, including menu, graphic and tabular displays. In addition, cursor selection of an alarm message on any alarm summary display or on the alarm lines followed by actuation of a display request pushbutton, shall cause a pre-selected display for the point in alarm to appear on the display screen. The UI shall also allow user selection of a display by pressing a dedicated display request pushbutton (hard or soft key). Displays to be selectable by this means shall include but are not limited to menu displays, overview displays and alarm summary displays. Paging through multi-page displays by means of page forward and page backward pushbuttons shall be provided. Display paging shall be user definable by standard display editing procedures. The UI shall provide for a display recall pushbutton that shall cause the display that was on view immediately prior to the current display to be recalled. Displays shall also be accessible by entering a display identifier. The identifier shall be user definable through standard display editing procedures and shall consist of alphanumeric characters.


12.0 QUALITY ASSURANCE AND TESTING All materials, hardware, and software to be furnished and all work to be performed under this SOW shall be subject to Quality Assurance and Testing. No hardware or software shall be shipped until all required inspections and tests have been made, demonstrating that the SCADA/EMS conforms to the SOW and the hardware and software have been approved for shipment by Utilties. Approval of the inspection and test results, the acceptance of hardware and software, or the waiving of inspection or tests thereof, shall in no way relieve the Contractor of the responsibility for furnishing a complete SCADA/EMS that meets the requirements of this SOW. Nor shall such actions invalidate any claim that Utilties may make because of defective or unsatisfactory hardware and software. Utilties reserves the right to request additional tests at no extra charge on any work Utilties determines not to be in accordance with this SOW. Whenever the results of any inspections or tests performed by Utilties or the Contractor indicate that specific hardware, software, or documentation does not meet the SOW requirements, the Contractor shall replace, modify or add, at no cost to Utilties, hardware, software or documentation as necessary to correct any discovered deficiencies. 12.1 TEST PLANS AND PROCEDURES Test plans and procedures for both factory and field tests shall be developed and sufficiently documented by the Contractor in order to ensure that each test is comprehensive based on the functions to be exercised and that any part of the test can be repeated, if so desired. Separate test plans and test procedures shall be submitted to Utilties for approval prior to the start of the functional performance tests. The Contractor shall submit for approval a test plan and test procedures for the factory tests and all field tests at least eight (6) weeks prior to the start of the FAT and SAT. The test procedures shall be comprehensive and include the following:

a) Purpose of each test b) Function(s) to be tested c) Test set-up and test conditions for each part of the test d) Expected results/the acceptance criteria

A schedule shall be provided with the test procedures, detailing the individual tests to be performed each day. A minimum of three days shall be set aside for unstructured testing of the hardware and software by Utilties representatives. The Contractor shall maintain a complete record of the results of all factory and field tests. This record shall be corresponding to the steps enumerated in the test procedures. This record shall be provided to Utilties. 12.2 TESTING The SCADA/EMS must undergo and pass a number of functional and performance tests prior to final acceptance by Utilties. This testing shall incorporate the use of actual Remote Terminal Units (RTU) and Programmable Logic Controllers (PLC) where appropriate.


12.2.1 FACTORY ACCEPTANCE TESTS Acceptance for the purpose of shipment of the SCADA/EMS shall depend upon achieving satisfactory results for tests conducted at the Contractor's factory. The test data shall include Utilties database and display formats constructed for the project. These tests shall be conducted on the entire master station and a limited set of physical RTUs. Additional simulated RTUs shall be used to perform performance testing of the SCADA/EMS. Prior to FAT, the Contractor shall perform a complete and organized pre-FAT test to verify that the SCADA/EMS has been properly integrated and that in fact it is ready for start of FAT. Utilties shall have the option of witnessing the Pre-FAT in parts or in whole. Any problems or issues discovered in FAT shall be documented and resolved to the satisfaction of Utilties prior to SAT. Variances should be resolved prior to CSU authorizing shipment. Utilties shall have the option of verifying the retesting of all such issues in person. Prior to FAT a mutually agreed upon FAT plan shall be developed and agreed upon between Colorado Spring utility and Contractor. Factory acceptance shall include but not be limited to: The FAT requirements listed in Section 10 Security RTU communications all protocols where applicable

a. RTU Analog Verification 1. IEEE 2. Integer 3. Scaling

b. RTU Set Point Control 1. IEEE 2. Scaled Integer Output 3. Control Inhibit

c. RTU Status Verification d. RTU Status Control

1. Inhibit 2. Abnormal/Normal 3. Status With Memory

e. SOE f. Scan Rates g. Scan Enable/Disable h. Data Collision With Multiple RTU’s i. Communications Error Checking

Area of Responsibly Testing (AOR) Alarm Verification:

1. Limit Testing 2. Rate Of Change 3. Logging 4. Historical Logging 5. Alarm operator instructions

Automatic Generation Control


12.2.2 SITE ACCEPTANCE TESTING The Site Acceptance Testing shall consist of the important subset of the FAT demonstrating the operation of the SCADA/EMS hardware and the basic system functions under normal operation. The SAT test shall concentrate on those areas of system operations that are simulated or only partially tested in the factory. For example, system timing and loading while communicating with a full complement of RTUs and the system reaction to actual field conditions shall be tested. Any problems or issues discovered in SAT shall be documented and resolved to the satisfaction of Utilties prior to Availability Testing. Utilties shall have the option of verifying the retesting of all such issues. Utilties will conduct the SAT tests with support provided by the Contractor. The SAT requirements listed in section 10 Security 12.2.3 AVAILABILITY TESTING Following the SAT, a 1000-hour test shall be conducted to verify the ability of the SCADA/EMS to meet its availability requirements. All variances against the SCADA/EMS must be resolved prior to the start of the test. The responsibility for the conduct of the availability test is Utilties responsibility. The test consists of normal system operations without special test equipment or procedures. Utilties personnel shall maintain all reports and records defined in the availability test procedure. Utilties shall operate the SCADA/EMS according to the procedures described in the approved Contractor documentation. The Contractor shall perform all preventive and remedial maintenance. The SCADA/EMS shall be deemed available if it is functional for normal operations. Examples of the SCADA/EMS being unavailable shall be the failure of both the prime and backup software applications or hardware, thus rendering the SCADA/EMS not fit for operational use. Examples of problems that shall not constitute the system as “unavailable” are database and configurations issues where the SCADA/EMS is functioning properly, however has been programmed with improper data. In the event of failure of non-redundant devices such as consoles or printers, the SCADA/EMS shall be deemed unavailable if more than one device is not functioning 12.3 VARIANCES A variance report shall be prepared each time a deviation from SOW requirements is detected or a Problem in the functionality of the SCADA/EMS is encountered during any of the system tests. The report shall include a complete description of the variance, including the reference to this SOW and the test procedure and a description of the test conditions at the time the variance was detected. The Contractor shall document the corrective actions taken to eliminate each variance by providing sufficient detail for the Utilties representative to determine the necessity for and extent of the re-testing of the offending function. This shall include an evaluation of any interaction with previously tested functions, and of any documentation that may require updating as a result of the corrective action. The variance report shall be completed when the Contractor and Utilties representatives acknowledge correction of the variance with signatures. The variance reports shall be available to Utilties at all times and shall be submitted by the Contractor to Utilties at the conclusion of each test.


Appendix A

SCADA/EMS System Sizing System Sizing Initial Sizing Ultimate Sizing Platform Redundancy Required (Yes/No) YES Hardware Manufacturer Preference (Dell, IBM, HP, etc.)

NONE

Server Operating System Preference (Windows, Linux, or Unix)

Windows/Linux

RDBMS Preference (Oracle, MS SQL, MySQL) Oracle Backup Solution Required (Yes/No) YES GPS Time & Frequency Unit (Yes/No) YES Firewalls Required (Yes/No) USER SUPPLIED No. of B/W Printers 0 No. of Color Printer Ports (SU will supply printers)

4

Backup Control Center Redundancy Required (Yes/No) See Section 8.0 No. of Operations Consoles-local 4 Monitors No. of Operations Consoles-local 3 Monitors No. of Operations Consoles-local 2 Monitors 5 No. of Operations Consoles-local 1 Monitor Test System Redundancy Required (Yes/No) No No. of Operations Consoles-local 4 Monitors No. of Operations Consoles-local 3 Monitors No. of Operations Consoles-local 2 Monitors 2 No. of Operations Consoles-local 1 Monitor Development System Redundancy Required (Yes/No) No. of Operations Consoles-local 4 Monitors No. of Operations Consoles-local 3 Monitors No. of Operations Consoles-local 2 Monitors 3 No. of Operations Consoles-local 1 Monitor Corporate Historian System (Yes/No/Use Existing)

Use existing

MMI/Consoles/Mapboard/Miscellaneous


System Sizing Initial Sizing Ultimate Sizing Equipment No. of Operations Consoles-local 4 Monitors 2 No. of Operations Consoles-local 3 Monitors 6 No. of Operations Consoles-local 2 Monitors 5 No. of Operations Consoles-local 1 Monitor 4 No. of Remote PC Consoles (Software only) 6 No. of Strip Chart Pens No. of Map-board Status Points No. of Map-board Analog Points Local I/O (No. of Input Analog Points) 10 Local I/O (No. of Output Analog Points) 10 Projection System Interface Required (Yes/No)

YES

Other Interface Other Interface FEP/DAC No. of Leased Line Comm. Channels 40 No. of Bell 202T Modems 96 No. of Other Modems (If any) 32 Flash Pole No. of Scanned RTUs (Total) 95 Electric

120 Gas 240 Water

2 times initial quantities

No. of IP based RTUs (If any) 2 2 times initial quantities

No. of Radios for RTU Communications 40 Master RADIOS


RTU Protocols (Please list additional Protocols provided)

DNP 3.0 50 150 DNP TCP 5 2 times initial

quantities Vancomm 50 0 Modbus RTU 275 2 times initial

quantities ModBus TCP 5 2 times initial

quantities SCADA No. of Telemetered Analog Points 4000 Electric

1000 Gas 3500 Water


No. of Telemetered Status Points 8000 Electric 6000 Water


No. of Calculated Points 8500 Electric 500 Water 1000 Gas


No. of Control Points 5000 Electric 2 times initial


System Sizing Initial Sizing Ultimate Sizing 3000 Water 400 Gas

quantities

No. of Accumulator Points 88 2 times initial quantities

Historical Archival No. of Analog Points Archived per Hour 8500 2 times initial

quantities No. of Status Points Archived per Hour 1400 2 times initial

quantities Retention Period of Hourly Data (Months) 72 2 times initial

quantities Corporate HIS/Web Server Required (Yes/No) YES Number of Concurrent HIS/Web Users 40 2 times initial

quantities Third-party Historian Interfaces (OSIsoft PI, eDNA, etc.)

OSIsoft PI 2 times initial quantities

Total Historized Points 50,000 2 times initial quantities

Data Links & ISO/Market Interfaces No. of ICCP Links 5 2 times initial

quantities ISO Interfaces (MISO, ERCOT, CALISO, etc.) 0 Market System Interfaces (Structure, OATI, etc.)

OATI

OMS Interface (Name of OMS) GE Small world OPTIONAL

Applications AGC - No. of Units 15 2 times initial

quantities AGC - No. of Units on AGC Control 10 2 times initial

quantities Number of Control Areas (For multi-area dispatch)

0

Economic Dispatch (Yes/No) Yes Reserve Monitor (Yes/No) Yes Production Cost (Yes/No) Yes NERC Monitoring (Yes/No) Yes Load Shed and Restoration (Yes/No) Yes Market System Applications Transaction Management System (Yes/No) Yes

Optional

Tagging Interface to OATI - Requires OATI WebData licensed by Utilities (Yes/No)

Yes Optional


System Sizing Initial Sizing Ultimate Sizing Market Operating System – ERCOT – XML Interface (Yes/No)

No

Market Operating System – MISO – XML Interface (Yes/No)

No

ERCOT – Control Algorithm (Yes/No) No Generation Scheduling and Dispatch Short-term Load Forecast (Yes/No) Yes

Optional

Transaction Evaluation – Economy A (Yes/No) Yes Optional

Transaction Evaluation – Economy B (Yes/No) Yes Optional

Unit Commitment (Yes/No) Yes Optional

Network Analysis No. of Internal Buses 200 2 times initial

quantities No. of External Buses 200 2 times initial

quantities Network Topology Processor (Yes/No) Yes Power Flow (Yes/No) Yes

Optional

Contingency Selection (Yes/No) Yes Optional

Contingency Analysis (Yes/No) Yes Optional

State Estimator (Yes/No) Yes Optional

Dynamic Penalty Factors (Yes/No) Yes Optional

Short Circuit Analysis – Balanced (Yes/No) Yes Optional

Available Transfer Capability (Yes/No) Yes Optional

Optimal Power Flow (Yes/No) Yes Optional

Security Dispatch (Yes/No) Yes Optional

Voltage/Var Scheduler (Yes/No) Yes Operator Training Simulator No. of Operations Consoles-local 4 Monitors No. of Operations Consoles-local 3 Monitors 1 No. of Operations Consoles-local 2 Monitors No. of Operations Consoles-local 1 Monitor


Appendix B

Performance & Response Requirements Performance Test Scenarios Steady State High Activity Test Period 15 minutes 15 minutes No. of Analogs Changing every scan 20% of all 50% of all No. of Status Points Changing every scan 20% of all 50% of all No. of ICCP Analogs (imports per 10 sec.) 500 1000 No. of ICCP Status (imports per 10 sec.) 500 1000 No. of ICCP Analogs (exports per 10 sec.) 500 1000 No. of ICCP Status (exports per 10 sec.) 500 1000 No. of alarms generated per second 50 1000 Periodicity of display requests from all consoles

15 second 10 second

Control Request from at least 3 consoles 2 per minute 10 per minute AGC Controls issued to Units 50% of all units 100% of all

units UC/TE Study request 1 per 5 minute 2 per 5 minute Historical Archival of Analogs 1000 points per

minute 2000 points per

minute Response Requirements Steady State High Activity Display Call-up time---------One-lines 1 sec. 1.5 sec. Display Call-up time---------SCADA Tabulars 1 sec. 1.5 sec. Display Call-up time---------Alarming Tabulars 2 sec. 2.5 sec. Historical Reports 5 sec. 5 sec. Control Completion time (local RTU) 1 sec. 1.5 sec. Alarm Acknowledgment time 1 sec. 1.5 sec. Alarm Delete time 1 sec. 1.5 sec. Applications-----------UC-168 hour study 60 sec. 120 sec. Applications-----------Load Flow 4 sec. 8 sec. Applications-----------State Estimator 10 sec. 15 sec. Applications-----------CA-25 Full contingencies 60 sec. 90 sec. Applications-----------ITS-insert one schedule 2 sec. 3 sec. Applications-----------ITS-Build AGC composite 1 sec. 2 sec. Applications-----------STLF-24 hour forecast 10 sec. 15 sec.


Loading Requirements Steady State High Activity FEP/DAC Servers <20% <60%. SCADA Servers <20% <60%. APPS Servers <20% <60%. Historian Servers <20% <60%. ICCP/Comm. Servers <20% <60%. Operator Consoles <20% <60%. Local Area Networks <5% <10%

ATTACHMENT 1 EXHIBIT A SCADA/ENERGY ...

Documents