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

Reliability

July 14, 2004Terry Saxton

Xtensible Solutions

This presentation was prepared by:

Terry Saxton

Xtensible Solutions18125 23rd Avenue NorthPlymouth, MN 55447E-mail: tsaxton@xtensible.net

Presentation Contents

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

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

Scope of CME Project

RTO A

ISO D RTO C

ISO B

Generators

Loads

Marketers

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)

Inter-ISO/RTO Messaging

MIS

SCUC SCED

Settlement

Intra-ISO/RTO Messaging

RTO A

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

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

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

CurveSchedule

curveStyle : CurveStylerampMethod : RampMethodrampStartMethod : RampStartMethodrampUnits : RampUnitsxAxisType : XAxisTypexAxisUnits : XAxisUnitsy1AxisUnits : Y1AxisUnitsy2AxisUnits : Y2AxisUnitsyAxisType : YAxisType

(f rom Core)

Curv eSchedData

rampData : FloatrampDataValue : FloatxAxisData : Floaty 1AxisData : Floaty 2AxisData : Float

(from Core)

0..n

0..1+Curv eScheduleDatas

0..n+Curv eSchedule

0..1

Document(f rom DocumentInheritancePackage)

ResourceBid

zzmarketType : String = DAzzcommodityType : StringenergyMinDay : ActivePowerenergyMaxDay : ActivePowervirtual : Boolean = 0shutDownsMaxWeek : IntegershutDownsMaxDay : IntegerstartUpsMaxDay : IntegerstartUpsMaxWeek : Integer

Pnode

beginPeriod : AbsoluteDateTimeendPeriod : AbsoluteDateTimepublic : Boolean = Truetype : Stringusage : String

TransactionBid

0..1

0..n

+Receipt_Pnode

0..1

+TransactionBids

0..n

PointOfReceipt

0..1

0..n

+Deliv ery _Pnode

0..1

+TransactionBids 0..n

PointOfDelivery

NotificationTimeCurve

StartUpTimeCurve

BidSet

StartUpCostCurve

GeneratingBid

maximumEconomicMW : ActivePowerminimumEconomicMW : ActivePowerminimumDownTime : MinutesstartupTime : MinutesnotificationTime : MinutesmaxEmergencyMW : ActivePowerminEmergencyMW : ActivePoweroperatingMode : StringupTimeMax : MinutesupTimeMin : MinutesdownTimeMax : MinutesnoLoadCost : MoneystartUpType : IntegerstartUpRampRate : RateOfChange

0..1

0..n

+Notif icationTimeCurv e 0..1

+GeneratingBids 0..n

0..1

0..n

+StartUpTimeCurv e

0..1

+GeneratingBids

0..n

0..1

1..n

+BidSet 0..1

+GeneratingBids1..n

0..n

0..1

+GeneratingBids

0..n

+StartUpCostCurv e

0..1

RegisteredGenerator

0..n

0..n

+StartUpCostCurv es

0..n

+RegisteredGenerators

0..n

0..n

0..1+GeneratingBids

0..n

+RegisteredGenerator0..1

NonConformLoadSchedule(f rom LoadModel)

EnergyConsumer(f rom Wires)

0..n

1

+NonConf ormLoadSchedules 0..n

+Energy Consumer 1

LoadReductionPriceCurve

LoadBid

minLoadReductionInterval : MinutesminTimeBetLoadRed : MinutesreqNoticeTime : MinutesshutdownCost : MoneyminLoadReduction : ActivePowerminLoad : ActivePowerdropRampRate : RateOfChangepickUpRampRate : RateOfChangeminLoadReductionCost : Money

0..1

0..n

+LoadReductionPriceCurv e

0..1

+LoadBids0..n

RegisteredLoad

0..n

0..1

+LoadBids0..n

+RegisteredLoad0..1

BidPriceCurve

ProductBid

0..n

0..1

+ProductBids 0..n

+BidPriceCurv e0..1

MarketFactorsMarketProduct

0..n

1

+ProductBids 0..n

+MarketProduct 1

Market

0...0...

+MarketFactors

0...+Market0...

1...

0...

+MarketProducts

1...+Market

0...

Bid

startTime : AbsoluteDateTimestopTime : AbsoluteDateTime

1

1..n

+Bid1

+ProductBids

1..n1

0..n

+Market1

+Bids0..n

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

Presentation Contents

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

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

DataWarehouse

SubstationAutomation

OMS

DistWiresModel

GridWiresModel

DAC

CIS

VRU

AM/FM/GIS

DistributionAutomation

HumanResources

OutageReporting

Common Language Used Over

Integration Framework (intra-RTO) or WAN (inter-RTO)

InformationExchange

Model

Event History WorkManagement

...

EMS

= 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).

How the CIM Provides a Common Language for Information Exchange via Adapters

App CIMY.1 X.1Y.2 X.2Y.3 X.3Y.4 X.4Y.5 X.5

Publisher

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)

DataWarehouse

SubstationAutomation

OMS

DistWiresModel

GridWiresModel

DAC

CIS

VRU

