Integrating Bulk Power Generation Assets

into the Common Information Model

3002006661

14635805
14635805
 Integrating Bulk Power
Generation Assets
into the Common
Information Model

EPRI Project Manager

J. Thibault

3420 Hillview Avenue

Palo Alto, CA 94304-1338
USA

PO Box 10412
Palo Alto, CA 94303-0813
USA

800.313.3774
650.855.2121

[email protected] 3002006661
www.epri.com Technical Update, December 2015
14635805
DISCLAIMER OF WARRANTIES AND LIMITATION OF LIABILITIES

THIS DOCUMENT WAS PREPARED BY THE ORGANIZATION(S) NAMED BELOW AS AN ACCOUNT OF

WORK SPONSORED OR COSPONSORED BY THE ELECTRIC POWER RESEARCH INSTITUTE, INC. (EPRI).
NEITHER EPRI, ANY MEMBER OF EPRI, ANY COSPONSOR, THE ORGANIZATION(S) BELOW, NOR ANY
PERSON ACTING ON BEHALF OF ANY OF THEM:

(A) MAKES ANY WARRANTY OR REPRESENTATION WHATSOEVER, EXPRESS OR IMPLIED, (I) WITH RESPECT
TO THE USE OF ANY INFORMATION, APPARATUS, METHOD, PROCESS, OR SIMILAR ITEM DISCLOSED IN
THIS DOCUMENT, INCLUDING MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, OR (II) THAT
SUCH USE DOES NOT INFRINGE ON OR INTERFERE WITH PRIVATELY OWNED RIGHTS, INCLUDING ANY
PARTY'S INTELLECTUAL PROPERTY, OR (III) THAT THIS DOCUMENT IS SUITABLE TO ANY PARTICULAR USER'S
CIRCUMSTANCE; OR

(B) ASSUMES RESPONSIBILITY FOR ANY DAMAGES OR OTHER LIABILITY WHATSOEVER (INCLUDING ANY
CONSEQUENTIAL DAMAGES, EVEN IF EPRI OR ANY EPRI REPRESENTATIVE HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES) RESULTING FROM YOUR SELECTION OR USE OF THIS DOCUMENT OR
ANY INFORMATION, APPARATUS, METHOD, PROCESS, OR SIMILAR ITEM DISCLOSED IN THIS DOCUMENT.

REFERENCE HEREIN TO ANY SPECIFIC COMMERCIAL PRODUCT, PROCESS, OR SERVICE BY ITS TRADE
NAME, TRADEMARK, MANUFACTURER, OR OTHERWISE, DOES NOT NECESSARILY CONSTITUTE OR IMPLY
ITS ENDORSEMENT, RECOMMENDATION, OR FAVORING BY EPRI.

THE ELECTRIC POWER RESEARCH INSTITUTE (EPRI) PREPARED THIS REPORT.

This is an EPRI Technical Update report. A Technical Update report is intended as an informal report of
continuing research, a meeting, or a topical study. It is not a final EPRI technical report.

NOTE

For further information about EPRI, call the EPRI Customer Assistance Center at 800.313.3774 or
e-mail [email protected].

Electric Power Research Institute, EPRI, and TOGETHER…SHAPING THE FUTURE OF ELECTRICITY are
registered service marks of the Electric Power Research Institute, Inc.

Copyright © 2015 Electric Power Research Institute, Inc. All rights reserved.

14635805
 Acknowledgments
The Electric Power Research Institute (EPRI) prepared this
report.

Principal Investigators
P. Brown
G. Gray
C. Huff
J. Simmins

This report describes research sponsored by EPRI.

This publication is a corporate

document that should be cited in the
literature in the following manner:

Integrating Bulk Power Generation

Assets into the Common Information
Model.
EPRI, Palo Alto, CA: 2015.
3002006661.
 iii 

14635805
14635805
Abstract
The Electric Power Research Institute (EPRI), member utilities,
vendors, and other stakeholders have invested millions of dollars over
the past two decades in the common information model (CIM)—an
electric utility industry-standard semantic model—and have reaped
dividends in the form of saved development and integration costs.
However, CIM application and development has been mainly in the
transmission and distribution domain, excluding the CIM from
being of direct value to bulk power generation.

Much of what has been accomplished in transmission and

distribution provides a good foundation for bulk power generation to
build on, but a great deal of work remains to be done in identifying
generation domain functions and information flows, modeling the
data needed to support them, and creating standards describing the
model.

The CIM for generation standards would support a range of data

models, focused on operation, maintenance, planning, environmental
monitoring, and scheduling in order to facilitate the sharing of
information among the software applications used in the generation
domain.

This report describes work that has been accomplished toward the
goal of a generation CIM, including case studies; describes the
background of the CIM, core technologies, and available tools; and
outlines a four-year plan to work toward an internationally accepted,
standard semantic model with comprehensive support for bulk power
generation. The work would consist of two concurrent efforts that
would produce usable results within the first year.

Keywords
Common information model (CIM)
Data model
Generation standards
Semantic model
Unified Modeling Language (UML)

v

14635805
14635805
Table of Contents

Section 1: Introduction ........................................ 1-1

Section 2: The Case for a Semantic Model in Bulk

Power Generation .............................. 2-1
Summary of Success Stories Using CIM Solutions ........... 2-1
Summary of Past EPRI CIM Projects .............................. 2-4
EPRI: A Long-Term CIM Supporter ........................... 2-4
EPRI: CIM Projects................................................. 2-4
EPRI: and Interoperability Testing ............................ 2-5
The Cost of Missing Generation Assets and Systems in
the CIM .................................................................... 2-6

Section 3: Generation Domain Case Study:

Enhanced Operator Rounds ................ 3-1
Operator Rounds Scenario .......................................... 3-2
Comparison ......................................................... 3-4
CIM and the Work Management Ecosystem ............ 3-4
Work Order Advancement .................................... 3-5
Technical Components .......................................... 3-6

Section 4: Overview of the Common Information

Model ................................................. 4-1
What is the CIM? ....................................................... 4-1
Enterprise Service Bus ........................................... 4-4
CIM UML .................................................................. 4-4
Quick Introduction to UML ..................................... 4-4
CIM Identity and Naming ...................................... 4-9
CIM Units and Language ..................................... 4-10
CIM Geographical Data ...................................... 4-11
Asset Versus Power System Functional Role in CIM . 4-11
CIM Network Modeling....................................... 4-11
Diagram Layouts in CIM ...................................... 4-16
CIM Modeling of Assets ...................................... 4-16

 vii 

14635805
 CIM Packages Overview........................................... 4-22
IEC 61970-301 .................................................. 4-22
IEC 61968-11 .................................................... 4-22
IEC 62325-301 .................................................. 4-22
Contextual Modeling ................................................ 4-23
Deriving Profiles ................................................. 4-23
CIM Standard Profiles ......................................... 4-23
CIM Data Exchanges ................................................ 4-25
Current International Electrotechnical Commission
CIM Committees and Working Groups ....................... 4-25
Technical Committee 57 ...................................... 4-25
Standards Process ............................................... 4-26

Section 5: Next Steps for Semantic Model

Development in Generation ................ 5-1
CIM for Generation: Plan Summary .............................. 5-1
Background on Generation CIM Development ......... 5-2
Initiative Details ......................................................... 5-5
Adding Generation Assets to WG14’s Scope–
Leveraging Existing CIM Assets and Work Models ... 5-5
Creating a Bulk Power Generation Family of
Standards: Building a CIM to Fully Support
Generation Systems .............................................. 5-9
Summary................................................................. 5-11

Section 6: Bibliography ...................................... 6-1

Appendix A: 61968 Asset Templates for

Interoperability .................................. A-1
Template for SF6 Breaker ............................................ A-1
Template for Two Winding Transformer ........................ A-2

Appendix B: Success Stories: Using Common

Information Model Solutions ............... B-1
Success Story: The Green Button Standard .................... B-1
Success Story: Southern California Edison Uses
CIM for Green Button Support ................................ B-2
Success Story: Consumers Energy ................................ B-2
Success Story: Long Island Power Authority ................... B-3
Success Story: Idaho Power Company .......................... B-4
Success Story: Sempra Energy ..................................... B-6

 viii 

14635805
 Appendix C: Technical Considerations Related
to Adding Generation Assets to the
Common Information Model ............... C-1
Summary of CIM Asset Health Model ........................... C-1
CIMug Asset Health Focus Community .................... C-2
Asset Templates for Interoperability ......................... C-5
Support for History ................................................ C-7

Appendix D: Technical Consideration for Using

the EPRI Master Equipment List Report
(1025340) for Development of
Generation Systems in the Common
Information Model .............................. D-1
Rationalizing Master Equipment List to CIM ............. D-3

Appendix E: Description of EPRI Preventive

Maintenance Basis Database in
Relation to the Common Information
Model ................................................. E-1
Preventive Maintenance Basis Database ........................E-1
PMBD Purpose ............................................................E-1
PMBD Data Sources ...............................................E-5

 ix 

14635805
14635805
List of Figures

Figure 3-1 Work management system simplified

ecosystem showing CIM interfaces ............................... 3-5
Figure 3-2 CIM createMaintenanceOrders integration
example .................................................................... 3-7
Figure 3-3 CIM getMaintenanceOrders integration
example .................................................................... 3-7
Figure 3-4 WorkTasks portion of a MaintenanceOrders
message ................................................................... 3-8
Figure 3-5 WorkLocation portion of the CIM
MaintenanceOrders message .................................... 3-10
Figure 3-6 InternalLocation portion of the CIM
maintenanceOrders message .................................... 3-11
Figure 4-1 Communications between enterprise applications 4-3
Figure 4-2 Enterprise service bus model for
inter-application communication................................... 4-4
Figure 4-3 Circle object .................................................... 4-5
Figure 4-4 Class hierarchy for diagram shapes ................... 4-6
Figure 4-5 Class hierarchy of diagram shapes with a Style... 4-7
Figure 4-6 Aggregation example with Layer and Shape ....... 4-8
Figure 4-7 IdentifiedObject class with Name Class .............. 4-9
Figure 4-8 Example Circuit as a Single Line Diagram ........ 4-12
Figure 4-9 Example Circuit with Partial CIM Class
Mappings ............................................................... 4-13
Figure 4-10 Example circuit with complete CIM class
mappings ................................................................ 4-15
Figure 4-11 Basic asset and asset component identification:
UML and instance representation ............................... 4-17

 xi 

14635805
 Figure 4-12 Basic asset plus model and asset-specific
characteristics: UML and instance representation ......... 4-19
Figure 4-13 Asset plus asset-related activities and results –
UML and instance representation ............................... 4-21
Figure 4-14 Example information to contextual models ...... 4-24
Figure 5-1 Overview of transmission and distribution
domain systems, business functions, and their applicable
CIM standards ........................................................... 5-3
Figure 5-2 Vision of generation domain systems, business
functions, and their use of existing and future CIM
standards .................................................................. 5-4
Figure 5-3 Schedule of tasks that shows how they would fit
into a staged effort to bring bulk power generation
assets into the CIM ..................................................... 5-6
Figure 5-4 A simple schedule for developing a new set of
generation standards ................................................ 5-10
Figure A-1 Template for SF6 breaker ................................. A-1
Figure A-2 Template for two winding transformer ................ A-2
Figure C-1 Model-driven integration vision for asset health
assessment ................................................................ C-4
Figure C-2 Overview of 61968 asset health model with
proposed asset health focus community extensions ......... C-5
Figure C-3 Template for SF6 breaker ................................. C-6
Figure C-4 Template for two winding transformer ................ C-7
Figure C-5 Leveraging the proposed CIM change model for
asset history exchange ................................................ C-8
Figure D-1 Hierarchical structure of data in the master
equipment list, developed by EPRI in 2012 ................... D-1
Figure E-1 PMBD vulnerability input ....................................E-4
Figure E-2 PMBD vulnerability output ..................................E-4
Figure E-3 PMBD equipment failure mode............................E-6

 xii 

14635805
List of Tables

Table 1-1 Summary of the sections in this report .................. 1-2

Table 2-1 CIM value reported by member utilities ............... 2-2
Table 3-1 Comparison of diagnosis of a faulty transformer
cooling fan ................................................................ 3-3
Table D-1 Examples of master equipment list elements
to be converted into the Medium class .......................... D-3
Table E-1 EPRI PMBD asset scope .......................................E-3

 xiii 

14635805
 Section 1: Introduction
The Electric Power Research Institute (EPRI), member utilities, vendors, and
other stakeholders have invested millions of dollars over the past two decades in
the common information model (CIM)—an electric utility industry-standard
semantic model—and have reaped dividends in saved development and
integration costs. However, CIM application and development has been mainly
in the transmission and distribution domain, excluding the CIM from being of
direct value to bulk power generation.

The “low-hanging fruit” being interoperability of disparate systems in a vendor-

agnostic implementation. Data flows into many systems could be automated, but
A semantic model-based
current functionality requires a person to evaluate the output and determine next
integration has much to
actions because of integration challenges that could be handled by a semantic
offer the bulk power
model.
generation domain in terms
of facilitating business EPRI produced a video in 2015 to demonstrate the potential application of these
processes, improving technologies in a bulk power generation environment—leveraging a common,
efficiency, avoiding error, semantic model. EPRI made the video available to the public via the EPRI
and increasing the ability to YouTube channel: https://www.youtube.com/watch?v=fkslM37EcXA.
extract useful information
from data. From the experience gained in the transmission and distribution domains,
however, creating a solid standard semantic model for an industry domain is no
small task. Much of what has been accomplished in transmission and distribution
provides a good foundation on which bulk power generation can build, but there
is still a large amount of work to be done in identifying generation domain
functions and information flows, modeling the data needed to support them, and
creating standards describing the model. Table 1-1 presents a description of each
of the following sections of this report.

 1-1 

14635805
 Table 1-1
Summary of the sections in this report

Report Section Summary

Section 2: The Case for a Semantic Users of the CIM have already experienced real benefits from using
Model in Bulk Power Generation the CIM in transmission and distribution systems. The addition of
bulk power generation assets and systems represents an opportunity
to leverage investments that members have made in the CIM in
other areas.
Section 3: Generation Domain This section details an operator rounds scenario enhanced by
Case Study: Enhanced Operator automated systems that are integrated using the CIM. This is based
Rounds on a video that was posted to YouTube by EPRI in September
2015.
Section 4: Overview of the Previous sections provided an understanding of the potential of an
Common Information Model industry-standard CIM. This section describes what the CIM is, how
it works, and how it is built.
Section 5: Next Steps for Semantic This section reflects the analysis done by EPRI staff into expanding
Model Development in Generation the scope of the CIM to adequately cover bulk power generation
integration challenges. This plan will produce usable results within a
year of initiation and a more comprehensive semantic model two
years from the start.
Section 6: Bibliography This section contains references that were used in preparing this
report.
Appendix A: 61968 Asset This appendix consists of two templates that are referred to in the
Templates for Interoperability report.
Appendix B: Success Stories Using Details of successful uses of the CIM by EPRI member utilities are
Common Information Model presented in Appendix B.
Solutions
Appendix C: Technical This appendix presents technical details of the “adding generation
Considerations Related to Adding assets to the CIM” through collaboration with the International
Generation Assets to the Common Electrotechnical Commission (IEC) Technical Committee 57 –
Information Model Working Group 14 described in the “Next Steps for Semantic
Model Development in Generation” section.
Appendix D: Technical A collection of observations by EPRI technical staff after evaluating
Consideration for Using the EPRI EPRI Report 1025340 to support the “development of generation
Master Equipment List Report systems within the CIM” effort described in the “Next Steps for
(1025340) for Development of Semantic Model Development in Generation” section is the content
Generation Systems in the Common of Appendix D.
Information Model
Appendix E: Description of EPRI This appendix presents a collection of observations by EPRI
Preventive Maintenance Basis technical staff after evaluating the EPRI Preventive Maintenance
Database in Relation to the Basis Database (PMBD) to support the “adding generation assets to
Common Information Model the CIM” through collaboration with the IEC Technical Committee
57 – Working Group 14 described in the “Next Steps for Semantic
Model Development in Generation” section.

 1-2 

14635805
 Section 2: The Case for a Semantic Model
in Bulk Power Generation
EPRI, member utilities, vendors, and other stakeholders have invested millions
of dollars over the past two decades in the CIM and reaped dividends in saved
development and integration costs.

