CIM Market Extensions CME

1
CIM Market Extensions (CME)

• Terry Saxton

2
CIM Extension for Markets

• Scope of project
• Common Information Model (CIM)
• Organization
• Tasks
• Initial meetings
• CME Core Group

3
CIM Extensions for MarketsScope

• Support FERC NOPR on Standard Market Design (SMD)
• Standardize data exchange between utilities (ISO,
  RTO,NJE) to support SMD applications and
  facilitate markets
• Not directly involved with data exchange between
  energy market players, (PSE, GSE, LSE) and
  utilities (RTO, ISO, IOU,NJE)
• Subsystems/Applications plug and play interfaces
  within an RTO

Generators (GSE)
RTO1
RTO2
Loads (LSE)
RTO4
RTO3
Marketers (PSE)
4
The Common Information Model (CIM)

• A data model to enable data transfer or
  integration in any domain where a common power
  system model is needed
• Model includes Classes, their Attributes, and
  Relationships to represent utility objects
• The Classes (Objects) are abstract and may are
  used in a wide variety Of applications
• Useful
• As Foundation for Logical Data Base Schema
• To Define Component Interfaces
• Common Language for Data Exchange

5
CIM Packages
Generation
LoadModel
Outage
SCADA
Protection
Assets
Meas
Financial
Wires
ERP Support
EnergyScheduling
Topology
Docs Trouble Tickets Work Orders
Commercial Transactions
Consumer
Reservation
Core
Domain
6
Naming
(from Core)
1..1
AreaReserveSpec
0..n
0..n
InadvertentAccounts
HostControlArea
HostControlAreas
0..n
SubControlAreas
1..1
1..1
1..1
1..1
0..n
0..n
HostControlArea
1..1
1..1
1..1
1..1
1..1
1..1
1..1
1..1
1..1
1..1
SideB_SubControlArea
1..1
1..1
Send_HostControlArea
SideB_HostControlArea
SideA_SubControlArea
Receive_HostControlArea
0..1
0..1
SideA_HostControlArea
DynamicEnergyTransaction
Receive_DynamicSchedules
Send_DynamicSchedules
0..n
0..n
0..n
0..n
SideA_TieLines
SideB_TieLines
TieLines
SideB_TieLines
0..n
0..n
0..n
0..n
0..n
0..n
0..n
0..n
TieLine
SideA_TieLines
0..n
0..n
7
CIM XML Standards

• CIM has been translated into XML
• For exchanging power system models
• For message-based information exchange between
  systems
• RDF (Resource Description Framework) schema and
  syntax used for CIM XML document
• Standard XML format that any EMS can understand
  using standard Internet and/or Microsoft
  technologies
• Automatically generated from the CIM Rational
  ROSE model using Xpetal tool
• NERC mandated use of this standard by Security
  Coordination Centers to exchange power system
  models by September 2001
• CPSM minimum requirements profile
• Other profiles possible

8
Benefits of Using CIM Approach

• Data model driven solutions leads to
  interoperability
• Provides common semantics for information
  exchange between heterogeneous systems
• Used for CA to CA communications
• NERC mandated use of CIM and RDF Schema version
  for power system model exchange
• Provides for automatic generation of message
  payloads in XML
• Ensures common language for all messages defined
• Avoids proprietary message formats from vendors
  (based on internal schemas)
• Eliminates work of creating DTD for each message
• Alternative to EDI or CSV file formats

9
Benefits of Using CIM Approach

• Uses industry standard modeling notation
• UML, XML
• Permits software tool use for
• Defining and maintaining data models
• Single point of maintenance for changes
• Documenting data models
• Automatic generation of information payloads
• Automatically generate IDL, Java, C code

10
CIM Extension Process for CME

• Define scope of SMD for purposes of extending the
  CIM
• Define business processes to support SMD
• Compile list of typical applications

11
Processes

• Standard Market Design Processes
• Day Ahead Market
• Real Time Market
• Bi-lateral Contracts
• Settlement
• Auction/Sell CRR
• Market Monitoring

12
Day Ahead Market

• Obtain outage schedules from TOs.
• Generation outage schedules are known internally
  and not shared
• Transmission outages are shared on major lines
• Obtain system load forecasts
• Known internally but not shared now - should they
  be shared?
• Submit day ahead bids for energy, loads, and
  ancillary services (includes bilateral contracts
  at least in the East)
• Market participants submit bids
• Bids that cross RTO boundaries should be shared
  between RTOs
