Jay Britton jay.britton@areva-td.com

3
 The members of an interconnection share a mutual necessity to achieve:

Accurate assessment of grid reliability.

Appropriate, timely response to insecure conditions.
 A pre-requisite to the above are:

Accurate, up-to-date network models.

Consistent network models (at each responsible site).
 In an interconnection, this requires:

Exchange of models.

Exchange of solved analytical results.
 2008 NERC Real-Time Best Practices Report:
 “Although defining the elements represented in internal network models is relatively straightforward, the task force finds that defining the elements to be represented in external models is much more complex.”
 “Issue #5: External Modeling and Data Exchange Practices Should be Improved by
Explicit Reference to the Definition of the Wide-Area-View Boundary. A consistent, uniform set of modeling and data exchange practices, procedures, and standards are needed to support creation and maintenance of accurate external models…”

These requirements apply in real-time, near-future and longterm time frames.
3

4

Basic Modeling:

Each TSO is the authority for its own territory.

Each TSO exports its internal model to its neighbors and/or regional authority, and keeps it up to date.

Regional authorities assemble internal regional models from member TSO internal models.

(Sometimes reducing unnecessary parts.)

All parties assemble external models from the internal models of other sites.

Analysis:

Responsibility may be distributed among cooperating sites.

Solution exchange is required, depending on the problem.

Exchanged solutions should be based on consistent underlying models.

These goals apply to both operations and planning.

Operations focus is on as-built and near future changes.

If operations and planning share the same as-built base model, then the planning focus is on exchange of plans.
4

5
TSO 1
EMS
TSO 2
EMS
TSO n
EMS
TSO 1
TSO 1
Internal Model
Plans
TSO 1
External Model
TSO 2
TSO 2
Internal Model
Plans
TSO 2
External Model
TSO n
Internal Model
TSO n
Plans
TSO n
External Model
Assembly of full primary model
Creation of derived target models
Derived Model
Interconnection
EMS
PRIMARY
Interconnection
Model
Derived Model
Interconnection
Planning
5

6
 Exchange of network models.

EMS A and B are neighbors in an interconnection and therefore each needs to represent the other as part of its external model.

Requires exchange of internal models.

Scope is limited to network data and measurement placements.

Common Modeling Source between planning and operations.

One modeling application for the enterprise.

An EMS requires a model that covers any point in time.
 Other targets require data for a specific “case”.
 Exchange of solved cases. Several variations…

Real-time exchange among different applications.

Real-time cases to study or planning.

Exchange of study or planning cases between different tools.

Import of study cases to EMS.

UCTE Day-Ahead.

Study cases are generated for the next day by each TSO representing the expected state of their internal network.
6

7
Partition by Object Instance according to Model Authority
Regional
Model Authority
Bndry
MA
Regional
Model Authority
Bndry
MA
Regional
Model Authority
State
Variables
State
Variables
State
Variables
Topology
Equipment
Model
Global
MA
Topology
Equipment
Model
Common Objects
Topology
Equipment
Model
7

8
The initial CIM model exchange (61970-452) standard focused only on transfer of complete models:
CIM Exchange
(full, partial, incremental update)
CIM import / export
System B
Import Model
Proprietary / Home grown
Extract / Merge Tools
System A
Local Vendor
Model
A Internal Model
A’s model of B a
System A EMS
CIM import / export
System A
Import Model
Proprietary / Home grown
Extract / Merge Tools
System B
Local Vendor
Model
B’s Model of A
B Internal Model
System B EMS b
8

9
9

10
1.
Initialization of a consistent primary interconnection model.


Mutual agreement as to which party is the master authority for each region of the model.
Mutual agreement on boundary points.
2.
Maintenance of the primary interconnection model by constituent model authorities.


Repeatable merge.
Preferably employing incremental updates.
3.
Derivation of operating and planning models from the interconnection model.
 Download of external models
– extraction.

Merge with internal for analytical case formation.
10

11

Each object is in one and only one set.

Simple labeling technique for assigning responsibility.

Associations connect some objects that are in different sets.
 Currently directional from n to 1 (“foreign key” convention)
– under discussion.
 Regional Sets:

No associations with other regional sets.

External associations to boundary sets only.

Boundary Sets:

External associations from regional sets.

External associations with other boundary sets.

A regional set may be referentially validated independent of other regional sets.

Modeling processes can proceed independently in each region.

Goal:

Maximize independence.

Design boundary sets to achieve:


Minimum data
Infrequent change
Model Authority Set
A
A-B boundary
MAS
Model Authority Set
B
Model Authority Set
C
11

12
A Region Substation C Region Substation
Tie Line Mid-point
Tie Line
BB
Model Authority Set
A
GEO= ’A’
T
ST ’X’
CN
T
T
T
T
T
CB CB CB
T CN T LS T m
A-C
Boundary
Set
LN= ’X-Y’
CN
Model Authority Set C
BB
GEO= ’C’
T
ST ’Y’
CN
T LS T CN
T
T
T T
CB CB CB
T T
12

13
C Region Substation
Tie Line Metering Point
A Region Transmission Line m
Model Authority Set
A
GEO= ’A’
T
LN
LS T
A-C
Boundary
Set
CN
Model Authority Set C
BB
GEO= ’C’
T
CN
ST
T T T
CB CB CB
T T T
13

14
 Key modeling roles in an interconnection:

Model Authority

The official source of data for a particular part of the network.

Usually the TSO (Transmission System Owner/Operator)

Model Quality Broker (optional)

Arbitrates boundary definitions.

Receive model authority data.

Assemble a complete interconnection model.

Validate interconnection model.

Distribute updates to model.

End User

Uses the models for some operational or planning purpose.

Creates analytical cases.
14

15
Site A makes a change:
1.
A changes its
ModelAuthoritySet using its CIM modeller.
2.
A imports the change into its EMS.
3.
A exports the change to B.
4.
B receives the change (full or incremental), updating A’s
ModelAuthoritySet within its CIM modeller.
5.
B renames any new elements and repeats any reduction of A’s
ModelAuthoritySet.
6.
B imports the new model into its EMS.
CIM Modeler
Full
Interconnection
Model
System A Source boundary
System B Import
My B Region
(reduced & renamed) a
CIM/XML
Model Exchange
Interface
CIM Modeler
Full
Interconnection
Model
System A Import boundary
System B Source b
My A Region
(reduced & renamed)
CIM Translator A
EMS A
Proprietary Model Format
EMS at Site A
CIM Translator B
EMS B
Proprietary Model Format
EMS at Site B
15

16

Bottom level.

No significant differences.

Export changes as the model authority.

Import externals from the full interconnection model.

Upper level:

Manages boundary sets.

Creates the full interconnection model.
EMS at Upper Level Authority
EMS Upper Level
Proprietary Model Format
CIM Translator x
Reliability Model
Full
Interconnection
Model
System A Import boundary
System B Import
CIM Modeler
Full
Interconnection
Model
System A Source boundary
System B Import
CIM Modeler
Full
Interconnection
Model
System A Import boundary
System B Source

Model quality evaluation.

Study state estimation.

Derives operational model in the same manner as lower levels.

Different reduction criteria.

Design extends to any number of hierarchical levels.
My B Region
(reduced & renamed)
CIM Translator A
EMS A
Proprietary Model Format
EMS at Site A a b
My A Region
(reduced & renamed)
CIM Translator B
EMS B
Proprietary Model Format
EMS at Site B
16

17

Full interconnection model is the common source for all models.

Interconnection planning shown on diagram.

No procedural difference required to support analytical functions running at any level for any purpose.

Planning adds other requirements.

New information modeling in
CIM.

Accommodate busoriented apps.

Add short circuit, dynamics, etc.

Incremental model standard expands to model plans.

CIM modeling applications need to have a temporal axis.
 2007 EPRI “CIM for Planning” project.

Goal is eliminate duplication of modeling.
EMS at Upper Level Authority
EMS Upper Level
Proprietary Model Format
CIM Translator x
CIM Modeler
Full
Interconnection
Model
System A Source boundary
System B Import
My B Region
(reduced & renamed)
Reliability Model Planning Model
Full
Interconnection
Model
System A Import boundary
System B Import a b
CIM Modeler
Full
Interconnection
Model
System A Import boundary
System B Source
My A Region
(reduced & renamed)
CIM Translator A
EMS A
Proprietary Model Format
EMS at Site A
Planning System
Planning System
Proprietary Model Format
CIM Translator
CIM Translator B
EMS B
Proprietary Model Format
EMS at Site B
17