Without a CIM, those responsible for procuring new solutions are left to either
Modifying the common develop point-to-point messaging by hand or depend on a single vendor to
information model would be provide an end-to-end solution. Those solutions represent the worst extremes:
a significant undertaking, either having to constantly reintegrate solutions into enterprise systems with each
but there are reasons to patch or give up technical independence to a third party with their own interests.
expect that the return on With a CIM, system integrators would be able to maintain confidence that
investment would be future solutions could be mapped to a common semantic model, allowing
realized quickly based on enterprise systems to be more sustainable.
previous experience.
Summary of Success Stories Using CIM Solutions

Table 2-1 summarizes member utilities that reported value from the CIM.
Greater details on each of these are in Appendix B.

 2-1 

14635805
 Table 2-1
CIM value reported by member utilities

Member CIM Implementation Value Derived

Southern SCE engaged Xtensible Solutions to support Open Automated Data CIM-based Green Button standards ensure that
California Exchange (OpenADE) and North American Energy Standards Board implementations are interoperable with each other,
Edison (SCE) (NAESB) groups working on the Energy Services Providers Interface drastically reducing interoperability costs.
(ESPI) / Green Button specification. The goal was to choose objects
from the meter reading package of the IEC’s CIM as the basis for the
objects to be exchanged.
Consumers Consumers Energy started to build an Enterprise Semantic Model Major benefits the company recognized are: eliminating
Energy (ESM) based on the CIM whose Unified Modeling Language (UML) duplicate integration work, reusability of a common
classes and attributes in the standard became building blocks for data model, cost savings in integration and support,
message payload definitions for integrations. As a result, a easier communication across multivendor landscapes,
semantically consistent common language is provided for exchanging and leveraging vendor’s CIM-based solutions for
data information across platforms and systems within the enterprise. integration.
Long Island As part of LIPA’s SmartGrid program, key business drivers are to The LIPA Model-Driven Semantic Integration approach
Power reduce the cost and complexity of the development and maintenance has consistently performed under budget and on time
Authority of integration solutions and data repositories, enable the ability to under complex and challenging conditions. Changes to
(LIPA) integrate LIPA data among multiple service providers, and implement implemented solutions are accomplished in a fraction of
“Best of Breed” applications. the time traditional Service-Oriented Architecture (SOA)
approaches would take.
All new projects are adopting the architecture and
methodology.

 2-2 

14635805
 Table 2-1 (continue)
CIM value reported by member utilities

Member CIM Implementation Value Derived

Idaho Power Based on the CIM UML model, IPC developed an ESM that provided The consequence is that the CIM standards, with the
Company (IPC) the capability to include private extensions and other modifications proper tools to manage their use, provide not only a
needed to the standard CIM model. The CIM-based ESM then scalable, maintainable integration framework, but one
provided a common set of semantics and data definitions from which that becomes more cost effective with each new system
all needed system interactions could be defined as XML schemas. The integration.
integration framework, then, comprised an Enterprise Service Bus (for
example, TIBCO) with data adapters at each system interface to
transform the data from the internal system representation to the ESM
representation.
Sempra The goal is to manage its vast business data, information, and Because each new system integration is able to build
Energy Utilities knowledge as corporate assets. To that end, Sempra established an from the existing ESM from earlier projects through
(SEU) Enterprise Information Management (EIM) strategy and business case reuse, the amount of work to define system interactions
in 2007 in order to realize the value of these corporate assets in decreases with each new project.
support of optimized business performance. The EIM used CIM
standards that consist of an information model and multiple message
definitions that are derived from the model, ensuring a single source
definition of each data element for all information exchanges.

 2-3 

14635805
 Summary of Past EPRI CIM Projects

EPRI was instrumental in the conception of the CIM, and the CIM is playing a
larger role in the collaboration among EPRI, its members, and industry
stakeholders.

EPRI: A Long-Term CIM Supporter

The CIM grew out of the collaboration spawned by an EPRI operating training
simulator project in the early 1990s. In its early days, the CIM—then called the
Control Center Application Programming Interface (CCAPI)— focused
primarily on modeling the configuration data required by Energy Management
Systems (EMSs). The goal was to describe the data required by the automatic
generation control, Supervisory Control And Data Acquisition (SCADA),
network analysis and operator training simulator functions in a standard fashion
so that utilities could buy and integrate best-of-breed EMS functions from the
vendor of their choice instead of being trapped into single-vendor solutions.

The rise of semantic model-based enterprise application integration in the

mid-1990s coincided with the transition of the CCAPI to the stewardship of the
IEC, a move that EPRI actively supported. Initially, the CIM consisted of only
the IEC 61970 standard (focusing on EMS and network analysis data)
maintained by WG13. Over the course of the next 10 years, the CIM expanded
to include other utility operational areas (such as assets, work, and metering)
under the auspices of WG14 and to include markets under the guidance of
WG16. EPRI has provided one or more staff to serve as experts on WG13 since
its inception and has provided experts for WG14 for the last 10+ years.

In addition to active participation in WG13 and WG14, EPRI has supported

initiatives for advancement of the CIM in specific areas, which are described
next.

EPRI: CIM Projects

CIM for Planning grew out of the industry need to exchange network models in
the Transmission planning domain as well as in the control center domain. This
initiative resulted in the extension of the model to support the description of
network model data in bus/branch (simplified) form in addition to breaker/node
EMS level detail. The IEC 61970-456 standard was created as a result of this
work.

CIM for Dynamics was a multi-year, multi-utility, multi-vendor, cross-continent

initiative that resulted in the definition of exchange standards for network
analysis dynamics (subcycle) behavior models. IEC standards 61970-302 and
61970-457, which contain the models defined by this work, are currently being
drafted by WG13, and EPRI is serving as an editor for one of the standards.

 2-4 

14635805
 CIM for Environmental Data is proposing a new IEC 62325-family standard
that models the forecasts, observations, and alerts common to the weather
information used for a variety of purposes across the utility. This work grew out
of a an EPRI project funded by Southern California Edison.

Asset Health is an area of growing importance across the utility industry from
Transmission and Substations to Distribution to Generation, all of which have
expensive and aging assets to manage and maintain. EPRI is co-leading the
CIMug Asset Health Focus Community, which is currently proposing
enhancements to the CIM in several areas (for example, support for history,
templates for commonly used breakers and transformers, and inputs and outputs
of asset health analytics). The work of the Asset Health Focus Community will
result in publication of Edition 2 of 61968-4.

CIM-MultiSpeak harmonization is of interest to smaller utilities that have

implemented products with MultiSpeak interfaces. MultiSpeak is the utility
messaging standard developed by the National Rural Electric Cooperative
Association (NRECA). EPRI has done work in the metering area to rationalize
CIM model descriptions with those of MultiSpeak, and the IEC 61968-14
standard is a result of this work.

Network Model Management is an area of growing interest to utilities in which

the data models of the 61970 standard can provide enormous benefit. As the
most mature part of the CIM, the network model classes of 61970 describe a
data organization strategy that is extremely useful in supporting effective,
integrated management of network analysis data across the utility enterprise.
Better management of network model data is a foundational enabler of the
analytics on which the future grid will depend. Through a series of projects over
the last three years, EPRI has been increasing industry awareness and promoting
industry adoption of CIM-based approaches to network model data
management. The knowledge gained from the “real-world” results of this work
have influenced the direction of a number of the 61970 standards.

Field Force Visualization using Augmented Reality techniques is another area in

which application of the data models of the CIM could provide enormous
industry benefit. CIM data exchange standards allowing mobile (or wearable)
devices to easily access asset, work, and network model data provide a key enabler
to widespread deployment. EPRI pilot projects done in this area have moved the
standards organizations toward inclusion of JavaScript Object Notation (JSON)
as one of the standard-specified serialization technologies.

EPRI: and Interoperability Testing

Over the last two decades, EPRI has supported interoperability testing of the
CIM in a variety of ways. One of the most significant has been the funding of
the test director for more than 15 interoperability tests covering data exchange
related to transmission and distribution power system models, dynamics data,
and metering data. EPRI has also created a test harness for validating for
61868-style (XML Schema) messages. Current activity is focused on establishing

 2-5 

14635805
 a formal CIM compliance and certification testing structure under the auspices of
Utility Communications Architecture (UCA) International Users Group
(UCAIug) in accordance with the Smart Grid Interoperability Panel (SGIP)
framework for testing and certification. 61968-9 (metering) messages will be the
first area for which compliance and certification programs are established.

The Cost of Missing Generation Assets and Systems in the CIM

The origins of the CIM were in power distribution, transmission, and—most

recently—in grid operability. As such, the model has extensive reach into those
assets and systems; but the bulk generation asset modeling is limited to their role
in the power grid. Foundational assets and systems remain unrepresented in the
CIM. This limits the scope of the CIM and ability for member utilities to
leverage a common semantic model in a truly end-to-end fashion.

A constellation of mobile computing and internet-of-things (IoT) solutions

With a common information coming into industrial settings holds much promise for improving maintenance
model, system integrators and operations of bulk generation facilities. However, integration challenges
would be able to maintain prove to be an insurmountable obstacle for some promising projects. Without a
confidence that future CIM, those responsible for procuring new solutions are left to either develop
solutions could be mapped point-to-point messaging by hand or depend on a single vendor to provide an
to a common semantic end-to-end solution. Those solutions represent the worst extremes: either having
model, allowing enterprise to constantly reintegrate solutions into enterprise systems with each patch or give
systems to be more up technical independence to a third-party with their own interests.
sustainable.
A CIM that can support bulk power generating facilities and assets would lower
these barriers and open up a greater array of solutions for the integration of new
technologies within enterprise systems supporting generation.

 2-6 

14635805
 Section 3: Generation Domain Case
Study: Enhanced Operator
Rounds
The ability to interdict expensive failure with less expensive solutions is the
justification for the application of condition-based maintenance (CBM),
predictive maintenance (PDM), and online monitoring through the use of
handheld devices and wearables over a wireless network. Even with these
solutions, there is still significant overhead in processing all of the data generated
by these techniques and performing the proper messaging. In most cases,
solutions come from disparate vendors, and few of them have common links with
the central systems (for example, maintenance, operations, and scheduling).

The current, common practice is to take a process that was once analog (that is,
The return on investment paper-based procedures) and incorporate digital technology to facilitate the
from these methods comes process.
from paperwork
elimination, lowering effort
EPRI has been working with member utilities to build an automated diagnostic
for data entry, and making
program—the Fleet-Wide Prognostics and Health Management (FW-PHM)
archiving and long-term
suite—that includes a Diagnostic Advisor that uses a case-based reasoner to
analysis easier. However,
evaluate equipment condition data against failure signatures in the Asset Fault
the current state of the art
Signature (AFS) database. Although data flows into this system could be
relies solely on people to
automated, current functionality requires a person to evaluate the output and
receive, acknowledge, and
determine next actions because of integration challenges that could be handled by
make decisions about
a semantic model.
messages from the system.
EPRI produced a video in 2015 to demonstrate the potential application of these
technologies with the application of augmented reality. EPRI made the video
available to the public via the EPRI YouTube channel:
https://www.youtube.com/watch?v=fkslM37EcXA.

 3-1 

14635805
 Operator Rounds Scenario

In this scenario, the cooling fan on a station transformer is damaged and,

subsequently, slightly imbalanced—perhaps through some foreign object damage.
In the overall scheme of transformer operation, a single fan in the cooling fan
bank is not the most operationally consequential nor is it difficult to repair. It is
also still functioning, even if slightly imbalanced. However, if the problem is left
to develop, the remedy would be more expensive if the fan were to fail
catastrophically.

Because of this, these fans are included in operator rounds performed once per
shift. Table 3-1 compares a current state-of-the-art generation scenario using
handhelds and wearables with another scenario to the same technology integrated
into an automated diagnostics system (FW-PHM) that are all mapped to the
CIM with power generation components added.

This scenario starts with an operator who walks up to the transformer as part of
their operator rounds and notices excessive noise coming from the area around
the cooling fans. Using a wearable device, he scans the tag on the equipment and
selects “Cooling Fans/Motors: Excessive Noise/Vibration” from the “As-Found”
dialog initiating the work order process within the computerized maintenance
management system (CMMS).

 3-2 

14635805
 Table 3-1
Comparison of diagnosis of a faulty transformer cooling fan

Current State CIM State

Day 1: The work order now sits in the CMMS system until a maintenance After the operator inputs the observation, he is asked to stand by
manager receives the message. She calls up the Diagnostic Advisor and momentarily. In seconds, the work order system messages the
notes that an acoustic analysis has not been performed recently. She then Diagnostic Advisor who examines operational data and recent
puts in another work order to send out a technician to examine the maintenance history and incorporates the operator’s observation. The
problem and determine whether a replacement is necessary. Diagnostic Advisor logic then produces a request for acoustic analysis.
Day 2: The technician locates the source of the noise and takes a This message is picked up by the operator’s wearable device that
recording. He then runs a Fast Fourier Transform (FFT) on a handheld confirms that the appropriate audio recording capabilities are present.
device. The FFT results suggests an imbalance. He then has to manually This process take a few seconds and then the operator is prompted to
enter in the findings into the maintenance system. take a video and open-air acoustic analysis. He hones in on the
Total time elapsed: 2 days highest level with the excessive noise and calls up a recording, which
takes a few seconds. The data is then sent to a diagnostic program
that runs the sound through FFT. The FFT results suggests an imbalance.
Total time elapsed: 3 minutes
The technician attaches the files to a work order and initiates a separate The operator is then prompted to confirm that there are no safety
request in the system to have the fan replaced. The fan is replaced the issues. All of the data are immediately available to the utility’s
following day. centralized monitoring and diagnostics (M&D) center, where a motor
Total time elapsed: 3 days expert analyzes data and passes along her conclusion—in an email to
the maintenance manager—that the fan should be replaced
immediately. The maintenance manager concurs and the fan is
replaced the following day.
Total time elapsed: 1 day

 3-3 

14635805
 Comparison
By using a CIM, the
messaging among In two days, a bad situation can become catastrophic. That is the most obvious
disparate systems can be comparison. However, a key difference is that there is an expense of time
standardized, enabling involved in the current state with messaging and reasoning that is automated in
automation. Without a the CIM state.
CIM, messages are not
standardized and data CIM and the Work Management Ecosystem
transfer is likely handled
manually by people making There have been significant advances in the mobility space, particular with
simple decisions that would wearable computers. Although some utilities are still using paper forms in the
often be more efficient to field, many utilities have been using various mobile solutions or devices such as
optimize hardened laptops to gather data, which have been important steps and have all
made positive contributions in the mobile workspace. However, challenges
remain. Hardened laptops are significantly more expensive relative to their
commercial counterparts, both for acquisition and for the “care and feeding” of
the applications.

As smart phone and wearable computer capabilities continue to advance (and

importantly—the app paradigm), the increase of cellular coverage and advances
in augmented reality have all contributed to what has become an innovation
explosion in the wearable computer space.

The advantage of a wearable computer is that it allows the worker to remain

hands free, freeing their hands to do actual maintenance, if required, and also
allows the worker to keep their personal protective equipment on their hands,
while still freeing them to interact with the wearable computer.

CIM fits into this space in the application integration messaging infrastructure.
Looking at Figure 3-1, mobile devices have existed for a while, although in the
past the device usually needed to be docked in order to exchange data with the
utility datacenter. Work management systems (WMSs) and asset management
systems (AMSs) have also existed for several years. In addition to new capabilities
being available for wearable computers and mobile devices, there are also new
capabilities in the CIM to support work orders.

 3-4 

14635805
 Figure 3-1
Work management system simplified ecosystem showing CIM interfaces

Work Order Advancement

In the past, when utilities needed to integrate WMS with other systems in the
enterprise, they had to rely on vendors that would either use a proprietary
interface (to help lock-in utilities) or the utility and/or integration consultants
would need to develop a custom interface. In 2013, the IEC published guidance
for utility application integration using IEC 61968 (the standard for distribution
systems). This standard is IEC 61968-100:2013 and gives guidance on using web
services for the creation of interfaces to support utility applications. Although
IEC 61968-100:2013 provides the guidance on the integration mechanisms,
other standards within the IEC family define the message payloads (the data)
Now, instead of having to that are exchanged in any given integration.
be locked in to a
proprietary interface or a In 2015, a new standard for work order–related messages was published: IEC
custom interface, a utility 61968-6:2015 Maintenance and Construction. This document specified
can now use a standards- maintenance order, work request, and service request messages.
based interface. This is
particularly important as the Because of the explosion in the wearable computer market, dozens of vendors
wearable computer space now offer numerous capabilities. This is similar to the desktop computer market
goes through a significant of the early 1980s, when there were dozens of vendors offering many types of
amount of churn. desktop computers. With the numerous startups, there will naturally be a

 3-5 

