epri introtocimforintegratingappsandsystemspdf

98
The Common Information Model for Distribution An Introduction to the CIM for Integrating Distribution Applications and Systems 1016058

Upload: craig-debenham

Post on 28-Apr-2015

77 views

Category:

Documents


6 download

DESCRIPTION

EPRI Intro to CIM

TRANSCRIPT

Page 1: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

The Common Information Model for Distribution

An Introduction to the CIM for Integrating Distribution Applications and Systems

1016058

Page 2: EPRI IntroToCIMForIntegratingAppsAndSystemspdf
Page 3: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

ELECTRIC POWER RESEARCH INSTITUTE 3420 Hillview Avenue, Palo Alto, California 94304-1338 ▪ PO Box 10412, Palo Alto, California 94303-0813 ▪ USA

800.313.3774 ▪ 650.855.2121 ▪ [email protected] ▪ www.epri.com

The Common Information Model for Distribution

An Introduction to the CIM for Integrating Distribution Applications and Systems

1016058

Technical Update, November 2008

EPRI Project Manager

L. King

Page 4: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

DISCLAIMER OF WARRANTIES AND LIMITATION OF LIABILITIES

THIS DOCUMENT WAS PREPARED BY THE ORGANIZATION 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 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.

ORGANIZATION THAT PREPARED THIS DOCUMENT:

Utility Integration Solutions, Inc. (UISOL)

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 © 2008 Electric Power Research Institute, Inc. All rights reserved.

Page 5: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

i

CITATIONS This document was prepared by

Utility Integration Solutions, Inc. (UISOL) 24 Benthill Court Lafayette, CA 94549

Principal Investigator T. Nielsen

This document describes research sponsored by the Electric Power Research Institute (EPRI).

This publication is a corporate document that should be cited in the literature in the following manner:

The Common Information Model for Distribution: An Introduction to the CIM for Integrating Distribution Applications and Systems. EPRI, Palo Alto, CA: 2008. 1016058.

Page 6: EPRI IntroToCIMForIntegratingAppsAndSystemspdf
Page 7: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

iii

REPORT SUMMARY This report introduces the Common Information Model (CIM) as it applies to electrical distribution system operations. The judicious use of the CIM to integrate applications and systems can enhance operational functionality and reduce the lifetime cost of integration efforts. This report can serve as a starting point for distribution system managers, engineers, and information technology (IT) resources for preparing strategic and tactical plans for enterprise integration projects.

Background The CIM has been used for several years to integrate transmission management system applications and to exchange power system models between systems. CIM has not been widely adopted for the integration of distribution management systems and applications, however. Feedback from utilities indicated that informational resources were lacking regarding the CIM and regarding integration methodologies in general.

Objectives • To explain how CIM can be used to integrate distribution applications

• To describe what utilities can do today to integrate their systems and prepare for the future so they can take advantage of Service Oriented Architecture (SOA) using the CIM.

Approach In order to hit the target of providing beneficial information for the utility industry, the project team held a kick-off meeting with the IntelliGrid funders at the beginning of the project. The team presented broad information on the CIM and Enterprise Application Integration and received feedback on particular aspects of the application of CIM to distribution systems that need attention. The team used this feedback and its knowledge of the CIM and common industry practices with respect to system integration to write this introduction to the use of CIM in distribution systems.

Results This report is intended to provide an introduction to the CIM as it applies to electrical distribution systems. It is targeted for distribution utility general managers, software IT managers and analysts, and distribution engineers in planning, maintenance, and operations who may not familiar with the CIM and its purpose and benefits. The report will be of particular interest to distribution organizations that might be evaluating or considering utilizing the CIM in an integration product, as part of vendor selection criteria, or for building an intelligent grid strategy.

Page 8: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

iv

The report addresses the following main topics:

• Integration overview of applications and systems used for the management and optimization of electrical distribution networks

• The CIM: history and background, packages, and profiles

• The integration process and where the CIM is used

• Integration technology including Service Oriented Architecture (SOA) and an Enterprise Service Bus (ESB)

EPRI Perspective The ever-changing business environment leads to a greater need for business and operating flexibility in the energy industry. EPRI is committed to ensure this need can be met in the area of data exchange and data management. EPRI continues to sponsor research in areas where CIM needs additional definition or visibility such as the use of CIM for planning and dynamic modeling initiatives. EPRI also plays a role in introducing CIM into other research activities where it can be used in larger initiatives such as the IntelliGrid program.

With the adoption of advanced metering infrastructure (AMI) as well as other new sensors and information sources in the electrical distribution system, the problem of integration is not getting any easier. Vendor support and utility adoption of the CIM for managing distribution systems will help reduce the long-term costs of application and system integration at a time when the number of integration points is increasing.

Keywords Common Information Model (CIM) Distribution Management System (DMS) Enterprise Application Integration (EAI) IEC 61968 IEC 61970 Service Oriented Architecture (SOA)

Page 9: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

v

ACKNOWLEDGEMENTS

We would like to acknowledge and thank the attendees from the kick-off meeting held in Atlanta on June 3, 2008. The attendees provided critical insight and feedback into the structure and outline used for this report. We would also like to give special thanks to Southern Company for hosting the workshop.

The following people provided content, source material, and feedback on early drafts of this report:

• Scott Neumann • Ali Vojdani • Parag Parikh

Page 10: EPRI IntroToCIMForIntegratingAppsAndSystemspdf
Page 11: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

vii

CONTENTS

1 INTRODUCTION............................................................................................................1-1 1.1 Report Purpose ........................................................................................................1-1 1.2 Role of EPRI and IntelliGrid .....................................................................................1-1

2 UTILIZING IT INTEGRATION FOR DISTRIBUTION SOFTWARE...............................2-1 2.1 Common Software Systems used in Distribution .....................................................2-2 2.2 Integration of Distribution IT Systems ......................................................................2-2 2.3 Minimizing the Distance to Integrate ........................................................................2-3 2.4 Building the Business Case and Managing the Cost ...............................................2-4 2.5 Further Reading .......................................................................................................2-5

3 THE COMMON INFORMATION MODEL......................................................................3-1 3.1 History of the CIM.....................................................................................................3-1

3.1.1 The EPRI Roots .................................................................................................3-1 3.1.2 The IEC Standard...............................................................................................3-2 3.1.3 CIM Users Group ...............................................................................................3-3 3.1.4 IEEE ...................................................................................................................3-3 3.1.5 EPRI’s Continued Role.......................................................................................3-4

3.2 What CIM Does ........................................................................................................3-4 3.3 What CIM Isn’t..........................................................................................................3-4 3.4 CIM Background.......................................................................................................3-5

3.4.1 The Unified Modeling Language (UML) .............................................................3-5 3.4.2 eXtensible Markup Language (XML)................................................................3-13 3.4.3 Ontology Definition ...........................................................................................3-14 3.4.4 Resource Description Framework (RDF) .........................................................3-14 3.4.5 Web Ontology Language (OWL) ......................................................................3-15

3.5 CIM Packages ........................................................................................................3-16 3.6 Relevant 61970 Packages .....................................................................................3-17

3.6.1 The Core Package ...........................................................................................3-17 3.6.2 The Topology Package ....................................................................................3-18 3.6.3 The Wires Package – Part 1 Lines...................................................................3-19 3.6.4 The Wires Package – Part 2 Transformers ......................................................3-21 3.6.5 The Wires Package – Part 3 Switches .............................................................3-21

3.7 Relevant 61968 Packages .....................................................................................3-23 3.7.1 Assets Package................................................................................................3-23 3.7.2 Operations Package.........................................................................................3-24 3.7.3 Work Package..................................................................................................3-25

3.8 CIM Profiles............................................................................................................3-26 3.8.1 Definition of a Profile ........................................................................................3-26

Page 12: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

viii

3.8.2 CPSM Profile....................................................................................................3-26 3.8.3 Planning Profile ................................................................................................3-27 3.8.4 Dynamics Profile ..............................................................................................3-27 3.8.5 CDPSM Profile .................................................................................................3-27

3.9 Generic Interface Definition (GID) ..........................................................................3-28 3.10 Further Reading .....................................................................................................3-29

4 INTEGRATION PROCESS............................................................................................4-1 4.1 Use Case Overview..................................................................................................4-1 4.2 Use Case Development ...........................................................................................4-3 4.3 Sequence Diagram Creation ....................................................................................4-4 4.4 Domain Modeling .....................................................................................................4-6 4.5 Message Design.......................................................................................................4-7 4.6 Interface Design .......................................................................................................4-9 4.7 Interface Construction ............................................................................................4-10 4.8 Artifact Management ..............................................................................................4-11 4.9 Managing CIM Extensions .....................................................................................4-12

4.9.1 Extension Management....................................................................................4-12 4.9.2 Extension Attribute ...........................................................................................4-13 4.9.3 Extension Class................................................................................................4-13 4.9.4 Impact of New CIM Versions............................................................................4-15 4.9.5 Merging Models................................................................................................4-15

4.10 Further Reading .....................................................................................................4-16

5 INTEGRATION TECHNOLOGY ....................................................................................5-1 5.1 Introduction...............................................................................................................5-1 5.2 Service Oriented Architecture (SOA) .......................................................................5-1

5.2.1 Definition of SOA................................................................................................5-1 5.2.2 Integration using SOA ........................................................................................5-1

5.3 Enterprise Service Bus (ESB) ..................................................................................5-3 5.4 Enterprise Application Integration (EAI) Suites ........................................................5-5 5.5 Practical Guidelines..................................................................................................5-6 5.6 Messaging Framework .............................................................................................5-8 5.7 Integration Options .................................................................................................5-10 5.8 Other Considerations .............................................................................................5-11 5.9 Integration Patterns ................................................................................................5-12 5.10 IT Standards...........................................................................................................5-14

5.10.1 Security Issues...............................................................................................5-14 5.10.2 Implementation Technology ...........................................................................5-14

5.11 Comparison with MultiSpeak..................................................................................5-15 5.12 Further Reading .....................................................................................................5-19

6 SUMMARY.....................................................................................................................6-1

Page 13: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

ix

A TERMINOLOGY ........................................................................................................... A-1

B COMMONLY USED TOOLS ........................................................................................ B-1

C LIST OF DISTRIBUTION RELEVENT IEC STANDARDS EFFORTS ......................... C-1

Page 14: EPRI IntroToCIMForIntegratingAppsAndSystemspdf
Page 15: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

1-1

1 INTRODUCTION The Common Information Model (CIM) is an abstract information model that can be used to model an electrical network and the various equipment used on the network. By using a common model, utilities and vendors can reduce their integration costs, which should allow more resources to be applied toward increased functionality for managing and optimizing the electrical system.

1.1 Report Purpose

This report is intended to provide an introduction to the CIM as it applies to electrical distribution systems. It is targeted for distribution utility general managers, software IT managers and analysts, and distribution engineers in planning, maintenance, and operations who may not familiar with the CIM and its purpose and benefits. It is of particular interest to distribution organizations that might be evaluating or considering utilizing the CIM in an integration product, as part of vendor selection criteria, or for building an intelligent grid strategy.

1.2 Role of EPRI and IntelliGrid

The ever-changing business environment leads to the greater needs for business and operating flexibility in the energy industry. EPRI is committed to ensure this need can be met in the area of data exchange and data management.

EPRI continues to sponsor research in areas where CIM needs additional definition or visibility such as the CIM for planning and CIM for dynamic modelling initiatives. EPRI plays a role in introducing CIM into other research activities where it can be used in larger initiatives such as the IntelliGrid program.

With the adoption of AMI as well as other new sensors and information sources in the electrical distribution system, the problem of integration is not getting any easier. Vendor support and utility adoption of the CIM for managing distribution systems will help reduce the long-term costs of application and system integration at a time when the number of integration points is increasing.

Page 16: EPRI IntroToCIMForIntegratingAppsAndSystemspdf
Page 17: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

2-1

2 UTILIZING IT INTEGRATION FOR DISTRIBUTION SOFTWARE In the typical distribution utility there are hundreds and even in some cases thousands of software solutions and applications that are managed by the IT department. These applications were initially used and operated independently by the various groups, departments, and organizations in the utility. Whenever a business process required information to flow from one system or application to another system or application, the process was managed manually. This level of maturity in an organization’s software infrastructure is sometimes called “islands of automation”, “software silos”, or “software stovepipes”.

Typically, over time, these group and departmental boundaries between systems were bridged by software built by the IT department or, in some cases, in ad-hoc fashion by desperate end users. Inevitably, this situation becomes unmanageable because the software bridges are built by different people using diverse technologies. The number of interfaces rapidly becomes very large because there are so many needed areas of integration that can be easily justified on their own. The situation is further aggravated as systems are upgraded or replaced and as business processes change.

Two strategies exist for dealing with this: 1) utilize a common integration platform for all integration, and 2) reduce the number of systems and applications by purchasing from a small set of vendors who can offer large suites of applications pre-integrated (or “internally” integrated). Even if the later strategy is pursued, consolidating to just one single system and vendor is, for all practical purposes, impossible; so “external” integration is still needed, and the use of a common integration platform still has many benefits.

There are several common integration technologies and platforms that are commonly used today. These have names like:

• Service Oriented Architecture (SOA)

• Enterprise Application Integration (EAI)

• Enterprise Service Bus (ESB)

• Web Services

Each of the above technologies is unique and has specific capabilities and characteristics; they all attempt to solve a similar problem of providing a solution to the problems associated with difficult–to-maintain ad-hoc integration technologies. More specific details of these technologies are discussed later in this report.

When one of these technologies is utilized, one of the biggest tasks not solved by the technology is the challenge of mapping the data output from a source system to the input needs of the sink system. To perform this mapping, experts in both systems are generally required who understand the exact meaning of each data element being transferred.

Page 18: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

2-2

A way to reduce the effort and complexity of this task is for each system to map their data elements to a common data model. Instead of mapping the data elements from each system directly to the data elements of each other connected system, the mapping is performed once from each system to this common model. In cases where the number of systems is large and the number of interconnects is large, this method can significantly reduce the number of mappings required.

A technique for further simplifying this task is to utilize one or more industry standard information models, so that the common model doesn’t have to be hand built—rather, it can be adopted. These industry standard models are typically called common information models, and they exist for many different industries such as telecommunications, healthcare, and manufacturing. Within the electric utility industry, the CIM has emerged as this common information model. (There are also common information models that are specific to back-office functions such as human resources, finance, purchasing, and customer relationship management; and there’s also a common information model for managing computer network infrastructures.)

2.1 Common Software Systems used in Distribution

