are va training

The e-terrahabitat Overview

Topics

e-terrahabitat and its features

e-terrahabitat Architecture

Operating Systems and Compiler

Portability Model

Types of e-terrahabitat Systems

Subsystems or components of e-terrahabitat

e-terrahabitat Applications

Starting up e-terrahabitat

2 2

What is e-terrahabitat?

e-terrahabitat is a software product that provides an environment and a suite of tools for the:

development

operations

of highly available real-time control systems andengineering applications.

NOTE: For additional information on e-terrahabitat, refer to the e-terrahabitat Users Guide (hab_ug.pdf).

3 3

Features of e-terrahabitat (1 of 2)

e-terrahabitat memory-resident database subsystem allows it to support large databases where tens-of-thousands of real-time measurements are scanned every two to ten seconds.

Real-time means having to manage:

Large amount of interrelated and interacting pieces of data

Tasks that operate asynchronously

Processing of time-critical events

Demanding availability and fault tolerances

4 4

Features of e-terrahabitat (2 of 2)

The user interface subsystem refreshes the data on the operators screens at the same rates and supports large database-driven geographic one-line displays as well as tabular displays.

A complete suite of support applications and software tools to monitor and manage hardware and software as required by your real-time control systems operating at all times, 365 days a year.

5 5

The e-terrahabitat architecture (1 of 2)

An e-terrahabitat based real-time control system has a three-layered architecture. The benefits of layering are:

Isolate e-terrahabitat-based applications from the underlying

operating system (OS).

Provide portability for e-terrahabitat applications across multiple

OS platforms.

Engineering App i.e., Telephone switching

Distribution Automation Systems

Energy Management Systems i.e., e-terraplatform

Computer Operating System*

Windows 2003 Server + SP1, Red Hat Linux 4.0 (WS, AS) 64 bit

e-terrahabitat

environment and development layer

Real-time control systems i.e., e-terrascada

OS Layer

e-terrahabitatLayer

Real-time Application Layer

6 6

Energy Management System Applications

The e-terrahabitat architecture (2 of 2)

An example of e-terraplatform (EMP) built in layers as shown in figure below.

SCADASubsystem

GenerationSubsystem

NetworkSubsystem

Analogs & Statuses

Estimated Values

External unit MW schedules, pump

unit limits,incremental cost

curves

Frequency, time,plant & tie-line

measurements, unit controls,

ACE, system load

Unit security limits, loss sensitivities, AGC participation factors

Unit Controls

FEP ore-terracontrol

AnalogsStatusesControls

RTUs

Operating Systems

Windows 2003 Server, Red Hat Linux 4.0 (WS, AS)

Real-Time Control System Environment

e-terrahabitat

NETIO Web-FG Permit Hdb

Configuration Manager MRS Alarm

DTS

7 7

Operating Systems and Compiler Support

GNU Compiler Collection 3.4 (GCC C++) Intel Fortran compiler 9.0

Visual Studio .NET 2003 Intel Fortran Compiler 9.0 (Standard Edition)

Compiler Support

Java 2 Platform Standard Edition 5.0, Perl 5.8, Acrobat Reader 7.0+

Windows Server 2003 (32 & 64 bit) Windows XP Pro+ SP1 (UI only)

Windows

Java 2 Platform Standard Edition 5.0, Perl 5.8, Acrobat Reader 7.0+

Red Hat Linux 4.0 Enterprise Edition (AS & WS) 64 bit

Linux

Other Software

OS System

VER 5.6

e-terrahabitat -based applications can be developed from the following operating systems and compilers.

NOTE: For more details on the hardware and software requirements, refer to the e-terrahabitat 5.6 Release Notes.

8 8

Portability

Layering allows the real-time control system applications to be portable.

Portability means it is available for real-time use and development on across supported operating systems.

Portability protects against the operating system becoming obsolete.

The databases, displays, and applications are portable within e-terrahabitat, so the operating system can be changed without procuring a new control system.

9 9

Types of e-terrahabitat Systems

e-terrahabitat can be used in multiple types of environments, which affects the techniques used to maintain the installation:

Real-Time e-terrahabitat systems remain in an up condition at all

times, either in primary mode supporting real-time functions such

as SCADA, or in standby mode waiting to assume the real-time

functions in case the primary machine fails.

e-terrahabitat simulation-type systems support simulation of a real-time e-terrahabitat environment for simulation software such

as the e-terrasimulator (DTS). The e-terrahabitat functions are

similar to those of a real-time system, but without the need for

constant availability (i.e., redundancy) of the e-terrahabitat.

e-terrahabitat program development-type systems (PDS) are

installed to provide application development environments, or to

test areas and examine the effects of software changes.

Development is typically done on Windows platform and

deployed to LINUX, and/or Windows.

10 10

Subsystems or components of e-terrahabitat

The e-terrahabitat environment can be conceptually divided into four high level subsystems:

e-terrabrowser (WebFG) User Interface Subsystem

HDB Database Management Subsystem

Programming Tools and Portable APIs

Real-Time Core and Support Applications and Utilities (Alarms,

Configuration Manager, NETIO, Process Manager, Permit, etc.)

11 11

Graphics User Interface (UI) Subsystem

UI forms a direct link between the users and the database.

UI is an easy-to-use full graphics user interface consisting of:

e-terrabrowser (WebFG) for data access (authentication) to

displays

e-terratrust (optional) for authentication using Kerberos.

FG Display Builder for building displays

Real-Time Support Subsystem

Programming Tools and APIs

Databases Management Subsystem

Graphics User Interface Subsystem

e-terrahabitat

12 12

Database Management Subsystems

Hdb is the Database subsystem. There are several concepts that are unique to e-terrahabitat:

Clones, clone context, application, database, and savecases

Hdb consists of many utiltities that allow data to be access, stored and modified:

hdbcloner, hdbcopydata, hdbexport, hdbimport, hdbrio

HdbRdb Tools (hierarchical to relational database utilities)





e-terrahabitat

13 13


Contains many tools, Application Programming Interfaces (APIs) that provide essential functions and allow customization of e-terrahabitat based applications.

ESCATOOLS directory provides a set of tools to store, build and link code with consistent and standard methods.

HABITAT_SRCDIR and HABUSER_SRCDIR are directories containing the source code (codeset) for e-terrahabitat and non e-terrahabitat layer applications (e.g. e-terraplatform).





e-terrahabitat

14 14

Real-Time Support Subsystems

Within e-terrahabitat there are many applications that provide real-time operations support to the real-time, highly available control systems:

ALARM, NETIO, Process Manager (PROCMAN)

Permission Manager (PERMIT)

Configuration Manager (CFGMAN)

Memory Replication Services (MRS)

The applications listed above will be covered in Module 4. Many more applications not listed here are covered in other courses.





e-terrahabitat

15 15

What are e-terrahabitat Applications? (1 of 3)

The e-terrahabitat system (as well as the real-time control systems that are built on it) is a suite of related, database-driven applications.

In the e-terrahabitat context, an application is a uniquely-named collection of one or more of each of the following:

databases what

information is managed by

the application.

tasks how the data is

processed.

displays how the user

works with and accesses

the application.

savecases how the

information is archived from

snapshots of data.

16 16


All e-terrahabitatapplications have the same central organizational structure.

Each component (databases, tasks, displays, and savecases) of an e-terrahabitat application is created (written or built) separately and reflects its modularity.

17 17


An e-terrahabitat-based application is broken down into discrete units of work or operations tasks.

Units could be either standalone or make use of each others

services.

Allows for prioritization of tasks:

Within a bigger application

Between applications

An e-terrahabitat application typically includes one or more tasks, which represent an executable code or script.

NOTE: Tasks are defined in an application definition file called.appdef located in the HABITAT_APPDEFS directory.

18 18

Task View Utility (1 of 2)

Tasks can be started with the Task View utility. Task View allows the user to interactively, start, stop, and view the tasks running on the e-terrahabitat.

Task View can be invoked from the command prompt by typing tview:

Alternatively, Task View can be used in a command-line, non-interactive fashion as follows:

tview run procman procman habitat

habitat start and habitat stop can also be used to start and

stop tasks in e-terrahabitat.

19 19