14635805
 “shaking out” in this market. Some vendors will not execute well or might be
The use of a standards- acquired by “bigger players.” In fact, for the utility, buying any particular vendor’s
based messaging device has some risk associated with it. However, the standards-based messaging
infrastructure is a “no- infrastructure reduces this risk. If the utility bought a wearable computer
regrets” decision for the platform with a vendor’s proprietary interface, and that vendor goes out of
utility. Instead of competing business, the investment would represent a sunk cost for the utility, which would
on the capabilities of a be left with the devices that they could use only as long as the devices still
proprietary interface, operated. But with a standards-based messaging infrastructure using CIM
vendors can instead standards IEC 61968-100:2013 and IEC 61968-6:2015, if a particular vendor’s
compete on the capabilities goes out of business, or if the utility chooses to change vendors, the utility need
of their particular device, only use a vendor that supports these standards. The devices may change, but the
cost, and service, while the messaging infrastructure remains the same.
utility can rely on a
messaging infrastructure Technical Components
that costs less to support
because it uses standards Although a full discourse on the contents of IEC 61968-6:2015 is beyond the
that support personnel can scope of this report, some important areas that illustrate the flexibility and usage
more easily understand. of CIM-based messaging should be highlighted. For example, for both the
generation example shown previously (operator rounds scenario) or for a first
responder scenario (field work doing a storm damage assessment), the web
services for the initial integration are the same. When a maintenance order is
created (either for maintenance on a piece of equipment or for work required in
the field), the naming convention is: createMaintenanceOrders as shown in
Figure 3-2. The user creates a work order and, behind the scenes, the
createMaintenanceOrders message is sent to the WMS. On receipt of the data,
the WMS sends a reply to the initiating user to indicate that the work order has
been created in the system (or an error if one occurs or if something has gone
awry).

Note: The whole class of messages contained in IEC 61968-6:2015 are referred
to generically as work order messages. For any given type of work, the given
messages may be one of MaintenanceOrders, ServiceRequests, or WorkRequests.
For the “Operator Rounds” scenario, these will typically be the
MaintenanceOrders version of a work order.

 3-6 

14635805
 sd Sequence Diagrams

Field Worker Work Management System

create(MaintenanceOrders)

reply(MaintenanceOrders)

Figure 3-2
CIM createMaintenanceOrders integration example

By the same token, the field worker could also call up (request) a given work
order to update the status or assets needed. Depending on the implementation, a
field worker might scroll through a selection of work orders that it is aware of,
and then passing the identifier (the CIM uses a standard identifier called a
master resource ID, or mRID) to query the WMS for one or more work orders
as shown in Figure 3-3. Again, when one or more mRID is passed using the
“get,” for each one, assuming successful operation, the data for any particular
work order are returned.

sd getMaintenanceOrders

Field Worker Work Management System

getMaintenanceOrders(mRID)

replyMaintenanceOrders()

Figure 3-3
CIM getMaintenanceOrders integration example

 3-7 

14635805
 Again, although an examination of the entirety of the MaintenanceOrders
message is beyond the scope of this report, a few areas bear examination that
highlight the flexibility of the messaging. One area is the “WorkTasks” portion
of the message, and the other is the “location” portion of the message. The
WorkTasks portion of the schema is shown in Figure 3-4. This is where data
such as the type of task or any assets associated with maintenance are entered.

Figure 3-4
WorkTasks portion of a MaintenanceOrders message

 3-8 

14635805
 How the information is entered or displayed is determined by any given vendor.
Figure 3-4 shows an example of what could be passed in the message. Dashed
lines indicate optional data items, while solid lines indicate required information.
For example, when a maintenance order is first created, the operator may have no
information about which crew may be assigned or what their estimated time of
arrival (ETA) might be. However, after the maintenance order has been created,
the operator might want to check on the status, and this information might be
filled in by whatever entity manages crew assignment.

The other portion of the work order message that bears examination is the “work
location.” The CIM provides a variety of mechanisms for annotating where work
will be performed, as can be seen in Figure 3-5.

 3-9 

14635805
 Figure 3-5
WorkLocation portion of the CIM MaintenanceOrders message

 3-10 

14635805
 The CIM provides for the usage of a coordinate system, or a traditional mailing
address (mainAddress), position points (the x, y, z for GPS systems) or an
internal location that can be used for plant locations. For example, for the
operator rounds scenario, the user could enter both the street address of the plant
and the building, floor, and room location for a particular piece of equipment (see
Figure 3-6).

Figure 3-6
InternalLocation portion of the CIM maintenanceOrders message

This sort of construct allows the flexibility of the CIM work order messages to
support maintenance request for either internal or external work locations.

 3-11 

14635805
Section 4: Overview of the Common
Information Model
This section of the report provides an overview of the CIM. Topics include the
general background of the CIM, its use as a semantic model, core technologies
often involved in its implementation, free and open-source tools available,
current IEC CIM committees and working groups and the scope of their work,
and a summary of past CIM work conducted by EPRI, as well as presenting
success stories from several utilities. Information in this section is synthesized
from the following EPRI reports:
 Common Information Model Primer: Third Edition. EPRI, Palo Alto, CA:
2015. 3002006001.
 The Standards Based Integration Specification: Breaker Modeling for Asset Health
Using the CIM. EPRI, Palo Alto, CA: 2012. 1024297.
 CIM Training by Alan McMorran, EPRI Power Quality and Smart
Distribution 2012 Conference and Exhibition.
 Standard Based Integration Specification: A Reference Architecture and Basic Asset
Model in Support of Asset Health Analysis. EPRI, Palo Alto, CA: 2013.
3002000607.
 Standard Based Integration Specification: Common Information Model
Framework for Asset Health Data Exchange. EPRI, Palo Alto, CA: 2014.
3002002586.

What is the CIM?

The CIM is an electric utility industry-standard semantic model, which covers

information related to the entire realm of power system operation, from
generation interconnect to customer, from the control center to the back office.
It is used to enable the sharing of data among software applications. The
deregulation of the power industry, the emergence of Smart Grid technologies
and the proliferation of automation solutions has resulted in a great need for
sharing power system data between companies and systems. The increase in
choice provided by the number of power system software vendors and the
different software packages and architectures available add to the challenge of

 4-1 

14635805
 data exchange. These issues point to a need for a single, open standard for
describing utility operations data and to aid the interoperability between software
packages and exchange of information both within one company and between
companies.

The standard was started as part of the CCAPI project at EPRI with the aim of
The CIM is an open data creating a common definition for the components in power systems for use in the
exchange standard EMSs. That work, as it transitioned to the IEC, became the basis for one of the
originally developed by the three CIM standards currently in existence: IEC 61970-301 (CIM base), which
Electric Power Research is now maintained by IEC Technical Committee 57 Working Group 13. The
Institute (EPRI) in North data model described in the IEC 61970-301 standard has now been adopted by
America and now a series the vast majority of major EMS vendors and major transmission planning tool
of standards under the vendors around the world to allow the exchange of network model data between
auspices of the International their applications, independent of their internal software architecture or
Electrotechnical operating platform.
Commission.
Two other IEC standards, in combination with 61970, comprise the CIM. IEC
61970 standard describes the components of a power system at an electrical level
and the relationships between each component. IEC 61968 standard extends this
model to cover other aspects of power system software data exchange such as
asset management, work scheduling, and customer billing. In addition, IEC
62325 standard extends both of these models to cover the data exchanged
between participants in electricity markets. The working groups associated with
these standards and the scope of work involved in each will be described later in
this section.

As a semantic model, the CIM defines the organization of shared data. It does
Typically, CIM will not align not contain everything that every application has or needs; it does not even
exactly with the internal contain everything that one application might use. It only models data that needs
storage strategy of any to be shared among applications.
application; each
In utilities, several computer applications often must communicate with each
application has its own
purpose and presumably a
other. This can result in many point-to-point interfaces using custom formats
data model tailored to that
and protocols to exchange data between software applications from several
purpose. The CIM does,
vendors. Adding a new application to the system requires additional interfaces to
however, provide a
be defined and implemented, further increasing the complexity of the overall
standard way to organize
system. This results in an application ecosystem that is often referred to as brittle.
all of the data exchanged
This is because a change to one system’s interfaces may break the interfaces with
among applications.
another system. in addition, the total cost of ownership (TCO) of such a system
is higher because each system has its own data definitions that must be mapped
and managed for every interface to another system.

 4-2 

14635805
 Figure 4-1
Communications between enterprise applications

As illustrated in Figure 4-1, even for a small section of the overall enterprise
system, this can result in many inter-application communication links. As
companies expand their information and communications technology (ICT)
infrastructure or replace existing applications with products from other vendors,
they must define new interfaces for each communication link, a process that is
time consuming and expensive.

 4-3 

14635805
 Enterprise Service Bus

Figure 4-2
Enterprise service bus model for inter-application communication

Figure 4-2 illustrates integration using middleware services, which is one way
Enterprise application that the model-in-the-middle data sharing communication could be done.
integration replaces these
For utilities, the CIM provides the common semantic model that can be used to
dedicated point-to-point
construct data exchanges among applications (Model Driven Integration (MDI)
interfaces with a data-
for Electric Utilities, G. Robinson). This requires each application to map its
sharing strategy using a
external interface to the CIM class structure allowing the inter-application data
“model-in-the-middle”
exchanges to be defined in the CIM.
approach, in which each
application has only to
CIM UML
translate between its
internal data model and the
The CIM is an implementation agnostic data model, expressed in UML, which
shared semantic model.
defines information used by electric utilities.

Quick Introduction to UML

Unified Modeling Language is a nonproprietary modeling and specification

language used for describing data structure, application structure, behavior and
architecture, and business processes. UML provides the foundation for a generic
model to represent information that is independent of any particular proprietary
data standard or format. The following reports offer more explanation to UML:
 International Standards Organization/International Electrotechnical
Commission (2012-04).

 4-4 

14635805
  ISO/IEC 19505-1 Information technology – Object Management Group
Unified Modeling Language (OMG UML) – Part 1: Infrastructure. 2012.
[standard] International Standards Organization/International
Electrotechnical Commission, (2012-04).
 ISO/IEC 19505-2 Information technology – Object Management Group
The CIM leverages several
Unified Modeling Language (OMG UML) – Part 2: Superstructure. 2012.
of the capabilities of UML:
[standard]
data structure definition,
UML Data Structure
sequence diagrams, and
activity partitions. To
Major UML data structure constructs are the following:
understand the CIM, the
user must understand UML  Classes and their attributes
class diagrams and the
 Type of relationships: inheritance, association, and aggregation
entities within it.
Classes

Within a system, a class represents a specific type of object being modeled.

A class hierarchy is an abstract model of a system that defines every type of
component in a system as a separate class.

In the CIM, for example, physical objects such as transformers are modeled as
classes, as well as more abstract concepts like “customer.”

Each class can have its own internal attributes and relationships with other
classes. Each class can be instantiated into any number of separate instances,
known as objects in the object-oriented programming paradigm, each containing
the same number and type of attributes and relationships, but with their own
internal values.

As a simple example, the class Circle is used to describe the characteristics of a

circle that is to be plotted on a diagram. Attributes of the circle that would need
to be known if the circle is to be plotted and, assuming the diagram is a simple,
two-dimensional drawing, requires an X and Y coordinate that represents the
center of the circle. The radius of the circle would also be required, and so an
additional attribute is added to store this value. The diagram may contain
multiple circles on the screen at different locations with varying radii, but they
can all be described in the same way using this Circle class shown in Figure 4-3.

Figure 4-3
Circle object

 4-5 

14635805
 If 100 circles were to be instantiated in the diagram, the system would create 100
separate instances of circle, each containing an X and Y coordinate and a radius,
but all are independent of each other. A change in one circle’s radius will not
affect any other.

Obviously, a diagram containing only circles is not particularly useful; therefore,

it would be useful if it could contain rectangles, triangles, squares, lines, and so
on. This will require the class structure to become more complex.

Inheritance

Inheritance (also known as Generalization) defines a class as being a subclass of

another class. As a subclass, it inherits all the attributes of its “parent,” but can
also contain its own attributes.

Classes can be abstract or concrete, depending on whether they are expected to

be instantiated. If the class is in the class hierarchy to define an abstract class that
represents a common parent for many other classes, it is considered abstract, but
if it is something that may be instantiated, it is concrete.

An example of this is that circles, rectangles, triangles, squares, and so on are all
shapes. If a Shape class is added as a parent class, then a Circle, Rectangle, and
Triangle class can all be considered to be subclasses of Shape. In addition, a
Square can be considered to be a subclass of Rectangle. Because the user will not
be creating instances of Shape, it is considered to be an abstract class while its
“children” are all concrete classes because the diagram will contain circles,
rectangles, triangles, circles, and so on.

Figure 4-4
Class hierarchy for diagram shapes

 4-6 

14635805
 Figure 4-4 illustrates this class hierarchy with the abstract Shape class along with
its child classes Circle, Rectangle, and Triangle, and Square as a subclass of
Rectangle. Because every shape will have a location in the diagram, the X and Y
coordinates are moved from Circle to its parent Shape class and so is inherited by
everything that inherits from Shape. The radius attribute remains in Circle.

The Rectangle class has additional attributes added to represent the width and
height of the rectangle. Square inherits these attributes (along with x and y from
Shape) and the implementation would ensure that width and height would be
equal for a square. In the Triangle, three attributes are added to explicitly define
the length of the three sides.

So a Square is a Rectangle and a Shape but not all Rectangles are Squares and not all
Shapes are Rectangles. A system would know that any Shape will have a
coordinate, but it will expect only a Circle to have a radius and a Triangle to have
side A, side B, and side C.

Association

In Figure 4-4, the only relationship between any of the classes is that of parent
and child.

Classes can have other relationships defined that represent linkages between
classes showing a relationship other than parent–child. As an example, given that
the shapes will be drawn on a diagram, it would be beneficial if each shape could
have a Style associated with it, representing the thickness of the outline, the
outline color, and the internal fill color. These styles may be used by multiple
shapes and have a specific name associated with them.

Figure 4-5
Class hierarchy of diagram shapes with a Style

In Figure 4-5, the Style class with its three attributes for lineThickness,
outlineColour, and fillColour and an additional name attribute to provide a human-
readable name for reference is shown with an association to Shape. The
 4-7 

14635805
 association is shown as a line between Shape and Style, and the association has
roles on each end. This shows that a Shape has a role Style on the Style class with
cardinality of 1. This means that a Shape must have an association to an instance
of Style. On the opposite side, the Style class has an association to Shape with the
role name Shapes with cardinality 0..*. This means that a Style may associate with
0 or more Shapes.

This means that any of the subclasses of Shape, whether it is Circle, Rectangle,
Triangle, or Square, must have a Style and they may share a common Style among
multiple instances.

Aggregation

The aggregation relationship defines a special kind of association between classes,

indicating that one is a container class for the other. For the diagram shapes
example, a Layer class is added that may contain multiple Shapes.

This means that a Style may associate with 0 or more Shapes.

This means that any of the subclasses of Shape whether it is Circle, Rectangle,
Triangle, or Square must have a Style and they may share a common Style among
multiple instances.

Figure 4-6
Aggregation example with Layer and Shape

In Figure 4-6, an additional class Layer is added that can be used to group
together Shapes into layers that can be turned on or off within the diagram. The
Layer class has attributes to provide it a name and a flag to indicate whether it
visible. The relationship to Shape is an aggregation relationship, shown with a
diamond on the side container side of the relationship, with role names and
cardinalities used in the same way as a normal association.

As such, this diagram indicates that a Layer may contain 0 or more instances of
Shape while a Shape will be in 0 or more Layers (it is assumed that Layers are
optional). The clear diamond, however, indicates that the two are not completely
interdependent, and that if the Layer was destroyed, the Shapes would still exist.

 4-8 

14635805
 CIM Identity and Naming

The CIM hierarchy currently has no official common super-class (that is a class
The majority of CIM classes, from which every component inherits). The reason for having a super-class is to
however, inherit from the have common attributes for identification that can be used by any class that needs
IdentifiedObject class, to be given a universally unique identifier (commonly referred to as a UUID or
therefore, for this section it GUID) known in CIM as a master resource identifier (MRID) and a human-
can be considered the base readable name. Because the CIM version 15 draft was finalized in 2011, a
class for the hierarchy. construct has also been added to enable any class that inherits from
IdentifiedObject to have 0 or more additional Name entries using a 0..* association
between IdentifiedObject and Name.