Only a few decades ago, in many of even the largest utilities, distribution systems were mostly managed with paper maps, paper asset records, and manual processes for reading measurements, communicating with field crews, managing outages, and collecting meter information. Today, it is much more common to find software systems that automate most of these aspects of running a distribution system; and it has only been within the last ten to fifteen years that these systems became available from software vendors rather than something built entirely in-house by the utility.

Below is a list of the more common names for many of these systems that are available from vendors that serve the distribution utility marketplace:

• Distribution Management Systems (DMS)

• Outage Management Systems (OMS)

• Supervisory Control and Data Acquisition (SCADA)

• Mobile Workforce Management (MWM)

• Geographical Information Systems (GIS)

• Work Management Systems (WMS)

• Enterprise Asset Management Systems (EAMS)

• Metering and Meter Data Management Systems (MDMS)

• Customer Information Systems (CIS)

• Planning and Reliability Analysis

2.2 Integration of Distribution IT Systems

As described in general terms earlier, integration practices have historically been relatively ad-hoc and not well structured. For this reason the systems mentioned above have are connected in many different ways from one utility to the next. Below is a diagram that represents just one example of the interconnections that might exist between these systems.

Page 19: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

2-3

Outage Management

System

Geographic Information

System

Customer Information

System

Asset &Work

Management System

Mobile Workforce Management

System

Meter Data ManagerMetering System

SCADADistribution

Management System

Reliability & Planning Systems

Figure 2-1 Example Distribution Systems Interconnections

2.3 Minimizing the Distance to Integrate

An objective frequently defined for interoperability is the concept of “plug-and-play”. Plug-and-play is usually defined as a goal where the system integrator is able to configure a connection between a software system simply by “plugging” it in. The plugging in is achieved by an “adaptor” that automatically determines the nature of the newly connected system so that it is properly configured and can begin operation properly. If we consider the level of integration involved as a length or distance, then the “distance to integrate” for plug-and-play is small.

Page 20: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

2-4

No standard exists, requires completely custom integration

Interfaces can be transformed and/or

mapped

Interfaces use a common

model

Optimal: ‘Plug and Play’ standard defined

Figure 2-2 Illustration of Integration Distance

Achieving plug-and-play is not easy; and in many, complex situations, it is not practical to specify standard interfaces to this level of detail. The greater the customization and effort to make and test these changes, the greater is the distance to integrate.

However, standards or best practices can be used to shorten this distance. For example, a commonly used information model can provide semantics that a community of integrators readily understands. Standard syntax, such as XML, provides a familiar format and structure without significant training. With time, things can more closely approach plug-and-play. At least by reaching agreements in specific areas of interoperation, a community can improve system integration and the effort to achieve interoperability.

There are many techniques that can reduce the distance to integrate. These include:

• Use the CIM as the common information model for integration

• Use general purpose software standards and technologies where appropriate

• Minimize the amount of custom code, biasing towards next-generation tools that allow integration to be ‘configured’ instead of ‘coded’, remembering that every line of code needs to be tested, maintained, and evolved

2.4 Building the Business Case and Managing the Cost

Reducing the distance to integrate can have a significant impact on installation and maintenance costs. A business case for using the CIM and modern integration technology requires identifying the savings associated with the reduction of development costs and testing costs and with the reduction in rework associated with ad-hoc or primitive integration technologies. In many cases, this requires identifying costs that are spread across many departmental boundaries.

Page 21: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

2-5

Another approach to building the business case is to identify the returns associated with improved business effectiveness, increased agility, and faster response to changes. The unforeseen changes that are most likely going to occur in the utility industry due to the intelligent grid, distributed resources, environmental concerns, and renewable energy sources could easily make adopting the CIM and associated integration technologies a very compelling case on its own.

How is this increased agility and faster response achieved with the improved interoperability associated with reducing the distance to integrate? It creates well-defined points in applications and systems that have already been deployed, and it allows for new applications to easily connect. This can enable one application to be substituted for another with a lower cost; it can also provide a path to upgrade applications and systems in a localized manner that preserves the overall integrated system operation thus reducing testing costs. This can create an environment where multiple vendors can compete to provide the same functionality and where things such as price and reliability become distinguishing characteristics. The same well-defined points of connection can also allow for new capabilities or features to be integrated into the system.

2.5 Further Reading

1. Neumann, S.; Nielsen, T.; “Distance to Integrate: Is the Hype of Plug and Play Integration Doing the Industry a Large Disservice?”; DistribuTECH Conference Proceedings, Tampa, FL, 2008

2. Reifer, D.; “Making the Software Business Case”, Addison-Wesley, 2002.

3. Rhodes, Randy, “CIM at PacificCorp”, presented at 2007 EMS users conference; www.emsusers.org/prevconf/2007/CIM%20at%20PacifiCorp%20v10.ppt

4. Hengst, D.; “MDI: A Solution for Outage Management,” IEEE PSC&E 2004, October, 2004.

5. Brown, D.; Robinson, G.; “Using a Common Infrastructure and Language to Integrate Applications at Florida Power & Light”, presented at DistribuTECH 2001.

6. Falcon, R.; Williams, G.; Boardman, E.; Kuntz, P.; Ulph, I.; “From GIS to CIM to DMS operations model and UI”, presented at DistribuTECH 2003.

7. Hervey M.; “LIPA Takes a Journey on the Integration Bus”, T&D World, Feb 1, 2008. http://tdworld.com/distribution_management_systems/lipa_takes_journey/

Page 22: EPRI IntroToCIMForIntegratingAppsAndSystemspdf
Page 23: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

3-1

3 THE COMMON INFORMATION MODEL This section covers in detail the definition of the Common Information Model, background material required to understand the model, and a high-level description of the components relevant to distribution.

3.1 History of the CIM

This section explains some of the relevant history of the CIM, including most importantly the roles of the different organizations that are part of the CIM community.

3.1.1 The EPRI Roots

The Common Information Model was originally created to solve the problem of vendor lock-in created by the Energy Management System (EMS) vendors who served the utility marketplace. This lock-in caused great difficulty for the utilities because it required large investments in time and money to purchase and support their Energy Management Systems. Upgrades were typically only possible by replacing the entire EMS with a “forklift” replacement. In this environment, once an EMS vendor was chosen the utility was forced to buy all applications from the same vendor and typically the applications were available in “all or nothing” packages.

It was believed that this lock-in was caused by the fact that each EMS vendor built their applications using technologies such as proprietary databases and inter-application messaging systems.

The CIM vision was to enable applications vendors to build and sell pieces of an EMS separately that could be interconnected together. This would allow vendors to compete on an application level and provide room for new vendors to emerge who could offer one or two EMS applications. It would also allow buyers to replace individual applications over time, removing the need for forklift replacements.

To achieve this vision, it was envisioned that applications would have to exchange information in a way that was not tied to a proprietary technology. And even more fundamentally, exchange data in way where the meaning of the data is universally understood by both parties.

The roots of the utility CIM go back to several projects sponsored by the Electric Power Research Institute (EPRI), the first being the Control Center Application Programming Interface (CCAPI) project. This project was an attempt to produce a set of common Application Programming Interfaces (APIs) that could be provided and used by vendors to communicate information between applications, potentially provided and used by different vendors.

Over time, while working on this problem, it became apparent that having a common definition of the data being passed between these applications was a critical component of making the vision work. This is where the concept of having a common information model was first determined to be a fundamental problem that needed to be solved. It was also becoming apparent that APIs are typically tied to specific technologies. Thus, it would be very difficult to get

Page 24: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

3-2

vendors and users who had made significant investments in specific technologies to agree upon a set of APIs. For these reasons, the focus shifted away from APIs and towards defining what is called an information model.

3.1.2 The IEC Standard

As the research progressed and started to produce a concrete information model, the next step was to promote its use among the vendors. Without vendors utilizing the information model, the vision could not be achieved. One way to do this was to take the information model and turn it into an international standard. Once a standard, it would become easier for vendors, users and consultants to promote the use of CIM by simply referencing the standard. This could be done in many forums, including Requests for Proposals (RFPs) issued to the vendors, articles in trade journals, and promotional literature by the vendors touting their compliance to the standard. Ultimately, it was perceived that vendors would build products using the standard and that the original goals of opening up the vendor application marketplace lock-in would be achieved.

For this reason, CIM efforts were started by the International Electrotechnical Commission (IEC). The technical committee chartered with turning the information model into a standard is known as Technical Committee 57 (TC 57): Power Systems Management and Associated Information Exchange. Initially, the following draft standards were submitted to the IEC:

• Common Information Model (CIM)

• Generic Interface Definition (GID)

• Common Power System Model (CPSM)

Over time, the committee initiated efforts for adding additional pieces to the information model, including electrical distribution system elements. Each sub-area that is to be addressed by the standard was assigned to small teams of interested parties called a working group. The current set of relevant working groups are

• WG 13 – Energy Management System Application Program Interface (EMS - API);

• WG 14 – System Interfaces for Distribution Management (SIDM);

• WG 16 – Deregulated Energy Market Communications; and

• WG 19 – Interoperability within TC 57 in the Long Term.

The working groups each produce a series of standards that describes in precise language the scope and definition of the standard. The standards documents are assigned a standard number by the IEC. Further breakdown and additions to the standard are handled by producing different documents within the one standard by assigning different “parts” to the standard which are also numbered.

There are now parts of the standard that not only cover the information model but also different implementations and uses of the information model. This includes ways to express the information model in files, messages, and interestingly enough, the definition of APIs, which was the original goal of the CCAPI project.

The two most relevant series of standards today are the IEC 61970 and IEC 61968 series.

Page 25: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

3-3

The IEC 61970-301 standard (part of the IEC 61970 series) describe the information model used by EMSs. This includes many of the core components such as wires, switches, transformers, and the connectivity of these devices. For this reason, IEC 61970-301 is said to contain to the “core” CIM.

The IEC 61968-11 standard (part of the IEC 61968 series) describes the extensions to the information model used in electrical distribution IT systems, such as Distribution Management Systems, Outage Management Systems, and Work Management Systems. The IEC 61968 standard is a derivative and references many of the components in the IEC 61970-301 core standard.

The IEC TC 57 working groups share a common web site at http://tc57.iec.ch. This web site is access-restricted to the members of the working groups.

A list of the relevant standards and the associated working groups are listed in Appendix C.

3.1.3 CIM Users Group

Because IEC TC 57 is focused on defining and revising the official standard and is formally part of the IEC, another forum was created to provide a venue for utilities, vendors, consultants, and integrators who use the CIM.

This forum is called the CIM Users Group (CIMug). The CIMug users group holds meetings and hosts a web site. The web site contains a repository of additional presentations, documents, files, and other artifacts to be shared among the user community. In addition, the CIMug also provides a channel to the standard organization for users to make suggestions for changes and extensions to the current standard.

The CIMug is a member group of the UCA (Utility Communications Architecture) International Users Group (UCAIug). The CIMug web site can be found at http://www.cimug.org, which redirects to http://cimug.ucaiug.org.

In addition, a common area for the relevant TC 57 working groups is also hosted on the UCAIug web site at http://iectc57.ucaiug.org. This web site is access-restricted to the members of the working groups

3.1.4 IEEE

The Institute of Electrical and Electronics Engineers (IEEE) Power and Energy Society (PES) contains groups that provide forums for power system engineers to discuss issues associated with the use of CIM. The IEEE also is a good source of references including material in the various journals, conferences, and proceedings where cases studies and research topics associated with the use of CIM can be found.

Some of the more relevant IEEE groups are below:

• Power System Analysis, Computing, and Economics (PSACE) Committee: http://ewh.ieee.org/cmte/psace/

o Computing and Analytical Methods (CAMS) Subcommittee: http://ewh.ieee.org/cmte/psace/CAMS.html

Page 26: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

3-4

Power System Modeling in CIM (PSM-CIM) Task Force

• Distribution System Analysis Subcommittee: http://ewh.ieee.org/soc/pes/dsacom/

3.1.5 EPRI’s Continued Role

EPRI continues to conduct research in areas where CIM needs additional definition or visibility such as the CIM for planning and CIM for dynamic modelling initiatives. EPRI also plays a role in introducing CIM into other research activities where it can be used in larger initiatives such as the IntelliGrid program.

EPRI coordinates the annual interoperability tests, which are tests of various vendor-provided software systems to validate that they can interchange information based upon a CIM definition. These tests are specific to a particular subset of CIM defined in what is called a profile. Currently, there is a profile and interoperability test that applies to transmission systems and EMS vendors (IEC 61970-452) and another interoperability test that applies to distribution systems and the associated software (IEC 61968-13).

3.2 What CIM Does

An information model is an abstract and formal representation of objects, their attributes, their associations to other objects, and the behavior and operations that can be performed on them. The modeled objects may be physical objects, such as devices on an electrical network, or they may themselves be abstract, such as the objects used in a customer information system.

The primary purpose of the information model concept is to formally describe a problem domain without constraining how that description is mapped to an actual implementation in software.

The information model is usually formally described in a particular, well-defined fashion—typically a rigid language or diagramming technology. In many cases the information model can be represented in different forms usually by a formal translation. In the case of the common information model used in electric utilities, the formal definition is done using the Unified Modeling Language (UML). This modeling will be further described later in this report.

3.3 What CIM Isn’t

There are some common misconceptions about the CIM. By stating what CIM doesn’t do, it can help create a better understanding of what it does do—and remove some false expectations.

First, CIM does not specify or define a physical data model or physical data store. It is a logical information model that is intended to be used in message definitions between separate systems. There is nothing preventing it from being adapted to be used as a definition for a physical database, but that is not its originally intended purpose; nor is there a strict definition of what a CIM-based physical database should look like. For this reason it is not accurate to describe a database schema as being CIM compliant.

Second, applications and systems don’t need to store their data natively in CIM format for them to be able to externally connect to other systems via CIM. In fact, in most cases it is probably better for the applications to have a database structure defined in a way that optimizes the use of the data for that application. In other words, a software system that is CIM based doesn’t have to

Page 27: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

3-5

have a database schema that uses the CIM—rather it should have interfaces that have messages defined based upon the CIM.

Third, extending the CIM information model is acceptable and even anticipated. The CIM covers the common information that is typically used in the information flows between systems in a generic electrical utility. There can and will be information that is unique to a particular utility and its specific software systems. Adding extensions to the information model is necessary to deal with these situations. There are ways to manage these extensions so that they don’t cause problems; and that topic will be covered in more detail later.

Fourth, currently there are no rigorous definitions of what makes an application or system CIM compliant or not. Vendors can easily claim some level of CIM compliance. Currently, the only certification of CIM compliance is the interoperability test sponsored by ERPI; however, these only cover testing of certain parts of the CIM in some very specific usage scenarios. There will be more details on this interoperability testing later in this report.