18
Model Authority 1
EMS
TSO 1
Internal Model
TSO 1
External Model
Model Authority 2
EMS
TSO 2
Internal Model
TSO 2
External Model
Model Authority n
EMS
TSO n
Internal Model
TSO n
External Model
PRIMARY
Interconnection
Model
Assembly of full primary model
Creation of derived target models
Name translation point
Regional
External Model
Regional
EMS
Name Registry
18

19
 The 61970-452 standard exchanged EMS models.
 Did not deal with planning (‘bus-branch’ models).

Did not support power flow solution exchange (or any other type of analytical result).

Several recent efforts defined other needed support.
 2007 EPRI ‘CIM for Planning’

2008 UCTE Day Ahead Congestion Analysis

2008-
2009 EPRI ‘CIM for Dynamics’
 2009 IEC WG13 Goals

Unify and formalize UCTE and CIM for Planning results:

Capture CIM changes in CIM14.
 Complete 61970-456 specification for Solved Power System State
Exchange.

Solidify building block concept for a family of standards.

CIM modularized by ‘profile data groups’.
19

20
Existing UCTE Process for Day-Ahead Congestion Analysis
 Daily Process:
1.
Each TSO constructs power flow cases representing the planned operation for each hour of the following day.
2.
Each TSO gets its neighbors cases and conducts congestion analysis studies focused on its own territory.
 Cases typically generated and analyzed with planning tools.

Case Format:

Power flow format unique to UCTE.

Bus-branch network topology.

Each case is a single point in time.



Load and generation values at each bus.
Specific targets for controls (regulated voltages, regulated flows).
Status of branches (in or out of service).
20

21
TSO
TSO
TSO
UCTE Model Server
TSO TSO
TSO TSO
TSO
My TSO
X-Node
List
Export my TSO Model to
UCTE Server
Market
Outcomes
My TSO’s Cases
for Export text
My TSO
TSO
Development
TSO TSO TSO
TSO
My
TSO
Model
Maintenance
Import neighbor TSOs from
UCTE Server
Merge
Analysis Model
TSO TSO TSO
TSO
My
TSO
21

22
 Equipment.

Identifies equipment and describes basic characteristics.

Connectivity.

Describes electrical connectivity that would be input to topology processing.
 Schedules.

Describes input to functions that derive parameters for a specific point in time.

Analogs.

The set of SCADA values for analog measurements for a particular point in time.
 Status.

The state of switches – input to topology processing.

Topology.

The result of topology processing. i.e. Description of how equipment connects into buses and how buses makeup connected systems.
 Scheduled.

This is the result of time scheduling to develop input for a case.

State.

This is the set of state variables used in the mathematical formulation that the algorithms work with.
22

23

In an EMS environment:
1.
A modeler supplies Equipment + Connectivity + Schedules to the EMS.
2.
Switch states and other parameters may be changed by telemetry or manual entry.
3.
The EMS code develops Topology + Scheduled data for the desired case.
4.
Manual override of the case input is allowed.
5.
Algorithm develops solved State.

In a planning environment:
1.
A ‘base’ version of case input is selected.
2.
Manual override of the case input is allowed.
3.
Algorithm develops solved State.

Both environments feed the same case data (Equipment +
Topology + Scheduled) into the solution applications.

Main question is how to address the different starting points.
23

24

Receivers of solved cases often need to recreate the case input.

Since there is normally the possibility of manual override of data, cases cannot simply be recreated from 452 static model data.

This means we need to define exchange of Topology + Scheduled data as well as State.

If we need to exchange Topology + Scheduled anyway,

A family of profiles are desired such that use cases may bypass Connectivity and Schedules where that makes sense.

Propose two standards:

Static Model Exchange

Solved Power System State Exchange

We should be able to construct profiles for all use cases from these.

EMS and planning.

Real-time and future.

Bus versus breaker detail.

State estimator and power flow.
24

25

Topology

TopologicalNodes (i.e. buses) in EMS represent the collection of
ConnectivityNodes that are connected by closed Switches -- the result of topology processing.
 Objective: don’t force Connectivity modeling if the usage only demands Topology.

Solution: establish direct relationships from Terminals to each.


Terminal  ConnectivityNode
Terminal  TopologicalNode

Scheduled

Scheduled data is essentially starting conditions for state variables
-- additional modeling is not required.
 State is modeled in a new collection of SV (state variable) classes.

State Variables profile data group may be used to present starting conditions, solved state or indeed, any set of values for state variables, depending on the business usage.
25