Task View Utility (2 of 2)

Windows-based e-terrahabitat systems have both a command line and a GUI version of Task View.

To launch Task View you can double click on the shortcut or type the name of executable from the command line.

E:\AREVA\habitatnn\habitat\bin\TaskView.exe

Task View [GUI]

E:\AREVA\habitatnn\habitat\bin\tview.exe (cmdline version)

Task View [Standard]

Windows commands are not case sensitive, unlike UNIX.

shortcut

com

man

d

20 20

Process Manager or PROCMAN is responsible for managing and starting all tasks for e-terrahabitat, and is covered in the Managing High Availability System course or the Procman Users Guide (proc_ug.pdf).

Starting and Stopping e-terrahabitat

To start e-terrahabitat, you would use Task View utility. For example, you could type non-interactively:

tview run procman procman habitat

To stop all tasks, you could do the following:

tview stop -all

You could also start individual tasks as follows:

tview run

You could also stop individual tasks as follows:

tview stop __

familyapplicationtaskcommand

21 21

Summary

1. e-terrahabitat provides an environment for the ________, and ______ of real-time control systems and engineering applications.

2. e-terrahabitat memory-resident ______ subsystem allows it to support large databases where tens-of-thousands of real-time measurements are scanned every two to ten seconds.

3. In the e-terrahabitat context an application is comprised of the following components:

1. ______________

2. ______________

3. ______________

4. ______________

4. The ____ _____ utility allows the user, interactively, to start,stop, and view the tasks running on the e-terrahabitat.

Overview of e-terrahabitat DatabaseDesign and Development

Topics

Data Modeling

Relational and Hierarchical Databases

What is an Application?

What is a Database?

What is a Clone?

HDB Database Management System and Utilities

2 2Overview of e-terrahabitat Database Design and Development

Data Modeling

Data modeling is the process of defining the logical structure of the data in a form that can be prepared for input to a computer.

The purpose of data modeling is to develop an accurate model or graphical representation of the applications needs and processes.

Data modeling specifies the following:

What field data will be stored

How large each value can be

What kind of information each field can contain

Which fields can be left blank

Which fields are constrained to a fixed range

Whether or not (and how) various records are linked


The Relational Data Model

There are two popular types of databases in data modeling: relational and hierarchical.

A relational database consists of a collection of tables, each having a unique name. A row in a table represents a relationship among a set of values. Thus a table represents a collection of relationships:

data

Attributes

Tu

ple

s

Attributes serve as

names for the

data, represented

by each column.

Rows of a

relation are

called

tuples.


Example of a Relation

Here is an example of a relation that describes employees of a company populated with data values

There is an implied relationship because the EMP table has a Dept_No column that is the same as the ID column in the DEPT table.

46.754330Thompson

45.504220Smith

12.000940Dilbert

60.005010Jones

Pay RatePay

Grade

Dept_NoName

DepartmentDept_No

Administrative40

Support30

Training20

Engineering10

EM

P t

ab

le

DEPT table


The Hierarchical Data Model

The hierarchical data model organizes data in a tree structure.

There is a hierarchy of parent and child records, which implies that a record can have repeated information, (generally in the child records).

Power system applications commonly use hierarchical data structures as illustrated below:

SUBSTN

DEVTYP

DEVICE

DEVICE

DEVTYP


Logical (Hierarchical) Structure of e-terrahabitat Databases

Logical structure refers to the

human view of data, i.e., how

records and fields relate to

each other in order to best

model the physical objects that

the data represents.

The HDB model organizes data

using a hierarchical database.

A database is an instance of a

database schema: the

database source schema file is

created from a data model for

input to a computer.

In HDB, a clone schema is an

instance of a data model.

SUBSTN

DEVTYP

DEVICE

DEVICE

DEVICE

DEVICE

DEVTYP


What are e-terrahabitat Applications?

The e-terrahabitat system (as well as the real-time control systems that are built on it) is a suite of related, database-driven applications.

In the context of e-terrahabitat,an application is a uniquely-named collection of one or more of the following:

Displays: How the user works with and accesses the application

Savecases: How the information is archived from snapshots of data

SC

AD

AR

TG

EN

RT

NE

T

Databases: What information is managed by the application

Tasks: How the data is processed


e-terrahabitat Databases

Databases are a main

component of e-terrahabitat

applications.

Databases are a collection of

related information organized

in defined structures called

database schema.

The database schema simply

describes the organizational

structure of the database.

Database schema broadly

consist of the structure of

tables and their relationships.

tasksdatabases

savecasesdisplays

SCADA Application

scadamommescada

taglogcommlog

Note: The design of database schema (.dbef) will be discussed in Module 2.


The Concept of Clones

Databases are

central to all

e-terrahabitatapplicationsA clone

is a collection of one or more databases used to retrieve and store data.

tasksdatabases

savecasesdisplays

SCADA.EMS clone

SCADA.DTS clone

SCADA.XXX clone

SCADA Application

scadamommescada

taglogcommlog

A *.CLS file defines the clone schema and lists the applications, databases, and savecases used for the clone. A clone is a single file (*.car) and contains all databases owned by the application.

Hence, a clone is the data instance of an application under a specified family.


Clone Context (1 of 3)

All data operations in an e-terrahabitat environment depend on a

clone context. A clone context is required for all database access

and consists of:

Application Name: Specifies the application schema involved

Family Name: Specifies the particular family instance of the clone

Group Number: Instance of the e-terrahabitat system. Each instances

of e-terrahabitat will be assigned a unique, 2-digit group number (i.e. 60)

Clone context can be determined as follows:

From default environment variables using:

HABITAT_APPLICATION, HABITAT_FAMILY, HABITAT_GROUP

At a CMD prompt/window and typing the CONTEXT command:

context (i.e.. context scada ems)

Within the user interface login as defined for a given user (mode)

permissions in the PERMIT application

From within an application programmers code using API functions

(covered in the Programming in e-terrahabitat course)


Permissions

defined for an

application

determine the

user level of

access to that

applications

clone.


User assignments and permissions are managed by the PERMIT application. Users can access only one application clone at a time.

CLONE

(SCADA.DTS)

PERMIT

USER1

APPLICATION FAMILY R W E A

SCADA DTS NIOSERVE EMS

USER2

APPLICATION FAMILY R W E A

SCADA EMS NIOSERVE EMS

SESSIONS

CLONE

(SCADA.EMS)

CLONE

(NIOSERVE.EMS)



Heres an example of clone context from two user accounts (dts, demo) with the same application name but a different family name:

User login as DEMO with mode HABTMPLT

User login as DTS with mode DTSTMPLT


What is HDB Database Management Subsystem? (1 of 5)

The database subsystem within e-terrahabitat is called HDB. e-terrahabitat

provides a database subsystem for the creation, manipulation and archival

of the various application databases.

e-terrahabitat contains many databases there is no one single massive

database. Heres a list of frequently-used utilities:

hdbrio: An interactive, command-based database query and edit program, for viewing and modifying database data

hdbcopydata: Copies clones, archives, databases, and savecase files

rdbcopydata: Copies to/from hierarchical to/from relational databases

hdbcompare: Compares two databases, zipped archive files, or savecases

hdbexport: Converts data from an HDB database to an ASCII file for export to HDB or other databases

hdbimport: Loads ASCII files into an HDB database

Data Management Utilities



The hdbdirectory is a system administrator utility for managing HDB groups as they are created, copied (from one computer to another), or

used to repair a corrupt cloning database.

The hdbserver utility is an HDB system administrator program for placing an HDB group clone server online or offline at system start-up

or shut-down.

Administration Utilities



The hdbcloner utility manages database schema and clone instances:

Clone and Database Utility

A complete listing of commands and helphdbcloner h

Lists existing schema defined in the dictionary show_schema

Lists existing clonesshow_clone

Renames a clone file rename_clone

Removes existing schema from the dictionary remove_schema

Removes existing clonesremove_clone

Marks a clone onlineonline_clone

Marks a clone offline offline_clone

Loads new schema or replaces schema in the dictionaryload_schema

Creates a new clone or replaces an existing clonecreate_clone



emsdictionary_setup: Creates the EMSDictionary database within a

relation database