Fifth, CIM does not dictate platform technologies such as Windows, Linux, Java, C++, C#, Oracle, or SQL Server. In fact it is intentionally considered to be technology agnostic.

3.4 CIM Background

As mentioned earlier, CIM is built upon several foundation technologies. This section provides background material that covers the key elements of those technologies. It is not meant to be comprehensive material on any of these technologies, rather it provides enough background for a person to understand CIM. An interested reader should utilize the references listed at the end of this section for more in-depth coverage of these topics.

The following topics are necessary background for understanding the CIM:

• Unified Modeling Language (UML)

• eXtensible Markup Language (XML)

• Ontologies

• Resource Descriptor Format (RDF)

• Web Ontology Language (OWL)

3.4.1 The Unified Modeling Language (UML)

The Unified Modeling Language (UML) is a formal descriptive language that unifies several methodologies commonly used by software engineers to model systems. It is a language and not just a diagramming technique. It is used for defining, visualizing, building, and documenting software systems. UML is officially defined by the Object Management Group (OMG) and has been officially turned into an international standard currently defined as ISO/IEC 19501:2005 Information technology — Open Distributed Processing — Unified Modeling Language (UML) Version 1.4.2.

A UML diagram is a graphical representation of the model of a system. A complete model includes not only diagrams but also supporting written documents.

UML diagrams are used to provide three different views of a model:

Page 28: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

3-6

• Functional Requirements

• Static Structure

• Dynamic Behavior

UML models can be exchanged between UML tools and software systems and using the XML Metadata Interchange (XMI) file format. The metadata provides “data about data” (i.e., it describes characteristics and context of data in an information model). The metadata contains technical composition, content, and nature of an information entity, its relationships, and associations with other data.

3.4.1.1 UML Overview

UML officially defines the notation and syntax for thirteen different types of diagrams, categorized into three groups:

Structure Diagrams:

• Class Diagram

• Component Diagram

• Object Diagram

• Composite Structure Diagram

• Deployment Diagram

• Package Diagram

Behavior Diagrams:

• Activity Diagram

• Use Case Diagram

• State Machine Diagram

Interaction Diagrams:

• Sequence Diagrams

• Interaction Overview Diagram

• Communication Diagram

• Timing Diagram

Since we are interested in integrating systems using an information model, and not completely defining a software system, using the CIM only requires an understanding of the class diagram and the sequence diagram. For this reason, this report only provides details on class and sequence diagrams as they are used to perform integration using the CIM.

3.4.1.2 UML Class Diagrams

UML class diagrams provide a means to visually represent object hierarchies and relationships. This section provides a simple example of how class diagrams can be used to represent a model that is independent of the implementation platform.

Page 29: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

3-7

A class represents a specific type of object. A class hierarchy is a model of the system that represents every component as a separate class. As a general modeling principle, the class hierarchy should represent the real-world structure of the system.

3.4.1.2.1 Packages

UML class diagrams can be divided into separate groups of classes. These groups of classes are called packages. In the class diagram, they are diagramed as folders. Packages can be thought to be similar to folders or directories in a computer file system.

Figure 3-1 Example Class Diagram Containing Two Packages

Each package has a name that should be descriptive of the group of classes contained in the package. Just like the contents of folders in a file system, the classes in the folder should be related, and the different packages should be described in way that assists a reader to understand the groupings.

3.4.1.2.2 Classes

Classes are the specific types of things that are being modeled. When modeling a system, the task of dividing up the system into the different types of things that will be represented is a key first step. For instance, if you were building a model to be used by a Human Resources system, you might create classes for things like employees, managers, departments, and benefits. Getting the correct set of classes defined for a particular problem is challenging and usually takes an experienced modeler to get it “right”.

In UML class diagrams, classes are diagramed as boxes with the name of the class in the top of the box. Each class belongs to a specific package, much like a file is placed inside of a directory or folder.

One of the challenges in getting the right set of classes defined is anticipating future changes and new requirements. The goal is to design the classes so that new requirements don’t require changes to the classes already defined.

Page 30: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

3-8

3.4.1.2.3 Inheritance

One way to reduce the impact of change on the system is to make use of a concept called generalization or inheritance. Inheritance allows us to define very general classes and more specific classes, and define a relationship between the specific classes and general classes. The association between the more specific class and the more general class is called inheritance.

There is a good reason for doing this. Code, messages, and software operations can be defined to work with the most general class possible, and then if a new, more specific class that inherits from the general class is defined, all of the software that works on the general class will still work with the new class.

For example, if you had defined a general class called vehicle and built more specific classes for automobile and motorcycle, all of the code that works on vehicle would also work for an automobile and motorcycle, and more importantly would work on any new types of vehicles you add in the future.

In UML, inheritance is shown with an arrow that goes from a box associated with the more specific class to the box that represents the more general class. The generalization of classes can be extended for multiple levels, leading to a class diagram that has some very general classes and multiple levels of more specific classes.

Common terminology is to call the more specific classes “child classes” and the more general classes “parent classes”. When there are multiple levels of inheritance, child classes can also be parent classes of other child classes .

Sometimes the class diagram is called an “inheritance tree” because the classes will branch out from a common parent class or a few parent classes. The classes that have no children are often called “leaf classes” because they have no further branching and look like the leaves of the tree.

3.4.1.2.4 Attributes

Classes have properties or elements called attributes that are descriptive of that type of thing. Each class can have multiple instances of that class which are called objects. Each object instance has the same number and type of attributes, but with their own internal values.

In UML class diagrams, the bottom of each box associated with a specific class is a list of each attribute name and the associated data type of that attribute. It is important to understand that not only does the class have the attributes listed in the box for that class, but it also has all of the attributes associated with the classes that it inherits from.

For example, in a Human Resources system, the person class might have name and a gender as attributes; and an employee class could inherit from the person class and have an additional attribute: employee number. Inheriting from the employee class would be exempt and non-exempt classes, which would have an attribute of salary for the exempt class and an attribute of hourly rate for the non-exempt class.

Page 31: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

3-9

Figure 3-2 Example Class Diagram Containing Four Classes Showing Inheritance and Attributes

3.4.1.2.5 Associations

Classes also have relationships that describe how an object is related to or connected to other objects. These relationships are called associations in UML. Just like attributes, each object instance has the same number and type of associations, but with their own internal values.

There are three types of associations that can be represented. The first is called a simple association, the second is a specialized type of association called aggregation, and the third is called composition.

Simple associations show that the two classes have a connection; an aggregation association indicates a closer connection that means that the one object is made up of the other objects or is said to contain the associated objects. For example, the relationship between an owner and a motorcycle is a simple association, but the relationship between a motorcycle and its engine and handlebars is an aggregation because the parts could be removed and replaced. As an example of a composition association, the relationship between a building and its rooms is a composition because the building is not an assembly of rooms, rather it is composed of rooms.

Associations are drawn as lines between two boxes that represent the two related classes. Aggregations are drawn as a line with an open diamond on one end of the line. A composition is drawn as a line with a closed diamond on one end of the line.

Page 32: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

3-10

Associations have properties that represent the number of possible connections between that object and the related object. This property is called the multiplicity. The multiplicity is represented in a UML Class Diagram as a single number or a pair of numbers on each end of the line that represents the association. The numbers represent the minimum and maximum possible relationships. For example, a simple “1” says that the relationship from this object to the associated object must be one and only one. If the association is noted as (1..*) then it means that the relationship from this object to the associated object must be one or more. If it was (0..*) then it would mean that it may be zero or more.

It should be noted that the multiplicity is represented on both ends of an association and it can be different on each end. For instance, in our example a vehicle must have one and only one owner but an owner may have zero or more vehicles.

Figure 3-3 Example Class Diagram Showing Associations and Multiplicity

3.4.1.2.6 An Example Class Diagram

These fundamentals of the class diagram are essential in the understanding of the CIM as described in the following sections. For this reason, another example is appropriate.

Page 33: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

3-11

Figure 3-4 Example Class Diagram Showing a Vehicle Information Model

We are going to start with the vehicle example used earlier but more fully develop it. In this example, we start with a parent class called Vehicle. This Vehicle class has two simple associations: one to an Owner and one to a Manufacturer. In our example model, each Vehicle has one attribute: Model Name. The multiplicity of the association from the Vehicle class to the Owner class is “1” indicating that the vehicle can have one and only one owner.

The Owner class has one attribute: Name; and the multiplicity between the Owner class and the Vehicle class is “0..*” indicating that an owner can own zero or more vehicles.

The class Manufacturer has one attribute: Name (not shown in figure 3-4); and the multiplicity between the Manufacturer class and the Vehicle class is “1..*” because the manufacturer can make many different vehicles; however the multiplicity between the Vehicle class and the Manufacturer class is “1” because a vehicle can have one and only manufacturer.

In the example model, there are two child classes of the Vehicle class: Motorized and SelfPropelled. The Motorized class has one attribute: VIN#; and the SelfPropelled class has no additional attributes.

The Motorized class has one association to a class called Engine. This association type is an aggregation because the engine may be removed and replaced. In this model, the association to

Page 34: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

3-12

the Engine class has a multiplicity of “1” in both directions because the engine can be part of one and only one vehicle and a vehicle can have one and only engine. The Engine class has several attributes: Horsepower, Manufacturer, Serial number, and TorqueCurve.

The Engine class has two child classes: Electric and Combustion. The Electric class has attributes for Impedance, StartingCurrent and VoltageRating. The Combustion class has two attributes: Cylinders and Fuel Type.

This is a good example of how the attributes of classes should be defined. The attributes that are applicable to both electric and combustion engines such as Horsepower should be associated with the parent class. Those that are applicable only to a particular type of engine, such as the VoltageRating attribute of the Electric class, should be defined at the child class level.

The Motorized class has two child classes: Automobile and Motorcycle. Neither child class has any defined attributes, but they each have associations.

The Automobile class has an aggregation association to a Chassis class and a Steering Wheel class. The Motorcycle class has an aggregation association to a Frame class and a Handlebar class.

One might ask why the Automobile class does not also have associations to doors, wheels, and many other parts of an automobile? The answer is that the modeling should stop at the level in which it is expected that the software system doesn’t need it. If we didn’t do this, every model would be overly complex for the software that uses it. To paraphrase, our models should be just as complex as needed and no more.

If you can follow this example, you have an understanding of UML class diagrams sufficient to read and interpret all of the CIM class diagrams used later in this report. The only difference is that the class diagrams in the CIM model have many more classes, attributes, and associations.

3.4.1.3 UML Sequence Diagrams

UML sequence diagrams are used to model the flow of messages, events, and actions between the entities of a system. Time is represented vertically—showing the time sequence of interactions in the system. Displayed horizontally at the top of the diagram are the applications or entities in the system.

Through parallel vertical lines, a sequence diagram shows different processes or actors involved in the scenario. With horizontal arrows, the sequence diagram shows the information or messages exchanged among actors. The timing sequence flows from top to bottom.

Actors that are software processes are underlined. The horizontal arrows have a message name written above them. Solid arrows with filled in arrowheads represent synchronous messages, solid arrows with open arrowheads represent asynchronous messages. Dashed arrows with open arrowheads are response messages.

A message that originates from outside of the scenario diagram starts from a circle.

Page 35: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

3-13

Figure 3-5 Example Sequence Diagram

3.4.2 eXtensible Markup Language (XML)

The eXtensible Markup Language (XML) is a specification for creating markup languages, which are ways to encode both information and meta-information so that a clear, unambiguous communication of the information can be exchanged between computer applications and systems. HyperText Markup Language (HTML) and Standard Generalized Markup Language (SGML) are examples of well-known markup languages.

By adding constraints, XML can be used to create “application languages”. For the purposes of the CIM, XML can be used to define ontologies, including Resource Description Framework (RDF) and Web Ontology Language (OWL), which are described in the next sections.

Page 36: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

3-14

3.4.3 Ontology Definition

An ontology is a definition of concepts and their associations within a particular domain. A domain can be thought of as one field or area of specialty, much like the field of study in an academic environment, i.e., medicine, political science, or electrical engineering. The ontology represents the particular meanings of terms as they apply to that domain. For example the word “base” has many different meanings. An ontology in the domain of American baseball would model the "base: one of the canvas bags used in a baseball diamond" meaning of the word; an ontology in the domain of chemistry would model the "base: the opposite of an acid" meaning; and an ontology in the domain of electronics would model the “base: one of the regions of a bipolar junction transistor”.

The definition of a concept in an ontology starts with a definition of the classes, attributes, and associations that could be defined in a UML class diagram, but goes further and defines the following additional concepts:

• Restrictions: formal descriptions of what must be true in order for some assertion to be accepted as input;

• Rules: an if-then statement that describes the inferences that can be drawn from an assertion;

• Axioms: Assertions and rules that together comprise the overall theory in the domain; and

• Events: the changing of attributes or relations.

The additional constructs such as the rules and restrictions make the use of ontologies a richer and a more powerful tool for defining information models. As an example, a sub class of an Airplane class might be a SuperSonicAirplane class; and using a restriction, the maximum speed attribute can be restricted to be not less than 1,225.1 km/h.

Ontologies are commonly encoded using ontology languages. RDF and OWL described in the next two sections are both Ontology languages used in the CIM standard and by CIM software tools.

3.4.4 Resource Description Framework (RDF)

Resource Description Framework (RDF) is a method of defining information models that is specified by the World Wide Web Consortium (the W3C).

RDF is based upon the idea of making statements in a subject-predicate-object expression. Each expression is commonly called a “triple” in RDF terminology. The subject is defined by naming a resource, the object denotes traits or attributes associated with the subject, and the predicate expresses the relationship between the subject and the object.

The subject, or resource, in an RDF model is expressed as a Uniform Resource Identifier (URI). URIs are similar to the Uniform Resource Locators (URLs) used as web addresses but are more general because they are not limited to accessible data on the web.

The predicate and object are also technically URIs and so also are just identifiers.

The subject-predicate-object triplets takes the form of expressing syntactical constructs like “a person has a name” or “a car has four wheels”.

Page 37: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

3-15

RDF actually can be expressed in more than one syntax. There are two common file formats used for RDF.

The first is an XML format. This format is often called simply RDF because it was introduced as part of the W3C specifications defining RDF. However, it is important to note the XML format is not the same as the abstract RDF model itself. In this format each URI is tagged in XML style, and the file is given an .rdf extension rather than an .xml extension.

The second is the Notation 3 (or N3) as a non-XML format of RDF models designed to be easier to read and write. The CIM community also uses the Turtle format which is a minimal form of the N3 format. Turtle stands for Terse RDF Triple Language. The SPARQL Protocol (a query language for RDF) uses a derivative of the N3 and Turtle syntax.

