Download as pdf or txt
Download as pdf or txt
You are on page 1of 5

CIM Modeling For Market Management Systems

Xing Wang, Senior Member, But-Chung Chiu, Member

The key components in Figure 1 are described below:


Abstract— This paper presents a Common Information Model • Enterprise Service Bus (ESB). ESB is the backbone
(CIM) based modeling process for PJM Market Management of a SOA system. It provides high performance data
Systems (MMS). CIM network model is imported into MMS via transfer between service components and facilitates
a static model importer, which also serves as the model manager
for the commercial model. In addition, standard CIM is extended comprehensive workflow management. Message
for enterprise master data modeling processes. CIM compliant definition for ESB data transfers should be CIM
messages are used for data transfers between different business compliant in order to allow easy integration of a
service components under the Service Oriented Architecture. third party application service.
• Common Source Modeler (CSM). CSM provides
Index Terms—Common Information Model (CIM), Market CIM based network and commercial models for both
Management Systems (MMS), Service Oriented Architecture
(SOA)
EMS and MMS. It ensures model consistency
between different services and significantly reduces
I. INTRODUCTION RTO model maintenance efforts.
• Shared Architecture (SA) consists of a set of shared

I
n a practical Market Management System, there are many
services that are available to all other Business
important software components and they are interfaced
Service Components (BSC), e.g., Common Logging
with almost all the other systems of a RTO/ISO. A good
design for system integration should provide enough Service, etc.
flexibility for future expansion while satisfying the business • Orchestrator provides overall process control and
functional requirements. coordination over the ESB.
• EMS. State Estimation (SE) and Real-Time
In recent years, the IEC Common Information Model (CIM) Contingency Analysis (RTCA) provide market
and the Service Oriented Architecture (SOA) have become the systems with real-time network topology, generation
industrial trend for control center system integration. In fact, and load MW values, and real-time transmission
CIGRE D2.24 working group has been developing a CIM and security constraints. On the other hand, Automatic
SOA based standard for Very Large Power Grid Operators Generation Control (AGC) takes the real-time SCED
(VLPGO) around the world. Figure 1 shows a high level solution as the unit base points for generation
example of SOA based RTO system integration. control.
• DA/AS/RT/FTR. Common market functional
components for a RTO/ISO: Day Ahead Market,
Ancillary Services Market, Real-Time Market, and
Financial Transmission Rights (FTR) Market.
• MUI. Market User Interface is for participants to
submit bids and offers and for RTO to publish
market clearing results.
• Data Warehouse is capable to store all market
clearing related historical data for multiple years.
• Market Monitoring is the post market analysis to
detect potential market power. It often requires the
same core market clearing engines that are used to
clear the markets and other statistical tools. Market
monitoring system can access all historical market
data stored in the data warehouse for play back,
Figure 1 – SOA based MMS System Integration market simulation and scenario analysis.

________________________________ CIM is the backbone of such a SOA enabled MMS system. It


not only provides a standardized network/commercial
Xing Wang is with AREVA T&D Inc., Redmond, WA 98052, modeling processes, but also build a common foundation for
USA. (email: xing.wang @areva-td.com) ESB message transfers between different application
But-Chung Chiu is with AREVA T&D Inc., Redmond, WA 98052, components. This paper uses PJM Advanced Control Center
USA. (email: [email protected])

978-1-4244-6551-4/10/$26.00 ©2010 IEEE


(AC2) as an example to demonstrate a practical CIM based • Applying SOA technology to PJM enterprise
modeling approach for MMS. systems.
• Developing an innovative generation control
II. CIM MARKET EXTENSION application (GCA).

CIM is the Common Information Model, an IEC standard, that The AC2 objectives for PJM MMS systems include:
was created and extended under the sponsorship of EPRI. The
most mature part of CIM in use today is the power system • Importing CIM Network Model into MMS
model that is used by ISOs, RTOs, and TRANCOs, for • Building CIM compliant messages for ESB data
exchanging power system equipment and network connection transfers to replace the messy point-to-point DB links
data. between business components within MMS and
between MMS and other PJM systems.
CME means CIM Market Extensions and it is a phased • Enhancement on system security
implementation of information model components used to • Inter-site coordination
represent wholesale energy market operations. CME is the
result of FERC’s request of EPRI to extend CIM to model
B. Import CIM network model into MMS
SMD (Standard Market Design) functions and facilitate the
integration of CIM into market applications. CME is often
written as a couplet acronym with CIM as CIM/CME. To ensure system operational reliability during markets
operation, MMS requires a detailed transmission network
The chief goal of CME is to standardize the information model which is based on the one used in EMS. In the case of
model and data format for the North American wholesale PJM, the network model is produced by its EMS modeler. In
electricity markets. The key players in this arena include: the past, the network model exchange between EMS and
• ISOs/RTOs MMS has been a time consuming process because it involves
• Generator & Demand Service Response Organizations. many manual steps and thus very difficult to operate and
• Load (industrial and retail demand customers). maintain. One of the main goals of the AC2 project is to
streamline this modeling process utilizing the CIM standards.
• Energy Marketers
The following figure illustrates the main workflow of the new
The CME information model is a common language that
AC2 CIM network model importing process.
describes the data and entity types, the semantics, and the
entities involved in market operations. In addition, NERC has PJM Sonic Environment
mandated that the XML data formatting language be used for Claim
AOA ORG TNA C&S
all CIM/CME data exchanges. Check