rdbcloner: Loads and creates the e-terrahabitat-based database

schemas corresponding in a relational database instance

rdbcopydata: Copies an entire e-terrahabitat-based database to a

relational database, or copies in the reverse direction

rdbimport: Imports data into a relational database using the data files

created by the hdbexport utility

rdbexport: Exports data from a relational database. The exported data

can be used by the hdbimport utility to import into e-terrahabitat-based

databases

HdbRdb Tools

This course will only focus on hierarchical databases. Additional info on HdbRdb can be found in the HdbRdb Tools User Guide.


HDB Database Subsystem (5 of 5)

hdbdocument: Converts a database schema definition file (DBDEF) into a file containing only the documentation and structure of the database

schema

hdbdump: Dumps clone, archive, and/or save files data to a print file forprinting

hdbformat: Creates Fortran 90 INCLUDE and C-language header files that define database fields for an application

hdbmemlock: A UNIX-only program that locks database partitions into physical memory to enhance data access performance

Other Utilities


Summary

1. _____ _______ is the process of defining the logical structure of data in a form that can be prepared for input to a computer.

2. Power system applications commonly use ___________ data structures.

3. The term used for describing the data structure of a database is called a ____________ __________.

4. An e-terrahabitat application is comprised of four components:

___________, ___________, _____________, and __________.

5. An instance of an applications database space is called a _________.

6. The application clone __________ source file has the file

extension .________.

1 1January 2006

e-terraplatform Overview

2 2January 2006

e-terraplatform

AREVA Software

for

Energy Management Systems

(EMS)

3 3January 2006

e-terraplatform Architecture

4 4January 2006

e-terraplatform -1-

Platform of Application Software for the management of Power Transmission & Generation Systems

4 major Sub-Systems :

SCADA e-terrascada, for the control and monitoring of transmission and distribution grids

NETWORK e-terratransmission, for secure network analysis of transmission grids

GENERATION e-terrageneration, for control and dispatch of power generation

DTS e-terrasimulator, for the simulation of control and power systems

OPERATING SYSTEM

e-terrahabitat

SYSTEM SERVICES

APPLICATIONS

Operations Training

GENERATION

NETWORK

SCADA

Data

Acquisition

Supervisory

Control

DISPATCHER

TRAINING

SIMULATOR

5 5January 2006

e-terraplatform -2-

e-terraplatform is designed on a

core foundation that is shared

among all EMS applications; the

core technology includes:

e-terrahabitat, a real-time computing and database

environment

e-terrabrowser, a graphical user interface for control center

operators

e-terramodeler, an environment for managing all your model

changes

e-terraarchive, an enterprise database for your historical data

and operational knowledge

OPERATING SYSTEM

e-terrahabitat

SYSTEM SERVICES

APPLICATIONS

Operations Training

GENERATION

NETWORK

SCADA

Data

Acquisition

DISPATCHER

TRAINING

SIMULATOR

6 6January 2006

Operating System Support

Server side

Windows Server 2003 Win32

Windows Server 2003 Itanium IA64

Windows Server 2003 x64

Red Hat Linux 3.0 (e-terrahabitat 5.5) and 4.0 (e-terrahabitat5.6)

Tru64 UNIX and OpenVMS will no longer be supported for any upcoming releases

Client side

Windows XP

Windows Vista in 2006

7 7January 2006

Hardware Support Intel Pentium (x86)

Windows 2003 Server 32 bits

Intel Itanium 2 (ia64)

Windows 2003 Server 64 bits

Linux_ia64

Intel EM64T (Extended Memory 64 Technology)

Linux_x64 & Windows 2003 Server 64 Bits

e-terrahabitat 5.6

e-terrahabitat 5.5 not supported in 64-bit mode on this platform

e-terraplatform 2.3 certified as part of the e-terrahabitat 5.6 certification (until then, not supported)

Why not AMD?

Additional testing hardware costs

Ongoing additional testing costs (releases, patches, etc)

Hardware cost saving does not justify additional costs

8 8January 2006

e-terraplatform: Hardware Support

INTEL/MS-Windows based Operator consoles

Low cost

Multi-source

Familiar look & feel

Windows XP Pro or Windows 2000 pro on Pentium X86

PCI based communication boards (DIGI) or DIGI Terminal

Server

9 9January 2006

Application codesets

Documentation set

Release Notes

Test Procedures

Installation and Maintenance Tools

Software Configuration Management Tools

Performance Model

Training

Demonstration System

e-terraplatform - Content of the platform

10 10January 2006

e-terraplatform in 2006Available upgrades

Upgrade to 3.4

(and e-terratrust 1.0)

Upgrade to 5.6

(and eterratrust 1.0)

Upgrade to 2.4

Upgrade to 2.3

Upgrade to 3.4

(and e-terratrust 1.0)

11 11January 2006

EMS Architecture

1 1

EMS MODEL

Topics

Overview

SCADA Data Model

Network Data Model

Generation Data Model

Dispatcher Training Simulator Data Model

2 2

EMS MODEL - Overview

Topics

Purpose of Modeling

Entities to be modeled

Purpose of EMP Subsystems

Main EMP Databases

Displays organization

Modeling tools

Mapping the Power System Model on EMP databases

EMP Modeling : common principles

3 3

OVERVIEW - Purpose of Modeling

Deliver a set of data describing

The equipment for Operation of the Power System

The electrical characteristics of the Network components

The technical and economical parameters of the Generation strategy

The dynamic Simulation of the power system

Identify entities to be managed by the EMS

Represent them by database record types and fields

Modeling versus Populating

Modeling consists of defining the components structure

Populating consists of entering values to describe the components of the

power system

4 4

OVERVIEW - Entities to be modeled (1/2)

Equipment for Operation

Power system description (substation, devices,)

Data retrieval system (RTU)

Communications system (Relation between hosts, TFE, CFE, RTU)

Electrical characteristics of the Network

Topology of the power system

Component characteristics

Load model

Operating limits

5 5

OVERVIEW - Entities to be modeled (2/2)

Generation strategy

Operating areas, plants and units

Tie-lines and transactions between operating areas

Transaction and fuel cost schedules

Dynamic Simulation

Parameters describing the prime movers dynamic

Parameters describing the various relays

6 6

OVERVIEW - EMP Subsystems Purposes (1/2)

SUPERVISORY CONTROL AND DATA ACQUISITION

Subsystem responsible for gathering, processing, displaying information

about the state of a monitored system (i.e. Operate the power system)

Sending controls

NETWORK Analysis

Accurate Assessment of the network state (based on the State Estimator SE)

Various applications to analyze and enhance network security

7 7

OVERVIEW - EMP Subsystems Purposes (2/2)

GENERATION

Adjust generating unit outputs so as to

maintain frequency

control area interchange to the scheduled value

Produce energy to meet the demand at a minimum cost, while observing all

system constraints (economic, security, and energy constraints)

DISPATCHER TRAINING SIMULATOR (DTS)

Offline software sub-system to support training of the power system

dispatchers

Dynamic power system model used to create a simulated operating

environment

Provides instructor facilities for modifying the parameters of the power system

model and the simulation.

8 8

OVERVIEW - Main EMP Databases

One main database for each specialized subsystem

SCADAMOM for SCADA subsystem

NETMOM for NETWORK subsystem

GENMOM for GENERATION subsystem

DTSMOM for DTS subsystem

Each database contains specific record types and fields

SCADAMOM: SUBSTN, DEVICE, POINT, CTRL, ANALOG, LIMIT,

NETMOM: CO, DV, ST, KV, UN, CBTYP, XFMR, LINE, LDAREA,

GENMOM: OPA, PL, PLC, UNIT, TIE, TYLN, FUELTY,

DTSMOM: ST, PLC, UN, GT, HYDRO, VRY, VCB, FRY,

9 9

OVERVIEW - Displays organization

Displays are belonging to applications

Each display shows information stored in EMP databases and allows

entry parameters

Particular displays (tabular) are immediately available to monitor and

control the system

10 10

OVERVIEW - Modeling tools (1/3)

Database building tools

Data Base Builder (DBB) - Bulk initial population

GENESYS - Maintaining and browsing data

Other tools:

SCADAMDL application - Viewing Scada database using RFG displays

Hdbrio - offline database entry tool designed for developers

Hdbimport - imports data from an ASCII file into an Hdb clone

11 11


Display building tools

PC Builder

NT application with Windows GUI

Ability to create an interactive view of application data from one or more

application databases

Ability to access Rapport-FG user interaction functions such as:

- scroll bars

- menus

- panning

- positioning to specific record occurrences

- zooming

- decluttering

12 12


Network Placement Editor (NPE)

NT application with Windows GUI

Automate the production of one-line displays from the data

Provide easy-to-use, intuitive User Interface

Improve the productivity when building & maintaining schematic displays

Eliminate the potential errors when linking the displays with the databases

Accommodate various data sources

13 13

OVERVIEW - Mapping of Power System model on EMP databases

Component SCADAMOM NETMOM GENMOM DTSMOM

Stations SUBSTN ST PL Site and/or ST

Plant controllers DEVICE - PLC PLC

Generating units DEVICE UN UNIT UN

Circuit breakers DEVICE CB - VCB, OCCB or FCB

Lines DEVICE LN - -

Tie-lines DEVICE TLN TYLN -

Transformers DEVICE XF - -

Nodes DEVICE ND - -

14 14

OVERVIEW - EMP Modeling Common principles (1/2)

Building models (example with SCADAMOM)

11-- Create Model of a Create Model of a

SCADA SystemSCADA System

22-- Validate the modelValidate the model

33-- Save a version of Save a version of

the databasethe database

44-- Retrieve for Retrieve for

further further

modificationsmodifications

55-- Transfer model on lineTransfer model on line

SAVECASESAVECASE

Disk FileDisk File

SCADASCADA

SCADAMOMSCADAMOM

Real time applicationReal time application

Data ModelerData Modeler

SCADAMOMSCADAMOM

Modeling applicationModeling application

15 15

OVERVIEW - EMP Modeling : Common principles (2/2)

Validation program

Each database has one or more validation (or verify) program

Activation

Can be activated throughout the development of the database

Must be activated before putting a new version of the database on line

Purpose

Check the data entry consistency

Update existing fields according to the new database

Create new records and/or calculate new fields

1 1> KESH SCADA/EMS October 2005

SCADA OVERVIEW

TOPICS

1. SCADA OVERVIEW

2. SCADA FUNCTION

3. SCADA APPLICATION INTERFACE

4. SCADA DATABASE

5. FRONT END PROCESSOR


SCADA (Supervisory Control and Data Acquisition)SCADA (Supervisory Control and Data Acquisition)

SCADA as the name itself suggests acquires data from geographically distant remote locations and

makes it central at the Control centre for

supervisory control.

SCADA system, thus connects two distinctly different environments.

The Substation The Control Centre

A communication pathway connects the two environments.

SCADA OVERVIEW


CONTROL CENTRE SUBSYSTEM

Data acquisition/transfer system (front end system)

Data base Management system

MMI (Man Machine Interface) system

EMS (Energy Management System)

DMS (Distribution Management System)

SCADA OVERVIEW


SCADA OVERVIEW

Substation mainly will have CTs and PTs

Transducers

Intelligent Electronic Devices (IEDs)

The substation terminus where the communication and substation interface interconnect is the

RTU (Remote Terminal Unit)

FIELD SUBSYSTEM


SCADA OVERVIEW

Any communication circuit with adequate signal to

noise ratio and enough bandwidth may be used.

VSAT

Optic Fibers

COMMUNICATION SUBSYSTEM


SCADA OVERVIEW

104

stns

SCADA Workstations

SCADA Servers

FEP

FOX PANEL

OPTICAL

COMMUNICATION

NETWORK

FOX PANEL

104

stns

FEP

RTURTU

104 line

101 lines

101 stns

RTU

101 lines

104 line

FIELD DEVICESFIELD DEVICES

FOX PANELFOX PANEL

104 line


SCADA OVERVIEW

In Substation , where communication and

substation interface interconnected is the RTU

In control centre , where communication and control

centre interface interconnected is the FEP


SCADA FUNCTIONS

1. DATA ACQUISITION

2. DATA PROCESSING

3. SUPERVISORY CONTROL

4. DEVICE TAGGING & DISPLAY NOTES

5. TOPOLOGY PROCESSING

6. DYNAMIC USER CALCULATIONS

7. LOAD SHEDING

8. HISTORICAL DATA RECORDING

9. DATA MODELLING

10. GRAPHICAL USER DISPLAY

11. USER DISPLAY & OPERATION

12. SCADA FRONT END

13. ALARM MANAGEMENT

14. TRENDING

15. SEQUENCE OF EVENTS (SOE)

16. AREA OF RESPONSIBILITY


SCADA Application Interfaces

SCADAMDL

SCADA

FEP & other sites

RTNET

RTGEN

LOADSHED

Copy Overrides

MeasurementsScansControls

State Estimator Values

Measurements,Status

Instructions (Controls)

Measurements

Pulses, Setpoints

Time error, frequency, tielines, unit MW,status

SCADFREQ

USERCALC

Frequency

Measurements


SCADAMOM Database

SCADAMOM represents the current model of the monitored system.

There is no historical information in SCADAMOM .

Three types of measurements are maintained in SCADAMOM:

Analog Values - Continuously variable quantities (volts, watts,

temperature)

Status Values - Discrete states (tripped/closed, on/off)

Pulse Accumulations - Usually represent quantities delivered

over time (megawatt hours, gallons)


SCADAMOM Hierarchy

SCADEK Separator

SUBSTN Station Data (includes Calculation arguments)

RTU RTU Data (for TFE download only)

TFE Communications to RTUs (for TFE download)

FUNC Calculation Function Definitions

CONV Status Conversions data

ALTTYP Alternate Limits


Substation Subtree Hierarchy

SUBSTN Substation level informationDEVTYP Device type: circuit breaker, transformer, pump, valve, etc.

DEVICE E.g, Line # 1, breaker #2MEAS Group of measurements and controls used by Calculations

POINT A status point: on/off, open/closed, etc.CTRL Controls allowed for the device

LOCK Interlocking points on the controlPNTMSG Alternate logging text = 40 characters

ANALOG A measurement: KV, MW, etc. LIMIT Measurement limits used for abnormal and alarm definitions

ALTLIM Alternate limits: Winter/Summer, Day/Night, etc.RATLIM Rate-of-change limitsSETPNT Set Point controlsANAMSG Alternate logging text = 40 characters

COUNT Pulse Accumulators reading: KWH, BBLS, etc.RCONST Constant value for CalculationsPNTREF Reference to a POINT record under another MEAS recordALGREF Reference to a ANALOG record under another MEAS recordCNTREF Reference to a COUNT record under another MEAS recordCONREF Reference to a CONST record under another MEAS recordCTLREF Reference to a CTRL record under another MEAS recordSETREF Reference to a SETPNT record under another MEAS record


Naming Conventions

8 6 14 4

Redmond MOTR 1 STTS

ID_SUBSTN=REDMOND

ID_DEVTYP=MOTR

ID_DEVICE=1

ID_ANALOG/ ID_COUNT/ ID_POINT=STTS

o Name is composite key of ID fields (Virtual ID).

o Restrictions on names:

- SUBSTN must be unique under the parent SCADEK.

- DEVTYP must be unique under the parent SUBSTN.

- DEVICE must be unique under the parent DEVTYP.

- Measurements must be unique under the parent DEVICE.

- No embedded spaces.

Additional fields which may be used in Alarms and on displays, for more precision:

- NAME_SUBSTN (16 characters) and/or NAME_DEVICE (24 characters); spaces OK in both.

------

- OR-

- ANAMSG/PNTMSG = alternate 40 characters -optional alternate namefor alarms, events, and on displays; embedded spaces are OK.

40


RTU Subtree Hierarchy

RTU Description of RTU

PCLRTU * RTU type-specific option(s)

ADRS Grouping associated by type and rate

PCLADR * ADRS-specific modeling option(s)CARD Set of points wired to one card

PCLCRD * CARD-specific modeling option(s)

CONECT Raw Status information

XDUCER Raw Analog measurementPULSE Raw Pulse Accumulator measurement