26
Equipment
+ [Connectivity]
+ [Schedule]
Ref (static model)
+ Topology
+ State Variables
26

27
SvVoltage
TopologicalNode
TopologicalIsland
SvPowerFlow
State Variables
SvShuntCompensatorSections
TSO Topology
Terminal (about)
GeographicalRegion
SubGeographicalRegion
Substation
VoltageLevel
ControlArea
ControlAreaGeneratingUnit
TieFlow
LoadResponseCharacteristic
MutualCoupling
CurveData
TSO Equipment Model
EnergyConsumer
PhaseTapChanger
PowerTransformer
RatioTapChanger
ReactiveCapabilityCurve
RegulatingControl
ShuntCompensator
Switch
SynchronousMachine
Terminal
ACLineSegment
SeriesCompensator
TransformerWinding
SvTapStep
OperationalLimitSet
CurrentLimit
VoltageLimit
FossilFuel
GeneratingUnit
NuclearGeneratingUnit
HydroGeneratingUnit
ThermalGeneratingUnit
WindGeneratingUnit
HydroPump
UCTE Common Objects
BaseVoltage OperationalLimitType
27

28
 TSO Equipment Model Files (by Model Authority Set)

Equipment


All equipment modeled by a given TSO.
-
Includes Terminal objects.
Switches only if they are to be retained in studies.
 Equivalent generator at X-nodes.

Regulating Control:

RegulatingControl targetRange for each voltage and flow control.

Topology Files (by Model Authority Set)

X-node Boundary File

TopologicalNodes at tie midpoints.

TSO Files

TSO TopologicalNode objects

Terminal ‘about’ objects
-
TopologicalNode association
-
Connected attribute indicates open/close end

State Variable Files (by Model Authority Set)

SvVoltage at TopologicalNodes

SvPowerFlow at GeneratingUnits, EnergyConsumer

SvShuntCompensatorSections and SvTapStep
28

29
A Region Substation
B Region Substation
Tie Line Mid-point m
Tie Line
UCTE Common Objects
T
TSO Equipment Model
LS T
T LS T
T
T a
T a
LS T
TSO Topology
T a
T a
T a
TN
EG T
T a
T a
BV
X-nodes
TN
T
TSO Equipment Model
LS T T LS T
T a
T a
T LS T
T EG
TSO Topology
T a
T a
TN
T a
T a
T a
FL
FL
FL
FL
V FL FL FL
State Variables
V FL FL FL
State Variables
V
FL
FL
FL
FL
29

30
Partition by Object Instance according to Model Authority
Regional
Model Authority
Bndry
MA
Regional
Model Authority
Bndry
MA
Regional
Model Authority
State
Variables
State
Variables
State
Variables
Topology
Equipment
Model
Global
MA
Topology
Equipment
Model
Common Objects
Topology
Equipment
Model
30

31
 Files

A business exchange contains 1-n files.

File bodies follow 61970-
552 except that some have “dangling associations”.

MRIDs are used as RDFIDs.

File naming convention TBD

Header references dependent files.

When multiple files are used to transmit a complete model – as defined by some CIM profile…

Files are zipped together.

Each XML expression of an object, association or attribute appears in one and only one file.

Associations are defined from the “many” end as with the existing 452 exchanges that have been interop tested.

Total profile transmission is the union of the file body contents.

A complete valid XML expression can be obtained simply by concatenating the RDF/XML in the file bodies.
31

32

Boundary Set Update

X-node boundary topology file
 Daily Base Model Submission

TSO equipment model file

Daily submission of hourly cases

TSO incremental equipment model (normally null)

TSO topology file (optional incremental)

TSO state variable file for each time point (solved)
 Complete Solved Studies

X-node boundary topology file

All TSO equipment model files

All TSO topology files

All TSO state variable files.
 Partial Updates

Send only changed files.
32

33
 61970-552

Allow dangling associations.
 RDF ‘about’.

File bodies and concatenation.
 File header conventions.

Either separate or in 552.
33

34
 Typically, 61970-456 users will need to add specific usage decisions for their exchange agreements.

Boundary conventions

Is there a model broker?

Naming

Slack variable treatment

EMS or planning or both?

File packaging.
34

35
 Business agreements are the essential (and often difficult) pre-requisite.

CIM examples already defined can help.

CIM has the flexibility to accommodate special requirements – requirements are not the same everywhere.
35