Figure 4-7
IdentifiedObject class with Name Class

In Figure 4-7, the IdentifiedObject class is shown along with the Name class. In
addition, the NameType and NameTypeAuthority is also included. These latter
classes are used to more accurately identify what an additional Name entries
refers to. For example, a component may exist in multiple different systems with
different identities depending on the application. This could be for a variety of
reasons including:
 Naming limitations on the source system (for example, maximum of eight
characters for a name)
 Historical divergence of data (two systems modeled the same network
independently and now must be merged while maintaining the identity used
on each system)
 To maintain local names from different utilities when network models are
merged from neighboring utilities

 4-9 

14635805
 The NameType class is used to identify what type of name is being provided. For
example, the NameType is a description and the corresponding Name contains a
verbose, human-readable description of the component. It may alternatively be
pathname to indicate that the Name contains a value that represents a path for
the component within the overall network hierarchy (for example,
country/region/city/locale/substation/voltage/bay/name).
The NameTypeAuthority is used to optionally describe which authority issued this
name. This could refer to an application for a systems integration environment or
an organization if the data is coming from multiple organizations. For example, a
component may have a Name entry with a value on name that is of a NameType
for name localName and has a NameTypeAuthority from ENTSO-E to indicate
that it is the local name for the component as issued by ENTSO-E. It may
simultaneously have another instance of Name assigned that also has a NameType
with name localName but a NameTypeAuthority of EDF, indicating that this is
Électricité de France’s (EDF’s) local name for the component. In versions of the
CIM prior to version 15, this Name/NameType/NameTypeAuthority construct did
not exist and instead IdentifiedObject had additional attributes for pathName,
aliasName, localName, and description. The issue with this approach is that it
limits an exchange to having only one alias and several situations arose where
there was a need to exchange more than one alias for a component. This new
approach allows for additional aliases to be included and adds an additional level
of description by making it clear where the aliases came from and their type.

CIM Units and Language

Data Type Units

All distance and volume measurements are metric and temperature in Celsius 1
As an IEC standard, the
etc.
CIM requires that all units
The CIM defines data types for all units used and are defined in the UML with a
must be defined as
stereotype of CIMDataType. For numeric units, there is also the option of
International System of Units
defining a standard multiplier along with the default unit. This means that values
(SI) or SI-derived. This
that are commonly in the thousands or millions can have a default multiplier of
means that in the CIM,
kilo or mega added, thus allowing voltages to be kilovolts or power as megawatts
values are not expressed as
reflecting the common representations within the industry without breaking the
per-unit, which is very
rules requiring SI units.
common for power system
formats.
Enumerations

Some attributes are defined as having an enumerated type. An enumeration is a

list of predefined values and the value of these attributes must be one of these
values to be valid. Examples of enumerations include the phase code (A, B, C,
AB, AC, ABC, and so on) or the operating mode of a Synchronous Machine
(generator or condenser).

1
Although it could be argued, of course, that Kelvin would be the purest definition of temperature.

 4-10 

14635805
 Language

As an international standard, the CIM is written in English, but even though it

originated in North America, the IEC requires the use of British English. As
such, all CIM terms are defined in British English terms, resulting in terms that,
to American users, may appear misspelled.

CIM Geographical Data

The CIM contains classes to define geographical locations. The classes provide
an explicit CoordinateSystem class with an attribute to denote the coordinate
reference system. This uniquely identifies the coordinate system being used (for
example, Latitude Longitude with Decimal Degrees, Lambert I-IV, GB
Ordnance Survey Grid Codes, and so on).

Each Location can have one or more PositionPoints, which contains an X,Y and
optional Z coordinate to define a point in space.

Asset Versus Power System Functional Role in CIM

As the CIM expanded from its roots in EMS, there was a need to include a
much wider range of information of importance to systems concerned with asset
management, Work Management, Procurement, and so on. There is a need to
represent both a physical asset and the function (or functions) that it performs
from an electrical network perspective. In the CIM, there is separation of asset
from network model role—but with a linkage between the two perspectives. The
asset view is concerned with how a piece of equipment is tracked, monitored,
maintained, and so on from the perspective of procurement, maintenance,
accounting, and so on. This view of an asset includes the manufacturer, model,
purchase date, installation date, maintenance history, and so on, but it is
generally unconcerned with how the asset fits into the electrical network beyond
knowing its physical location. Assets will also exist without being connected to
the functional network view of the enterprise. They may be because some assets
are not electrical equipment (for example, trucks, buildings, tools, and so on) or
because they are not yet commissioned and are sitting in a warehouse or service
yard. The AMS must still have a record of these assets and track them from the
point of ordering through their entire life in the organization.

A major benefit of this approach is that the replacement of a physical asset does
not require the functional equipment entry to be altered.

CIM Network Modeling

The original focus of the CIM was describing network model data. Today, it still
comprises a central portion of the CIM, is the primary focus of IEC TC57
WG13, and is the most mature area of the CIM. A high-level illustration of how
the CIM supports network model definition is given next. Note: It is important
to remember that the purpose of this portion of the CIM is to describe the power
grid in a standard way to support data exchange between power flow

 4-11 

14635805
 applications—so essentially, generator modeling is done from the grid
perspective. There are clearly other perspectives from which a generator can be
viewed and for which shared data models might be developed.

Translating a Circuit into CIM

The circuit shown in Figure 4-8 shows a circuit containing a single generating
source, load, line, and busbar. The circuit also contains two power transformers
resulting in three distinct voltage levels of 17 kV, 33 kV, and 132 kV.

Figure 4-8
Example Circuit as a Single Line Diagram

As shown in Figure 4-9, the load, line, and breakers map to the CIM
EnergyConsumer, ACLineSegment, and breaker classes, respectively, while the
busbar similarly maps to the BusbarSection class. Generator Alpha will map to a
single piece of conducting equipment, the SynchronousMachine, an
“electromechanical device that operates synchronously within the network” as
defined in the CIM.

 4-12 

14635805
 When operating as a generator, the SynchronousMachine object must have an
association with an instance of the GeneratingUnit class. The GeneratingUnit
class does not represent a piece of conducting equipment that physically connects
to the network; instead, it represents “a single or set of synchronous machines for
converting mechanical power into alternating current” as defined in the CIM.

Figure 4-9
Example Circuit with Partial CIM Class Mappings

Voltage Levels

Pieces of conducting equipment generally do not have a voltage attribute to

define the voltage as a specific value; instead, they are associated with a
VoltageLevel, a subclass of EquipmentContainer. Each instance of the VoltageLevel
class has an association to an instance of BaseVoltage that contains a single
attribute to define the nominal voltage of that particular group of components.
A single BaseVoltage instance exists for all of the standard nominal voltages used
in the data. As such, they may be associated with more than one VoltageLevel
because standard voltage levels (for example, 33, 132, 275, and 400 kV) exist
throughout the network. Each VoltageLevel instance, however, contains only the
interconnected pieces of equipment at the same voltage level. This is an example
of using a subclass of EquipmentContainer to represent electrical containment.

 4-13 

14635805
 Substations

The Substation class is a subclass of EquipmentContainer that can contain

multiple VoltageLevels and is used to define a collection of equipment “through
which electric energy in bulk is passed for the purposes of switching or modifying
its characteristics” in the CIM.

In the example network shown in Figure 4-10, the three different voltage levels
identified by the dashed bounding boxes are mapped to three instances of the
VoltageLevel and contained within a single Substation instance. Each VoltageLevel
object also has an associated BaseVoltage object with a nominal voltage of 17, 33,
and 132 kV.

The Substation class, being a subclass of EquipmentContainer can also contain

other instances of Equipment, such as PowerTransformer, which was itself a
container, not a piece of conducting equipment in CIM prior to version 15. The
Substation class is an example of a subclass of EquipmentContainer to represent
non-electrical containment because it will contain pieces of equipment that are
physically grouped, but not necessarily electrically connected.

Lines

The ACLineSegment is not contained in a VoltageLevel. Instead, it is contained in

an instance of the Line class. The Line class in CIM is used to define a
“component part of a system extending between adjacent substations or from a
substation to an adjacent interconnection point.” A Line may contain multiple
line segments of either the AC or DC variety, but it does not itself represent a
piece of physical conducting equipment.

Because a line segment is used to represent “a wire or combination of wires…

used to carry alternating [or direct] current between points in the power system,”
it would be inaccurate to define it as being inside a specific voltage level in a
substation. As such, the AC and DCLineSegment classes contain a direct
association to the BaseVoltage class to define their nominal voltage level.

In transmission models, the Line class generally contains only ACLineSegments

and ConnectivityNodes; however, when used in the distribution networks, it may
contain all equipment considered to be in a feeder such as switches and
transformers.

Defining Component Interconnections

When defining how components in a power system network join together, rather
than define direct connection between components, the CIM uses Terminals and
Connectivity Nodes. See Common Information Model Primer: Third Edition
(EPRI, 2015) for complete examples and figures of this concept.

 4-14 

14635805
 Figure 4-10
Example circuit with complete CIM class mappings

Figure 4-10 shows the CIM representation for the circuit shown in Figure 4-9.

The BusbarSection’s position may at first seem erroneous, but in the CIM, the
ConnectivityNodes are used to define the point of interconnection for pieces of
equipment. As such, the BusbarSection object is used primarily to provide a point
of association (via its Terminal) for Measurement objects measuring the voltage at
that particular busbar in the system. This reflects the positioning of equipment in
the physical system, because a voltage transformer often measure voltages at the
busbars within a substation.

The current transformer (CT) in the original diagram does not map to a piece of
ConductingEquipment in the CIM. Instead, a Measurement instance, representing
a SCADA measurement from the CT is associated with the Terminal on the
Breaker. Because the CT does not impact on the electrical characteristics of the
network and affect the results of any analysis, it is not explicitly modeled in the
same way as a breaker, generator, load, and so on. There may be a need to know
about the physical piece of equipment that is in this place in the network, but this
is the asset view of the system, which will be presented in the next section.

 4-15 

14635805
 This representation of the example network could be extended further with the
addition of objects to represent control areas, equipment owners, measurement
units and generation/load curves, but for now it is enough to understand how an
existing network representation can be mapped to CIM objects.

Diagram Layouts in CIM

The ability to visualize network schematics can be critical for engineers when
interpreting the status of an electrical network. As the number of systems using
electrical models grows and utilities move toward a single, common network
model across applications, there is a need to ensure that single line diagrams and
other schematics are reproduced accurately across each system.

The CIM Diagram Layout (CDL) format extends the CIM to provide a
mechanism for describing the layout of electrical schematics independent of the
source or target systems’ vendor. This standard will allow graphics and network
data to be exchanged simultaneously, thus ensuring that schematic views are
synchronized with the electrical model across multiple systems. The standard is
intended to allow each system to recreate the layout of a schematic accurately
while using their own styling for icons, colors, fonts, and other graphical
rendering attributes.

Separating Style from Layout

A key driver when developing the CDL was that any receiving systems should be
able to draw a schematic in the style that its users are familiar with. A SCADA
system may use different icons, coloring, and line styles than an EMS, but the
operator will want to ensure that the layout of a substation as well as the position
of busbars, switches, and transformers is the same as in the EMS. With this use
case in mind, the CDL is focused on the exchange of layout information allowing
a graphic to be created, rather than the exchange of a graphic on which layout
information must be derived.

Functional Model Integration

Extending the CIM to support Graphics Exchange allows the diagrams to be

tied directly into the electrical model and can be stored and exchanged using
existing CIM-compliant applications and formats such as CIM RDF XML

CIM Modeling of Assets

The CIM provides a rich set of asset- and network model-related classes that can
be leveraged in organizing information related to the health of a wide variety of
electric utility industry assets, from transformers and breakers to cables and tap
changers. This section explores the basic approach taken by the existing CIM in
modeling assets and their participation in the electrical grid. Information in the
following section is from Standard Based Integration Specification: A Reference
Architecture and Basic Asset Model in Support of Asset Health Analysis (EPRI report
3002000607).

 4-16 

14635805
 CIM Asset Classes

Using the classes of the CIM, a full-featured model supporting asset health
information can be built. At the center of the model is the asset itself, which is
described by using two classes in the assets package, Asset and AssetContainer, that
allow the identification of an asset and its component parts.

Figure 4-11 shows the CIM UML model of those two classes on the left along
with an instance diagram showing conceptually how they would support the
instance representation of an asset with two components. Note that in the UML,
that asset Container both inherits from asset and has a relationship with asset,
allowing the repetitive nesting of component assets within component assets.
The Asset and AssetContainer classes are intended to represent the simple fact that
a physical asset exists and to allow the description of a few types of information
that any asset might have: identifying numbers, geographic location, type,
condition, and status. The asset class does not contain any information that
relates to specific types or models of assets. The Asset and AssetContainer classes
are the foundational classes from which an asset model is built. All other classes
supplying asset-related information have associations to the asset model.

IEC 61968
Common and Assets

Asset Identification
Asset
Component
Identification
Asset
Component
Identification

Figure 4-11
Basic asset and asset component identification: UML and instance representation

Information on asset characteristics or asset model characteristics is provided by

the AssetInfo class, or more accurately, by the asset type-specific child classes of
AssetInfo that are in the AssetInfo package. A collection of classes (AssetModel,
ProductAssetModel, and Manufacturer) are used to specify the model and
manufacturer of an asset.

 4-17 

14635805
 Figure 4-12 shows the UML model of the participating classes and expands the
asset conceptual instance representation to include asset and asset model
characteristics as well as model and manufacturer information. The information
modeled by the AssetInfo child classes is intended to be specific to the type of
asset (switch, cable, transformer, meter, and so on) and is intended to be used in
the following three different ways:
 To describe the characteristics of a specific asset
 To describe the characteristics of a specific asset model
 To describe the characteristics of a generalized asset used in the field
construction design and planning process

Note the relationship of both AssetModel and asset to AssetInfo. The AssetModel
relationship reflects the use of AssetInfo for describing asset model-specific
information, the asset relationship leverages AssetInfo to describe information
specific to a given asset.

 4-18 

14635805
 IEC 61968

Common and Assets AssetInfo

Model
Model and Characteristics
Manufacturer (nameplate)

Asset
Asset Identification Characteristics
Asset
Component Asset
Identification Component
Characteristics
Asset
Component
Identification

Figure 4-12
Basic asset plus model and asset-specific characteristics: UML and instance representation

 4-19 

14635805
 There are a multitude of asset-related activities whose results have bearing on
understanding asset health: factory, field and lab tests, field inspections and
various types of maintenance tasks. In the CIM, activities related to assets are
described using the Procedure class. The results of activities related to assets are
described using the ProcedureDataSet class or its children. Both the Procedure class
and the ProcedureDataSet class are contained in the asset package. The CIM
definitions of those classes are:

Figure 4-13 shows the UML of these activities- and results-related classes and
illustrates where they would fit in the conceptual instance representation.

 4-20 

14635805
 IEC 61968

Common and Assets AssetInfo

Model
Model and Characteristics
Manufacturer (nameplate)

Asset
Asset Identification Characteristics
Asset
Component Asset
Identification Component
Characteristics
Asset
Asset Procedures and
Component Results
Identification

Figure 4-13
Asset plus asset-related activities and results – UML and instance representation

 4-21 

14635805
 CIM Packages Overview
For a detailed view of all of
the packages, their classes, As with any other complex class structure, classes in CIM are grouped together
and relationships, the into packages 2 depending on their role in the utility.
reader is urged to view the
CIM UML model available Three main IEC standards that correspond to the three highest level CIM UML
to members of the CIM User packages are IEC 61970-301, IEC 61968-11, and IEC 62325-301, described
Group as an Enterprise next.
Architect file or in the
relevant International IEC 61970-301
Electrotechnical Commission
standard publications. The core IEC 61970-301 standard covers the content of the IEC61970 UML
package, which contains a number of main packages, along with a global domain
package used for defining data types. The core, Wires and Topology packages
contain all the basic classes for defining a power network model.

The Wires package defines classes that are required to represent the electrical
components of a network, such as Transformers, AC Line Segments and Switches,
while the core and Topology packages define the interconnection and containment
of components. These three packages provide the basic electrical characteristics
of the equipment and describe how they are connected. To provide a detailed
description of a network at an operational level, other classes are required in order
to define the data required for operation and control including: generation data,
operational limits, SCADA measurement, state variables, dynamic generator and
load behavior, and protection.

