situational awareness test bed (situtb) visualization of 220/33 kv (off-campus) substation and...

SituTB Specification

of 115

Detailed Specifications

Situational Awareness Test Bed (SituTB)

“This Tender Document shall be used only for

the purpose of responding to this tender and

cannot be used for any other purpose without

written consent from CPRI.”


of 115

Contents 1 Introduction .......................................................................................................................................... 8

2 Abbreviations ........................................................................................................................................ 8

3 Intended SituTB Use Cases .................................................................................................................... 9

4 Architecture ........................................................................................................................................ 10

4.1 Architectural Principles ............................................................................................................... 10

4.2 ADMS Configuration ................................................................................................................... 12

4.2.1 Production Environment ..................................................................................................... 12

4.2.2 Simulator Environment ....................................................................................................... 13

4.2.3 Program Development System Environment ..................................................................... 13

4.2.4 Management Environment ................................................................................................. 14

4.2.5 System Components Overview ........................................................................................... 15

5 CIM Compliant Adapters ..................................................................................................................... 16

6 Supervisory Control and Data Acquisition .......................................................................................... 17

6.1 RTU Data Acquisition .................................................................................................................. 17

6.1.1 RTU Protocols ...................................................................................................................... 17

6.1.2 Data Polling ......................................................................................................................... 17

6.1.3 Report by Exception ............................................................................................................ 18

6.1.4 Unsolicited Reporting.......................................................................................................... 18

6.1.5 Data Integrity Scan .............................................................................................................. 18

6.1.6 On-Demand Data Acquisition ............................................................................................. 19

6.2 Data Processing ........................................................................................................................... 19

6.2.1 Data Quality ........................................................................................................................ 19

6.2.2 Areas of Responsibility ........................................................................................................ 19

6.2.3 Analog Data Processing ....................................................................................................... 20

6.2.4 Status Data Processing ........................................................................................................ 21

6.2.5 Processing of Non-Telemetered Data ................................................................................. 21

6.3 Supervisory Control ..................................................................................................................... 22

6.3.1 Digital Status Control .......................................................................................................... 22

6.3.2 Set-Point Control ................................................................................................................. 23

6.3.3 Raise/Lower Control ........................................................................................................... 23


of 115

7 User Interface ...................................................................................................................................... 23

7.1 User Interface Guidelines............................................................................................................ 23

7.1.1 Guidelines on User-System Interactions ............................................................................. 23

7.1.2 Guidelines on Information Presentation ............................................................................ 24

7.1.3 Look-and-Feel ...................................................................................................................... 25

7.2 Display System Requirements..................................................................................................... 25

7.2.1 General Requirements ........................................................................................................ 25

7.2.2 Overlays and Data Sets ....................................................................................................... 25

7.2.3 Bit-Map “Picture” Displays .................................................................................................. 26

7.2.4 Queries-Based Displays ....................................................................................................... 26

7.2.5 Help Function ...................................................................................................................... 28

7.2.6 List Searching Capabilities ................................................................................................... 29

7.3 Screen and Windows Features ................................................................................................... 29

7.3.1 Windows ............................................................................................................................. 29

7.3.2 Date and Time ..................................................................................................................... 30

7.3.3 Pushbuttons (Soft Keys) ...................................................................................................... 31

7.3.4 Keyboard Functions ............................................................................................................ 31

7.3.5 Toolbars............................................................................................................................... 31

7.3.6 Dialog Boxes ........................................................................................................................ 32

7.3.7 Information boxes ............................................................................................................... 32

7.4 Data Representation ................................................................................................................... 32

7.4.1 Data Attribute Representation ........................................................................................... 32

7.4.2 Graphical Data Representation ........................................................................................... 34

7.5 Trend Displays ............................................................................................................................. 35

7.5.1 Trending Capabilities ........................................................................................................... 35

7.5.2 Precise Reading of Curve Values ......................................................................................... 36

7.5.3 Selection of Trending Data and Parameters ....................................................................... 37

7.6 Dispatcher Functions .................................................................................................................. 38

7.6.1 Display Call-Up .................................................................................................................... 39

7.6.2 Supervisory Control ............................................................................................................. 41

7.6.3 Deactivate/Activate RTUs ................................................................................................... 42


of 115

7.6.4 Deactivate/Activate Data Points ......................................................................................... 43

7.6.5 Manual Data Entry .............................................................................................................. 43

7.6.6 Advanced Visualization Features ........................................................................................ 44

7.6.7 Printing of Information and Displays .................................................................................. 45

7.6.8 Block Selection and Rubber Banding .................................................................................. 45

7.6.9 Access Security .................................................................................................................... 45

7.6.10 Data Access Spreadsheet .................................................................................................... 46

7.7 Areas of Responsibility ................................................................................................................ 46

7.8 Tagging ........................................................................................................................................ 47

7.8.1 Tag Attributes ...................................................................................................................... 47

7.8.2 Tag Summary ...................................................................................................................... 48

7.8.3 Tag Removal ........................................................................................................................ 49

7.9 Event and Alarm Management ................................................................................................... 49

7.9.1 Events .................................................................................................................................. 49

7.9.2 Alarms ................................................................................................................................. 50

7.9.3 Alarm and Event Processing ................................................................................................ 51

7.9.4 Alarm Summaries ................................................................................................................ 53

7.9.5 Alarm and Event Message Formats .................................................................................... 54

7.9.6 Alarm and Event Records .................................................................................................... 55

8 Data Historian ..................................................................................................................................... 56

8.1.1 User Access ......................................................................................................................... 56

8.1.2 Function Access ................................................................................................................... 57

8.1.3 Automated Data Capture .................................................................................................... 57

8.1.4 Data Quality Codes .............................................................................................................. 57

8.2 Historical Databases .................................................................................................................... 57

8.2.1 Capabilities of the Historical Databases .............................................................................. 58

8.2.2 Historical Points .................................................................................................................. 58

8.2.3 Manual Entry of Historical Data .......................................................................................... 59

8.2.4 Reports ................................................................................................................................ 59

9 Software .............................................................................................................................................. 60

9.1 Operating System Software ........................................................................................................ 60


of 115

9.2 System Software Requirements .................................................................................................. 60

9.2.1 Programming Tools ............................................................................................................. 60

9.2.2 Time and Calendar Synchronization Service ....................................................................... 61

9.2.3 System and Network Management Software ..................................................................... 61

9.2.4 Virus and Malware Protection Software ............................................................................. 62

9.2.5 Operating System Security Patch Update Facility ............................................................... 63

9.2.6 Patch Update Facility .......................................................................................................... 63

9.2.7 Automatic System and Data Backup ................................................................................... 63

9.2.8 Remote Maintenance Access .............................................................................................. 64

10 Hardware ............................................................................................................................................. 64

10.1 Servers and Auxiliary Memory .................................................................................................... 64

10.2 Front-End Processors .................................................................................................................. 66

10.3 Communication Network Processors (Authentication Server) ................................................... 66

10.4 Backup and Archive Storage ....................................................................................................... 66

10.5 Workstations ............................................................................................................................... 67

10.5.1 Monitors .............................................................................................................................. 67

10.5.2 Tower Processor.................................................................................................................. 68

10.6 Firewalls ...................................................................................................................................... 68

10.7 Video Display Wall ...................................................................................................................... 70

10.7.1 Installation .......................................................................................................................... 70

10.7.2 Graphics Display Server....................................................................................................... 71

10.7.3 Video Wall Maintenance ..................................................................................................... 73

10.7.4 Projection Cube Characteristics .......................................................................................... 73

10.8 RTUs ............................................................................................................................................ 74

10.8.1 Data Acquisition .................................................................................................................. 74

10.8.2 RTU Architecture ................................................................................................................. 77

10.8.3 DC Power Supply ................................................................................................................. 79

10.8.4 Local Control Panel ............................................................................................................. 81

10.8.5 RTU Software ...................................................................................................................... 81

10.8.6 Enclosures ........................................................................................................................... 82

10.9 Gateway ...................................................................................................................................... 82


of 115

10.10 Substation Surveillance Equipment ........................................................................................ 83

10.10.1 Video Manager Server .................................................................................................... 83

10.10.2 IP Cameras ...................................................................................................................... 84

10.11 Time and Frequency Facility ................................................................................................... 84

10.12 Cellular Modem ....................................................................................................................... 85

10.13 Multifunction Printers ............................................................................................................. 86

11 ADMS Functionality ............................................................................................................................. 86

11.1 Operating Modes ........................................................................................................................ 86

11.2 Network Operations Model ........................................................................................................ 87

11.3 Network Topology Processor ...................................................................................................... 88

11.4 Dynamic Network Coloring ......................................................................................................... 89

11.5 Unbalanced Power Flow ............................................................................................................. 89

11.5.1 Input .................................................................................................................................... 89

11.5.2 Output ................................................................................................................................. 90

11.6 Fault Location .............................................................................................................................. 91

11.7 Fault Location Isolation and Service Restoration (FLISR) ............................................................ 91

11.8 Volt/Var Control .......................................................................................................................... 93

11.9 Feeder Reconfiguration .............................................................................................................. 94

11.10 Outage Management .............................................................................................................. 94

11.10.1 Unplanned Outages ........................................................................................................ 95

11.10.2 Management Tools ......................................................................................................... 96

11.10.3 Crew Management ......................................................................................................... 96

11.10.4 Reliability Indices ............................................................................................................ 97

11.10.5 Historical Reporting ........................................................................................................ 97

12 System Simulator ................................................................................................................................ 98

12.1 Simulator Utilization Modes ....................................................................................................... 98

12.2 Dynamic Power System Model ................................................................................................... 98

12.3 Scenario Builder ........................................................................................................................ 100

12.4 Simulation Management........................................................................................................... 101

12.5 Database and Display Editor ..................................................................................................... 102

12.6 Database Creation and Editing.................................................................................................. 102


of 115

12.7 Display Creation and Editing ..................................................................................................... 102

13 System Interfaces .............................................................................................................................. 103

14 System Sizing ..................................................................................................................................... 104

15 System Performance ......................................................................................................................... 105

15.1.1 Normal Activity ................................................................................................................. 106

15.1.2 High Activity ...................................................................................................................... 106

15.1.3 System Start-Up ................................................................................................................ 107

15.1.4 System Response Times .................................................................................................... 107

16 Implementation and Contracting Responsibilities ............................................................................ 108

16.1 Responsibilities of Contractor ................................................................................................... 108

16.2 Responsibilities of CPRI ............................................................................................................. 111

17 Feature Quantities: ........................................................................................................................... 113

18 Mapping Functions to Features ........................................................................................................ 114

19 ADMS Supplier Qualification Criteria ................................................................................................ 115

Tables Table 14-1: System Sizing Components .................................................................................................... 104

Table 15-1: Maximum System Response Times........................................................................................ 107

Table 17-1 SituTB Feature List .................................................................................................................. 113

Table 18-1 SituTB Function vs. Feature Matrix ......................................................................................... 114

Figures Figure 4-1 SituTB Architecture, System Components, and Interfaces ........................................................ 10


of 115

1 Introduction The Situational Awareness Test Bed (SituTB) consists of hardware and software associated with an

Advanced Distribution Management (ADMS) system. The ADMS shall provide the following functionality:

Supervisory Control and Data Acquisition (SCADA)

User Interface

Historical Data Capture

ADMS functions such as:

o Network Topology Processor (NTP)

o Unbalanced Power Flow (UBPF)

o Fault Location

o Fault Location Isolation and Service Restoration (FLISR)

o Volt/Var Control (VVC)

o Feeder Reconfiguration

o Outage Management

System Simulator

Database and Display Editor tools

It is within this context that the SituTB specifications are presented from the perspective of specifying an

ADMS. Thus, as used throughout the report, the term ADMS or System is to be considered synonymous

with SituTB.

2 Abbreviations

ADMS Advanced Distribution Management System

CAIDI Customer Average Interruption Frequency index

CCTB Communications and Computing Test Bed

DATB Distribution Automation Test Bed

DERTB Distributed Energy Resources Test Bed

DMS Distribution Management System

EVTB Garage of the Future Test Bed

FDI Fault Detection

FLISR Fault Location Isolation and Service Restoration

HSR High-availability Seamless Redundancy (IEC 62439-3 clause 5)

IVVC Integrated Volt/Var Control

MAIFI Momentary Average Interruption Frequency Index

NTP Network Topology Processor

OMS Outage Management System

PSTB Power System Test Bed

PTZ Point-Tilt-Zoom


of 115

SAIDI System Average Interruption Duration Index

SAIFI System Average Interruption Frequency Index

SASTB Substation Automation System Test Bed

SCADA Supervisory Control and Data Acquisition

SituTB Situational Awareness Test Bed

SNMP Simple Network Maintenance Protocol

UBLF Unbalanced Power Flow

3 Intended SituTB Use Cases The SituTB will be used to support the following use cases as a minimum:

Demonstration of FLISR to visitors, utility personnel, and trainees

Use of offline data / simulation mode for comparative studies

Real-time monitoring of the CPRI power system network’s power consumption

Visualization of 220/33 kV (off-campus) substation and 33/11kV (on-campus) substation

Volt/Var control simulation

Hosting of ADMS functions from alternative (third-party) suppliers

Training for power system operators

Practicing outage management

Collection of metrics such as SAIDI and SAIFI

Display of substation videos


of 115

4 Architecture This section specifies the ADMS architecture requirements.

Figure 4-1 SituTB Architecture, System Components, and Interfaces

4.1 Architectural Principles

The configuration of the ADMS shall consist of a distributed computing environment with an open-

system and highly secure architecture. The system architecture shall be open internally and externally to

hardware or application software additions, whether supplied by the original system supplier or

obtained from third party vendors, both for capacity expansion and for upgrading functionality, without

affecting other ADMS components or its operation.

To be recognized as a true open computer system, all internal communications among the ADMS

processors and all external communications between the ADMS and other test bed computer systems

shall be based on widely accepted and published international or industry standards that are

appropriate and relevant to the open systems concept.

The following distributed and open-system design concepts shall apply:

SASTB DATB

Situational Awareness Test Bed – System Components

SCADA

CollectProcess

Store

Data Acquisition Front End

(DAFE)

Web Server System(WSS)

ADMS Access via

web browser(Read Only)

ADMS Applications

NTPUBPFFLISRV-V-C

ReconfigOMS

User Interface

Video WallWorkstation

Printers

Modeling

Maintain the Network

Operational Model(NOM)

Data Historian

(DHS)

Long term archive of

data as received by

SCADA

Remote Access(RAS)

Contractor maintenance interface to

ADMS

CPRI Network

Router -VPNw/Firewall

Small Simulation

Realy Test Set

Simulator in SGTB

Generic Direct

To any CPRI location with

Campus Network Access

Generic External

To any CPRI location without Network Access

Transformer Pad

To 11kV devices on the SGTB XFMR Pad

Router -VPN Router -VPN Router -VPN Cellular VPN

Substation Automation

System

IEC-104 to IEC 61850 Gateway

Router -VPNRouter -VPN

Environment

Production

Simulation

Programming

Management

Archive

SAS Remote Station

IEC-104 to IEC 61850 Gateway

Router -VPN

CPRI Corp Firewall

Cellular to Internet


of 115

1. The System configuration shall be based on Open Systems Standards supporting a clear

migration path toward an open architecture in which the software is totally transparent of

the hardware, such that any hardware adhering to these standards can be

replaced/upgraded with functionally similar hardware not necessarily manufactured by the

original manufacturer.

2. Dependent upon the supplier’s design, the major System environments shall be distributed

to different sets of server processors such as SCADA, Application, Front-End, and User

Interface processors. In this respect, whereas the servers (processors) shall be highly reliable

and exhibit high availability characteristics, there is no specific requirement for redundancy.

3. Each server or processor unit shall be replaceable/upgradeable by simple change out

without affecting the rest of the System and without requiring any software modification.

Replacing/upgrading any processor shall be totally transparent to the functionality of other

subsystems that reside on other processing units. Each disk drive subsystem shall be

dedicated to a single processor.

4. The environment that acquires data from a field device associated with a SCADA point shall

be responsible for obtaining, retaining, and forwarding the value when requested.

5. All processing units of the System shall be interconnected using industry standard Local Area

Networks (LANs). These LANs shall support exchange of data between the various system

components such as servers, user workstations, communications processors, terminals,

gateways, stand-alone disks, removable media, etc. The System components may be

dissimilar in architecture and/or operating systems. Each LAN shall operate at 1 Gbps as a

minimum. Whereas the LANs need not be redundant, components connected to a LAN shall

be dual-ported so that they are capable of being connected to a redundant LAN.

6. All internal communications between the System processors and all external

communications between the ADMS and other test bed computer systems shall be based on

widely accepted international or industry standards which are appropriate and relevant to

the open systems concept.

7. For server processors, the same revision of a widely accepted and latest version of the

Windows Server or Linux operating system shall be used. The operating systems shall be

registered products with long term support. The Linux operating system shall include long

term support from a Recognized Distribution such as Red Hat Enterprise Linux or SUSE Linux

Enterprise Server. Alternatively, the latest Windows Server operating system, with long

term support from Microsoft, shall be used. For workstation processors, the latest Windows

operating system (e.g., Windows 10) shall be used. All software shall be written in standard

ANSI high-level languages. The ADMS shall be designed to provide the highest possible level

of hardware and software independence using standard products, standard toolkits, and


of 115

modular design principles. All System software shall be the latest version. All third-party

software shall be compatible with the main ADMS software.

8. Expandability shall be provided using a hardware and software platform that allows for

vertical growth, and a configuration that allows horizontal growth and distributed

computer/server support.

9. Expansion of the power system models in the ADMS shall be a simple and quick task. The

expansion procedure shall be provided in a software maintenance manual.

4.2 ADMS Configuration

The ADMS consists of several environments:

1. Production Environment (PE)

2. Simulator Environment (SE)

3. Program Development System (PDS) Environment

4. Management Environment (ME)

5. Backup and Archiving Environment (BAE)

Each of these environments consists of one or more systems, which may be replicated across several

environments.

4.2.1 Production Environment

The Production Environment (PE) is the environment within which all power systems operations are run.

This critical environment consists of a monitoring and control system that is characterized by high-speed

data collection and presentation functions. In this respect, it shall collect, process, and store real-time or

near real-time data from the following data sources:

1. Remote Terminal Units (RTUs) located at CPRI on and off-campus substations

2. Substation Automation System Test Bed (SASTB)

3. Distribution Automation Test Bed (DATB)

4. AMI head-end systems that are a part of CPRI’s SG Lab

5. Substation IP cameras

The PE includes several System components (sub-systems) such as:

SCADA System

Data Acquisition Front-End System

Applications System


of 115

Data Historian System

The PE database1 shall be accessible by all its System components and, in this respect, all data used

within the Production Environment, presented to its users, and transmitted to external computer

systems and users shall be derived from this database. For a brief overview of the System components

referenced above and others, refer to Section 4.2.5).

4.2.2 Simulator Environment

The Simulator (SE) environment shall include hardware dedicated to hosting software that replicates the

PE functionality of the ADMS and allows this functionality to be used to operate power system networks

for which the characteristics and behavior are simulated. Within this context, the SE environment may

be used to not only train operations personnel, but also demonstrate the ADMS functions to electric

utilities and all other interested parties. Component sub-systems shall support the capability of the SE to

be initialized from System real-time snapshots as well as historical save cases.

4.2.3 Program Development System Environment

The Program Development System (PDS) environment shall include all necessary software and tools to

develop, test, and modify System applications, databases, displays, and reports. It shall also support

development and testing of CPRI applications.

The PDS shall be able to acquire data directly from a data source such as an RTU connected to it or via a

test set to verify correct configuration of the database and display linkage. Control commands issued

from the PDS shall be communicated to field devices only if those devices are directly and solely

attached to the PDS, i.e., commands to devices communicating through the PE or other System

components shall be disabled even though the PDS may be collecting data from these devices via the PE

or other System component.

The Contractor shall establish the PDS at CPRI’s SituTB site at an early stage of the project to allow CPRI

to perform database and display development.

The PDS shall be initially delivered with basic database and display generation capabilities and shall

include the Contractor’s software and support tools sufficient to perform the database and display

development. In addition, the PDS shall include the Contractor’s standard applications and base models.

The PDS shall also be used early by the Contractor to test and debug RTU protocol and interface issues.

1 This specification uses the terms “database” and “databases” interchangeably. Unless specifically stated

otherwise, either term refers to all information stored in the System relating to the power system and the System itself. This specifically includes information describing the power system, information describing the System, and execution parameters of System applications. This also specifically includes both “real-time” and “historical” information.


of 115

4.2.4 Management Environment

The System shall include a centralized Management Environment (ME). Services shall be provided for

the configuration, control, and monitoring of System resources including processors, peripheral devices,

network devices, applications, and databases. The ME functions shall be accessible from any node in the

System and shall be able to manage resources anywhere in the network.

The System management function shall have the capability to control any number of resident

application systems by the installation of different driving tables that define the makeup of an

application system, the assignment of processes to processors, and its requirements for network

resources. This shall be achieved without requiring source code changes. The System management

function shall facilitate the orderly start-up, shutdown, and tuning of any System resource without

affecting the availability of the other elements of the System.

Commercially available standards-based network management products employing SNMP version 3

(SNMPv3) are required. All System resources shall include SNMP agents for use by the System

management function and by Contractor-supplied management tools. A user interface that is graphics

rather than command-line based shall be provided.

It shall be possible to add resources outside the System to the management scheme. This may require

modifications to the outside applications, databases, processors, or devices, such as the addition of

agents or other software plug-ins. Such modifications will be performed outside this contract. The

System management function, however, shall include documentation describing the interface with both

System and non-System resources.

All errors and other events detected by the ME functions shall be recorded and reported to the user.

Fatal errors shall be reported as alarms. Where an error causes the System management function to

reconfigure the System (such as bring a backup resource to the primary state), the reconfiguring action

shall be reported as an alarm along with the error report.

Such error reports and other log messages shall be able to be recorded for audit and troubleshooting

purposes.

4.2.4.1 Backup and Archiving Environment

Services to back up, archive, and restore all ADMS software, operating system image, displays, and data

independently of its location shall be provided as part of a Backup and Archiving Environment (BAE). The

backup information shall include ADMS and network configuration information, such as database table

and queue sizing and router tables.

Once initiated, the BAE services shall automatically back up all information needed to recover from

failures or data corruption without manual intervention by users, except for replenishment of

removable media.

Although the devices being backed up may be physically separate, the backup system shall be managed

centrally.


of 115

4.2.5 System Components Overview

4.2.5.1 SCADA System

The SCADA system shall consist of a high-availability non-redundant server characterized by hosting

high-speed data collection and presentation functions. The SCADA System collects, processes, and stores

real-time data collected via the Data Acquisition Front-End (DAFE) system.

4.2.5.2 Data Acquisition Front-End System

The Data Acquisition Front End (DAFE) system shall consist of a high-availability non-redundant

processor hosting software that supports SCADA communication with RTUs, the SASTB, and the DATB.

4.2.5.3 Web Server System

The Web Server System (WSS) shall consist of a high-availability non-redundant server. It shall host

software allowing external users with appropriate log-in credentials and permissions to request or view

data provided by the ADMS. Users shall access web pages made available on the server using standard

browsers installed on CPRI laptop or desktop PCs and/or mobile devices connected to CPRI’s WAN. For

all such connections, there shall be no possibility of any user being able to send data or control signals to

the ADMS.

4.2.5.4 Applications System

The Applications System (AS) shall consist of the software that provides the ADMS Network Topology

Processor (NTP), Unbalanced Power Flow (UBLF), Fault Location, Fault Location, Isolation and Service

Restoration (FLISR), Volt/Var Control (VVC), Feeder Reconfiguration, and Outage Management

functionality. The software shall exhibit high-availability as well as high-speed characteristics. Provided

the software meets CPRI’s specified capacity and performance requirements, the Contractor may host

the software on the SCADA server or on its own dedicated (non-redundant) server.

4.2.5.5 User Interface System

The Contractor shall provide all hardware and software supporting the ADMS user interface system. This

includes user interface facilities consisting of operator and engineering/maintenance workstations,

video wall display, and printers. The user interface system shall allow users to interoperate with the

ADMS functions as viewed via workstation and video wall displays. It shall also allow users to select and

print the output of such functions. In this respect, printers shall be shared network devices, so that a

user shall be able to direct any printed output to any accessible printer.

4.2.5.6 Modeling System

A Modeling System is required for the maintenance of the Network Operational Model (NOM), i.e., the

ADMS database such as that which represents the power system network being monitored and

controlled by the ADMS, the associated ADMS displays, and the DAFE data points. The Modeling System


of 115

shall enable a single source of truth for model information such that updates shall be made once, in one

place and in one place only, for use by all ADMS components and functions.

In addition to schematic diagrams, the modeling tool shall provide interactive graphical representations

of the power system network to help visualize its connectivity and physical layout characteristics.

4.2.5.7 Data Historian System

The Data Historian System (DHS) functions shall execute on a high-availability non-redundant server. The

Data Historian shall store real-time data received from the ADMS Production System that will be made

accessible to users with appropriate log-in credentials and permissions.

4.2.5.8 Remote Access System

A Remote Access System (RAS) is required to support the ongoing maintenance of the ADMS by the

Contractor as part of the ongoing upkeep of the system. Hardware and software shall be supplied such

that remote access can be made consistent with the proposed security features.

5 CIM Compliant Adapters To support integration with other systems, the ADMS shall be capable of utilizing IEC 61968/61970

compliant adapters, i.e., CIM/XML using SOAP, JMS, etc.

The implementation of these adapters, supporting CIM export/import capabilities, shall conform to all

security requirements in these specifications. The Contractor’s adapters shall support the latest versions

of the CIM Schema for CIM profiles. In this respect, the capability to export/import only incremental

changes to a CIM/XML file is also required.

For the purposes of this section of the specification, CIM compliance means that the interface

definitions comply with the CIM in terms of:

1. Semantics (i.e., naming and meaning of data)

2. Syntax (data type)

3. Relationship (i.e., to other CIM components, to permit proper navigation within the

model).

CPRI also requires documented open APIs that will support integrating CPRI or third-party developed

applications. The API and associated programming environment shall support XML based open

interfaces such as SOAP and Microsoft.NET architecture.

As a minimum, the interfaces shall provide the following capabilities:

1. Real-Time Database Access – read and write all attributes of database points subject to

permission control.


of 115

2. Historical Database Access – read and write all data managed by the Data Historian

subject to permission control.

Exhibit 4-1: CIM Profiles

IEC Standard Profile

IEC 61970-452 Equipment (static transmission network model profiles)

IEC 61970-453 Schematics layout profile

IEC 61970-456 Analog measurements, discrete measurements, state variable, and topology profiles comprising steady-state solution profile group

IEC 61970-457 Dynamics profile

IEC 61970-458 CIM extension to generation

IEC 61970-556 CIM based graphic exchange format

IEC 61968-3 Interface for network operations

IEC 61968-4 Interfaces for records and Asset Management

IEC 61968-5 Interfaces for Operational planning and optimization

IEC 61968-7 Interfaces for Network Extension Planning

IEC 61968-9 Interchange for meter reading and control

IEC 61968-11 CIM extensions for distribution

IEC 61968-13 CIM RDF model exchange format for distribution

6 Supervisory Control and Data Acquisition This section specifies the data acquisition, data processing, supervisory control, and related capabilities

of the ADMS. The System will acquire data from and send control commands to field devices using

Remote Terminal Units (RTUs).

6.1 RTU Data Acquisition

6.1.1 RTU Protocols

The following communication protocols shall be available for RTU communications:

1. IEC 60870-5-104, for System interoperation with substation RTUs

2. DNP 3.0 (IEEE 1815), for System interoperation with substation RTUs

3. IEC 61850-90-2, for System interoperation with the SASTB as well as RTUs

6.1.2 Data Polling

The ADMS shall make data scan requests to RTUs for latest status, analog, and pulse accumulator data.

Such requests shall be made on a parallel basis for RTUs on different channels and on a sequential basis

when more than 1 (one) RTU shares the same communication channel.


of 115

It shall be possible to specify the frequency at which each data point is to be scanned by assigning it to a

scan group. The number of scan groups shall be configurable. The scanning frequency of each group

shall be adjustable in increments of 1 (one) second in the range of at least 2 (two) to 300 (three

hundred) seconds and in increments of 1 (one) minute in the range of 1 (one) minute to 60 (sixty)

minutes.

Scanned points shall be initially assigned to the following scan rates:

Exhibit 6-1: Scan Rates

Point Types Time

Status and Analog points 2 seconds

Pulse Accumulators 60 minutes

6.1.3 Report by Exception

Data acquisition using report by exception (RBE) shall be supported for the retrieval of status and analog

data. With RBE, the System shall poll RTUs for only the data changes that have been detected by the

RTUs since the last scan. In this respect, whereas all status changes shall be reported, only analog values

that have changed by more than a user-specified dead band shall be reported.

Dead bands for RBE reporting of analog values shall be specified on an individual point basis as a

percentage of the point’s full-scale value. When an analog reporting dead band is set to 0 (zero), the

analog value shall be reported at every scan whether it has changed from the previous scan or not.

6.1.4 Unsolicited Reporting

The System shall be capable of interoperating with RTUs that support unsolicited reporting of data point

values that have changed, i.e., in the event of changes, the RTU shall send the changed values without

waiting for a System scan request. In this respect, as for RBE, only analog values that have changed by

more than a user-specified dead band shall be reported.

6.1.5 Data Integrity Scan

A data integrity scan refers to a full scan whereby the System requests an RTU to send all data whether

it has changed or not. Full scans are required under the following conditions for data that is normally

acquired using the report by exception or unsolicited reporting modes:

1. Periodic “data integrity scans”. Initially every 15 (fifteen) minutes, but user adjustable for

each scan group from 5 (five) minutes to 60 (sixty) minutes in 5 (five) minute increments.

2. Upon System startup and restarts.

3. When any RTU is returned to service after being off-line or experiencing a power failure.


of 115

6.1.6 On-Demand Data Acquisition

A dispatcher, an application, or other authorized user shall be able to request immediate retrieval of

specific data from one or more RTUs by identifying the analog point, the status point, or preset groups

of points.

6.2 Data Processing

Data acquired from RTUs shall be processed and placed in the real-time database (RTDB) as soon as it is

received. Data processing includes ADMS calculations that may operate on the incoming RTU data to

generate real-time data not otherwise available by telemetry.

6.2.1 Data Quality

Data quality codes shall be maintained for all telemetered and calculated values to reflect their

reliability. The data quality codes that the System shall maintain are listed below. The letters in

parentheses are the associated data quality indicators that shall be shown with the values in displays

and reports.

1. Up-to-date (blank): Data has been successfully received during the latest poll.

2. Uninitialized (U): Point’s value has never been entered, neither by telemetry or

calculation, or manually.

3. Unreasonable (R): Point’s value is outside the reasonability limits for analog points.

4. Failed (F): System failed to receive valid data from the RTU for the point in the most

recent poll.

5. Deactivated (D): User deactivated scan processing for a point, RTU, or

communications channel. The last successfully retrieved value is shown.

6. Manually Entered (M): Point was deactivated, and the shown value was manually

entered.

The data quality codes are listed above in order of ascending precedence (i.e., “Up-to-date” has the

lowest precedence). When more than one data quality applies to a value, the indicator for the highest

precedence code shall be shown with the value at least in one-line displays and tabular displays when it

is displayed or printed.

For calculated points, the data quality of the result shall be set to the highest precedence code

associated with the elements of the calculation, i.e., to the quality code of the least reliable value used

in the calculation.

6.2.2 Areas of Responsibility

To facilitate flexible assignment of operational responsibilities to dispatchers, it shall be possible to

associate the field devices with Areas of Responsibility (AOR). It shall be possible to assign any point in

the RTDB to one of the AORs. The AOR assignments will be used: (a) to allocate control privileges and


of 115

operational responsibility for devices to specific workstations, (b) to determine which alarms to

annunciate at a workstation, and (c) to construct logs and summary displays for specific Areas of

Responsibility. Roles assigned in Role-based Access Control shall take AOR privileges and responsibilities

into account.

6.2.3 Analog Data Processing

6.2.3.1 Alarm Limit Checking

Every analog value shall be checked against 3 (three) sets of pre-defined high and low limits. All the

limits shall be individually specified for each individual analog point in the database. These limits shall

be:

1. High and Low Operational Limits: Readings beyond these limits indicate a deviation from

normal operational guidelines.

2. High and Low Emergency Limits: Readings beyond these limits indicate that the equipment

is operating outside its design tolerance.

3. High and Low Reasonability Limits: Readings beyond these limits indicate failure of the

transducer or A/D conversion equipment associated with RTUs.

Detection of a limit crossing, in either direction, shall result in appropriate alarm reporting. Each of the

limits shall be treated separately, e.g., when a point returns within an Emergency Limit it may still be out

of an Operational Limit. An alarm dead band shall be applied to each of the limits to derive the return-

to-normal level, so that repeated alarming does not occur for points whose magnitude hovers around

the limit. Individual alarm dead bands shall be specifiable in the database for each individual point.

When analog data exceeds its reasonability limit, the last reasonable value shall be retained in the

database and shall be assigned the “Unreasonable” data quality. The alarm message shall however state

the actual value of the analog data. The new data shall not be updated in the database or subject to

further processing until it returns within the reasonability limits.

Authorized users shall be able to enter a new value to override the value of any limit except for the

reasonability limit. Overridden limits shall be marked with a “limit override” quality code and shall be

used in place of the initial limit value. The System shall log each limit change as an event. The event shall

include the initial limit value and the new limit value. When the authorized user removes the override,

the limit shall revert to its initial value and the “limit override” quality code shall be removed. Limits

(both initial and overridden limits) shall be constrained to be within the reasonability limits of each

analog point.

When overridden limits are replaced by an alternative limit set, the “limit override” shall be removed

automatically.


of 115

6.2.4 Status Data Processing

Status data shall be processed to determine if changes have taken place. Changes of state shall be

processed as alarms (uncommanded changes) or events (changes resulting from supervisory control). All

status changes shall result in the immediate update of all relevant displays. No change-of-status

information shall be lost.

For each status point it shall be possible to define in the database the relationship between the RTU

contact-input position and the state of the device. For instance, an open contact may represent

"Tripped", or "Closed", "Open", "Alarm", "On", "Off", etc. It shall also be possible to define a “normal”

position for each status point in the database. A “no normal” state shall also be allowed.

The dispatcher shall be able to override the default normal state with a new definition of normal state

and remove the override and thereby return to the default normal state. Overriding the normal state

designation shall establish a “normal state override” quality code on the point. Dispatcher removal of

the normal state override shall remove the “normal state override” quality code.

6.2.4.1 Reporting of Multiple Status Changes

To the extent that the RTU identifies multiple breaker operations that occur between scans, the System

shall identify and alarm the operations. The capability shall be provided to detect, identify, and alarm at

least the following breaker operations which may occur between two consecutive status scans:

1. From close to trip

2. From close to trip to close

3. From close to trip to close to trip

4. From trip to close

5. From trip to close to trip

6. From trip to close to trip to close

6.2.4.2 Motor-Operated Switch Status Processing

Motor-operated switches are monitored by contacts to indicate fully opened and fully closed positions.

The software shall correctly interpret and show each switch position as being fully opened, fully closed,

in-transit, or invalid (an error condition).

6.2.5 Processing of Non-Telemetered Data

Non-telemetered data points represent data that is not derived from RTUs and is either manually

entered or calculated based on telemetered or other non-telemetered points. Whether a point is

telemetered or non-telemetered shall be transparent to the accessing programs. Non-telemetered data

points shall be definable in the database similarly to real-time data points.


of 115

6.2.5.1 Calculated Data Points

A calculated analog point is a data point whose value is a function of the value of one or more other

data points (component points). Analog data point calculations shall be performed periodically, and the

frequency of calculations shall be assignable in the database on an individual calculation basis.

The value of a calculated point shall be calculated by using a dedicated predefined algebraic equation. It

shall be possible to use telemetered data, manually entered data, constants and other calculated data

points as the component points in the calculation of a point. A minimum of 10 (ten) component points

shall be definable as part of a calculated point's definition. (It shall not be necessary to define multiple

calculated points as interim steps in processing the component points.) Newly calculated values shall

immediately be limit checked and subject to the same processing as telemetered points.

The Administrator shall have the capability to enable and disable the calculation of any calculated data

point. The “calculation suspended” quality code shall be set for any point for which the calculation was

disabled. For each suspended point, an entry shall be entered in a Suspended Calculation Summary

Display (Section 7.2.4.2, Summary Displays).

It shall be possible to use any value of any type from the database for arguments of the calculation,

including other calculated points and values produced by System functions.

The calculation function shall detect arithmetic exceptions such as division by zero and over-range

results. Such conditions shall be marked with the “failed data” quality code on the resultant calculated

points.

The Administrator shall be able to drag and drop points from displays or from the database into the

calculation definition.

6.3 Supervisory Control

The System will be used to perform Supervisory Control. In this respect, users shall be able to control

power system devices via commands transmitted by the SCADA system to RTUs. Control commands

such as digital status control, set-point control, and raise/lower control on selected status and analog

points shall be supported. In addition, the System shall be capable of automatically transmitting

supervisory control commands when directed by application programs or as the result of calculations.

6.3.1 Digital Status Control

A digital status control command results in the activation of an output relay in an RTU. Different forms

of these commands shall be possible such as:

1. Select Before Operate (SBO). This multi-step command is typically used to control circuit

breakers, i.e., to ensure the correct breaker is selected before the open or close command is

transmitted. If the select command is not acknowledged by the breaker relay within a

programmable time delay, the control command is inhibited.

2. Direct Operate (DO). This selects and activates the relay in just one single step.


of 115

Controls shall be checked for validity prior to sending. For example, if there is a blocking tag on the point

or the point is not in service, the control shall not be sent. In addition, a control command shall not be

sent to a point for which there is an outstanding control command not yet completed.

6.3.2 Set-Point Control

A set-point control results in a numerical value being sent to the field equipment, e.g., a voltage value

that a transformer tap-change controller needs to maintain.


or the point is not in service, the control shall not be allowed.

6.3.3 Raise/Lower Control

It shall be possible to send tap raise and lower controls to a transformer. In this respect, the System shall

support the raising and lowering of taps in a single selection/execution sequence.


or the point is not in service, the control shall not be allowed.

7 User Interface The functional capabilities that shall be provided to the users of the System are specified in this section.

All the specified user interface functionality shall be available to any user, except when certain functions

for which access is deliberately restricted per the user’s log-on privileges.

7.1 User Interface Guidelines

7.1.1 Guidelines on User-System Interactions

The user procedures for interacting with the System shall be simple, fast, and unambiguous, and shall be

“fail-safe” to guard against inadvertent user errors. In this respect, the following design guidelines shall

be followed:

1. Single-step procedures (i.e., initiation of functions by clicking a pushbutton or a display

symbol that is always shown in the appropriate application window) are required, whenever

feasible, for frequently used functions and for critical functions.

2. Common and frequently employed actions shall be initiated from toolbars. One or more

toolbars, specific to an application or function that is currently active, shall be shown in each

window.

3. The use of pop-up dialog menus which overlay portions of one or more windows shall be

kept to a minimum.

4. Multi-level menus shall be used only for the presentation of hierarchies of options and shall

have the minimal number of levels needed.


of 115

7.1.2 Guidelines on Information Presentation

The following design guidelines shall be followed for information presentation:

1. Power system information shall be organized and presented to the user in a manner that

allows the user to be immediately aware of any condition requiring urgent attention, to

quickly grasp the most significant aspects of a situation, and to have fast access to related

data for the investigation of details of the information presented.

2. Application programs shall not merely present the results of their calculations, but shall

present in highlighted form, the significant results

3. Displays built by the Contractor shall be constructed with systematic use of borders or

frames to visually group information that logically belongs together. For example, displays

for training simulation shall be shown in a color different than real time.

4. Headers shall be placed on displays and reports using larger fonts and/or bold characters.

5. Color shall be used sparingly for the following purposes: to distinguish different dynamic

states, for clarification purposes, and to highlight important information. Color shall not be

used for decorative purposes.

6. On-line help shall be readily available on displays and shall be designed to present useful

information and explanations to the inexperienced user. The System shall conform, as much

as possible to the Microsoft Windows standards for the on-line help function (e.g., pressing

the F1 function key shall open the Help directory window).

7. Messages to users shall be in plain English language and alphabet. Cryptic messages shall be

avoided.

8. When requesting input from the user, the System shall, to the maximum extent possible,

ensure that the user has on view all information needed to decide on the requested input.

9. Where possible, the system shall offer menu-selectable default entries for the most

common or most likely data entries.

10. The System shall not require the user to make repeated entries of the same data, but shall

provide a means for quickly copying data from one set of entry fields to another through

copy/paste and drag/drop techniques.

11. When a data entry must be one of a defined set of possibilities (e.g., a file name or

substation name), the possible entries shall be presented to the user in a scrollable list, and

selection of the desired option shall be by clicking the desired entry. If a search engine is

used, search shall be possible by keying in the first 2 or 3 characters.


of 115

12. A display shall be able to present any combination of telemetered and calculated data types

(e.g., historical as well as analog and status values) and any combination of display types

(e.g., schematic, graphical, and trend displays).

The detailed design of the user interface, including navigation trees and menu bars, the format and

contents of dialog menus, the colors of display features such as menu bars, window borders, display

background, and the operational procedures, shall be selectable in the database definition process. The

initial design to be included in the System upon delivery shall be subject to approval by CPRI.

7.1.3 Look-and-Feel

The Contractor shall provide a full-graphic user interface for the System workstations, whose

functionality and behavior shall conform to the norms of Microsoft Windows applications. Emulation of

X-windows is not acceptable. A design which takes full advantage of the features of the Windows

graphical user interface capabilities is required. The appearance of the user interface and the

methodology of user interaction with the System and all applications shall follow the “look-and-feel” of

the latest revisions of Microsoft Windows and the corresponding Windows Office applications.

A consistent approach is required for the formatting of displays, the graphic presentation of power

system devices, the use of color and other display features for highlighting events and exceptions, and

for every other aspect of display appearance. The appearance of power system devices (e.g., their

shape, color, background color, and blink-related features) and the use, for example, of fonts and colors

in display titles and other text shall be subject to CPRI approval.

7.2 Display System Requirements

7.2.1 General Requirements

The user will operate from several major types of displays of the power system including but not limited

to:

1. Schematic and graphical diagrams of power lines and substations

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

3. Queries-based displays

All the displays shall be dynamic, i.e., the appearance of displayed objects shall reflect values and

attributes in the Real-Time Database (RTDB), and they will be the user’s main tool for monitoring the

power system.

7.2.2 Overlays and Data Sets

There will often be several related sets of information about a system entity, all of which cannot be

displayed and made readable simultaneously without rendering the display to clutter. For this reason, it

shall be possible to create displays that have multiple data overlays consisting of a root overlay that is

normally visible and one or more auxiliary overlays that are visible only under explicit overlay control by


of 115

the user. Each overlay shall include its own static and any number of dynamic data points. For example,

a one-line diagram may have all status points in the root overlay, but have each type of analog

measurement (MW, Mvar, Volts, etc.) or values generated by an application in a separate overlay.

Overlays shall be independent of the de-cluttering levels. The users shall be able to select from a dialog

menu any mix of overlays to be displayed.

7.2.3 Bit-Map “Picture” Displays

Many schematic diagrams and other graphic information that must be available for viewing on System

workstations are not, at least not initially, in digitized formats. It shall be possible to import bit-map (or

“raster”) pictures and photographs in JPG and GIF format and include them in the structure of user-

callable displays. Thus, within this context, it shall be possible to:

1. Call bit-map pictures for display through any of the call-up procedures.

2. Link bit-map pictures to a world map display (i.e., a display of the entire power system

network that is capable of being scanned by the user). Each picture shall be represented by

a unique symbol and shall be called up when the user selects this symbol.

3. Use a bit-map picture as a world map overlay.

4. Place an overlay of dynamic display objects on top of a bit-map picture and link the dynamic

objects to the RTDB. The user shall be able to select these objects for all operations for

which the user is authorized.

7.2.4 Queries-Based Displays

Queries-based displays are displays for which only a format template is created by means of the display

editor and the contents of each instance of the display as called up are automatically determined and

generated by the System based on the real-time values of the specific data to be shown. Such queries-

based displays shall automatically adapt to database changes, and it shall not be necessary to edit the

underlying queries, nor to edit a template except to change its appearance or its contents. The format of

such displays shall automatically adjust to the amount of data that is applicable and available for each

call-up instance, i.e., their size shall vary as needed to show all the requested and available data, and

they shall not include any unused data fields.

7.2.4.1 Tabular and List Displays

Queries-based capabilities are required for station and similar tabular displays, and for displays that

present, for example, lists of devices and points from the RTDB. These capabilities are further described

as follows:

1. Queries-based tabular displays shall be used for substation data, but they shall also be

capable of being used for other classes of tabular data. Tabular display templates shall

define the appearance of the display (e.g., columns and their headers, fonts and their sizes,


of 115

colors, etc.), the data to be shown (e.g., status data, analog values, etc.), and the order in

which the data shall be presented. It shall be possible to include bar graphs and pie–charts

in the definition of queries-based tabular displays. When a tabular display is called, the

system shall automatically link the template to the appropriate portion of the database and

shall configure the display as appropriate for the quantity of data that must be shown for

each specific instance of the display.

2. Queries-based list displays shall be used to show devices corresponding to user selection

criteria. The user shall be able to request one or more fields in the RTDB to be displayed

(e.g., to show a list of all breakers that are not in their normal state and to present them by

substation in alphabetical order). When a list display does not fit into the window, it shall be

possible to scroll through it. It shall be possible for authorized users to control power system

devices from entries in a list display.

Detailed capabilities for each type of queries-based displays prepared by the Contractor, including

selection criteria for the contents of lists, shall be determined in consultation with CPRI.

Self-structured displays shall comply with the specified display response times. For flexibility, queries-

based displays shall be dynamically configured when they are called to the screen. However, in instances

where this may preclude meeting the display response time requirements, as may be the case for list

displays that require large amounts of system-wide data, such displays shall be pre-generated and kept

up to date, ready to be output to the screen whenever it is called.

7.2.4.2 Summary Displays

Summary displays shall be used to present lists of information that are derived from ADMS-created files

(e.g., alarm summaries that are derived from the Alarm and Event file) or based on the RTDB queries

(e.g., a summary of all points with alarming inhibited). Such displays (and printouts) shall be queries-

based, to adapt to the specific categories of data that must be shown for each instance (e.g., major

alarms for specified substations) and to the quantity of data that is included in the applicable categories.

When a summary display does not fit into a window, it shall be possible to scroll through it.

Selection of Summary Data

As a class of displays, summary displays shall provide a general capability for users to select specific

subsets of data for viewing. The same selection capabilities shall be available for the selection of

summary data for printing. The selection mechanism shall use SQL queries. However, to enable users

without SQL skills to make selections, pre-defined SQL scripts shall be available and invoked through

dialog menus. These dialogs shall enable users, through pointing and with the minimum possible typing,

to select the desired summary and to specify its scope per at least the following selection parameters

(as applicable to each summary):

1. Time range (before T1; after T2; between T1 and T2)

2. Substation(s)/feeder(s)


of 115

3. Area of Responsibility

4. Point status (open, closed, in a selected limit range, etc.)

5. Point attributes (tagged, abnormal state, alarming inhibited, alarmed, etc.)

6. Point’s data quality (deactivated, manually replaced, etc.)

For example, the ADMS shall support requests to view or print all the points at “Substation A” and

“Substation B” which are in an abnormal state. Where appropriate, it shall be possible to include “wild

card” characters in the search strings.

Additional specific data selection capabilities to be included by the Contractor in the initial System shall

be determined during its development.

A fast method shall be provided for requesting summary displays (alarms, abnormal, etc.) for one

specific substation by pointing to that substation.

Sorting of Summary Data

The "keys" provided for selecting summary data shall also be available for requests to sort summary

data. It shall be possible to specify one or more keys, and the data shall be sorted by the order in which

the keys are specified. For instance, it shall be possible to request the display of points in the

(alphabetical) order of the substations to which they belong, and, within each substation, to show

abnormal state points before normal state points.

The specific sorting capabilities for each type of summary (such as the ordering keys to be provided and

the default ordering for attributes when not explicitly specified by the user) shall be defined in

consultation with CPRI.

7.2.5 Help Function

The ADMS shall include a “Help” function of sufficient scope to instruct users on its normal operation

and each of its applications without having to resort to a printed user manual. The appearance and

capabilities of the Help function shall be like those of the Help function of Microsoft Office applications,

including the feature by which selection topics are suggested based on a partial or complete search

string entered by the user.

Users shall be able to call from any display, with a single mouse click, a Help window that explains every

pushbutton (and associated pull down or dialog menu) and data field of that display. Error messages

associated with the operations from that display shall also be explained. The Help window shall remain

on the screen until closed by the user, or until the display from which it was called is replaced.

The ADMS shall include tools for administrators to edit and add more screens for Help text.


of 115

7.2.6 List Searching Capabilities

Basic mechanisms to search for specific data in long lists shall be included in the System. These

mechanisms shall be like those provided in Microsoft Office applications for the selection of Help topics.

They shall be available, for example, for the selection of displays from display directories, for searching

an entry in a long list of selectable options, or for locating an entry in long lists of data such as a list of all

the devices represented in the power system model.

The following search mechanisms are required:

1. “Index” Search: This method shall present an index window with two fields, an “Item name”

entry field and an “Item index” field. As the user types the name of the desired display in the

Name field, the Index field shall show a portion of an alphabetized index of all the items in

the list, with items whose names match the characters entered so far appearing at the top

of the Index field. The user shall be able to select any item that appears in the Index field by

clicking it, i.e., this method of selection shall be like that of the Index tab of the Help

function of Microsoft Office applications.

2. “Contents” Search: This search method shall be provided for lists that are organized by

categories, such as a list of power system devices organized by substation or a list of all

System displays organized by display type. A “Contents” pushbutton shall bring up a window

showing the categories (e.g., the substation or the display types) in alphabetical order.

Clicking a category shall bring up an alphabetized list of all the items belonging to the

category, and the user shall be able to access an item by clicking it. This method of selection

shall be like that of the “Contents” tab of the Help function of Microsoft Office applications.

3. “Phonetic” Search: This method shall facilitate calling up of displays when the user does not

know the exact spelling of their name. The Soundex or similar coding method shall be

employed for the selection of groups of displays with similar sounding names. When the

user enters a display name, the System shall present a list of displays whose names are like

or sound like the entered name. The user shall then be able to select the desired display by

clicking it. The search for matching names shall ignore predefined key words, such as

“substation”, “feeder”, and “display”.

7.3 Screen and Windows Features

7.3.1 Windows

Windows shall be provided to allow the partitioning of the monitor so that several displays and

information from several programs can be viewed simultaneously. As delivered, the user workstations

shall support up to at least 8 (eight) windows on each monitor, in addition to the dedicated window for

information such as date and time.


of 115

There shall be only one active window at a workstation. This includes multi-monitor workstations. The

active window shall be identified by highlighting its title bar, and it shall be the focus and conduit for all

user interactions such as display call-up, navigation through displays, program execution, and dialog

interactions. An implicit rule for the active window shall be as follows: the window on which the cursor

comes to rest shall become the active window without clicking when it is in the window.

In general, all windows shall have the same basic structure and include:

1. Window border.

2. Title bar.

3. Maximize, Minimize, Restore, and Close buttons.

4. Scroll bars, when the display spans beyond the window. The magnitude and position of the

slider of the scroll bar shall represent the size of portion of the display that is currently being

shown relative to the full size of the display and the position of the shown portion within the

display.

5. Mode/Case identification, i.e., the operational mode (real-time, study, simulation, etc.) of

the function running in the window shall be shown very distinctly.

6. A Toolbar from which pull down menus can be called.

7. Application area, i.e., the main area of the window from which the ADMS functions and

applications are operated.

It shall be possible to drag a border of a window to increase or decrease its size in one direction, or to

drag a corner to increase or decrease the window size in the two adjacent directions. It shall be possible

to drag any window that does not fill the whole screen to any location, even when part of the window

extends beyond the screen. Any one window shall not be permitted to shrink to the point where the

window title cannot be read, and window titles shall be designed so that the currently loaded windows

