situational awareness test bed (situtb) visualization of 220/33 kv (off-campus) substation and...
TRANSCRIPT
SituTB Specification
Page 1 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.”
SituTB Specification
Page 2 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
SituTB Specification
Page 3 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
SituTB Specification
Page 4 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
SituTB Specification
Page 5 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
SituTB Specification
Page 6 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
SituTB Specification
Page 7 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
SituTB Specification
Page 8 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
SituTB Specification
Page 9 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
SituTB Specification
Page 10 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
SituTB Specification
Page 11 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
SituTB Specification
Page 12 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
SituTB Specification
Page 13 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.
SituTB Specification
Page 14 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.
SituTB Specification
Page 15 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
SituTB Specification
Page 16 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.
SituTB Specification
Page 17 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.
SituTB Specification
Page 18 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.
SituTB Specification
Page 19 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
SituTB Specification
Page 20 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.
SituTB Specification
Page 21 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.
SituTB Specification
Page 22 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.
SituTB Specification
Page 23 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.
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 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.
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 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.
SituTB Specification
Page 24 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.
SituTB Specification
Page 25 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
SituTB Specification
Page 26 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,
SituTB Specification
Page 27 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)
SituTB Specification
Page 28 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.
SituTB Specification
Page 29 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.
SituTB Specification
Page 30 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.
SituTB Specification
Page 31 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.
SituTB Specification
Page 32 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
SituTB Specification
Page 33 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.
SituTB Specification
Page 34 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
SituTB Specification
Page 35 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
SituTB Specification
Page 36 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
SituTB Specification
Page 37 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.
SituTB Specification
Page 38 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.
SituTB Specification
Page 39 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.
SituTB Specification
Page 40 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.
SituTB Specification
Page 41 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:
SituTB Specification
Page 42 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,
SituTB Specification
Page 43 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
SituTB Specification
Page 44 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.
SituTB Specification
Page 45 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.
SituTB Specification
Page 46 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:
SituTB Specification
Page 47 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
SituTB Specification
Page 48 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
SituTB Specification
Page 49 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
SituTB Specification
Page 50 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)
SituTB Specification
Page 51 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
SituTB Specification
Page 52 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.
SituTB Specification
Page 53 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.
SituTB Specification
Page 54 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.
SituTB Specification
Page 55 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.
SituTB Specification
Page 56 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.
SituTB Specification
Page 57 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
SituTB Specification
Page 58 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
SituTB Specification
Page 59 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)
SituTB Specification
Page 60 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.
SituTB Specification
Page 61 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-
SituTB Specification
Page 62 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.
SituTB Specification
Page 63 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.
SituTB Specification
Page 64 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.
SituTB Specification
Page 65 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.
SituTB Specification
Page 66 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.
SituTB Specification
Page 67 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.
SituTB Specification
Page 68 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.
SituTB Specification
Page 69 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.
SituTB Specification
Page 70 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.
SituTB Specification
Page 71 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.
SituTB Specification
Page 72 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.
SituTB Specification
Page 73 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
SituTB Specification
Page 74 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.
SituTB Specification
Page 75 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.
SituTB Specification
Page 76 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.
SituTB Specification
Page 77 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.
SituTB Specification
Page 78 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.
SituTB Specification
Page 79 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.
SituTB Specification
Page 80 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.
SituTB Specification
Page 81 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.
SituTB Specification
Page 82 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
SituTB Specification
Page 83 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
SituTB Specification
Page 84 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
SituTB Specification
Page 85 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
SituTB Specification
Page 86 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
SituTB Specification
Page 87 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.
SituTB Specification
Page 88 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.
SituTB Specification
Page 89 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
SituTB Specification
Page 90 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).
SituTB Specification
Page 91 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
SituTB Specification
Page 92 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.
SituTB Specification
Page 93 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.
SituTB Specification
Page 94 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
SituTB Specification
Page 95 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.
SituTB Specification
Page 96 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.
SituTB Specification
Page 97 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
SituTB Specification
Page 98 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.
SituTB Specification
Page 99 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:
SituTB Specification
Page 100 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.
SituTB Specification
Page 101 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.
SituTB Specification
Page 102 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
SituTB Specification
Page 103 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
SituTB Specification
Page 104 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
SituTB Specification
Page 105 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).
SituTB Specification
Page 106 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.
SituTB Specification
Page 107 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
SituTB Specification
Page 108 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:
SituTB Specification
Page 109 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.
SituTB Specification
Page 110 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.
SituTB Specification
Page 111 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.
SituTB Specification
Page 112 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.
SituTB Specification
Page 113 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
SituTB Specification
Page 114 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
SituTB Specification
Page 115 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.