Robust Adaptive Topology Control

madbrainedmudlickAI and Robotics

Oct 20, 2013 (3 years and 9 months ago)

171 views

TEXAS A&M UNIVERSITY

Robust Adaptive Topology
Control

Architecture Specification


Tomo Popovic













Version

Date

Description

0.12

8/22/12

Outline, First

Draft









Table of Contents

Introduction

................................
................................
................................
................................
..................

3

Context View

................................
................................
................................
................................
.................

5

Functional View

................................
................................
................................
................................
.............

6

Key Functional

Users

................................
................................
................................
................................
.

6

Top View

................................
................................
................................
................................
...................

6

Significant Use Cases

................................
................................
................................
................................
.

7

Renewable Generation Loss

................................
................................
................................
.................

7

Cascading Event Mitigation

................................
................................
................................
...................

7

Malicious Attack Mitigation

................................
................................
................................
..................

7

Co
st
-
based Optimization (Market
-
based optimization)

................................
................................
.......

7

Minimize Generation Cost

................................
................................
................................
....................

7

Minimize Load Shedding

................................
................................
................................
.......................

7

Optimization Algorithm

................................
................................
................................
........................

7

Cascad
ing Event Detection

................................
................................
................................
...................

7

Relay Settings Adjustment

................................
................................
................................
....................

7

Switching Stability Check

................................
................................
................................
......................

8

Switching Overvoltage Check

................................
................................
................................
................

8

Circuit Breaker Evaluation

................................
................................
................................
.....................

8

Process View

................................
................................
................................
................................
.................

9

Generic Process Diagram

................................
................................
................................
..........................

9

Process Diagram for a Specific Scenario

................................
................................
................................
.

10

Non
-
functional view

................................
................................
................................
................................
....

12

Constraints

................................
................................
................................
................................
..................

13

Technology Lis
t

................................
................................
................................
................................
.......

13

Relevant Standards

................................
................................
................................
................................
.

13

File and Message Formats

................................
................................
................................
......................

13

Timings

................................
................................
................................
................................
....................

13

Principles

................................
................................
................................
................................
.....................

14

Logical View

................................
................................
................................
................................
................

15

Interface View

................................
................................
................................
................................
.............

17

Design View

................................
................................
................................
................................
.................

18

RATC Optimization Algorithm

................................
................................
................................
.................

18

Switching Stability Check

................................
................................
................................
........................

21

Switching Overvoltage Check

................................
................................
................................
..................

22

Cascading Event Detection

................................
................................
................................
.....................

23

Circuit Breaker Operation Evaluation

................................
................................
................................
.....

25

Relay Settings Adjustment

................................
................................
................................
......................

27

Me
asurement and Model Data Integration

................................
................................
............................

28

Infrastructure View

................................
................................
................................
................................
.....

30

Deployment View

................................
................................
................................
................................
........

31

Operational View

................................
................................
................................
................................
........

32

Security View

................................
................................
................................
................................
..............

33

Data View

................................
................................
................................
................................
....................

34

Data Flow

................................
................................
................................
................................
................

34

Model Data

................................
................................
................................
................................
.............

38

Measurements

................................
................................
................................
................................
........

38

Simulated vs. Field Data

................................
................................
................................
..........................

38

Tech
nology Selection

................................
................................
................................
................................
..

39

Operating System(s)

................................
................................
................................
................................

39

Programming Languages

................................
................................
................................
.........................

39

Databases

................................
................................
................................
................................
................

39

Network

................................
................................
................................
................................
..................

39

Other

................................
................................
................................
................................
.......................

39

Appendix
-

Acronyms

................................
................................
................................
................................
..

40




Introduction

To be added later.

I
t would be good to include a docucment purporse.

Need to highlight that there are two key
functional modes



Day
-
ahead



Next
-
hour

Need to highlight that two architectures
must be defined



Development/Design/Test



Production


(It’s important to have a chrisp vision of production as development/test is constructed.)

We think
t
here are three high level

layers

to the architecture


and components are specified within this
document for each.



Data



Analytics



User Interface


Human inputs and outputs