can be identified on the task bar (for example, “Alarm Summary” and not “Window 1”).

It shall be possible for every user of the System to define and save the user’s individual screen layout for

each monitor of the user workstation, i.e., the preferred number of windows on each monitor of the

user workstation and their size, position, color, text, and content. When a user logs on to a user

workstation, the user’s pre-defined dedicated screen layouts shall appear.

Fully documented window management capabilities shall be provided to allow window creation,

deletion, movement, and re-sizing.

7.3.2 Date and Time

The date and time shall be shown on each user workstation monitor. Date shall be presented in the

format DD/MM/YYYY. Time shall be presented in the format HH:MM:SS with a resolution of 1 (one)

second and shall be updated once per second.


of 115

7.3.3 Pushbuttons (Soft Keys)

In the context of the specifications, the term push-button (or simply button) refers exclusively to

symbols on a monitor from which functions can be initiated or displays can be called by clicking it. The

term function key (or simply key) refers to a physical key on the keyboard.

7.3.4 Keyboard Functions

CPRI shall be able to assign and reassign combinations of keys of the user workstation keyboards (e.g.,

Control-Alt-P) to the activation of specific functions and calling up of frequently used displays. These

assignments shall be allowed only from user workstations in the Programmer mode and shall affect all

workstations. The following keyboard selectable functions shall be included in the delivered System:

1. SILENCE: Silence the audible alarm.

2. CANCEL: Has the same effect as a "cancel" button shown in a currently displayed menu.

3. DISPLAY: Call up a display by entering its mnemonic.

4. ALARM SUMMARY: Display the Alarm Summary for the calling user’s Area(s) of

Responsibility.

5. FREEZE/UNFREEZE: Toggle a display between “frozen” and “unfrozen”. When frozen, the

automatic refreshing of a display shall be suspended, and the note “DISPLAY FROZEN” shall

appear on the menu bar.

6. HELP: Show a menu of topics related to the active display from which further information or

instructions can be selected.

7.3.5 Toolbars

Toolbars with pull down menus shall provide fast navigation to functions and displays. It shall be

possible to navigate to functions and displays by clicking the toolbars and entries on their pull-down

menus. The layout of toolbars and the rest of the navigation schemes shall be developed and approved

in consultation with CPRI. Provisions are required for programmers to edit the toolbars and the

navigation trees, and to construct new ones, through an interactive procedure and without

programming.

1. A main toolbar shall appear near the top of each monitor. The main toolbar and pull down

menus initiated from it shall provide fast navigation to frequently used functions and

displays, and to functions that must be quickly accessible for the handling of emergencies.

2. One or more application toolbars shall be provided for application displays to facilitate

navigation to functions and displays which belong to the application itself or are used in

conjunction with it. Each application’s toolbar shall provide fast and convenient access to

Help information associated with the specific application.


of 115

7.3.6 Dialog Boxes

Dialog boxes shall be displayed when it is necessary to present the user with further information or to

allow the user to choose among several alternatives or enter data. Alternatives that are not currently

valid shall be displayed in lower intensity and shall be inactive. Alternatives that the user workstation is

not authorized to perform shall not be shown at all. A dialog box shall be placed close to the object from

which it was initiated, but shall not cover it, and it shall be possible for the user to drag a dialog box to

any part of the window. Dialog boxes shall be able to include static textual information, pushbuttons,

data entry fields, and check boxes as appropriate.

It shall be possible for the user to cancel a dialog at any time by selecting a Cancel push-button in the

dialog box and from a function key on the keyboard.

7.3.7 Information boxes

Information boxes shall be used to annunciate occurrences that require user attention, such as failures

to successfully complete a supervisory control request, receipt of a message from a substation, or errors

reported by power system applications. Messages that are displayed in response to dispatcher actions,

such as notification of failure of supervisory control, shall be displayed in an information box that pops

up on the screen from which the request was issued. Other messages, such as an error message from an

application, shall be posted on a predefined monitor on all user workstations that are assigned to the

function that is reporting the problem. Information boxes shall remain on the screen until they are

closed by a user and shall not be overlaid by other windows. Several information boxes shall be able to

exist on a monitor at the same time, and users shall be able to drag information boxes to another part of

the screen.

7.4 Data Representation

7.4.1 Data Attribute Representation

Any attribute of any data point contained in any System database, whether the point is telemetered,

received over a data link, manually entered, calculated, historical, or produced by an application shall be

available for presentation at any screen location of any display. No restrictions as to the placement of

data or the format of its presentation shall limit the way displays can be defined.

It shall be possible to access every attribute of any point or object in any database of the System to

dynamically control its appearance in displays. The presence, appearance, and location of quality

indicators (and whether to show all applicable indicators or only the one with the highest precedence),

tags, alarm inhibit indications, and any other indications and display features that depend on point

attributes shall be defined via the Display Editor during display creation or modification.

Methods to display data attributes (such as state of a device, limit range of an analog value, alarm state,

selection status of a point, etc.) shall include different object shapes, various object and background

colors, flashing, intensity, etc. The assignment of display features to data attributes shall be table-driven,

and shall be defined system-wide. It shall be possible for administrators to globally re-assign the colors


of 115

(or other display features) associated with any attribute. Through similar methods, they shall also be

able to designate a point as being telemetered and non-controllable, telemetered and controllable, or

non-telemetered (pseudo-point).

7.4.1.1 Numerical Data Display

Every numerical field on any display shall allow selection of the following features:

1. Number of integer and fractional digits displayed differently for each analog data item. Tap

positions shall be shown as integer values.

2. Number of integer and fractional digits displayed differently for the same data point when it

is shown on different displays or at different locations on the same display.

3. Algebraic sign of a value expressed as such or as one of a pair of alphanumeric or graphic

indications (up/down, in/out, arrow symbols, etc.) located anywhere in the display.

4. Capability to show or suppress leading zeros, plus signs, and minus signs for all numerical

data.

5. Protection of any data field against user entry as defined via the display generation

procedure.

6. Use of asterisks when the value of a data point cannot be represented completely by the

preformatted number of digits.

7. Data values shown numerically in any character size; left, right, or center justified; lined up

by decimal point (in lists); vertically or horizontally positioned, or rotated up to +45 degrees

or -45 degrees.

7.4.1.2 Display of Point States

It shall be possible to specify arbitrary sets of symbols, with up to at least 6 (six) different symbols for

each device, to represent the state of multi-state devices on displays. The symbols shall be built by the

Display Editor and shall be maintained in a library from which they can be selected. There shall be no

limit to the number of symbol sets that may be built. It shall be possible to use various display attributes

(color, flashing, inverse video, etc.) to represent the database attributes of a point or object.

A single symbol shall be able to use more than one color (e.g., the symbol for a transformer between

two voltage levels can show one side in the color associated with the first voltage level, and the other

side in the other color).

The state of three-state devices shall be represented by one of a set of four symbols, including a symbol

for the invalid state.


of 115

7.4.1.3 Displays Names

It shall be possible to assign to each display (or named segment of a world map) a name of up to at least

25 (twenty-five) alphanumeric characters. The names of a display shall be shown on any list that

includes the display, and shall be available for use with all the methods of calling displays by name.

When a new display is named, the System shall reject attempts to reuse an existing name.

7.4.2 Graphical Data Representation

Graphic data displays presenting bar charts, dials, pie charts, and X-Y plots and Kiviat charts shall be fully

supported. Any numerical database value shall be representable in graphics format on any kind of

display. All charts and plots shall also be capable of being displayed in a 3D format.

7.4.2.1 Bar Charts and Dials

A bar chart shall provide a simple pictorial method of showing the magnitude of a data value. It shall be

possible to define a bar chart to extend either horizontally or vertically. The location, maximum length,

width, and nominal color shall also be defined at display definition time. The length of the bar shall

represent the value of the data point. It shall be possible to split the background of the bar chart into

regions corresponding to the limits of an analog point, and to assign a different color to the portion of

the bar that appears in each region. It shall be possible to display bars in a flashing mode to represent

the value of data points with unacknowledged alarms.

Dials shall include a circle, or an arc of a circle, with a pointer whose position represents the value of the

data displayed. Like bar charts, the background color of the dials can be used to define regions of limits.

7.4.2.2 Pie Charts

The capability to show the relative percentages of a set of related data by means of pie charts shall be

supported. A pie chart shall appear as a circle divided into wedge segments, each a different color and

representing a different data base variable. The size of each wedge shall be proportional to the value of

the variable in relation to the total of all variables. The circle origin and radius, as well as the number,

identity, order, and displayed color of variables shall be definable at display definition time.

7.4.2.3 X-Y Plots

A means of graphically displaying X-Y plots of data from the RTDB and from the historical database shall

be provided. An X-Y plot shall show the relationship between two arrays of data whose structure is such

that the ordinates (x values) of a set of points are contained in one array and the abscissas (y values) are

contained in the other. The color, data point symbol, location and extent of both axes shall be

individually assignable to each plot. Multiple plots shall be allowed within an area defined by one pair of

plot axes.

7.4.2.4 Kiviat Charts

Kiviat charts or radar charts display multivariate data in the form of a two-dimensional chart of three or

more variables represented on axes starting from the same point. The chart consists of a sequence of


of 115

equally angled spokes, with each spoke representing a variable. The data length of a spoke is

proportional to the magnitude of the variable. A line also connects the data values for each spoke giving

the appearance of a star.

The color, data point symbol, location and extent of both axes shall be individually assignable to each

plot. Multiple plots shall be allowed within an area defined by one pair of plot axes.

7.5 Trend Displays

Trend displays shall provide the capability to view telemetered and calculated real-time data plotted

against time in a horizontally or vertically oriented graph. In the trend displays, 1 (one) axis shall be time

and the other axis shall be the value of one or more selected points as they vary with time.

7.5.1 Trending Capabilities

It shall be possible to select any analog point for temporary real time trending. It shall also be possible to

assign any point to permanent trending. The values of permanently trended points shall be available in

the historical database at time intervals that are commensurate with the scaling of the trending curve in

such a way that at least 1 (one) value is saved for each pixel of the curve. For such points, (1) all the data

needed for the curve shall be available whenever their trending is requested, and a complete curve shall

immediately be displayed, and (2) it shall be possible to request trending of historical data for any

period for which it is on-line.

The following trending capabilities shall be provided:

1. It shall be possible to define, separately for each trend display, horizontal or vertical

orientation of the trending curves. For horizontally oriented curves, the value of time shall

increase to the right (i.e., the oldest data shall be on the left and the most recent data on

the right.) For vertically oriented curves, the value of time shall increase downward.

2. It shall be possible to plot at least 4 (four) curves, corresponding to 4 (four) separate data

values, together on the same set of axes, and to define different scaling for each curve. All

curves shown simultaneously on the same axes shall have the same time scale.

3. It shall be possible to select time scaling so that the complete (full-scale) time axis

represents any user-selected period, such as:

a. 1 (one) second

b. 10 (ten) seconds

c. 15 (fifteen) minutes

d. 12 (twelve) hours

e. 24 (twenty-four) hours


of 115

4. When several values from a trending file correspond to a single point on the trending curve,

then the average trending file values shall be used to construct a point on the curve.

5. It shall be possible to select different time and value scaling for curves in different windows.

6. It shall be possible to define a unique color for each curve.

7. Using different colors, it shall be possible to identify portions of a curve that represent

values marked with a “Failed” or “Deactivated” data quality, and manually entered values.

8. It shall be possible to assign a pair of limits for each curve and to select shading to

emphasize the areas inside and outside the limits. For real time values the limits shall be

linked, as a default, to the first, innermost, pair of operational limits of the trended point,

but it shall also be possible to assign them to the point’s other pairs of operational limits, or

to assign to each limit a value within the range of values of the trending curves. Only the last

option is required for historical trends. The limits shall be shown as lines on the curve, and

their numerical values shall also be shown.

9. It shall be possible to superimpose trend curves where 1 (one) curve represents historical

data from a given period and the other curve represents the real-time data of the