RELAY Output record used for transmitting controls

ANOUT Analog OutputXDUREF Reference to XDUCER

CONECR Reference to CONECT

RTPORT Each port, if RTU is multi-ported

PATHC Connection of this port to a PATH (comm line)

* PCL* records - RTU protocol-specific modeling


Communication Hierarchy

SCADA lets you model the way each host device in the system communicates with each RTU along its communication path.

* PCL records - configuration - specific modeling option(s)

TFE Describes each CPU node(s) in which TFEMAIN runs

CHANEL Describes each CFE device(s) assigned to each TFE

PATH Describes each communication path to one or more RTUs

RTUC Describes the communication aspects of each RTU

RTU Index Into the SCADAMOM RTU Subtree

PCLCHN*

PCLPTH*


EMP Front End

RTU

RTU

RTU

RTU

FEP to FEPCommunications

SecondaryPrimary

Offline SCADA Server

Online Telemetry

Online SCADA Server

Online Telemetry

ISD Protocol

e-terrascadaSystem

e-terrascadaSystem

e-terracontrol e-terracontrol


Front End Processor Functions

The Front End Processor (FEP) handles protocol specific details of all normal RTU data retrieval functions, independently of the EMS / SCADA CPU(s).

Converts RTU formats to RTU-independent format.

Provides exception reporting.

Sequences select-before-operate controls.

Convert raw data in Engineering unit.

Interface SCADA server by using ISD protocol

Provides User-Interface for Communication management

Provides User-Interface for SOE analysis

Provides FEP redundancy management


(FEP) Internal Functional Blocks

SCADA Host

To UI Client(s)

To RTUs

Protocol Z

To RTUs

Protocol X

To RTUs

Protocol Y

LAN/WAN Interface

InterSite Data Links

Display Server

FEP Server

and Database

CFEReader

RTU Protocol

Translator

Gateway

Apps Device Apps

PLC/Modbus

ReaderTo DCS/PLC

Protocol QQQ


Line Switching (Physical)

Scada Server allows only one of two FEP Server online

Primary Server Secondary Server

CFEReader

FEP Server FEP Server

CFEReader

Serial Comm Ports Serial Comm Ports

Bit-to-Byte Converter Bit-to-Byte Converter

Winstream (CFE) Winstream (CFE)

RTU RTURTU

Modem Modem

(not needed for some protocols)Ports


SCADA Overview

Summary

SCADA drives the RTU data acquisition done by the Front-End

SCADA maintains an accurate and up-to-date model of the

system being monitored.

SCADA maintains three types of measurements:

Status Values

Analog Values

Pulse Accumulations

The FEP manage the communication lines, receives data from the RTU, formats the data, and then sends it to the SCADA host.

Layered Applications (SCADA)

Topics

SCADA Data Flow

SCADA Subsystems

SCADA Host Processes

2 2The SCADA Subsystem

The SCADA Subsystem

The SCADA subsystem is a set of applications that deal with:

data acquisition

from RTUs

from other sites

from other programs

supervisory control

other miscellaneous functions

historical data recording

tagging

loadshed

generalized calculations

topology processing


SCADA Data Flow

scapi users (e.g. psa

apps, dts apps,

customs)

SCADA Apps (e.g.

SCANNER,

CONTROL,

TAGGING, . . .)

SCADA

dbs

User

Workstation

Telemetered

Physical

Equipment

Other Sites

& Systems

(e.g.

ISDLINK,

ICCPLINK)

Network

HABITAT SERVICES

PROCMAN

CFGMAN

HDB/MRS

NETIO

ALARM

TIMEDATE

HDR

Outputs

Network

Other

SCADA

dbs


The SCADA Host

The SCADA Host machine is the repository of acquired data

from various sources:

telemetry through the front ends to RTUs

messages sent from SCADA API (scapi) users

inter-site data (ISD) transfers from other sites

The data is held in the SCADAMOM database of the SCADA

application clone.

There are up to 10 SCADA-related processes that own and

write to partitions of this database during real-time operations.

Some own private partitions which only they read/write.

Some own public partitions that they write and others read.


SCADA Host Processes (1 of 6)

SCANNER - the main data processing module in SCADA:

reads data from:

scapi clients

other sites via ISD

processes limits and alarms

processes data quality information

calculates non-telemetered point values

writes history files

outputs ISD to other sites



CONTROL -

processes supervisory controls from:

operator stations

other scapi API clients (like AGC and Loadshed)

other host sites (via CONTROL-to-CONTROL NETIO link)

manages control sequence for client through communications to

front-end processors



SCSRV - supports scapi interface by:

serving as the single point of contact for applications that wish to

read or write SCADA data, or issue controls.

SCADA Host

SCSRV

SCANNER

CONTROL

FE

scapi

client

scapi

client

scapi

client

scapi

client



USERCALC - allows the operator to create new calculations

from existing SCADA data during operations.

scapi client

output values may be

directed into SCADAMOM database points

(points must be modeled correctly)

held in a local USERCALC variable

periodic rate defined for the calculation

SCADATOP - determines the connectivity and energization of

the electrical network.

scapi client

allows alarming for loss of connectivity

allows conditions to be displayed



TAGGING - for marking devices to limit accepted controls

(either locally, or at remote sites.)

linked directly to CONTROL via NETIO

messages from TAGGING used by CONTROL to disable and re-

enable possible controls on devices.

LOADSHED - sends load shedding controls automatically to

RTUs in emergency situations

scapi client

issues messages to CONTROL

activity based on database modeling and triggers by operator

(automatic triggers possible.)

also manages restoration after load shed incident (manually only)



HDRCOPY - automatically copies closed historical data files

from SCANNER to an alternate location for redundancy.

optional

copies from HABITAT_HDR_RECORD environment location to

HABITAT_HDR_BACKUP

RECON - allows the operator to examine the state of the

system at a previous time, based on information in

SCANNERs historical data files.

optional

can recover snapshot in time

can playback on scan-by-scan basis

can show tabular history of selected measurements


Summary

1. SCADA is a major user of ___________ services.

2. Multiple SCADA processes run on the Host CPU where the

_________ ________ repository resides.

3. Many SCADA processes:

a) are started by ___________.

b) are given roles by ____________.

c) connect with other processes using ________.

SCADA Displays1

Proprietary - See Copyright Page

Notes:

1 1> Displays

SCADA User Interface

Topics

Overview and Detailed one-line displays

Picture Definitions

SCADA host and other UI

SCADA Displays2


Notes:

2 2> Displays

Station Mapboard Display

REDBRIDG

GOLDEN B'VILLE STRATFRD

J'VILLE

COBDEN BRIGHTON

E C A R

PICTON

CHENAUX

E A S T

MITCHELL

CHFALLS

MARTDALE

CEYLON RICHVIEW LAKEVIEW

HEARN

KINCARD

HANOVER

DOUGLAS

PARKHILL

HUNTVILL

THOREAU

NANTCOKE

SOUTH

HOLDEN

STINSON

WALDEN M'TOWN

W'VILLE

NORTH

Display = MAPBOARD,SCADA

SCADA Displays3


Notes:

3 3> Displays

Douglas Substation Schematic

DOUGLAS,40SCADA[ESCA] 1,1

1314

MWMVRMVA

400401

401402 401403

MWMVRMVA

FDR 402

MWMVRMVA

GEN1

1516

MWMVRMVA

GEN2

MORE

sc056.cvs

Navigate/Zoom Display/Full

SCADA Displays4


Notes:

4 4> Displays

Sample CB Picture

1 BAAAAAAAA

Field A - Identity and condition of circuit breaker

Format: 8 alphanumeric characters

State 1 - WHITE STEADY = NOT SELECTED

State 2 - WHITE BLINKING = SELECTED

Poke-point:

1. Select for control

2. Acknowledge alarm

3. Inhibit/enable alarm

4. Remove from scan/restore to scan

5. Tag/clear tag

Field 1 - Status of circuit breakerFormat: 1 graphic character

State 1 - RED STEADY = CLOSED, NO ALARM

State 2 - GREEN STEADY = OPEN, NO ALARM

State 3 - RED BLINKING = CLOSED, ALARM