We think the data comes in
at least 4
distinct classes.
Understandably we’re
most interested in the
measurem
ent data layer


so
, we’ll drill into that.

From this measurem
ent and state data,
RATC will b
e able to
consume information o
n the current
operating point

of the electrical network.

Measurement and state data are required for the
“next
-
hour” process along
with planning data


planned load, planned interchange, etc.

For the “next
-
day” process, measurement and state data is not
required.

1.

Measurement and state data

(Data shown can be provided, all may not be necessary)

a.

Real
-
Time

(Estimated and Measured)

i.

Line
/Bus
power flow, current, voltage and phase angle

ii.

Generator output

iii.

Major Loads

iv.

Breaker State

v.

Transformer Tap Setting
s

vi.

Tie
-
Line Flows

b.

External RATC

Triggers
(potential)



Data Source, EMS, SE and Relays

i.

Loss of Generation

ii.

Line Trip

iii.

Loss of Load

iv.

Elements with Failed N
-
1 Contengency

v.

dF/dt

c.


Historical
Data (high
-
granularity historican data,
available very soon after event)

i.

DFR

ii.

PMU

iii.

PQ Meter
s

iv.

Relay
s / IEDs


2.

Planning Data


a.

Generation Outages f(t)

b.

Transmission Outages f(t)

c.

Transmission Schedules f(t)


Wheeling

d.

Load Forecast

f(t)

e.

Off
-
s
ystem Sales & Purchases

f(t)


3.

Electrical Network
Model Data

(including generation assets
, load distribution factors, among
other

parameters.
)


4.

RATC

Configuration Data


THE COMPONENTS

We think the introduction should outline the
system
components

and the document drill into each.

The function of the GPA component is to make
measurement and state data available to all other
project components.

We strongly recommend that this be a specifically identified component in the
project.


5.





Context

View

Big picture
, context

discussion
, RATC vs. “external world”



Figure 1.
Context V
iew

of the RATC Solution

We think that this diagram should be replaced with a new high
-
level diagram. It would show the
relationship of RATC architectgural comonents.






Functional View

This section introduces
architecture
-
significant use case
s, their relationship and top view.

It also
discusses why these use cases are

important for the architecture, what
the system actually does,
and
what the key functional users are.

Key Functional Users



Operators



Protection



Maintenance


Top View




Figure 2. Architecture
-
significant Use
Cases


Note: dashed arrow means “depends on”

relationship


Significant Use Cases

The architecture significant use cases are briefly described in the following subsections.

Renewable Generation Loss

In the event of loss of renewable generation, the operator

wants to use RATC optimization algorithm to
minimize load shedding.
This is possibly the most time
-
critical situation.

Cascading Event Mitigation

Once a cascading event is detected, the operator wants to use RATC optimization algorithm to minimize
load sh
edding.

Malicious Attack Mitigation

Once a malicious attack is detected, the operator wants to use RATC optimization algorithm to minimize
load shedding. From RATC perspective, the malicious attack is interpreted as loss of availability to use
certain line
s

for switching
.

Think that this use
case should be generalized

to

unforecast loss of assets



could
be a tornado or
could be the result of hostile action.

Cost
-
based Optimization (Market
-
based

optimization
)

Base on given generator and load data, the
operator wants to use RATC optimization algorithm to
perform cost
-
based optimization. This use of RA
TC algorithm may not be as time
-
critical as the other
cases above.


Minimize Generation Cost

The RATC solution uses a given

objective function that minimize
s generation cost.


Minimize Load Shedding

The RATC solution uses a given

objective function that minimizes load shedding (minimizes demand not
met).

Optimization Algorithm

The RATC solution uses given

static model data, branch availability, and objective
function

to perform
the optimization
. Additional input to the algorithm may be a time
-
frame in which the results are
needed.

Cascading Event Detection

The RATC solution uses this module to continuously monitor
disturbance
s i
n the system

for the
possibility of cascading

event. If a cascad
ing

event occurs then the information about lines switched off
due to false tripping will be reported.

Relay Settings Adjustment

The RATC solution will
re
-
compute