corresponding current period. (For example, a window might present two curves, one

showing the load of a transformer on the day of the peak, and the other showing the

current day's load, updated in real-time)

10. Trend curves for real-time data shall automatically be updated when a new value becomes

available. When historical data for a corresponding period is superimposed on real time

data, it shall be updated too in synchronism with the real-time data.

11. For trend curves showing real-time data, the position of the axes shall remain fixed, and the

curves, time axis markers, and the grid shall move with the addition of newly acquired data.

12. It shall be possible to use a pre-existing trend curve as a template for a new trend curve by

calling it up and then saving it under a new name or ID. This new trend curve can be

modified by selecting different data points or other parameters.

13. It shall be possible to select historical data to be displayed in two ways: (1) static display of

data for a user-specified period, or (2) dynamic display of as many of the most recent values

as can be accommodated in the trend curve. Dynamic historical trends shall be

automatically updated as new values are received.

7.5.2 Precise Reading of Curve Values

Users shall obtain a precise reading of values of each curve within the set of axis, at any point along the

time axis, by placing a hairline cursor at the desired point. The time for which the accurate values are

shown, and the engineering values of the curves corresponding to this time shall be shown. The user


of 115

shall be able to quickly place the hairline cursor at any point on the curve and then move it slowly to

precisely select the desired point.

When a new trending display is shown, the hairline cursor shall be placed at the end of the curve, so

that the value of each curve is shown.

7.5.3 Selection of Trending Data and Parameters

It shall be possible to select any telemetered or calculated value for trending. For the selection of data

for trending, a procedure is required which is based on pointing the cursor to the desired point; it shall

not be necessary to enter a point name or ID to select a point for trending.

7.5.3.1 Pre-Selected Trending Points

It shall be possible to pre-select points for trending. The momentary values of such pre-selected

trending points shall be saved in the historical database at time intervals that are commensurate with

the scaling of the trending curve in such a way that at least one value is saved for each point of the

1,024 points of the curve. For such points, all the data needed for the curve will therefore be available

whenever their trending is requested, and a complete curve shall immediately be displayed. It shall also

be possible to trend historical data points from the data repository. In this respect, the requirements

below for displaying historical curves and overlays apply.

Trending data shall be transferred into the data repository for long term keeping and archiving.

Historical and restored archived trending data shall be accessible to the trending function from the

repository.

Pre-select trending is also referred to as “permanent trending.”

7.5.3.2 Presentation of Trending Curves

The following basic capabilities for the presentation of trending curves shall be provided:

1. When trending is requested for a point that is not assigned to permanent trending, the

trend shall appear with system-wide, predefined, default trending parameters, including

time and value scaling, default limits, and default shading attributes.

2. User shall be able to change all the trending parameters (scaling, limits, etc.) from within the

display. This customized version shall apply only at the workstation at which it was

prepared. A “Restore” function shall enable the user to request restoration of a permanent

trend display to its assigned parameters or of a non-permanent trend to the default

parameters.

3. A capability to buffer a user customized version for later recall is required for each trend

display.


of 115

4. It shall be possible to select no less than 4 (four) points for trending within the same set of

axes. It shall be possible to mix permanent trending points with non-permanent trending

points.

5. For permanent trending points the user shall be able to request a curve of historical data to

be overlaid on top of a curve of real-time data. The overlay shall be white with transparent

shading through which the underlying curve is visible. The user shall be able to specify a

date, whereupon data for the same hours of the day shall be shown in the overlay. When

real time curves get updated, the overlay curves shall likewise be updated with the

corresponding values for the overlay date. The user shall be notified when historical data for

the requested dates is not available.

7.6 Dispatcher Functions

In this section, the following required dispatcher functions are specified:

1. Display Call-up

2. Control of Overview Display

3. Supervisory Control

4. Device Tagging

5. Deactivate/Activate RTUs

6. Deactivate/Activate Data Points

7. Manual Data Entry

8. Printing of Information and Displays

9. Block Selection and Rubber Banding

10. Access Security

11. Data Access Spreadsheet

Other dispatcher functions are specified elsewhere in the context of the required applications.

Messages shall be displayed to advise the dispatcher of the disposition of his request after each action.

Appropriate dialog menus or pushbuttons shall automatically be displayed to guide the dispatchers

through operating procedures. Error messages shall explicitly identify the encountered problem or

reason for which a user’s request was rejected.

User operations on power system points, such as supervisory control, tagging, and acknowledgement of

alarms, shall be permitted only for points that belong to areas of responsibility to which the workstation

is assigned.


of 115

User requests shall be validated and shall be rejected if the user is not authorized to issue the request or

if parameters or other data that the user entered for the request are not valid or are unreasonable. The

user shall be notified of the rejection of requests through an information box with a message that states

the reason for the rejection.

Several dispatcher functions, such as supervisory control and deactivation of points, require a point to

be selected. Point selection shall automatically be canceled when the last step of an activity with respect

to a point is completed. Point selection shall also be canceled for multi-step procedures if the time

between two consecutive steps of the procedure exceeds a pre-defined system-wide selection timeout

period. The selection timeout period shall be adjustable by programmers in the range of 10 (ten)

seconds to 120 (one hundred and twenty) seconds for each individual point in the system. It shall also

be a global default selection timeout value (adjustable in the range of 10 (ten) seconds to 120 (one

hundred and twenty) seconds), and shall be used for points for which an individual timeout period is not

specified in the RTDB.

7.6.1 Display Call-Up

It shall be possible to call up any display or named segment of the world map, at any time, to any

window of any monitor of any user workstation. It shall be possible to call the same display to any

number of windows, on any number of monitors, at any number of user workstations, at the same time.

Suggestions for additional methods to enhance the efficiency of operations are welcome. Because rapid

and error resistant call up methods are critical to safe operations and the handling of emergencies, the

details of display call up capabilities and procedures shall be worked out and approved in cooperation

with CPRI.

7.6.1.1 Call-Up Methods

Display call-up methods shall include:

1. Display Directory: A list of displays from which a display can be called by clicking its name.

The directory shall include individual displays as well as named sectors of the world map.

Only displays belonging to classes that the user is authorized to see shall appear in the

directory.

2. Search: Both an Index and Contents search facility shall be provided for locating displays in

the directory. The display categories for the Contents search will be defined by CPRI during

the preparation of CPRI’s displays.

3. Pushbuttons: It shall be possible to define pushbuttons which, when selected, call up a

designated display.

4. Function Keys/Keyboard Shortcuts: Administrators shall be able to assign function keys and

keyboards shortcuts to displays so that, when a user presses the key(s), the corresponding

display is called up in the active window.


of 115

5. Display Name: Users shall be able to call a display by entering any of the names of the

display in a data entry field that shall be provided for this purpose on each monitor. The

name entry shall not be case sensitive (i.e., the case of the typed letters shall be ignored).

6. Equipment Name: Users shall be able to call up a display by referring to a substation name,

circuit name, device ID, or location.

7. Device ID: Users shall be able to enter point IDs consisting of area, substation, and device

number. The SCADA shall list all the displays (including named sectors of the world map) in

which the specified point appears, and which the user is authorized to view. Clicking a

display name on the list shall call that display to the screen.

8. Recall: The system shall maintain a circular buffer with the identity of at least the last 20

(twenty) displays that were viewed at each workstation; toggling back and forth between

two displays shall not result in repeated entries into the buffer. It shall be possible to go to

the next or previous display either by typing a “Recall” shortcut or by clicking “Recall

Next/Previous” pushbuttons in a toolbar. To call other displays from the Recall buffer

without repeatedly clicking the Next/Previous pushbuttons, the user shall be able to initiate

a Recall dialog menu. The dialog menu shall list all the recallable displays, and the user shall

be able to directly recall any listed display by clicking it. Recalled displays shall appear in the

active window, which shall not necessarily be the window on which they had last been

shown.

9. Hierarchy: Hierarchical displays shall include pushbuttons for calling the next/previous

(child/parent) level of the display. Where operationally desirable, additional pushbuttons

shall provide direct access to other levels of the display rather than just to the next/previous

level.

It shall also be possible to call an Alarm Summary display by clicking a point on a world map or

substation display. If there is an entry for the selected point in an alarm summary, the portion of the

summary that includes the entry shall be shown. The point’s entry shall be highlighted, e.g., by placing it

on the top of the display or by other means subject to CPRI approval.

In addition, Alarm Summary displays shall include functionality to navigate to the schematic

display/world map and the location or device where the active alarm is present, or to highlight the alarm

generating feature in some other way acceptable to CPRI.

7.6.1.2 Placement of Displays on Screens

Several options shall be available for the placement of a display when it is called. These shall include:

1. The new display replaces the display in the currently active window.

2. The new display replaces the current display only when called from a pushbutton within

that display.


of 115

3. The new display appears in a new window. For multi-screen workstations, the user shall be

able to select the destination screen on which the next window shall be created.

It shall be possible to select a default method, between those listed above, for each display. However,

users shall be able to override the default, and choose a different method whenever they call a display.

7.6.1.3 Display Viewing Restrictions

To restrict the viewing of privileged data it shall be possible to assign displays for viewing only at

workstations that are authorized for viewing them and to assign individual data fields within displays for

viewing only by “unrestricted” users.

It shall be possible to assign each display, including the world map and queries-based displays, to a class

and to define specific classes of displays that may be viewed on workstations of each of the functional

areas. One of the classes shall be “Unrestricted”. Viewing of “Unrestricted” displays shall be permitted

on workstations of any functional area.

Displays shall be assigned to one class when they are built, and it shall be possible to change assignment

from the Engineering workstations. To prevent inadvertent wrong display assignments, it shall be

required to explicitly specify a class for each display (i.e., the class shall not be “inherited” when one

display is used as a template for the construction of another display). If a display has no class assignment

at all, it shall be viewable only on the Engineering workstations.

It shall be possible to assign RTDB data fields and historical data records to “restricted” viewing.

Restricted data shall be shown only on workstations whose logged-on user has “unrestricted” viewing

rights.

7.6.2 Supervisory Control

This section specifies the procedures for supervisory control. Authorized users shall be able to control

two-state devices such as breakers and switches, three-state devices such as motor-operated switches,

and multi-state (Raise/Lower) devices such as tap changers.

Only 1 (one) user at a time shall be able to select a device for control, or for any other point-oriented

operations such as tagging. If the user does not perform the next step of a control procedure (or other

point-oriented procedure) within the selection time-out period, the point’s selection shall automatically

be canceled. A system-wide time-out period shall be adjustable by programmers.

Rejection of a control request shall occur at the procedure step at which it is detected, and in any event

before the request is sent to the RTU. The user shall be notified of the rejection and of its reason.

7.6.2.1 Device State Control

Supervisory control of two state devices and three-state devices such as breakers and switches shall

involve the following consecutive actions:


of 115

1. The authorized user selects the device for control by clicking the dynamic presentation of a

control point.

2. When the device is selected, the device symbol shall flash and a pop-up menu with the

device name and available operations shall be displayed. Operations that are not applicable

under current circumstances or time shall be dim and inactive. This menu shall not obscure

the selected device.

3. The dispatcher selects a control operation (TRIP, CLOSE, etc.). Users shall be permitted to

control devices into any state, including the current state of the device.

4. A message is placed in the pop-up menu identifying the device and the selected control

operation. The pushbuttons EXECUTE and CANCEL are placed in the window.

5. The dispatcher initiates the control action by selecting the EXECUTE function.

Successful completion of the control request shall be recorded as an event. Request failures shall be

annunciated by displaying an information box that identifies the controlled device and the specific

problem that was encountered (such as failure to communicate with the RTU or an error condition

reported by the RTU).

Control requests shall be cancelled and the selection of the point shall be terminated when the user

cancels a request, does not perform the next step of the control procedure within the selection time-out

period from the previous step, or the request is rejected.

7.6.2.2 Incremental (Raise/Lower) Control

Supervisory control of Raise/Lower control devices shall involve the same set of consecutive actions as

specified above for device state control except that:

1. Only RAISE and LOWER control operations may be selected.

2. The command shall be issued as soon as RAISE or LOWER is selected, without an EXECUTE

step. It shall be possible for dispatchers to initiate control repeatedly without reselection of

the controlled point, if the execution of the previous control command has been completed

successfully.

3. A separate timeout period shall be provided, which shall be adjustable by programmers in

the range of 10 (ten) seconds to 120 (one hundred and twenty) seconds. The timer shall be

reset and start counting again whenever a RAISE or LOWER command is issued.

7.6.3 Deactivate/Activate RTUs

It shall be possible to deactivate and activate processing for any RTU, manually from field

communications control displays and from CPRI written applications. When an RTU is deactivated, the

System shall stop processing all data for the RTU and shall mark all the points belonging to the RTU as

“Deactivated”, except for points with “Manually Entered” data quality. Supervisory control requests,


of 115

issued by authorized users or applications, shall be rejected for deactivated RTUs, and the reason for the

rejection shall be noted in a message displayed to the user or reported to the requesting application.

When the RTU is reactivated, the "Deactivated" quality codes shall be replaced with the "Bypassed"

quality code until up-to-date data is received from the RTU. However, points that have been deactivated

individually, or for which data has been entered manually either before or after the RTU was

deactivated, shall remain in the "Deactivated" or “Manually Entered” state.

A user deactivating an RTU shall be prompted to enter a comment of up to at least 50 (fifty) characters.

The comment shall appear in a comment box when the deactivated RTU is pointed to in the field

communications control displays. The comment field shall also be shown in the Deactivated Summary.

7.6.4 Deactivate/Activate Data Points

Authorized users shall be able to deactivate individual telemetered data points. The incoming data for a

deactivated point shall not be processed. A deactivated point shall retain the last value or state that was

successfully retrieved before being deactivated, and shall be assigned a "Deactivated" quality code.

Upon reactivation, the system shall resume processing of data reported for the point from the field. The

data quality of the point shall be set to "Bypassed" until up-to-date data is successfully retrieved for it.

When deactivating a data point, the authorized user shall be prompted to enter a comment, whose

length may be at least 50 (fifty) characters. The comment shall be shown in a comment box when the

pointer rests on the point. The comment field shall also be shown in the Deactivated Summary.

7.6.5 Manual Data Entry

It shall be possible to manually enter data into the RTDB, into the historical database, and into data

tables.

Attempts by more than 1 (one) user to enter values into the same point or set of data at the same time

shall be rejected, and an explanatory information box shall be displayed for the user.

7.6.5.1 RTDB Data Entry

It shall be possible to manually alter the state or value of a telemetered or non-telemetered data point.

Data entry requests shall be validated and unreasonable requests shall be rejected. For successful

entries, an event shall be generated; the old state or value and new state or value and the user entering

the data shall be shown in the event message. The “Manually Entered” data quality shall be assigned to

such points from the moment that data is manually entered until it is replaced with telemetered data,

and the point shall not be updated until it is manually activated.

Limit checking shall be performed when values are entered for analog points. The entered value shall be

displayed in the appropriate color, but no alarms shall be generated if the data entry results in a limit

violation.

A procedure like that used for supervisory control shall be employed for manually changing the state of

a status point. Manual requests to change the state of a device shall be subject to the same restrictions


of 115

imposed by tagging as apply to supervisory control commands, and the same dispatcher notification is

required when an attempt to manually change the state of a device is rejected by the System.

7.6.5.2 Other Data Entry

It shall be possible to enter data that is not associated with points in the RTDB, as in entering

parameters and operating conditions for the application functions, and to edit historical data and

information in the data repository. It shall be possible to enter values into several fields at the same

time. All enterable fields shall be highlighted. The new values shall be processed, validated, and

accepted only when a “Manual Entry” pushbutton is clicked. If one or more of the new values failed

checking and is rejected, the invalid values shall be highlighted, and none of the newly entered values

shall be accepted until all invalid values have been corrected and “Manual Entry” has been clicked again.

Each Data entry shall be recorded as an event. The event message shall identify the data structure (e.g.,

historical data for a certain day or outage scheduler parameters) into which the data has been entered,

the previous value, the new value, and the user who entered the data.

Where applicable, such as when user data enters the historical database, the “Manually Entered” data

quality flag shall be set.

7.6.6 Advanced Visualization Features

Advanced Visualization tools shall be provided to enhance situational awareness. These features shall

include dynamic dashboards, dynamic color contouring, 3D objects, and animated objects.

Dynamic color contouring shall be configurable to show variations in color or intensity to depict menu

driven system values or limit conditions from real-time data. Contouring techniques shall be capable of

being applied to voltage levels, line real and reactive power flows, and power flow injection and

withdrawal points.

Dynamic dashboards shall be provided. Dashboard displays shall represent a configurable window by

each user representing a simultaneous view of data and displays from multiple sources in the system

including real-time, study or historical data as well as alarms and alarm counts. Displays shall be user

configurable with drag and drop techniques from any existing graphic, tabular or trend display.

Dashboards shall be user configurable by the dispatcher. They shall have the capability to drill down,

provide the ability to use hyperlinks and pop-ups, and can include animated objects.

Display objects including cylinders, cones, etc. shall enable the user to depict system conditions of

interest on select 3D displays.

Display objects including animated arrows or other graphic symbols shall be configurable by the user to

depict specific conditions for individual system elements of interest. Animation features shall enable the

user to define dynamic sizing, direction, color and object speed for individual value conditions such as

showing arrows to show real and reactive power flow, halos for violations, increasing line size for limit

violations, etc. The user shall be able to disable and enable any animation feature via on-screen menus.


of 115

Dynamic characteristics from the RTDB shall be capable of being displayed with coloring and gradient

effects to reflect the dynamic state of the network. As violations occur, the coloring shall identify this.

All groupings, colors, and dynamic behavior related to the presentation of the above features shall be

configurable by CPRI and will not require any customization on the part of the Contractor.

The stated visualization tools shall be available for use in both the real time and study contexts.

7.6.7 Printing of Information and Displays

Users shall be able to request the printing of copies of any display, including the world map display,

trend displays, and other printable data and reports. The user shall be able to choose to print either only

the active window or the complete monitor screen. Copies shall be printed in color when directed to

color printers and in gray tone otherwise. Copy requests shall be buffered so that the user workstations

are not tied up until the display is printed.

It shall be possible to request the printing of any display to file format, i.e., PDF format, etc.

7.6.8 Block Selection and Rubber Banding

The various selection methods included in Windows shall be available for selecting text and objects for

processing by the System. This includes selecting blocks of text by dragging the mouse pointer through

the block or clicking the block’s beginning and end points with the Shift key depressed.

In addition, a simple means shall be provided for the user to easily and quickly select a multiple of

entities on any schematic display, map-display, or other world-map display, for further user actions. For

example, the dispatcher should be able to select several busses, several substations, several breakers,

and the connecting lines/busses, etc., from a schematic diagram, in one action. To indicate such multiple

selection, the user shall be able to use the mouse to draw one or more closed curves on the schematic

diagrams to indicate that all the entities within the curves are either selected or excluded for a

subsequent user action (such as a switching study, a count of interrupted customers, disable scanning,

etc.). The user shall be able to designate additional entities outside (or inside) the curves as being also

selected in case the enclosed curves cannot include all such entities.

7.6.9 Access Security

A mechanism for defining and controlling user access to the System shall be provided. This security

scheme shall be in addition to that included with the operating system. That is, even though a user has

logged onto the System network or a processor, access to System functionality shall be subject to

additional security checks.

7.6.9.1 User Log-On

Users shall be required to log-on to gain access to the System. The log-on procedure shall require

entering an associated password. A list of authorized users shall be maintained, and a default

workstation mode shall be assigned to each user. Upon logging on, the workstation shall be put into the

user’s default mode. Prior to logging on, however, any person already logged on must log off.


of 115

Logging on and off shall be recorded as events. When nobody is logged on to a user workstation, logging

on shall be the only function allowed at a workstation.

Users shall be able to change their own passwords. Changed password shall be propagated throughout

the System as necessary and without additional user intervention. An appropriately authorized user may

administratively reset passwords. Administratively reset and expired passwords must be changed at the

next login.

The delivered System shall not include any guest accounts or default administrator or maintenance

accounts providing user access. It shall not include any accounts that do not require an interactive log in.

All accounts in the delivered System shall use passwords assigned by CPRI. The Contractor shall provide

a user management document for CPRI’s approval.

7.6.10 Data Access Spreadsheet

A spreadsheet application shall be included in the System to enable users to perform ad-hoc calculations

and to define more permanent calculations and format them for viewing and printing. In addition to

manually entering variables into the spreadsheet, it shall be possible to copy values from the System

databases. Methods to do so shall include drag/drop and copy/paste techniques. Clicking a Refresh

button shall cause all the values derived from databases to be updated and a recalculation to be

performed.

Incorporation of a commercially available spreadsheet such as Excel is preferred.

The following capabilities are required:

1. Interfaces and methods for easy retrieval of historical data into spreadsheets.

2. Linking of spreadsheets to the RTDB.

The intent is to allow CPRI to use spreadsheets as System displays to present user-specific calculated

information.

7.7 Areas of Responsibility

It shall be possible to assign from 1 (one) to at least 8 (eight) Areas of Responsibility (AORs) to user

workstations. Default AORs shall be defined for each person in the list of authorized users and assigned

to the workstation when a user logs on. Supervisors shall be able to temporarily change the current

AORs for workstations; such changes shall be logged as events.

It is required that every active AOR always be assigned to at least 1 (one) workstation. Log-on attempts

and requests for reassignment of AORs that violate this rule shall be rejected. When this rule is violated

due to deactivation or failure of equipment, a major alarm shall be generated.

Alarms shall be annunciated only at workstations assigned to an alarmed point’s AOR, and point related

operations (including those listed below) shall be permitted only for points that belong to an AOR

assigned to the user’s workstation:


of 115

1. Supervisory control

2. Alarm acknowledgement and deletion

3. Alarm inhibition

4. Tagging and removal of a tag

5. Deactivation and activation of points and RTUs

6. Data entry.

7.8 Tagging

The user shall be able to apply a tag to a point or all points in an RTU (except for “limit override” and

“normal state override” tags), to non-telemetered points, and to calculation points. When a tag has

been applied to a point, a tag symbol separate from the quality code symbol shall be presented next to

the tagged point on any display or report where the point is presented.

All tag information for a point shall be accessible by any System functions and applications including the

calculation function.

7.8.1 Tag Attributes

Each tag type shall have a set of attributes. The administrator shall be able to enable/disable individual

attributes associated with each tag type. As a minimum, the System shall support the following tag

attributes:

1. Control inhibited in one direction, such as close

2. Control inhibited in the other direction, such as trip

3. Alarm inhibit

4. Event inhibit

5. Limit override

6. Normal state override

7. Scan inhibit

In addition, the administrator shall be able to define the following for each tag type:

1. The tag symbol to be presented

2. The tag precedence

As a minimum, the System shall support up to 16 (sixteen) tag types. There shall be no limit on the

number of tags per point. When a point carries multiple tags, the highest priority tag shall be presented.

Any combination of tags shall be supported, including multiple tags of the same type. The combined


of 115

effect of multiple tags shall be to inhibit a type of function (or multiple types of functions) if it is

inhibited by any of the applied tags.

7.8.1.1 Control Inhibit

The control inhibit action shall apply to authorized user supervisory controls as well as controls initiated

by a System function. When an authorized user attempts a supervisory control action on a tagged point

in a direction prohibited by the tag type, the System shall block the control and inform the authorized

user of the inhibit condition. When a System function attempts a prohibited supervisory control action

on a tagged point, the System shall block the control and return an error indication to the function.

7.8.1.2 Alarm Inhibit

It shall be possible for the authorized user to tag “alarm inhibit” of any alarm limit for any analog points

and any integrated accumulation points. When an alarm limit is inhibited, the System shall not raise an

alarm for this limit violation. When a status point is tagged “alarm inhibit”, the System shall not raise an

alarm for any spontaneous changes in state.

7.8.1.3 Event Inhibit

It shall be possible for the administrator to inhibit any event logging for any types of points. When a tag

with an “event inhibit” attribute is placed on a point, the System shall not raise events for this

point. However, the administrator action for putting on and removal of the “event inhibit” attribute

must be logged in the Event Summary as a record.

7.8.1.4 Limit Override

It shall be possible to set a “Limit override” tag.

7.8.1.5 Normal State Override

It shall be possible to set the “Normal state override” tag.

7.8.1.6 Scan Inhibit

The user shall be able to “scan inhibit” an individual point and all the points in an RTU with a single RTU

scan inhibit tag.

7.8.2 Tag Summary

A Tag Summary of all active tags on a point shall be conveniently accessible to the authorized user. The

Tag Summary shall indicate for each active tag the date and time the tag was placed on the point, the

point identification, dispatcher identification, tag type, and comment. A display of tagged point entries

shall be selectable based upon the following sort or search parameters and combinations of these

parameters:

1. Tag group number range

2. Tag type


of 115

3. Location

4. Point

5. Time period - Both specific time periods and relative time periods (for example, twelve

hours prior to the current time) shall be supported.

6. General text.

For any text search, the System shall support wildcard matching.

It shall be possible for the Administrator to create pre-configured filtered Tag Summary displays to show

all entries of a specific tag type, for example Alarm Inhibit Summary. These displays shall be called up in

one single action.

7.8.3 Tag Removal

Tag removals for a point shall be permitted, one at a time, from the Tag Summary or any display

showing that tag. When the authorized user removes a tag, the System shall prompt the authorized user

to enter a short comment (up to 60 (sixty) characters). When the last tag in a tag group is removed, the

tag group shall also be removed. The authorized user’s action including the comment shall be logged in

the Event Summary.

Upon a database maintenance operation or regeneration, or a system restart, all tag information shall

remain unchanged.

7.9 Event and Alarm Management

7.9.1 Events

The following occurrences shall be processed as events:

1. All changes of status points resulting from supervisory control commands.

2. Authorized user’s actions including, but not limited to, the following:

a. Workstation log on/off

b. Changing of workstation modes and AORs

c. Supervisory control

d. Tagging and removal of tags

e. Alarm acknowledgement

f. Data entry in the real-time or historical database

g. Deactivation and activation of points, RTUs, and audible alarming

h. Alarm inhibition and enabling


of 115

i. Manual fail-over or restart

3. Events declared by application programs

4. Other conditions that may be specifically called out in these specifications.

When an event occurs, an entry shall be made in an Alarms and Events (A&E) file.

7.9.2 Alarms

7.9.2.1 Definition of Alarms

The following occurrences shall be processed as alarms:

1. Un-commanded changes of state of status points.

2. Limit crossing by analog values.

3. Failures of a device to respond to a supervisory control command.

4. When any System device or major component such as a processor or printer fails, becomes

unavailable, or experiences a high rate of unrecoverable errors.

5. Permanent failures of communications with RTUs or other external computer systems.

6. When an alarm is declared by an application program.

7. When a numerical value (calculated or telemetered) exceeds a limit in either direction.

When processing of a value reveals that several limits have been exceeded since the value

had previously been reported, only one alarm shall be reported, and the final limit range

shall be shown in the event message. Dead bands shall be provided to eliminate alarms

caused by a value fluctuating about a limit.

8. When utilization of a System resource exceeds a pre-assigned limit.

9. Other conditions specifically called out elsewhere in these specifications.

CPRI shall be permitted to add, delete, or redefine conditions for alarming at any time before the entire

Contractor's design documents are approved.

It shall be possible to assign points and specific alarm conditions to major and minor alarms. For

instance, it shall be possible to define the excursion of a value of an analog value outside the operational

limits as a minor alarm and exceeding of the emergency limits as major alarms.

7.9.2.2 “Return to Normal Alarm” Flag

Each database point shall have a Return to Normal Alarm flag. When this flag is set, then all un-

commanded changes (state changes for status points, and limit crossings for analog points) shall be

alarmed. When the flag is not set, then return to a normal state (when a status point returns to the state

defined in the RTDB defined as Normal, or when an analog value returns within the first set of limits)


of 115

shall always be processed as an event. For status points for which no Normal state is defined, all un-

commanded changes shall always be processed as alarms.

7.9.3 Alarm and Event Processing

7.9.3.1 Alarm Management Responsibilities

Alarms shall be annunciated and their handling (acknowledgement, deletion, etc.) shall be permitted

only at workstations that are assigned to the AOR of the alarmed point.

7.9.3.2 Alarm and Event Reporting

The following shall occur when an alarm is detected:

1. An audible tone shall sound at user workstations that are assigned to the point’s AOR or to

the alarming application.

2. The visual representation of the point in alarm (the status symbol, or the numerical value)

shall flash at user workstations that are assigned to the point’s AOR or to the alarming

application.

3. If the point going into or out of alarm is represented on the user workstations, then the

Overview Displays shall be changed accordingly.

4. An entry for the point shall appear on appropriate Alarm Summary displays.

5. An entry shall be made in the Alarm and Event (A&E) file.

7.9.3.3 Alarm Priorities

It shall be possible to assign up to 8 alarm priorities. For the sake of flexibility in altering the alarm

priorities that are assigned to various types of occurrences the following scheme shall be provided:

Using database generating and editing procedures, it shall be possible to assign one of 8 alarm priorities

to every un-commanded change of state of a status point (e.g., different levels to a breaker opening and

closing), to each crossing of every analog value out of or back into limit range, and to every alarm

condition including alarms generated by application programs. From a supervisor or maintenance

workstation, it shall be possible to assign a priority from which and the alarms below the priority can be

suppressed. Such reassignment of alarm priorities shall be recorded as events, with the range of non-

suppressed alarm levels shown in the event message.

7.9.3.4 Conditional Alarms

It shall be possible to define in the RTDB alarms as being conditional on the value (state or limit range) of

other points or on the logical relationship among several other points.

“Conditional” alarms shall be evaluated and declared only after up-to-date data has been retrieved for

all the points on which the alarms depend. Evaluation of conditional alarms shall be designed for


of 115

asynchronous data acquisition, i.e., the evaluation shall not rely on the data used for the evaluation

being received in any particular order.

In addition, when manual supervisory control affects a primary device, dependent alarms shall be

suppressed.

Disabling/enabling of conditional alarming shall be permitted from authorized types of workstations. A

Conditional Alarming Disabled indicator shall appear in the Chronological Alarm Summary displays when

conditional alarming is disabled.

7.9.3.5 Alarm Tone

When an alarm occurs, an audible tone shall sound at each workstation that has the permissions to

handle the condition. A tone generation function shall provide a variety of tones:

1. A distinct tone shall be assigned to each alarm priority. If an audible alarm is already

sounding when a higher priority alarm is generated for the same point, the tone shall

change to that of the higher priority alarm.

2. It shall be possible to choose different sets of tones for each workstation.

The tones for each priority at each workstation as well as the number of times that an audible alarm is

repeated and the periodicity of its repeat shall be selectable from supervisor and maintenance

workstations.

Users shall be able to silence the tone on their workstation by clicking a “Silence” pushbutton in the

main toolbar or by pressing a “Silence” keyboard shortcut. That workstation’s alarm tone shall be

silenced until the next new alarm is received.

7.9.3.6 Alarm Inhibition

Authorized users shall be able to inhibit alarm processing for any point. When a point is alarm-inhibited

it shall be processed as usual, and analog points shall continue to be shown in the color (or other

characteristic) that corresponds to their limits range, however no alarm conditions associated with the

point shall be reported. This capability is intended primarily to prevent nuisance alarms from points

which are under maintenance or intermittent.

7.9.3.7 Acknowledgment and Deletion of Alarms

Authorized users shall be able to acknowledge alarms that are associated with their AORs. It shall be

possible to acknowledge individual alarms from any display on which the alarmed point is shown. On

Alarm Summary displays it shall be possible to use the mouse or keyboard to select individual alarms or

blocks of alarms for acknowledgement and for deletion from the summary. Deletion shall be permitted

only for previously acknowledged alarms. When an alarm is acknowledged, its visual representation

shall no longer flash at user workstations and the Overview Displays shall be changed accordingly.


of 115

7.9.4 Alarm Summaries

Authorized users shall be able to call up an Alarm Summary display. The capability to sort and filter the

alarm summary display at least by substation and priorities shall be provided. Alarm display attributes

such as the color of the alarm priority shall be configurable.

For summaries that include alarms of more than one priority, the alarms shall be grouped by priority

and the groups shall be shown in descending order of priority.

Each of these summary displays shall include a toolbar with pushbuttons from which the other

summaries can be called. In addition, each of these summary displays will include functionality to

navigate to the schematic display and position to the location (or device) where the active alarm is

present.

7.9.4.1 Summary Structure

Alarm Summary displays shall be queries-based. Entries in the alarm summaries shall be in inverse-

chronological order, with the most recent alarms appearing at the top of the summary. When an Alarm

Summary display is called, the start of the list, which includes the most recent alarms shall be shown,

and it shall be possible to reach any part of the display using the scroll bar and/or Page Up/Down

buttons. An Alarm Summary display shall show only one entry for any point in alarm, with the latest

alarm state and the time that the point entered that state.

The number of display pages shall vary depending on the number required to hold all entries to be

displayed. The date field, only, shall flash in entries for unacknowledged alarms on Alarm Summary

displays. When the dispatcher acknowledges alarms, their date field shall stop flashing.

7.9.4.2 Customization of the Summary

By default, when a user calls up an Alarm Summary display, it shall show only those alarms that belong

to the categories that are assigned to the workstation. These shall be shown system-wide. Fast

procedures shall however be provided for the user to request alarm summaries for:

1. Any combination of categories and functions: Such customization shall be accomplished

through selection from a list of categories and functions, and shall not require typing.

2. A specific substation: Such customization of Alarm Summary displays shall be accomplished

through selection of the summary by any of the following methods:

a. Clicking the symbol of that substation on a world map

b. Pressing a pushbutton in a schematic diagram of the substation

c. When a station name entered before the Alarm Summary key or a corresponding

pushbutton is pushed/clicked by the dispatcher.

Users shall also be able to request customization of alarm summaries by means of the selection

capabilities.


of 115

7.9.4.3 Acknowledgement and Deletion of Alarms

A user shall be able to select single alarms or blocks of alarms for acknowledgment. Deletion shall be

permitted only after an alarm has been acknowledged.

7.9.5 Alarm and Event Message Formats

All entries in alarm summaries and in the Alarm and Event (A&E) file shall be a maximum 1 (one)

monitor line in length and shall be identical in both the monitor display version and when printed. No

unduly cryptic abbreviations shall be used in alarm and A&E messages. An alarm and event message

shall contain the following information, as applicable:

1. Class (required only for A&E messages): a one-letter designation defining the category of

alarm or event:

a. “A” for alarm

b. “O” for dispatcher initiated event

c. “R” for return to normal event

d. “M” (Message) for “Text Events”

2. Alarm Priority (for alarm message), indicated through color and a symbol

3. Date and time of the detection of the condition, or of the user’s action

4. Date shall be in the format MM/DD/YYYY

5. Time shall be in the format HH:MM:SS

6. The user ID and workstation ID (for user-initiated events)

7. Location (e.g., substation ID, “Test Bed”) or application

8. Point Name

9. Point Descriptor.

The following requirements shall also be met:

1. For analog limit violations, both alarm and return to normal, the alarm text shall also include

the measurement and the name of the limit that was crossed, and in which direction.

2. For status changes, in direction, the alarm or event text shall include the new state. For

alarms/events of multiple state transitions, the alarm text shall include all transient states as

well as the final state (e.g., for a reclosing operation followed by a lock-out, the text shall be

“TRIP-CLOSE-TRIP”.)

3. The normal and abnormal state names shall be shown in different colors for each type of

point.


of 115

4. For user-generated text events, the event message shall include dispatcher ID, date and

time, and free format text.

The exact format of the alarm and event messages shall be subject to approval by CPRI.

7.9.6 Alarm and Event Records

Alarms and events shall be recorded in an Alarm and Event (A&E) file and shall be available for viewing

and printing on demand.

7.9.6.1 Alarm and Event File

An entry shall be made for every alarm and every event in a chronologically ordered A&E file.

Occurrences, such as un-commanded status changes and limit violations, which would normally be

annunciated as alarms shall be recorded as events if alarming is suppressed due to alarm inhibition, or

any other reason. In contrast to the Alarm Summary, the A&E file shall have a time-tagged entry for

every occurrence, rather than just the most recent alarm or event for a point or function.

The A&E file shall be part of the historical database, and entries shall be kept on-line for the period

specified for historical data.

The user shall be able to view the A&E file and to print it in whole or in part.

7.9.6.2 Selection of Alarms and Events for Viewing and Printing

By default, only alarms and events belonging to the categories to which the workstation is assigned shall

be shown when the alarm and event list is viewed. The most recent entries shall be shown when an A&E

display is requested, and the rest of the list shall be accessible through scrolling. It shall, however, also

be possible to select specific data from the alarms and events list for viewing and printing. The selection

mechanism shall be by means of SQL queries.

To enable the user without SQL skills to select alarm and event data for viewing and printing, the

Contractor shall include in the system pre-defined SQL scripts and a user oriented interface for them.

Authorized users shall be able to select data through pointing and minimal typing, per the following

criteria and combinations thereof:

1. Date and/or time range (before T1; after T2; between T1 and T2; All)

2. Functional areas

3. Alarm priority

4. Alarm substation(s)/locations

5. Point name

6. Point attribute, including limit violation, open state, etc.


of 115

8 Data Historian The System shall include a data historian. Open Database Connectivity (ODBC) is required with

documented and demonstrable compatibility with Microsoft Access, Microsoft Excel, and other common

front-end software.

Any data value in the System shall be available for collection, calculation, retention, and archiving by the

Information Storage and Retrieval (IS&R) function. This includes scanned data, data received via data

exchange, calculated data, and data produced by applications.

Any authorized, designated System user shall be able to access all data historian functions, review

historical information, and edit information from any System workstation.

A solution that includes the capability to capture (for future analysis and/or replay) all changes of real-

time data (like a flight data recorder) is strongly preferred.

Any third-party license(s) provided to support these functions must allow CPRI “full-use” of the

software. It shall provide for use by CPRI of all databases and applications delivered with the System by

the Contractor as well as permit CPRI to develop additional applications and/or databases generally

related to the functionality of the System.

8.1.1 User Access

The user access function shall incorporate the following features as a minimum:

1. Menu driven data selection process

2. Pre-formatted sets of data retrieval request displays built via the IS&R user interface

3. Sets of generic access routines for typical types of access, such as all analog points at a

specific time, average, maximum or minimum of a value over a user nominated time period,

etc.

4. Capability to define ad hoc queries to call for any specific value(s) that have specified similar

characteristics over specified periods of time

5. Capability to transparently deliver interpolated data for a specific time or period of time and

associated periodicity, where the source data was stored by exception

6. Capability to display data graphically

7. Capability to edit data by authorized users

8. Restrictions on access to confidential information based on user access control

9. Seamlessly integrated with Web browser users to retrieve historical data and for the

presentation of reports

10. Any quality code, tag, or data value stored for any historical data value shall be retrievable.


of 115

For retrieval purposes, it shall be transparent to requesting users or applications whether the requested

information is stored on-line or on archival storage, or spans across both storage types. The data

historian shall satisfy a retrieval request of any time period and any time span. Sufficient relationships

shall be maintained between the historical data and the System Real Time Data Base (RTDB) to ensure

that selections can be made based on comparisons between stored historical values (such as a

periodically saved bus voltage value) and any related, fixed System value (such as the bus voltage limit).

8.1.2 Function Access

The Contractor shall provide a library of programming interfaces to allow any function added by CPRI to

access the historian for information storage and retrieval. For example, it shall be possible to initialize an

ADMS simulator case from the data historian for any date and time within the data retention period or

the archived period. The data storage times closest to the date and time specified by the user shall be

used to select values from the historical database.

The historical database shall also provide an interface to PC-based applications such as Microsoft Office

applications (e.g., WORD, EXCEL, etc.), report generators, and other RDBMS products via the latest

standard data requests or ODBC drivers.

8.1.3 Automated Data Capture

It shall be possible to capture any analog or status value defined in the System database either upon

detection of its change (with associated data quality codes and time tags) or periodically in sets of

associated data. Automated capture of alarms and events, user entries (including control, tag and flag

requests, manual data entries including limit changes) and system maintenance log entries shall be

provided. All alarms and events shall be captured upon occurrence and forwarded to the IS&R facility for

storage and future access.

8.1.4 Data Quality Codes

The IS&R database shall include all quality codes associated with each point. In addition, a distinct

quality code shall be provided to denote that a correction has been made to a point’s value while in the

IS&R database.

8.2 Historical Databases

Data collected or calculated by the System shall be saved in a historical database (HIS). Historical data

shall be available for viewing and editing, inclusion in printed reports, archiving for long term storage,

and transmission to external systems. The selection of data for inclusion in the historical database shall

be controllable by CPRI, shall be defined in the RTDB, and shall not require separate data historian

definition.

The stored data, including archived data, shall contain sufficient information to enable the retrieval of

the data value, its quality codes, and the time and date that the data was collected at any time in the


of 115

future. Access to the stored data shall not be affected by computer system failure recovery, time

change, or changes to the computer system configuration.

All stored data shall be accessible from any time period regardless of changes made to the RTDB or the

historical database after storage of that data.

Database changes shall not require re-building of the stored data (e.g., it shall not require re-building

the archived media after a structure change in the historical database) and shall be transparent to a

retrieval request that may span across multiple database changes.

The addition, deletion, or modification of data to be collected and processed shall not result in loss of

any previously stored data during the transition of data collection and processing to the revised

database.

8.2.1 Capabilities of the Historical Databases

All the historical data collected shall be stored in a single historical database. All the data needed for the

preparation of reports shall be derived from this database. Users shall be able to select from this

database any part, or all, of the historical data collected or processed by the System for viewing and

editing, printing, and archiving to magnetic or other suitable media that may be added to the System. To

do so, user-oriented procedures that do not require familiarity with database querying techniques shall

be provided for the display and printing of on-line historical data for specific points or predefined groups

of points and for user-specified time periods. Procedures based on selection by pointing, with minimal

data entry, are required for the selection of historical data for display, archiving, or any other purpose.

The historical database shall consist of historical points and blocks thereof. A historical point is a set of

values collected for 1 (one) variable at pre-specified time periods. Such variables can be telemetered or

non-telemetered values from the real-time database or variables calculated periodically from other

historical points. Examples are bus voltage readings, which may be saved hourly from the real-time

database, or hourly minimum and maximum values calculated daily for sets of historical points. The

arithmetic precision of real-time data shall not be reduced when stored in the historical database.

Historical data shall be stored in such a way that it will be possible to identify and display the date and

time of each entry and request specific data for specified time periods. Historical data shall be saved

together with the associated data quality codes.

The size of the historical database (meaning the number of records) shall be constrained only by the

capacity of the disks. It shall be possible to increase the number of data points stored at each time, or

the number of data periods for which data is stored, while the database is on-line and without using

export and import procedures. The database shall be expandable beyond the delivered configuration by

assigning added physical storage.

8.2.2 Historical Points

It shall be possible to create a historical point for any telemetered or non-telemetered status, analog, or

accumulator data point in the real-time database and to create calculated points based on other


of 115

historical points. The value of a data point shall automatically be saved in the historical database

together with its quality codes at time configurable time intervals or by exception. Within this context, it

shall be possible without requiring any programming skills to:

1. Create new historical points by selecting real-time data to be saved

2. Create calculated historical points through definition of the calculations

3. Delete a historical point

4. Specify the time periods at which the data is to be saved or calculated

As a minimum, selection for data saving and calculation shall be possible on an individual point daily,

weekly, and monthly basis for periods of 1 (one) minute, 5 (five) minutes, 15 (fifteen) minutes, 30

(thirty) minutes, and 60 (sixty) minutes synchronized with the hour. Daily, weekly, and monthly

processing shall occur shortly after midnight.

The calculations specified in Section 6.2.5.1, Calculated Data Points, shall be provided as applicable to

historical data. Additional operations as required for historical data include:

1. Calculation of maximum, minimum, sum, average, and standard deviation over a set of data

saved at one time.

2. Calculation of maximum, minimum, sum, average, and standard deviation of the values of a

historical point over a pre-specified time period.

Every calculated data point in the historical database shall carry a quality code.

8.2.3 Manual Entry of Historical Data

The user shall be permitted to edit some of the values in the historical database. Edited data shall be

given a data quality of “Manually entered”. If the user manually edits any one or more of the

component points of a calculation, the system shall re-compute the calculated value and its data quality.

User-oriented manual entry procedures shall be provided that do not require programming skills. All

manual entry actions shall be logged. The selection of editable data in the historical database shall be

controllable by CPRI.

8.2.4 Reports

Any authorized System user shall be able to schedule the generation of historical data reports by time

and date or on demand. In addition, the user shall have the capability to specify conditions detected by

the System where designated reports are automatically initiated. Reports shall have the capability of

being regenerated if a value in the report is adjusted and all dependent values are re-calculated.

The facility shall be able to securely publish these reports in any format (including HTML, XML, PDF,

delimited text, Postscript, and RTF) to any destination (including e-mail, Web browser, and file system).

The user shall be able to designate the format and destination to which reports are generated. If the

destination is a hard copy printing device, the system shall use available (i.e., base operating system)


of 115

print file spooling logic. This shall include automatic redirection to a compatible output device and

notification to the system administrator and to the report requestor of the redirection. The report shall

not have to be rebuilt to send it to additional destinations.

9 Software This section specifies requirements for the software platform of the System with respect to its operating

system, compilers, basic and resource monitoring software, system and network management facilities,

and software development and maintenance tools.

All software written by the Contractor shall be written in an industry standard high level language such

as C++ or C#. Software sources shall include clear and unambiguous comments written in grammatically

correct English, and each program shall include a comprehensive description of its purpose, functions,

inputs, outputs, and resources operating system software.

9.1 Operating System Software

An operating system with long term support shall be supplied by the manufacturer of the server

processors. In this respect, it shall be the latest version of a 64-bit Linux or Windows Server operating

system.

All workstations shall use a latest long-term supported version of the Windows operating system from

Microsoft.

The same standard unmodified version of the operating systems shall be used throughout the System.

The operating systems shall provide robust security features.

Original Equipment Manufacturer (OEM) Operating Systems are not acceptable.

To facilitate operating system upgrades, the operating system directories shall not include any files that

are irrelevant to the operating system. In addition, the operating system and data files shall be placed in

different disk partitions.

The Contractor shall be responsible for service and support of the installation and the validation of

update security patches during the warranty period.

9.2 System Software Requirements

The following requirements shall apply to the System’s software.

9.2.1 Programming Tools

The system software shall include a comprehensive set of programming tools and aids including:

1. Assembly and compilation facilities including programming tools and programming services

for all delivered programs. This shall include compilers for all languages in which the

delivered software is written.


of 115

2. On-line Interactive debugging tools.

3. Utility functions, such as editors, file comparison, library maintenance, etc.

4. Program loading facilities where object modules produced by the compiler shall be

temporarily stored on disk and upon command by the programmer loaded and linked for

execution in the System. These facilities may consist of 1 (one) or more programs, written in

1 (one) or more languages, from more than 1 (one) input medium with necessary linkages,

in any combination.

5. Capability to create, modify, and execute batch files for program linking.

9.2.2 Time and Calendar Synchronization Service

Each system component and application throughout the System shall have the capability of being time

synchronized using Coordinated Universal Time (UTC) over the Network Time Protocol (NTP) to provide

accurate time stamped information.

This system service shall automatically adjust System time in accord with the input from a GPS

synchronized clock without the need for centralized time synchronization software to avoid a Single

Point of Failure (SPOF).

In addition, a time monitoring service shall be provided through the Management Environment to

ensure that all system components and applications are correctly synchronized. An Administrator shall

be alerted if an application or device has demonstrated a loss of synchronization. Historical data

scheduled to be stored during the time gap shall be marked with an appropriate quality flag.

When time is not automatically synchronized from the time standard, an authorized user at an

authorized workstation shall be able to set the time and/or to correct the time by entering a time

increment or decrement. The updated date and time shall be used to immediately update the system

clock and calendar at all servers and user workstations, and to reschedule the initiation of programs and

scheduled functions. If the clock is moved forward, or moves forward as a result of resynchronization

with the time standard, all functions (such as printing of reports) that were scheduled for execution in

the time gap shall be immediately executed.

9.2.3 System and Network Management Software

The System and Network Management Software shall include the minimum following characteristics:

1. Fault Management: This is used to recognize, isolate, correct and log faults that occur in the network.

2. Performance Management: This shall include both system and network performance.

3. Security Management: This is used to protect the System and its networks from unauthorized access by users and software and includes many sub-functions such as creating, deleting, and controlling security services and mechanisms, distributing security-


of 115

relevant information, reporting security-relevant events, controlling the distribution of cryptographic keying material, and authorizing user access, rights, and privileges.

4. Hardware and Software Inventory: This feature shall collect a wide variety of information about all computers in the System. The inventories shall include information such as processor, memory, operating system, peripherals, software, and service and the processes that are running on the computers.

As possible, the System and Network Management capability shall be based on IEC 62351-7 and shall have a secure browser-based user interface. The interface shall be designed to provide all pertinent information utilizing easy to use navigation techniques.

9.2.3.1 System Resource Monitoring and Management

The System shall include programs to monitor and record the utilization and queuing of requests for

resources on the various components of the System including the following:

5. Utilization (i.e., percentage of processor or channel time being used) by the following

resources:

Servers, workstations, and data storage systems

LANs, routers, and switches

Communications servers and data links

6. Queue lengths and average wait-times for the following queues:

I/O queues for disks and mass-storage devices

I/O queues for access to LAN and wide-area networks

Processing queues for major tasks, such as database access, alarm generation, scan

data processing, etc.

The utilization/performance information shall be sufficient to enable CPRI to track the system usage,

determine bottlenecks, and plan system upgrades.

Appropriately authenticated users shall be able to use any workstation for viewing and printing System

utilization and other performance information.

9.2.4 Virus and Malware Protection Software

All servers and workstations shall include virus and malware protection software that shall run at

startup, when initiated by an authorized user such as programmer, and whenever data or programs are

loaded into any server and workstation in the System. The virus and malware protection software shall

search for and report the existence of software viruses in RAM and on associated disk devices. A server

or user workstation shall not be allowed to connect to the System if it has been found to harbor a virus

or other malicious software.


of 115

An update service shall be available for the virus and malware protection software, with updates for

new known viruses provided to CPRI as soon as they become available. The Contractor shall be

responsible for this service and shall support the installation of updates during the warranty period.

Updating shall be required only on one server, with the updated version distributed as appropriate to

similar servers in the rest of the System.

The virus and malware protection software shall provide centralized installation, configuration,

reporting, monitoring, updates, and group management for all servers and workstations.

9.2.5 Operating System Security Patch Update Facility

A facility shall exist to manage and deploy OS patch updates for both servers and workstations in

accordance with the System Security requirements. It shall present new patch updates as they are

supplied by the OS vendor such that all available patches can be viewed. It shall also be possible to view

a summary of each of the servers and workstations to determine the version of software running (for

security audit purposes) against that available.

Adequate processes and the necessary infrastructure shall also exist such that patch updates can be

securely deployed to all systems in a managed way, first within the support environments and then,

once proven successful, to the Production Environment.

The facility shall provide centralized management of the patch update function using the Windows

Software Update Service (WSUS), or some other such service, such that minimal human intervention is

required to perform patch update deployment. Deployment of patches to the Production Environment

should not be restricted to a scheduled task but shall be “semi-automated” to allow strategic

deployment in concert with all System activities.

9.2.6 Patch Update Facility

A facility shall exist to manage and deploy patch updates for servers and workstations in accordance

with the System Security requirements. The principles and mechanism employed shall be the same as

for the Operating System Security Patch Update facility.

9.2.7 Automatic System and Data Backup

Once per day, shortly after midnight, the system shall automatically back-up the database to

appropriate media, which will contain online backup and removable media. The data saved shall include

the entire real-time database, applications database, historical database, all displays, all report

definitions. In addition, the saved data shall include any configuration files (e.g., hardware definitions,

definitions of parameters and calculations, script files, etc.) necessary for a complete “bare-metal”

restoration of the software system from a catastrophic failure.

An authorized administrator shall also be able to execute a system data back-up at any time.


of 115

In the event of a disk corruption or other problem affecting all redundant disks, it shall be possible to

restore an operational system, current as of the time of the most recent back-up, by loading system

programs and then restoring the database and the configuration files from an unaffected source.

All backup data contents shall be documented to include identification of the backup data and backup

schedule and details concerning the restoration procedure.

9.2.8 Remote Maintenance Access

Remote maintenance access capabilities for authorized and authenticated users outside the Production

Environment shall be provided for System monitoring, analyzing, and maintenance purposes.

Access shall be tightly controlled and include strong access restrictions and encryption including the

application of Virtual Private Network (VPN) technology between the ADMS and the remote user’s

external system. Remote maintenance access shall have the minimum following characteristics:

1. The VPN access point shall be a resource dedicated to the VPN. All VPN traffic shall be

routed through this access point. The access point shall enforce user authentication and

security policies; access to the System shall not be possible until the user has been

authenticated.

2. A client shall be installed on each remote PC that will be allowed to access the System. The

client shall be proprietary to the VPN technology supplier; it shall not be a client supplied

with the PC operating system.

3. Administrators shall be able to disable remote maintenance access with a single action and

to physically disconnect the System from the access point.

4. Any VPN session shall be logged in the centralized server.

The Contractor shall be able to inspect and solve any System problems throughout the warranty period;

therefore, it shall be the Contractor’s responsibility to prepare all necessary equipment used to link the

Contractor’s remote workstations to the ADMS. The network connection shall require the

authentication of users and software, the encryption for any significant information, e.g., username,

password, etc., and the logging of all remote session transactions. Any cost accorded to network

connection shall be paid by the Contractor.

10 Hardware

10.1 Servers and Auxiliary Memory

All necessary servers and auxiliary memory shall be provided by the Contractor to satisfy the ADMS

capacity, performance, and availability requirements. Where applicable, virtual machine servers shall be

utilized.


of 115

As a minimum, servers shall consist of 64-bit CPUs with main memory, auxiliary memory, terminals, and

all interconnections so that they can exchange data and information (such as status and program or data

control information).

All servers shall be current models selected for efficient operation of a real-time system. Generally, they

shall be within the same model family. CPRI shall be able to replace or upgrade the servers with future

offerings to obtain increased computational power and system expansion with no required system or

application software changes.

Each server shall include facilities for orderly shutdown and resumption of operation upon detection of

power loss and subsequent resumption of power.

No restrictions shall be placed on the allocation of server main or auxiliary memory for any specific

purpose.

Servers and processors shall be installed in rack mount enclosures. Minimum rack requirements are as

follows:

1. Each rack shall include a 17-inch TFT color monitor, optical mouse, and keyboard as a server

and network management terminal. Monitor and keyboard shall be mounted for storage

and ease of access using drawers of slide out type. The terminal shall manage all servers in

the rack via KVM (keyboard, video, and mouse) switches.

2. An overhead extractor fan kit shall enhance natural convection cooling by increasing the

airflow in the rack.

3. Equipment shall support a redundant power supply option.

4. All equipment shall support a No Single-Point of Failure (NSPOF) network switching option.

Necessary switches shall have a minimum interface speed of 1 Gbps.

5. Dedicated high-speed interconnections shall provide for efficient transfer of data to the

system’s Storage Area Network (SAN) and/or Network Attached Storage (NAS)

infrastructure.

6. Server disks and storages shall be configured using RAID technology with “hot swap”

maintenance capability. In this respect, a hot spare disk shall be included within any logical

group of disks.

7. The servers shall have warning lights that indicate and help identify equipment component

or subsystem faults.

8. Redundant processors (if any) shall be housed in separate rack mount enclosures to

enhance NSPOF capability.


of 115

9. Servers shall be equipped with a Network Interface Card (NIC) and, in this respect, shall

support a redundant NIC option.

10.2 Front-End Processors

Front-End Processors (FEPs) shall have server-like characteristics. They shall check for and report

protocol and other communication errors and convert the communications protocol to a common

internal format compatible with the data processing functions of the ADMS. In this way, the FEPs can

process the received data, in whole or in part, and store the processed data into the ADMS database or

pass the data on to other ADMS resources for further processing (e.g., alarm annunciation) and storage

into the database.

To protect the security perimeter associated with the SCADA functionality of the ADMS, the FEPs shall

also serve as firewalls.

It shall be possible to monitor the performance of each communications circuit or channel, to enable

and disable ports, and to switch to standby ports. Communications performance statistics shall be

collected and presented in a form designed to facilitate the identification of the communication circuits

or channels that suffer from high error rates.

10.3 Communication Network Processors (Authentication Server)

If necessary, Communication Network Processors (CNPs) shall be used for data exchange with external

computer systems. The CNPs, in general, shall satisfy the same server and auxiliary memory

requirements referenced in Section 10.1. They shall be from the same model family, use the same

operating system, and use commercially available hardware for their communication channel interfaces.

To maintain system security and prevent any unwanted CNP data traffic, firewalls shall be used.

10.4 Backup and Archive Storage Process historian servers and hard disk-based storage devices shall be used to provide the required IS&R

archive storage facilities. Hard disk-based storage devices shall also serve as the backup and storage

facilities for the ADMS databases and software. The Contractor’s backup and archive storage solution

shall comply with the following minimum requirements:

1. Be based on Storage Array Network (SAN) technology and, as applicable, Network Attached

Storage (NAS) technology.

2. Include redundant (fault tolerant) RAID 0, 1, 5 or better technology.

3. In the case of IS&R, have the capacity to retain up to 2 (two) years of stored data.

4. In the case of System backup, have capacity for two (2) years of model and configuration

data.

5. Have the necessary throughput, capacity, and redundancy to meet overall System

performance requirements.


of 115

6. Include ports of fiber channel host interfaces where applicable.

7. Support redundant hot-pluggable power supply technology.

8. Support a redundant cooling system.

9. Support local and remote data replication.

10. Support mirrored write-back cache.

11. Support clustered servers.

12. Include controller password protection for configuration control.

13. Include monitoring and controlling units and software with respect to reporting storage

health, performance, and utilization statistics.

The System shall also include rewritable single-platter DVD drives for general storage purposes. The DVD

drives shall be capable of reading and writing with CD-ROM media

10.5 Workstations

Workstations shall include all hardware necessary to facilitate optimum user access to the ADMS. They

shall include facilities to detect the loss of input power, execute an orderly shutdown upon loss of input

power, and automatically resume operation when power is restored. As a minimum, they shall consist of

the following equipment:

1. Multiple LED monitors.

2. Tower processor.

3. Alphanumeric keyboard and cursor control device.

4. Audible alarm.

5. Uninterruptible Power Supply (UPS).

10.5.1 Monitors

The monitors shall be of latest LED technology and shall satisfy the following minimum requirements:

1. Monitor: 27” LED FHD (1920 x 1080).

2. Aspect ratio: 16 x 9.

3. Viewing angle: 170 (vertical), 160 (horizontal)

4. Displayable colors: 16.7 million

5. Brightness: 250 cd/m2.

6. Contrast ratio: 1000:1.

7. Response time: 0.5 ms.

8. Video input: DVI/HDMI, DisplayPort.


of 115

9. Video tuning: On-monitor menu.

10. Base: Removable.

11. Adjustments: Height, tilt, swivel, pivot.

12. Power input: 100 -240 Vac.

10.5.2 Tower Processor

Tower processors shall include all necessary processing and display generation electronics, main

memory, and auxiliary memory and, in this respect, shall support the ADMS capacity and performance

requirements. They shall represent the latest technology available at the time the Contractor orders

them. As a minimum, they shall comply with the following requirements:

1. Processor: Intel 7h Generation or equivalent.

2. Memory: 16 GB (expandable).

3. Storage: 512 GB.

4. Graphics: NVIDIA or equivalent (2GB).

5. Display support: DVI/HDMI (capable of supporting at least 3 monitors).

6. Ports: 2 x USB, 1 x Ethernet.

7. Network: 10/100/1000 Ethernet, Wi-Fi (IEEE 802.11).

8. Disk drive: Internal DVD+/-RW.

9. Keyboard: Wireless

10. Mouse: Wireless optical.

11. Battery: Li-Ion type (60Wh).

12. Power Pack: Switched-mode type capable of accepting 100-240 Vac.

13. Operating system: Latest long-term supported Windows operating system.

14. Software: MS Office including licenses.

10.6 Firewalls Each firewall shall be of next generation type. They shall provide advanced security and control

capabilities at throughput speeds that will allow authenticated users, devices, computers, and

applications to exchange data with the ADMS or access ADMS services with no perceivable delays. As a

minimum, firewalls shall include the following features:

1. Highly effective security backed by extensive threat intelligence to reduce the risk of a data

breach.

2. Integrated Intrusion Prevention System (IPS), Web filtering, IP reputation, antivirus, and

advanced threat protection.


of 115

3. Deep inspection of network traffic to identify applications, users, devices, and threats

through granular policy controls.

4. Single operating system and consolidated user interface for all security and networking

capabilities.

5. Centralized “single-pane-of-glass” management and reporting capabilities to visualize the

security effectiveness of the firewall and help determine what strategic security policies to

implement, such visibility making it easier to control device configurations, security policies,

firmware installations, and content security updates as well as monitor what is happening in

the network through logging, in-depth reporting, and event management.

6. Highly reliable core firewall capabilities such as:

a. Authentication – Enforcement of user and application password construction rules

such as minimum length, inclusion of non-alphanumeric characters, and maximum

validity period.

b. Access Control – Different ADMS access levels for internal and external users (both

persons and applications) including none, read only, read/write, and execute.

Internal ADMS users shall be denied access to the Internet.

c. IP Spoofing – Protection against attacks in which a would-be intruder outside the

firewall configures its machine with IP addresses on the internal ADMS LAN.

d. Prevention of Denial of Service – Protection against attacks that are characterized by

attempts to deny service through overrunning buffers, filling the firewall disk, or

overrunning log files, such attacks resulting in rejection of packets where they can

be recognized or, where they are not recognized, resulting in shutting down or

denying external access when overruns occur rather than continuing to operate

with partial capability.

e. Packet Filtering Restriction – Based on both source and destination IP addresses.

f. Stateful Inspection – Determining which port numbers are used by which

connections and, when a connection closes, shutting down access to the port used

by the connection until another authorized user establishes a new connection.

g. Proxy Servers – Application proxies including HTTP, FTP, UDP, TCP, and others as

needed for the relevant ADMS functions, access to these services being

customizable based on user ID and IP address.

h. Network Address Translation (NAT) – Permitting CPRI to hide the IP addresses used

on the internal ADMS LAN from external view.

i. Notifications – Recording all break-in attempts in a log file.


of 115

10.7 Video Display Wall

The video display wall as a part of the Situational Awareness Test Bed (SituTB) shall consist of LED-

illuminated rear-projection cubes, offering the latest generation of redundant LED and DLP technology,

along with all associated equipment such as a graphics display server. The cubes shall form a continuous

single large display wall that is 2 cubes high and 2 cubes wide. The aspect ratio of each cube shall be

16:10 with a cube diagonal of 72 and a resolution per cube corresponding to WUXGA (1920 x 1200

pixels).

10.7.1 Installation

Each projection cube shall include a complete frame and mounting system, the projector and mirror

mounts, all required data and video cabling, and all internal power wired to power junction boxes

furnished by the Contractor.

The individual projection cubes shall be of rigid modular construction, fabricated to minimum tolerances

to ensure accurate and repeatable alignment. The projection cubes shall be capable of multiple

assemblies, disassemblies, and re-assemblies to accommodate factory inspection and test, shipping,

installation, and possible relocation. The video display wall shall be properly supported by pedestals

specifically designed for the SituTB laboratory and framed to ensure that there is no perceptible jitter to

the projected images caused by mechanical vibration of the overall structure.

The display structure shall be directly anchored to the concrete structural flooring of the control room

with all projection cubes positioned so that their monitors are flush with the wall’s front surface. The

lowest row of monitors shall be adjusted to a suitable viewing height above the control room’s raised

floor. This height shall be based on standard ergonomic rules for vertical and horizontal viewing angles.

The Contractor shall provide and install any additional bracing required to stabilize the display wall. If

any non-metallic materials are used as the carrier and/or support structures, the Contractor shall submit

a document identifying the chemical composition of the material(s) including fire rating and off-gassing

properties.

The front side of the display wall pertaining to pedestals and/or support base area shall include fascia

panels to provide a pleasing finished appearance. These panels shall be covered with sound adsorbing

material. The Contractor shall also provide and install trim material that bridges any gap between the

installed display wall assemblies and the rough opening created to accommodate the display wall. All

interior surfaces of the projection units housed in each cube shall have a flat black, non-reflecting finish.

The projection cubes shall be installed, aligned, and edge-matched by the Contractor for cube-to-cube

uniformity and continuity, with proper registration and alignment between cubes and without visible

changes in color, color temperature, projected image size, contrast, or light intensity from cube to cube.

In this respect, adjacent cubes shall be physically separated by no more than 2.0 mm with images across

monitors presenting a pixel-to-pixel alignment of less than 1.0 mm.


of 115

The Contractor shall adjust the installed projection cubes to provide the optimum vertical and horizontal

viewing angles. The projected images shall be clearly visible and legible from all viewing angles within

±80 degrees horizontally and ±35 degrees vertically. Each projection cube shall be capable of motorized

remotely controlled 6-axis adjustment such that one technician can mechanically adjust/align each

cube’s geometry from the front side of the display wall. Similarly, each cube shall be capable of

motorized mirror adjustments from the front side of the display wall. The means to lock and unlock all

adjustments and alignments shall also be provided.

10.7.2 Graphics Display Server

The Contractor shall supply a multi-monitor graphics display server that shall provide high-resolution

display signals to the projection cubes. The display server shall have the capability to display full graphics

and standard video images on each display unit at a minimum resolution that corresponds to the native

resolution of the cubes. For all graphics applications, the graphics display server shall treat the entire

group of projection cubes as a single display including implanted windowed data, graphic, and/or live

video displays.

The graphics display server shall enable any display on CPRI’s ADMS to be projected on the video display

wall. This shall include the ability to execute power system SCADA commands via the video wall. In this

respect, the video display wall shall serve as an ADMS workstation monitor.

As a minimum, the server from an overall perspective shall support the following types of input:

1) Analog (DSUB 15-pin connector) and digital (DVI-D, HDMI) supporting VGA to FHD resolutions.

