Upload
blaise-manning
View
221
Download
0
Embed Size (px)
Citation preview
A Family of CIM EMS Exchange Standards based on CIM/XML (71970-552)
- Static Network Model Exchange (61970-452)- Schematic Layout Exchange (61970-453)
- Solved State Exchange (61970-456)- EMS Static Model Update (proposed)
- Analog Measurement Set?- Status Measurement Set?
- Contingency Definition Update?- …
Jay Britton
3 3
The Basic Model Exchange Business Problem
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 long-term time frames.
4 4
There is high-level consensus about the right approach.
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.
5 5
Expanding the Use Cases
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 6
A Generic Model Exchange Business Process(ERCOT, WECC, …)
PRIMARY Interconnection
Model
Derived Model
TSO 1 External Model
Assembly of full primary model
Creation of derived target models
TSO 1 EMS
TSO 2 EMS
TSO n EMS
Interconnection EMS
TSO 1 Internal Model
TSO 2External Model
TSO 2 Internal Model
TSO n External Model
TSO n Internal Model
Interconnection Planning
Derived Model
TSO 1 Plans
TSO 2 Plans
TSO n Plans
7 7
Preview – We are working toward defining model partitioning into non-overlapping XML submodels that satisfy all of the use
cases.
Global Model Objects
Regional EMS Static Model
Bndry
Regional EMS Static Model
Regional EMS Static Model
Bndry
Partition by Object Instance using Model Authority Sets
Par
titio
n by
CIM
Sch
ema
Ele
men
ts
Sked
Conn
Common Objects
Display Layout
Equip Model
Sked
ConnDisplay Layout
Equip Model
Sked
ConnDisplay Layout
Equip Model
Solution
Measurements
Meas
State Variables
Topology
Measurements
Meas
Measurements
Meas
8 8
CIM Exchange(full, partial, incremental update)
The initial CIM model exchange (61970-452) standard focused only on transfer of complete models:
A Internal Model
A’s model of B
baProprietary / Home grown
Extract / Merge Tools
Proprietary / Home grown
Extract / Merge Tools
CIM import / export
System A Local Vendor
Model
System A Import Model
B’s Model of A
B Internal Model
System B Local Vendor
Model
System B Import Model
CIM import / export
System A EMS System B EMS
9 9
A More Desirable Process
CIM ModelerFullInterconnectionModel
CIM ModelerFullInterconnectionModel
EMS at Site BEMS at Site A
System A Source
System B Import
boundary
System B Source
System A Import
boundary
My A Region(reduced & renamed)
My B Region(reduced & renamed)
CIM Translator A
EMS AProprietary Model Format
CIM Translator B
EMS BProprietary Model Format
CIM/XMLModel Exchange
Interface
a b
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.
10 10
Merge/Extract with Model Authority Sets
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 SetB
Model Authority SetA
Model Authority SetC
A-B boundaryMAS
B-C
bou
ndar
yM
AS
A-C
bou
ndar
yM
AS
11 11
Typical North American Boundary
Model Authority Set C
A-C Boundary
Set
CN
Model Authority SetA
TT LS
A Region Transmission Line
C Region Substation
m
Tie Line Metering Point
T
T
CB
CN
T
T
CB
T
T
CB
T
BB
ST
GEO=’C’
LN
GEO=’A’
12 12
Typical UCTE Boundary
Model Authority Set CA-C Boundary
Set
CN
Model Authority SetA
T
T
CB
CN
Tie Line
C Region Substation
m
T
T
CB
T
T
CB
Tie Line Mid-point
A Region Substation
CN
T
BB
TLST
T
T
CB
CN
T
T
CB
T
T
CB
T
BB
TLSTCN
STST
GEO=’C’GEO=’A’
LN=’X-Y’
ST=’X’ ST=’Y’
13 13
Hierarchical Process Definition for an Interconnection
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.
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.
CIM Modeler
CIM ModelerFullInterconnectionModel
CIM ModelerFullInterconnectionModel
EMS at Site BEMS at Site A
System A Source
System B Import
boundary
System B Source
System A Import
boundary
My A Region(reduced & renamed)
My B Region(reduced & renamed)
CIM Translator A
EMS AProprietary Model Format
CIM Translator B
EMS BProprietary Model Format
a b
FullInterconnectionModel
System A Import
System B Import
boundary x
Upper Level Reliability Model
EMS at Upper Level Authority
CIM Translator
EMS Upper LevelProprietary Model Format
14 14
Consolidating Planning with Operations
CIM Modeler
CIM ModelerFullInterconnectionModel
CIM ModelerFullInterconnectionModel
EMS at Site BEMS at Site A
System A Source
System B Import
boundary
System B Source
System A Import
boundary
My A Region(reduced & renamed)
My B Region(reduced & renamed)
CIM Translator A
EMS AProprietary Model Format
CIM Translator B
EMS BProprietary Model Format
a b
FullInterconnectionModel
System A Import
System B Import
boundary x
Upper Level Reliability Model
EMS at Upper Level Authority
CIM Translator
EMS Upper LevelProprietary Model Format
Interconnection Planning Model
Planning System
CIM Translator
Planning SystemProprietary Model Format
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 bus-oriented 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.
15 15
The Naming Problem
PRIMARY Interconnection
Model
Regional External Model
TSO 1 External Model
Assembly of full primary model
Creation of derived target models
Model Authority 1 EMS
Model Authority 2 EMS
Model Authority n EMS
Regional EMS
TSO 1 Internal Model
TSO 2External Model
TSO 2 Internal Model
TSO n External Model
TSO n Internal Model
Name Registry
Name translation point
16 16
Roles in Model Exchange
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.
17 17
Adding Support for Analytical Processes
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’.
18 18
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).
19 19
Current UCTE Day-Ahead Process
text
text
text
TSO
X-NodeList
TSO
TSO TSO TSO
TSO My TSO
My TSO
Export my TSO Model to UCTE Server
Import neighbor TSOs from UCTE Server
Merge
Impo
rt a
ll T
SO
mod
els
to
UC
TE
Ser
ver
TSO
TSO
TSO
UCTE Model Server
My TSO’s Cases for Export
My TSO
Model Maintenance
text
TSO
TSO TSO TSO
TSO My TSO
My TSO’s Congestion Analysis Model
text
TSO
TSO TSO TSO
TSO My TSO
Market
Outcomes
Next Day’s Case Development
20 20
Requirements AnalysisData Modularity
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.
21 21
Requirements Analysis
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.
22 22
Requirements Analysis
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.
23 23
CIM Design
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.
24 24
IEC Static Model Exchange Profile (61970-452)
Equipment
+ [Connectivity]
+ [Schedule]
Ref (static model)
+ Topology
+ State Variables
IEC Solved State Exchange Profile (61970-456)
25 25
Solved State
Metadataby
File Type
State Variables
TSO Topology
TSO Equipment Model
ACLineSegment
ControlArea
CurrentLimit
CurveData
EnergyConsumer
FossilFuel
GeneratingUnit
GeographicalRegion
HydroGeneratingUnit
HydroPump
MutualCoupling
NuclearGeneratingUnit
OperationalLimitSet
PhaseTapChanger
PowerTransformer
RatioTapChanger
ReactiveCapabilityCurve
RegulatingControl
SeriesCompensator
ShuntCompensator
SubGeographicalRegion
Substation
SvPowerFlow SvShuntCompensatorSections SvTapStepSvVoltage
Switch
SynchronousMachine
Terminal
Terminal (about)
ThermalGeneratingUnit
TieFlow
TopologicalIsland
TopologicalNode
TransformerWinding
VoltageLevel
VoltageLimit
WindGeneratingUnit
UCTE Common Objects BaseVoltage OperationalLimitType
ControlAreaGeneratingUnit
LoadResponseCharacteristic
26 26
Profile Specification – File Types TSO Equipment Model Files
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 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 SvVoltage at TopologicalNodes
SvPowerFlow at GeneratingUnits, EnergyConsumer
SvShuntCompensatorSections and SvTapStep
27 27
Partitioning into Files by TSO
TSO Equipment Model
TSO Topology
TSO Equipment Model
State Variables
X-nodes
TN
TSO Topology
TN
Tie Line
B Region Substation
m
T TLS
T TLS
Tie Line Mid-point
A Region Substation
TLST
TN
TLST
T TLS
T TLS
State Variables FL
FLFL FLV VFL
FL
FL FL FL
FL
FL
TaTa
EG T
Ta
Ta
Ta
EGT
Ta
Ta
FL
FL
FL
Ta
Ta
Ta Ta
Ta
Ta
Ta
UCTE Common Objects BV
28 28
Complete View of Partitioning Into Files
GlobalMA
Regional Solved Case
Equipment Model
Topology
State Variables
Xnode
RegionalSolved Case
Equipment Model
Topology
State Variables
RegionalSolved Case
Equipment Model
Topology
State Variables
Xnode
Partition by Object Instance using Model Authority SetsP
artit
ion
by
CIM
Sch
em
a E
lem
en
ts
Common Objects
29 29
UCTE Interconnection Solution
GlobalMA
Regional Model
Equipment Model
Topology
Xnode
Regional Model
Equipment Model
Topology
Regional Model
Equipment Model
Topology
Xnode
Partition by Object Instance using Model Authority SetsP
artit
ion
by C
IM S
chem
a E
lem
ents
Common Objects
Global SolutionState
Variables
30 30
Dependency Relationships to be
Expressed in Headers
Equipment Model
TopologyState
VariablesCommon Objects
C1 S1T1E1
E1.1
T1.1
T1.2
T1.3
S10
S9
S8
S7
S6
S5
S4
S3
S2
S12
S11
31 31
61970 Profile Data Groups
61970-xxx Profile
61970-452Profile
Equipment Model
61970-456 Profile
Topology
State Variables
61970-453 Profile
Schedules
Connectivity
Schematic Layouts
Measurement Set
Measurement Specifications
32 32
Partitioning of EMS Static Model
Global Model Objects
Regional EMS Static Model
Bndry
Regional EMS Static Model
Regional EMS Static Model
Bndry
Partition by Object Instance using Model Authority Sets
Par
titio
n by
CIM
Sch
ema
Ele
men
ts
Sked
Conn
Common Objects
Display Layout
Equip Model
Sked
ConnDisplay Layout
Equip Model
Sked
ConnDisplay Layout
Equip Model
33 33
Partitioning of EMS Solved Cases
Global Model Objects
Regional EMS Static Model
Bndry
Regional EMS Static Model
Regional EMS Static Model
Bndry
Partition by Object Instance using Model Authority Sets
Par
titio
n by
CIM
Sch
ema
Ele
men
ts
Sked
Conn
Common Objects
Display Layout
Equip Model
Sked
ConnDisplay Layout
Equip Model
Sked
ConnDisplay Layout
Equip Model
Solution
Measurements
Meas
State Variables
Topology
Measurements
Meas
Measurements
Meas
34 34
61970-553 Display Layout Exchange
Purpose: To exchange schematic display layouts accompanying model or solution
exchanges.
Corresponds to the part of display maintenance work that normally goes with model maintenance.
Defines graphic objects used in the sender’s displays: Usually linked to a model object, but can also be background.
One or more location coordinates. (Optional glue points.)
Graphic style reference.
Does not define: Interpretation of graphic style references.
Diagram exchanges must first agree on a set of style references. Receiver provides the graphic style interpretation models for their display
management software.
Result: Layouts and names of things should be familiar.
Exact replication graphically is likely only when sender and receiver applications are the same.
Exact replication functionally is likely only when sender and receiver applications are the same.
35 35
Display Layout UML Proposal
class Domain Objects
DiagramObject
+ offset: int+ offsetDirection: int+ rotation: int
DiagramObjectPoint
+ sequence: int+ xPosition: float+ yPosition: float+ zPosition: float [0..1]
DiagramObjectGluePoint
IdentifiedDiagramObject
DiagramObjectStyle
+ drawingOrder: int+ name: char
IdentifiedDiagramObject
VisibilityLayer
IdentifiedObject
A DiagramObjectStyle is optional. If so the receiver is supposed to find a graphical shape that is relevant to the actual subtype of the IdentifiedObject associated with.
If the glue points connects points at different cooridantes the symbolsize matters.
«enumeratio...CoordinateSystem
gps rk90
DiagramObjectSet
IdentifiedDiagramObject
Diagram
+ coordinateSystem: CoordinateSystem+ x1InitialView: float+ x2InitialView: float+ y1InitialView: float+ y2InitialView: float
How do we represent hierarchies of DiagramObjects containing each other and manage the references from them to the CIM equipment model?
1..*
1
0..1
+Point
2..*
1..*
+DiagramObjectSet
0..1
1..*
0..*
+IdentifiedObject
0..1 0..* 0..*
+Style
0..1
1..*
+DiagramObject
1
36 36
UCTE Case – Display Layout Exchange
Display Bndry
TSO Equipment Model
TSO Topology
TSO Equipment Model
Display Layout
X-nodes
TN
TSO Topology
TN
Tie Line
B Region Substation
m
T TLS
T TLS
Tie Line Mid-point
A Region Substation
TLST
TN
TLST
T TLS
T TLS
Display Layout GO
GOGO GOGO GO GO
TaTa
EC T
Ta
Ta
Ta
ECT
Ta
Ta
GO
GO
Ta
Ta
Ta Ta
Ta
Ta
Ta
UCTE Common Objects BV
37 37
Profile Specifications -- Packaging
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.
38 38
Business Usage Profiles for 61970-45x
Typically, 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.
39 39
Conclusions
A great deal of progress has been made.
Tools exist.
Adoption is lagging – especially in North America.