new relay settings

for the anticipated l
ine switching actions from
RATC
optimization
algorithm. Information about the relays
needed to
be updated and the new settings
(
Zones 2 and 3) will be reported to the operator and protection.

Switching Stability Check

For all the anticipated switching act
ions from RATC algorithm a Transient and small signal stability check
will be performed. Unstable swi
tching actions will be reported to the operator.

Switching Overvoltage Check

EMTP studies will be carried out to evaluate the switching over voltages that
may result due to switching
actions of RATC. The switching actions which can impact insulation will be reported to the operator and
protection.

Circuit Breaker Evaluation

Circuit breakers will be monitored for assessing their suitability for switching. Br
eakers not suitable for
switching will be reported in a form of line availability update. If the maintenance of the breaker is
needed the maintenance group will be notified.


Question1: Do we need a topology processor that is a part of RATC solution?

Quest
ion2: How fast the topology update needs to be (is SCADA topology processor OK)?



Process View

The process view e
xplain
s

what the system does at a high level,
its
main processes and flow of
information
.

Generic Process Diagram

Should be a decription of
the

data source that drives each of the these processes


They all seem to
work but the one for “
attack” which seems to not be an independent process but a subset of loss of
generation or loss of transmission.

Also think the titles of these boxes should be

parallel in structure.



Figure 3. Process Activity Diagram

for
the
RATC Solution



Process Diagram for a Specific Scenario



Figure 4. Process Activity Diagram for
Cascading Event
Scenario


Note:

o
ther scenarios follow the same logic (no need for
additional dia
grams)



Non
-
functional view

P
lace to relist the important non
-
functional requirements, especially the ones that are significant to the
architecture
.


Possible c
andidates:



File formats and conventions



External
dependencies





(
to

be added later)

Note:
communication dis
cussion may be included here




Constraints

T
ime and budget (if applicable), approved technology lists and technology constraints, local and public
standards, standard protocols, message formats, …

Technology List



Op
erating Systems:

Windows, Linux



Programming Languages: Pyomo (Python), Java, C#/C++
, Matlab?



Super computing?




Relevant Standards



IEEE C37.111
-
1999, IEEE Standard Common Format for Transient Data Exchange (
COMTRADE
)
for Power Systems



IEEE C37.232
-
2007,
IEEE Recommended Practice for Naming Time Sequence Data Files



IEEE C37.232
-
2011 (Revision of IEEE Std C37.232
-
2007), IEEE Standard for Common Format for
Naming Time Sequence Data Files (COMNAME).



IEEE C37.239
-
2010, IEEE Standard for Common Format for Event

Data Exchange (
COMFEDE
) for
Power Systems



PQDIF?



C37.
118.1
-
2011, IEEE Standard for Synchrophasor Measurements for Power Systems



C37.118
-
2005, IEEE Standard for Synchrophasor Measurements for Power Systems



IEC
61850
, Substation Automation



IEC 61970, Common

Information Model (CIM) / Energy Management



IEEE C37.238
-
2011, IEEE Standard Profile for Use of IEEE 1588 Precision Time Protocol in Power
System

Applications



IEEE 1588?




File and Message Formats



Model data



EMTP/ATP file formats




Timings






Principles

L
ist
of
important architectural principles (layers, use of frameworks and libraries, design patterns and
templates, error handling,
logging …)


Main architectural principles:



Louse Coupling



each component, software module that is part of RATC solution, sh
ould be
designed and implemented as independent as possible. Whenever possible, the components
should be designed as stand
-
alone applications with clear specification of the input and output
data formats.



Data Format Unification



all of the information ex
changed between the solution components
should utilize uniform and standardized formats and data structures. All of the data of the same
type should be used and kept in desired pre
-
selected data format.



Dependency



each component, whenever possible, shoul
d be designed with minimal
dependency on other RATC components, but also on third
-
party software packages.

(more
to

be added later)


This section is great ! Having a common design philosophy is critical.





Logical View


B
ig picture again

(“from 30,000 feet”)
, the connection between the system components, high
-
level
.



Figure 5. Logical View Diagram: System Components Interconnection