IEC 61968-11

IEC 61968-11 (the standard that covers the content of the IEC61968 UML
package) extends the IEC 61970-301 model and introduces classes aimed at the
exchange of data other than network models.

61968 has support for Asset Management, Customer Management, Work

Management, Meter Data (including remote meter readings and meter data
management), and Geographical Data.

IEC 62325-301

IEC 62325-301 (the standard that describes the IEC62325 package) builds on
IEC 61970-301 and IEC 61968-11 and adds packages for defining the data
exchanged between participants in electricity markets. These classes include the
data exchanges at the different stages of market operations including: billing,
clearing, and settlement.

2
A package is used to “group elements, and to provide a namespace for the grouped elements”
(OMG Unified Modeling Language (OMG UML), Infrastructure, V2.1.1 p.158). A package may
contain other packages and provides a hierarchical organization of elements within UML.

 4-22 
14635805
 The IEC 62325-301 classes do not themselves model a market; they are used to
define the data exchanged between entities involved in the operation of the
market and so include classes to describe agreements, invoices, prices, bids,
notifications, and so on.

Contextual Modeling

Deriving Profiles

The CIM is by definition intended to be a single, “common” model. The CIM

now has the goal of clearly and unambiguously defining a data structure for all
the data exchanged among electric utility operational systems. This has meant
that the CIM model itself has grown as its scope has increased, from a core set of
fewer than 100 classes, which describe a balanced electrical model from the
perspective of an EMS, to a model of more than 800 classes with thousands of
attributes and associations.

It is this all-encompassing model that new users often encounter, either as the
IEC standard documents for 61970-301, 61968-11, or 62325-301, or the UML
model itself from Enterprise Architect or in XML Meta Interchange (XMI)
format. Because the model includes every class and element, it can appear overly
complex and impractical for those seeking simple implementations or viewing the
CIM for the first time.

CIM Standard Profiles

Normally, the CIM is not
implemented in its entirety. For the exchange of messages between the enterprise and systems such as
International metering, Work Management or Operations, several IEC 61968 standards
Electrotechnical Commission profiles have been defined.
standard documents such as
61970-452 (Common When viewed as a contextual profile, a CIM interface is no longer a complex
Power System Model), model of more than 800 classes but is instead a small number of classes with a
61968-13 (Common subset of their attributes and associations. When multiple interfaces are to be
Distribution Power System implemented by a single system, the use of a single overall model from which the
Model), and ENTSO-E are profiles are derived means that the data definitions are re-used, not duplicated.
examples of contextual For example, a GeneratingUnit is defined once in the CIM but can be used in any
profiles derived from the number of contextual profiles, whether they are interfaces for transmission,
overall CIM model used to distribution, or market systems.
exchange electrical network
models.
As shown in Figure 4-14, the addition of this context (that is, perspective or view
of the model) makes it easier for a user to understand which parts of the CIM
need to be implemented in order to support an interface. Supporting an interface
of a few classes and attributes is far simpler than looking at more than 800
classes.

 4-23 
14635805
 Figure 4-14
Example information to contextual models

The CIM Primer document provides examples of profiles from a common power
system model, common distribution power system model, and an ENTSO-E
example (EPRI report 3002006001).

 4-24 
14635805
 CIM Data Exchanges

Although the main focus of the CIM is defining a shared semantic model for
utilities, its value becomes real when standard profiles for data exchange are
defined and expressed in a specific interface technology. Because CIM data
exchanges are typically accomplished using XML, two XML definition
technologies are used to describe CIM standard profiles: XML Schema and RDF
Schema. More information on XML Schema messages and RDFS file formats
can be found in the CIM Primer.

Current International Electrotechnical Commission CIM

Committees and Working Groups

This section provides an overview of the IEC CIM committees and working
groups and the current scope of their work.

Technical Committee 57

IEC Technical Committee 57 (TC57) develops standards for “Power systems

management and associated information exchange.” The committee was
established in 1965 and contains working groups that develop and maintain
standards including CIM, IEC 61850 3 and IEC 60870-6/TASE.2 4.

The CIM is developed and maintained by three working groups under IEC
TC57, working groups 13, 14, and 16. A further group, Working Group 19, is
responsible for “Interoperability within TC57 in the long term” and harmonizes
work across the TC57 working groups. This is to ensure that there is no
duplication of effort and to promote interoperability between the standards.

WG13: Energy Management System Application Programming Interface

Working Group 13 maintains the core CIM model that covers the modeling of
electrical networks from the perspective of the transmission system operator, and
so it is focused on the definition of the electrical network and applications linked
to online operations and offline analysis of the network.

WG14: Systems Interfaces Distribution Management Systems

Working Group 14 is responsible for the portion of the CIM related to more
“back office” utility functions: asset management, Work Management, Customer
Management, Automated Metering Interface (AMI), Geographical Information
Systems (GISs), Maintenance and Construction, Network Planning, and other
systems.

3
‘‘IEC 61850 Communication networks and systems in substations - Part 1: Introduction and
overview’’, IEC, Edition 1.0, April 2003.
4
‘‘IEC 60870 Telecontrol equipment and systems - Part 6-503: Telecontrol protocols compatible
with ISO standards and ITU-T recommendations -- - TASE.2 Services and protocol’’, IEC,
Edition 2.0, April 2002.

 4-25 
14635805
 WG16: Deregulated Energy Market Communications

Working Group 16 oversees the portion of the CIM that models data exchanged
in the area of deregulated energy market operation, including bidding, clearing,
and settlement. This portion of the CIM models the data that are communicated
between market participants and not the structure of the market itself. There are
two primary sub-teams in the working group: one creating extensions for
European-style markets and the other for U.S.-style markets.

Standards Process

As an IEC standard, the CIM and all related standards must go through the IEC
standards process to be published. This process contains a number of steps,
which are presented next.

New Work Item Proposal

A new work item proposal (NWIP) is the first step in creating a new standard.
The NWIP is submitted by a working group and is voted on by all member
countries. A minimum of five countries must provide experts to work on the
proposal, and a majority must vote in favor of the proposal in order for it to move
forward in the standards process.

Working Draft and Committee Draft

The working group then prepares a working draft of the standard, which can take
months or even years to prepare. This is then submitted as a Committee Draft
(CD) that is circulated to all national committee members for comment. These
comments are then compiled and sent to the working group to be addressed.

Committee Draft for Vote

After addressing the comments received from national committees about the
CD, the working group then prepares an updated version of the standard that is
issued as a Committee Draft for Vote (CDV). This is circulated to member
countries for a five-month voting period and is considered approved if two-thirds
of the votes cast are in favor and the number of negative votes does not exceed
25% of the votes cast. At this stage, countries may still submit comments along
with their vote.

Final Draft International Standard

The working group, once again, addresses any comments that have been received
and prepares a Final Draft International Standard (FDIS). This is submitted to
the IEC Central Office and circulated to the national committees for a two-
month voting period. At this stage, a country may make only an explicit vote:
positive, negative, or abstention.

 4-26 
14635805
 The FDIS is approved if two-thirds of the votes cast are in favor and the number
of negative votes cast does not exceed 25% of the votes cast. If approved, the
document is published; however, if the conditions are not met, it is referred back
to the working group to be revised. Final publication is the responsibility of the
IEC Central Office and leads to the publication of an international standard.
This normally takes place within two months of the approval of the FDIS.

Time Scales

The standards process can take a significant period of time as shown here:
 CDV: 5 months
 FDIS vote: 2 months
 Addressing comments: up to 4 months
 Publication: up to 2 months

In addition, time is needed to prepare the NWIP, WD, and CD with additional
time in between all of these stages for experts to work on the drafts. As such, the
process can take several years from inception to the publication of the standard.
As such, it is not uncommon for users to work on draft documents; however, this
must be undertaken with the knowledge that a draft may change before final
publication. Any projects using draft documents should take this into account
and plan accordingly.

 4-27 
14635805
 Section 5: Next Steps for Semantic Model
Development in Generation
A semantic model-based integration has much to offer the generation domain in
terms of facilitating business processes, improving efficiency, avoiding errors, and
Much of what has been
increasing the ability to extract useful information from data. From the
accomplished in
experience gained in the transmission and distribution domains, however,
transmission and
creating a solid standard semantic model for an industry domain is no small task.
distribution provides a good
(Working Group 13—the network model working group—has been around since
foundation on which
the mid-1990s, and its standard, IEC 61970, is just now mature enough to
generation can build, but
support complete integration solutions in the network analysis domain.)
there is still much work to
be done in identifying
This section of the report outlines a four-year plan from current state to having
generation domain
an internationally accepted standard semantic model with comprehensive support
functions and information
for bulk power generation. The staging of this work would be in two concurrent
flows, modeling the data
efforts—one populating assets into existing efforts by IEC TC 57 Working
needed to support them,
Group 14 (WG14) and another starting a generation systems working group—
and creating standards that
that would produce usable results within the first year.
describe the model.
CIM for Generation: Plan Summary

The CIM for generation standards would support a range of data models,
focused on generation operation, maintenance, planning, environmental
monitoring, and scheduling to facilitate the sharing of information among the
software applications used in the generation domain.

After consideration of best approaches for CIM development and work products
in EPRI’s Generation and Nuclear sectors, the strategy for the creation of a CIM
for Generation is composed of the following two major efforts that would happen
in concurrence:
 Adding bulk power generation assets to WG14’s scope. This effort leverages
existing CIM modeling in the areas of assets and work to facilitate
generation domain integration solutions in the near term. This allows
CIM-based integration solutions to be implemented in the generation
domain, which will demonstrate benefit, build integration skillsets, and speed
the implementation of CIM interfaces on asset- and work-related software
products.

 5-1 
14635805
 This effort would leverage the asset information in the PMBD (more
information on the PMBD and its potential relationship to the CIM is in
Appendix E) to populate the area under Working Group 14 (WG14), which
includes asset management, Work Management, GIS, and Maintenance and
Construction. Because WG14 is an existing effort, demonstration and initial
deployments could begin in the first year past initiation.
 Creating a bulk generation family of standards. This second effort builds out
the full generation domain semantic model supporting a wide range of
generation domain functions, expressed in a new family of CIM standards,
supported by a new IEC TC57 Working Group. This is the ultimate long-
term goal enabling semantic model-based solutions to be implemented in
many generation domain areas and allowing the vendors of a variety of
software applications to implement CIM-compliant, interoperable interfaces.

This effort would leverage both the existing CIM UML and the structural
schema described in the EPRI Master Equipment List (MEL) report (more
information on the Master Equipment List work and its potential
relationship to the CIM is in Appendix D) to guide a new working group.
Given that some of the organization tasks that must precede technical work,
this would lag the WG14 augmentation efforts by approximately 12 months,
demonstration and initial deployments could begin in the second year past
initiation

Background on Generation CIM Development

Semantic model-based integration is a high-value approach to any situation in

which multiple applications must exchange data and where it is desirable to
minimize long-term software costs and facilitate application replacement and/or
upgrade activities. In the utility transmission and distribution domains,
opportunities for semantic model-based integration—enabled by the CIM
semantic model—occur in many areas: network model maintenance, asset
condition analysis, meter data management, work management, and electric
markets. A subset of those areas is illustrated in Figure 5-1, in which CIM model
standards are shown in grey ovals and the business functions they support appear
in blue ovals.

 5-2 
14635805
 Communications

Environmental Data Communication Model

Model
Asset
(62325) Grid Operation Management

Power Grid Network Model / Assets Work

Protection Model Asset Criticality
(IEC 61968-4) (IEC 61968-6)
(IEC 61970)

Protection Grid Planning Work

Management

Key

System System of assets collectively performing a real-world function

Business Business Function performed by software and people

Function

CIM Standard CIM Standard data model supporting data sharing between Business Functions
Data Model

Figure 5-1
Overview of transmission and distribution domain systems, business functions, and
their applicable CIM standards

The IEC 61968-4 (Interfaces for records and asset management) standard,
which was described in detail in the CIM Modeling of Assets section, is shown
as are several other standards that support data exchanges between transmission
and distribution business functions. In its modeling, the CIM draws a firm
distinction between a physical asset and the role the asset plays in supporting a
system. The physical asset model (described in 61968-4) addresses physical asset
characteristics. The behavior of an asset in a particular system (such as the power
system or a communications system) is modeled separately. The most obvious
illustration of this in the transmission and distribution domain is the separation
of asset models from network models, which was described in the Asset Versus
Power System Functional Role in CIM section of this report. This distinction
both supports the reality of the world (assets can be replaced but the role in the
system remain unchanged) and provides clarity in the modeling process. This
distinction also affords the generation domain a significant opportunity: it can
leverage the existing CIM asset model directly because it is a general asset model,
not a model of how assets are used in the transmission and distribution domain.

 5-3 
14635805
 A diagram similar to Figure 5-1 for the generation domain might look similar to
what is shown in Figure 5-2. In the diagram, the Assets, Work, Network Model,
Environmental Data, and Market Model data models from the existing CIM are
leveraged and new data models are added specifically to support generation
domain application data exchange requirements.

Long Term
Material Asset
Network Model Management
Handling
(IEC 61970) Performance Maintenance
Safety Systems Electrical & Condition Basis
Distribution Monitoring Optimization
Generating Unit
Operation Maintenance &
Generating Unit Model Power Inspection
Generation Asset Criticality Assets Work
Support Assets Ranking (IEC 61968-4) (IEC 61968-6)
Systems
Water Supply Field Recording Work
Design Configuration Management
Management
Environmental Model
Market Model
(IEC 62325) Environmental Commissioning Model
Generation
Fleet Scheduling Plant
Scheduling Environmental Data
Model
Fleet & Plant Model (IEC 62325)

Key

System System of assets collectively performing a real-world function

Business Business Function performed by software and people

Function

CIM Standard CIM Standard data model supporting data sharing between Business Functions
Data Model

CIM Standard Potential area for CIM Standard data model creation to support data sharing
Data Model between Generation Domain Business Functions

Figure 5-2
Vision of generation domain systems, business functions, and their use of existing
and future CIM standards

The new generation domain data model standards shown in purple in Figure 5-2
are for illustration purposes only; the determination of generation areas of
modeling is the core work of creating a bulk generation family of standards. The
remainder of the diagram illustrates the potential use of existing CIM standards
in the generation domain. Of those areas, the assets and Work areas are probably
the ones with the largest potential for immediate benefit. They are, indeed, the
two areas of the existing CIM standard that support the operator rounds scenario
described in the Generation Domain Case Study: Enhanced Operator Rounds
section.

 5-4 
14635805
 Initiative Details

Adding Generation Assets to WG14’s Scope–Leveraging

Existing CIM Assets and Work Models

This first initiative would involve leveraging (and extending) existing CIM
modeling in the areas of assets and work to facilitate generation domain
integration solutions in the near term. It is work that could begin immediately
with a small number of EPRI staff, along with a couple of consultants and a
limited number of interested utilities. It leans heavily on the momentum of
existing asset modeling work going on in Working Group 14 and takes
advantage of the vendor involvement already in play in the CIMug Asset Health
Focus Community. Work under this task ranges from technical modeling, to
demonstration implementations, to standards engagement. If sufficient resources
were applied, the work of adding generation assets to WG14’s scope could start
bearing fruit within 12 months, in the form of standard asset models ready for
deployment. (Sufficient resources means nearly full-time engagement by an EPRI
staff person, part-time engagement by one to two integration/modeling
consultants, and assistance from two to three utilities on a bi-weekly basis.) If
asset software product vendors participate actively in the process for the first 12
months, vendor products with CIM-compliant interfaces could follow in the next
12 months.

The realm of bulk power generation assets affords a significant opportunity for
EPRI has leading asset EPRI and its members to contribute to the industry. Applying the domain
health modeling expertise in knowledge resident in Substations program and generation domain to the
the information and expansion of the CIM could help it mature rapidly into a truly useful semantic
communications technology model in the asset realm. Augmenting the current offering of EPRI asset analytic
program, leading analytics, tools with CIM interfaces could help them become even more powerful tools for
and asset failure knowledge allowing utilities to harness their data and turn it into asset health insight.
in its Substations program,
and a leading maintenance The following are concrete actions that could be taken as part of this initiative.
and failure vulnerability tool  Join the CIMug Asset Health Focus Community (AHFC)
in the PMBD that is
supported by the nuclear
 Conduct a Demonstration Integration (or two or three or four…)
