EPRI CIM for Market Extensions (CME) and CIM-Based Messaging to Support Markets and Reliability

1. EPRI CIM for Market Extensions (CME) and CIM-Based Messaging to Support Markets and Reliability July 14, 2004Terry SaxtonXtensible Solutions

2. This presentation was prepared by: Terry Saxton Xtensible Solutions 18125 23rd Avenue North Plymouth, MN 55447 E-mail: tsaxton@xtensible.net

3. Presentation Contents • CIM for Market Extensions (CME) • How CIM-Based Message Standards Work • ITC Standards Collaborative with MDA • NERC Functional Model and MDI

4. Initiation of CIM for Market Extensions (CME) Project • FERC requested EPRI to extend the CIM architecture to support the SMD and facilitate markets • EPRI initiated CIM for Market Extensions (CME) project • Made up of utility and industry organizations to support this initiative • Managed by Xtensible Solutions for EPRI • Focus on the Day-Ahead and Real-Time Market Processes to define extensions needed for the CIM data model to support these processes • Goal of CME • Standardize information format and application interfaces to make the North American wholesale electricity market run efficiently, reduce seams issues and save substantial costs in the development of applications for each RTO • Will allow RTOs to buy best-of-breed applications and communicate with Independent Transmission Organizations (ITOs) or other ISOs and RTOs in a standard information format • Will allow marketers, Load Serving Entities (LSE), and Generator Serving Entities (GSE) to access information and bid into the RTO’s preferred format

5. Scope of CME Project Inter-ISO/RTO Messaging Intra-ISO/RTO Messaging Generators RTO A MIS Settlement RTO A ISO B Marketers SCUC SCED ISO D RTO C Loads CIM extensions in scope for CME XML information exchange model and terms database – message standards to be developed as part of RTO/ISO Data Initiative Market, Load, Generation Participants CIM extension and information exchange model – Other Initiatives and/or Future Phase(s)

6. Role of the CIM • An information model – provides common language (i.e., semantics/data definitions) for exchange of data between various applications both within and across company boundaries • Developed through efforts of EPRI, vendors and utilities through EPRI CCAPI Task Force • CIM now adopted by International Electrotechnical Commission (IEC) as international standard for information exchange and data access • NERC mandated use of CIM XML format for sharing power system models between Reliability Coordinators in North America • CIM extensions • Continues to expand to include models of distribution systems and business objects, such as assets, documents, etc. • Now being extended to support Market Operations

7. CME Phase 1 • Define data requirements and CIM extensions needed to support the well-defined, high-priority SMD software applications • Investigate applications and functions needed to support real-time and day-ahead markets • Focused on: • Security Constrained Unit Commitment (SCUC) • Security Constrained Economic Dispatch (SCED) • Ex Ante LMP (based on bids) • For each application: • Develop data requirements • Define information exchange data requirements • Review CIM and identify extensions needed to support SMD • Deliverable for Phase 1: • EPRI TR “CIM Extensions to Support Market Operations Phase 1: Day Ahead and Real Time Scheduling Applications” • CIM representation of data requirements in table format with mapping to existing applications • Extended CIM UML model to support the SCUC/ED/LMP data requirements • Reuse and creation of new classes, attributes, and associations • XML Schema for the Input/Output data • Presents the CIM-based XML tags proposed to support exchange of market operation data • Tag names • Definitions

8. Phase 1 CIM UML Extensions • New CIM Package created for Market Operations • Bid • Resource • RTO • Security Constraints • Clearing Results • Updates to existing CIM Packages • Energy Scheduling • Financial • Reuse of existing IEC 61970 and 61968 Packages • 61970 – Core, Generation/Production, Measurements, others • 61968 - Core2/Top Level and Activity Record

9. Bid Example

10. CME Phase 2 & 3 • CME Phase 2 (Current) • Network Analysis • State Estimator, Security Analysis, Optimal Power Flow • Ex-Post LMP (based on actuals, SE results) • Financial Transmission Rights • Facilitated Check Out (FCO) • Phase 3 (Planned for 2004 if funded) • Network model maintenance • Complete, incremental, and partial model transfers) • Control Area seams-related data exchange • Applications include ramp data, TTC, ATC, AFC (Available Flowgate Capacity) • Market participant upload bids and download of results • Would not include user interface • Data Exchange between Operations and Settlement • Intra-RTO pending DRWG resolution • Inter-RTO if use cases can be identified • Market monitoring information

11. Presentation Contents • CIM for Market Extensions (CME) • How CIM-Based Message Standards Work • ITC Standards Collaborative with MDA • NERC Functional Model and MDI

12. CIM Provides Vocabulary - CIM XML Provides Standard Messages • Webster’s Dictionary = CIM • Provides standard data semantics and data types • Sentence structure = CIM- based XML messages • Just as you must have structured sentences to communicate orally, you must have standard messages to share data electronically • Standard messages are needed to • Ensure interoperability both within RTOs and between RTOs • Remove seams • Define that part of CIM that must be supported by an application • Adapters provide CIM <-> proprietary data mappings used by applications

13. How the CIM Provides a Common Language for Information Exchange via Adapters = Application Adapter The “Common Language” Is Based On The Common Information Model (CIM) Specified In IEC Standards. The Meta Data For This Language Is Maintained In The Information Exchange Model (IEM). Grid Wires Model Dist Wires Model DAC VRU Information Exchange Model Outage Reporting Distribution Automation EMS OMS CIS Common Language Used OverIntegration Framework (intra-RTO) or WAN (inter-RTO) ... Event History Substation Automation Data Warehouse Human Resources Work Management AM/FM/GIS