This document
is not going to very valuable to GPA

unless our work
can be

identified as a
stand alone
comp
onent.
Therefore, w
e would like to see “Measurement and State
” data shown sperately.



Question1: Which component will be installed at the substation level (Substation RATC)?

To be
discussed in the physical architecture.

Question2: Can all of these
components reside in a centralized location (if not, what are the benefits or
disadvantages)?



Interface View


R
elated to logical level, key communication messages, databases, external APIs,
asynchronous/synchronous,


(can be added later, relevant to the

logical view)




Design View

M
ore detailed look at the system: detailed use cases, used technologies, use of common patterns across
the system, UML class and sequence diagrams if needed, other information that may not be well
documented inside the code it
self.

As identified earlier in Figure 5, the main components of the RATC solution are:

1.

RATC Optimization Algorithm

2.

Switching Stability Check

3.

Switching Overvoltage Check

4.

Cascading Event Detection

5.

Circuit Breaker Operation Evaluation

6.

Relay Settings Adjustmen
t

7.

Measurement and Model Data Integration

The following sections provide
more details on each component.

RATC Optimization Algorithm

RATC Optimization Algorithm module will be using software CPLEX

(Fig. 6)
. The optimization algorithm
solves for candidate sw
itching actions based on the given static model data, current state, and line
availability.

Not sure it is good style to

comingle stat
ic

and dynamic data
in one flow
.
The four unique dimensions of
input should follow the data dimensions of


Model,

Planni
ng, Measurement, and Application (Objective
Function).


Figure 6. RATC Optimization Algorithm Component

Again, don
’t think it’s good form to overload these arrows. What’s the consuming process for
“sequence and generation patterns”

That

the I/O architecture for the algoritym component is file
-
based is a critical architectural statement
and should be reflected in the Figure 6.

No problem drawing in real
-
time data from the EMS. However,
I’m confused on the data flow needed
from the “topo
logy processor”

itself.

It would seem that these analytics need to be topology aware as
derived from breaker state or forecas
t

line
and generation
status.




The code will be written in Pyomo
, Python, or C++ and the solution will call CPLEX solver. Currently, the
code is being developed in Pyomo.

Pyomo reads input data, Pyomo shell calls CPLEX, Pyomo receives solution form CPLEX, and Pyomo
prints the output to an external file. This file is ca
lled by a shell program that sends it to an AC power
flow and a stability check routine. Once the action passes these stages, this shell program sends the
suggested decision action (e.g., line switching) to the control screen and the operator. Such a shell

program is to be developed by commercial entities post ARPA
-
E project.

The RATC optimization routine
will depend on the information collected from the state estimator and the topology processor, which
will determine the current status of the network (powe
r flow information, generator dispatch and
availability, and topology status). This dynamic data will be used in combination with the typical static
network model and generator information.

Main Users

The RATC
optimization algorithm
is primarily used by th
e system operator.

Triggers

The RATC algorithm may be initiated based on triggers such as network constraint violations. Primarily,
we envision it being triggered manually by the operator.

Not sure that this is the right vision for a
production applicatio
n


but
certainly works fine for test and development.

This is based on the application: anytime there is an N
-
1 event, anytime there is a constraint violation in
the network, when there is a cascading event.

Please n
ote that the periodicity of running t
he RATC algorithm does not mean that the switching actions
are happening at the same frequency as the RATC concept is a decision support tool and it can be used
to provide continual suggestions to system operators in the event that something occurs, e.g.,
a
contingency, but that does not mean that the corrective action is implemented.

Input Data

Input data includes: network topology

?? breaker state
, generator information and availability, load and
renewable forecasts, hydro scheduling

(interesting


will RATC treat hydro as a special scheduling case
realitive to

other generation scheduling
. Is the intent for RATC to recommend changes in generation
schedules
for quick response
generation

(secondary reserves)
in combination with line s
withing?
)
, state
estimation information, real
-
time generator status and availability, and topology processor
??
.

and
interchange and transmission schedules.

Input data is expected to be provided in a text file (i.e. ASCII or XML).