ESB

CIM/CME offers an information model to describe the ETS


following kinds of entities: IMM
Adapter
MIC

• Bids & Offers Market DB’s

• Resources (Generators, Demand Side Responsive Load) ETS


DA
MDB
Disk
• RTO & ISO
FTR
MMI
MDB
AS

• Security Constraints Network CTGS Pnodes


ETS Server MDB

• Market Clearing Results Disk


ETS DB

The existing CME structure is very generic and it has to be Network CTGS Pnodes

extended to model the commercial model of any of the ETS Import/Export

existing RTO/ISO markets. However, CIM extension is not an


EMS
easy task. It requires both MMS domain expertise and
familiarity of the object oriented CIM/CME standard model. NET
MOM
CTGS

Contingency
Powerflow NETVALID
Validation

III. CIM BASED MODELING FOR PJM AC2 MMS


A. PJM AC2 Introduction
Figure 2 – PJM AC2 MMS Network and Contingency Model
AC2 stands for Advanced Control Center. The main focus of Importing Process
the AC2 objectives includes:
The modeling importer has the following main tasks:
• A new control center in Melford. • Import either a full network model or an incremental
• Telecom infrastructure between Valley Forge and network model, which is produced by the EMS
Melford. modeler and is in CIM RDFS format;
• Create a native network savecase to support SFT that are used together to meet demand specified
(Simultaneous Feasibility Test); by a given load forecast.
• Import the contingency model; • Market Ancillary Services Area - Made up of a
• Validate the contingency model against the network group (one or more) of Market Control Zones for
model and create a native contingency savecase for the purpose of specifying ancillary requirements
SFT; with a slightly broader perspective.
• Push the essential network device information into • Control Area - The Control Area is the energy
the market database (MDB) in various environments management, transmission, control area used to
with effective dating to facilitate market operator’s manage generation and load to minimize ACE
overrides on the network topology and limits; and control frequency.
• Automatically build/update the commercial model • Reserve Zone - The Reserve Zone is a special
upon the imported network model; PJM region within a control zone used to
• Push the commercial model into MDB in various manage and control a particular reserve
environments with effective dating. scheduling problem
• Dispatch Zone - Zone defined for zonal dispatch
rate calculation
C. CIM Based Commercial Model and Message • Pnode - Pricing node.
Definition

The first (and the most important) step towards a true SOA AS Area
enterprise architecture is to build a common master data model Control
Zone 1
Contro
l Zone
using a UML (Unified Modeling Language) tool. This master
UML model will be used to produce message definitions Control
Area: PJM

(XSDs and WSDLs) that are used to build the data transfers Dispatc
between different Business Services Components (BSC). The h Zone Contro
l Zone
Contr
ol
AS Area

Standard CIM/CME provides a solid base for such a master Reserv


data model, but extension is needed for PJM specials. e Zone

The PJM commercial model draws most heavily on that part


of CIM/CME describing Resources and less so on the part that
describes RTO & ISO entities. The aspect of the commercial
model referred to as standing data is best described in the
market database maintained by PJM. Entities that are used to Figure 3 – PJM Areas and Zones
describe aspects of the market product and operations include:
class CSM_AreaZoneModel

• energy & ancillary services product, areas, zones, IdentifiedObject

pricing nodes, EnergyScheduling::HostControlArea


{leaf}

+ areaControlMode: AreaControlMode
+ freqSetPoint: Frequency

• components supporting the market definition and + frequencyBiasFactor: FreqBiasFactor

+hostControlArea 1 MarketOperations ::ResourceGroup


Colle ction

operation (thresholds, authority, market timeline, 1


+ availableSpinPercen t: Percent = 0.00
{leaf}

calendar), ControlArea
IdentifiedObject

+controlArea
+
+
+
controlArea: Reference
internalArea: Boolean = FALSE
internalAre aDay: Date


+ hostControlAre a: Reference* + operatingReserve Req: Reference*

and components usually initialized by an external +


+
internalControlArea : Boolean = FALSE
internalControl AreaDay: Date
1 0..*
+
+
regulationCostAdd er: Money = 0.00
regulationReq : Reference*

facing market participant registry, such as


+ regulationSpinPerce nt: Percent = 0.00
+ requirements: Reference*
+ sequenceNumber: int*

generators, demand response resources, and +


+
spinCostAdder: Money = 0.00
spinningReserveReq: Reference*

participant managed pricing pnodes. +resourceGroup 1 +resourceGroup 1+resourceGroup 0..*

