European Model Exchange Standard based on IEC 61970-552, 501-IEC 61970-452

2. European Model Exchange Standardbased on- IEC 61970-552, 501- IEC 61970-452 (updated 2009)- IEC 61970-456 (updated 2009) Jay Britton jay.britton@areva-td.com

3. Current UCTE Day-Ahead Process

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

5. UCTE CIM Profile Functional Overview • Studies are run by TSOs. • Internal models are prepared and submitted to provide basic data. • TSOs assemble appropriate study models from contributed internal models. Profile governs exchanges between TSOs

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

7. IEC Requirements AnalysisCIM Metadata Modularity – “profile data groups” • 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. • 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.

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

9. Objective  a modularized overall model…

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

11. IEC Static Model Exchange Profile (61970-452) Equipment + [Connectivity not used] + [Schedule not used] Ref (static model) + Topology + State Variables future IEC Solved Power Flow State Profile (61970-456)

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

13. UCTE MetadatabyFile Type

14. Partitioning into Files by TSO

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

16. Complete View of Partitioning Into Files

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

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

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

20. Example: TSO Internal Model Export