For now, we’ll assume
a
well
-
structured

XML file for measurement data
. It creates a lot of churn pre
-
position these files just in case it
might be time for RATC to run. Therefore, we
’ll also assume that we’ll get a trigger from some source
to produce these files.

So that th
e interface can follow the file
pattern,

we
’ll watch for a file at a
configurable location (UNC)
to pvoide us notice to d
rop produced measurement files in confiruable
directories (UNCs). Mutiple directories since other RATC components may need access to t
his same
time slice of data and the trigger will distribute data one or more locations where it is needed for
processing.

There will be no specific API. The input data will be provided in the form of file exchange.

Output Data

The output data from RATC Opt
imization Algorithm (implemented in Pyomo) will go to the
Switching
Overvoltage Check

and
Switching Stability Check
. Once the suggested decision action is verified, it will go
to the system operator. There is no closed loop for the RATC algorithm. RATC is
a decision support tool.
It will provide suggestions to the operator. It is up to the operator to implement the action.

The output data will contains list of the lines to be switched together with the switching sequence and
generation patterns.


Performance/Periodicity

The RATC optimization routine will have different computational times based on application. We expect
the execution times to vary from ASAP to 30 minutes. This will be defined later with the research, per
application.

For now, it i
s primarily something that will be initiated by an operator based on events. This will be
refined later with the research.

Remarks

For high performance computing application there will be a need to utilize
supercomputing

configuration.


Switching Stability

Check

Switching Stability Check module performs a feasibility analysis to determine stability for the proposed
line switching.


Figure 7. Switching Stability Check Component

Main Users

Switching Stability Check module is to be used by system planners
and operators.

Triggers

This software module is run whenever a line switching is being proposed by the RATC optimization
algorithm.

Input Data

Input data includes the model data (line data, bus data), loading, and proposed line switching.

The input data fo
rmat could be PSSE or PowerWorld, or preferably the same text file format that will be
used by the RATC algorithm (if we assume that the conversion from third
-
party formats to a unified
format will be implemented).

Interesting. As a bus
-
branch load flow
model

inputs are not breaker state but planning data that show
line outages as f(t)


typically

hourly.

Is the plan to run this tool next hour
as well as

day ahead?

If run next hour, the classic approach is to use next hour planning data (a line might be scheduled to
come back
into service) and trump it by removing lines that currently out of sevice.

Output Data

The output data includes approve or disapprove (ok/not o
k) information for the proposed switching.

The format is yet to be decided.

Performance/Periodicity

We expect the execution times to vary from ASAP to 30 minutes. This may be adjusted later in the
project.

The module execution is event based and it the sta
bility check is performed every time the RATC
algorithm proposes a switching.

Remarks

None.


Switching Overvoltage Check

Switching Overvoltage Check module will assess the switching overvoltage caused by the proposed
transmission line switching.



Figure
8. Switching Overvoltage Check Component

Main Users

The main users of the switching overvoltage check module are the system.

Triggers

This software module is run whenever a line switching is being proposed by the RATC optimization
algorithm.

Input Data

Inp
ut data includes the model data (line data, bus data), loading, and proposed line switching.

The input data format could be PSSE or PowerWorld, or preferably the same text file format that will be
used by the RATC algorithm (if we assume that the conversio
n from third
-
party formats to a unified
format will be implemented).

Output Data

The output data includes approve or disapprove (ok/not ok) information for the proposed switching. For
each switching action, the output will also contain the estimated overvo
ltage. This information can
potentially be used by system operators and protection group to support the decision making process.

The format is yet to be decided.

Performance/Periodicity

We expect the execution times to vary from ASAP to 30. This may be adj
usted later in the project.

Remarks

This module will depend on the execution of EMTP/ATP
simulation
.

CB data to be assumed, obtained from CB manufacturer, or from CB monitoring evaluation module.

EMTP model to use distributed parameters model or frequency
dependent model, not decided yet.


Cascading Event Detection

Cascading Event Detection module determines which transmission assets that are currently out of
service due to a cascade switching are actually “healthy” and hence candidate to be placed back in
to
service. The module provides us with the cascading event detection, list of switched lines and
assessment which lines are faulted and which are incorrectly switched out. The module also performs
fault location calculations.