0..* 0..*

To build a CIM compliant commercial model, it requires the 0..*


PNode
IdentifiedObject IdentifiedObject
MarketOpe rations::
Resource GroupReq

following steps:
IdentifiedObject
+ bidVirtual: Enume ratedType = NoBid
Reserv eZone + resourceGroup : Reference*
+ caseInjection: Boolean = FALSE
+ sequenceNumber: int

• Collect and consolidate model data from the existing


+ remainingCapabilit y: PerCent = 0.0 + factors: Reference*
+ reserveRequirement: ActivePower = 0.0 + nodalReferencePri ce: Money = 0.00
+ resourceGroup : Reference* + ownerParticipan t: Reference*

BSCs, which were implemented by different venders


+ privateToISO: Boolean = FALSE
+pnode + purposeType: String = B
+reserveZone 1 + resourceGroup : Reference*

at different time.
0. .1 + sequenceNumber: int

• Map the consolidated model to CIM/CME. 0..*

• Carefully extend the CIM to model those specials. IdentifiedObject


MarketOpe rations:: 0..*
IdentifiedObject
Registere dResource DispatchZone
+resources +dispatchZone
+ dispatchZone : Reference + fixedSteam: Boolean = FALSE

For example, PJM has the following areas and zones as shown +
+
+
ownerParticipan t: Reference* 0..*
pnode: Reference
reserveZone: Reference
1 +
+
+
genEmergencyCondition: EnumeratedType = Normal
gpmEnabled: B oolean = FALSE
resources: Reference*

in Figure 3. + rtoID: String

• Market Control Zone - A region comprised of


market resources (generators and load response) Figure 4 – Extend CIM to model PJM areas and zones
Figure 4 shows how standard CIM package is extended to • Governance
support PJM model. • Business Processes Streamlining

It is important to note that the purpose of such a master model Technology:


is to standardize the interface data transfer messages between • Design & Architecture
major system components. It does not aim at building a full • SOA Technologies
commercial data model to reflect the entire market database. • Standards (CIM)
• Best Practices
Adapters are implemented for each BSC to produce or
consume these standardized messages while within each BSC
it is allowed to use native data communication.

An SOA project is a model driven integration process, which People


requires all parties work closely with each other. Figure 5
shows the general process for an SOA implementation with
CIM compliant message definitions.

gy
Pro
• Create Business Process • Gather Interface Inventory
Flows • Determine Interface Scope

olo
c
ess

hn
• Interface Discovery and
• BSP Discovery

c
Documentation

es

Te
• Create Relational Model and Map to
• BSP Requirements CIM
• Generate UML Model

• BSP Design • Message Design Figure 6 – SOA project experiences

• Message Generation

• BSP and Message Review/Validation


• Sign-off V. CONCLUSION
• BSP Implementation
This paper describes the roles of CIM/CME in the future
• BSP Adapter Design
• BSP Adapter Implementation
Market management systems. Although CIM is still an
evolving standard, it is providing great benefits in terms of
system common source modeling and data interfaces. CIM is
Figure 5 – Process for CIM compliant ESB data transfer the key for smart grid implementation.
design and implementation

IV. SOA PROJECT EXPERIENCES VI. ACKNOWLEDGMENT


The views expressed in this paper are solely those of the
While CIM based SOA technology has many obvious authors, and do not necessarily represent those of AREVA and
advantages in terms of system integration and modeling, PJM.
making an SOA project successful is a challenging task.
VII. REFERENCES
The three key factors for a successful SOA project are People,
[1] IEC Common Information Model standard package. IEC Standards
Processes and Technology. 61970-301, 61970-501, 61970-452, 61970-552-4, www.iec.ch.
[2] J.P. Britton, “Designing Model Exchange Processes with CIM and
People: ‘RMA sets’”, in Power Systems Conference and Exposition 2006, 2006
• Domain Knowledge IEEE PES, Oct. 2006, pp. 487-489
• IT Skills
• Change Management
• Culture and Organization
VIII. BIOGRAPHIES
Processes:
• Collaboration Xing Wang received his B.S from North China University of
• Methodologies Electrical Power in 1991, his M.S. from China Electrical Power
Research Institute (CEPRI) in 1996 and his Ph.D. from Brunel
University, UK in 2001, all in Electrical Engineering. He worked at
CEPRI on Energy Management System development and project
delivery from 1991 to 1998. He joined AREVA T&D Inc. in 2001.
Since then he has been working as technical team lead for several
Market Management System projects. Dr. Wang is a senior expert of
AREVA T&D and a senior member of IEEE.

But-Chung Chiu received his B.E.E. from University of Minnesota


and his M.A.Sc from University of British Columbia. He worked ten
years in the utility sector including China Light and Power,
Edmonton Power and British Columbia Hydro and Power Authority.
He joined AREVA T&D Inc. in 1986 and is responsible for
delivering software systems to electrical utility customers.

You might also like