RDF Schema (RDFS) files describe the classes, attributes, and relationships of an information model and typically use an .rdfs extension. RDF instance files describe object instances and typically use an .xml or .rdf extension. RDF incremental files describe changes to a set of object instances as described by an instance file, and typically use an .xml or .rdf extension.

Within an RDF or RDFS file, the following objects are used:

Schema file

• Class: Used in RDF Schema to define a new class

• Resource: Root class for all resources

• Property: Class of all properties

• Datatype: Identifies data types

• subClassOf: Specializes a class

• range: Limits the values of a property

• type: Identifies the class of an individual resource

• about: Describes an existing resource

• Description: Used for property/value pairs about a resource

Instance file

• ID: Identifies a new resource

• about: Describes an existing resource

• Description: Used for property/value pairs about a resource

Parts of the CIM standard define the way in which RDF files (RDF expressed as XML) are used for the exchange of CIM-based models. This is covered in more detail later.

3.4.5 Web Ontology Language (OWL)

Web Ontology Language (OWL) is a language based upon RDF that is capable of fully expressing ontologies, unlike UML Class Diagrams or standard RDF. Using OWL to express a full ontology is done by defining “individuals” and “property assertions”. Individuals are similar to the constructs of a class diagram, and the property assertions are based upon axioms. These describe the rules and restrictions in a formal syntax.

Page 38: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

3-16

OWL is used by some CIM tools to specify subsets of the full information model, called profiles. The CIM information model is defined in UML and commonly exchanged using XMI files. Profiles are commonly defined in OWL, instead of UML or XMI, because it allows axioms that place further restrictions on the model to be defined.

Officially, the CIM standard expresses profiles only in textual documents. However, the use of the English language as the definition syntax in these documents limits the precision and requires someone to interpret the language. It is most likely that the official standard will follow the lead of some of the CIM tools and express profiles in OWL in the future.

3.5 CIM Packages

The fundamental component of the CIM is the set of documents published by the IEC that describe the details of the information model. These documents are created from a UML model, which is available in electronic form from the CIMug that can be loaded into one of several different UML modeling tools. (The latest-and-greatest CIM model is kept in Enterprise Architect, which has a free viewer available.) The UML class diagrams are composed of packages that describe a unique sub-domain of the information model. Each package contains a set of classes along with their inheritance structure, their attributes, and their associations.

Figure 3-6 CIM Packages

We can first break down the relevant packages in the information model by looking at which IEC standard describes the packages. In this case, there are the packages that are part of the 61970 series of standards and those that are part of the 61968 series. Even though the 61968 series covers the distribution sub-domain, it is necessary to understand the 61970 transmission sub-domain first because the 61968 standard is based upon the 61970 standard.

Page 39: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

3-17

3.6 Relevant 61970 Packages

This section describes the relevant 61970 packages including Core, Topology, and Wires. The intended purpose is not to describe every class, attribute, and association, but rather to provide highlights of key concepts. This should enable the reader to read and explore relevant parts of the CIM on their own.

3.6.1 The Core Package

The Core package contains definitions of classes that are parent classes to many of the more specific classes in other packages of the CIM model, including classes defined in the 61970 and 61968 series of standard.

Figure 3-7 The CIM Core Package

3.6.1.1 IdentifiedObject

The Core package contains a class called IdentifiedObject. This class is very abstract and only contains attributes used to reference the object either by a user or in software. The attributes of IdentifiedObject include mRID, which is the master resource identifier that should be a globally

Page 40: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

3-18

unique identifier of objects; the mRID does not have to be human-readable. This identifier is generally intended to be used by software systems.

The attributes name, description, aliasName, and pathName are intended for providing identifiers that are human-readable. It is common for names of objects within a utility to not be unique due to historical naming conventions, the results of mergers and acquisitions, and the inability of other software systems to manage uniqueness. For these reasons, there are no constraints on these names requiring them to be unique.

3.6.1.2 PowerSystemResource

The PowerSystemResource class inherits from IdentifiedObject and provides another relatively abstract class used in the CIM. The PowerSystemResource class supports an association to a Company class. This relationship identifies the company that operates the resource.

3.6.1.3 Equipment and ConductingEquipment

The ConductingEquipment class inherits from an Equipment class which inherits from PowerSystemResource. This is the parent class for most of the physical equipment that are used to model the power system.

3.6.1.4 Substations, Bays and Voltage Levels

The Core package also contains three classes that are used to model the aggregations of equipment: Substation, Bay, and VoltageLevel classes. These three classes inherit from EquipmentContainer, and they can be used to construct a hierarchy of objects where equipment is contained in a voltage level, which is contained in a bay, which is contained in a substation.

It should be noted that this hierarchy is not required in the information model and is not very applicable to distribution equipment on circuits outside of a substation. However, this hierarchy may be required in certain application sub-domains such as transmission applications that exist in an EMS.

3.6.1.5 Terminal

Any object inheriting from the class of ConductingEquipment has a relationship to an object by the class of Terminal. This relationship has a multiplicity of 0...*, but typically it will be one or two terminals depending upon the specific class. This relationship is actually defined in the Core package but only utilized in the Topology package.

3.6.2 The Topology Package

The Topology package is used to define the interconnection between any class that inherits from ConductingEquipment. This is essentially the wiring diagram of the model.

Page 41: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

3-19

Figure 3-8 The CIM Topology Package

3.6.2.1 ConnectivityNode

The ConnectivityNode class has a relationship to the Terminal class. Each ConductingEquipment object has Terminals, which are then connected to ConnectivityNodes. The terminals can be thought of as being closely related to the conducting equipment, and the connectivity nodes are the glue that defines what equipment is connected to what other equipment.

3.6.2.2 TopologicalNode

The TopologicalNode class is used to define the objects that are all combined into a single bus when a bus-branch model is built using the device statuses (usually the nominal device statuses). This aggregation is done with the relationship between TopologicalNode and ConnectivityNode.

3.6.3 The Wires Package – Part 1 Lines

The Wires package is a relatively large package that can be logically broken down into three parts: lines, transformers, and switches. The lines part is has classes that define electrical lines, either AC or DC.

Page 42: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

3-20

Figure 3-9 The Wires Package - Lines

3.6.3.1 Conductor

Directly inheriting from ConductingEquipment is the Conductor class. This class contains the electrical attributes commonly associated with a line needed for steady state analysis, including the positive-sequence and zero-sequence resistance, reactance, conductance, and susceptance.

3.6.3.2 ACLineSegment and DCLineSegment

Inheriting from Conductor are the two classes: ACLineSegment and DCLineSegment. Multiple ACLineSegments are aggregated into a single ACLine object.

3.6.3.3 ConductorType, WireArrangement, and WireTypes

Additional information about each line segment is described using associations to a class called ConductorType, which has relationships to WireArrangement and WireType.

Page 43: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

3-21

3.6.4 The Wires Package – Part 2 Transformers

Transformers are also part of the Wires package. The transformer model is broken down into several parts: the transformer itself, the windings, and the tap changer.

Figure 3-10 The Wires Package – Transformers

3.6.4.1 PowerTransformer, TransformerWindings, and TapChanger

The PowerTransformer class inherits from Equipment (not ConductingEquipment) and has associations to the TransformerWinding class. The majority of the electrical characteristics associated with the transformer are actually associated with the associated TransformerWinding objects.

An association from the TransformerWinding class to the TapChanger class is used when the transformer has a tap changer. The TapChanger class has as attributes for things like the tap steps and nominal setting. The TapChanger class inherits from the PowerSystemResource class instead of the Equipment class, so it has few inherited attributes and associations.

3.6.5 The Wires Package – Part 3 Switches

The third major subsection of the Wires package contains switches. This is the section where you will find the breakers, fuses, and other devices that can be open or closed.

Page 44: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

3-22

Figure 3-11 The Wires Package – Switch

3.6.5.1 Switch

The Switch class inherits from ConductingEquipment. Specific switch attributes include a flag to indicate if a device is nominally open. It also has an association to the CompositeSwitch class, which is used to define a group of switches that operate in a coordinated manner such as a “throwover” switch, where one switch closes when the other opens.

3.6.5.2 Switch Child Classes

There are quite a few child classes of Switch:

• Fuse

• Disconnector

• Jumper

• GroundDisconnector

• ProtectedSwitch

The ProtectedSwitch class has two child classes of its own: LoadBreakSwitch and Breaker.

Page 45: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

3-23

3.7 Relevant 61968 Packages

This section describes the relevant 61968 packages: Assets, Operations, and Work. It also describes the distribution software systems that are most relevant to each package.

3.7.1 Assets Package

The Assets package defines the attributes and relationships that are commonly part of an asset management program.

Figure 3-12 The Linear Assets Package

The Asset class includes a large number of attributes that include manufacturer, serial numbers, manufacture date, purchase date, etc. The Asset class contains an association to the

Page 46: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

3-24

PowerSystemResource class, so that any object that can be defined as part of a power system model can be linked to the asset model. The multiplicity of this relationship allows for multiple Asset objects to be associated with a single PowerSystemResource and multiple PowerSystemResource objects can be associated with a single Asset. Also significant is the fact that the Asset class has an association with the Document class, which allows it to be related to many different types of documents, which support linkages with outages, failures, procedures, maintenance activities, and other documents defined in the 61968 model.

3.7.2 Operations Package

The Operations package contains objects typically managed by outage management and distribution management systems. This includes outages, switching documents, and safety documents.

Figure 3-13 The Operations Package

3.7.2.1 OutageRecord

The OutageRecord class is used to record an outage that occurs on the distribution power system. The OutageRecord can record the start and end date and time of the outage, the type of outage, the type of damage, and the action taken to restore the outage. Since OutageRecord inherits from

Page 47: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

3-25

the Document class, it also contains an association to any PowerSystemResource object, which is necessary to record the location of the outage electrically.

3.7.2.2 SwitchingSchedule and ScheduleStep

The SwitchingSchedule class is used to define a planned or current sequence of switching steps that are to be performed on the distribution power system. The steps in the switching schedule are managed by an association between the SwitchingSchedule class and the ScheduleStep class. For each step, there is a date and time attribute that records the time the step was instructed and the time the step was completed. Each step has an association to a PowerSystemResource class so that the step can record the device that was operated.

3.7.3 Work Package

The Work Package contains objects commonly used in a work and asset management software. This includes objects for design, compatible units, work initiation, work closing, and work schedules.

Figure 3-14 The Work Package

3.7.3.1 Work and Work Task

The Work class is the fundamental piece of work managed by a work management system. The Work class has an association to one or more objects of the WorkTask class. Associated with

Page 48: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

3-26

each WorkTask object are the related Design and WorkSchedule instances that contain attributes describing the design type, the cost of the design, the quantity, and material used.

3.7.3.2 Design and DesignLocation

The Design class inherits from the Document class and contains attributes to track the design type and status. The Design class has an association to the DesignLocation class. Each piece of work has an association to a design.

3.7.3.3 Other Work Relationships

The WorkTask class has a large number of associations defined. Some of these are listed below:

• WorkTask to MaterialItem

• WorkTask to LaborItem

• WorkTask to EquipmentItem

• WorkTask to OverheadCost

3.8 CIM Profiles

3.8.1 Definition of a Profile

A profile is defined as the set of classes, attributes, and relationships that are a subset of the classes, attributes, and relationships found in another schema. Thus, a given profile is a subset of a parent schema. Profiles cannot “extend” a schema or add any classes, attributes, or relationships. Profiles can place restrictions on the cardinality of a relationship. A profile is usually given a name and has an assigned namespace. Profiles are used to define contextual or domain models. Profiles can be realized in a variety of forms, including to RDFS, XML Schema, text documents, and HTML.

3.8.2 CPSM Profile

The Common Power System Model (CPSM) profile defines the subset of classes, attributes, and associations necessary to execute the EMS applications of power flow and state estimation. The North American Electric Reliability Corporation (NERC) Data Exchange Working Group (DEWG) produced the original definition, which has been extended by the IEC. This profile is commonly used to exchange transmission network models between ISO/RTOs and the participating member utilities. The CPSM profile is widely used because of the NERC requirements for its use; and for this reason, it is sometimes called the NERC profile.

The CPSM profile is defined by the IEC standard 61970-452. The stated purpose of the standard is the following:

• To improve that accuracy of power system models used in critical systems, particularly the representation of parts of the network outside the primary domain of the system in question.

• To achieve consistency among the models used by the various systems that play a role in operating or planning the interconnection.

• To reduce the overall cost of maintaining critical models used in operating or planning an interconnection.

Page 49: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

3-27

The CPSM profile is tested as part of an annual interoperability test sponsored by EPRI. At this interoperability test, sample models in CPSM format are exchanged between all of the major EMS vendors; and power flow and state estimator results are compared to validate the models have been correctly interpreted by the EMS products.

The results of the tests performed in 2006 can be found in “Interoperability Test #9 of the Generic Interface Definition (GID) Standards and the Common Information Model (CIM)” at http://mydocs.epri.com/docs/public/000000000001012494.pdf. The most recent test reports can always be found by searching the EPRI site.

3.8.3 Planning Profile

A new model profile is in the process of being defined within the EPRI-sponsored CIM for Planning activity for the purposes of defining a model for performing transmission planning power flow and other related transmission planning applications.

Planning models make use of the TopologyNode class to define a bus-based model that is a topological reduction of the node-breaker model. The use cases that the planning profile is targeted to address are the exchange information between an EMS and a planning system of the following information:

• Load Throw-Over

• Contingency Specifications

• Remedial Action Schemes

• Load Forecast Data

• Generation Scheduling Data

• Branch Limits

• Handling Model Equivalents

The process appears to be converging on a solution that enables the exchange of planning models in much the same way as operation models are exchanged using the CPSM profile.

3.8.4 Dynamics Profile

Another new model profile is in the process of being defined within the EPRI-sponsored CIM for Dynamic Modeling activity for the purposes of defining a model for performing dynamic stability analysis. The dynamics models will require an additional modeling package that associates back to the static model, which is similar to how the dynamic parameters are handled in the vendor-offered dynamic stability packages.

3.8.5 CDPSM Profile

Of most interest to the audience of this report is the Common Distribution Power System Model (CDPSM) profile, which defines the subset of classes, attributes, and associations necessary to execute several DMS applications. The CDPSM profile is very similar and modeled after the CPSM profile.

The CDPSM profile is defined in the IEC standard document 61968-13.

Page 50: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

3-28

This profile has also been tested in interoperability tests of DMS applications sponsored by EPRI. The results of the tests performed in 2006 can be found in “Interoperability Test #9 of the Generic Interface Definition (GID) Standards and the Common Information Model (CIM)” at http://mydocs.epri.com/docs/public/000000000001012494.pdf. The most recent test reports can always be found by searching the EPRI site.