There are two main components

of the system:



System
-
wide monitoring and control


computes vulnerability

indices for power system
components. Vulnerable elements identified and associated relays closely monitored.



Local monitoring and control
-

i
nitiates when triggered by a relay trip

signal. Provides detailed
information about disturbance and relay operations for each related local substation: a) neural
network based fault detection and classification (NNFDC): provides a more accurate fault
detection and classification by using the sa
me data inputs as distance relay, and b) synchronized
sampling based fault location (SSFL): provides a very high accuracy in fault location using data
from two ends of the line.


Figure 9. Cascading Event Detection

Main Users

Main users of the systems are

the system operators and protection.

Triggers

The execution is triggered by relay trip or occurrence of the event/fault records.

The module runs continuously.

Input Data

It utilizes model data and event records collected in the substations (DFR, DPR).
Bas
e case system model
is required (power flow system specification data, eg. PSS/E .raw file). Sequence impedance data is also
required. Topology changes & SCADA measurements (loads, generations, flow, and breaker statuses)
required for system level monitori
ng.

Event records from DFRs and DPRs from both ends of a line which was tagged as vulnerable. Event
records are expected to be in COMTRADE file format.

Output Data

The output data contains: detection of the cascading event, line availability update (info
rmation if the
line is faulted or not), fault location for faulted lines.

The

output

format to be provided later.

Performance/Periodicity

We expect the execution to be ASAP as soon as the data is available. However, the cascading event
keeps evolving and t
he execution will continue with inclusion of newly available data.

The system
-
wide vulnerability function is continuous. The local event
-
based function is triggered by
relay trip (new event records occurrence).

Remarks

The module utilizes neural networks.


The module is implemented in MATLAB (Octave), and is expected to be implemented in Java.

The test data will be created using EMTP/ATP simulation.


Circuit Breaker Operation Evaluation

Circuit Breaker Operation Evaluation module assesses the health conditions of the circuit breaker, and
recommend whether the specific breaker is suitable for switching or needs maintenance. This output
maps into the line availability update and maintenance

reports.


Figure 10. Circuit Breaker Operation Evaluation

The software module develops circuit breaker control signals and exact timings of each signal parameter
using its internal signal processing. Then, it analyzes the relationship between the parame
ters using
scatter plots and fits probability distribution to each parameter.
This information is used to determine
performance indices which are used to assess the health condition of the breakers.

Main Users

Main users of this module are the system oper
ators and maintenance group.

Triggers

The module is triggered by a circuit breaker operation (open/close).

Input Data

The input data includes event records coming from circuit breaker control circuit monitoring. These
records include analog and digital sig
nals representing phase currents and internal logic signals (A/B
contact, X/Y contact, trip, …).

The module also uses its internal history of control circuit recordings and condition
-
based circuit breaker
data.

Output Data

The output data is mapped into th
e line availability update (which lines can are available for switching).

The output also include a maintenance report directed at the circuit breaker maintenance staff.

Performance/Periodicity

We expect the execution to be ASAP as soon as the data is avai
lable.

The monitoring and processing of newly collected circuit breaker monitoring events is continuous.

Remarks

Depends on monitoring of circuit breaker control logic circuits.





Relay Settings Adjustment



Figure
11
. Rela
y Settings Adjustment

Main
Users

Main users are the system operators and protection.

Triggers

The execution of this module is initiated every time the RATC algorithm calculates/proposes a switching.

Input Data

Input data includes the model data (line data, bus data), loading, and pr
oposed line switching.

The input data format to be defined later.

Output Data

The output data contains adjustments for relay settings (Zone 2 and Zone 3).

The output data format is not yet defined.

Performance/Periodicity

We expect the execution to be ASAP as soon as the RATC algorithm proposes the switching.


Remarks

Question 1: What is u
se of current
/existing

relay settings
?

Question2: Is there a need to interface to CAPE or similar program
?


Measurement and Model Data
Integration