2) SDI, Composite/PAL, S-Video, and Component-HD.

The graphics display server shall be integrated with the SituTB’s LAN via redundant 10/100/1000 Base-T

Ethernet (Gigabit Ethernet) interfaces. Communications with the ADMS shall be supported using the

TCP/IP protocol.

The server shall obtain graphics information to be shown on the video wall from the ADMS

workstations. Authorized users shall have the capability of positioning a window of any size and aspect

ratio anywhere within the video wall, including across projection display unit boundaries. The graphic

server shall support the presentation of any workstation display, including text, help, and tabular

displays.

In addition, the server shall be able to display simultaneously up to four standard (PAL) video signals as a

minimum. These video signals will be available from outside broadcast or cable sources, and will be

provided as composite video signals. The server shall display the video sources as multiple separate

windows anywhere within the video wall. The server shall also display live images from the CPRI CCTV

system that will be deployed as part of the SituTB.


of 115

As an option, the server shall also support input signals from mobile devices such as smart phones,

tablets, and laptop PCs via wireless communications. Such support shall be subject to appropriate

security features such as user authentication. Within this context, video wall display (as in “screen

mirroring”) shall be limited to display of mobile device content only, i.e., no power system control or

execution of any other ADMS function shall be possible from such devices.

The graphics display server shall be controlled through a secure user interface that allows authorized