3.9 Generic Interface Definition (GID)

The Generic Interface Definition (GID) is a subset of the IEC TC 57 standards work that involves defining application interfaces based upon the CIM. The GID is defined in the IEC 61970-4xx series of standards. In IEC terminology, these are called the Component Interface Specification (CIS). The following is a list of the relevant standards:

• IEC 61970-401 Component interface specification framework

• IEC 61970-402 Common services

• IEC 61970-403 Generic data access

• IEC 61970-404 High speed data access

• IEC 61970-405 Generic eventing and subscription

• IEC 61970-406 Program invocation

• IEC 61970-407 Time series data access

The GIDs fill the space of providing APIs for applications to communicate without the use of integration software, essentially a direct connection between two applications rather than through an intermediary piece of software. This type of connection is desirable for scenarios where general purpose integration software is not being used and/or where the overhead of integration software is undesirable. It also gets closer to achieving the objective of plug-and-play integration. However, some of the configurability and adaptability to different business processes is not present when using GID-based adaptors.

Within the EMS marketplace, there are vendors who offer GID-based connectors that can be connected directly to other applications. These GID based connections are also tested as part of the interoperability testing sponsored by EPRI.

The GID definitions do not specifically include transport layer definitions. The existing implementations today typically leverage a set of standards from the OPC foundation (open connectivity via open standards). The OPC foundation standards provide a well-understood approach for transport layer communication that is widely used in many automation applications (manufacturing, process control, etc.)

The GID standard is based on existing open standards for both energy and industrial uses defined in the following standards:

• Object Management Group (OMG): Data Access for Industrial Systems, Data Access Facility.

Page 51: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

3-29

• OLE for Process Control (OPC): Data Access, Historical Data Access, Alarms & Events.