14. Decoupled Information Exchange • Subscribers: • Several Application Adapters Receive The Same Message • Each Adapter: • Parses Message, Pulling Out Data Needed By Application • Transforms Data (if necessary) to Local Application Format • Passes Data To Local Application And/Or Database Subscriber Subscriber Subscriber CIS Event Type: ChangedNetworkDataSet (Expressed In Common Language) Outage Reporting AM/FM/GIS Substation Automation Data Warehouse Work Management Distribution Automation CIM X.1 X.2 X.3 X.4 X.5 • Publishers: • One Application Connector: • Obtains Data From Application And/Or Database • Transforms Data (if necessary) to CIM Format • Puts Data Into Message Template • Publishes The Message (Fires & Forgets) CIM App X.1 B.1 X.2 B.2 X.3 X.4 X.5 CIM App X.1 C.1 X.2 X.3 C.3 X.4 C.4 X.5 CIM App X.1 A.1 X.2 X.3 X.4 A.4 X.5 A.5 App CIM Y.1 X.1 Y.2 X.2 Y.3 X.3 Y.4 X.4 Y.5 X.5 Human Resources Subscriber Publisher Grid Wires Model Dist Wires Model DAC VRU EMS OMS ... Event History  2003-2004 Xtensible Solutions, Inc.14

15. Presentation Contents • CIM for Market Extensions (CME) • How CIM-Based Message Standards Work • ITC Standards Collaborative with MDA • NERC Functional Model and MDI

16. ISO/RTO Standards Collaborative • Objective • Bring together organizations interested in developing IT standards for North American ISO/RTOs business processes • Goals • For first deliverable, select a single application/process to produce short-term results • Review and update the CIM/CME model in the context of selected process • Validate a practical & repeatable process to develop standards-based messages and interfaces for ISO/RTO processes • Discussed two message development processes • MDA (Model Driven Architecture) from OMG • Best for stateless messages • MDI (Model Driven Integration) from IEC • Best for stateful, transactional business processes • Both methods are standards-based and are repeatable • Selected the MDA methodology for the SCUC standards

17. Finalized Data Requirements for SCUC

18. Message Framework Constructed Based on CIM with Market Extensions • Market Input Message (Bids) • Gen Bid • Load Bid • Transaction Bid • Network Model Input Message • CPSM NERC Data Exchange Profile • Security Analysis Input Message • Outage • Contingencies • Constraints (individual and group) • Limits • Violation Checklists • Control Messages • Schemas • Fetch (Message ID to retrieve) • Execute (Message ID to deliver) • Standing Input Message (Master File) • RTO Product definition • Market Definition • Market Participant Registry • System Requirements Message • Requirements • Generation Initial Conditions • Load Forecast • Output Message • Schedules • Prices • Errors • Warnings • Solution Notes

19. Message Framework for SCUC with MDA

20. Model Driven Architecture (MDA) Process

21. ITC Standards CollaborativeInitial Deliverables and Next Steps • Current Deliverables (based on CME Phase 1) • Message Framework • Model Driven Architecture process flow and tools • Profiles used to selectively include required portions of the CIM/CME models • New draft revision of the CIM • Next Steps • Initiate an implementation Proof Of Concept for SCUC • Forward message standards to the SRC • Submit CME modifications to official standards bodies • Select future applications/business processes to standardize (based on CME Phase 2) • Security Constrained Economic Dispatch and Locational Marginal Pricing • Control Room portions of the NERC Functional Model • CRR/FTR/TCC Auction processes

22. Presentation Contents • CIM for Market Extensions (CME) • How CIM-Based Message Standards Work • ITC Standards Collaborative with MDA • NERC Functional Model and MDI

23. Message Definition Process with MDI Based on NERC Functional Model • Current ITC Standards Collaborative methodology for SCUC is based on MDA • Input/Output data requirements for legacy software applications plus process knowledge • Start with existing applications, extend CIM in UML, then work in XML to define messages • MDI starts with business processes to derive information exchange requirements and message standards based on the NERC Functional Model and the CIM • Stay in UML until last step, starting with NERC Functional Model use cases • Each RTO/ISO can map their business processes onto this model

24. Using NERC Functional Model to Define CIM-based Standard Messages & Adapters NERC NERC Business Use Cases RTO Use Cases Role Based Activity Diagrams IRM Application Based Activity Diagrams Sequence Diagrams (name, type) CIM Message Schema Mapping (Ex: Contivo) MAP RTO Data to CIM ETL (Ex: Data Junction) Execute Data Transformation

25. The NERC Functional Model

26. NERC Functional Modelin UML for TVA

28. Load Data Set Message Type Package

29. Putting It Altogether With MDI Data Fields Mapped To Semantic Model BusinessVocabularyManagement Supporting: Semantic Mapping, Cataloging Of Data Assets, Unified Model & Data Queries, etc. Information Exchange Requirements Information Exchange Modeling Mapped Interfaces Common Information Model (CIM) Implementation (ETL, EAI, Web Services) Other Models Utility Application & Database Interfaces Application & Database Interface Transformations NERC Functional Model Business Process Modeling Common Information Modeling Use Cases Interface Reference Model IEC

30. NERC Functional Model & MDI Conclusions • Improved ability to integrate business processes across commercial-off-the-shelf (COTS) applications • while lowering dependence on individual vendors • Can articulate how business objectives are implemented • Provides end-to-end requirements traceability back to functional model • Reusable approach for growth and change • Methodology • Business process models • Common information models • Information exchange models • Faster integration of application systems and information: • Improving ability to react to business changes • while providing the right information to where it is needed • Run time support with Business Vocabulary Management, Message Standards Repository, and Adapters • One repository of all source, target, and CIM-based messages to ensure consistency and leverage existing message definitions