• Create schedules using Security Constrained Unit
  Commitment (LMP) (including bilateral contracts)
  at each affected RTO and
• Share schedules with other affected RTOs
• Reconcile schedules between RTOs
• Post reconciled schedules, ATC, LMP prices
• Submit E-TAGS

13
Real-Time Markets

• Obtain state of network topology, load, -
• Output of SE application SCADA data from
  neighboring RTOs. Apps may include short term
  load forecast
• Submit real-time (i.e., hour ahead or less) bids
  for energy, loads, and ancillary services
• Market Participants submit bid,
• Bids that cross boundaries should be shared
  between RTOs
• Merge real-time bids for energy, loads, and
  ancillary services with day-ahead schedules to
  create schedules
• Share portions of schedules with other affected
  RTOs
• Reconcile schedules between RTOs
• Post reconciled schedules, ATC, LMP prices
• Submit E-tags
• Dispatch based on economic dispatch app to units
  that have been bid
• Signals sent through TOs or direct to generating
  units
• Issue load reduction orders (as needed) to UDCs
• Monitor actual power flows at tie lines ( meter
  readings via SCADA from CAs), daily share
  inadvertent flows with other RTOs

14
Settlements

• Obtain revenue meter readings from TOs for each
  settlement period
• Could be hourly, daily for past periods
• Exchange actual energy schedules and ancillary
  services use with generators, loads, other
  entities at end of day
• Recompute LMP for price corrections and share
  with RTO, IPPs, loads, GSEs,
• Calculate transmission charges, losses,
  penalties, etc. associated with differences
  between actual and planned schedules
  (reconciliation).
• Send bills to appropriate entities
• Submit payment and receive

15
SMD Application List

• SCADA
• EMS
• State estimation, topology processor, security
  analysis, OPF
• Market Operations System
• applications that run the day-ahead and real-time
  markets
• LMP
• Rights auctions and allocations
• Bid-based dispatch
• Congestion management (FTR and CRR)
• Planning Operations
• both transmission and generation planning
• Billing Settlement
• Market Monitoring

16
CIM Extension Process for CME

• Define scope of SMD for purposes of extending the
  CIM
• Define business processes to support SMD
• Develop use cases
• Define integration scenarios
• Identify information elements to be exchanged

17
Use Cases - Day Ahead Transmission Outage and LGR
Outage Scheduling
18
Use Case State Estimation Results

• See Use Case Example

19
Integration Scenario for Extension Implementation
2
Maintenance Construction
Network Model Customer Attachments
Operation
3
1
Planning
Extension Project Job
Switching Schedule
Record
Optimization
Asset
Management
3
3
3 Customer Affected
Switching Schedule
Switching Schedule
See Usecase Network Extension Planning
Safety Document(Issue/Cancel)
See Use Case Network Edit
Approved Extension Project
Extension Project Job Complete
Safety Document(Issue/Cancel)
Planned Outage
Planned Outage Status
13
10
9,11
9,11
Changes to Network
4
8
7,12
Network Extension Planning
4
Planned Outage
Network
6
Start Extension Project
Operation
7,11
Changes to Network
8
Planned Outage Status
13
Extension Project Job Complete
5
Planned Outage Status
Customer
(This Example Integration Scenario Was Submitted
to IEC TC57 WG14 By Midlands Electricity and M3i)
20
CIM Extension Process for CME

• Define scope of SMD for purposes of extending the
  CIM
• Define business processes to support SMD
• Develop use cases
• Define integration scenarios
• Identify information elements to be exchanged
• Review and extend CIM to support these scenarios
• Define standard messages
• Create XML schema for each message type

21
Implementing A Common Data Language
1 Identify Steps Information Exchange Needed
For Business Process Automation
22
CIM Extension Process for CME

• Define scope of SMD for purposes of extending the
  CIM
• Define business processes to support SMD
• Develop use cases
• Define integration scenarios
• Identify information elements to be exchanged
• Review and extend CIM to support these scenarios
• Define standard messages
• Create XML schema for each message type
• Define underlying integration framework to
  exchange XML payloads
• Standard APIs
• Permit multiple technologies for communications
  infrastructure
• gt Produce new SCP document?
• Include ESC work for GSE, LSE, MSE participants?
• What happens to OASIS Phase II for electronic
  tags, etc.?

23
Organization