State 4 - GREEN BLINKING = OPEN, ALARM

Field B - Data quality flag

Format: 1 alphanumeric character

sc024.cvs

Display = any substation oneline

SCADA Displays5


Notes:

5 5> Displays

SCADA User Interface

SCADA Host User Interface

SCADA application displays:

Overview and Substation oneline displays

Tabular displays related to many kinds of summary

Other SCADA functional displays

HDR / Tagging functions

Maintenance : Log, Calculation, On-line editor

Other Application displays

Usercalc / Loadshed

ALARM User Interface

Any Alarm & Event lists and synopsis alarm list

FEP User Interface

Communication Diagram from FEP or OAG systems

SCADA Displays6


Notes:

6 6> Displays

Demonstration & Lab

SCADA uses three basic types of displays:

Overview Mapboard Display

Schematic Diagrams Substation oneline

Tabular Displays Substation Tabular

Substation displays analysis

Displays access : Menus / Summaries / Buttons for navigation

Typical pictures : Point / Analog / popup menus

Detailed pictures : Quality flags / On-line editor

Other displays

Communication Diagram from eterra.Control (FEP)

SCADA utilities : SCADA menus / Related & Analyst displays

SCADA Displays7


Notes:

7 7> Displays

SCADA Displays

Summary

SCADA host uses three basic types of displays:

Overview Displays

Schematic Diagrams

Tabular Displays

Other UI are

Dedicated applications displays : Alarm , Loadshed

Other Communication servers : FEP and OAG systems

Alarms1


Notes:

1 1> Alarm

Alarms

Topics

Overview, Definition, Concepts, and Perspective

Databases

List Displays

Synopsis Display

Major Inputs and Outputs and Software Organization

SCADA Alarms Defined via Genesys

Area of Responsibility and Permission Areas

Alarms2


Notes:

2 2> Alarm

Alarm Overview

ALARM server processing:Format event.Event/Alarm?Insert in lists?

Insert in Log(s)?

Auto-ack Alarm?Replicate on standby.

ArchiveSound tone(s)?

Print?Notify client(s)?

client

- Object (type + handle)

- Time- Exception- Category- Location- Permission key- Options- Formatting data

Alarm Modelling

Information

Archive(Flat file)

Alarm Lists

Permit

Horn

Event

AckNotification

(optional)

Display

Alarm LOG

Application

- Category1- Category2- Object definition 1

* exception1* exception2

- Object definition 2* Exception1

Display

Displays = Alarm app: ALARM and ALARM_SYSTEM_ACTIVITY

SCADA app: TIMEXC (Time Ordered Exception List)

Alarms3


Notes:

3 3> Alarm

Definitions (1 of 4)

Event - An event occurs when something notable happens at a single point in place/time. The only events of relevance here are those detected by the software. Thus, an event is detected (butmay be declared to have occurred at a previous time) whenever a particular software criterion is satisfied.

State Change - Each potentially alarmable event is a state change of a database object. The state of a database object is determined by software criteria.

Abnormal State - When a database object experiences a state change, it may or may not enter an abnormal state. Its abnormalstate(s) is determined by software criteria.

Alarms4


Notes:

4 4> Alarm


Exception - A database object becomes an exception when it experiences a change to an abnormal and/or alarmable state. It remains an exception if either:

It is in an abnormal state.

It has experienced an alarmable state change that is unacknowledged.

Exception Display - An application display of exceptions in one or more categories.

Alarm - An alarm is an unsolicited indication from an application to an operator that a new exception(s) has occurred.

Alarms5


Notes:

5 5> Alarm


Alarm Exception - An exception that requires an alarm.

Acknowledgment - The action taken by an operator to confirm, via

software, that an alarm has been recognized.

Permission Area - Each database object that can enter an

alarmable state is assigned to a single permission area.

Permission areas are also assigned to consoles. Alarm

information is conditional on a console basis, using permission

area assignments.

Alarms6


Notes:

6 6> Alarm


Category - Each exception is assigned to a category. Categories

are used to classify exceptions that have similar attributes, for the

purpose of convenient console presentation and notification

control. Each category is assigned a priority and a severity,

which are used to group alarms within a list display and to order

Category and Location Alarm Line entries.

Location - All exceptions are assigned to locations, or geographic

area occurrence, typically a substation. Locations are used for

convenient console presentation. When an application does not

specify a location, ALARM uses a default from its database.

Alarms7


Notes:

7 7> Alarm

Alarm Concepts (1 of 3)

Each database object that can enter an abnormal and/or

alarmable state is assigned:

Category

Permission area

Exception definition

Optionally to a location (SCADA generally uses substation name)

The application that owns the database object makes the

assignment.

Alarms8


Notes:

8 8> Alarm


Examples of typical SCADA alarm categories:

230 KV transmission

Major 13 KV distribution

Line overload

Breaker trip

Low voltage

Display = Alarm_Synopsis_List_Default

Alarms9


Notes:

9 9> Alarm


Category synopsis buttons can appear dynamically to represent

unacknowledged alarms. Poking these buttons can bring up an

applications abnormal display or alarm display.

Location synopsis buttons can appear dynamically with function

and behavior similar to that of category buttons, except that the

displays brought up are usually the corresponding substations

oneline display.

For SCADA, alarm location is usually a substation name.

Alarms10


Notes:

10 10> Alarm

SCADA as an Alarm User

PowerSystemEvent

SCADAApplication

Abnormal

Indication?

Acknowledgment?

Exception Display

Alarm Utility

Acknowledgment? Logging?

System Activity Log(s)and displays(s)

Alarm Synopsis Lines Alarm ListDisplays

Acknowledgment?

ne

t01

2.c

vs

Hardcopy

Logger(s)[Printer(s)]

Printing?Horn

Issue Ack

Alarms11


Notes:

11 11> Alarm

Alarm Database Hierarchy

DeckApp Application that issues alarms

Deflog Default log for messages

Cat User process alarm communicates with

Category of exceptions

Objdef Dbase objects for which alarms are generated

Excdef Exception Definition

Ovlog Override log for exception messages

Loc Location of exceptions

Que Permission area messages are assigned to

Horn Horn device to issue audible signals

Tone Audible toneHABITAT console to hear/silence a horn

Consol

Display = Alarm_Model_Exception_Cat

Then from FG managers command box, do:

find objdef=analog

Also, see Alarm Users Guide,

section Defining Application Exceptions

Alarms12


Notes:

12 12> Alarm

Three Types of Alarm and Abnormal List Displays (1 of 3)

Alarm Lists

Maintained by Alarm Utility

Contain alarm events only

Sorted by various combinations of location, priority, unacknowledged

vs. acknowledged, and time

Unacknowledged can be acknowledged; acknowledged can be

deleted

Intended to be kept short

Displays = Alarm

Then to see other sorting sequences and filterings of the alarm list, open the Alarm Displays menu,

select Alarm Lists, then select any or all of the fourteen Alarm list displays.

Alarms13


Notes:

13 13> Alarm


System Activity Logs

Maintained by Alarm utility

Contain Alarm events, plus operator action events

Time ordered

Historical record

No acknowledgment

Entries never deleted, except via circular wraparound

Open Alarm Displays menu, select Event Logs, then select any or all of System Activity Log, Log #2,

or Log #3.

Alarms14


Notes:

14 14> Alarm


SCADA Exception Lists

Maintained by SCADA

Contain unacknowledged alarm events, plus objects that are currently

abnormal

Unacknowledged can be acknowledged

Various orders: time, substation, status POINT only, ANALOG only

Open menu, EMP Applications, and select SCADA; then select Substation Tabular Directory. Now open

Related Displays menu, and select Exception Lists, followed by Time Ordered Point/Analog. You can now

navigate, using any of the nineteen exception list displays.

Alarms15


Notes:

15 15> Alarm

Independence of Alarms and Abnormals for POINT

Each POINT is assigned to a PNTTYP (point type record).

Each PNTTYP record has flags to define abnormal and alarm

status for each state of the POINT.

ABNORM00, ABNORM01, ABNORM10, ABNORM11

ALARM00, ALARM01, ALARM10, ALARM11

Commanded state changes are not alarmed, but may be

abnormal and/or logged (optional).