users to control all capabilities of the server through a network application, including as a minimum:

1. Opening and closing application displays from any ADMS workstation.

2. Defining, editing, and saving display configurations.

3. Performing remote diagnostics on the server.

4. Controlling the projectors such as on, off, standby, brightness, and contrast.

The user interface shall be Windows based and available through the LAN. It shall have an automatic

display configuration feature that can open, close, or adjust the size of multiple windows at pre-

determined locations at a specified time of day or day of the week, with no user intervention. The server

shall include wireless keyboard and mouse ports that shall provide all control and configuration features

for the projected display as described above.

The Contractor shall provide the interconnection cables between the server and the projectors. The

server interface equipment shall be strategically located to minimize cabling.

The server's output to each projection display unit shall be through a direct digital link conforming to the

latest version of the DVI (Digital Visual Interface) standard. The server shall be a standard rack-mount

assembly, mounted and secured to the display unit structure with theft-proof mounting on a pullout

tray by the Contractor. The server shall be installed within the projection cube base modules and shall

be front accessible.

When the graphics display server receives a command to show a new display or windowed display via

one of the projection cubes, the new display format shall be generated completely within one (1)

second, without any interference or delay to one-second periodic updates to all other projection cubes

handled by the server, regardless of the current configuration of display windows on the other

projection cubes.

The application display updates coming from the ADMS shall be displayed on the video display wall

without delay at the same speeds with which they are displayed on the ADMS workstations. The

capability of the video display wall to support this feature shall be demonstrated during ADMS factory

testing.


of 115

10.7.3 Video Wall Maintenance

The video wall design shall permit maintenance personnel to easily perform diagnostic tests as well as

adjust each projection display unit. This shall include easy access to all display components for cleaning,

adjustment, replacement, and other maintenance tasks. In this respect, projection cube front access

shall be possible.

Each projection cube shall have a fully modular projector/engine that allows for easy replacement in less

than 20 minutes, where fully modular is defined as having the optics, light source, I/O chassis, and 6-axis

adjuster all combined in a single replaceable component to minimize downtime in case of a failure. In

addition, all projectors shall be capable of being removed, repaired, and reinstalled in any display unit

with minimal readjustment.

10.7.4 Projection Cube Characteristics

Each projection cube shall consist of an optical light engine, a cabinet with built in mirror, and a

projection screen that is mounted to the cabinet. The cabinets shall be designed so that they can be

interlocked to form a rigid overall display wall.

The optical light engine in each cube shall be driven by a redundant LED light source (4 to 6 LEDs per

color). Upon failure of a light source, the redundant configuration shall support automatic switch over.

Otherwise, the optical light engine shall be based on single-chip DLP technology meeting or exceeding

the following criteria:

1. Minimum WUXGA (1920 x 1200) native resolution.

2. Projector brightness of at least 730 ANSI lumens in bright power mode.

3. Brightness uniformity greater than 95%.

4. 16.7 million colors.

5. Illumination system life of at least 60,000 hours in continuous 24-hour, 7 days per week

operation.

6. Contrast ratio of 1500 to 1 minimum.

7. Mean Time Between Failure (MTBF) greater than 150,000 hours in continuous 24-hour, 7

days per week operation.

Each projector/engine shall include color matching and brightness control features that allow CPRI

personnel to easily adjust the color balance and brightness of each individual display unit to match the

other units in the display wall. It shall also include a built-in mechanism for frequently monitoring color

and brightness automatically and, as needed, adjusting its light source over time to ensure optimal

brightness and color uniformity is maintained for the entire wall.

The projector/engine in each cube shall employ a maintenance free cooling system with typical

component lifetimes of at least 100,000 hours. The cooling system shall not require any scheduled


of 115

maintenance during its lifetime and shall be a forced air cooling system to avoid, as in case of a liquid

based cooling system, the risk of coolant leaks and scheduled maintenance.

The display unit monitors shall be wide-angle, high-contrast, multi-element, cast acrylic, rear-projection

monitors specifically designed for use with high brightness single lens projectors. The viewing side of the

monitors shall have an abrasion resistant, anti-glare surface. On-axis gain shall be 1.0 minimum, with a

minimum horizontal and vertical ½ gain angle of + 33 degrees.

10.8 RTUs

The SituTB shall utilize one or more RTUs that may be installed in the CPRI on and off campus

substations as a basis for demonstrating the capability of SCADA to directly monitor and control typical

substation equipment.

NOTE: SGTB RTUs will be acquired through the SGTB Distribution Automation Test Bed purchases. The

RTU specification will remain in this SituTB document for reference, but has been reproduced and

modified in the DATB Specification. Refer to the DATB specification for the latest RTU information

including recommended point count

The RTUs shall support two-way data communications with the SCADA component of the ADMS. In this

respect, the ADMS and RTUs shall communicate over CPRI’s optical fiber IP-based WAN. The data

communication protocols supported by the RTUs shall include:

1. IEC 60870-5-104

2. DNP3 over TCP/IP or UDP/IP

3. Modbus RTU

4. IEC 61850

10.8.1 Data Acquisition

In accordance with each communication protocol, support for data acquisition shall include:

1. Polling of the RTU by the ADMS for specified status and analog data points at configurable

scan rates or on demand.

2. Report-by-exception, i.e., polling of the RTU in such a way that for status data points only

those that have changed are sent to the ADMS and for analog data points only those that

have changed by a configurable dead band.

3. Unsolicited reporting in which the RTU sends the changed data automatically without

waiting to receive a poll command.

4. General interrogation in which the ADMS polls the RTU for all available data.

10.8.1.1 Analog Inputs

The RTU shall:

1. Acquire analog inputs directly without transducers from power system voltage and current

terminals.


of 115

2. Apply suitable filtering to eliminate the risk of signal aliasing.

3. Use voltage and current inputs for calculations that support acquisition of the following data

as a minimum:

a. Line-to-line voltages.

b. Phase current magnitudes and phase angles.

c. Real and reactive powers (three-phase kW and kVar totals with sign).

d. Power factor.

4. Accept ac voltage input signals with a normal input level of 110 V.

5. Employ analog to digital converters with minimum of 16-bit resolution for a bipolar input

signal.

6. Accurately resolve ac voltage input signal levels from 0 to 150 V.

7. Accurately resolve ac current input signals with normal ranges of 0 to 5 A or 0 to 1 A.

8. Include the capability to report all analog values that have changed by more than their

programmable dead bands from their last values successfully reported to the ADMS.

9. Record maximum rms fault current signals, over a period of at least one (1) second, up to 20

times normal (100 A) within a maximum error of 2.5% of Full Scale Deflection (FSD).

10. Not impose a total analog input burden of more than 0.5 VA for all current and voltage

inputs.

11. Demonstrate an overall analog input error of no more than ±0.2% of 1.2 times normal FSD

over the temperature range 0 to 70°C.

12. Demonstrate an analog input linearity better than ±0.05%.

13. Reject common mode ac (50 Hz) voltages up to 150 V.

10.8.1.2 Status Inputs

As a minimum, RTUs shall accept isolated wet and dry single contact two-state status inputs and two-

state status inputs with memory, i.e., Momentary Change Detection (MCD) inputs. Input changes of

state shall be time stamped to a precision of 1 millisecond.

Within this context:

1. All necessary wetting voltage, current limiting, input isolation, and bounce filtering shall be

provided.

2. Contact de-bounce time periods shall be individually configurable.

3. The input circuits shall be optically isolated from the external signal.

4. Input contact wetting voltages shall be 24 VDC as obtained from the RTU’s DC power supply.


of 115

5. Each wetting voltage circuit shall be protected with its own circuit breaker.

10.8.1.3 Analog Outputs

RTUs shall include the capability to receive analog output signals from the ADMS such as those that may

be used to send set points to automatic voltage regulators.

10.8.1.4 Control Outputs

The RTU shall support the capability to receive commands such as those that may be used by relays to

open and close substation circuit breakers or other switches. Such commands shall include the

following control output features:

1. A Select-Check Back Before-Operate (SCBO) procedure:

a. On receipt of a control point select command, the RTU shall check that no other

point is selected, select the requested point, acknowledge the select command, and

start a Command Receipt Timer.

b. Control point selection shall be canceled if the subsequent operate command is not

received within the Control Receipt Timer’s programmable time-out period, which

shall be adjustable from five (5) to thirty (30) seconds.

c. On receipt of the operate command, if the control point has remained selected and

no other point has become selected, the RTU shall then initiate the requested

control action.

d. The SCBO procedure shall be canceled automatically on completion of the control

action or if not completed within an adjustable time-out period of up to 60 seconds.

e. Any further attempt at control shall require a new SCBO procedure.

2. Opening and closing of a switch by sending commands to a complimentary pair of contact

outputs such that:

a. One command activates the contact used to open the switch.

b. The other command activates the contact used to close the switch.

c. Only one contact output in a complimentary pair can be activated at a time.

3. Momentary control where each output provides a contact closure pulse having an

individually programmable duration from 1 to 60 seconds in increments of 1 second.

The following requirements shall also apply:

1. The voltage rating of the control output contacts shall be 24 VDC.

2. All control power shall be obtained from the RTU’s 24 VDC power supply.

3. RTU control outputs shall be able to drive loads of at least six (6) amps.

4. Output relays shall be designed for 106 (one million) mechanical operations.


of 115

5. The RTU shall monitor all operations and local status information and give warnings or

advisory messages when any wrong operational sequence is requested.

6. Abnormal conditions shall inhibit control operations.

10.8.2 RTU Architecture

The RTU shall incorporate a programming capability within an architecture that supports convenient

installation, maintenance, and expansion features. The architecture shall include a central processing

module, I/O module, control module, communications module, and time and date module.

10.8.2.1 Central Processing Module

The Central Processing Module (CPM) shall:

1. Support a high-level language processing capability per the open IEC-61131-3 standard for

programmable logic controllers.

2. Support management of the RTU database from a local test set.

3. Support ADMS download and upload of RTU parameters and configuration data.

4. Implement the communication interfaces with the ADMS.

5. Control data acquisition and the sending of control commands using an I/O module.

6. In accepting commands from the ADMS:

a. Perform address recognition.

b. Assemble response messages in accordance with the received command messages.

c. Transmit these messages to the ADMS.

7. Provide interfaces for a time standard and test set.

8. Manage communications between all other functional modules of the RTU.

9. Determine the integrity of the RTU.

10. Provide diagnostic information in the message structure that the ADMS shall monitor.

11. Set a flag if the RTU performs a restart for any reason including power failure.

12. Include a watch-dog timer that is reset regularly by RTU software. If the software fails to

reset the watch-dog timer (e.g., because of a software error causing the software to “loop”

or “hang”), then the timer shall expire causing the CPM to reset and restart.

10.8.2.2 I/O Module

I/O module requirements include the following capabilities and features:

1. Capability to accept analog and status inputs and send control outputs. This shall include

fault current measurements.


of 115

2. Capability of being replaced without reprogramming, redefinition of configuration

parameters, or rewiring.

3. A Control Switch (CS) that, if not in its normal control position, inhibits control from the

ADMS or test set.

4. A status input contact so that the ADMS or test set can monitor if the position of the CS is in

its normal control position.

10.8.2.3 Control Module

The RTU shall include an integrated control module that can control devices without the need for

interposing relays.

10.8.2.4 Communications Module

The RTU shall be provided with a communications module including necessary and sufficient numbers

and types of port that can be used to support:

1. Remote data communications with external systems and devices over an Ethernet/IP

network. This shall include data communications with multiple masters.

2. Local connection to instrumentation by Ethernet AND at least (2) serial communication

ports configurable as RS232 or RS485 supporting all configured protocols.

3. Local and remote configuration with a static IP address.

4. The fully implemented message security features of the required data communication

protocols running over TCP/IP.

5. Communications that is not degraded by simultaneous activity in other parts of the RTU.

6. Temporary connection of test sets such as laptop PCs for local installation, maintenance,

diagnostic, and test purposes for all configurations and data access functions associated

with the RTU.

7. SCP/SSH with respect to downloading, for example, RTU configuration parameters and

firmware updates.

8. Features such as HTTPS for web server functionality.

9. Blocking or disabling of ports to prevent unauthorized access.

10. MAC and IP filtering so that Ethernet traffic is limited to a configurable “whitelist” of

network device MAC and IP addresses.

11. Access control using a secure log-in procedure. As a minimum, this shall include user

authentication based on a unique username and password.

12. System logging (syslog) at a device or system level. Syslog alerts shall include remote user

access activity including successful and unsuccessful login attempts.


of 115

13. Manual configuration of a routing table with different metrics so that networks may be

reached using locally entered alternative paths (IP redundant paths for example).

10.8.2.5 Time and Date Module

The RTU’s time and date module shall:

1. Include an internal time-of-day clock for data collection coordination. The time resolution of

the internal clock shall be one (1) ms or better and, without synchronization, the time shall

drift by no more than 5 ms per hour.

2. Use the RTU’s 24 VDC power supply as the only source of power for the internal clock, i.e.,

no other source such as an internal (on-board) battery shall be used.

3. Synchronize the internal clock whenever the RTU is powered up. This shall not prevent the

RTU from immediately registering inputs even before the time and date reference signal has

been received. Any such inputs shall be reported to the ADMS with the appropriate time

and date, i.e., use of an arbitrary default time and date is not acceptable.

4. Support receipt of a DNP 3.0 compliant time and date message that contains a Greenwich

Mean Time (GMT) reference signal, generated by the ADMS in long format and in such a

way as to properly account for communication path delays.

5. Support capability to synchronize the internal clock to the GMT time and date received from

the ADMS.

6. Support capability to synchronize to an optional Global Positioning System (GPS) receiver.

The GPS antenna shall be of low profile type for secure and moisture-resistant mounting on

top of the RTU enclosure. The receiver shall be used to synchronize the internal clock to the

correct GMT time and date within a time resolution of at least 1 millisecond.

10.8.3 DC Power Supply

The RTU scope of supply shall include a 24 VDC power supply. It shall be used to power the RTU and its

local control panel. It shall also be capable of powering local test sets from an RTU enclosure power

receptacle. The supplier shall be responsible for determining its maximum output capability.

10.8.3.1 Batteries

Under normal conditions, the DC power supply shall connect to a substation 230 VAC power supply. As

backup, however, it shall be powered by a 24 VDC maintenance-free rechargeable battery with the

following characteristics:

1. Be of lead-acid gel electrolyte type.

2. Be designed and tested per IEC 60896-21, DIN 43534, BS 6290 Part 4, or equivalent.

3. As a minimum, have sufficient capacity to sustain operation of the RTU and its local control

panel for not less than twelve (12) hours if the ac power source fails.


of 115

4. Be designed using an appropriate temperature correction factor, design margin, and ageing

factor.

5. Have a minimum lifetime of not less than 8 (8) years at a nominal temperature of 20 °C.

10.8.3.2 Battery Chargers

The DC power supply shall include an intelligent battery charger, which shall:

1. Be of switched-mode 100-240 VAC power input type.

2. Be fully temperature compensated.

3. Be automatically switched to charging mode when the battery voltage drops below a preset

value and, in the following cases, be automatically switched to a “do not charge” trigger

mode:

a. Battery voltage is over the preset value.

b. Ambient temperature is more than 60 °C.

c. Charging time is more than a configurable number of hours, e.g., twenty-four (24)

hours.

d. Battery exhibits a high impedance (battery failed) condition.

4. Have over current, over voltage, and surge protection.

5. Prevent deep discharge of the battery on loss of the AC power source. In this respect:

a) The battery charger shall automatically disconnect all circuitry fed by the battery

following a user-adjustable time or when the battery voltage falls below a preset

value.

b) The time to fully recharge the battery once disconnected from load shall not

exceed twenty-four (24) hours.

c) The direct current power will be cut off when voltage stays under the minimum

preset value.

In addition to the above requirements, the capability to initiate the following alarms shall be provided:

1. Low battery voltage alarm.

2. High battery voltage alarm.

3. Battery failed alarm.

4. Battery charger overvoltage alarm.

5. Battery disconnected alarm.

Each alarm indication shall be displayed on the RTU’s local control panel with super bright LED pilot

lamps. These alarms shall be reported to the ADMS as an event.


of 115

10.8.4 Local Control Panel

The RTU shall include a local control panel, which shall include:

1. A mimic diagram and facilities for operation of RTU local control functions.

2. An A/C power supply on/off switch. When the A/C power source is off, operation of the RTU

shall be possible by using its battery backup feature.

3. A Local/Remote switch. While this switch is in the “Local” position, control shall be

permitted only from the local control panel (i.e., remote control shall be prohibited).

Otherwise, while the switch is in its “Remote” position, control shall be permitted only from

the ADMS (i.e., local control shall be prohibited).

4. LED lamps for RTU, battery, battery charger, and local/remote status indications.

5. Battery voltage test points.

10.8.5 RTU Software

The term “software” is used to mean software or software implemented through firmware. Complete and

comprehensive documentation shall be provided for all software.

10.8.5.1 Operating System

The RTU operating system shall:

1. Be a real-time non-proprietary operating system.

2. Manage and support all RTU applications.

3. Support editing and customization as needed to maintain RTU operation.

4. Provide automatic restarts of the RTU on power restoration, memory parity errors,

hardware failures, and manual request.

5. Initialize the RTU on power-up and begin execution of the RTU functions without

intervention by the ADMS.

6. Report all restarts to the ADMS.

10.8.5.2 Operating Software

The RTU operating software shall be:

1. Prepared in a high-level language such as the IEC61131 programming suite.

2. Documented in detail.

3. Free of additional licensing charges or license agreements.

4. Supported by protocol, configuration, and application data contained in easily

programmable non-volatile memory such as Flash EPROM.


of 115

5. Independent of any data communications protocol that would impose restrictions on the

flexibility or functionality of the RTU. In this respect, protocol changes shall be capable of

being accomplished by locally and remotely implemented software/firmware changes only.

10.8.5.3 Diagnostic Software

RTU diagnostic software shall:

1. Continuously monitor operation of the RTU.

2. Report RTU hardware errors to the ADMS.

3. Check for memory, processor, and input/output errors and failures.

4. Be sufficiently detailed to detect malfunctions to the level of the smallest replaceable

component.

5. Facilitate isolation and correction of all failures.

6. Include features promoting rapid fault isolation and component replacement.

7. Include integrated on-line diagnostic functions in all functional module nodes.

8. Report diagnostic results to the CPM for store and forward to the ADMS.

10.8.6 Enclosures

The RTU equipment, including local control panel, batteries, and battery charger, shall be housed in a

suitable enclosure.

To safeguard against outdoor installation, the enclosure shall prevent moisture condensation including

corrosive salt formations and the ingress of rain water, airborne dust, vermin, and small objects. It shall

be designed to ensure that it remains rigid and retains its structural integrity under all operating and

service conditions with and without the door being closed. In this respect, it shall be fabricated from

stainless steel panels (Type 304L) of not less than 2 mm in thickness, and the door opening shall have a

perimeter flange with a rubber or neoprene gasket. The finishing coat shall be grey (RAL 7032).

A pocket attached to the inside of the door shall be provided to hold documentation such as

maintenance log sheets, control unit diagrams, and operating instructions. The door shall be opened by

a single handle, which shall be capable of being locked by use of a padlock and key. A means to remotely

monitor the open/closed status of the enclosure’s door shall be provided. An equipment alarm shall be

generated whenever the door is opened.

The enclosure shall include a grounding terminal with grounding bolt and lock washer for connecting a

50 mm2 galvanized steel grounding conductor. The grounding bolt and lock washer shall be made of

stainless steel.

10.9 Gateway The Gateway shall support the ADMS as a remote server allowing the ADMS to interoperate with the

SASTB, i.e., allow the ADMS to perform remote SASTB monitoring and control functions via the HMI


of 115

system and individual IEDs that comprise the SASTB. In this respect, it shall be able to communicate with

the ADMS using the IEC 61850-90-2, IEC 60870-5-104, or DNP 3.0 protocols, over serial or IP data

channels, while simultaneously serving as an SASTB client, in effect as a data concentrator capable of

communicating with the SASTB HMI system and any or all SASTB IEDs using the IEC 61850 protocol. The

Gateway shall also serve as a protocol converter for any other end device that may need to

communicate with the ADMS. For example, where the RTU (perhaps as an ADMS interface to the DATB)

supports IEC 60870-5-104 and the ADMS is configured to use DNP 3.0.

In its multi-protocol support for the ADMS data acquisition and control functions, the Gateway shall

include:

1. A database with a real-time capacity equivalent to 10,000 signed 16-bit points, which can

accommodate combinations of digital, analog and counter data.

2. Support for autonomous automation applications via integrated IEC 61131-3 compliant

programmable logic runtime.

3. Integrated web server for password authorized remote access via a standard browser (such

as Explorer and Firefox).

4. Password authorized local or remote access for user configuration via standard off-the-shelf

user friendly software.

5. An integrated archiving facility for event and computed analog data trends for operational

management analysis.

6. Protection against security threats including RBAC password permissions, SHA 512 password

data encryption, centralized password management, integrated firewall protection with

strong port blocking and restriction, secure open path access protection, and centralized

logging.

7. Communications capability for 10/100BaseT(X), 100BaseFX Ethernet.

8. A minimum of 8 serial ports for 9,600 to 115,200 Baud operation over RS232 or RS 485

communication links.

The Gateway shall be fully solid state and suitable for installation in substation environments. In this

respect, it shall conform to all applicable Indian (or equivalent international) standards with respect to

electrostatic and electromagnetic immunity as well as environmental withstand requirements.

10.10 Substation Surveillance Equipment

The substation surveillance equipment shall consist of a Video Management Server (VMS) and, at CPRI

option, one or more IP cameras. This equipment shall be substation hardened allowing CPRI to install

the equipment in CPRI’s on or off campus substations.

10.10.1 Video Manager Server

The Video Management Server (VMS) shall be able to record video images from IP cameras and, on

analysis, automatically send real-time alerts (based, for example, on motion detection and camera

tampering) along with video images to the ADMS. Live video streaming shall also be supported along


of 115

with camera control capabilities such as pan, tilt, and zoom. Control shall be possible remotely from the

ADMS as well as locally from a portable PC. Within this context, VMS key features shall include:

1. Compliance with IEC 61850-3 and IEEE 1613

2. Operating temperature range of -40°C to +85°C (no fans)

3. Dual power supply option (24 VDC, 48 VDC, or 85-250 VAC)

4. Ethernet LAN and/or wireless interface for IP cameras (up to 4 cameras)

5. Compression technology based on H.624 and JPEG encoding

6. Serial, USB, and digital I/O interfaces (e.g., control of substation lights and alarm horns)

7. Ethernet (10/100/1000 Base Tx), wireless (802.11 b/g), and cellular modem interface ports

for interoperation with the ADMS

8. ADMS integration support (e.g., DNP 3.0)

9. VGA interface for local monitor

10. Rack mount (19”, 2U height)

11. Audio output interface

12. Local solid-state storage up to 1 TB

10.10.2 IP Cameras

At CPRI option, various forms of IP camera suitable for outdoor installation may be utilized with the

VMS. They shall include, for example, an IP camera with the following capabilities and features:

1. Full HD 1080p (60/30 fps)

2. Progressive scan

3. Onboard infrared illuminator

4. Pan-tilt-zoom control

5. Wide angle, day and night vision, 30x zoom lens

6. Focal length 6mm - 180mm

7. Digital 32x zoom

8. Video compression H.264, MPEG-4, MJPEG

9. Streaming capability

10. Powered from Power-Over-Ethernet

11. IP66 rating, -40°C to +60°C operating temperature, 90% relative humidity

10.11 Time and Frequency Facility A time and frequency facility, compatible with IEC 61850-9-3, shall determine Universal Coordinated

Time (UTC), power system time, time deviation, power system frequency, and power system frequency

deviation. UTC shall be obtained from the Global Positioning System (GPS) satellite constellation. The

time receiver shall include propagation delay compensation to provide an overall accuracy of ±40 ns

(±150 ns peak) when tracking satellites and shall also include an offset to permit correction to local time.

The time and frequency facility shall be and shall output time and date reference signals to synchronize

the internal clocks of ADMS servers/processors. Using Greenwich Mean Time (GMT) and taking


of 115

communication path delays into account, the ADMS shall also be capable of synchronizing the internal

clocks of field devices such as RTUs.

System time shall frequently be compared to the time standard unit and synchronized to keep system

time within ± 1 (one) millisecond of standard time for use in time tagging of all data, alarms, and events.

A common time code output format such as IRIG-B shall be supported. Also, as a minimum, four (4)

communication ports shall be provided with drivers capable of supporting communication protocols

such as NTP, SNTP, and TCP/IP.

Upon loss of satellite time signal, the time and frequency facility shall revert to an internal time base.

The stability shall be 2 x 10-6 or better when not tracking satellites with an output time drift not

exceeding 30 milliseconds per day. The time shall return to within ±1.5 ms of UTC within five minutes of

reacquisition of signal.

The local frequency input shall be separate from the time and frequency facility's power input.

The time and frequency facility shall include an antenna suitable for outdoor mounting along with

connector, cable, and a surge protection system capable of preventing equipment damage from

lightning. A cable distance of 50 meters shall be assumed. The Contractor shall determine the actual

cable length prior to installation.

The time and frequency facility shall also include an alphanumeric display and keypad on its front panel.

The display shall show time, facility and satellite tracking status, as well as all setup parameters capable