The measurements and model data integration module will provide RATC operational data layer. The
key data needed for proper operation of the RATC solution include model data, current state updates,
and event records. Majority of the RATC softwa
re modules use model data (static and/or dunamic),
current state updates (based on SCADA scans, state estimator, topology processor), and event
-
based
records collected from substation IEDs such as DFRs, DPRs, or CBRs.

The idea is to utilize a data integrat
ion layer based on GPA’s openHistorian product that will be
customized to accommodate RATC requirements.

It is desired that the data layer provides for standardization and unification of the formats used by all of
the modules in the RATC solution.




Figu
re 12. Measurements and Model Data Integration


Main Users

Main users of this module are expected to be other software components of the RATC solution.

Triggers


Input Data


Output Data


Performance/Periodicity

We expect the execution to be ASAP as soon as

the data is available.

The monitoring and processing of newly collected circuit breaker monitoring events is continuous.


Remarks




Infrastructure View

P
hysical architecture, hardware, redundancy (if needed) and failover, sizing the hardware components,

networks, routers, switches, ownership of the resources…

(communication input may be used here)

(selected hardware for deployment)



Deployment View


H
ow will software components be deployed across the hardware components, scaling, operating
systems, depl
oyment platforms…

(
to
be added later)




Operational View

A
bility to monitor and manage the system, installation, updates, logs …

(
to

be added later)



Security View

A
uthentication, authorization, different types of users and user roles, restricted access,

encryption, …

(
to be added later
)



Data View

D
ata flow, formats, archiving, backup, regulatory requirements…

Data Flow


Data Flow Diagram Notation



Figure 13. Data Flow Diagram Notation

RATC Solution (Top Level)



Figure 14
. Data Flow for RATC
Solution (Top Level)

What
’s the vision for “decision support” with the operator
directly
vs.

through

EMS.




RATC Optimization


Figure

15
. Data Flow for RATC Optimization

Switching Overvoltage/Stability Check


Figure 16
. Data Flow for
Switching
Overvoltage/Stability Check


Cascading Event Detection


Figure 1
7
. Data Flow for Cascading Event Detection

Circuit Breaker Operation Evaluation


Figure 18
. Data Flow for Circuit Breaker Operation Evaluation

Relay Settings Adjustments



Figure 19
. Data
Flow for Relay Settings Adjustment


Measurements and Model Data Integration



Figure 20
. Data Flow for Measurements and Model Data Integration


Model Data


Measurements


Simulated vs. Field Data



Technology Selection


I
s it clear what technology was sele
cted, other options and why were the
y

not chosen, compatibi
lity
with the selected hardware…


Operating System(s)



Linux



Windows

Programming Languages



Python/Pyomo



Matlab/Octave



Java



C# (GPA openHistorian)

Databases




Network




Other







Appendix
-

Acronyms


ATP


Alternative Transients Program

CB


Circuit Breaker

CBM


Circuit Breaker Monitor

CBR


Circuit Breaker Recorder

CCDC


Control Center Data Concentrator

CIM


Common Information Model

DDR


Digital Disturbance Recorder

DFD


Data Flow Diagram

DFR


Digital
Fault Recorder

DNP


Distributed Network Protocol

DPR


Digital Protective Relay

EMS


Energy Management System

EMTP


Electromagnetic Transients Program

FERC


Federal Energy R
egulatory Commission

GPS


Global Positioning System

IEC


International
Electrotechnical Commission

IED


Intelligent Electronic Device

IEEE


Institute of Electrical and Electronic Engineers

IP


Internet Protocol

ISO


Independent System Operator

LAN


Local Area Network

NERC


North American Electric Reliability Corporation

NTP


Network Time Protocol

PDC


Phasor Data Concentrator

PMU


Phasor Measurement Unit

QoS


Quality of Service

RATC


Robust Adaptive Topology Control

RTU


Remote Terminal Unit

SCADA


Supervisory Control and Data Acquisition

TCP


Transmission Control Protocol

TSO



Transmission System Operator

UDP


User Datagram Protocol

UML


Unified Modeling Language

XML


Extensible Markup Language