Alarms16


Notes:

16 16> Alarm

SCADA Inhibit Flags

Provided on SUBSTN, DEVICE, POINT, ANALOG, RTU, SITE,

CTRL, and SETPNT records.

There are two sets of flags:

INHIBIT DEFINITION - temporary, via operator action in realtime

INITIAL INHIBIT - permanent, operator can not reenable in realtime

The restriction of exception reporting is for:

Logging (alarm issue) - No alarm issued if logging is inhibited

Unacknowledgment - alarm is issued as pre-acknowledged

Alarms17


Notes:

17 17> Alarm

Demonstration & Lab

Generate Alarms

On Point : NIS / Toggle / Enable again Change of status

On Analog : Manual entry crossing a limit Analog violation

Review summaries

Alarm lists / Synopsis lists / System Activity Log

SCADA exception lists

Alarms acknowledgment

On list : individual / by page

On point : Tabular display or popup menu

Alarms18


Notes:

18 18> Alarm

Alarms

Summary (1 of 2)

SCADA is a user of the Alarm application.

Alarms are issued for events that indicate database objects have

changed states. The state changes may or may not mean

abnormal conditions.

Events are classified into:

Categories, which broadly classify the type of alarms

Exceptions, which specify unacknowledged or abnormal alarms

Locations, which group alarms according to where they occur

Alarms19


Notes:

19 19> Alarm

Alarms

Summary (2 of 2)

Priorities, for ordering alarm messages by importance

Severities, for ordering location and category buttons

The Alarm process maintains a system alarm list for all the

applications and a location alarm list for each location. Alarm

messages on both lists are chronologically ordered.

Permission areas, which specify the operators areas of

responsibility

Data Acquisition and Data Quality1


Notes:

1 1> Data Acquisition and data quality

Data Acquisition and Data Quality

Topics

Data Acquisition

RTU Front-End and other sites connection by ISD protocol

Data Processing

Data Quality

Data Quality Flags

Displaying Data Quality

HDR - Historical Data Recording

Topology




Data Acquisition

Modem(1 per line)Bridging

Power SystemDevices

SCADA

Communications

Front End (FEP)

RTU

(1 or more

RTUs per line)

EMS Host

SCADA Data Controls

RawData Controls

RTUData

SCADAMOM




RTU Functions

Data to FEP/

Controls from FEP

Power System

RTUAnalog data

(measurements)

Status data

(on/off)

Pulse

accumulations

Control outputs

(trip/close, raise/lower)

MW outputs

(Setpoint outputs)

Analog-to-digital

converter

Digital inputs

Accumulator

counter

Control signals

out

Digital-to-analog

converter

Control

Logic




SCADA Host Functions

Primary task is to maintain SCADA databases, using ISD protocol for exchange with Front-End Processor and other sites

Performs other functions:

Manages ISD protocol for exchange with Front-End Processor and

other sites

Performs limit checks.

Processes alarms.

Processes calculations

Processes HDR recording and SCADA topology

Secondary tasks

Interfaces with SCADA utilities by using API

Front-End Processor down load management about COMM / RTU

models




SCADA Data Processing

The major function of the data processing module is to place

data from RTUs into the database.

Status Points Analog Values Pulse Accumulators

Retrieved values

checked for any

status changes.

Retrieved values in

engineering units

Last retrieved value is

converted to floating

point and scaled.

Points then checked

for a defined

normal state.

Engineering value

checked against

operational limits

and rate of change

limits.

Conditionally, difference

with respect to previous

value is computed, with

adjustment if value

negative (counter wrap-

around)




Data Quality

There are three kinds of Data Quality flags:

Source Flags - Indicate where the data has come from.

Reliability Flags - Indicate the reliability of the data.

Composite Flags - Summarize combinations of Source and/or

Reliability Flags.




Source Flags

NREMOTE- Value is normally reported by another SCADA site

(i.e Front-End)

BKUPSITE - If the main site is out of service, value will

automatically be accepted from another SCADA site.

NCALC - Value is normally calculated from other values in the

database.

NMANUAL - Value is normally entered manually by the operator.

NEXTERN - Value is normally supplied by an external source,

such as the State Estimator.




Reliability Flags (1 of 3)

UNINIT - Data has never been received for this record (or cold

start).

OLD - Data not properly retrieved from normal source at last

opportunity.

BAD - Data came from RTU circuitry determined to be bad.

(Analog-to-Digital converter check values out of limits.)

OVER - Value may be over or under the capacity of the Analog-to-

Digital converter (e.g., raw value of -2048 or + 2047 (or 0 or 4095)





ABNOMAL - Set by State Estimator if trend of SCADA values from record do not fit into system state solution

NIS - Display value is no longer updated by its normal source. This flag is set only by the operator.

SEREP - Set by operator to replace value with State Estimated value. Value must be set as NIS first

UNREAS - Auxiliary bit to indicate that value was marked OLD because an analog exceeds reasonability limits or a point returns an illegal bit combination.





REMSUP - Value declared suspect at remote site (OLD, BAD, or OVER).

MANREP - Normal value was manually replaced by the operator (after being set NIS).

ESTREP - Normal value was replaced by the State Estimator (after being set NIS).

REMREPL - Value replaced at remote site (MANREP or ESTREP).

GENREP - Value replaced by User Generalized Calculation.

Action at

Native

Site

Quality at

Native Site

Quality at

ISD Receiver

Site

Remove

from

Service

NIS REMSUSP

ManualReplace

MANREP REMREPL

(do NOT see

NIS nor OLD)

(do NOT see

MANREP)

Flag, ESTREP, applies only to Analogs.




Composite Flags

GARBAGE - Meaningless value.

Set if UNINIT is set.

SUSPECT - Value probably not reliable.

Set if OLD, BAD, REMSUSP and/or OVER is set.

REPLACED - Replaced value.

Set if MANREP, ESTREP, REMREPL, or GENREP is set.

GOOD - Reliable, up-to-date value.

Set if neither GARBAGE, SUSPECT, nor REPLACED is set.




HDR: Historical Data Recording

RTU

OperatorEntry

OtherSite

External Program

HDRFiles

SCANNERDataProcessing

StatusAnalog

Calculation

Count Limit




HDR Reconstruction

HDR

FilesRECON

History,RECON[DTS]

32

3100000

-

------

0

0064728688

Validate

ChenauxGen

G1MW

Time Rq

------------

Build

HearnGen

G1MW

1/1/99 00:00:00--

----

(Many)-----------

Playback

Mode

HistoryMode

CHENAUX,RECON[DTS]




HDR Recording

Each HDR file contains a list of all the POINTs, ANALOGs,

LIMITs, and COUNTs being recorded, plus their initial value and quality.

Subsequently, each change in value or quality is stored in the file, along with the time of occurrence.

Recording is continuous, not based on triggers.

Recording is compact and files can be archived for off-line

storage.

Individual POINTs, ANALOGs, COUNTs, and certain LIMITs*

may be selected for recording.




HDR Reconstruction

Allows Historical data to be used to populate a SCADAMOM

database in a RECON application clone. Historical data may be viewed using the same displays that are used to view real-

time data.

User may reconstruct history to any specific time.

User may play through the HDR history at any rate, pause the playback, or single-step through history one scan at a

time.

User can identify selected measurements by their virtual ID.

RECON then builds a tabular view of the history of those measurements for any time range




SCADA Topology

Determines energization and connectivity of electrical devices.

Used to issue alarms, drive mapboards, and drive dynamic

oneline displays.

Separate from RTNET topology processor to accommodate

SCADA-only sites.




Topology Terms

Connectivity States (apply to both terminals of a

2-terminal device)

Open - Device terminal is open.

Connected - Device terminal is connected.

Grounded - Device terminal is connected to ground.

Energization States (apply to device)

Live - Device is in an island where measurements indicate island is

live.

Dead - Device is in an island where measurements indicate island

is dead.

Ambiguous - Unknown - Device is in an island where

measurements are not available or consistent.




Topology - Buses and Islands

Node names entered on Device, Point, and Analog records

are used by Topology processor to determine what is

connected to what.

Buses are formed by grouping nodes that are connected by closed switching devices. Each valid bus is an island to which

an energization state is assigned, based on measurements in the island.

A special node (GRND) indicates electrical ground. All devices in an island are marked as grounded if any GRND nodes are present in the island.




Topology Example (1 of 2)

G125

1C

G120

1B

G115

1A

G225

2C

G220

2B

G215

2A

69KV 69KV

Gen 1 Gen 2

230KV Bus1




Topology Example (2 of 2)

Devtyp: Gen

Device: G1 Near: 1A

Point: G115 Near: 1A Far: 1B

Point: G120 Near: 1B Far: 1C

Point G125 Near: 1C Far: Bus1

Analog: KV Node: 1A

Device: G2 Near: 2A

Point: G215 Near: 2A Far: 2B

Point: G220 Near: 2B Far: 2C

Point G225 Near: 2C Far: Bus1

Analog: KV Node: 2A

Devtyp: Bus

Device: 230Bus1

Analog: KV Node: Bus1




Demonstration & Lab

Status / Analog Quality Flags review

General controls on SCADA Command button review

Not in Service command

Manual Entry on Status and Analog

Historical Data recording

Recording / HDR file management

Reconstruction : Playback and history modes




Data Acquisition and Data Quality

Summary

The SCADA host interfaces the Frond-End (FEP) as any other SCADA sites by using the ISD protocol.

The host maintains the SCADA databases and performs any necessary checks and calculation on the incoming data.

There are three kinds of data quality flags: Source, Reliability,

and Composite.

Additional features include historical data recording and topology

processing.

Status Measurements1


1 1> Status measurements

Status Measurements

Topics

Digital Status Processing

Display Values

Momentary Change Flag

State Definitions

Status Flags

Sequence of Events




Status POINT Measurements

Data Stream

STATUS

SRAW

XRAW

Raw

Invert

Conversion(if needed)

SDIS

XDIS

Display

Types of Status:

Two-stateThree-stateFour-state

ON/OFFON/in-between/OFFStates 1,2,3,4

Data Stream:

SPREP

XPREPsc1513.cvs

Two-state 1 Bit SDISThree & four-states 2 Bits SDIS/XDIS

FEP side SCADA host side




S X Meaning

0 x Open

1 x Closed

Two-state points use 1 bit to represent whether they are

OPEN/CLOSED, ON/OFF, etc.

Status meanings for SDIS and XDIS

Digital Status Inputs (Two-State)

BIT STATUS

Open

Closed

0

1

SRAW

sc214.cvs

x=

Dont Care

} Values needed by- RTNET