of entry via the keypad.

10.12 Cellular Modem To support devices capable of communicating with the ADMS using third-party service providers, such

as the Video Manager Server (VMS) described in Section 10.10.1, a cellular modem shall be provided in

the form of a router with the following features:

1. 230VAC 50-Hz power

2. 4 Ethernet ports

3. VPN support

4. Intrusion Detection capability

5. Single T1/E1 interface

6. Cellular modem interface – LTE, 3G, GPRS

7. SNMP Management version 2c and version 3

8. Web-based and/or CLI (SSH) management

9. Syslog Logging

10. IEC 61850-9-3/IEEE 1588 PTP compliant


of 115

10.13 Multifunction Printers

Any printer to be supplied and connected to the ADMS LAN shall be of multifunction type. The

technology, capabilities, and features of such a printer shall be based on the following minimum

requirements:

1. Functions: Print, copy, scan, fax.

2. Print technology: Laser.

3. Print speed: More than 20 pages per minute in black and color.

4. Duplex printing: Automatic

5. Resolution: 600 x 600 dpi (black and color).

6. Duty cycle: 15,000 pages per month.

7. Print languages: Postscript, PDF, etc.

8. Paper sizes: A4, A3, letter, legal.

9. Paper trays: Input/output capacity of 250 pages.

10. Connectivity: USB, Ethernet, RJ-11.

11. Memory: 256 MB.

11 ADMS Functionality This section presents the functional requirements associated with the following applications that will be

used in real-time, study, and simulation modes to support the objectives of the Situational Awareness

Test Bed (SituTB):

Network Topology Processor (NTP)

Unbalanced Power Flow (UBPF)

Fault Location

Fault Location Isolation and Service Restoration (FLISR)

Volt/Var Control (VVC)

Feeder Reconfiguration

Outage Management

All SCADA functions required to support the applications in their different operating modes must also be

active.

11.1 Operating Modes

The three operating modes to be supported by the ADMS are described as follows:

1. Real-Time Mode. This is a mode in which the applications perform their functions by using real-time data acquired by SCADA from RTUs or other sources of real-time data including


of 115

CPRI test beds such as the DATB and SasTB. It shall also be possible to utilize pseudo real-time data, i.e., non-telemetered data as calculated by the System or entered manually. As an example, consider the FLISR application when the ADMS is connected for interoperation with the DATB representing one or more MV feeders. On SCADA receiving data from the DATB that indicates a feeder fault, FLISR shall use this data, and all other current and subsequent real-time data acquired from the DATB, to analyze the situation and send control commands, via SCADA, to isolate the feeder’s faulted section and restore power to all sections that are no longer connected to the faulted section.

2. Study Mode. This is a mode in which applications use real-time, saved, and/or modified data to produce information that can be used to examine alternative hypothetical or postulated operating scenarios. For example, the Unbalanced Power Flow (UBLF) application may be used to study what happens when the loads on a representative power system are changed from current levels to some other future levels.

3. Simulation Mode. In this case, the applications run in an environment where the real-time data acquired by SCADA is replaced by simulated data derived from a “dynamic” model that endeavors to replicate the time dependent behavior of an actual power system, under a given initial state, to various operational scenarios that may be used for training, demonstration, or any other purpose such as testing. Typically, the operational scenarios include pre-defined load profiles and events, but may also include events introduced as and when required during the simulation period. As the simulation proceeds, the model also responds to any control actions that may be initiated by the ADMS user and/or its applications.

11.2 Network Operations Model

The Network Operations Model (NOM) represents the database on which the ADMS applications

depend in all three operating modes. In this respect, the model shall support:

1. Analytic models of electrically connected power system elements including conventional

and renewable energy resources, substation transformers with tap changers, circuit

breakers, disconnectors, overhead and underground circuits, line reclosers, load break

switches, shunt capacitor banks, automatic voltage regulators, var controllers, distribution

transformers, electrical loads, etc.

2. Meshed and radial power system configurations including single-phase and two-phase

circuits and associated loads as well as non-symmetrical three-phase circuits and loads. In

this respect, the models shall allow for three-phase balanced and unbalanced operations.

3. Information for schematic displays of the electrical facilities showing individual elements

and interconnections along with the operating state and related information.

4. Information for geographically oriented displays of the distribution network showing the

individual elements, their operating state, associated land based information, operations

data, facilities, equipment, locations of field crews, and other related information.


of 115

5. Operations data such as feeder and device status indications, associated statistics, tags,

operating limits, set points, power flows, voltages, currents, transformer tap positions,

quality codes, fault passage indications, alarms, and outage locations.

6. Facility and equipment information such as status, alarms, location and site details,

electrical and mechanical design parameters, photographs, contact replacement indices,

operating instructions, and maintenance procedures. This information shall be made

available by equipment point and click operations on relevant displays and presentation of a

drop down menu allowing the user to select the information of interest.

7. Modeling that accounts for temporary jumpers, grounds, and cuts. Using a world map

display, the user shall be able to make changes that reflect those that were planned (e.g., a

lineman doing maintenance work) and unplanned (e.g., a tree falling and breaking a power

line). This feature shall allow the user to change the power system model very easily and, at

the same time, have the display symbolically updated to show, for example, a feeder being

jumped (attached) to another feeder, grounded, or cut. It shall be possible to "back out"

(undo) the change when the repair is completed to restore the power system display and

model to their original states. The feature shall support single-phase as well as three-phase

changes, and all such changes shall be made without the need for a formal editing session to

modify the ADMS database.

8. Field crew information such as names, planned assignments, completed assignments, and

current location.

9. Land based information such as street maps, buildings, waterways, and other landmark

detail.

10. A dynamic operations model that in addition to the NOM characteristics above shall be used

when the ADMS is in simulation mode. Further details are provided in Section 12.2.

11.3 Network Topology Processor

This application shall be capable of automatically analyzing the open/closed status of power system switching devices to determine the electrical connectivity and the energization, de-energization, or grounded status of power system components such as generators, transformers, lines, and capacitor banks.

The status of the switching devices shall be obtained from real-time, simulated, and/or manually entered data. These devices shall include all relevant power system elements such as circuit breakers, switch disconnectors, line reclosers, remote controlled switches, and capacitor bank switches. They shall also account for the connectivity changes that occur when temporary jumpers, grounds, and cuts are applied to the power system.

The Network Topology Processor (NTP) shall result in an updated power system model that can be used by the applications which depend on the model to analyze the system under postulated system conditions as well as actual and/or simulated real-time conditions. The user shall be able to execute the NTP on demand as well as periodically. In addition, NTP shall automatically and efficiently result in an updated power system model whenever a switching device status change is detected.


of 115

11.4 Dynamic Network Coloring

Dynamic Network Coloring (DNC) shall enable users to quickly recognize the power system’s operating

status on all associated tabular and one-line diagram displays. As a minimum, this shall allow the

energized, de-energized, faulted, grounded, and overloaded conditions of the power system to be

differentiated, using various color codes automatically following execution of the NTP.

In addition, DNC shall allow users to request distinctive color-coded traces that can quickly highlight

electrically connected elements of the power system through simple point-and-click operations. User-

requested tracing results shall be displayed only at the workstation where the request is issued; multiple

users at different workstations shall be able to request and view different tracing actions in parallel.

Such traces shall include, but shall not be limited to:

1. Highlighting the entire electrical island or feeder section to which a power system device selected by the user is connected.

2. Highlighting the upstream power supply path from the user-selected device to the head-end power injection point including the path’s load break switches, reclosers, and circuit breakers.

3. Highlighting all feeder sections downstream of the user-selected device.

11.5 Unbalanced Power Flow Unbalanced Power Flow (UBPF) shall calculate the state of a power system that is defined in the SituTB

by its applicable Network Operations Model (NOM). The solution shall include individual phase voltages

and phase angles at all buses corresponding to any unbalanced (or balanced) power system

configuration. This shall include meshed and radial systems.

11.5.1 Input

Depending on its operating mode, UBPF shall calculate the state of the power system network based on:

1. Real-time, simulated, manually-entered, calculated, and/or saved base case data.

2. Models of power system loads at substation buses, distribution transformers, and customer

points of connection.

3. Models corresponding to the operation of automatic devices such as OLTC transformers,

voltage regulators, capacitor banks, and var controllers.

4. Models of power plant connected at different voltage levels. This shall include distributed

generation such as small-scale Diesel, PV-Solar, and Wind-Turbine units.

To perform a power flow analysis on a distribution network it is necessary to have complete and

accurate information on all loads in the network. Hence, for feeder loads not usually telemetered, an

iterative Bus Load Allocation (BLA) function shall be used to allocate loads to buses based on nominal

(i.e., historical) load profiles that correspond to the date and time for which the analysis is required. For

example, non-telemetered loads may be allocated by multiplying their nominal values by scaling factors

accounting for any telemetered power flows that are available and, on this basis, UBPF can then execute


of 115

to provide a state estimation for the network. As may be necessary, however, the load allocation and

UBPF process shall iterate until the differences between the telemetered values and their UBPF

calculated values are acceptably minimized.

The BLA function shall have the following capabilities:

1. Allocation of loads for both radial and meshed distribution networks.

2. Incorporation of system losses during the allocation procedure.

3. Support for multiple load models associated with a single network node.

4. Support for three phase and single phase load models associated with a three-phase

network node.

5. Estimation of loads to be restored after an outage (either planned or unplanned) as a

function of the allocated load and cold load pickup models that account for outage duration

and load type.

During real-time power flow executions, load profiles shall be updated and stored for a configurable

number of daily time periods for each day type for each load. Typically, the system will be configured to

store updated historical load profiles per day type per load. The number of stored historical values may

be increased by the system administrator.

11.5.2 Output

As a minimum, UBPF shall calculate the following quantities:

1. Real power, reactive power, and three-phase current for all circuit elements.

2. All three phase-voltages at all buses.

3. Total real and reactive losses, line losses (load and no load), and transformer losses (load

and no load) both in kW and in percent.

4. Tap positions for substation transformers and line voltage regulators.

5. Switch positions for capacitors and automatic transfer switches.

6. Feeder voltage drops.

7. Bus voltage and power flow limit violations (e.g., values outside their normal and emergency

values).

8. Phase imbalance of 3-phase circuits (e.g., average phase current minus minimum phase

current, divided by the average current).

9. Voltage imbalance of 3-phase buses (e.g., maximum voltage minus average voltage, divided

by the average voltage).


of 115

10. Voltages and currents on single and 2-phase portions of the network.

The power flow results shall be made available in tabular form and on one-line diagrams equivalent, for

example, to the graphical displays used for real-time dispatching. It shall be possible to print any

selected UBPF tabular or graphical display and to store and retrieve UBPF solutions as save cases.

Tabular displays shall show a comprehensive list of all violations, but only a single alarm message shall

be sent to the centralized alarm system. The violations shall also be displayed as colored halos on the

geographic network view. At high zoom levels the individual components shall be marked with halos to

indicate voltage or overload violations. At lower zoom levels the entire line segment shall be shown with

a halo.

An exception summary display shall show key substation data points from the UBPF solution. The display

shall be ordered such that the substation with the most significant problems is listed at the top. Within

this context, it shall be possible:

1. To navigate to a feeder exception summary display by clicking on a substation name.

2. It shall be possible to navigate to individual network components with limits exceeded by

clicking on a value in the feeder exception summary.

It shall also be possible to show UBPF results for any network component in a pop-up window by selecting the device on the network view and clicking the appropriate button on a toolbar.

11.6 Fault Location

The Fault Location (FL) application shall provide input to the outage management function by using

telemetered information from relays and fault passage indicators to automatically determine the

suspected location of a fault, such information as may be received by the ADMS directly from individual

devices or indirectly from RTUs. On this basis, FL shall be able to:

1. Process un-commanded status changes and fault passage indications received by SCADA.

2. Determine which feeders have sustained faults.

3. Highlight the switchable feeder sections that contain the faults on feeder network displays.

4. If fault current levels are available, calculate distances to fault so that the faults may be

located more precisely.

5. Highlight the switchable feeder sections and the suspected fault locations on feeder

network displays, which for some feeders may require several possible fault locations to be

highlighted.

FL shall not issue any alarms. The user shall be notified of fault-related problems through SCADA. The

user shall then be able to quickly navigate to fault location displays.

11.7 Fault Location Isolation and Service Restoration (FLISR)

A Fault Location Isolation and Service Restoration (FLISR) application shall enable power to be restored

to loads following a sustained feeder fault. FLISR shall create a Switching Plan which isolates the faulted


of 115

area and provides service restoration by using optimal feeder reconfigurations, including cascading

reconfiguration to off-load one feeder to pick up part of the load of an adjacent feeder. In this respect,

FLISR shall be capable of one or more operational objectives, including minimizing un-served kW,

minimizing customer minutes interrupted, minimizing the number of switching operations, and

minimizing voltage drop along the reconfigured feeders. The problem formulation shall specify the

network and operational constraints including segment overloads, voltage violations, and relay settings.

The viable fault isolation and service restoration plans shall be shown in ranked order based on a set of

pre-defined criteria. It shall be possible to select a plan to display the individual steps of the plan.

To avoid closing into a fault, FLISR shall always isolate the faulted section from the un-faulted de-

energized sections and then restore the un-faulted de-energized sections. Acting autonomously, FLISR

shall always close the upstream protective devices that tripped to restore the loads upstream of the

fault. Otherwise, FLISR shall run in two user selectable modes:

1. Closed-loop mode, in which case the best plan is automatically selected and executed based

on the SCADA controlled switches that are available.

2. Advisory mode, in which case the pans are presented in ranked order so that the user can

select the plan for subsequent manual or automatic implementation.

Protection settings selection shall be automatically determined and modified during closed-loop FLISR

operation to ensure proper operational settings.

The user shall be able to define the operational objectives of the FLISR application. As a minimum, the

objectives shall include:

1. Minimize Unserved Load - Restore as much load (kW) as possible while respecting user-

specified limit sets. This shall allow the user to run FLISR so that only SCADA controlled

switches or both SCADA and manually controlled switches are considered.

2. Minimize Customer Minutes Interrupted (CMI) – Find restoration plans that minimize the

total number of customer minutes interrupted, where CMI depends on manual and

automatic switch operation times.

3. Minimize Loss of Customer Value of Uninterrupted Service - Find restoration plans that

minimize the loss of customer value of uninterrupted service. The customer priorities are

assigned based on the costs of uninterrupted service that are given to each load category.

4. Minimize Number of Switching Operations - Find restoration plans that minimize the total

number of switching operations.

5. Minimize Voltage Drop Along Reconfigured Feeders - Find restoration plans that minimize

the voltage drop between the highest voltage and the lowest voltage along the feeder.

It shall be possible for the user to enable or disable FLISR. When enabled, in addition to being triggered

on sustained feeder fault, FLISR may also execute on substation or feeder loss of voltage.


of 115

11.8 Volt/Var Control

A Volt/Var Control (VVC) application shall be provided. It shall enable the user to optimize power system

operations from the perspective of user-selectable objective functions, controls, and constraints such as

follows:

1. Objective Functions

a. Minimize MW losses

b. Minimize power factor penalty functions

c. Minimize total MW demand (energy conservation)

d. Minimize total Mvar demand (emergency var support)

2. Controls

a. Var Control Active

i. Switched capacitor banks in substations where each bank may be switched

on or off independently either remotely or locally.

ii. Switched capacitor banks on feeders such as a single capacitor bank that

may be switched on or off remotely or locally.

b. Volt Control Active

i. Substation transformer tap positions and/or their AVR voltage set points.

ii. Feeder regulator tap positions and/or their AVR voltage set points.

3. Constraints

a. Var Control and/or Volt Control Active.

i. Maximum and minimum limits on voltage magnitudes.

ii. Maximum current or KVA flow limits through transformers, circuit breakers,

line reclosers, load break switches, voltage regulators, and overhead and

underground feeder sections.

iii. Maximum limits on number of individual capacitor bank operations each

day.

iv. Minimum limits on time intervals between individual capacitor bank

operations.

b. Var Control Active: If power factors are not an objective function variable, minimum

power factor limits at each power delivery and supply point of interest.

c. Volt Control Active: If MW load demands are not an objective function variable,

maximum MW load demand for each substation and entire power system.


of 115

The user shall be able to execute VVC on demand. This shall include the capability to have VVC run

automatically on a periodic basis.

On each execution, VVC shall assess the current power system condition and determine the control

actions that should be taken. Normally, in advisory mode, these control actions shall be presented to the

user as a recommendation. The user shall be able to accept the recommended control actions and have

them automatically issued by SCADA. At user discretion, VVC shall be able to run in closed-loop mode as

well.

The user shall be able to suppress VVC on a substation-by-substation basis as well as prevent VVC from

considering any of the applicable control devices.

In the case of equal size parallel capacitor banks in substations, VVC shall give preference to operating

the bank with the lowest operation count to keep the number of operations of each bank reasonably

balanced.

11.9 Feeder Reconfiguration A Feeder Reconfiguration (FR) application shall be used to create switching plans that optimally (a)

unload overloaded feeder segments and (b) locate normally-open tie points between feeders. Like other

applications, FR shall support several problem formulations that define one or more operational

objectives, including minimizing the number of switching operations, improving reliability, reducing

overloads and voltage violations, and minimizing power losses.

FR shall be activated automatically based on SCADA observations or network analysis calculations or

manually by user request. On this basis, it shall provide recommended switching actions that reduce

overloads on substation transformers and feeder segments. In doing so, it shall consider peak load

conditions within a user-configured time window. As required, it shall also move normally open tie point

locations in a distribution network to improve reliability of the network. This shall be based on network

element characteristics such as their different frequencies of faults, different number of customers

connected to feeder sections, and different reliability values for different load categories. In this respect,

the application shall suggest alternative combinations of open points to satisfy the user selected

constraints and optimization criteria.

An FR “Return to Normal” mode shall also be provided. This shall generate a switching pan that restores

all switching to their normal states for a given substation or group of substations with the minimum

interruption of power supply to customers. The mode shall be used as the final restoration process after

the cause of an outage has been repaired. The results shall be presented as a set of valid switching

plans. The user shall select the most appropriate plan for automatic transfer to a formal switching order.

11.10 Outage Management

An Outage Management (OM) application shall form an integral component of the SituTB. It shall allow

users to manage unplanned and planned (scheduled) outages for the network that the SituTB is


of 115

currently monitoring and controlling. In this respect, it shall collect and coordinate all available

information about the outages.

11.10.1 Unplanned Outages

In the case of unplanned outages, customer trouble calls, AMI observations, SCADA operations, and

other emergency service calls shall be analyzed to assist in determining the most likely point at which

customer supply has been interrupted. From initial notification of a fault through prediction, crew

assignment, fault isolation and return-to-normal switching, the user shall be able to work from a single

set of network views.

All necessary information shall be clearly presented in a way that allows the user to manage each outage

efficiently while also staying aware of other network activity.

The OM application shall be designed to handle storm situations. It shall be able to divide or combine

areas of responsibility and therefore match the user’s workload. A comprehensive and flexible record

keeping function shall automatically provide all necessary information to support outage reporting

features.

In addition to customers calls, AMI observations, and SCADA data, the direct entry of trouble calls

representing emergency calls made by authorities such as police shall be supported. Trouble calls shall

be specified by location if there is no direct association with a customer connection.

Customer attributes shall be used to determine the priority to be applied for restoration or outage

status reports. Customer attributes supported shall include:

Life Support Customer

Handicapped Customer

Elderly Customer

High Priority – ‘Key Account’ Customer

Large Industrial Customer

The suspected nature of the outage shall be recorded as a trouble code that is normally supplied by the

customer or the AMI sensor. OM shall use a translation table so that an existing set of trouble codes can

be retained for display and data entry purposes.

The first observation of an outage (phone call, or AMI observation) shall result in a predicted outage. An

outage that is identified by SCADA information shall be registered as a confirmed outage. The time of

the first observation shall be recorded as the start time of the outage. The system shall detect duplicate

calls and roll them into a single outage incident, including any additional or updated information such as

a changed trouble code or customer comments.

The user shall be able to edit any of the information contained within an existing outage incident to

reflect actual conditions or manually generate an outage incident if required.


of 115

11.10.2 Management Tools

An Outage Information Summary as well as network view displays shall allow the user to analyze and

prioritize the outage incidents and assign them to work crews. The information provided to the user

about each incident shall include the number of customers off supply, the customer type, outage time,

and any special customer considerations such as life-support or key customer. The user shall also be

able to group multiple incidents into a single incident or separate one incident into multiple incidents.

It shall be possible for information in the form of case notes to be recorded by the user against a specific

incident. To streamline operations during major events such as storms, it shall be possible for area case

notes to be applied. In this way, all outage incidents will automatically inherit the area case note, which

can then be modified for individual incidents if required.

The user typically works with field crews to identify the actual cause of the fault, isolate it, restore as

many customers as possible, repair the fault, and return the network to normal. Typically, as this work is

proceeding, the user also updates the case notes that are used to keep customers informed on the

progress of restoration efforts via a utility’s IVR or CIS system. For the SituTB, however, these features

shall be supported by a facility that allows the user or others to enter all such data directly, thereby

simulating OM’s interface with field crews and customers.

As each customer or group of customers is restored, the relevant trouble call orders shall be removed

from the System. This shall be done manually so that the relevant information about the cause of the

outage can be captured. Once power has been restored, the user shall have the option (as simulated) to

call customers manually or request automatic call backs by the IVR to confirm that power is restored. If

the customer is confirmed to still be off supply, the trouble call shall be automatically re-entered in the

System with the original reported outage time. A trouble order priority indicator flag shall be set if a call

is received from a customer that was expected to have been restored. It shall be possible to ‘ping’ the

AMI meters related to an outage incident to confirm that power has been restored. The results of the

‘ping’ shall be displayed on the geographic network view allowing for easy identification of clusters of

customers that are not restored.

Once all customers have been restored, it shall be possible for the user to close out the outage incident.

The requirements for closing an incident (an editable checklist which is completed manually) shall be

configurable to suit specific business processes. For example, it shall be possible to set, on a system-

wide basis, rules regarding the information that must be entered for different types of outages. The

system shall retain all information about the outage incident as necessary for historical reporting and

analysis.

11.10.3 Crew Management

The assignment of crews to outages and the monitoring of their current location and status shall be

performed directly on the outage management displays. Crew symbols shall be positioned on the

geographic network view or the Outage Information Summary. Colors shall be used to indicate crew

status. Vehicle type, crew names, and assignment status shall be displayed. A search facility shall be

provided to allow for rapid identification of any crew by name, job, or truck ID.


of 115

It shall be possible to include additional information including:

Crew foreman, mobile phone number, or radio

Identification of non-company crew

Crew status such as Currently Assigned, Dispatched, Needed, At Job, Standing By, and On

Meal Break

Length of time the crew has been working

Next assigned job

Location of next assigned job

Remaining time to job completion

Actual time of job completion

Type of crew truck

Number in crew

Assignable crew labels (for example crew name with radio number, radio number only, and generic crew

names such as one to indicate status “patrolled, needs transformer”). Taking advantage of crew mobile

phones, it shall also be possible for the System to support the user’s secure exchange of text messages

with field crews.

11.10.4 Reliability Indices

The OM application shall support the calculation of reliability indices, such as SAIDI, SAIFI, and CAIDI,

based on the distribution network’s frequency and duration of sustained unplanned outages. The

capability to calculate MAIFI based on momentary outages shall also be possible. The calculations shall

follow the IEEE 1366-2003 standard.

The indices shall be calculated using a batch process that is run at regular intervals or on-demand. They

shall be included in reliability reports that can present them by date and geographical areas.

11.10.5 Historical Reporting

A Historical Reporting (HR) application shall ensure a complete record of all outages can be retrieved for

review and reporting purposes. Within this context, the user shall be able to search outage records to

allow the following historical information to be reviewed and reported:

Cause of Outages

Reliability Indices

Division and/or Operating Center Outages

Trouble Summaries by Division and/or Operating Center

Overhead and Underground Outage Summaries

Recurring Trouble Summaries

Worst Performing Devices

Worst Performing Feeders

Crew Assignments

Closed Outage Cases


of 115

12 System Simulator For any given power system network, the System Simulator shall provide the capability to use the ADMS

applications in their real-time and study modes in such a way, however, that the data as may be used by

these applications are not derived from actual field device measurements (as received from RTUs for

example) but from dynamic models capable of simulating the behavior of the power system network in

response to time-dependent load and event scenarios representing those that may or not be typical of

the loads and events experienced by the actual network. On this basis, the System Simulator shall be

used for ADMS training and demonstration purposes.

In case of training, ADMS workstations may be used in such a way that one is assigned to a trainee and

another to a trainer, in which case the trainee shall only have access to the simulated ADMS production

environment, i.e., shall be able to use the ADMS and its facilities only in the same way as a control room

dispatcher. This shall include access in accordance with the applicable area of responsibility.

When using the simulator, the user interface shall include a distinguishing feature confirming that the

ADMS is in simulation mode, e.g., use of a “Simulation” water mark on all user interface displays.

Otherwise, the appearance and functionality associated with all real-time and study related displays,

drop down menus, and toolbars shall be the same as in using the ADMS in its on-line mode.

12.1 Simulator Utilization Modes

The System Simulator shall be capable of being utilized in the following two ways:

1. Supervised – The trainer shall set up, monitor, and control the simulator session so that the

trainee focuses only on using the ADMS real-time and/or study functions.

2. Non-supervised – The user shall set up, monitor, and control the simulator session as well

as use the ADMS functions.

12.2 Dynamic Power System Model

The simulator shall be supported by a dynamic power system model that shall be an extended form of

the Network Operations Model (NOM).

The NOM component of the dynamic power system model shall represent the on-line database model

and, in this respect, shall be capable of being populated not only by the on-line database values and

attributes, but also those that are specific to the simulator session in hand.

As a minimum, the extended NOM shall include settings, parameters, and all other modelling details as

necessary to support:

1. Simulations consistent with modelling the behavior of the power system from a static and

dynamic perspective.

2. Creation of scenarios from pre-stored load curves and event groups, where event groups

consist of one or more events that occur at the same time, at different times, or in

accordance with other events and power system conditions.


of 115

3. Definition of events such as change of bus load, change of system load, loss of generation,