• Advisory Group
• Open to any interested industry party
• Access to listserver and FTP site
• Core Group
• 5-10 workers
• Will meet every few weeks
• Facilitators
• David Becker, EPRI
• Peter Hirsch, EPRI
• Terry Saxton, KPMG Consulting

24
CIM Extensions for Markets

• Tasks
• Define SMD Business Processes for which data
  needs to be exchanged
• For each process
• Define Business Case
• Define Use Cases
• Define Data Requirements and CIM extensions
• Define Communication Architecture, Interfaces
• Define standards for data and communication
  protocols to satisfy SMD requirements

25
Other Related Activity

• NERC Facilitated ESC/OSC
• Designing market interface for OASIS Phase II,
  focused on scheduling, tagging
• Electric Grease, Common Systems Interface
  Coordination (CSIC)
• Effort by WECC utilities to standardize
  interfaces
• Open Scheduling System (OSS)
• Effort by NE-ISO, NYISO to standardize interfaces
• Ontario Energy Board
• Standardized application and data interfaces for
  retail markets
• Mentioned in FERC announcement for Oct 3 workshop
• PJM-MISO integration efforts

26
CIM Extensions for MarketsInitial Meetings

• Sign up for Advisory or Core group, if you are
  interested
• CORE group first meeting
• August 29-30, 2002 in Palo Alto, CA
• Agenda
• Define Initial Scope
• Define Applications
• Define high level schedule
• EPRI CIM Extensions for Market Data Standards
  Workshop
• September 12-13, 2002, Dallas Texas
• Presentations by FERC, NERC, NAESB, EPRI
• FERC Technical Conference, October 3, 2002,
  Washington D.C.
• Focusing on RTO application interfaces and data
  exchange for SMD

27
CIM Market Extensions (CME) Core Meeting
8/29-8/30

• Goal
• Determine the scope and schedule of CME
• Objectives
• Determine Data for SMD business processes that
  needs to be standardized for wholesale
  electricity markets
• Determine Application and System Interfaces,
  Standards and Protocols that should be
  standardized for wholesale electricity markets

28
Internal RTO Applications/Sub-Systems

• Market Applications
• Energy Management Systems (EMS) Applications
• Settlement Applications

EMS Applications
Market Applications
Settlement Applications
Message Bus
CME would develop data and communication
protocols for these interfaces to allow for Plug
and Play
29
Communication Protocols and System Architecture

• APIs
• Independent of data transferred via interface
• Should be specified a high level (e.g., IDL or
  UML), and then mapped in standard ways to
  specific technologies (e.g., C, Java, etc. )
• Should be provided for selected data exchange
  patterns needed to support SMD operations
• Example Publish/subscribe, request/reply, SQL,
  ODBC. Does not include protocol for
  communications between applications.
• Architecture
• Examples include client/server, distributed vs.
  centralized, service-oriented,
• Can be specified in different layers (e.g., data
  architecture, services, communication)
• Security
• Consider specific security requirements for
  various data exchanges (e.g., private vs. public
  networks, specific data types to be encrypted,
  etc.)
• Specify standard security models and protocols
  (e.g., HTTPS, secure ICCP, VPN, certificates,
  etc.)

30
Communication Protocols and System Architecture

• Information Exchange Model
• Specifies content of message payloads (e.g., a
  bid specified as an XML schema, OASIS-style
  template)
• Specifies format of data (e.g., XML)
• Protocols
• Specifies how two entities communicate with each
  other, but may not specify an API.
• Examples include TCP/IP, ICCP, HTTPS, SOAP, SMXP,
  
• Performance requirements
• Time criticality
• Availability
• Throughput
• Reliability of delivery

31
Other Issues

• Incremental updates
• Interoperability testing

32
CME Draft Schedule

• Initial CME meeting Aug 30, 2002
• CME Workshop on Sept 12-13, 2002
• CME scope will be finalized at FERC meeting on
  Oct 3, 2002
• CME meeting in Minneapolis on Oct 7, 2002
• Draft set of business processes
• Draft glossary
• Draft communication protocols and architecture
• Create new Task Forces to address the detailed
  technical issues
• Draft CME specification by Feb 15, 2003
• Submitted Standards and Communication Protocols
  (SCP) to NAESB by June 15, 2003
• Submitted SCP to FERC by Sept, 2002
• FERC Rules on CME standards by Dec 15, 2003

33
CME Listserver and FTP site

• Listserver
• cme_at_lists.epripowerdelivery.com
• FTP
• ftp\\ftp.epripowerdelivery.com
• Username cmeuser, Password cimmrkts