(or Closed)

(or Open)




Digital Status Inputs (Three-State) (1 of 2)

Open

0

0

1

1

Closed

0

1

0

1

In Between

Not Open/Closed

Open/Not Closed

Open/Closed Meaningless state = UNREAS

State

sc215.cvs

Three-state points use 2 bits to represent the status of the point.

A value can have a state between fully opened and fully closed.

SRAW XRAW




Digital Status Inputs (Three-State) (2 of 2)

Status meanings for SDIS and XDIS

S X Meaning

0 01 00 11 1

OpenClosedIn TransitIllegal State

Values needed by

- RTNET




Persistant Alarming for Status POINTs

POINT TYPE

Illegal condition validity status

Abnormal position Exception management

Alarming transition Alarm management

DELAY POINT

Instead of issuing an alarm as soon as a POINT value spontaneously goes abnormal, the alarm can optionally be

delayed, and be issued only if the POINT stays abnormal for a user-specified number of seconds.

Possible

Indications

Effect When

DELAY = True

Display Value

and ABNORMAL flag

Immediately updated

(never delayed)

Issue an Alarm Delayed

Log event/alarm on

SYSACT display

Conditionally delayed,

based on SCPARM item




POINT Flags (1 of 3)

UNACK - If set, an unacknowledged alarm exists for this point.

UNACKVAL - If set, an unacknowledged status change exists

on the point.

UNACKRES - If set, an unacknowledged illegal condition

exists on the point.

ABNORMAL - If set, the point is not in its normal state.

INHIBIT - If set, alarm processing is restricted for this value.





TAG1 - TAG14 - These flags are provided to allow multiple user-

defined tags.

NOTAG - If set, none of TAG1 - TAG14 flags is set.

SELECT - If set, point is reserved by a console while a command is in progress.

PENDING - If set, a control on this point has been sent to the RTU, and the associated telemetry verification is expected.

DQ1 - DQ5, DA1 - DA5 - User-definable flags.

CMD - If set, the value is the result of a control command.





BKUPSITE - Point may be received from another site if RTU

scanning it is NIS.

REMOTE - Another site may control this point.

FLIP - Point state should be inverted before being used by advanced applications.

THREE - Point is represented by S and X bits.

HDR - Point stored in HDR history files.

AUTOACK - Point acknowledged when it returns to normal state.




Pending Flag

DEVICE SELECTED FOR TRIP

Controland

Data Processing

RTUInterface

CONTROLPENDING

SCADAMOM

EXECUTE1)

EXECUTE3)

Change of State

Executed Control

4)

PENDING

Bit

Set

2) PENDING

Bit

Reset

5)

Optional:

If state change does not occur within a timeout period, there is a timeout alarm.

sc052.cvs




FEP : PCI Bus

CF

E

CF

E

TIME

S

TD

M M

Sequence-of-Events

l Satellite time provided on PCI bus via time standard.

l CFE sets RTU clock periodically, based on system time synchronization period

parameter, typically to +/- 10ms of satellite time.

l RTU time tags status changes and notifies host when they are available.

l CFE retrieves SOE data from RTU, then FEP locally stores iinto SOE files based .csv format.

l Data listed by SOEviewer UI which accesses to all related FEP for SOE files reading

l Not supported for all RTU protocols.

l No formal link with the SCADA system, however RTU time is transferred by ISD protocol

RTU




Status Measurements

Summary

The Area of Responsibility determines the devices to which a console can issue commands.

Status points return one, two, or three bits, allowing the following types of reports:

Two State (on/off, open/closed, etc.)

Three State (open/in-between/closed)

Four State (open/more than half-open, less than half-open/closed)

Sequence of events

Locally managed then stored by FEP server

Dedicated UI not linked with the SCADA host system

Analog Measurements1


1 1> Analog Measurements

Analog Measurements

Analog Limits

ANALOG and LIMIT Flags

Limit Processing

Limit Replacement




SCADA Analog Measurements

The retrieved values are converted to engineering units, then transferred to SCADA host and placed in the database.

RawData Stream

ANALOG

LinearNon-Linear

Display

RAW

I 4*

DISPREP

Conversion Reasonability Check

sc1526.cvs

R * 4R *4

Normalize to

2s Complement

SCADA host sideFEP side

Displays = RTU_ANALYST_INFO, on Card Type = XDUCER, and SUBSTN_ANALOG_TABULAR, in

SCADA

and DTSMEAS_PWRFLOW, in DTSPSM application




Analog Reasonability Limits

Used to check reliability of data.

Raw value reasonability limits (RAWHIGH_XDUCER, RAWLOW_XDUCER) : Done by FEP

Integer values for incoming data that scale to engineering units.

If the raw value is out of range (0 or 4095, or -2048 or +2047) for the Analog-to-Digital converter, that value is marked OVER.

Engineering reasonability limits (HIREAS_ANALOG,

LOREAS_ANALOG) : Done by Host SCADA

If the converted data value is not within these limits, the data quality

is set to UNREAS and OLD, and the converted value is not

saved.




Analog Operational Limits

Used to generate exceptions and alarms.

LIMIT, RATLIM, and ALTLIM records are used to declare limits:

Basic operational limits

Alternate limits

ANALOG

LIMIT

ALTLIM

DEVICE

MEAS

sc1

52

7.c

vs

RATLIM Rate-of-change limits

Display = SUBSTN_ANALOG_TABULAR, in application SCADA:

from any SCADA display, open Related Displays menu, and

choose Substation Tabular, then Substation Directory, then

desired substations button, and lastly Analogs/Limits radio

button.




ANALOG Flags (1

are va training

Documents

isolate eterrahabitat

eterrahabitat users

features of e

components of e

example of e

biteterrahabitat environment

based applications

red hat linux