Document 7684785

Download Report

Transcript Document 7684785

European Model Exchange Standard based on

- IEC 61970-552, 501 - IEC 61970-452 (updated 2009) - IEC 61970-456 (updated 2009)

Jay Britton [email protected]

Current UCTE Day-Ahead Process

TSO TSO TSO UCTE Model Server TSO TSO TSO TSO TSO My TSO X-Node List

Export my TSO Model to UCTE Server

My TSO’s Cases for Export My TSO Market Outcomes TSO TSO Development TSO TSO My TSO Model Maintenance

Import neighbor TSOs from UCTE Server Merge

TSO Analysis Model TSO TSO TSO My TSO

UCTE CIM Profile Objectives



Data Scope



Support existing day-ahead model exchange data.



Currently implemented with the UCTE-DEF format.



Expanded data scope.

 

Covers power flow and short circuit data.

Future – dynamics, …



Cover expanding set of business processes.



TSO Internal Model Exchange



Each TSO uses the profile to export its internal network model in such a way that it can be easily and unambiguously combined with other TSO internal models to make up complete models for analytical purposes.



Solved Case Exchange



Any steady-state solution case created by one party, covering any territory, may be sent to any other party using the profile. In such an exchange, it shall be possible for the receiver to discern how the case modeling relates to TSO internal models.

UCTE CIM Profile Functional Overview

TSO Model Mgmnt TSO Study Cases UCTE Model Server

Profile governs exchanges between TSOs

My TSO TSO Other TSO My TSO TSO Other TSO TSO Study Cases TSO Model Mgmnt TSO Applications TSO Applications 

Studies are run by TSOs.



Internal models are prepared and submitted to provide basic data.



TSOs assemble appropriate study models from contributed internal models.

Adding CIM 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).



UCTE is one of several similar add-on efforts:



2007 EPRI ‘CIM for Planning’



2008 UCTE CIM



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

IEC Requirements Analysis CIM Metadata Modularity – “profile data groups”



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



This is the set of state variables used in the mathematical formulation that the algorithms work with.

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.

Objective



a modularized overall model…

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

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.



SV classes relate to classes whose state they represent.

  

SVVoltage



TopologicalNode SVInjection



TopologicalNode SVPowerFlow



Terminal



etc

IEC Static Model Exchange Profile (61970-452)

Equipment + [Connectivity not used] + [Schedule not used]

future IEC Solved Power Flow State Profile (61970-456)

Ref (static model) + Topology + State Variables

Profile Specification – File Types



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

SvVoltage TopologicalNode TopologicalIsland

UCTE Metadata by File Type

GeographicalRegion SubGeographicalRegion Substation VoltageLevel SvPowerFlow State Variables SvShuntCompensatorSections TSO Topology Terminal (about) 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

A Region Substation

Partitioning into Files by TSO

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

Profile Specifications – Model Organization



Model Authority Sets



Each TSO is a model authority set



Associations to TopologicalNodes representing X-nodes



One X-node model authority set



Contains only TopologicalNodes at midpoints of ties



Instance Identification of Objects



TSOs issue MRIDs



MRIDs are 60 hex digit GUIDS

Complete View of Partitioning Into Files

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.

Other Profile Decisions



Decisions



MRIDs will be 60 digit hex guids.



For SvClasses, there is no MRID. RDFID will be a generated GUID.



EIC names should be put in the name attribute.



When object parts occur in two different files:



There is a primary reference in a root file.



The is an ‘rdf about’ reference in dependent files.



Topology report for open branches:



Branch ends are designated open by the connectedTerminal attribute.



The association between a branch end TopologicalTerminal and TopologicalNode should remain – i.e. the branch end associates to the node it would connect to if it closed.



For an open retained switch, both terminals are marked disconnected.

Types of Business Exchanges



Boundary Set Update



X-node boundary topology file



Daily Base Model Submission



TSO equipment model file



Daily submission of hourly cases