circuit breaker trip/close operations (including, for example, those corresponding to

sustained line faults that result in breaker lockout and those corresponding to momentary

faults that are cleared by breaker reclose action), fault indications at one or more remote

controlled switches, loss of data, equipment alarms, etc.

4. Initialization of the dynamic power system model from ADMS on-line save cases and

snapshots of the real-time state of the actual power system.

5. Initialization of the dynamic power system model from simulator save cases and snapshots

of the current state of the simulated power system.

6. Simulation starts, pauses, restarts, and stops.

7. Creation, application, and omission of events during an on-going simulation.

8. Periodic and demand snapshot save cases. At user discretion, periodic snapshots shall be

saved automatically at a specified time interval throughout the simulation, where a

snapshot is all data required to initialize the simulation to the conditions prevailing at the

time of the snapshot. Periodic and demand snapshots shall not cause the simulation to

pause.

9. Recording of scenario events so that these events together with a corresponding snapshot

may be used to replay and review the simulation session.

The simulator’s modelling requirements shall extend to all equipment and devices comprising the power

system as modelled in the on-line ADMS. It shall also extend to equipment and devices that are not

included in this model but, as part of the power system infrastructure, affect the dynamic behavior of

the power system.

The power system model as used by the simulator shall also be capable of being modified in any way to

represent the addition and/or removal of equipment and devices, as for example to study the impact of

new substation construction.

Within this context, as a minimum, the simulator shall include models or scripts that can represent:

1. Time-dependent changes in bus loads as derived, for example, from the profiles of

conforming and non-conforming loads for each effective season and day type. Users shall be

able to modify such profiles, e.g., by defining a new peak value that scales the entire load

profile, or by changing one or more individual load values. This shall include the capability to

define and save load profiles manually.

2. Distributed generation such as PV-solar and wind-turbine renewable energy plant.

3. Power system frequency and/or voltage dynamics such as those that control the behavior

of:


of 115

a. Loads defined as functions of frequency and/or voltage.

b. Overvoltage and undervoltage relays.

c. Overfrequency and underfrequency relays.

d. LTC transformers and generator AVRs.

4. SCADA functionality as, for example, opening and closing circuit breakers and disconnecting

switches, sending set points and tap positions to control the power system’s LTC

transformers, and sending commands to reset underfrequency and lockout relays.

5. Overcurrent and automatic recloser relays in addition to the above referenced voltage and

frequency relays.

6. Load Shedding in response to underfrequency relay operations.

7. Transformer and feeder faults.

8. Customer trouble calls at different call rates.

9. Field device measurements.

12.3 Scenario Builder Scenario definition and building shall be supported by comprehensive and convenient user interface

facilities. In this respect, a Scenario Builder shall be provided, which can be used to define scenarios up

to twenty-four (24) hours long. A provision shall be made to define multiple training scenarios.

Each scenario shall be described by defining events. This shall include the capability to define conditional

and probabilistic events. Within this context, as a minimum, it shall be possible to create scenarios

based on the following specifically defined events:

1) Circuit Breaker Manual and Automatic Operation.

2) Trip or Trip/Close on a Breaker.

3) Failure of a Breaker to Operate.

4) Relay Malfunction.

5) Local Control Malfunction (Load Tap Changers, Load Shedding, Generation Control).

6) Limit Violations (all types).

7) Temporary and Permanent Loss of Equipment (including data sources such as RTUs).

8) Loss of Generation.

9) Change in MW and Mvar Generator Outputs.

10) Single Bus Load Change.


of 115

11) Area Load Changes.

12) Fault Occurrence (e.g., a scenario defined event such as a feeder section fault resulting in a

circuit breaker trip).

13) Loss of a Line or Transformer.

14) Islanded Operation.

15) Receipt of Operational Alarm.

16) Receiving trouble calls and dispatching field crews.

In addition to the above, the scenario builder shall support the merging of information available from

the on-line ADMS to generate a scenario. For example, a scenario may be developed starting from a

simulator scenario and subsequently merging historical data and/or a power flow save case from the on-

line ADMS. With each merge action, some data may be overwritten.

12.4 Simulation Management

As a means of simulation management, a user interface shall be provided to facilitate simulator session

setup and control. The simulation management capabilities shall include:

1. Session start, stop, pause, and resume at any time within a scenario.

2. Session replay from an earlier state including all user/trainee actions.

3. Variable real-time speed selection (fast, normal, slow).

4. Base case initialization from any of the following sources:

a. Real-time snapshots from the on-line ADMS.

b. Measurement data and save cases as existing on the on-line ADMS.

c. Snapshots and save cases as created by the simulator.

d. Historic event data from the on-line ADMS.

5. Scaling of power system load for different operating conditions.

6. Saving multiple simulator save cases.

7. Storing of scenario and associated initialization data in the simulator database.

All operations during a simulation session, including those of the trainee and trainer, shall be logged

automatically and shall be available for subsequent review.

In addition, the user shall be able to:

1. Create a library of training scenarios.

2. Initialize the simulator with a snapshot saved during a training session.


of 115

3. After loading a snapshot, call up displays and examine any data normally available during a

session as, for example, to review or discuss specific details with others.

4. Resume the simulation session from a snapshot in the same manner as resuming from a

pause.

Reports for each session shall be made available. As a minimum, these reports shall include the session

log and any comments that may have been incorporated during or after the session. All completed

reports shall be capable of being saved, printed, and exported in a suitable format to other computer

systems.

12.5 Database and Display Editor

Comprehensive database and display editing tools shall be provided as described in the following

subsections.

12.6 Database Creation and Editing

Tools shall be provided to support ADMS database creation and editing. They shall allow database

structures to be defined, populated with their initial contents, and subsequently updated incrementally.

In this respect, it shall be possible to perform database creation and editing from any ADMS

workstation. The tools shall support a validation mechanism for data entries. Global validation of the

database shall be possible.

At the time of database construction, database directories sufficient to fully describe the database shall

be built. These database directories shall be independent from the data itself. Subsequently, the

database shall have the capability to be maintained by adding, deleting, or modifying database records.

This shall not require any recompilation of the source code.

In addition to using manual database tools, it shall be possible to import and export data definitions in

the CIM format to enable more accurate and faster database creation and updates.

Operations on the different portions of the database, such as those associated with the Network

Operations Model (NOM), shall be independent. Easy access to database content shall be provided to

perform modification of any record or its attributes (such as add, change and delete).

12.7 Display Creation and Editing

Tools shall be provided to allow displays to be easily created and modified. They shall be fully

compatible with the database creation and editing function. To facilitate the creation and editing

process, they shall support the creation of libraries of standard and custom display symbols or

components.

The tools shall support the listing, deleting, reloading, and validating of display definitions. Important

creation and modification options shall include:

Copy, move, delete, modify


of 115

Building at different zoom levels

Linking of any defined graphics symbol to any database point

Pop-up menus

Protection of any data field on any display against user entry based on log-on permissions

Activation of new or modified displays for any application or across all applications of the

System by a simple command that causes no noticeable interruption of on-line System

activity.

Displays shall be composed of display elements, primitives, symbols and macros. Within a display, each

display element shall be assigned a position, in rectangular co-ordinates, within the display space. The

individual dynamic data fields and data arrays in defined displays shall be logically identifiable.

It shall be possible to reference multiple data sets by the same display. Database items shall be

presented in the formats like numerical text, symbol, colors, textures, blinking conditions, graphical

presentation, and a combination of the above formats.

The condition of the data shall be displayed by quality code and tagging. Color, appended symbols, and

other display features may be used for this purpose. There shall be different display layers and each

layer shall be a self-contained world co-ordinate space onto which display elements, including data, shall

be placed.

The selective presentation of layers (de-cluttering) shall be controlled by the scale (zoom or

magnification) level and by user selection. Each layer shall be visible over a range of scale levels defined

as the display is built. The System shall have ‘pop-up’ and ‘pull-down’ menus for user interaction. A

facility shall be provided to create display macros to aid in the display construction process.

Each display shall have headings at a fixed location, placed either vertically, horizontally or both.

Database references shall survive any type of data change, including record insertion, record deletion,

and schema redefinition.

In addition to the tools above, tools allowing for automatic creation of schematic and graphical displays

shall be provided. For example, graphical displays may be created from AutoCAD and CIM files, or other

files as may be available from a Geographical Information System (GIS). Once created in the ADMS, it

shall be possible to use graphical displays to automatically create schematic displays.

13 System Interfaces The following System interfaces shall be provided:

1. RTU Interfaces. These interfaces shall be enabled using the IEC 60870-5-104 and DNP 3.0

data communication protocols. These protocols shall allow for serial as well as IP based

communications. In addition, it shall be possible to implement the latest secure

authentication versions of these protocols. The RTU interface may also be used to

demonstrate cyber security measures such as VPN tunneling and encryption. The RTUs shall


of 115

include those provided with the SituTB for installation in CPRI on and off campus

substations. They may also include RTUs provided as components of the SASTB and DATB or

provided by others for testing.

2. IED Interfaces. These interfaces shall be enabled using the IEC 61850-90-2 data

communication protocol where the IEDs can be components of the SASTB. The capability to

demonstrate the protocol running over IP shall be possible. In addition, it shall be possible

to communicate with the IEDs using a gateway that can convert IEC 61850-90-2 to IEC

60870-5-104 and DNP 3.0.

3. AMI Head-End Interfaces: These interfaces shall be enabled via client software installed in

the ADMS so that the web services provided by software installed as part of each AMI head-

end system can be accessed to collect voltage readings and last-gasp messages from smart

meters as well as ‘ping’ meters to determine the status of customer power supplies.

4. Substation Camera Surveillance Interfaces: These interfaces shall be enabled such that IP

(including PTZ) cameras as may be installed in CPRI on and off campus substations can

provide alarms and video images to the ADMS. For example, one or more IP cameras may

be installed along with a local Video Management Server (VMS) in which there is software

capable of monitoring and controlling the cameras based on observed substation events and

sending corresponding alarms and video images to the ADMS. In this respect, using a data

communications protocol (such as DNP 3.0) and VMS client software, the ADMS

workstations and video wall controller can then be used to display the alarms and video

images to the ADMS user. The video server may also be used to send live video streams to

the ADMS and, if required, VMS archived videos.

5. External User Interfaces: These interfaces shall be enabled by installing and configuring a

web server with the SituTB in such a way that that external users with appropriate

permissions can access ADMS information (only that which is made available to them via the

web server) using any standard browser installed on a PC connected to the ADMS LAN. For

security purposes, the web server may be installed in the ADMS Demilitarized Zone (DMZ).

14 System Sizing The System shall be capable of accommodating power system models based on the information

provided in the following Table 14-1, which also includes System sizing components dependent on the

number of workstations and customers.

Table 14-1: System Sizing Components

Sizing Component

Number of

Components

HV Substations 15

HV Substation Buses 180


of 115

HV/MV Substations 20

MV Substation Buses 50

Generating Plant (at HV points of connection) 10

Substation Remote Terminal Units 35

Substation Status Points 1,000

Substation Analog Points 500

Substation Accumulator Points 100

MV Feeders 200

MV Feeder RTUs 500

MV Feeder Status Points 6,000

MV Feeder Analog Points 6,000

Distribution Transformers 2,000

Number of Customers 10,000

Distributed Generation (at MV points of

connection) 50

Distributed Generation (at LV points of

connection) 1,000

ADMS Workstations 3

15 System Performance Based on the sizing components in Table 14-1 above, and considering all other ADMS operational

requirements as specified, the ADMS shall meet the following performance requirements, which must

be verified during ADMS Factory Acceptance Testing (FAT).


of 115

15.1.1 Normal Activity

The normal activity level shall be run over a period of 60 minutes. It is defined as follows:

1. Changes in 1% of all status indications per minute with subsequent processing and sorting

into System lists.

2. A total of 2% of all analog measurements exceeding their alarm limits per minute with

subsequent processing and sorting into System lists.

3. All measurements being transmitted to the System at a scan rate of 5 seconds with

subsequent processing and presentation on displays of the System

4. A total of 2% of all alarm points being initiated per minute, in addition to alarms caused by

the above stated status changes and measurement limit violations, with subsequent

processing and sorting into System lists.

5. A new display being requested every minute at each ADMS workstation.

6. Trending of two analog variables during the normal activity performance test.

7. One alarm page accepted every 3 minutes.

8. All standard software running as normal.

9. Execution of topology processing and any cyclically executing applications every 5 minutes.

10. On demand execution of UBL, FLISR, FR, and VVC every 10 minutes.

11. Execution of Outage Management based on 5 customer trouble calls every 10 minutes.

15.1.2 High Activity

The high activity level shall be run over a period of 30 minutes. It is defined as follows:

1. Changes in 5% of all status indications per minute with subsequent processing and sorting

into System lists.

2. A total of 8% of all analog measurements exceeding their alarm limits per minute with

subsequent processing and sorting into System lists.

3. All measurements being transmitted to the System at a scan rate of 5 seconds with

subsequent processing and presentation on displays of the System

4. A total of 8% of all alarm points being initiated per minute, in addition to alarms caused by

the above mentioned non-commanded status changes and measurement limit violations,

with subsequent processing and sorting into System lists.

5. A new display being requested every 30 seconds at each ADMS workstation (each display

containing an average of 30 analog values and 50 indications).

6. Trending of four analog variables during the high activity performance test.

7. One alarm page accepted every 30 seconds.

8. All standard software running as normal.

9. Execution of topology processing and any cyclically executing applications every 5 minutes.

10. On demand execution of UBL, FLISR, FR, and VVC 4 times during the high activity

performance test.

11. Execution of Outage Management based on 10 customer trouble calls every 5 minutes.


of 115

15.1.3 System Start-Up

The total time for start-up of a server or workstation, including automatic program load, initialization

and database updating, shall not exceed five minutes.

System automatic restart following a power down shall not exceed five minutes.

Complete SCADA functionality shall be available within a further five minutes following an on-demand

start-up or an automatic restart. Updating from RTUs may extend beyond this time but the full update

of the System with data from the field shall not exceed a further five minutes. Thus, a complete restart

of the System, including full update from the field, shall not exceed 15 minutes.

15.1.4 System Response Times

The performance of the System shall meet or better the maximum response times specified in the

following Table 15-1.

If a display is suspended during panning and zooming, the time for the display to be refreshed shall be

no more than 1 second after the panning/zooming operation has completed.

Table 15-1: Maximum System Response Times

Description

Normal

Activity

(seconds)

High

Activity

(seconds)

Confirmation of point selection on a monitor 1 1

The time between selection of a display and the VDU

diagram fully updated shall not exceed 1 2

Acceptance of a single alarm 1 2

Acceptance of a page of alarms 1 2

The time between selection of a control function and

check back from the RTU as to whether or not the control

can be performed shall not exceed (*) 2 4

The time between execution of a control function and

initiation of the control at the RTU shall not exceed 1 1

The time between the occurrence of a change of state or

an alarm at a RTU and display at the System shall not

exceed (*) 3 4

The time between a change of state at a RTU due to a

control action and display at the System shall not exceed 3 4


of 115

(*)

The time between successive updates of the main

computer database with analog measurements shall not

exceed

a) MW, MVAr, and Voltage measurements

b) Other measurements

5

10

10

20

The time between successive updates of the main

computer database with pulse meter values shall not

exceed 30 30

The time of loading of a save case and initialization of a

study mode EMS application shall not exceed 10 30

Results from a derived calculation shall be available in less

than 2 2

Time from request of hard copy output to the

commencement of printing (printer already in hot state)

shall not exceed 5 15

(*) Communication time between the Front End and the RTU not included.

16 Implementation and Contracting Responsibilities This section specifies the project implementation responsibilities of the Contractor. It also identifies

CPRI’s responsibilities.

16.1 Responsibilities of Contractor

Except for the activities specifically assigned to CPRI, the Contractor shall assume full responsibility for

the design, assembly, development, integration, delivery, installation, and commissioning of the System

within the context of its meeting fully and completely all of CPRI’s operational performance

requirements.

No attempts have been made to include all Contractor items of work to be done in the list below. Only

the work that is significant and for which the scope and boundary can be clearly illustrated is covered.

Other Contractor responsibilities are expressly identified or implied in other parts of these

specifications.

Thus, within this context, Contractor specific responsibilities shall include:


of 115

5. System engineering, including the qualification of all hardware and software components

for the functions to which they are assigned, and modification of the components as

necessary to achieve system performance as a single, fully integrated system.

6. Integration of the Contract deliverables with equipment and software that may be supplied

by CPRI including existing and new RTUs and other test beds.

7. It shall be the Contractor’s responsibility to verify the functional capabilities and

performance of CPRI-furnished equipment and subsystems including any interfacing with

CPRI’s communication systems, which will be provided to the Contractor by CPRI in good

faith and with its best effort. The Contractor shall promptly notify CPRI of the discovery of

limitations in or problems with equipment and software furnished by CPRI that may prevent

any Contract requirements from being met. The Contractor shall cooperate with CPRI

expeditiously in solving such problems and it shall be the Contractor’s responsibility to

modify or replace all necessary System interface parts without any charge to CPRI.

8. Hardware and software development engineering, as may be required to develop and

configure all System functions, and interfaces to other test beds and external systems that

are required under the Contract.

9. Supply of all System equipment, including processors, servers, workstations, LANs, data

storage devices, communications gateways, and related support material, except for

equipment, if any, that is explicitly designated by the Contract to be furnished by CPRI.

10. Supply of hardware interfaces to the external systems and applications as required by the

Contract.

11. Integration of the System with the external equipment and systems as required by the

Contract.

12. Supply of System software, including power system applications software, to satisfy all

Contract requirements.

13. Supply of spare parts as required for CPRI operation of the System and its maintenance until

the end of the warranty period.

14. Furnishing and installing of all interconnecting cables and wiring, including power wiring,

among all Contractor-furnished equipment. The Contractor shall document the

manufacturer type and catalog number for the power plugs being furnished and for

communication interface connectors and any other connectors to external equipment.

15. Preparation, with CPRI participation, of the complete applications database including the

Network Operational Model.

16. Integration of any databases and displays prepared by CPRI into the System.


of 115

17. Support for CPRI generation of all required reports excluding standard reports that are

provided in the Contractor’s standard software.

18. Training CPRI staff so that they will be self-sufficient and able to operate, maintain, and

upgrade the System.

19. Training CPRI staff on database and display preparation and maintenance and provision of

direction and assistance to CPRI in building power system databases and displays.

20. Training CPRI staff on system maintenance, expansion, and upgrading through formal

courses and on-the-job training.

21. At CPRI’s option, inclusion of CPRI staff in the System development team. This includes

Contractor responsibility for directing and supervising the work of the CPRI staff.

22. Provision and maintenance of the Program Development System (PDS) environment for use

by CPRI.

23. Ensuring and periodically demonstrating that the work is progressing according to the

approved schedule.

24. Successful completion of the ADMS Factory Acceptance Test (FAT) per AT procedures

approved by CPRI.

25. Ensuring that the requisite security measures have been incorporated in the ADMS and all

software, upon delivery, is free of viruses, worms, trapdoors, and other software

contaminants, contains no software enabled with “electronic self-help”, is purged of all

sample scripts and sample code, and has had all default accounts and passwords removed

or disabled.

26. Shipment of project deliverables including transportation and delivery of all Contractor-

provided equipment and materials to CPRI’s site.

27. Installation of System equipment and participation in all testing at CPRI’s site including the

correcting of all outstanding variances.

28. All interconnection wiring between external communications terminals and communications

interface panels supplied by the Contractor.

29. Supplying and installing the System and the associated cabling and wiring to all supplied

equipment, including connection to input power at the CPRI delivery points within the

SituTB building, and delivery of all necessary installation documents in advance of and in

accordance with the anticipated start-up of the System.

30. Providing input power via cabling, distribution boards, and cable trays (and associated labor)

to System equipment enclosures per the CPRI approved designs.


of 115

31. Supplying final (“as built”) documentation that is accurate and complete.

32. Performing, with CPRI oversight, system start-up after satisfactory System installation,

including powering up the system, loading correct versions of all software and databases,

activating data links, verifying correct operation of the system, including checking the

database and displays are correctly showing data and the setting up of all functions for

proper operation (system and function “tuning”).

33. Full system backup of all installed software for all servers and workstations.

34. Assistance (i.e., provision of labor and materials) and testing, such as the formal Site

Acceptance Test (SAT), and correction of defects discovered during all such testing.

35. Maintenance of an up-to-date version of the Contract documents to reflect all agreed-upon

change orders (if any).

36. Providing secure remote computer access from the Contractor's factory to support the field-

installed System. This shall include double factor authentication and use of CPRI’s

authorized procedures. It shall also include provision of the communications channels

necessary for remote support in case this support cannot be done through the Internet.

37. Correction of all defects covered by the Warranty.

38. Provision and maintenance of secure remote computer/network access from the

Contractor’s factory to support and maintain the installed System until the end of the

warranty period.

16.2 Responsibilities of CPRI

CPRI will be responsible for the following:

1. Preparation of test bed facilities as needed to support the System equipment.

2. System power supply receptacles per the Contractor’s specifications.

3. Communications channels (excluding interfaces) to the System at the test bed location.

4. Coordination of the physical installation of the System equipment by the Contractor.

5. Review and approval of custom documentation.

6. Preparation of CPRI displays including station one-lines. Review of the Contractor’s auto-

tabular and auto-display generation capabilities.

7. Furnishing of information required by the Contractor for preparation of Contractor-built

databases, displays, and reports.

8. Preparation of customized power system database under Contractor’s direction and for

integration by the Contractor.


of 115

9. Preparation of customized power system displays under Contractor’s direction and for

integration by the Contractor.

10. Consultation on Contractor-built displays and reports and review and approval of same.

11. Furnishing, upon request by the Contractor, necessary documentation, interface

information, engineering drawings, and schematic diagrams for CPRI equipment that will be

directly interfaced with Contractor equipment.

12. Coordination of project work at the CPRI facilities, such as connection to external

equipment, testing of System interoperation with external systems, and integration of

equipment and software into the System.

13. Attending and participating in the System acceptance tests. Reviewing and approving the

test results.

14. Providing test data for processes external to the System.

15. Reviewing variance reports, approving variance priorities assigned by the Contractor,

resolving variance issues, and approving corrected variances.

16. Determining if the Contractor’s work is progressing in accordance with the schedule.


of 115

17 Feature Quantities:

# Feature Qty Section Notes

1 SCADA/Applications Server 1 4, 6, 10.1

2 Front-End Processor/CNP 1 4, 10.2

3 Authentication Server 1 4, 10.3

4 Web Server 1 4.2.5.3

5 Data Historian Server 1 4, 8, 10.4

6 Backup/Archive Storage 1 4, 8, 10.4

7 Workstation Monitor 6 10.5.1 As needed for workstation equipment

8 Tower Processor 3 10.5.2

9 Firewalls 2 10.6

10 Video Display Wall 1 10.7

11 Gateway (including PSU) 1 10.9

12 Video Manager Server 1 10.10.1

13 IP Camera 2 10.10.2 Observation of remote locations

14 Time and Frequency Facility 1 10.11 May use the SASTB IEEE1588 time

15 GPS Receiver 1 10.11

16 Router/Cellular Modem 1 10.12

17 Multifunction Printer 1 10.13

18 Historian Software 1 8

19 SCADA/FEP Software 1 6, 7

20 ADMS Applications Software 1 7, 11, 12

Total count 29

Table 17-1 SituTB Feature List


of 115

18 Mapping Functions to Features SituTB enables CPRI to perform a list of Functions as specified in section 11. Each Function depends on a subset of test bed Features. The Design of the SituTB

has generated a list of 20 Features to support 9 different Functions as itemized in Table 18-1.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

Sec SituTB Functions

SCA

DA

/Ap

plic

atio

ns

Serv

er

Fro

nt-

End

Pro

cess

or/

CN

P

Au

then

tica

tio

n S

erve

r

Web

Ser

ver

Dat

a H

isto

rian

Ser

ver

Bac

kup

/Arc

hiv

e St

ora

ge

Wo

rkst

atio

n M

on

ito

r

Tow

er P

roce

sso

r

Fire

wal

ls

Vid

eo D

isp

lay

Wal

l

Gat

eway

(in

clu

din

g P

SU)

Vid

eo M

anag

er S

erve

r

IP C

amer

a

Tim

e an

d F

req

uen

cy F

acili

ty

GP

S R

ece

iver

Ro

ute

r/C

ellu

lar

Mo

de

m

Mu

ltif

un

ctio

n P

rin

ter

His

tori

an S

oft

war

e

SCA

DA

/FEP

So

ftw

are

AD

MS

Ap

plic

atio

ns

Soft

war

e

11.3 Network Topology Processor

11.5 Unbalanced Power Flow

11.6

11.7 Fault Location/FLISR

11.8 Volt-Var Control

11.9 Feeder Reconfiguration

11.10 Outage Management

6 SCADA Applications

11.2 Network Operation Model

7.5 Trending and analysis

Table 18-1 SituTB Function vs. Feature Matrix


of 115

19 ADMS Supplier Qualification Criteria The ADMS supplier shall meet the following Qualification Criteria.

Experience

The ADMS supplier shall:

1. Have a minimum of 5 years of experience in the development of SCADA and DMS systems

for the electric utility industry.

2. Demonstrate a total turnover during the last 3 years for EMS, DMS, and OMS systems

delivered to electrical utilities greater than Rs. 200 Lakhs per year.

3. Have a fully integrated ADMS platform with a single user interface capable of accessing all

applications in their real-time, study, and simulation modes.

4. Have provided ADMS systems that have been in commercial operation at more than 3

electric utilities for more than 6 months.

5. Have developed in-house (and/or be the sole licensor of) the three core modules of the

ADMS, i.e., the SCADA, DMS, and OMS modules.

References

The Supplier shall provide:

1. At least three electric utility references that can be used to confirm delivery, installation,

and successful operation of a supplier ADMS over the last 24 months. Information provided

shall include utility contact information and brief project descriptions.

2. At least two additional references where an ADMS has been delivered and installed by the

supplier outside of the country where the factory for ADMS development, assembly, and

testing is located. One of them shall have been delivered and installed in India. These

references shall also include utility contact information and brief project descriptions.

3. Evidence that the ADMS proposed for the SituTB can be provided within a 12-month

schedule.

situational awareness test bed (situtb) visualization of 220/33 kv (off-campus) substation and...

Documents