AM/FM/GIS

DistributionAutomation

HumanResources

OutageReporting

Event History WorkManagement

EMS

...

CIMX.1 X.2 X.3 X.4 X.5

Subscriber

CIM AppX.1 B.1X.2 B.2X.3 X.4 X.5

Subscriber

CIM AppX.1 A.1X.2 X.3 X.4 A.4X.5 A.5

Subscriber

CIM AppX.1 C.1X.2 X.3 C.3X.4 C.4X.5

Subscriber

Subscribers:Several Application Adapters Receive The Same MessageEach 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

Event Type: ChangedNetworkDataSet (Expressed In Common Language)

Decoupled InformationExchange

2003-2004 Xtensible Solutions, Inc. 14

Presentation Contents

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

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

SCUC

- Topology Processor- Security Analysis- Power Flow

Network ModelDEWG RDF

CIM

Outage Schedules

Equipment Limits(24 hour, 4 hour, 15 minutes)

(Seasonal)

Contingency List

Monitored Elements

Stability Limits

General Constraints

Active Transmission Constraints

Shift FactorsPenalty Factors

Load DistributionFactors

Generator/Load Schedules

Finalized Data Requirements for SCUC

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

Message Framework for SCUC with MDA

User MarketSystem

SCUC(ID#)

EXECUTEEXECUTE (ID1,ID2,ID3,ID4, ID5)

FETCH (ID1)

Network (ID1)

FETCH (ID2)

Standing (ID2)

FETCH (ID3)

Market (ID3)

Results (ID1,X,ID3,ID4, ID5)

FETCH (X)

Standing (X)

DISPLAY

FETCH (ID3)

Market (ID3)

FETCH (ID4)

Security Analysis (ID4)

FETCH (ID5)

System Requirements (ID5)

Model Driven Architecture (MDA) Process

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

Presentation Contents

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

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

Using NERC Functional Model to Define CIM-based Standard Messages & Adapters

NERC Business Use Cases

RTO Use Cases

Role Based Activity Diagrams

Application Based Activity Diagrams

Sequence Diagrams (name, type)

Message Schema

MAP RTO Data to CIM

Execute Data Transformation

NERC

IRM

CIM

Mapping (Ex: Contivo)

ETL (Ex: Data Junction)

The NERC Functional Model

Balancing(Balancing Authority)

Interchange(Interchange Authority)

TransmissionService

(Transmission ServiceProvider)

GeneratorOperations

(Generator Operator)

GeneratorOwnership

(Generator Owner)

TransmissionOwnership

(Transmission Owner)

Load-Serving(Load-Serving

Entity)

Purchasing-Selling

(Purchasing-SellingEntity)

TransmissionOperations

(Transmission Operator)

Distribution(Distribution Provider)

OperatingReliability

(Reliability Authority)

StandardsDevelopment

(Standards Developer)

ComplianceMonitoring

(Compliance Monitor)

ReliabilityService

Functions

Planningand

OperatingFunctions

StandardsFunctions

NERC FunctionalModelVersion 2

PlanningReliability

(Planning Authority)

ResourcePlanning

(Resource Planner)

TransmissionPlanning

(Transmission Planner)

MarketOperations

(Market Operator orResource Dispatcher)

NERC - Balancing Authority Responsibilities Activ ity Diagram: Formulate Operational Plan / Formulate Operational Plan

Activ ity Diagram: Transaction Approv al

Activ ity Diagram: DetermineIOS / Determine Intercon Op Serv ices

Act iv it y Diagram: Energy Emergencies / Energy Emergencies

Activ ity Diagram: MaintainBalance / Maintain Balance

Report cont rol performanc e and disturbance recovery

Approve Interchange Transactions

Implement emergency procedures

Provide balancing and energy accounting

Determine needed Interconnected Operations Services

Formulate Operational Plan

Cont rol of Balancing Aut hority Area

Deploy I nt erc onnected Operations Serv ices

Calculate ACE

Rev iew generation commitments, dispatch, & load f orecasts

Implement interchange schedules

Prov ide f requency response

Balancing Authority

(from NERC Functions)

Activ ity Diagram: ComplianceMonitoring / ComplianceMonitoring

NERC Functional Modelin UML for TVA

Load Data Set Message Type Package

NERC

Functional Model

CommonInformation

Modeling

Business Process

Modeling

IEC

InterfaceReferenceModel

Application & Database InterfaceTransformations

Implementation(ETL, EAI, Web Services)

BusinessVocabulary

ManagementSupporting:

Semantic Mapping,Cataloging Of

Data Assets, UnifiedModel & Data Queries,

etc.

BusinessVocabulary

ManagementSupporting:

Semantic Mapping,Cataloging Of

Data Assets, UnifiedModel & Data Queries,

etc.

Mapped Interfaces

Data Fields Mapped To Semantic Model

Use Cases

Putting It Altogether With MDI

InformationExchange Modeling

Utility Application& DatabaseInterfaces

Utility Application& DatabaseInterfaces

Common InformationModel (CIM)

InformationExchangeRequirements

OtherModels

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