2. Jay Britton jay.britton@areva-td.com
A Family of CIM EMS Exchange Standards based on CIM/XML ( ) - Static Network Model Exchange ( ) - Dynamic Model Exchange? - Schematic Layout Exchange ( ) - Solved State Exchange ( ) - EMS Static Model Update (proposed) - - Contingency Definition? - …
Jay Britton

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. 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. 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.
Exchange of schematics with models is desirable.
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.
ENTSO-E DACF.
Study cases are generated for the next day by each TSO representing the expected state of their internal network.

6. A Generic Model Exchange Business Process (ENTSO-E, ERCOT, WECC, …)

7. Preview – We are working toward defining model partitioning into non-overlapping XML submodels that satisfy all of the use cases.

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
CIM import / export
System B Import Model
System A Import Model a
Proprietary / Home grown
Extract / Merge Tools
Proprietary / Home grown
Extract / Merge Tools b
A Internal Model
B’s Model of A
System A Local Vendor Model
System B Local Vendor Model
A’s model of B
B Internal Model
System B EMS
System A EMS

9. A More Desirable Process
Site A makes a change:
A changes its ModelAuthoritySet using its CIM modeller.
A imports the change into its EMS.
A exports the change to B.
B receives the change (full or incremental), updating A’s ModelAuthoritySet within its CIM modeller.
B renames any new elements and repeats any reduction of A’s ModelAuthoritySet.
B imports the new model into its EMS.

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

11. Typical ENTSO-E Operations Boundary

12. Typical North American Operations Boundary

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.

14. Consolidating Planning with Operations
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. The Naming Problem

16. Evolving Support for Analytical Processes
The original 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’
ENTSO-E Day Ahead Congestion Analysis
EPRI ‘CIM for Dynamics’
Recent IEC WG13 Accomplishments
Update of
Draft defines solved power system state exchange.
Operations and planning supported.
ENTSO-E DACF supported.
Draft defines display layout exchange.
Update of includes header specifications.
Current WG13 Agenda
Finalize , 454, 456
Unify distribution and transmission network modeling.
Object registry specification
Liaison with Smart Grid standards.

17. Requirements Analysis Data 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.

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

19. 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.

20. CIM Design Decisions Equipment Topology Scheduled
At this point, we have kept Connectivity and Schedules as part of Equipment.
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.

21. Current Modularity 61970-452 Static Model.
Equipment Profile.
Identifies equipment and describes basic characteristics.
Describes electrical connectivity that would be input to topology processing. (Optional for planning.)
Describes input to functions that derive parameters for a specific point in time. (Optional for planning.)
Solved Power System State
Topology Profile.
The result of topology processing. i.e. Description of how equipment connects into buses and how buses makeup connected systems.
Analogs Profile.
The set of SCADA values for analog measurements for a particular point in time.
Status Profile.
The state of switches – input to topology processing.
State Variables Profile.
This is the set of state variables used in the mathematical formulation that the algorithms work with.
Used to represent starting conditions or ending conditions of analysis.

22. 61970 Profiles

23. DACF Process

24. ENTSO-E 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

25. Combining profiles into a complete solution description.

26. Partitioning into Files by TSO

27. Complete View of Partitioning Into Files

28. ENTSO-E Interconnection Solution

29. Dependency Relationships to be Expressed in Headers

30. Partitioning of EMS Static Model

31. Partitioning of EMS Solved Cases

32. 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.
Usage
Sender describes diagram.
Senders disclose the way their system uses graphic styles.
Object placements describe sender’s diagram as is.
Receiver must decide how to render the diagram in its system.
Create interpretation of sender’s styles.
Receivers are not expected to duplicate functionality.
Receivers may break apart complex styles or combine simpler styles.
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.

33. Display Layout UML Proposal

34. ENTSO-E Case – Display Layout Exchange