The OPC Foundation (http://www.opcfoundation.org) developed application programming interfaces to enable plug and play of applications and drivers called OLE for Process Control (OPC). The OPC community is dominant in the industrial automation and process control industries providing connectivity to hundreds of automation applications.

OPC started as a standard that was based upon Windows specific technology called OLE, but today it is available as a cross platform technology including web services and SOA.

However, due to the process control nature of the OPC standards, adoption by non-control room vendors in the distribution space are less likely to build OPC based integration adaptors because their preference will be towards more horizontal integration (information bus) technologies.

For this reason, the most likely integration solutions to be deployed in distribution will be mixed with GID based integration for the control room applications connected to horizontal dominant technologies such as Service Oriented Architecture (SOA) and Enterprise Service Bus (ESB) that will be used for enterprise wide integration. It is technically feasible to bridge the GID adaptors to the enterprise integration platforms, preventing any silos from being formed. The SOA and ESB technologies are explained in more detail later in this report.

3.10 Further Reading

1. D. Becker, H. Falk, J. Gillerman, S. Mauser, R. Podmore, L. Schneberger, “Standards Based Approach Integrates Utility Applications”, IEEE Computer Applications in Power, Vol. 13, No. 4 10/2000, pp 13 – 20

2. Lee, S.T.; “The EPRI common information model for operation and planning”, Power Engineering Society Summer Meeting, 1999. IEEE, Volume 2, 18-22 July 1999 Page(s):866 - 871 vol.2

3. Berry, T.; “Standards for energy management system application program interfaces; Electric Utility Deregulation and Restructuring and Power Technologies, 2000. Proceedings. DRPT 2000. International Conference on 4-7 April 2000 Page(s):156 – 161

4. D. Brown, G. Robinson, “Using a Common Infrastructure and Language to Integrate Applications at Florida Power & Light”, DistribuTECH 2001.

5. Mauser, S.F.; Gillerman, J.; Nordell, D.; ”Utility information integration-vision, benefits, strategies, and status”, System Sciences, 2000. Proceedings of the 33rd Annual Hawaii International Conference on, Jan 4-7 2000 Page(s):6 pp.

6. Berry, T.; Shephard, B., “Information exchange standards for power system monitoring and control”, Power System Management and Control, 2002. Fifth International Conference on (Conf. Publ. No. 488) 17-19 April 2002 Page(s):136 – 141

7. Britton, J.P.; deVos, A.N., “CIM-based standards and CIM evolution”, Power Systems, IEEE Transactions on Volume 20, Issue 2, May 2005 Page(s):758 – 764.

8. Sinan Si Alhir, “UML in a Nutshell, A Desktop Quick Reference”, O’Reilly: 2005.

9. Passin, Thomas B., “Explorer's Guide to the Semantic Web”, Manning Publications: 2004.

Page 52: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

3-30

10. Xiaofeng Wang; Van Ausdall, S.; “Representing Business Data Semantics In CIM using UML”, Power Systems Conference and Exposition, 2006. PSCE '06. 2006 IEEE PES, Oct. 29 2006-Nov. 1 2006 Page(s):480 – 486

11. de Vos, A.; Widergren, S.E.; Zhu, J.; XML for CIM model exchange. Power Industry Computer Applications, 2001. PICA 2001. Innovative Computing for Power - Electric Energy Meets the Market. 22nd IEEE Power Engineering Society International Conference on 20-24 May 2001 Page(s):31 – 37

12. Powers, Shelley, “Practical RDF”, O'Reilly: 2003.

13. Neumann, S.; “CIM extensions for electrical distribution” Power Engineering Society Winter Meeting, 2001. IEEE, Volume 2, 28 Jan.-1 Feb. 2001 Page(s):904 - 907 vol.2

14. Xiaofeng Wang; Schulz, N.N.; Neumann, S.; “CIM extensions to electrical distribution and CIM XML for the IEEE radial test feeders”, Power Systems, IEEE Transactions on Volume 18, Issue 3, Aug. 2003 Page(s):1021 – 1028

15. McMorran, Alan; “An Introduction to IEC 61970-301 & 61968-11: The Common Information Model”, http://cimphony.org/cimphony/cim-intro.pdf

16. The CIM Users Group, “Introduction to the CIM Users Group”, presented at the 2006 EMS users conference; http://www.emsusers.org/prevconf/2006/CD2/Introduction%20to%20the%20CIM%20Users%20Group.pdf

17. Mackiewicz, Ralph, “Applying the Generic Interface Definition (GID) in a Web Services Environment”, presented at the 2005 EMS users conference; http://www.emsusers.org/prevconf/2005/EMS%202005%20GID%20-%20Web%20Service.pdf

Page 53: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

4-1

4 INTEGRATION PROCESS This section describes a typical process used for integration. The process is not unique, and almost every integration activity will be slightly different; however, the basic steps will be similar.

As a brief introduction, the steps of the process are as follows:

• Build the Use Cases

• Create the Sequence Diagrams

• Build the Domain Model

• Design the Messages

• Design the Interfaces

• Construct the Interfaces

• Manage the Artifacts

4.1 Use Case Overview

A very popular approach to doing software engineering is to use a methodology based upon the development of “use cases”. For this reason, use case diagrams are one of the standard diagrams that are part of the UML language. In the simplest terms, a use case describes a typical scenario of use of the software to be designed and constructed.

Typically, a CIM based integration effort will involve multiple systems each with multiple information flows into and out of each system. A way to approach the myriad of requirements that will ultimately come out of the requirements analysis process is to construct a use case overview diagram as part of the use case development process. Use Case Overview diagrams paint a broad picture of the system’s context. Use Case Overview Diagrams are one of the UML standard diagrams.

Page 54: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

4-2

Figure 4-1 A Use Case Overview Diagram from the IEC 61968 Standard

Initially, when the IEC 61970 was being developed, use cases were not part of the methodology used in building the standard information model. Today, as part of the standards process, each new addition to the information model is submitted with a use case. Since the distribution extensions were started later, more use cases exist for this domain, which relate to many of the objects in the IEC 61968 information model.

Because of this, in a CIM-based integration project, especially one in the distribution area, you don’t need to start from scratch in building your use cases and use case overview diagram. You can leverage use cases from other utilities that have used the CIM information model; and where they are available, you can leverage ones from the standards community.

When beginning the analysis, it is important to take a step back and attempt to build a high level list or inventory of the information flows that might be expected as part of the integration process. Once the list is built, the details of the use cases can be filled in, and the use case overview can be built in conjunction with the detailed analysis.

Page 55: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

4-3

4.2 Use Case Development

A complete use case consists of both a use case diagram and a document or table that describes the use case in more detail. Some practitioners find that the diagram itself is not strictly necessary, and the diagramming step can be omitted as long as a detailed use case document is produced.

4.2.1.1 Develop a Requirements Document Along with the Use Cases

Use cases are not the complete story when gathering requirements for software integration—but they are the best place to start. As the use cases are being developed, a complete set of requirements analysis documents should be produced in conjunction with the use cases.

There should not be a requirements document for each use case, but the use cases need to be reviewed and factored into the actual software requirements. One use case step may map to multiple requirements, and one requirement may meet the needs of multiple use case steps.

In all but the simplest cases, it is usually necessary to build a “database” that maps each use case step to the associated requirement(s). By doing this, it is possible to verify that complete coverage of all of the use cases has been met. In smaller projects, this database could be a simple spreadsheet; in larger projects, it could be a database or even an off-the-shelf tool specifically designed to track requirements to use cases.

Many software development organizations may have standards for what a software requirements document should contain, but if a standard doesn’t exist, the IEEE standard 830-1998 is a good place to start. This standard was developed before the adoption of use cases became prevalent, so explicit references to use cases are not described in the document. However, the standard does contain a section called “stimulus/response” that is functionally equivalent to a use case, so the standard can easily be extended to be compatible with use cases.

4.2.1.2 Use Case Definition

There are three standard parts of a use case:

1. A description of the actors involved. An actor is a type or class of user involved. Who are the actors involved in an integration? It is perfectly acceptable for actors to be other software systems rather than actual end users. In most integration use cases, this will be the case.

2. A definition of the software system being used. This is not a system that might be defined as an actor, but it is the actual system that the requirements are being gathered for. In the software integration case, this is going to be the integration software, sometimes called the Integration Layer (IL).

3. The goal or objective is what the actor(s) achieves using the system. In other words, the goal should be something that the actor needs, not just a task the actor performs.

To summarize the fundamentals, the two key questions to ask are (1) who will be using the system and (2) what objective will they achieve by using it.

Page 56: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

4-4

4.2.1.3 Use Case Details

Once the high-level definitions are complete, the more detailed information in the use case can be filled in. The detailed information contains the following information:

• Preconditions – The expected conditions that must exist for the use case to begin.

• Success End Condition – The expected end state that occurs upon successful completion of the use case.

• Failed End Condition – The expected end state that occurs when the use case fails.

• Trigger – The event or stimulus that initiates the steps in the use case.

• Steps necessary to achieve the Success End Condition – The step-by-step process that must be taken to achieve the end objective. The steps are usually numbered sequentially as “1, 2, 3, …”

• Extension steps – Extension steps are referenced to the step numbers in the success scenario that occur when something fails. It is best to look at each step and review if there are possible extensions to that step that might be due to alternate paths and failures. The steps are usually numbered with “a,b,c,…” suffixes to the main scenario steps where the extension occurs.

By analyzing and filling each of these sections in a use case template, the analyst is forced to consider all of the critical aspects of the system that are needed to build a robust system. Thoughtful and detailed analysis can help avoid missed requirements that cause unforeseen problems later. For instance, if you were not following a use case based process, it is easy for users to overlook scenarios based upon failures—like what happens when an actor isn’t authorized, or what happens when the system doesn’t accept a request because it is not valid.

4.3 Sequence Diagram Creation

A sequence diagram is a form of a UML diagram that shows how processes and actors interact between each other, clearly indicating the order and timing of the interactions. The timing and interactions between systems and the integration layer is a critical detail that must be specified. For this reason, sequence diagrams are very valuable when doing integration projects. Similar to how use cases form the cornerstone of the requirements analysis process, sequence diagrams can form the cornerstone of the detailed design process.

Page 57: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

4-5

Figure 4-2 An Example Sequence Diagram

The sequence diagrams should be relatively easy to construct based upon the use cases, and they are the first place design decisions are applied. For instance, as part of the design process, it might be determined that one system needs to provide the same or similar information to three different systems, yet one consumer needs the information daily and the other two need the information hourly. Instead of having two sequence diagrams—one that shows a daily sequence and one that shows the hourly sequence—you would have one sequence diagram showing the hourly sequence with two consumers and with the system that needs the information daily only picking up the same information up once per day.

In the example sequence diagram shown in Figure 4-2, the actors involved include the Customer Information System (CIS), Work Management System (WMS), the Metering System (MS), the Meter Data Management System (MDMS), and Meter Asset Management (MAM). The actors are shown across the top of the diagram.

The use case being documented is one that involves removing an old meter and replacing it with a new one. The sequence of time goes from the top of the diagram to the bottom, and arrows between the different actors show the interaction between the actors, which could be software systems, physical systems, or users. When the interaction is between two software systems, the message verb is shown capitalized and the message noun is shown inside of the parentheses.

Page 58: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

4-6

The use case begins with a meter service request being generated in the CIS that is passed to the WMS. The WMS will schedule the work; and once the work is performed, the old meter will be read and removed, and the new meter will be installed, configured, and read.

Completion of the work on the metering system will result in the WMS being updated and the CIS being updated. In the use case, the CIS will then update the MAM, and the WMS will update the MDMS.

4.4 Domain Modeling

For each message identified in the sequence diagrams, the message content needs to be defined. If we were not using a CIM-based approach, we would most likely design our message content to be based upon one of the connecting system’s information models. We would probably select one system as a point of reference and map the other one to that.

Figure 4-3 A Diagram Representing the Domain Modeling and Message Construction Process

In the CIM-based approach, the process involves mapping the classes, attributes, and associations that can be produced by the producing system to the CIM model. Then the same thing is done for the receiving system(s). This mapping is best represented as a profile. The process is called “domain modeling” or “context modeling” because what is being done is the

Page 59: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

4-7

creation of a definition of the needed content from the information model within a particular context or domain.

When doing domain modeling, care must be taken to ensure that the definitions are really the same. Things that are named the same might not actually be the same. Conversely, things with very different names might actually be the same thing. Within the CIM, each attribute, association, and class has a detailed descriptive definition in the model that can be reviewed. The owners of each system should ask themselves: “Does the definition in the CIM model describe what I am proposing to use in the message to/from my system?” If it does, then the mapping is appropriate.

So what happens when it isn’t there? In cases where an equivalent item cannot be found in the CIM, an extension should be added to the base CIM(s) defined in the Enterprise Information Model (EIM). Note that in profiles and domain models, extensions are not allowed—extensions are made in the information model layer.

A word of caution is appropriate at this point. It is easy to do a quick look and conclude what you are looking for is not in the CIM. However, people who have familiarity with the CIM and experience using CIM can often find things in the CIM that a novice might not be able to find. For instance, the high-side voltage rating of a transformer might be needed in a message. In the sending system, it is a simple attribute of the transformer. Looking at the CIM Transformer class, there is no high-side voltage rating, so it might be concluded that it doesn’t exist and the CIM must be extended. However, in the CIM, the voltage rating is actually an attribute of the TransformerWinding class. So, you have to know that to find the high-side voltage rating, you have to follow the association from transformer to transformer winding and then use the voltage rating (ratedU) attribute.

Once the needed extensions are made at the EIM layer, then the contextual mapping from the CIM extensions can be made, just as the mappings from the core CIM are made.

4.5 Message Design

Designing the actual messages used by the integration layer requires taking the domain model defined earlier and constructing an actual data payload for the message. The “payload” is the terminology for the actual data being passed from one system to another. Generally, a payload can be reused in several messages depending on what is being done with the data. For instance, you can use the same payload in a message that is going to create an object as one that changes an object. In the IEC 61968 standard, a predefined set of message verbs has been defined that describe the actions that can be performed. The following is an example of the verbs defined in IEC 61968. The verbs are different depending on the pattern used for the messages (i.e., Request/Reply vs. Publish/Subscribe).

Request/Reply:

• CREATE

• CHANGE

• CANCEL

• CLOSE

Page 60: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

4-8

• DELETE

• GET

• SHOW

• REPLY

Publish/Subscribe:

• SUBSCRIBE

• UNSUBSCRIBE

• CREATED

• CHANGED

• CANCELED

• CLOSED

• DELETED

Figure 4-4 Using CIMTool: One Possible Way to Design a Message Payload Using a Domain Model

Shared among all messages should be a standardized structure for the “message envelope”. The envelope is essentially a holder for the verb, the noun, the data, and a header. IEC 61968 has also defined a standardized envelope for use with CIM-based integration, and this envelope should be used for all messages.

Page 61: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

4-9

Figure 4-5 An Example Showing the Message Envelope along with the Verb and Payload Contents

In summary, constructing a message involves (1) defining the payload based upon a profile specified against a domain model; (2) defining the appropriate verb associated with the message type; and (3) putting the payload and verb into the message envelope.

4.6 Interface Design

Once the messages have been designed, the actual interface adaptors need to be built. Typically, there would be one adaptor built for each system that is connected to the integration layer. To design the adaptors, the requirements analysis documentation, sequence diagrams, and message designs need to be studied so that the adaptor design can be produced. It is important to note that the adaptor design will be specific to the actual integration technology used.

Many of the integration technologies in use today are highly configurable, and the design process is a matter of selecting a design pattern and documenting the configuration parameters. Even with these configurable tools, certain designs will require some code to be developed. This is especially true when parsing RDF because while XML is a message and file format the integration tools are well versed in, none of the integration tools at this time natively understand RDF. There are open source toolkits that are designed for use with RDF and the RDF query

Page 62: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

4-10

language SPARQL. This is the recommended approach when dealing with RDF that can’t be parsed by the integration tools.

Additional detail on the available integration technologies and design patterns is given in the Section 5 of this report.

4.7 Interface Construction

Constructing the interfaces based upon the design should be relatively straight forward if the design documents are done properly. The major steps in the task are as follows:

1. Configure the integration tool based upon the parameters and design patterns documented in the design and sequence diagram.

2. Develop the processes that perform the logic documented. (This may either be in the integration tool environment or in a traditional language.)

3. Construct the components that perform the validation, transformation, and translations.

4. Put the interface code, message definitions, and any files associated with the interface in a source code repository.

5. Perform unit testing, debugging, and resolution.

Page 63: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

4-11

Figure 4-6 A Typical Integration Development Environment that could be Used to Construct an Integration Adaptor

4.8 Artifact Management

If the process described here is followed, quite a few artifacts will be produced that could be considered in their entirety the blueprint for the actual interfaces. Because the systems get enhanced and upgraded—and business processes change—continued maintenance of the integration is critical. For this reason, all of the artifacts produced should be placed in a repository for future reference. Ideally, this repository should have some sort of version management so that a history of all the changes is maintained as the integration evolves. Examples of repository technology that could be used includes the following:

• Microsoft SharePoint

• Open source Wiki

• Commercial Wiki

• Document management system

• Source management system

Page 64: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

4-12

The following is a list of the artifacts that should be placed in a repository and maintained as the system evolves:

• List of connected systems (and versions supported)

• Requirements-tracking database

• Base CIM model

• CIM extensions

• Domain model profiles

• Analysis documents

• Use cases

• Sequence diagrams

• Message definitions

• Design documents

4.9 Managing CIM Extensions

The IEC CIM is used as an enterprise information model to provide a basis for design artifacts. As mentioned in Section 3, the CIM covers the common information that is typically used in the information flows between systems in a generic utility. There can and will be information that is unique to a particular utility and its specific software systems, which will require extension to the information model. The CIM model extension is required and acceptable in such a situation. It is also important to recognize that the CIM itself is subject to change, where new standard CIM versions are typically augmentations of previous versions. The CIM extensions need to be managed efficiently to avoid future complications resulting because of various versions of the CIM extensions. There are many approaches to extending the CIM, and this section gives an overview of a flexible approach that can be realized using a combination of freely available and low cost tools.

During the process of domain modeling, interface message content is identified. This process requires mapping of classes, attributes, and associations of source and target systems. When an appropriate equivalent CIM class, attribute, or association is not available in the CIM information model, the designer extends the CIM model by adding a new attribute, class , or association. (Refer to Figure 4-3.)

The model can be extended for following reasons:

• vendor-specific and or proprietary features that require model extensions, and

• extensions required for local needs that are company or project specific. (Extensions that are widely useful are good candidates for formal adoption in a future CIM version.)

4.9.1 Extension Management

Until now, CIM designers have used several different techniques to manage the CIM extensions:

• Maintaining a single logical model that includes extensions and is manually edited as needed to add extensions

• Placing extensions involving only new classes in a separate package

Page 65: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

4-13

• Adding new classes (containing extension attributes) with 0|1:1 association to existing class

• Tagging of extension elements

• Using multiple inheritance, where a parent class identifies those classes that are extensions

• Tracking extensions in a database or spreadsheet

• Using an extension schema

Out of all the techniques listed above, using an extension schema is a recommended approach because it does not require a single logical model, tagging of the extension elements, or use of multiple inheritance. The extension schema method allows the designer to define more than one extension schema for the model, where each extension schema could have its own namespace. The freely-available open source CIMTool (http://www.cimtool.org/) can merge the CIM standard schema and extension schema automatically during the profile definition. This approach also eliminates the need of re-entering or re-merging the extensions when a new official CIM version is released; it also provides end-to-end traceability. Moreover, if extensions are defined as “optional”, then they do not affect the existing implementation.

The example below gives an overview of adding an extension attribute and class using the extension schema method.

4.9.2 Extension Attribute

As an example, in order to add a new attribute ‘y’ to an existing CIM class, the designer first adds a class of interest—referred as a shadow class—from the base CIM model to an extension model. In this example, the class of interest is the Switch class. (The full definition of the Switch class remains in the base information model.) The designer then adds a new extension attribute ‘y’ using CIM naming and type convention to the class of interest, which provides a link to the base model.

Figure 4-7 An Extension Attribute

4.9.3 Extension Class

As an example of adding an entire new class, the designer adds the extension class to the model in the extension schema. In this example, the extension class SwitchX is defined with its attributes in the schema. The extension class name must not conflict with existing CIM class names. The pre-existing CIM class Switch is added to the extension model as a parent for the

Page 66: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

4-14

extension class. Just as in the extension attribute example earlier, the CIM class Switch is referred as a shadow class, which provides a linkage to the base CIM model.

Figure 4-8 An Extension Class

The above process extended base CIM Switch class by adding an extension attribute ‘y’. It also added an extension class SwitchX with an attribute ‘x’. The extension class SwitchX is a subclass of CIM class Switch.

Figure 4-9 The Extension Model

Figure 4-10 provides an overview of relationship between the standard CIM model and an extension schema model. The extension schema is related to CIM model via the shadow class Switch.

Page 67: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

4-15

Figure 4-10 The Extension Schema Showing the Shadow Class

4.9.4 Impact of New CIM Versions

Periodically, the IEC will release new CIM versions based on input from the standards committee, vendors, and utilities. The extension model created using an extension schema should be compatible with the new CIM versions. There is a possibility that new CIM model can impact the extension models, such as when an extension model was directly adopted or provided a basis for an extension to the standard CIM model.

4.9.5 Merging Models

The extension schema approach enables designers to merge one or more extensions models together or with base model logically or physically. The shadow classes in the extension model provide the logical linkage points between the base and extension models. The merged models are in XMI format before and after the merge, and there are two options to merge the models:

• Logical Merge – The logical merging is done using the open-source CIMTool, where the merging of the models occurs automatically when an extension model is loaded.

• Physical Merge – The extensions are merged with a base model to generate a single model file that is a composite of the base and extensions.

Once the models are merged in XMI format, the profiles are created using CIMTool. The profiles are used to define the content of information exchanges by identifying a formal subset of the logical information model and its extensions with added constraints.

Page 68: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

4-16

4.10 Further Reading

1. Robinson, G.; Zhou, M.J.; “Utility applications should be integrated with an interface based on a canonical data model, not directly with each other”, Power Systems Conference and Exposition, 2004. IEEE PES 10-13 Oct. 2004 Page(s):1592 - 1596 vol.3

2. Cockborn, Alistair; “Writing Effective Use Cases”, Addison-Wesley, 2001

3. Wiegers, Karl. E.; “Software Requirements”, Microsoft Press, 1999

Page 69: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

5-1

5 INTEGRATION TECHNOLOGY

5.1 Introduction

This section provides a brief introduction to some common integration technologies, a bit of history of integration technology, and an overview of how the technologies can be utilized with the CIM.

5.2 Service Oriented Architecture (SOA)

A technology called Service Oriented Architecture (SOA) is gaining wide acceptance in the IT industry today. SOA is the foundation for some of the other integration technologies described in this section.

5.2.1 Definition of SOA

SOA is a set of guidelines for loosely coupling a modular set of well-defined functional interfaces. These interfaces encapsulate business processes. Business processes can be thought of as specific tasks that a business conducts such as take order, place bid, create new customer, connect service, etc. Building applications is done by connecting the services together into business flows through a technique called orchestration.

The term service refers to the encapsulation of the business process into an atomic interface that can be invoked remotely. XML is used heavily in SOA to create data messages that are passed to and from these services. The services can packaged and exposed to the application users by WSDL (Web Services Definition Language) and the communications protocols that are part of SOAP (originally named Simple Object Access Protocol).

A key component of SOA is the concept of discoverability. Discoverability is where software systems can dynamically “discover” services that are exposed by looking in a directory or registry.

Web services is a term used to describe a specific method of implementing SOA. Web services implement SOA by making the services accessible over standard Internet and World Wide Web protocols. By doing this, well-established communication protocols are used to expose the software services. A key characteristic of this approach is that by the very nature of using web protocols, the services are independent of software operating systems, platforms, and implementation languages.

It is important to recognize that SOA is not a product that can be purchased from a vendor; rather it is a framework and guidelines for a software architecture.

5.2.2 Integration using SOA

Using SOA for the integration of software applications is a method of integration that leaves in place the traditional applications and their respective user interfaces but uses SOA to perform

Page 70: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

5-2

software integration. By using this approach, the orchestration process is not strictly necessary. One key advantage is that by using SOA for traditional application integration, orchestration can be used to build applications that fill in gaps not provided by the legacy applications. This provides for greater business flexibility and adaptability as business processes change in unexpected and unanticipated ways after the applications have been deployed.

The Information Technology (IT) department is no longer a “support organization” for various enterprise applications but a key enabler to adapt with changing business environment and deregulation. As utilities merge, form new operating companies, or integrate IT systems, disparate information systems may serve the same functional area. The SOA implementation will provide a platform of common technical and business services such as auditing, security, and data archival. For example, a Customer Information System (CIS) business area in the diagram below provides an overview of the future system architecture by implementing the SOA based integration.

Before SOA After SOA

Customer Information System

SOA Services/ESB

CIS Vendor 1

Outage Management System Work Management SystemOutage

Management SystemWork

Management System

Figure 5-1 Integration Scenario Before & After Using the SOA

The above SOA based integration is just one of the numerous business scenarios where SOA adoption could benefit the utilities. Typically, SOA implementation is best started with business process improvement initiatives where a utility may focus on one or more business functional

Page 71: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

5-3

area transformations such as customer service, reducing outage duration, demand management etc.

5.3 Enterprise Service Bus (ESB)

A technology called the Enterprise Service Bus (ESB) is commonly used today in the integration of IT systems. This technology has been successfully deployed by many enterprises in different industries.

The ESB is an enabling technology to achieve coherent Enterprise Integration Architecture (EIA). The ESB is a software infrastructure that provides application integration and flexible reuse of the business components within an SOA. The word “bus” refers to the physical bus that carries data between applications and acts as a message broker between applications resulting in reduced point-to-point connections between applications. The ESB does not implement an SOA, but it provides the capability to implement the SOA.

Enterprise Service Bus

Consumer A Consumer B Consumer/Provider C

Provider X Provider Y Provider Z

Interface X1 Interface Y1 Interface Z1 Interface Z2

Interface C1

Figure 5-2 A Diagram Representing an Enterprise Service Bus

An ESB is loosely related to SOA principles; however in contrast to SOA, it is more than just a software architecture. ESB is specific software that can be implemented. The ESB concept is the next generation of integration middleware, which leverages previous-generation EAI technology and web services. An ESB is a standards-based integration platform that is a combination of various types of messaging paradigms, web services, transformation, routing, and reliable transactions. A key characteristic is that ESB technology is distributed, making it scalable for enterprise wide integration.

ESB technology was first introduced in 2002 and has been adopted by many integration vendors. In many cases, the vendors were able to take existing products and retool them to be true ESB platforms.

Page 72: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

5-4

ESB technology is built upon quite a few different IT standards including the following:

• Java Message Service (JMS)

• SOAP and web services APIs

• XML

• XSLT, XPath, and Xquery data transformations

• Web Services Description Language (WSDL)

The ESB typically provides following functionality:

• Adapter Support: The availability of Software Development Kits (SDKs) for custom adapter development to integrate applications and databases.

• Messaging Layer: The ability of the transport layer to support Publish-Subscribe and Request-Reply messaging, and support for services levels such as guaranteed and transactional messaging.

• Data Mapping and Routing: The ability to perform data transformation and intelligent routing to multiple destinations.

• Business Process Automation: The ability to model and automate business processes that span multiple applications.

• Security and Systems Management: The capabilities of system management tools and the ability to comply with future security restrictions, including user authentication and encryption.

• Configuration Environment: The usability of GUI configuration and development tools.

Table 5-1 shows a partial list of ESB vendors and products.

Table 5-1 Partial list of ESB vendors and products

Vendor Product(s) IBM IBM WebSphere ESB, IBM WebSphere Message Broker Iona Artix ESB iWay Software iWay Service Manager Oracle Oracle Service Bus part of Oracle SOA Suite, BEA Aqualogic ESB Software AG webMethods ESB Sonic Software Progress Sonic ESB Sun Java Composite Application Suite (CAPS) (formerly SeeBeyond) Tibco ActiveMatrix Service Bus Vitria Business Accelerator ESB

5.3.1.1 XML Foundation

XML is the language used for representing data in the ESB architecture. XML has many benefits:

• It is a rich data model allowing for many data types to be represented.

• It is human-readable.

• It is easily parsed by software.

Page 73: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

5-5

• It is not a fixed format data structure (both variable length data elements and variable number of fields are supported).

• It is self-describing because XML contains the data elements names in the tags.

• Due to the extensibility, it tends to not break (non-brittle).

5.3.1.2 Message Oriented Middleware (MOM)

A key component of the ESB architecture is the use of Message Oriented Middleware (MOM). MOM is a concept that has been around in the integration world for a while, but it has not gained wide acceptance because it was not coupled with the other important technologies that are now part of an ESB.

MOM provides a loose coupling of the applications because message producers and consumers don’t directly communicate—instead the messages are put on the bus and then picked off of the bus where the producer and consumer don’t know specifically about each other. The bus concept is called channels, queues, or topics depending on the vendor implementation.

In an ESB, the loose coupling is taken one step further because the actual channels, queues or topics are not hard coded into the application—instead, they are configured. Much like the class diagrams discussed earlier, the communication channels, queues, or topics can be organized into a hierarchy, providing a further degree of abstraction and loose coupling.

5.3.1.3 Reliability

In an ESB, messages have certain reliability characteristics. The fundamental property is that the messaging system can provide a store-and-forward mechanism so that unavailable applications will get their data delivered at a later time. Other variations of the store-and-forward mechanism of reliability are delivery options for “at least once”, “at most once”, and “exactly once” delivery.

5.3.1.4 Using CIM with an ESB

The proposed IEC 61968-1-1 Enterprise Service Bus Implementation Profile defines a specific approach to application integration using the CIM and an ESB. The document covers topics such as ESB integration patterns; the common message structure; the use of SOAP; and the use of channels, queues, or topics. The document also includes sample XML and WSDL.

5.4 Enterprise Application Integration (EAI) Suites

Enterprise Application Integration (EAI) suites are software products that provide the capability to share data between applications within the enterprise. This includes solutions for dealing with applications that run on different operating systems, database architectures, programming languages, and the broad category of legacy applications. EAI suites are provided by many vendors who generally offer multiple modules to solve different aspects of the integration problem.

Since ESB is a particular approach to EAI, it is a really a subset of the EAI suite product market. Many EAI vendors that have been in the integration market for a relatively long period of time—pre-dating the ESB standards; and they have capabilities and functionality beyond what is defined as an ESB. These include capabilities such as auditing, monitoring, tracking, and process modeling. Many EAI vendors who originally offered proprietary methods and solutions for the

Page 74: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

5-6

core integration problem have replaced (or now provide alternatives to) the proprietary components in the form of ESB standards-based components. For this reason, the list of ESB vendors has grown to include most of the EAI vendors over time. However, there are a few “pure” EAI vendors who do not offer any ESB technologies, and a few “pure” ESB vendors do not offer a traditional, proprietary EAI solution. There has also been a recent trend of EAI/ESB product acquisitions by software application platform vendors removing most of the pure EAI or ESB vendors from the marketplace.

Table 5-2 shows a partial list of EAI suite vendors and products.

Table 5-2 Partial list of EAI suite vendors and products

Vendor Product IBM WebSphere Microsoft BizTalk Oracle Oracle Fusion Middleware, Oracle SOA Suite Magic Software Enterprises iBolt SAP Netweaver PI Software AG webMethods Sun Sun One Integration Server Tibco BusinessWorks Vitria M3O Suite

5.5 Practical Guidelines

Practical guidelines for developing an integration framework should be based on how efficiently and effectively it integrates applications and provides tools to administer and integrate applications. Table 5-3 lists some essential criteria.

Table 5-3 Essential Criteria for the Integration Framework

Criterion Description Best-in-Class Attributes

Application How it integrates with source and target systems

• Standard database, file, e-mail, and monitoring integrations

• Tools for wrapping integrations around legacy systems • Libraries for custom integrations in a variety of

environments

Transformation How it translates data from source to target system

• Field mappings, type conversions, identifier normalization.

• Support for industry standard formats and protocols • Tools for validating data conformance to business rules

Page 75: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

5-7

Criterion Description Best-in-Class Attributes

Communication How it physically moves data from source to target

• Synchronous or asynchronous, high volume, and low latency.

• Reliable or guaranteed transactions with recoverability • Point-to-point, multicast, or broadcast messages over IP

Orchestration How it moves data according to process rules

• Supports state-full, long-running processes. • Content and availability based dynamic routing. • Ability to encapsulate processes into composite services

Implementation How it enables developers to build solutions

• Minimizes custom code but is extensible. • Provides debugging, testing, and simulation tools. • Simplifies change management and versioning

Administration How it enables managing a solution in production

• Centralized integration cataloguing, definition, and discovery

• Centralized security, monitoring, and exception management

• Business event, process, and activity monitoring

The widely used integration technologies such as Web Services/SOAP, ESB, and EAI integration suites should be reviewed and assessed based on the above listed criteria to achieve the CIM based integration. Table 5-4 provides an overview of most widely used integration technologies support for core criteria of the integration framework.

Page 76: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

5-8

Table 5-4 Integration Framework Technology Support for Core Criteria

Criteria Custom /

Proprietary Web Services /

SOAP ESB - Enterprise

Service Bus EAI - Enterprise Integration Suite

Application

Transformation

Communication

Orchestration

Implementation

Administration

Rationale

Custom or out-of-the-box proprietary integrations can be a good solution for simple problems;

but they are hard to reuse, do not scale

well, and lack central

administration.

Web services hold long-term promise for interoperability, but standards are in their infancy (or to be determined) and retrofitting legacy applications can be

expensive.

ESBs bring central administration and

orchestration to web services, but

also suffer from to-be-determined standards and

general platform immaturity.

EAI products are mature, easily

bridging legacy environments with web services via

proven integration patterns and open

standards.

Legend

Lacking

Meets

Exceeds

5.6 Messaging Framework

The middleware-messaging-based integration is considered an industry best practice; so it is recommended that utilities review and adopt the messaging framework-based integration. Messaging provides interoperability between legacy and newly acquired modern enterprise

Page 77: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

5-9

systems. It also supports asynchronous event-oriented processing and mission critical communications, where messages are not required to provide a reply in response to a request.

Figure 5-2 Diagram Representing Messaging Based Integration

The ESB provides process orchestration where messages generated by dynamic execution of various business processes are routed. The ESB provides an infrastructure to support intelligently directed communication and mediated relationship among integrated applications as depicted in the diagram above. The use of web services can be used instead of traditional point-to-point customized integrations, but using the ESB with process orchestration ensure correct routing of web-service enabled messages.

Page 78: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

5-10

5.7 Integration Options

A middleware platform allows decoupling of source / target integrations, protocols, timing, and processes. The diagrams below give two examples of various systems integrated using different methods. When middleware is deployed, the integration method is transparent to both the source and target systems, which allows decoupling of the integration method.

Figure 5-3 Adaptors Have Coupled Integration Methods

Page 79: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

5-11

Figure 5-4 Middleware Decouples Integration Methods

As explained earlier, a single integration technology may not meet needs of all various applications. Utilities should consider appropriate integration technologies after carefully reviewing each individual application’s requirements and the applications’ vendor-provided integration solutions. The web services, vendor-provided custom adapters, and middleware-based integration can co-exist.

5.8 Other Considerations

For each system and information flow, there are many non-functional considerations that must be considered:

• Do requests need to be authenticated and authorized?

Page 80: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

5-12

• Is encryption needed?

• Is non-repudiation needed for transactions?

• How long will it take the service to process the request?

• How much data will be exchanged?

• Does a request need to be routed or orchestrated?

• How complex is the interface definition?

• What is the impact of changing an interface definition?

• Will the interface be exposed to external attacks by denial-of-service (DoS) or replay?

• What is the impact of the service being unavailable?

• Should the interface be discoverable?

• Are there performance considerations that need to be addressed?

• Are there information flows of concern that do not fit well into a request-reply model?

• What does it take to “service enable” each application?

Answers to these questions can significantly impact the choice of technology used and the designs that might be used when integrating systems. Without clear answers to these questions, fundamental architectural mistakes can be made that could, at a minimum, cause a lot of rework, and in the worst case, cause a project to fail.

5.9 Integration Patterns

Design patterns are general reusable solutions. Design patterns can be compared to algorithms, but they are different in that they provide a solution to design issues rather than computational issues. Design patterns can also be thought of as templates for the design of a piece of software. They are not components or reusable code, just a template for how to design a solution to a particular problem.

Integration patterns are specific design patterns for the integration of software applications and systems. Because the integration domain has a unique class of problems, the use of integration patterns can significantly reduce the cost and effort in performing integration because these patterns provide tested, proven development paradigms. Successful designs require understanding many subtle issues that may not become visible until late in the implementation or even after deployment. By reusing design patterns, integrators can prevent subtle issues that can cause major problems. They are particularly difficult to diagnose because the problems may appear as issues in a downstream system and not in the integration software layer. The use of integration patterns also improves documentation and code readability for architects, designers, and coders who are familiar with the patterns.

Page 81: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

5-13

Figure 5-5 Some Commonly Used Integration Patterns and their Symbols

A step further in reuse can be taken by implementing integration patterns into a form of a library of reusable code sometimes called “common services”. By implementing the common services using well-known integration patterns in the ESB technology being used, reliability and maintainability can be improved further and costs reduced significantly when doing enterprise-level integration.

Common patterns for integration cover issues in message routing, message transformation, and system management. Many of them are applicable to the problems that occur when integrating distribution utility systems. Examples include the following:

Message Routing:

• Splitter

• Aggregator

• Routing slip

Message Transformation:

• Content filter

• Content enricher

• Claim check

Page 82: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

5-14

System Management:

• Control bus

• Message store

• Smart proxy

Common practice in integration today is to use integration patterns. Anyone embarking on an ESB-based integration of distribution systems should provide for the use of integration patterns and the development of common services.

5.10 IT Standards

Generally, within any large IT organization there is a set of IT standards with which to comply. In many cases, these standards will impose some constraints on the types of integration solutions that can be pursued. These standards can range from the simple standardization of desktop applications to back-office server technologies such as the use of operating systems, database platforms, the choice of languages such as Java or .NET, XML, security protocols, the use of Light-Weight Directory Access Protocol (LDAP), and even user interface design.

Modern ESB platforms provide support and compliance with most potential IT standards; but before deciding or beginning any detailed analysis and design, the integration team must review and be aware of the implications of these standards.

5.10.1 Security Issues

Implementations may or may not need to address issues related to security:

• Encryption

• Authentication

• Authorization

• Non-Repudiation

• Protection from attacks such as denial-of-service (DoS)

To address these issues, proposed standard IEC 61968-1-1 Enterprise Service Bus Implementation Profile will leverage security standard technology as needed. The most common ones that can be used today are WS-Security and SSL/TLS.

5.10.2 Implementation Technology

Many integration products provide a “service container” for the execution of integration components. By deploying multiple service containers, high availability and load balancing can be supported.

Integration products also provide administrative tools to perform the following functions:

• Deploy components to a service container once they have been implemented.

• Configure, monitor, start, and stop deployed components.

• Configure, monitor, start, and stop the service container itself.

Page 83: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

5-15

Components can often be instrumented to permit detection of conditions of interest such as failures, exceptions, queue overflow, etc.

5.11 Comparison with MultiSpeak

MultiSpeak® (www.multispeak.org) could be considered a “competing” specification for integration of software for distribution utilities. For this reason, it is necessary to compare the two because, depending on the circumstances, MultiSpeak could be a more suited messaging specification for a utility to adopt.

It should be noted that the MultiSpeak and the IEC are now working on harmonization efforts where the MultiSpeak messaging specifications will become 61968 profiles. Over time, the differences between the two are expected to be reduced, which will enable even greater flexibility in integrating systems.

5.11.1.1 MultiSpeak Background

The MultiSpeak effort is funded by National Rural Electric Cooperative Association (NRECA). NRECA has almost 1000 member electric cooperatives in 47 states. The stated goal of MultiSpeak is to achieve out-of-the-box integration for applications used by NRECA members.

MultiSpeak has gone through several major versions that had different capabilities and used different technologies. MultiSpeak version 1 focused on back-office applications and defined batch file data transfers between them; there was no messaging defined. MultiSpeak version 2 added support for both batch and message-based transfers. MultiSpeak version 3 added additional message-based support and new applications. MultiSpeak 4 will be released in 2009.

5.11.1.2 Comparison

The CIM covers transmission, generation, and distribution; but MultiSpeak is distribution focused. MultiSpeak is focused to meet the needs of electric cooperatives in the US, while IEC 61968 is focused towards all utilities, including IOUs and the international marketplace.

From a technology perspective, IEC 61968 was designed to be transport-independent while MultiSpeak is transport-specific and based upon web services. This has trade-offs that make MultiSpeak adaptors very close to plug-and-play, but they are natively unable to connect to ESB infrastructures. Due to the plug-and-play design goal, the MulitSpeak standard does not have a good mechanism for extending the information model, and thus it is also difficult to adapt to different business processes.

There are also modeling differences that make it difficult to perform simple translations between MultiSpeak and CIM. The following table goes into further detail on the comparison between MultiSpeak and CIM—it highlights some of the major information model differences.

MultiSpeak is a registered trademark of the National Rural Electric Cooperative Association.

Page 84: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

5-16

Table 5-5 MultiSpeak and CIM Modeling Differences

MultiSpeak CIM

Model Management

Model managed using XML Schema with XML Spy

Model managed with Enterprise Architect, where RDFS and XML Schemas are generated

Object identification

objectId found in mspObject class

Naming class used to manage names for virtually all CIM classes

Class Hierarchy

mspObject is parent class for mspSwitchingDevice, mspLineObject, mspPointObject, mspDevice, and mspResultsBase, where each ‘msp’ class may have subclasses

Organized using packages. Naming is parent for PowerSystemResource, whose descendant classes include Equipment and ConductingEquipment

Relationships Inheritance relationships and ‘Lists’ and ‘Banks’ for aggregations

Wide variety of associations and aggregations are defined and managed in the model

Connectivity

Supports both section-oriented (section, parent section) and node-oriented (from – to) connectivity

ConductingEquipment has terminals, which are grouped into ConnectivityNodes – does not support section oriented topology

Asset Modeling

Asset related attributes included within class definitions as needed or through simple grouping (e.g., SwitchBank)

Asset model implemented where a PowerSystemResource can be comprised of one or more Asset instances

Graphical Modeling

mspLineObject has GMLcomplex line and mspPointObject has grid location and rotation

Managed as an attribute of an instance; may have multiple representations

Page 85: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

5-17

The following class hierarchy diagram shows the MultiSpeak equivalent of the CIM UML class diagrams shown earlier in this report.

mspObject

mspLineObject(by the addition of GMLcomplex line)

mspPointObject(by the addition of GML coordinate set, facilityID,gridLocation, and rotation)

mspConnectivityLine(by the addition of from/to

nodes or sectionID and parentSectionID)

mspElectricLine(by the addition of phasing,

conductor information and load)

ohPrimaryLine ohSecondaryLine

ugPrimaryLine ugSecondaryLine

mspConnectivityPoint(by the addition of nodeID or sectionIDand parentSectionID)

mspElectricPoint(by the addition of phasing

and load information)

mspBankObject(by the addition of

comments,See Figure 2-4)

mspMotorGenerator(by the addition of rotating

machine specific fields)

fakeNodeSection

serviceLocation substation

MultiSpeak

mspDevice(by the addition of deviceClass,

inServiceDate, outServiceDate, and facilityID)

meter(by the addition of

meter-specific fields)

mspSwitchingDevice(by the addition of switching

specific fields, See Figure 2-5)

mspResultsBase(by the addition of

engineering analysis fields)

shortCircuitAnalysisResult

feederObjectmotor generator

loadFlowResult

Figure 5-6 The MultiSpeak Class Hierarchy

The following table outlines differences between CIM and MultiSpeak at the object attribute and relationship level:

Page 86: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

5-18

Table 5-6 Comparison of CIM and MultiSpeak Object Level Differences

MultiSpeak CIM Key differences

switchDeviceBank, switch

Switch, Asset CIM Switch with child Assets is roughly equivalent to a MultiSpeak switchDeviceBank comprised of a set of switch objects. Both have subclasses for fuses and breakers.

mspElectricLine Conductor MultiSpeak has ohPrimaryLine, ohSecondaryLine, ugPrimaryLine, ugSecondaryLine, where each has a list of Conductors

CIM Conductor has subclasses ACLineSegment and DCLineSegment, with r, r0, x, x0, bch, b0ch, gch, g0ch

Note that use of Conductor is very different in these models.

transformer, transformerBank

PowerTransformer, TransformerWinding, WindingTest, Asset

CIM impedance model includes b, g, r, r0, x, x0

MultiSpeak identifies priVoltsLo, priVoltsHi,secVoltsLo, secVoltsHigh, pcb

customer Customer MultiSpeak model currently more complete for AMR integration

meter CustomerMeter MultiSpeak model currently more complete for AMR integration

workOrder Work Where MultiSpeak workOrder is focused on staking, 61968 has a much broader treatment of distribution work management

outageEvent OutageReport OutageReport supports multiple steps and associated tracking of customers affected.

Page 87: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

5-19

MultiSpeak CIM Key differences

customerCall TroubleTicket TroubleTicket tracks information needed for callbacks

5.12 Further Reading

1. Erl, Thomas, “Service Oriented Architecture: A Field Guide to Integrating XML and Web Services”, Prentice Hall: 2004

2. B. Leonard, G. Robinson, “Achieving Reliability Objectives with the Aid of a Service Oriented Architecture”, DistribuTECH 2005.

3. Chappell, Dave, "Enterprise Service Bus", O’Reilly: June 2004.

4. Hohpe, Gregor; Bobby Woolf “Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions”, O’Reilly: 2003.

5. S. Neumann, K. Shankar, Ali Vojdani, “Applying Workflow Technologies to Integrate Utility Business Processes”, DistribuTECH 2005.

6. McNaughton, G.; Saint, R.; “Comparison of the MultiSpeak Distribution Connectivity Model and the CIM Common Distribution Power System Model”; DistribuTECH Conference Proceedings, Tampa, FL, 2008

Page 88: EPRI IntroToCIMForIntegratingAppsAndSystemspdf
Page 89: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

6-1

6 SUMMARY Software applications in a distribution utility were typically built around departmental boundaries and were bridged by software built by the IT department, or in some cases in ad-hoc fashion by desperate end users. Inevitably, this situation becomes unmanageable because the software bridges are built by different people using diverse technologies. The number of interfaces rapidly becomes very large because there are so many needed areas of integration. A systematic, well-understood process for integration is desperately needed in the industry. Business drivers and solid business cases can be built for doing integration this way. The utility- centric information model called the Common Information Model can be used with industry best practices to reduce the cost and complexity of performing these integrations.

The CIM is backed by key organizations including EPRI, IEEE, and the IEC. A collaborative organization called the CIM Users Group has been established to make it easier for utilities to share their experiences and work with the various standards organizations.

Understanding CIM requires understanding key technologies such as UML, XML, RDF, and OWL. The CIM is composed of packages specifically for representing electrical networks, assets, and work. Because the CIM is used for various purposes, specific profiles are defined that describe a subset of the model that is applicable to those applications covered by the profile.

The CIM standard also provides a definition of adaptors that conform to the Generic Interface Definition (GID) that facilitate vendor pre-built adaptors based upon the process control OPC technology. The GID subset of the standard is most applicable to the control-center-specific integration space.

Using the CIM as part of a well-defined integration process typically follows these steps:

• Build the Use Cases

• Create the Sequence Diagrams

• Build the Domain Model

• Design the Messages

• Design the Interfaces

• Construct the Interfaces

• Manage the Artifacts

Extending the CIM is typical and to be expected; however, without establishing a methodology for managing the extensions, it is possible to get locked into a specific release of applications and the CIM standard.

Using the CIM as part of an enterprise wide integration strategy requires selecting and utilizing one or more accepted technologies. These include Service Oriented Architecture (SOA), web services, and Enterprise Service Bus (ESB) technologies. Practical considerations must be taken

Page 90: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

6-2

into account when selecting one technology over another; and no one technology is suited best for all situations.

MultiSpeak is a set of message specifications for integration defined by the National Rural Electric Cooperative Association (NRECA). It is focused to meet the needs of electric distribution cooperatives, whereas the CIM standard is designed to meet the needs of all utilities. MultiSpeak has little support for extensions (less flexibility than the CIM), but MultiSpeak leverages the fixed message specifications to achieve a higher degree of plug-and-play. A direct mapping between the two standards is not completely possible, but efforts are underway to make them more compatible.

Page 91: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

A TERMINOLOGY

Term Definition

CDPSM Common Distribution Power System Model (IEC 61968-13)

CIM Common Information Model

CIMug Common Information Model User Group

CIS Customer Information System

CIS Component Interface Specification

CPSM Common Power Systems Model (IEC 61970-452)

DMS Distribution Management System

DoS Denial of Service

EAI Enterprise Application Integration

EAM Enterprise Asset Management

EIA Enterprise Integration Architecture

EIM Enterprise Information Model

EMS Energy Management System

EPRI Electric Power Research Institute

ESB Enterprise Service Bus

GDA Generic Data Access

GID Generic Interface Definition

GIS Geographic Information System

HSDA High Speed Data Access

IEEE Institute of Electrical and Electronics Engineers

ISO International Standards Organization

IT Information Technology

JMS Java Message Service

LDAP Lightweight Directory Access Protocol

MDMS Meter Data Management System

MOM Message Oriented Middleware

mRID Master Resource ID

MultiSpeak Message specifications sponsored by NRECA

MWM Mobile Workforce Management

NRECA National Rural Electric Cooperative Association

Page 92: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

A-2

Term Definition

OMG Object Management Group

OMS Outage Management System

OWL Web Ontology Language

RDF Resource Description Format

RDFS RDF Schema

SCADA Supervisory Control and Data Acquisition

SOA Service Oriented Architecture

SSL Secure Sockets Layer

TC Technical Committee

TLS Transport Layer Security

TSDA Time Series Data Access

UML Unified Modeling Language

URI Uniform Resource Identifier

URL Uniform Resource Locator

WG Working Group

WMS Work Management System

WS-Security Web Services Security)

WSDL Web Services Definition Language

XMI XML Metadata Interchange

XML eXtensible Markup Language

Page 93: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

B-1

B COMMONLY USED TOOLS

Tool Name Vendor Description

Enterprise Architect

http://www.sparxsystems.com.au/products/ea/index.html

Sparx Systems

http://www.sparxsystems.com.au/

UML Modeling Tool

Rational Rose

http://www-01.ibm.com/software/awdtools/developer/rose/index.html

IBM

http://www.ibm.com

UML Modeling Tool

XMLSpy

http://www.altova.com/products/xmlspy/xml_editor.html

Altova

http://www.altova.com/

XML Viewer/Editor

CIMTool

http://www.cimtool.org/

Langdale Consulting

http://www.langdale.com.au/

CIM Modeling Tool

CIMVian

http://www.uisol.com/uisol/CIMvian/CIMvian.htm

UISOL

http://www.uisol.com/

CIM/XML Model Viewer

CIMSpy

http://www.powerinfo.us/CIMSpy21/download.html

Power Info

http://www.powerinfo.us/

CIM/XML Model Viewer

Page 94: EPRI IntroToCIMForIntegratingAppsAndSystemspdf
Page 95: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

C-1

C LIST OF DISTRIBUTION RELEVENT IEC STANDARDS EFFORTS

Category Standard Group Title

Distribution 61968-1 TC 57 WG 14 Interface Architecture and General Requirements

Distribution 61968-1-1 TC 57 WG 14 Enterprise Service Bus Implementation Profile

Distribution 61968-1-2 TC 57 WG 14 Naming and Design Rules.

Distribution 61968-2 TC 57 WG 14 Glossary

Distribution 61968-3 TC 57 WG 14 Network Operations

Distribution 61968-4 TC 57 WG 14 Record and Asset Management

Distribution 61968-5 TC 57 WG 14 Operational Planning and Optimization

Distribution 61968-6 TC 57 WG 14 Maintenance and Construction

Distribution 61968-7 TC 57 WG 14 Network Extension Planning

Distribution 61968-8 TC 57 WG 14 Customer Support

Distribution 61968-9 TC 57 WG 14 Meter Reading and Control

Distribution 61968-10 TC 57 WG 14 Other Systems (e.g., ERP)

Distribution 61968-11 TC 57 WG 14 CIM Extensions for Distribution

Distribution 61968-12 TC 57 WG 14 Use Cases

Distribution 61968-13 TC 57 WG 14 RDF Distribution model exchange (CDPSM)

Distribution 61968-14 TC 57 WG 14 MultiSpeak Mappings and Profile

EMS API 61970-1 TC 57 WG 13 EMS API Guidelines

EMS API 61970-2 TC 57 WG 13 EMS API Glossary

CIM 61970-301 TC 57 WG 13 CIM Base (the core CIM)

CIM 61970-302 TC 57 WG 13 CIM – Financial, Energy Scheduling, and Reservations

CIS 61970-401 TC 57 WG 13 Component Interface Specification Framework

GID 61970-402 TC 57 WG 13 Common Services

GID 61970-403 TC 57 WG 13 Generic Data Access

GID 61970-404 TC 57 WG 13 High Speed Data Access

Page 96: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

C-2

GID 61970-405 TC 57 WG 13 Generic Eventing and Subscription

GID 61970-406 TC 57 WG 13 Program Invocation

GID 61970-407 TC 57 WG 13 Time Series Data Access

CIM 61970-450 TC 57 WG 13 CIS Information Exchange Model Specification Guide

CIM 61970-451 TC 57 WG 13 SCADA CIS

CIM 61970-452 TC 57 WG 13 Transmission Network Model Exchange Profile (CPSM)

CIM 61970-453 TC 57 WG 13 CIM-based graphics exchange (SVG)

CIM 61970-501 TC 57 WG 13 CIM RDF Schema (CIM XML)

CIM 61970-552 TC 57 WG 13 CIM XML Model Exchange Format

CIM 61970-552-4 TC 57 WG 13 Format and rules for exchanging modeling information

Page 97: EPRI IntroToCIMForIntegratingAppsAndSystemspdf
Page 98: EPRI IntroToCIMForIntegratingAppsAndSystemspdf

Electric Power Research Institute 3420 Hillview Avenue, Palo Alto, California 94304-1338 • PO Box 10412, Palo Alto, California 94303-0813 • USA

800.313.3774 • 650.855.2121 • [email protected] • www.epri.com

Export Control Restrictions

Access to and use of EPRI Intellectual Property is granted with the specific understanding and requirement that responsibility for ensuring full compliance with all applicable U.S. and foreign export laws and regulations is being undertaken by you and your company. This includes an obligation to ensure that any individual receiving access hereunder who is not a U.S. citizen or permanent U.S. resident is permitted access under applicable U.S. and foreign export laws and regulations. In the event you are uncertain whether you or your company may lawfully obtain access to this EPRI Intellectual Property, you acknowledge that it is your obligation to consult with your company’s legal counsel to determine whether this access is lawful. Although EPRI may make available on a case-by-case basis an informal assessment of the applicable U.S. export classification for specific EPRI Intellectual Property, you and your company acknowledge that this assessment is solely for informational purposes and not for reliance purposes. You and your company acknowledge that it is still the obligation of you and your company to make your own assessment of the applicable U.S. export classification and ensure compliance accordingly. You and your company understand and 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.

The Electric Power Research Institute (EPRI)

The Electric Power Research Institute (EPRI), with major locations in Palo Alto, California; Charlotte, North Carolina; and Knoxville, Tennessee, was established in 1973 as an independent, nonprofit center for public interest energy and environmental research. EPRI brings together members, participants, the Institute's scientists and engineers, and other leading experts to work collaboratively on solutions to the challenges of electric power. These solutions span nearly every area of electricity generation, delivery, and use, including health, safety, and environment. EPRI's members represent over 90% of the electricity generated in the United States. International participation represents nearly 15% of EPRI's total research, development, and demonstration program.

Together…Shaping the Future of Electricity

© 2008 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.

Printed on recycled paper in the United States of America 1016058