and generation sectors.  Engage with CIM Standard Working Group 14
 Learn from others

The schedule in Figure 5-3 shows how these tasks would fit into a staged effort
to bring bulk power generation assets into the CIM.

 5-5 
14635805
 Figure 5-3
Schedule of tasks that shows how they would fit into a staged effort to bring bulk
power generation assets into the CIM

A description of each of these follows. In addition, Appendix C provides an in-

depth look at technical considerations related to this effort, and Appendix E
describes how the PMBD could be used in this effort.

Join the CIMug Asset Health Focus Community

Working with the AHFC will provide both a learning opportunity for generation
The Asset Health Focus
domain participants and a vehicle by which their contributions can be
Community is open to
incorporated into the CIM Assets standard. Phone calls are held on a weekly
anyone interested in helping
basis: one week there are requirements-definition conversations among subject
to define asset health data
matter experts, the next there are CIM modeling conversations among Working
exchange requirements or
Group 14 members on meeting the requirements. Members and contributors
in suggesting CIM
include utilities, asset analytic vendors, test labs, integration consultants, AMS
enhancements to support vendors, and others. It is co-chaired by representatives from Doble and EPRI. Its
them.
web page can be found on the CIMug website (www.cimug.org) and is accessible
via the “asset health” item on the “Focus Community” pull-down menu located
on the top menu bar. Information about how to become involved in the work of
the Focus Community is provided at the site.

 5-6 
14635805
 Conduct a Demonstration Integration (or two or three or four…)

Select an Area of Greatest Need or Benefit

A good starting point is to identify, in the generation domain, the typical

applications that use or provide asset-related information along with the
function(s) they perform. In the transmission and distribution worlds, these
applications include asset/WMSs such as Maximo, real-time data historians such
as plant information (PI), online monitors such as ABB Circuit Breaker Sentinel,
a variety of vendor and home-grown analytics applications such as EPRI’s Power
Transformer Expert System (PTX) or Doble’s dobleARMSTM, plus a variety of
custom-written applications (or paper forms) for inspection/test records, problem
reports, and maintenance results.

Describing the generalized industry picture of applications and functions

Understanding data usage provides a useful foundation for exploring what kind of data is typically stored or
and flow often provides used and how it typically flows among applications. These areas are good areas
insight into the where the on which to focus semantic modeling efforts.
most onerous data
management problems exist Find a Real-World Problem to Solve
or where “low-hanging
fruit” improvements might A real implementation (or two or more) is an excellent way for people to learn
be possible. semantic model skills and to test drive potential shared model definitions.
Hopefully, a real-world example in one of the areas of greatest need or benefit
could be identified. Ideally, in a demonstration implementation, approximately
three applications would be involved and the complexity of data exchanges would
be fairly low. The learning curve for semantic model-based integration is steep.
Although integration solution design is not really more difficult than many other
software or engineering design tasks, it comes from a distinctly different
perspective that can take a bit to adjust to. There is also a set of design processes
and artifacts that are fairly unique to the integration challenge. For these reasons,
it is recommended that a capable integration consultant—one as interested in
training as in doing—be retained to ensure a successful demonstration project
design and to teach integration techniques to the project team.

Create a Semantic Model Focused on a Specific Area

In conducting an integration demonstration, one of the design tasks is

articulating the semantic model that will be used to describe shared data, which is
generally a small subset of a standard semantic model. In a generation domain
demonstration project, the effort would use the CIM as a starting point and then
use input from generation domain sources (three of them being CIM, PMBD,
and MEL, and a possible fourth being the modeling done by the Southern
Company Generation) to implement the M&D Center to inform enhancements
to the CIM semantic model. The demonstration project would, hopefully, allow
thorough investigation of the similarities and differences in modeling between
the various structures in a specific narrow area and would allow extensions to the
CIM to be suggested in that area.

 5-7 
14635805
 Engage with CIM Standard Working Group 14

Participation directly in Working Group 14 asset and work modeling activities is

The breadth of asset possible as either a guest or as an officially appointed expert. Either route would
modeling represented by be appropriate and would allow face-to-face interaction with the experts currently
PMBD, MEL, and other working on extending the CIM in the asset health and work domains. Additional
efforts in the generation resources to help further the work of increasing the usefulness of the CIM in the
sector would be welcome asset management/health realm would be enthusiastically received. Working
additions to the asset health Group 14 meets three times a year, typically twice in the United States and once
modeling work currently in Europe. A basic level of understanding of enterprise integration and CIM
under way in Working modeling practice is required, and engaging with Working Group 14 is probably
Group 14. an activity that would follow participation in the AHFC by several months.

Learn from Others

EPRI’s Power Delivery and Utilization Substations Program

EPRI’s Program 37, Substations, helps substation owners enhance safety,

reliability, equipment life, and performance, as well as maximize the return on
asset investments. It offers a portfolio of tools and technologies such as risk-
based asset and fleet management decision support analytics and transformer
monitoring. The program also provides knowledge sources such as failure
databases—for transformers, circuit breakers, and bushings—and aging models to
improve equipment life management and training materials for substation
personnel. Recently, Substations has started an Asset Health Systems Interest
Group, whose meetings are held in conjunction with its bi-annual task force
meetings. The purpose of the Asset Health Systems Interest Group is to promote
information exchange and experience sharing among utilities and enterprise-wide
asset health system vendors. Meetings are open to members funding any part of
Program P35 (Overhead Transmission), P36 (Underground Transmission), or
P37 (Substations) and could provide a forum for cross-sector idea exchange.

EPRI’s Power Delivery and Utilization Information and Communication

Technology Program

EPRI’s Program 161, Information and Communication Technology - 37,

conducts research in application interoperability, communication, enterprise
architecture/system integration, and advanced metering. Over the course of the
last three years, ICT has published a number of deliverables, many of them cited
by this report, related to the CIM and its use in asset health data exchange. A
2015 report examined the use of IEC data exchange standards (CIM and 61850)
to support field-to-enterprise use of asset health measurement information,
something that could converge with the activities of the generation sector’s Fleet-
Wide Monitoring Interest Group. Collectively, ICT staff has more than 35 years
of experience in CIM standards development and can provide technical guidance
to the generation sector in moving forward with semantic model-based
integration initiatives.

 5-8 
14635805
 Best Practice Implementations in Transmission

Transmission entities have implemented visionary asset management/asset health

solutions worth investigating, including the following three:
 American Electric Power recently deployed an Asset Health Center, a
diagnostic center that enables asset managers to prevent unforeseen failures,
optimize asset maintenance, and support prioritization of asset replacement.
The initial system includes transformers, circuit breakers, and substation
batteries, although other assets may be added later. The CIM is implemented
by the main application deployed in the Asset Health Center solution for
describing asset network roles. For more information, see Jeff Fleeman’s
article in the May 2014 edition of energyBiz
http://www.energybiz.com/article/14/05/whats-utility-doc.
 Fingrid, the Finnish transmission system operator (TSO), has just completed
a project they call ELVIS, which is a comprehensive asset and network
model management solution integrating multiple systems. It is CIM-based
in its network model data exchange, although not in its asset data sharing.
High-level information is available from an entertaining YouTube video at
https://www.youtube.com/watch?v=gL4z-guklKM and from a presentation
given at recent CIMug meeting
http://cimug.ucaiug.org/Meetings/Oslo2014/Supporting%20Documents/CI
M%20Users%20Group%20Day%201/ELVIS_CIMUGM_2014_FINAL.pd
f.

Creating a Bulk Power Generation Family of Standards:

Building a CIM to Fully Support Generation Systems

This effort would be to build out the full generation domain semantic model
supporting a wide range of generation domain functions, expressed in a new
family of CIM standards, supported by a new IEC TC57 Working Group. This
is an extremely ambitious undertaking, but there are a wealth of resources
available to assist in the work. On the technical side, this effort calls for
developing a consensus view of the typical business functions and data flows
present in any area of the generation domain where application-to-application
data sharing and interoperability are deemed important. Then for each area, the
supporting data models must be defined in harmony with the data models for
other areas in the generation domain and other data models in the CIM. The
models are then used as the basis for defining standard profiles (subsets of the
model) used for specific data exchanges. A number of tools are used in the model
and profile development process and a number of artifacts are produced as
documentation. On the IEC side, a new Working Group would need to be
established and a new family of CIM standards approved. Experts from various
countries with membership in TC57 would be appointed to serve on the new
Working Group, and a convener would be appointed. Each standard developed
by the new Working Group would go through the IEC standardization process
described in the Standards Process portion of Section 4 of this report.

 5-9 
14635805
 One collection of contributors launched the CIM, and others encouraged
In the history of the subsequent growth spurts. The initiatives listed under EPRI CIM Projects in
development of the CIM, it Section 2 are examples of some of those collaborative efforts; many others have
has nearly always been the occurred as well. A collaborative effort could be launched, likely sponsored by
collaborative efforts of a EPRI, to engage with the IEC to create a CIM for generation. There is interest
specific collection of players in this among the CIM Working Groups, and some initial motion in this
(utilities, vendors, and/or direction was started by Alstom and EDF in the summer of 2013, although there
consultants) that has pushed is no activity at the moment.
the CIM yet one step further
along the path of An optimistic estimate of the time frame in which a new IEC TC57 Working
maturation. Group could be established and work on a new family of standards started is
probably 6 to 12 months. Concerted design efforts could likely produce a
framework for the family of standards and an “Interface Reference Model”
outlining the generation domain functions and high-level information flows
during the next 12 months. Development of models for the first area of
generation domain interoperability could likely be completed in the subsequent
six months. At that point, vendors could start writing interfaces using the data
model, and field integrations could be done based on it. Because of the time
delays inherent in the IEC standards approval process, production of initial
international standards would probably take close to another two years.

Figure 5-4 shows a simple schedule for developing a new set of generation
standards. This would be in concurrence with the previous initiative: working
with WG14 to get generation assets into the CIM.

Figure 5-4
A simple schedule for developing a new set of generation standards

 5-10 
14635805
 This report’s team’s estimate is that this would take at least one full-time EPRI
resource for 24 months to support the successful launch of CIM for bulk power
generation, along with nearly full-time assistance from a CIM-savvy integration
consultant for the same time period. A large part of the early work will be
reaching out to potentially interested parties: vendors, utilities, research and
regulatory entities in order to garner support, interest, and offers of technical
contributions. Then the critical mass of interested parties can engage with the
IEC and start the technical and standards work described here.

In the early days of the CIM, there was contention among vendors, but by now
A note on vendor relationships have grown to be collaborative. Vendors understand that no matter
participation: It is essential. the size of the functionality niche they hope to capture in the utility industry, the
It is vendors who have both ability to easily integrate with systems around theirs is a selling advantage rather
the long-range vested than a lost sale risk. Interoperability standards allow vendors to concentrate their
interest and the budget to efforts on improving product functionality (which can be sold to many
support standards work. customers), not on one-off data import/export solutions sold to only a single
customer. It seems likely that in the generation domain, where utilities
themselves are competitors, the role of vendors might be even more critical to
standards success.

Summary

It is apparent that the costs of bringing the benefits of semantic model

integration to the generation domain are largely about investing time—learning
time, modeling time, and “selling” time. The journey toward generation industry
engagement in semantic-based modeling is much like any utility’s journey in
implementing semantic model-based integration solutions: it is front loaded. The
costs are highest at the beginning as the semantic model infrastructure is built.
For the generation domain, this infrastructure takes the form of the industry
technical expertise required for designing, managing, and implementing semantic
model-based solutions and the existence of CIM standards to support product
development and solution deployments. When the ball gets rolling, every
subsequent activity built on the infrastructure becomes easier.

 5-11 
14635805
Section 6: Bibliography
“Application integration at electric utilities - System interfaces for distribution
management - Part 13: CIM RDF Model exchange format for distribution”,
IEC, Edition 1.0, June 2008.

CIM Primer 3rd Edition. 3002006001. Palo Alto, CA: Electric Power Research
Institute (2015).

“Energy management system application program interface (EMS-API) - Part

452: CIM Transmission Network Model Exchange Profile”, IEC, Draft.

“Interoperability Test “CIM for System Development and Operations, 2011,”

ENTSO-E Final Report, 15th August 2011.

Linthicum, D. Enterprise Application Integration. Reading: Addison Wesley

Longman. 2000.

Robinson, G. Model Driven Integration (MDI) for Electric Utilities. Proceedings

of DistribuTECH. Miami. 2002.

W3C. Resource Description Framework. Retrieved from W3C Recommendation :

http://www.w3.org/TR/REC-rdf-syntax/. February 1999.

W3C. Extensible Markup Language Version 1.0. Retrieved from W3C

Recommendation: http://www.w3.org/TR/REC-xml. October 2000.

W3C. RDF Vocabulary Description Language 1.0: RDF Schema. Retrieved from
W3C Recommendation Version 1: http://www.w3.org/TR/rdf-schema/.
February 2004.

W3C. XML Schema Part 0: Primer Second Edition. Retrieved from W3C
Recommendation : http://www.w3.org/TR/xmlschema-0/. October 2004.

 6-1 
14635805
 Appendix A: 61968 Asset Templates for
Interoperability
Template for SF6 Breaker

mechanism:BreakerMechanism breaker mechanism:BreakerMechanismInfo

pole 1 interrupter:InterrupterUnit pole 2 interrupter:InterrupterUnit pole 3 interrupter:InterrupterUnit interrupter:InterrupterUnitInfo

+MovingContact +FixedContact +MovingContact +FixedContact +MovingContact +FixedContact

bushing 1:Bushing bushing 2:Bushing bushing 3:Bushing bushing 4:Bushing bushing 5:Bushing bushing 6:Bushing bushing:BushingInfo

tank medium:Medium
type = sF6 tank assembly:AssetContainer
type = breakerTankAssembly

SF6 Dead Tank

3Poles/Tank whole SF6 dead tank breaker:AssetContainer whole SF6 dead tank breaker:SwitchInfo
3Poles/Mechanism type = breakerSF6DeadTank gasWeightPerTank = <gas weight>
Single Break

Figure A-1
Template for SF6 breaker

 A-1 
14635805
 Template for Two Winding Transformer

Figure A-2
Template for two winding transformer

 A-2 
14635805
Appendix B: Success Stories: Using
Common Information Model
Solutions
This section consists of success stories from using the common information
model (CIM) based on the experience in the area of power delivery.

Success Story: The Green Button Standard

Green Button is a White House initiative by the U.S. Federal Government’s

Office of Science and Technology Policy (OSTP), Department of Energy
(DOE), National Institute of Standards and Technology (NIST), and Council
on Environmental Quality (CEQ). Green Button promises a common experience
for consumers from their energy providers. This encourages the development of
an ecosystem of applications, known as apps, and service providers around the
availability of standardized energy usage information (EUI). The history behind
the development of the Green Button Standard can be found in the CIM Primer
report (EPRI report 3002006001).

The early results have been phenomenal. Tens of millions of American

consumers now have access to this CIM-based data. Dozens of utilities and
third-party services providers are exchanging data based on this standard. All of
this was accomplished in less than two years from the start of the Green Button
Initiative. A large penetration (30+ million customers) has been achieved in a
short amount of time. In addition, in late 2012, Canada followed the U.S. lead as
the province of Ontario adopted Green Button.

The significant impact of the Green Button effort is a testament to the common
sense of the solution, the elegance of the technology based on core pieces of
knowledge that took years to develop by a cadre of experts (that is, CIM), and
the assembly of a voluntary industry collaboration to solve a real problem in a
short amount of time.

 B-1 
14635805
 Success Story: Southern California Edison Uses CIM for Green
Button Support

As part of the NIST SGIP PAP10 drive to define a common format and
protocol for exchanging EUI, groups within UCAIug Open Smart Grid
(OpenSG) and NAESB needed an information model that stakeholders from a
wide variety of companies, industries, and backgrounds could agree on.

Southern California Edison (SCE) engaged Xtensible Solutions to support

OpenADE and NAESB groups working on the Energy Services Providers
Interface (ESPI) / Green Button specification. The goal was to choose objects
from the meter-reading package of the International Electrotechnical
Committee’s (IEC’s) CIM as the basis for the objects to be exchanged.

With assistance and guidance from SGIP and other groups, UCAIug is
developing a testing and certification program for Green Button standards to
ensure that implementations are interoperable with each other. This program will
allow energy consumers to grant access to automated periodic transfers of their
data to allow for active management of smart appliances and other energy
management services.

In 2012, SCE, along with Pacific Gas & Electric (PG&E) and San Diego Gas &
Electric (SDG&E), were among the first utilities to implement the standard,
making usage data available to most Californians. This data can be shared with a
growing number of providers of energy services.

Success Story: Consumers Energy

Consumers Energy has been adopting IEC CIM standards since 2008 when they
started its service gap analysis as part of the Automated Metering Interface
(AMI) solution effort. The intention was to deploy a solution that is based on
existing vendor systems using open industry standards such as IEC CIM where
available. The goal was to perform the gap analysis between these vendor
applications and standards-based services, and work with vendors to ensure that
there is sufficient coverage and support for industry standards from vendor
products perspective to deliver an open and integrated AMI solution for
Consumers Energy. As a result, interoperability could be achieved among various
systems and applications, and common semantics can be established to represent
power system objects in the company.

The standards that are involved are mainly IEC 61968-1, IEC 61968-9, and
IEC 61968-100. The IEC 61968-1 Interface Reference Model (IRM) is used to
group functional requirements. Its business functions and abstract components
are used as actors to describe application/systems interaction using UML
sequence diagrams. IEC 61968-9 is the base to define the metering and control
context models in XML schemas (XSDs) for the integration. After the initial
success of the service gap analysis, Consumers Energy started to build an
Enterprise Semantic Model (ESM) based on the IEC CIM. Displayed in Sparx
Systems’ Enterprise Architect (EA), the UML classes and attributes in the
standard became building blocks for message payload definitions for integrations.

 B-2 
14635805
 This model-driven methodology included in Xtensible Solutions’ MD3i
Framework was adopted. The framework includes a set of plug-ins that enables
users to work within EA’s user interface through each step of the methodology.

As a result, a semantically consistent common language is provided for

exchanging data information across platforms and systems in the enterprise.
Major benefits that the company recognized are the following:
 Eliminating duplicate work on integration
 Maximizing the reusability of a common data model
 Lowering the cost on overall integration and support
 Facilitating the composition and consumption of information across
multivendor landscapes
 Leveraging vendors’ CIM-based solutions and service-oriented architecture
(SOA) approaches for Integration

As a major contributor to the OpenSG user group, Consumers Energy also

worked closely with other utilities in North America to promote the CIM
standards and provide user requirements for CIM model improvement and
extensions. Recognizing the need for common Web services definition language
(WSDLs), Consumers Energy provided resources working on the IEC
61968-100 and leading the effort on defining common Web service templates for
the Implementation Profiles for the standard. Overall IEC CIM standards fit
well in the approach Consumers Energy put together for top-down business
process gap analysis, integration services design, and message payload and web
service definitions for integration. Consumers Energy is continuing to use this
methodology and associated tools for integration work in 2013 and the
foreseeable future.

Success Story: Long Island Power Authority

Long Island Power Authority (LIPA) leverages IEC CIM for Enterprise
Information Management and Semantic Integration initiatives.

As part of LIPA’s SmartGrid program, key business drivers are to reduce the cost
and complexity of the development and maintenance of integration solutions and
data repositories, enable the ability to integrate LIPA data among multiple
service providers, and implement “Best of Breed” applications.

Some of LIPA’s architectural goals are 1) develop an event-driven enterprise and

2) provide a robust yet agile and loosely-coupled architecture along service-
orientated architecture (SOA) principals. The loosely-coupled architecture
provides the following benefits:
 Changes to one system that have minimal impact on other existing systems
 Allows flexibility and agility to implement improved or new functionality at
much reduced cost, effort, and risk

 B-3 
14635805
  Allows the assimilation of data required for holistic decision making,
analysis, planning, risk management, and so on
 Allows for the development of new reports and functionality not previously
available in any of the off-the-shelf applications

LIPA avoids proprietary integration solutions, rather, targeting and embracing

semantic interoperability that leverages standards-based architecture to drive
down effort and cost for new integration and integration maintenance. This
semantic interoperability is key to enabling this decoupling of the architecture.

The LIPA approach comprises an end-to-end model-driven methodology for

designing and implementing a “common model” based on the IEC CIM to
provide the targeted loosely coupled system integration. This is consistent with
the goals of the IEC Technical Committee (TC) 57 Working Group (WG) 14.
LIPA has solved many of the challenges that utilities will face when adopting the
“common model” approach and implement a scalable solution for the
governance, processes, and methodology of managing this solution in a real-
world environment with multiple changing pieces. The methodology, framework
and key components can be found in the CIM Primer report (EPRI report
3002006001)

The methodology has helped LIPA establish a layered and loosely coupled
architecture with the business benefits of being more agile and responsive to
business and regulatory changes, leveraging services on new projects (enabling
reuse with minimal refactoring). Projects comprised integration solutions and
persistent data stores (ODSs and Data Warehouses). The LIPA Model-Driven
Semantic Integration approach has consistently performed under budget and on
time under complex and challenging conditions. Changes to implemented
solutions are completed in a fraction of the time that traditional SOA approaches
would take.

All new projects are adopting the architecture and methodology. The trend of
reduced cost and improved delivery speed is based on:
 Model-driven approach + governance + processes + tools for
“automated/integrated” development, testing, implementation, and
maintenance of the model
 Reuse of data and interfaces across company systems and SOA

Success Story: Idaho Power Company

When Idaho Power Company (IPC) began to transform its business with the
implementation of Smart Grid capabilities, it became apparent that they would
first need to put in place a robust system integration framework to handle all of
the new system interactions resulting from the multiple planned system
replacement projects. SOA coupled with mature interoperability standards
seemed to be the best approach to achieve a scalable and extensible solution. IPC
quickly realized that key to a successful outcome was to have in place a set of
policies and practices prior to starting the first integration project, which was to

 B-4 
14635805
 replace their outage management system. A critical component of governance
was the choice of international standards for all system interactions standards
that are independent of any particular vendor’s proprietary platform. The CIM
standards, as recommended by NIST, were selected for further evaluation to see
whether they could be used to not only handle the information exchanges for
each system interaction point, but that the tools to develop and maintain the
multiple system interaction definitions needed by IPC were available with good
vendor support.

The CIM standards are composed of an information model and multiple profiles
(or message definitions) that are derived from the model, ensuring a single source
definition of each data element for all information exchanges. Based on the CIM
UML model, IPC developed an ESM that provided the capability to include
private extensions and other modifications needed to the standard CIM model.
The CIM-based ESM then provided a common set of semantics and data
definitions from which all needed system interactions could be defined as XML
schemas. The integration framework, then, comprised an Enterprise Service Bus
(ESB) (for example, TIBCO) with data adapters at each system interface to
transform the data from the internal system representation to the ESM
representation.

To develop, manage, and maintain the ESM and message definitions based on
the ESM, IPC selected Xtensible’s MD3i Framework operating on the Sparx
EA platform, which is also used by the IEC standards body to manage and
maintain the CIM UML model. After first conducting a proof-of-concept
project using MD3i, Xtensible was selected to perform the following:
1. Develop a version of the MD3i process to meet the needs of IPC’s
integration design process.
2. Develop a multi-user, Oracle server-based EA modeling tool environment
for use by IPC system analysts to develop and maintain the ESM and system
interactions.
3. Provide training on the CIM and UML modeling within EA using the
MD3i add-ins to execute the integration design process for ESM modeling
and design.
4. Provide guidance and advice as well as development of selected system
integrations following the IPC integration design process. The XML
schemas for each system interaction were then used to create the System-to-
ESM mappings for the ESB system adapters.

The development of an integration design process and governance policies built

around a CIM-based ESM and system interface definitions was key to managing
multiple system integration projects. Because each new system integration is able
to build off the existing ESM from earlier projects through reuse, the amount of
work required to define system interactions decreases with each new project. The
consequence is that the CIM standards, with the proper tools to manage their
use, provide not only a scalable, maintainable integration framework, but one that
becomes more cost effective with each new system integration.

 B-5 
14635805
 Success Story: Sempra Energy

Sempra Energy utilities’ (SEU) goal is to manage its vast business data,
information, and knowledge as corporate assets. To that end, Sempra established
an enterprise information management (EIM) strategy and business case in 2007
to realize the value of these corporate assets in support of optimized business
performance.

Sempra IT established their Service Delivery Program (SDP) in support of two

large business programs (OpEx 20/20 and Smart Metering) to ensure that IT
services across all current and future programs are consistent and sustainable. A
key part of the SDP service portfolio is process integration and information
management capabilities using SOA supported and directed by the EIM
strategy.

Sempra realized that key to the success of the SOA integration in delivering
sustainable process integration and business intelligence for OpEx 20/20 and
Smart Metering was adopting a “common model” approach for defining common
interface definitions, providing loose coupling at the data level.

The CIM standards comprise an information model and multiple message

definitions that are derived from the model, ensuring a single source definition of
each data element for all information exchanges. Based on the CIM UML
model, Sempra developed its own ESM, referred to as the Sempra Information
Model (SIM), which contained all the required extensions and other
modifications needed to the standard CIM model. The CIM-based ESM then
provided a common set of semantics and data definitions from which all needed
system interactions could be defined as XML schemas. The Sempra integration
framework comprised an Enterprise Service Bus (Oracle). The integration
pattern used most of the time comprised data adapters at each system interface to
transform the data from the internal system representation to the ESM
representation. Sempra engaged Xtensible Solutions as a trusted advisor for
developing the EIM strategy and associated business case. Based on the EIM
strategy, Xtensible Solutions was engaged for the Smart Metering and OpEx
20/20 programs to provide support to the SDP for the SOA-based integration
delivery. To this end, Xtensible implemented Xtensible’s MD3i Framework to
manage, develop, and maintain the Sempra SIM which is based on the IEC
CIM. The framework and methodology were composed of the following:
 Governance and processes to manage the SIM extensions, as needed
 A toolset (plug-ins running on Sparx EA) that manages the multiple
reference models, common model, data lineage and mapping

Xtensible also helped train Sempra resources in order to establish a data

modeling function in the data architecture group.

The methodology supported the implementation of new applications such as

asset management, work management, mobile workforce management, and
outage management. The development of an integration design process and
governance policies built around a CIM-based ESM and system interface

 B-6 
14635805
 definitions was key to managing multiple system integration projects. Because
each interface definition is based off the SIM common model, and each adapter
transformed the proprietary interface to the common model representation,
Sempra achieved the decoupling of applications they desired. Sempra has also
achieved reuse of services through this approach, which has saved time and cost.
Because each new system integration is able to build off the existing ESM from
earlier projects through reuse, the amount of work required in order to define
system interactions decreases with each new project.

 B-7 
14635805
Appendix C: Technical Considerations
Related to Adding
Generation Assets to the
Common Information Model
This appendix explores some of the technical considerations related to leveraging
the existing common information model (CIM) asset model in the generation
domain. It is provided to give the reader a realistic view of both the feasibility of
leveraging the existing assets model and the work that would be involved in
doing so. It provides an overview of the existing CIM assets model and the work
being done to extend it to fully support asset health data exchange. It summarizes
the overlap in asset models between the generation and transmission/distribution
domains. In addition, it explores how two existing generation data models might
be harmonized to inform modeling improvement to the CIM to support its use
in the generation domain.

Summary of CIM Asset Health Model

Note: Information in this section is synthesized from the following EPRI

reports:
 Standard Based Integration Specification: A Reference Architecture and Basic Asset
Model in Support of Asset Health Analysis. EPRI, Palo Alto, CA: 2013.
3002000607.
 Standard Based Integration Specification: Common Information Model
Framework for Asset Health Data Exchange. EPRI, Palo Alto, CA: 2014.
3002002586.

The basic support offered by the current CIM for modeling of asset health-
related information was described in the CIM asset classes section. The existing
model forms a solid basis for asset health modeling, and it:
 Separates the model of the physical asset from the environment in which it is
deployed
 Supports a flexible definition of assets made up of components
 Allows nameplate data to be associated with an asset, asset component, or a
model

 C-1 
14635805
  Provides a way to describe the results of a variety of types of activities (for
example, tests, inspections, and maintenance) associated with assets and asset
components
 Supports the association of any type of measurement (such as flow, voltage,
state, temperature, alarm, wear, concentrations, counts, and so on) to assets
and asset components

However, there has been little real-world application of the CIM for asset health
purposes; therefore, the details of the model have not, for the most part, been
fleshed out.

The industry has long recognized the value of condition-based maintenance, but
it has been thwarted in its attempts to make meaningful improvements, largely
because the data needed for implementing asset health algorithms are difficult to
assemble. Data related to asset conditions exist in scattered locations and
disparate formats throughout most utilities, trapped inside applications, stored in
inaccessible files, or recorded on paper documents. Many types of information
could be useful in providing insight, including the following:
 Monitored data (sensors, intelligent electronic devices [IEDs], remote
terminal units [RTUs], fault recorders, synchrophasors, supervisory control
and data acquisition [SCADA] systems, energy management systems
[EMSs], and meter management systems)
 Historic monitored data (real-time historian, IEDs, fault recorders)
 Nameplate information (field, asset management systems [AMS])
 Installation, deinstallation, current location (work management systems
[WMSs], maintenance management system, paper documents, AMS)
 Maintenance records (maintenance management system, spreadsheets)
 Test/inspection results (paper, spreadsheet, lab-specific software systems,
home-grown inspection databases, AMSs)

There is a growing industry recognition of the role that data—and the structure
in which it is organized—play in enabling asset health analytics. At EPRI, the
Information and Communication Technology (ICT) program in Power Delivery
and Utilization (PDU) has recently engaged with a number of utilities on
projects focused on integrating and leveraging asset information across the
enterprise. The substations program, also in PDU, has initiated an Asset Health
System (AHS) Interest Group where meeting discussions frequently conclude,
“It’s all about corralling the data.”

CIMug Asset Health Focus Community

At the standards level, the CIM Users Group (CIMug), a community of CIM
users and product vendors, has created an Asset Health Focus Community
(AHFC), which is focused on exploring the requirements of asset health
information exchange and on suggesting CIM enhancements to meet them. The
AHFC was formed in late 2012 in recognition of the fact that the CIM Working

 C-2 
14635805
 Groups collectively lacked the asset domain subject matter expertise to adequately
suggest CIM asset model enhancements. The CIMug, with its broad community
of CIM users and implementers, was seen as the perfect organization to sponsor
a group to engage people with asset management and maintenance knowledge to
help define the requirements that CIM extensions would need to meet. Close
coordination with modeling experts from the IEC CIM Working Groups
(Working Group 14, in particular, because of its responsibility for the IEC 61968
series of standards, which includes assets) was also recognized as crucial.

One of the first activities of the AHFC was the development of a vision for an
architectural framework for integrating asset health-related information. The
vision is shown in Figure C-1. It illustrates where CIM standard models could
facilitate effective information sharing. Along the bottom, a wide variety of data
sources provides data: an AMS, a maintenance management system, a test
records database, sources of real-time and historic field data, and the energy
management system. Data are organized in the lower integration layer by use of
the CIM semantic model. The analytics layer turns the data organized by the
lower integration layer into information that is shared with users across the
enterprise through the upper integration layer, which is also enabled by the CIM.

The use of standard data models for information sharing means that analytics can
gather the input data they need and share their results electronically without the
need for manual data assembly or transfer. This broadens the number and type of
data sources that can be effectively used as input to analytics to include sources
with differing schemas and formats. It also opens up use of analytics results to
new applications like real-time contingency analysis that require frequent
updating of analytics results.

 C-3 
14635805
 .. .. .. .. ..
EMS Work
Planner Engineer Asset Field Contingency Management
Operator Manager Analysis System
Maintenance

3. Events / Visualization 4. Data to Applications

Insight
Data Integration (analytics results) CIM

2. Health and Risk Assessment Analytics

Data Integration (source data) CIM

1. Data from Multiple Sources

Asset Maintenance Test

Operations Field Data

EMS

Asset Field Data

Management Management Records
RTUs SCADA
System System Database
IEDs
Data
.. .. ..
Asset Manager Sensors
Field Maintenance
Operator

Figure C-1
Model-driven integration vision for asset health assessment

The AHFC has completed a significant amount of work in exploring

requirements and proposing CIM model extensions in several areas, including
asset lifecycle, oil analysis results, online monitored values, asset component
templates, and the exchange of historic data. The AHFC is in the process of
creating an Edition 2 of the IEC 61968-4 (Interfaces for Records and Asset
Management) standard. An overview of the complete CIM UML asset health
model, including the CIM extensions being proposed as part of Edition 2, is
shown in Figure C-2. The UML includes models for information related to the
following:
 Asset and asset component lifecycle
 Asset model, manufacturer, and nameplate
 Asset monitoring
 Procedures done on assets and the results of those procedures
 Work that is related to assets
 The physical environment surrounding assets
 Asset events (such as failures)
 Asset location in the network
 Asset ownership

 C-4 
14635805
 Figure C-2
Overview of 61968 asset health model with proposed asset health focus
community extensions

There is additional, more-detailed CIM UML modeling supporting each of the

colored areas shown in Figure C-2. The complete UML is part of the work of
the AHFC, which is collected on the CIMug website (www.cimug.org),
accessible via the “asset health” item on the “Focus Community” pull-down
menu located on the top menu bar.

Asset Templates for Interoperability

As has been pointed out in previous EPRI reports (Standard Based Integration
Specification: A Reference Architecture and Basic Asset Model in Support of Asset
Health Analysis [3002000607] and Standard Based Integration Specification:
Common Information Model Framework for Asset Health Data Exchange
[3002002586]), the Asset and AssetContainer classes of the CIM provide a
powerful tool for accurately modeling assets and their components, supporting an
infinite variety of nested combinations of components. The downside of this

 C-5 
14635805
 flexibility is that it does little to promote interoperability. If one application
models a given asset with one combination of components and another models
the same asset with a different combination, their ability to exchange information
easily and clearly is compromised. The AHFC has recognized the need for
instance templates to aid in the semantic modeling of assets and to support the
exchange of their asset health information. Templates for common breaker
families and for transformers have been developed by the AHFC. Samples are
shown in Figures C-3 and C-4.

mechanism:BreakerMechanism breaker mechanism:BreakerMechanismInfo

pole 1 interrupter:InterrupterUnit pole 2 interrupter:InterrupterUnit pole 3 interrupter:InterrupterUnit interrupter:InterrupterUnitInfo

+MovingContact +FixedContact +MovingContact +FixedContact +MovingContact +FixedContact

bushing 1:Bushing bushing 2:Bushing bushing 3:Bushing bushing 4:Bushing bushing 5:Bushing bushing 6:Bushing bushing:BushingInfo

tank medium:Medium
type = sF6 tank assembly:AssetContainer
type = breakerTankAssembly

SF6 Dead Tank

3Poles/Tank whole SF6 dead tank breaker:AssetContainer whole SF6 dead tank breaker:SwitchInfo
3Poles/Mechanism type = breakerSF6DeadTank gasWeightPerTank = <gas weight>
Single Break

Figure C-3
Template for SF6 breaker

 C-6 
14635805
 Figure C-4
Template for two winding transformer

Support for History

In the world of asset condition assessment, there is a ubiquitous need for history.
Asset heath analysis is all about looking at assets over the full course of their
lifetimes. From the total number of breaker trips to the last internal maintenance
to the trend of power factor test results, examples of the need for history are
everywhere. An EPRI report, Standard Based Integration Specification: Common
Information Model Framework for Asset Health Data Exchange (3002002586),
published in 2014, provided a compelling illustration of the need for CIM
support of historic data exchange. The report outlined a simple asset health
integration environment and put forth a number of use cases describing data
exchanges in the environment. The report went on to propose “that the messages
by which shared information is exchanged are the place where the universal
support for history is best accomplished.” In addition, it noted, “This approach
seems to conceptually align as well with the notion of ‘incremental datasets’
currently under discussion in a joint CIM Working Group task force working on
change modeling.”

In the year since the EPRI report was published, significant progress has been
made in exploring this idea. A recent proposal for exchange of asset data history
has been put forth that leverages the nearly complete work of the CIM Working
Group Change Modeling Task Force to facilitate the sharing of changes to asset
data over time. The UML model for this is presented in Figure C-5, in which
the change model classes created by the Change Modeling Task Force are shown

 C-7 
14635805
 in yellow, and the classes supporting exchange of asset history are shown in teal.
It is worth noting that the design is intentionally general enough to support the
exchange of history of any property of any instance of a CIM class, not just those
related to assets.

Figure C-5
Leveraging the proposed CIM change model for asset history exchange

 C-8 
14635805
Appendix D: Technical Consideration for
Using the EPRI Master
Equipment List Report
(1025340) for Development
of Generation Systems in the
Common Information Model
EPRI Report 1025340, Developing and Maintaining a Master Equipment List for
Fossil Power Plants: Asset Naming Conventions, Classifications, and Hierarchies,
proposed a standardized approach to naming and classifying all plant equipment
owned by an organization. It outlined the need for such an approach to enable
deployment of fleet-wide reliability software and explored and recommended a
master equipment list (MEL) asset classification and naming hierarchy based on
the structure illustrated in Figure D-1 .

Plant

System

Sub-System

Component
Type
Specific ID

Figure D-1
Hierarchical structure of data in the master equipment list, developed by EPRI
in 2012

 D-1 
14635805
 The MEL hierarchy enables equipment organization and naming in a technique
in which each component has a six-digit plant/unit ID. Each component then
has a two-letter system code and a two-letter subsystem code. Next, the
component has a three-letter component category, and it has a 12-alphanumeric
code for location.

Comparison to CIM

Similarities in motivation and objective between MEL and common information

model (CIM) exist. Both are based on a fundamental goal of being able to easily
implement an application in multiple environments. Both aim to support a
similar set of processes (work management, asset criticality, maintenance
optimization, performance monitoring, long-term asset management, and so on).
Both envision organizing similar types of asset data (model, manufacturer, serial
number, manufacture date, in-service date, name, and nameplate) and related
data (work and maintenance history). Both recognize the need for data
governance in order to maintain data quality. The intent of both is to provide
unambiguous identification of assets across systems.

Some similarities in modeling approach exist as well, with containment

hierarchies used as a vehicle for organizing information related to both assets and
their components. Interestingly, they both appear to be influenced to some
degree by the design of the same asset management product, Maximo.

At a high level, the largest difference between the MEL and CIM is in the scope
of the solution. MEL aims to define an asset identification and organization
structure, while CIM aims to define a data structure supporting a far wider range
of information, including asset and asset component identification and naming,
but also encompassing a wide variety of asset-related data (measurements; test,
inspection, and maintenance results; lifecycle; nameplate; and so on).

There is an interesting disconnect between MEL and the CIM approach to

object identification. MEL details a strategy for creation of object identifiers
(UNIDs) based on a containment hierarchy that is humanly understandable and
reflective of the real world. The CIM uses what are essentially long random
numbers as identifiers. Early in the history of the CIM, the decision was made
to express the identity of every shared object by means of a unique master
resource ID (MRID). The MRID intentionally contains no meaningful
information; it is simply an identifier. In CIM, human-interpretable names are
understood to be essential, but, because they may need to be changed or
corrected over time, they are never used for the purpose of unique identification.
As was described in the CIM Identify and Naming section in Section 4 of this
report, support for human-readable names is provided by the
IdentifiedObject.name attribute, and support for alternate names (needed by
systems with varying identifier format rules) is provided by the Name, NameType,
and NameTypeAuthority classes.

 D-2 
14635805
 Rationalizing Master Equipment List to CIM

From a data modeler’s perspective, create the UML describing the data models
helps in “seeing” the context of data. By way of an example, there is a Medium
class in CIM that has the following definition:

A substance that either (1) provides the means of transmission of a

force or effect, such as hydraulic fluid, or (2) is used for a surrounding
or enveloping substance, such as oil in a transformer or circuit breaker.

In other words, Medium is used to define a fluid that envelops equipment, usually
cooling. In the CIM, it has only been used in the context of gas-insulated relays.
When considering all of the fluids in the fossil fuel generation context, the list of
potential mediums grows considerably. Table D-1 has examples of fluids MEL
models that could be considered a match for the Medium class.

Table D-1
Examples of master equipment list elements to be converted into the Medium class

System Sub-System
TurboGenerator Main hydraulic and lube oil
Air Supply Control air
Station service air
Water Supply Raw cooling water
Raw service water
Condenser circulating water
Water treatment
Potable water

Whether it is appropriate to add the values listed under Sub-System in Table

D-1 to the enumeration of possible kinds expressed by the Medium.kind attribute
in CIM can be determined only by understanding the context in which both are
used.

 D-3 
14635805
Appendix E: Description of EPRI
Preventive Maintenance
Basis Database in Relation to
the Common Information
Model
Preventive Maintenance Basis Database

The Preventive Maintenance Basis Database (PMBD) software collects

operating, repair and maintenance experiences for the major components and
valves in power generating facilities into a single database and offers EPRI
member utilities a basis for maintenance task selection.

Within the PMBD are baseline equipment templates that have been widely
adopted as a reference for maintenance planning and schedule and equipment
data tables that were built through an expert elicitation process described in
EPRI Report 1023073. These data allow for the PMBD’s “Vulnerability”
analysis. This tool allows maintenance and engineering personnel to establish a
quantitative maintenance basis that factors in equipment history, design,
operating experience and industry data customized to their plant’s resources.

PMBD Purpose

The PMBD was designed to support the task analysis portion of the AP-913
process from the Institute of Nuclear Power Operations (INPO). The primary
use of the PMBD has been providing reference maintenance schedules and task
definitions. Figure E-1 is an example of a maintenance schedule:

 E-1 
14635805
 Figure E-1
Task interval template

 E-2 
14635805
 This decades-long, collaborative, institute-wide effort has produced more than
320 data tables—representing assets that support power generation—as shown in
Table E-1.

Table E-1
EPRI PMBD asset scope

AC motor Cooling tower: natural Steam turbine

draft, counter flow
Air dryer Coupling Steam turbine controls
Battery: lead acid DC motor Substation circuit
breaker
Battery: NiCad Diesel: small standby Switchgear: low
voltage
Battery: valve regulated Distribution circuit breaker Switchgear: medium
lead acid voltage
Battery charger Distribution disconnect Switchgear: motor
control centers
Cable: buried power Distribution lightning Transformer
arrestor: motor-operated
valve (MOV)
Cable: plant Distribution recloser Turbine: main
feedwater
Coal handling: conveyer, Exciter Turbine: terry
belt type
Coal handling: magnetic Fan: induced draft (ID) or Valve: air operated
separator forced draft (FD)
Coal handling: vibrating Fluid drive Valve: check
feeder
Compressor: centrifugal Fly ash handling Valve: motor operated
Compressor: reciprocating Gas turbine Valve: relief
Compressor: rotary screw Gas turbine: fuel gas Valve: solenoid
system operated
Compressor and pump: Gas turbine: heat Valve: steam control
rotary, liquid ring recovery steam generator valves
Condenser Gearbox with cooler Voltage regulator
Cooling tower: Steam jet air ejector Water intake screen
mechanical draft

More recently, member utilities have been using the vulnerability analysis feature
in the PMBD that uses the equipment data tables to aid users in optimizing their
maintenance task selection and frequency. Figures E-2 and E-3 show the input
removing a maintenance task from the schedule and the subsequent output.

 E-3 
14635805
 Figure E-1
PMBD vulnerability input

Figure E-2
PMBD vulnerability output

 E-4 
14635805
 A number of EPRI projects are making greater use of these data tables and
expanding the equipment scope to areas such as combined-cycle, combustion
turbine, and co-generation facilities. In addition, continuing the coverage of the
diversity of power generation and support equipment in the fleet remains a
priority for a growing number of EPRI programs.

PMBD Data Sources

The data in the PM Basis Database are built using a regimented expert elicitation
process (EPRI Report 1023073) that leverages the experience of experts from
around the industry. The entire process yields is summarized in Table E-2.

Table E-2
Expert elicitation process

Process Step Description

Designate A component type is a clear title that communicates the
component type component analyzed where it is sometimes differentiated
by a number of factors.
Establish boundary Make a statement that establishes what is included and
explicitly excluded from the boundary of the component or
system.
Define duty-cycle Define how duty-cycle and environmental stressors
and identify challenge equipment availability.
equipment
stressors
Identify component Identify those tasks that provide information on component
reliability tasks material condition and performance including: condition-
monitoring, performance monitoring, and preventive
maintenance tasks.
Develop List all of the subcomponents, any reasonable way those
degradation subcomponents fail, and the causes for that failure along
modes with a number of other factors.
Determine The elicitation team comes to consensus on the scope of
component task the Component Tasks and on the Task Effectiveness for
effectiveness each Degradation Mode/Component Task combination.
Summarize Complete a final review of the previous work and wrap-up
elicitation tasks that complete the following fields: Maintenance Risk,
Common Failure Causes, and Industry References.
Fault Signature Development can be part of this final step.
Analyze results In this stage, the facilitators complete all Component Task
fields and adopt Baseline intervals, create Task Ranking,
build as-found condition checklists, perform the peer
review, and test component data table in analysis
software.

 E-5 
14635805
 The component degradation tables are built largely during the “Develop
Degradation Modes” through identifying the subcomponents of assets, then
identifying the ways those assets can degrade, and then identifying the causes.

Figure E-4 shows a sample failure mode, as explained in an EPRI presentation.

Figure E-3
PMBD equipment failure mode

There are more than 23,000 of these in the database. There are more than 7,000
unique combinations of assets and Failure Locations in the database. These can
be used to provide a quicker way to build a comprehensive framework that would
inform the class hierarchy. Messaging can also be informed by the “Degradation
Influence” section of the data tables and the associated Task Effectiveness.

Comparison to CIM

The CIM and PMBD both define data models, but for different purposes. The
data models of the CIM are crafted for the purpose of facilitating exchange of
shared data between multiple applications, the data structure that underlies
PMBD supports its analytical functions. There are, however, several similarities
in the approaches to modeling. Both models support the notion of asset
components, leverage the idea of containment for organizing data, and address
the need to describe tasks that provide information on component condition.
The PMBD data model has a wider scope, including the two following areas that
the CIM has not yet addressed, but certainly recognizes the need for:
 Planned maintenance schedules
 Failure/degradation modes and risks

 E-6 
14635805
14635805
14635805
Export Control Restrictions The Electric Power Research Institute, Inc.
Access to and use of EPRI Intellectual Property is granted (EPRI, www.epri.com) conducts research and
with the specific understanding and requirement that development relating to the generation, delivery and
responsibility for ensuring full compliance with all applicable use of electricity for the benefit of the public. An
U.S. and foreign export laws and regulations is being
independent, nonprofit organization, EPRI brings
undertaken by you and your company. This includes an
together its scientists and engineers as well as
obligation to ensure that any individual receiving access
hereunder who is not a U.S. citizen or permanent U.S. experts from academia and industry to help address
resident is permitted access under applicable U.S. and challenges in electricity, including reliability,
foreign export laws and regulations. In the event you are efficiency, affordability, health, safety and the
uncertain whether you or your company may lawfully obtain environment. EPRI also provides technology, policy
access to this EPRI Intellectual Property, you acknowledge
and economic analyses to drive long-range
that it is your obligation to consult with your company’s legal
research and development planning, and supports
counsel to determine whether this access is lawful. Although
EPRI may make available on a case-by-case basis an research in emerging technologies. EPRI’s
informal assessment of the applicable U.S. export members represent approximately 90 percent of the
classification for specific EPRI Intellectual Property, you and electricity generated and delivered in the United
your company acknowledge that this assessment is solely for States, and international participation extends to
informational purposes and not for reliance purposes. You
more than 30 countries. EPRI’s principal offices and
and your company acknowledge that it is still the obligation of
laboratories are located in Palo Alto, Calif.;
you and your company to make your own assessment of the
applicable U.S. export classification and ensure compliance Charlotte, N.C.; Knoxville, Tenn.; and Lenox, Mass.
accordingly. You and your company understand and
Together…Shaping the Future of Electricity
acknowledge your obligations to make a prompt report to
EPRI and the appropriate authorities regarding any access to
or use of EPRI Intellectual Property hereunder that may be in
violation of applicable U.S. or foreign export laws or
regulations.

© 2015 Electric Power Research Institute (EPRI), Inc. All rights reserved.
Electric Power Research Institute, EPRI, and TOGETHER…SHAPING THE
FUTURE OF ELECTRICITY are registered service marks of the Electric
Power Research Institute, Inc.
30020066661

Electric Power Research Institute

3420 Hillview Avenue, Palo Alto, California 94304-1338 • PO Box 10412, Palo Alto, California 94303-0813 • USA
14635805800.313.3774 • 650.855.2121 • [email protected] • www.epri.com