The Common Information Model for Distribution

An Introduction to the CIM for Integrating Distribution Applications and Systems 1016058

Effective November, 2008, this report has been made publicly available in accordance with Section 734.3(b)(3) and published in accordance with Section 734.7 of the U.S. Export Administration Regulations. As a result of this publication, this report is subject to only copyright protection and does not require any license agreement from EPRI. This notice supersedes the export control restrictions and any proprietary licensed material notices embedded in the document prior to publication.

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

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 ▪ askepri@epri.com ▪ www.epri.com

com. NOTE For further information about EPRI. EXPRESS OR IMPLIED. INCLUDING MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. APPARATUS. ANY MEMBER OF EPRI. (EPRI). OR (B) ASSUMES RESPONSIBILITY FOR ANY DAMAGES OR OTHER LIABILITY WHATSOEVER (INCLUDING ANY CONSEQUENTIAL DAMAGES. Inc. OR SIMILAR ITEM DISCLOSED IN THIS DOCUMENT. Inc. METHOD. Inc. PROCESS. and TOGETHER…SHAPING THE FUTURE OF ELECTRICITY are registered service marks of the Electric Power Research Institute. APPARATUS. NOR ANY PERSON ACTING ON BEHALF OF ANY OF THEM: (A) MAKES ANY WARRANTY OR REPRESENTATION WHATSOEVER. or a topical study.313. 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. METHOD.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. PROCESS. INCLUDING ANY PARTY'S INTELLECTUAL PROPERTY. EPRI. (UISOL) This is an EPRI Technical Update report. INC. Electric Power Research Institute. a meeting. All rights reserved. A Technical Update report is intended as an informal report of continuing research. Copyright © 2008 Electric Power Research Institute. OR SIMILAR ITEM DISCLOSED IN THIS DOCUMENT. OR (II) THAT SUCH USE DOES NOT INFRINGE ON OR INTERFERE WITH PRIVATELY OWNED RIGHTS. OR (III) THAT THIS DOCUMENT IS SUITABLE TO ANY PARTICULAR USER'S CIRCUMSTANCE. ANY COSPONSOR. call the EPRI Customer Assistance Center at 800. It is not a final EPRI technical report. ORGANIZATION THAT PREPARED THIS DOCUMENT: Utility Integration Solutions.3774 or e-mail askepri@epri. . (I) WITH RESPECT TO THE USE OF ANY INFORMATION. NEITHER EPRI. THE ORGANIZATION BELOW.

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. (UISOL) 24 Benthill Court Lafayette. i . EPRI. CA 94549 Principal Investigator T. Inc. CA: 2008. Palo Alto.CITATIONS This document was prepared by Utility Integration Solutions. 1016058. Nielsen This document describes research sponsored by the Electric Power Research Institute (EPRI).

.

Results This report is intended to provide an introduction to the CIM as it applies to electrical distribution systems. The report will be of particular interest to distribution organizations that might be evaluating or considering utilizing the CIM in an integration product. 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. and operations who may not familiar with the CIM and its purpose and benefits. engineers. Background The CIM has been used for several years to integrate transmission management system applications and to exchange power system models between systems. Approach In order to hit the target of providing beneficial information for the utility industry. The judicious use of the CIM to integrate applications and systems can enhance operational functionality and reduce the lifetime cost of integration efforts. and distribution engineers in planning. This report can serve as a starting point for distribution system managers. or for building an intelligent grid strategy. It is targeted for distribution utility general managers. 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. and information technology (IT) resources for preparing strategic and tactical plans for enterprise integration projects. however. software IT managers and analysts. Feedback from utilities indicated that informational resources were lacking regarding the CIM and regarding integration methodologies in general.REPORT SUMMARY This report introduces the Common Information Model (CIM) as it applies to electrical distribution system operations. 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. as part of vendor selection criteria. maintenance. iii . the project team held a kick-off meeting with the IntelliGrid funders at the beginning of the project. CIM has not been widely adopted for the integration of distribution management systems and applications.

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. EPRI is committed to ensure this need can be met in the area of data exchange and data management. With the adoption of advanced metering infrastructure (AMI) as well as other new sensors and information sources in the electrical distribution system. 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.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. 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. Keywords Common Information Model (CIM) Distribution Management System (DMS) Enterprise Application Integration (EAI) IEC 61968 IEC 61970 Service Oriented Architecture (SOA) iv . packages.

The attendees provided critical insight and feedback into the structure and outline used for this report. 2008. The following people provided content.ACKNOWLEDGEMENTS We would like to acknowledge and thank the attendees from the kick-off meeting held in Atlanta on June 3. We would also like to give special thanks to Southern Company for hosting the workshop. and feedback on early drafts of this report: • • • Scott Neumann Ali Vojdani Parag Parikh v . source material.

.

...........................1 The Core Package ...........3-17 3.....................................................................................3 CIM Users Group ............................................4 Resource Description Framework (RDF) .....................................CONTENTS 1 INTRODUCTION...............................................................3-2 3..............3 What CIM Isn’t....................2 The Topology Package ...2 Role of EPRI and IntelliGrid .........................................................................4........6.........4.2 Integration of Distribution IT Systems ...........................7.........3-4 3..................................8 CIM Profiles.....................1-1 1...................................................................8.............................................................................5 Further Reading .......................................3 Work Package ..........................................7......................................................3-23 3..........4 IEEE ............................................2 What CIM Does ...............3-5 3......................1-1 UTILIZING IT INTEGRATION FOR DISTRIBUTION SOFTWARE .........................3-25 3.........5 The Wires Package – Part 3 Switches .................2 The IEC Standard.............................................3 Ontology Definition ................5 CIM Packages ......................3-15 3................2-3 2.4...2 Operations Package.........................3-4 3..................................3-26 3.3-19 3.............3-24 3............................................2-4 2...................................................3-5 3............1.............1 The Unified Modeling Language (UML) ..1 Definition of a Profile ..................3-1 3..................................1 History of the CIM..1..............................................................................................................................................2-1 2.......................................................................4 The Wires Package – Part 2 Transformers ....6.....................................3-1 3........................................................................................3-16 3..3-3 3...........................................6 Relevant 61970 Packages .........................3-3 3...............3-1 3............................................................2-2 2..........3-23 3................................................6................................................5 EPRI’s Continued Role.....7 Relevant 61968 Packages ...3-21 3..........................................6.............3-4 3...................1 Assets Package......................5 Web Ontology Language (OWL) .........1 Report Purpose ...................................3-14 3..............................................3 The Wires Package – Part 1 Lines......................................2 eXtensible Markup Language (XML).............................4 CIM Background......................1.......................................3-13 3............................7................................4.................................................................................................................2-5 THE COMMON INFORMATION MODEL .........4..............3 Minimizing the Distance to Integrate ................................................................................................................................4 Building the Business Case and Managing the Cost ..............3-26 2 3 vii ..........1 The EPRI Roots ...............................................................................................3-17 3...........1......................................1-1 1......................3-14 3.........................................................1 Common Software Systems used in Distribution ........................................................................................................2-2 2....3-18 3....6..................................................................................................................................................................3-21 3..............................................................................................................................1........

...............................................................................................................1 Security Issues .............9..................................2 Use Case Development ...............................................................................................10 IT Standards........5-11 5........6 Interface Design .........................................................................3-28 3...........4-15 4.....................................................................................................................................................5-6 5.........................................9........................................................10....................................................................4-1 4......................1 Use Case Overview..5-14 5.....4-4 4.............5-1 5...........3-27 3......................5-19 SUMMARY........................3-29 4 INTEGRATION PROCESS .5-12 5....................................................................................................4-15 4.........................5-15 5.4-3 4........................5-5 5.................3 Extension Class....9...................................................5-14 5......................................3 Enterprise Service Bus (ESB) ..............................................................4-10 4..10 Further Reading .........................2 CPSM Profile.............5-3 5................................................................................................3-27 3......................................8..............11 Comparison with MultiSpeak........................................................................................5-10 5.................................................................................................................................................................................................................4 Impact of New CIM Versions...............4 Enterprise Application Integration (EAI) Suites .................................................3 Planning Profile ..................................5-1 5.....4 Dynamics Profile ..................................................9.4-12 4...........4-12 4................................................................................8 Other Considerations .......................................................................................5-1 5.................................................................................................2 Implementation Technology .......................5 Message Design..............................................3-27 3.................................4-6 4................................................................................................................4-16 INTEGRATION TECHNOLOGY ..........................................................................................................3 Sequence Diagram Creation ......................................................4-13 4.............5 Practical Guidelines............................................................................................................................3-26 3............10 Further Reading .................7 Integration Options .....5-1 5....6-1 5 6 viii ...........2............................4-11 4.........................5 CDPSM Profile .....................1 Definition of SOA........................................................................8.......................9 Integration Patterns .........................4-7 4.....5-14 5................2 Extension Attribute .....3....................................................................4-9 4...........................................................................................12 Further Reading ........................4-1 4......................................................................................................................9............10...............................................5-8 5..............1 Introduction......................................2 Service Oriented Architecture (SOA) .............................8....2.....................7 Interface Construction ..................................................................9 Generic Interface Definition (GID) ......................................1 Extension Management...5 Merging Models...................................8 Artifact Management .........6 Messaging Framework ........................................4-13 4..............................................................................................................5-1 5....4 Domain Modeling ....................................................................9 Managing CIM Extensions .....................2 Integration using SOA ....................................................8...............................................

................................ C-1 ix ......................................................................... B-1 LIST OF DISTRIBUTION RELEVENT IEC STANDARDS EFFORTS ...................................... A-1 COMMONLY USED TOOLS .....A B C TERMINOLOGY .........................................................................

.

1. EPRI plays a role in introducing CIM into other research activities where it can be used in larger initiatives such as the IntelliGrid program. It is targeted for distribution utility general managers.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. which should allow more resources to be applied toward increased functionality for managing and optimizing the electrical system. utilities and vendors can reduce their integration costs. or for building an intelligent grid strategy. EPRI is committed to ensure this need can be met in the area of data exchange and data management. With the adoption of AMI as well as other new sensors and information sources in the electrical distribution system.1 Report Purpose This report is intended to provide an introduction to the CIM as it applies to electrical distribution systems. the problem of integration is not getting any easier. By using a common model. 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. 1-1 . 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. as part of vendor selection criteria. 1. and operations who may not familiar with the CIM and its purpose and benefits.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. software IT managers and analysts. and distribution engineers in planning. maintenance. It is of particular interest to distribution organizations that might be evaluating or considering utilizing the CIM in an integration product.

.

consolidating to just one single system and vendor is. the process was managed manually. 2-1 . 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. in ad-hoc fashion by desperate end users. or “software stovepipes”. Two strategies exist for dealing with this: 1) utilize a common integration platform for all integration. over time. These applications were initially used and operated independently by the various groups. There are several common integration technologies and platforms that are commonly used today. so “external” integration is still needed. 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). they all attempt to solve a similar problem of providing a solution to the problems associated with difficult–to-maintain ad-hoc integration technologies.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. More specific details of these technologies are discussed later in this report. this situation becomes unmanageable because the software bridges are built by different people using diverse technologies. The situation is further aggravated as systems are upgraded or replaced and as business processes change. Inevitably. departments. 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. experts in both systems are generally required who understand the exact meaning of each data element being transferred. When one of these technologies is utilized. for all practical purposes. Even if the later strategy is pursued. in some cases. To perform this mapping. Typically. these group and departmental boundaries between systems were bridged by software built by the IT department or. 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. Whenever a business process required information to flow from one system or application to another system or application. and organizations in the utility. impossible. This level of maturity in an organization’s software infrastructure is sometimes called “islands of automation”. “software silos”. and the use of a common integration platform still has many benefits.

this method can significantly reduce the number of mappings required. and customer relationship management. 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. Instead of mapping the data elements from each system directly to the data elements of each other connected system. in many of even the largest utilities. and manufacturing.) 2. In cases where the number of systems is large and the number of interconnects is large. Below is a diagram that represents just one example of the interconnections that might exist between these systems. Today. For this reason the systems mentioned above have are connected in many different ways from one utility to the next. the CIM has emerged as this common information model.2 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 Integration of Distribution IT Systems As described in general terms earlier. finance. Within the electric utility industry. communicating with field crews. and collecting meter information. so that the common model doesn’t have to be hand built—rather. paper asset records. distribution systems were mostly managed with paper maps.1 Common Software Systems used in Distribution Only a few decades ago. and they exist for many different industries such as telecommunications. healthcare. it is much more common to find software systems that automate most of these aspects of running a distribution system. A technique for further simplifying this task is to utilize one or more industry standard information models. it can be adopted. (There are also common information models that are specific to back-office functions such as human resources. integration practices have historically been relatively adhoc and not well structured. purchasing. and manual processes for reading measurements. managing outages. the mapping is performed once from each system to this common model. 2-2 . and there’s also a common information model for managing computer network infrastructures. 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: • • • • • • • • • • 2. These industry standard models are typically called common information models.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.

then the “distance to integrate” for plug-and-play is small. 2-3 . Plug-andplay 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.3 Minimizing the Distance to Integrate An objective frequently defined for interoperability is the concept of “plug-and-play”. 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.SCADA Distribution Management System Customer Information System Outage Management System Geographic Information System Reliability & Planning Systems Metering System Meter Data Manager Asset & Work Management System Mobile Workforce Management System Figure 2-1 Example Distribution Systems Interconnections 2. If we consider the level of integration involved as a length or distance.

a community can improve system integration and the effort to achieve interoperability. remembering that every line of code needs to be tested. The greater the customization and effort to make and test these changes. In many cases. a commonly used information model can provide semantics that a community of integrators readily understands. it is not practical to specify standard interfaces to this level of detail. standards or best practices can be used to shorten this distance. 2-4 .No standard exists.4 Reducing the distance to integrate can have a significant impact on installation and maintenance costs. For example. At least by reaching agreements in specific areas of interoperation. provides a familiar format and structure without significant training. maintained. With time. this requires identifying costs that are spread across many departmental boundaries. There are many techniques that can reduce the distance to integrate. and evolved Building the Business Case and Managing the Cost 2. 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. 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. things can more closely approach plug-and-play. biasing towards next-generation tools that allow integration to be ‘configured’ instead of ‘coded’. and in many. complex situations. 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. However. such as XML. the greater is the distance to integrate. Standard syntax.

3. S. Ulph. T. “LIPA Takes a Journey on the Integration Bus”. Hervey M. R. presented at DistribuTECH 2003. FL.. Reifer. Kuntz. increased agility..emsusers. 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... October. Randy. Robinson. E. www. Williams. I. 2004. “From GIS to CIM to DMS operations model and UI”. presented at 2007 EMS users conference. environmental concerns.. T&D World. “Using a Common Infrastructure and Language to Integrate Applications at Florida Power & Light”. http://tdworld. and renewable energy sources could easily make adopting the CIM and associated integration technologies a very compelling case on its own. Neumann. D.Another approach to building the business case is to identify the returns associated with improved business effectiveness. “Distance to Integrate: Is the Hype of Plug and Play Integration Doing the Industry a Large Disservice?”.. “CIM at PacificCorp”.ppt 4. 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... DistribuTECH Conference Proceedings. D. 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. Feb 1. and faster response to changes. Nielsen. This can enable one application to be substituted for another with a lower cost. Rhodes. 2008. G. 2002.. distributed resources. 5. 2008 2..5 Further Reading 1.com/distribution_management_systems/lipa_takes_journey/ 2-5 . and it allows for new applications to easily connect. 2.” IEEE PSC&E 2004. Falcon. The unforeseen changes that are most likely going to occur in the utility industry due to the intelligent grid. “Making the Software Business Case”.. D. Addison-Wesley. 6. P. “MDI: A Solution for Outage Management. G. Boardman. 7. presented at DistribuTECH 2001.. Tampa. Hengst. Brown.org/prevconf/2007/CIM%20at%20PacifiCorp%20v10. The same well-defined points of connection can also allow for new capabilities or features to be integrated into the system.

.

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. it was envisioned that applications would have to exchange information in a way that was not tied to a proprietary technology. exchange data in way where the meaning of the data is universally understood by both parties. It would also allow buyers to replace individual applications over time. The roots of the utility CIM go back to several projects sponsored by the Electric Power Research Institute (EPRI). 3. Upgrades were typically only possible by replacing the entire EMS with a “forklift” replacement.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. 3. and a high-level description of the components relevant to distribution. 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. To achieve this vision. 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. while working on this problem. Thus. And even more fundamentally. potentially provided and used by different vendors. The CIM vision was to enable applications vendors to build and sell pieces of an EMS separately that could be interconnected together. 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.3 THE COMMON INFORMATION MODEL This section covers in detail the definition of the Common Information Model. removing the need for forklift replacements. it would be very difficult to get 3-1 . background material required to understand the model.1 History of the CIM This section explains some of the relevant history of the CIM. In this environment. Over time. 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. including most importantly the roles of the different organizations that are part of the CIM community. This is where the concept of having a common information model was first determined to be a fundamental problem that needed to be solved.1. It was also becoming apparent that APIs are typically tied to specific technologies. the first being the Control Center Application Programming Interface (CCAPI) project. 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.

which was the original goal of the CCAPI project. the definition of APIs. 3-2 . the committee initiated efforts for adding additional pieces to the information model. it would become easier for vendors. messages. articles in trade journals. WG 16 – Deregulated Energy Market Communications.1. the vision could not be achieved. the next step was to promote its use among the vendors. CIM efforts were started by the International Electrotechnical Commission (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. and interestingly enough. The working groups each produce a series of standards that describes in precise language the scope and definition of the standard. Once a standard. The standards documents are assigned a standard number by the IEC. Ultimately. Initially. 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. Each sub-area that is to be addressed by the standard was assigned to small teams of interested parties called a working group. 3.API). the following draft standards were submitted to the IEC: • • • Common Information Model (CIM) Generic Interface Definition (GID) Common Power System Model (CPSM) Over time.2 The IEC Standard As the research progressed and started to produce a concrete information model. and WG 19 – Interoperability within TC 57 in the Long Term. users and consultants to promote the use of CIM by simply referencing the standard. including electrical distribution system elements. including Requests for Proposals (RFPs) issued to the vendors. For this reason.vendors and users who had made significant investments in specific technologies to agree upon a set of APIs. There are now parts of the standard that not only cover the information model but also different implementations and uses of the information model. Without vendors utilizing the information model. 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. The two most relevant series of standards today are the IEC 61970 and IEC 61968 series. WG 14 – System Interfaces for Distribution Management (SIDM). For these reasons. The current set of relevant working groups are • • • • WG 13 – Energy Management System Application Program Interface (EMS . and promotional literature by the vendors touting their compliance to the standard. the focus shifted away from APIs and towards defining what is called an information model. This includes ways to express the information model in files. This could be done in many forums. One way to do this was to take the information model and turn it into an international standard.

The web site contains a repository of additional presentations. This forum is called the CIM Users Group (CIMug).org/cmte/psace/CAMS. and proceedings where cases studies and research topics associated with the use of CIM can be found.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. files.1. 3.The IEC 61970-301 standard (part of the IEC 61970 series) describe the information model used by EMSs.org/cmte/psace/ o Computing and Analytical Methods (CAMS) Subcommittee: http://ewh.org. such as Distribution Management Systems. switches. This web site is access-restricted to the members of the working groups. and integrators who use the CIM.cimug. Computing. In addition. a common area for the relevant TC 57 working groups is also hosted on the UCAIug web site at http://iectc57.iec. and the connectivity of these devices. This web site is access-restricted to the members of the working groups 3.org. and other artifacts to be shared among the user community. and Economics (PSACE) Committee: http://ewh. The IEC 61968 standard is a derivative and references many of the components in the IEC 61970-301 core standard. transformers.ucaiug.org. The IEEE also is a good source of references including material in the various journals.html 3-3 . documents. and Work Management Systems. which redirects to http://cimug. Some of the more relevant IEEE groups are below: • Power System Analysis.3 CIM Users Group Because IEC TC 57 is focused on defining and revising the official standard and is formally part of the IEC. For this reason. In addition. The IEC TC 57 working groups share a common web site at http://tc57.ch. vendors. The CIMug is a member group of the UCA (Utility Communications Architecture) International Users Group (UCAIug). conferences. The CIMug users group holds meetings and hosts a web site.ucaiug. another forum was created to provide a venue for utilities.ieee.1.ieee. A list of the relevant standards and the associated working groups are listed in Appendix C. Outage Management Systems. consultants. The IEC 61968-11 standard (part of the IEC 61968 series) describes the extensions to the information model used in electrical distribution IT systems. The CIMug web site can be found at http://www. IEC 61970-301 is said to contain to the “core” CIM. the CIMug also provides a channel to the standard organization for users to make suggestions for changes and extensions to the current standard. This includes many of the core components such as wires.

It is a logical information model that is intended to be used in message definitions between separate systems. 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. In fact. but that is not its originally intended purpose.org/soc/pes/dsacom/ 3. 3. In the case of the common information model used in electric utilities. a software system that is CIM based doesn’t have to 3-4 . EPRI coordinates the annual interoperability tests. it can help create a better understanding of what it does do—and remove some false expectations. such as devices on an electrical network. 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.2 What CIM Does An information model is an abstract and formal representation of objects. 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). the formal definition is done using the Unified Modeling Language (UML). well-defined fashion— typically a rigid language or diagramming technology. 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. 3. By stating what CIM doesn’t do. These tests are specific to a particular subset of CIM defined in what is called a profile. or they may themselves be abstract.3 What CIM Isn’t There are some common misconceptions about the CIM.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. The information model is usually formally described in a particular. In other words. Currently. Second. CIM does not specify or define a physical data model or physical data store. their attributes. First. In many cases the information model can be represented in different forms usually by a formal translation.Power System Modeling in CIM (PSM-CIM) Task Force • Distribution System Analysis Subcommittee: http://ewh. 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. such as the objects used in a customer information system. which are tests of various vendor-provided software systems to validate that they can interchange information based upon a CIM definition. 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.1. This modeling will be further described later in this report. There is nothing preventing it from being adapted to be used as a definition for a physical database. and the behavior and operations that can be performed on them. their associations to other objects. The modeled objects may be physical objects.ieee.

Fourth. In fact it is intentionally considered to be technology agnostic. It is used for defining. and documenting software systems. Java. There are ways to manage these extensions so that they don’t cause problems. Linux.4. Oracle. There will be more details on this interoperability testing later in this report. or SQL Server.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. This section provides background material that covers the key elements of those technologies. CIM is built upon several foundation technologies. Vendors can easily claim some level of CIM compliance. rather it provides enough background for a person to understand CIM.have a database schema that uses the CIM—rather it should have interfaces that have messages defined based upon the CIM. CIM does not dictate platform technologies such as Windows.4. these only cover testing of certain parts of the CIM in some very specific usage scenarios. UML diagrams are used to provide three different views of a model: 3-5 . visualizing. the only certification of CIM compliance is the interoperability test sponsored by ERPI. A complete model includes not only diagrams but also supporting written documents. Currently. C#. C++. It is a language and not just a diagramming technique. Adding extensions to the information model is necessary to deal with these situations. Fifth. An interested reader should utilize the references listed at the end of this section for more in-depth coverage of these topics. however. extending the CIM information model is acceptable and even anticipated. 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. The CIM covers the common information that is typically used in the information flows between systems in a generic electrical utility. A UML diagram is a graphical representation of the model of a system. building. 3. and that topic will be covered in more detail later.4 CIM Background As mentioned earlier. There can and will be information that is unique to a particular utility and its specific software systems. Third.2. It is not meant to be comprehensive material on any of these technologies. 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. currently there are no rigorous definitions of what makes an application or system CIM compliant or not.

this report only provides details on class and sequence diagrams as they are used to perform integration using the CIM. The metadata provides “data about data” (i.e.1.1 UML Overview UML officially defines the notation and syntax for thirteen different types of diagrams.2 UML Class Diagrams UML class diagrams provide a means to visually represent object hierarchies and relationships. using the CIM only requires an understanding of the class diagram and the sequence diagram. This section provides a simple example of how class diagrams can be used to represent a model that is independent of the implementation platform.. For this reason.4. it describes characteristics and context of data in an information model). 3.• • • 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. and associations with other data. and not completely defining a software system. its relationships. content.1. 3-6 . and nature of an information entity. 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. The metadata contains technical composition.4. 3.

much like a file is placed inside of a directory or folder.1. departments. if you were building a model to be used by a Human Resources system. Packages can be thought to be similar to folders or directories in a computer file system. These groups of classes are called packages. Getting the correct set of classes defined for a particular problem is challenging and usually takes an experienced modeler to get it “right”. managers.4. 3. the task of dividing up the system into the different types of things that will be represented is a key first step. and benefits. As a general modeling principle. When modeling a system. For instance. The goal is to design the classes so that new requirements don’t require changes to the classes already defined.1 Packages UML class diagrams can be divided into separate groups of classes. 3.2. the class hierarchy should represent the real-world structure of the system. Each class belongs to a specific package. In UML class diagrams. the classes in the folder should be related. Just like the contents of folders in a file system. you might create classes for things like employees.1.2.A class represents a specific type of object.4. A class hierarchy is a model of the system that represents every component as a separate class. In the class diagram. One of the challenges in getting the right set of classes defined is anticipating future changes and new requirements. classes are diagramed as boxes with the name of the class in the top of the box. they are diagramed as folders.2 Classes Classes are the specific types of things that are being modeled. 3-7 . 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. and the different packages should be described in way that assists a reader to understand the groupings.

3 Inheritance One way to reduce the impact of change on the system is to make use of a concept called generalization or inheritance. and software operations can be defined to work with the most general class possible. It is important to understand that not only does the class have the attributes listed in the box for that class.3. if you had defined a general class called vehicle and built more specific classes for automobile and motorcycle. In UML class diagrams. When there are multiple levels of inheritance. Each class can have multiple instances of that class which are called objects. and an employee class could inherit from the person class and have an additional attribute: employee number. In UML. leading to a class diagram that has some very general classes and multiple levels of more specific classes. The generalization of classes can be extended for multiple levels. messages. The association between the more specific class and the more general class is called inheritance. Inheritance allows us to define very general classes and more specific classes.1. but it also has all of the attributes associated with the classes that it inherits from.4. and then if a new.4. all of the software that works on the general class will still work with the new class. Inheriting from the employee class would be exempt and non-exempt classes.4 Attributes Classes have properties or elements called attributes that are descriptive of that type of thing. and define a relationship between the specific classes and general 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. and more importantly would work on any new types of vehicles you add in the future. There is a good reason for doing this.1. For example. Code. Common terminology is to call the more specific classes “child classes” and the more general classes “parent classes”. 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.2. which would have an attribute of salary for the exempt class and an attribute of hourly rate for the non-exempt class. 3-8 . 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. For example. but with their own internal values. Each object instance has the same number and type of attributes. the person class might have name and a gender as attributes. 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.2. child classes can also be parent classes of other child classes . 3. all of the code that works on vehicle would also work for an automobile and motorcycle. more specific class that inherits from the general class is defined. in a Human Resources system.

These relationships are called associations in UML. and the third is called composition. There are three types of associations that can be represented.5 Associations Classes also have relationships that describe how an object is related to or connected to other objects. Associations are drawn as lines between two boxes that represent the two related classes. 3-9 . As an example of a composition association.2. For example. each object instance has the same number and type of associations. but with their own internal values. the relationship between an owner and a motorcycle is a simple association. the second is a specialized type of association called aggregation. 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.4. the relationship between a building and its rooms is a composition because the building is not an assembly of rooms. Just like attributes.1. rather it is composed of rooms. but the relationship between a motorcycle and its engine and handlebars is an aggregation because the parts could be removed and replaced. Aggregations are drawn as a line with an open diamond on one end of the line. The first is called a simple association. A composition is drawn as a line with a closed diamond on one end of the line. Simple associations show that the two classes have a connection.Figure 3-2 Example Class Diagram Containing Four Classes Showing Inheritance and Attributes 3.

3-10 . For example. in our example a vehicle must have one and only one owner but an owner may have zero or more vehicles. For instance.*) then it means that the relationship from this object to the associated object must be one or more. If the association is noted as (1.Associations have properties that represent the number of possible connections between that object and the related object. Figure 3-3 Example Class Diagram Showing Associations and Multiplicity 3. a simple “1” says that the relationship from this object to the associated object must be one and only one.1.2. This property is called the multiplicity...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. 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. It should be noted that the multiplicity is represented on both ends of an association and it can be different on each end. For this reason.4. The numbers represent the minimum and maximum possible relationships. If it was (0.*) then it would mean that it may be zero or more. another example is appropriate.

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. This Vehicle class has two simple associations: one to an Owner and one to a Manufacturer.. and the multiplicity between the Owner class and the Vehicle class is “0. The class Manufacturer has one attribute: Name (not shown in figure 3-4). the association to 3-11 . however the multiplicity between the Vehicle class and the Manufacturer class is “1” because a vehicle can have one and only manufacturer. 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. each Vehicle has one attribute: Model Name.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. there are two child classes of the Vehicle class: Motorized and SelfPropelled.*” indicating that an owner can own zero or more vehicles. The Owner class has one attribute: Name. and the multiplicity between the Manufacturer class and the Vehicle class is “1.*” because the manufacturer can make many different vehicles. we start with a parent class called Vehicle. The Motorized class has one attribute: VIN#. In this model. and the SelfPropelled class has no additional attributes. In our example model. In the example model.

StartingCurrent and VoltageRating. and actions between the entities of a system. 3-12 . Actors that are software processes are underlined. The Electric class has attributes for Impedance. every model would be overly complex for the software that uses it. the sequence diagram shows the information or messages exchanged among actors. 3. events. If we didn’t do this. To paraphrase. a sequence diagram shows different processes or actors involved in the scenario.3 UML Sequence Diagrams UML sequence diagrams are used to model the flow of messages. Dashed arrows with open arrowheads are response messages. wheels. Manufacturer. you have an understanding of UML class diagrams sufficient to read and interpret all of the CIM class diagrams used later in this report. Serial number. and TorqueCurve. solid arrows with open arrowheads represent asynchronous messages.4. but they each have associations. This is a good example of how the attributes of classes should be defined. The Engine class has two child classes: Electric and Combustion. The Automobile class has an aggregation association to a Chassis class and a Steering Wheel class. Solid arrows with filled in arrowheads represent synchronous messages. The Combustion class has two attributes: Cylinders and Fuel Type. The Engine class has several attributes: Horsepower.1. 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.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 timing sequence flows from top to bottom. The horizontal arrows have a message name written above them. such as the VoltageRating attribute of the Electric class. With horizontal arrows. The only difference is that the class diagrams in the CIM model have many more classes. One might ask why the Automobile class does not also have associations to doors. The attributes that are applicable to both electric and combustion engines such as Horsepower should be associated with the parent class. A message that originates from outside of the scenario diagram starts from a circle. If you can follow this example. The Motorized class has two child classes: Automobile and Motorcycle. and associations. our models should be just as complex as needed and no more. Through parallel vertical lines. Displayed horizontally at the top of the diagram are the applications or entities in the system. Time is represented vertically—showing the time sequence of interactions in the system. Neither child class has any defined attributes. should be defined at the child class level. Those that are applicable only to a particular type of engine. The Motorcycle class has an aggregation association to a Frame class and a Handlebar class. attributes.

2 eXtensible Markup Language (XML) The eXtensible Markup Language (XML) is a specification for creating markup languages. unambiguous communication of the information can be exchanged between computer applications and systems. By adding constraints.4. 3-13 . which are ways to encode both information and meta-information so that a clear. XML can be used to create “application languages”. XML can be used to define ontologies. HyperText Markup Language (HTML) and Standard Generalized Markup Language (SGML) are examples of well-known markup languages. For the purposes of the CIM. including Resource Description Framework (RDF) and Web Ontology Language (OWL). which are described in the next sections.Figure 3-5 Example Sequence Diagram 3.

4. the object denotes traits or attributes associated with the subject. The subject is defined by naming a resource. 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. Each expression is commonly called a “triple” in RDF terminology. much like the field of study in an academic environment.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). and associations that could be defined in a UML class diagram. a sub class of an Airplane class might be a SuperSonicAirplane class. The subject-predicate-object triplets takes the form of expressing syntactical constructs like “a person has a name” or “a car has four wheels”. Rules: an if-then statement that describes the inferences that can be drawn from an assertion. i. A domain can be thought of as one field or area of specialty. or electrical engineering.1 km/h. an ontology in the domain of chemistry would model the "base: the opposite of an acid" meaning.e. The predicate and object are also technically URIs and so also are just identifiers. and an ontology in the domain of electronics would model the “base: one of the regions of a bipolar junction transistor”. or resource. RDF and OWL described in the next two sections are both Ontology languages used in the CIM standard and by CIM software tools. Axioms: Assertions and rules that together comprise the overall theory in the domain. medicine.. the maximum speed attribute can be restricted to be not less than 1. political science. 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.3 Ontology Definition An ontology is a definition of concepts and their associations within a particular domain. For example the word “base” has many different meanings. The ontology represents the particular meanings of terms as they apply to that domain. 3. The subject. attributes. Ontologies are commonly encoded using ontology languages.4. 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. and Events: the changing of attributes or relations. RDF is based upon the idea of making statements in a subject-predicate-object expression. and using a restriction. and the predicate expresses the relationship between the subject and the object.225. As an example. 3-14 . in an RDF model is expressed as a Uniform Resource Identifier (URI).3. 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 definition of a concept in an ontology starts with a definition of the classes.

3-15 . and relationships of an information model and typically use an . These describe the rules and restrictions in a formal syntax. Within an RDF or RDFS file. The first is an XML format. Individuals are similar to the constructs of a class diagram.xml extension. This format is often called simply RDF because it was introduced as part of the W3C specifications defining RDF. attributes.xml or . In this format each URI is tagged in XML style. unlike UML Class Diagrams or standard RDF. 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.rdf extension rather than an .rdfs extension. Turtle stands for Terse RDF Triple Language. Using OWL to express a full ontology is done by defining “individuals” and “property assertions”. 3. The CIM community also uses the Turtle format which is a minimal form of the N3 format.xml or . RDF Schema (RDFS) files describe the classes.RDF actually can be expressed in more than one syntax. and the file is given an .rdf extension. The SPARQL Protocol (a query language for RDF) uses a derivative of the N3 and Turtle syntax. it is important to note the XML format is not the same as the abstract RDF model itself. The second is the Notation 3 (or N3) as a non-XML format of RDF models designed to be easier to read and write. and typically use an .5 Web Ontology Language (OWL) Web Ontology Language (OWL) is a language based upon RDF that is capable of fully expressing ontologies. RDF instance files describe object instances and typically use an . and the property assertions are based upon axioms.4. This is covered in more detail later.rdf extension. However. There are two common file formats used for RDF. RDF incremental files describe changes to a set of object instances as described by an instance file.

These documents are created from a UML model. Even though the 61968 series covers the distribution sub-domain. the CIM standard expresses profiles only in textual documents. which is available in electronic form from the CIMug that can be loaded into one of several different UML modeling tools. The CIM information model is defined in UML and commonly exchanged using XMI files. it is necessary to understand the 61970 transmission subdomain first because the 61968 standard is based upon the 61970 standard. there are the packages that are part of the 61970 series of standards and those that are part of the 61968 series. because it allows axioms that place further restrictions on the model to be defined. 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. 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. 3. In this case. Profiles are commonly defined in OWL.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. instead of UML or XMI. their attributes. called profiles. (The latest-and-greatest CIM model is kept in Enterprise Architect. the use of the English language as the definition syntax in these documents limits the precision and requires someone to interpret the language. However. and their associations.) The UML class diagrams are composed of packages that describe a unique sub-domain of the information model. 3-16 . Each package contains a set of classes along with their inheritance structure. which has a free viewer available. Officially.OWL is used by some CIM tools to specify subsets of the full information model.

The attributes of IdentifiedObject include mRID. but rather to provide highlights of key concepts. This class is very abstract and only contains attributes used to reference the object either by a user or in software. which is the master resource identifier that should be a globally 3-17 .1 IdentifiedObject The Core package contains a class called IdentifiedObject.6 Relevant 61970 Packages This section describes the relevant 61970 packages including Core. The intended purpose is not to describe every class. Figure 3-7 The CIM Core Package 3.6. attribute. Topology.6.3.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. and Wires. This should enable the reader to read and explore relevant parts of the CIM on their own. 3. and association.1.

The PowerSystemResource class supports an association to a Company class.2 The Topology Package The Topology package is used to define the interconnection between any class that inherits from ConductingEquipment.6.. These three classes inherit from EquipmentContainer.6. Bays and Voltage Levels The Core package also contains three classes that are used to model the aggregations of equipment: Substation. and the inability of other software systems to manage uniqueness. This is the parent class for most of the physical equipment that are used to model the power system. aliasName. 3. and they can be used to construct a hierarchy of objects where equipment is contained in a voltage level. This relationship identifies the company that operates the resource. there are no constraints on these names requiring them to be unique.1. 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.6. However.2 PowerSystemResource The PowerSystemResource class inherits from IdentifiedObject and provides another relatively abstract class used in the CIM.1.3 Equipment and ConductingEquipment The ConductingEquipment class inherits from an Equipment class which inherits from PowerSystemResource.6.1.4 Substations. this hierarchy may be required in certain application sub-domains such as transmission applications that exist in an EMS. For these reasons. and VoltageLevel classes. the mRID does not have to be human-readable.*. 3.. which is contained in a bay.6. Bay. 3-18 . The attributes name. It is common for names of objects within a utility to not be unique due to historical naming conventions.5 Terminal Any object inheriting from the class of ConductingEquipment has a relationship to an object by the class of Terminal.1.unique identifier of objects. This identifier is generally intended to be used by software systems. This relationship has a multiplicity of 0. This relationship is actually defined in the Core package but only utilized in the Topology package. and pathName are intended for providing identifiers that are human-readable. description. which is contained in a substation. 3. but typically it will be one or two terminals depending upon the specific class. 3. the results of mergers and acquisitions. This is essentially the wiring diagram of the model. 3.

which are then connected to ConnectivityNodes. 3. The terminals can be thought of as being closely related to the conducting equipment.6. This aggregation is done with the relationship between TopologicalNode and ConnectivityNode.2.6. and switches. 3. transformers.6. 3-19 .2. The lines part is has classes that define electrical lines.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. Each ConductingEquipment object has Terminals.1 ConnectivityNode The ConnectivityNode class has a relationship to the Terminal class. either AC or DC.Figure 3-8 The CIM Topology Package 3. and the connectivity nodes are the glue that defines what equipment is connected to what other equipment.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).

1 Conductor Directly inheriting from ConductingEquipment is the Conductor class. Multiple ACLineSegments are aggregated into a single ACLine object.3.6. WireArrangement.6.2 ACLineSegment and DCLineSegment Inheriting from Conductor are the two classes: ACLineSegment and DCLineSegment. This class contains the electrical attributes commonly associated with a line needed for steady state analysis. 3. conductance.6.3.Figure 3-9 The Wires Package . 3-20 . including the positive-sequence and zero-sequence resistance.3 ConductorType. and susceptance. and WireTypes Additional information about each line segment is described using associations to a class called ConductorType.Lines 3.3. reactance. 3. which has relationships to WireArrangement and WireType.

and other devices that can be open or closed. The transformer model is broken down into several parts: the transformer itself. 3-21 . The TapChanger class inherits from the PowerSystemResource class instead of the Equipment class.4 The Wires Package – Part 2 Transformers Transformers are also part of the Wires package. The TapChanger class has as attributes for things like the tap steps and nominal setting. Figure 3-10 The Wires Package – Transformers 3. TransformerWindings. and TapChanger The PowerTransformer class inherits from Equipment (not ConductingEquipment) and has associations to the TransformerWinding class. 3.6. the windings.4.6.5 The Wires Package – Part 3 Switches The third major subsection of the Wires package contains switches. fuses. and the tap changer. An association from the TransformerWinding class to the TapChanger class is used when the transformer has a tap changer. The majority of the electrical characteristics associated with the transformer are actually associated with the associated TransformerWinding objects. so it has few inherited attributes and associations.3.1 PowerTransformer.6. This is the section where you will find the breakers.

3-22 .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.1 Switch The Switch class inherits from ConductingEquipment. It also has an association to the CompositeSwitch class. where one switch closes when the other opens.6. which is used to define a group of switches that operate in a coordinated manner such as a “throwover” switch. 3.6. Specific switch attributes include a flag to indicate if a device is nominally open.5.Figure 3-11 The Wires Package – Switch 3.

It also describes the distribution software systems that are most relevant to each package. serial numbers. Operations.7 Relevant 61968 Packages This section describes the relevant 61968 packages: Assets. 3. and Work. purchase date.1 Assets Package The Assets package defines the attributes and relationships that are commonly part of an asset management program. manufacture date. Figure 3-12 The Linear Assets Package The Asset class includes a large number of attributes that include manufacturer. etc.7. The Asset class contains an association to the 3-23 .3.

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

3-24

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

3-25

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: • • • • 3.8 WorkTask to MaterialItem WorkTask to LaborItem WorkTask to EquipmentItem WorkTask to OverheadCost 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.
3-26

3-27 . attributes.The CPSM profile is tested as part of an annual interoperability test sponsored by EPRI. 3.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.8. At this interoperability test.8. The CDPSM profile is defined in the IEC standard document 61968-13.8. which is similar to how the dynamic parameters are handled in the vendor-offered dynamic stability packages. 3. sample models in CPSM format are exchanged between all of the major EMS vendors.5 CDPSM Profile Of most interest to the audience of this report is the Common Distribution Power System Model (CDPSM) profile. 3. The CDPSM profile is very similar and modeled after the CPSM profile. and power flow and state estimator results are compared to validate the models have been correctly interpreted by the EMS products.epri. 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. which defines the subset of classes. The dynamics models will require an additional modeling package that associates back to the static model.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 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. The most recent test reports can always be found by searching the EPRI site.com/docs/public/000000000001012494.pdf. Planning models make use of the TopologyNode class to define a bus-based model that is a topological reduction of the node-breaker model. and associations necessary to execute several DMS applications.

Within the EMS marketplace.) 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. The OPC foundation standards provide a well-understood approach for transport layer communication that is widely used in many automation applications (manufacturing. The most recent test reports can always be found by searching the EPRI site. there are vendors who offer GID-based connectors that can be connected directly to other applications. etc. 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. It also gets closer to achieving the objective of plug-and-play integration. these are called the Component Interface Specification (CIS). some of the configurability and adaptability to different business processes is not present when using GID-based adaptors.com/docs/public/000000000001012494. The existing implementations today typically leverage a set of standards from the OPC foundation (open connectivity via open standards).pdf. 3. 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. The GID definitions do not specifically include transport layer definitions. In IEC terminology. These GID based connections are also tested as part of the interoperability testing sponsored by EPRI.epri. essentially a direct connection between two applications rather than through an intermediary piece of software. The GID is defined in the IEC 61970-4xx series of standards. 3-28 . However.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. 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.This profile has also been tested in interoperability tests of DMS applications sponsored by EPRI. process control.

“Using a Common Infrastructure and Language to Integrate Applications at Florida Power & Light”. Passin. due to the process control nature of the OPC standards. Issue 2.F. 3-29 .. 488) 17-19 April 2002 Page(s):136 – 141 7. Mauser. Shephard. 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. 8.871 vol. May 2005 Page(s):758 – 764. deVos. S. The OPC Foundation (http://www. but today it is available as a cross platform technology including web services and SOA. “CIM-based standards and CIM evolution”.10 Further Reading 1... Proceedings. “Information exchange standards for power system monitoring and control”. pp 13 – 20 2.. Podmore. Fifth International Conference on (Conf. A Desktop Quick Reference”. Sinan Si Alhir.• OLE for Process Control (OPC): Data Access. Britton. Nordell. Berry. Volume 2. ”Utility information integration-vision. DRPT 2000. “Standards Based Approach Integrates Utility Applications”. preventing any silos from being formed.P. Schneberger.N. “Standards for energy management system application program interfaces. S. B. T. Power Systems. IEEE. OPC started as a standard that was based upon Windows specific technology called OLE. No. Berry. D. D. Manning Publications: 2004. Falk. Power System Management and Control. O’Reilly: 2005. H.. Becker.opcfoundation. 13. Lee. 6.org) developed application programming interfaces to enable plug and play of applications and drivers called OLE for Process Control (OPC). Publ. Brown. The OPC community is dominant in the industrial automation and process control industries providing connectivity to hundreds of automation applications. 9. 4 10/2000. Thomas B. Mauser. 2000. The SOA and ESB technologies are explained in more detail later in this report. 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. System Sciences.. G.T. It is technically feasible to bridge the GID adaptors to the enterprise integration platforms. and status”. benefits. 2002. For this reason. “Explorer's Guide to the Semantic Web”. “The EPRI common information model for operation and planning”. J. Robinson.. Power Engineering Society Summer Meeting. “UML in a Nutshell. However. No. J. DistribuTECH 2001. Gillerman. R. strategies. T. IEEE Computer Applications in Power. Jan 4-7 2000 Page(s):6 pp. 18-22 July 1999 Page(s):866 ... A. Alarms & Events.2 3. S. Proceedings of the 33rd Annual Hawaii International Conference on. Electric Utility Deregulation and Restructuring and Power Technologies. L. Gillerman. International Conference on 4-7 April 2000 Page(s):156 – 161 4. D. 1999. IEEE Transactions on Volume 20. Vol.. Historical Data Access. J. 2000. 3. 5.

907 vol. 2001. Schulz.. http://www. de Vos. J.. 29 2006-Nov. “Representing Business Data Semantics In CIM using UML”. http://www. Power Systems Conference and Exposition. “CIM extensions for electrical distribution” Power Engineering Society Winter Meeting. McMorran.. PSCE '06. S. Alan. 13.10.-1 Feb. A. Xiaofeng Wang.2 14. XML for CIM model exchange. Issue 3. Ralph. http://cimphony. Powers. Neumann. “An Introduction to IEC 61970-301 & 61968-11: The Common Information Model”. Shelley. IEEE. “CIM extensions to electrical distribution and CIM XML for the IEEE radial test feeders”.org/prevconf/2006/CD2/Introduction%20to%20the%20CIM%20Users %20Group. Innovative Computing for Power . O'Reilly: 2003.. 2006 IEEE PES.pdf 16. “Introduction to the CIM Users Group”. PICA 2001.org/prevconf/2005/EMS%202005%20GID%20%20Web%20Service. 2001. N. Power Industry Computer Applications. Power Systems.org/cimphony/cim-intro.pdf 3-30 . The CIM Users Group. 22nd IEEE Power Engineering Society International Conference on 20-24 May 2001 Page(s):31 – 37 12. Van Ausdall. “Practical RDF”. Mackiewicz. presented at the 2005 EMS users conference. 2006.N. Oct. Aug.Electric Energy Meets the Market. Xiaofeng Wang.emsusers. Volume 2.. 1 2006 Page(s):480 – 486 11. IEEE Transactions on Volume 18. S. S. 28 Jan..emsusers. 2001 Page(s):904 . Zhu. 2003 Page(s):1021 – 1028 15. “Applying the Generic Interface Definition (GID) in a Web Services Environment”. S..pdf 17. presented at the 2006 EMS users conference. Neumann. Widergren.E.

however. and almost every integration activity will be slightly different. 4-1 . The process is not unique. a CIM based integration effort will involve multiple systems each with multiple information flows into and out of each system. For this reason. a use case describes a typical scenario of use of the software to be designed and constructed. the basic steps will be similar. 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 are one of the UML standard diagrams. In the simplest terms.1 Build the Use Cases Create the Sequence Diagrams Build the Domain Model Design the Messages Design the Interfaces Construct the Interfaces Manage the Artifacts Use Case Overview A very popular approach to doing software engineering is to use a methodology based upon the development of “use cases”. use case diagrams are one of the standard diagrams that are part of the UML language. the steps of the process are as follows: • • • • • • • 4. As a brief introduction. Typically. Use Case Overview diagrams paint a broad picture of the system’s context.4 INTEGRATION PROCESS This section describes a typical process used for integration.

as part of the standards process. Because of this. which relate to many of the objects in the IEC 61968 information model. and the use case overview can be built in conjunction with the detailed analysis. You can leverage use cases from other utilities that have used the CIM information model. When beginning the analysis. more use cases exist for this domain. 4-2 . in a CIM-based integration project. 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. especially one in the distribution area. and where they are available. use cases were not part of the methodology used in building the standard information model. you can leverage ones from the standards community. the details of the use cases can be filled in. you don’t need to start from scratch in building your use cases and use case overview diagram. Since the distribution extensions were started later. when the IEC 61970 was being developed. Once the list is built.Figure 4-1 A Use Case Overview Diagram from the IEC 61968 Standard Initially. Today. each new addition to the information model is submitted with a use case.

but it is the actual system that the requirements are being gathered for. However. 4-3 . but the use cases need to be reviewed and factored into the actual software requirements. Many software development organizations may have standards for what a software requirements document should contain.1. As the use cases are being developed. it is usually necessary to build a “database” that maps each use case step to the associated requirement(s). and the diagramming step can be omitted as long as a detailed use case document is produced. in larger projects.1. 4. Some practitioners find that the diagram itself is not strictly necessary. it could be a database or even an off-the-shelf tool specifically designed to track requirements to use cases. this is going to be the integration software. This standard was developed before the adoption of use cases became prevalent. the goal should be something that the actor needs. not just a task the actor performs. the standard does contain a section called “stimulus/response” that is functionally equivalent to a use case.2 Use Case Definition There are three standard parts of a use case: 1. This is not a system that might be defined as an actor. There should not be a requirements document for each use case. 2. To summarize the fundamentals. 3. In other words. By doing this. so explicit references to use cases are not described in the document. this database could be a simple spreadsheet. but if a standard doesn’t exist.4. the IEEE standard 830-1998 is a good place to start. 4. In most integration use cases. In the software integration case. In all but the simplest cases. In smaller projects. Who are the actors involved in an integration? It is perfectly acceptable for actors to be other software systems rather than actual end users. The goal or objective is what the actor(s) achieves using the system. One use case step may map to multiple requirements. A description of the actors involved. it is possible to verify that complete coverage of all of the use cases has been met.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. sometimes called the Integration Layer (IL). the two key questions to ask are (1) who will be using the system and (2) what objective will they achieve by using it.2. this will be the case. so the standard can easily be extended to be compatible with use cases. A definition of the software system being used. An actor is a type or class of user involved.2. a complete set of requirements analysis documents should be produced in conjunction with the use cases.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. and one requirement may meet the needs of multiple use case steps.

the more detailed information in the use case can be filled in. 4. if you were not following a use case based process. The detailed information contains the following information: • • • • • Preconditions – The expected conditions that must exist for the use case to begin. 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. Similar to how use cases form the cornerstone of the requirements analysis process. Thoughtful and detailed analysis can help avoid missed requirements that cause unforeseen problems later. • By analyzing and filling each of these sections in a use case template. Steps necessary to achieve the Success End Condition – The step-by-step process that must be taken to achieve the end objective.…” suffixes to the main scenario steps where the extension occurs. Success End Condition – The expected end state that occurs upon successful completion of the use case. The steps are usually numbered with “a. or what happens when the system doesn’t accept a request because it is not valid. 2. The steps are usually numbered sequentially as “1.b. 4-4 . Failed End Condition – The expected end state that occurs when the use case fails. For this reason.c.3 Sequence Diagram Creation A sequence diagram is a form of a UML diagram that shows how processes and actors interact between each other. …” Extension steps – Extension steps are referenced to the step numbers in the success scenario that occur when something fails. The timing and interactions between systems and the integration layer is a critical detail that must be specified.2.4. Trigger – The event or stimulus that initiates the steps in the use case. For instance. sequence diagrams can form the cornerstone of the detailed design process.3 Use Case Details Once the high-level definitions are complete. the analyst is forced to consider all of the critical aspects of the system that are needed to build a robust system. sequence diagrams are very valuable when doing integration projects. it is easy for users to overlook scenarios based upon failures—like what happens when an actor isn’t authorized.1. 3. clearly indicating the order and timing of the interactions.

The sequence of time goes from the top of the diagram to the bottom. which could be software systems. For instance. or users. and they are the first place design decisions are applied. The use case being documented is one that involves removing an old meter and replacing it with a new one. The actors are shown across the top of the diagram.Figure 4-2 An Example Sequence Diagram The sequence diagrams should be relatively easy to construct based upon the use cases. and Meter Asset Management (MAM). the actors involved include the Customer Information System (CIS). the Meter Data Management System (MDMS). and arrows between the different actors show the interaction between the actors. it might be determined that one system needs to provide the same or similar information to three different systems. Work Management System (WMS). 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. When the interaction is between two software systems. as part of the design process. the Metering System (MS). physical systems. the message verb is shown capitalized and the message noun is shown inside of the parentheses. 4-5 . yet one consumer needs the information daily and the other two need the information hourly. In the example sequence diagram shown in Figure 4-2.

and read. and the WMS will update the MDMS. Then the same thing is done for the receiving system(s). configured. The WMS will schedule the work. In the use case. Figure 4-3 A Diagram Representing the Domain Modeling and Message Construction Process In the CIM-based approach. 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. This mapping is best represented as a profile. the old meter will be read and removed. the message content needs to be defined. and the new meter will be installed. and once the work is performed.4 Domain Modeling For each message identified in the sequence diagrams. The process is called “domain modeling” or “context modeling” because what is being done is the 4-6 . 4. and associations that can be produced by the producing system to the CIM model. attributes.The use case begins with a meter service request being generated in the CIS that is passed to the WMS. the process involves mapping the classes. the CIS will then update the MAM. We would probably select one system as a point of reference and map the other one to that. Completion of the work on the metering system will result in the WMS being updated and the CIS being updated.

association. Generally. However.. A word of caution is appropriate at this point. Things that are named the same might not actually be the same. things with very different names might actually be the same thing. just as the mappings from the core CIM are made. The verbs are different depending on the pattern used for the messages (i. In the IEC 61968 standard.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. in the CIM. 4. each attribute. you have to follow the association from transformer to transformer winding and then use the voltage rating (ratedU) attribute. it is a simple attribute of the transformer. So what happens when it isn’t there? In cases where an equivalent item cannot be found in the CIM. Note that in profiles and domain models. In the sending system. the high-side voltage rating of a transformer might be needed in a message. However. and class has a detailed descriptive definition in the model that can be reviewed. Within the CIM. the voltage rating is actually an attribute of the TransformerWinding class. The “payload” is the terminology for the actual data being passed from one system to another. you have to know that to find the high-side voltage rating. you can use the same payload in a message that is going to create an object as one that changes an object. Publish/Subscribe). a payload can be reused in several messages depending on what is being done with the data. then the contextual mapping from the CIM extensions can be made.creation of a definition of the needed content from the information model within a particular context or domain. When doing domain modeling. there is no high-side voltage rating. extensions are not allowed—extensions are made in the information model layer. Conversely. So. The following is an example of the verbs defined in IEC 61968. For instance.e. Looking at the CIM Transformer class. It is easy to do a quick look and conclude what you are looking for is not in the CIM. a predefined set of message verbs has been defined that describe the actions that can be performed. Request/Reply: • • • • CREATE CHANGE CANCEL CLOSE 4-7 . then the mapping is appropriate. 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. Request/Reply vs. so it might be concluded that it doesn’t exist and the CIM must be extended. Once the needed extensions are made at the EIM layer. care must be taken to ensure that the definitions are really the same. For instance. an extension should be added to the base CIM(s) defined in the Enterprise Information Model (EIM). 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.

IEC 61968 has also defined a standardized envelope for use with CIM-based integration.• • • • 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”. and a header. the data. The envelope is essentially a holder for the verb. the noun. and this envelope should be used for all messages. 4-8 .

This is especially true when parsing RDF because while XML is a message and file format the integration tools are well versed in. certain designs will require some code to be developed. none of the integration tools at this time natively understand RDF. and the design process is a matter of selecting a design pattern and documenting the configuration parameters. Many of the integration technologies in use today are highly configurable. Even with these configurable tools.6 Interface Design Once the messages have been designed. constructing a message involves (1) defining the payload based upon a profile specified against a domain model. To design the adaptors. there would be one adaptor built for each system that is connected to the integration layer. the actual interface adaptors need to be built. There are open source toolkits that are designed for use with RDF and the RDF query 4-9 . Typically. 4. (2) defining the appropriate verb associated with the message type. and message designs need to be studied so that the adaptor design can be produced. the requirements analysis documentation.Figure 4-5 An Example Showing the Message Envelope along with the Verb and Payload Contents In summary. It is important to note that the adaptor design will be specific to the actual integration technology used. and (3) putting the payload and verb into the message envelope. sequence diagrams.

language SPARQL. 4-10 . Construct the components that perform the validation. The major steps in the task are as follows: 1.) 3. 5. 4. 2. and translations. Perform unit testing. Put the interface code. Configure the integration tool based upon the parameters and design patterns documented in the design and sequence diagram. 4. transformation. (This may either be in the integration tool environment or in a traditional language. debugging.7 Interface Construction Constructing the interfaces based upon the design should be relatively straight forward if the design documents are done properly. Additional detail on the available integration technologies and design patterns is given in the Section 5 of this report. message definitions. This is the recommended approach when dealing with RDF that can’t be parsed by the integration tools. and resolution. and any files associated with the interface in a source code repository. Develop the processes that perform the logic documented.

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. all of the artifacts produced should be placed in a repository for future reference. Examples of repository technology that could be used includes the following: • • • • • Microsoft SharePoint Open source Wiki Commercial Wiki Document management system Source management system 4-11 . For this reason.Figure 4-6 A Typical Integration Development Environment that could be Used to Construct an Integration Adaptor 4. this repository should have some sort of version management so that a history of all the changes is maintained as the integration evolves. Ideally.8 Artifact Management If the process described here is followed.

As mentioned in Section 3. It is also important to recognize that the CIM itself is subject to change.) 4.The following is a list of the artifacts that should be placed in a repository and maintained as the system evolves: • • • • • • • • • • 4. the designer extends the CIM model by adding a new attribute. The CIM model extension is required and acceptable in such a situation. This process requires mapping of classes.9 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 Managing CIM Extensions The IEC CIM is used as an enterprise information model to provide a basis for design artifacts. There can and will be information that is unique to a particular utility and its specific software systems. and extensions required for local needs that are company or project specific. During the process of domain modeling. where new standard CIM versions are typically augmentations of previous versions. attributes.9. class . or association. 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 4-12 . There are many approaches to extending the CIM. When an appropriate equivalent CIM class. and associations of source and target systems. or association is not available in the CIM information model. interface message content is identified. (Refer to Figure 4-3. the CIM covers the common information that is typically used in the information flows between systems in a generic utility. The CIM extensions need to be managed efficiently to avoid future complications resulting because of various versions of the CIM extensions.) The model can be extended for following reasons: • • vendor-specific and or proprietary features that require model extensions. and this section gives an overview of a flexible approach that can be realized using a combination of freely available and low cost tools. attribute. (Extensions that are widely useful are good candidates for formal adoption in a future CIM version.1 Extension Management Until now. which will require extension to the information model.

which provides a link to the base model. in order to add a new attribute ‘y’ to an existing CIM class. In this example. The example below gives an overview of adding an extension attribute and class using the extension schema method. tagging of the extension elements. The pre-existing CIM class Switch is added to the extension model as a parent for the 4-13 .3 Extension Class As an example of adding an entire new class. the designer first adds a class of interest—referred as a shadow class—from the base CIM model to an extension model. the designer adds the extension class to the model in the extension schema. Moreover.cimtool. In this example.• • • • • Adding new classes (containing extension attributes) with 0|1:1 association to existing class Tagging of extension elements Using multiple inheritance. (The full definition of the Switch class remains in the base information model. the extension class SwitchX is defined with its attributes in the schema. the class of interest is the Switch class. The extension class name must not conflict with existing CIM class names.) The designer then adds a new extension attribute ‘y’ using CIM naming and type convention to the class of interest.2 Extension Attribute As an example. This approach also eliminates the need of re-entering or re-merging the extensions when a new official CIM version is released. then they do not affect the existing implementation. Figure 4-7 An Extension Attribute 4. using an extension schema is a recommended approach because it does not require a single logical model.9. it also provides end-to-end traceability.9. The extension schema method allows the designer to define more than one extension schema for the model. or use of multiple inheritance.org/) can merge the CIM standard schema and extension schema automatically during the profile definition. 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. if extensions are defined as “optional”. 4. The freely-available open source CIMTool (http://www. where each extension schema could have its own namespace.

4-14 . the CIM class Switch is referred as a shadow class. It also added an extension class SwitchX with an attribute ‘x’. Figure 4-8 An Extension Class The above process extended base CIM Switch class by adding an extension attribute ‘y’. The extension schema is related to CIM model via the shadow class Switch. Just as in the extension attribute example earlier. which provides a linkage to the base CIM model. Figure 4-9 The Extension Model Figure 4-10 provides an overview of relationship between the standard CIM model and an extension schema model.extension class. The extension class SwitchX is a subclass of CIM class Switch.

9. Once the models are merged in XMI format. vendors.Figure 4-10 The Extension Schema Showing the Shadow Class 4. such as when an extension model was directly adopted or provided a basis for an extension to the standard CIM model. the profiles are created using CIMTool. and there are two options to merge the models: • • Logical Merge – The logical merging is done using the open-source CIMTool.9. 4-15 . The extension model created using an extension schema should be compatible with the new CIM versions.4 Impact of New CIM Versions Periodically. 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. There is a possibility that new CIM model can impact the extension models. where the merging of the models occurs automatically when an extension model is loaded. 4. The shadow classes in the extension model provide the logical linkage points between the base and extension models.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 merged models are in XMI format before and after the merge. 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. and utilities. the IEC will release new CIM versions based on input from the standards committee.

2001 3.4.3 2. Zhou. Power Systems Conference and Exposition. Karl. Microsoft Press. “Software Requirements”. Wiegers. not directly with each other”.. Alistair. Robinson.. G. “Utility applications should be integrated with an interface based on a canonical data model. M. 2004. “Writing Effective Use Cases”. 2004 Page(s):1592 . Addison-Wesley. 1999 4-16 . E. IEEE PES 10-13 Oct.J.10 Further Reading 1. Cockborn..1596 vol.

A key component of SOA is the concept of discoverability.1 Introduction This section provides a brief introduction to some common integration technologies. Web services is a term used to describe a specific method of implementing SOA.5 INTEGRATION TECHNOLOGY 5. By doing this. Discoverability is where software systems can dynamically “discover” services that are exposed by looking in a directory or registry. 5. Web services implement SOA by making the services accessible over standard Internet and World Wide Web protocols. The term service refers to the encapsulation of the business process into an atomic interface that can be invoked remotely.2. connect service. place bid. well-established communication protocols are used to expose the software services. platforms. 5. Building applications is done by connecting the services together into business flows through a technique called orchestration. Business processes can be thought of as specific tasks that a business conducts such as take order. create new customer. a bit of history of integration technology. These interfaces encapsulate business processes. and implementation languages. SOA is the foundation for some of the other integration technologies described in this section.1 Definition of SOA SOA is a set of guidelines for loosely coupling a modular set of well-defined functional interfaces. 5. A key characteristic of this approach is that by the very nature of using web protocols. XML is used heavily in SOA to create data messages that are passed to and from these services. and an overview of how the technologies can be utilized with the CIM.2 Service Oriented Architecture (SOA) A technology called Service Oriented Architecture (SOA) is gaining wide acceptance in the IT industry today. 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). 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.2. etc.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 5-1 . the services are independent of software operating systems.

software integration. One key advantage is that by using SOA for traditional application integration. Before SOA After SOA Outage Management System Work Management System Outage Management System Work Management System SOA Services/ESB Customer Information System CIS Vendor 1 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. The SOA implementation will provide a platform of common technical and business services such as auditing. Typically. the orchestration process is not strictly necessary. orchestration can be used to build applications that fill in gaps not provided by the legacy applications. 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. 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. or integrate IT systems. For example. form new operating companies. By using this approach. disparate information systems may serve the same functional area. and data archival. SOA implementation is best started with business process improvement initiatives where a utility may focus on one or more business functional 5-2 . security. This provides for greater business flexibility and adaptability as business processes change in unexpected and unanticipated ways after the applications have been deployed. As utilities merge.

In many cases. web services. The ESB does not implement an SOA. which leverages previous-generation EAI technology and web services. demand management etc. 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.area transformations such as customer service. A key characteristic is that ESB technology is distributed.3 Enterprise Service Bus (ESB) A technology called the Enterprise Service Bus (ESB) is commonly used today in the integration of IT systems. the vendors were able to take existing products and retool them to be true ESB platforms. Consumer A Consumer B Consumer/Provider C Interface C1 Enterprise Service Bus Interface X1 Interface Y1 Interface Z1 Interface Z2 Provider X Provider Y Provider Z Figure 5-2 A Diagram Representing an Enterprise Service Bus An ESB is loosely related to SOA principles. it is more than just a software architecture. ESB is specific software that can be implemented. making it scalable for enterprise wide integration. reducing outage duration. 5. however in contrast to SOA. ESB technology was first introduced in 2002 and has been adopted by many integration vendors. but it provides the capability to implement the SOA. and reliable transactions. The ESB is a software infrastructure that provides application integration and flexible reuse of the business components within an SOA. transformation. An ESB is a standards-based integration platform that is a combination of various types of messaging paradigms. The ESB is an enabling technology to achieve coherent Enterprise Integration Architecture (EIA). routing. 5-3 . The ESB concept is the next generation of integration middleware. This technology has been successfully deployed by many enterprises in different industries.

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. It is human-readable. IBM WebSphere Message Broker Artix ESB iWay Service Manager Oracle Service Bus part of Oracle SOA Suite. Security and Systems Management: The capabilities of system management tools and the ability to comply with future security restrictions. XPath. It is easily parsed by software. Configuration Environment: The usability of GUI configuration and development tools. BEA Aqualogic ESB webMethods ESB Progress Sonic ESB Java Composite Application Suite (CAPS) (formerly SeeBeyond) ActiveMatrix Service Bus Business Accelerator ESB 5. Business Process Automation: The ability to model and automate business processes that span multiple applications.1 XML Foundation XML is the language used for representing data in the ESB architecture.3. 5-4 . and support for services levels such as guaranteed and transactional messaging. Table 5-1 shows a partial list of ESB vendors and products. Messaging Layer: The ability of the transport layer to support Publish-Subscribe and Request-Reply messaging.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. including user authentication and encryption.1. Data Mapping and Routing: The ability to perform data transformation and intelligent routing to multiple destinations. XML has many benefits: • • • It is a rich data model allowing for many data types to be represented. Table 5-1 Partial list of ESB vendors and products Vendor IBM Iona iWay Software Oracle Software AG Sonic Software Sun Tibco Vitria Product(s) IBM WebSphere ESB.

The document also includes sample XML and WSDL.2 Message Oriented Middleware (MOM) A key component of the ESB architecture is the use of Message Oriented Middleware (MOM). but it has not gained wide acceptance because it was not coupled with the other important technologies that are now part of an ESB. queues. tracking.3. and the use of channels. Due to the extensibility. they are configured. 5. or topics. monitoring. programming languages.3. In an ESB.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. or topics depending on the vendor implementation. and the broad category of legacy applications. messages have certain reliability characteristics. providing a further degree of abstraction and loose coupling. 5.3. Much like the class diagrams discussed earlier. queues.3 Reliability In an ESB. “at most once”. Other variations of the store-and-forward mechanism of reliability are delivery options for “at least once”. and process modeling. Many EAI vendors who originally offered proprietary methods and solutions for the 5-5 . 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 not a fixed format data structure (both variable length data elements and variable number of fields are supported). This includes solutions for dealing with applications that run on different operating systems. queues or topics are not hard coded into the application—instead. MOM is a concept that has been around in the integration world for a while.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. Many EAI vendors that have been in the integration market for a relatively long period of time— pre-dating the ESB standards. database architectures. or topics can be organized into a hierarchy.1. the loose coupling is taken one step further because the actual channels. 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. the communication channels.1. The document covers topics such as ESB integration patterns. 5. 5. the common message structure. the use of SOAP. The bus concept is called channels. These include capabilities such as auditing. 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. queues. It is self-describing because XML contains the data elements names in the tags.1. and “exactly once” delivery. and they have capabilities and functionality beyond what is defined as an ESB. it is a really a subset of the EAI suite product market. it tends to not break (non-brittle).

the list of ESB vendors has grown to include most of the EAI vendors over time. For this reason. Oracle SOA Suite iBolt Netweaver PI webMethods Sun One Integration Server BusinessWorks M3O Suite 5. e-mail. However. there are a few “pure” EAI vendors who do not offer any ESB technologies. Table 5-3 lists some essential criteria. Table 5-3 Essential Criteria for the Integration Framework Criterion Application Description How it integrates with source and target systems • • • • • • Best-in-Class Attributes Standard database.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-2 shows a partial list of EAI suite vendors and products. proprietary EAI solution.core integration problem have replaced (or now provide alternatives to) the proprietary components in the form of ESB standards-based components. Support for industry standard formats and protocols Tools for validating data conformance to business rules Transformation How it translates data from source to target system 5-6 . Table 5-2 Partial list of EAI suite vendors and products Vendor IBM Microsoft Oracle Magic Software Enterprises SAP Software AG Sun Tibco Vitria Product WebSphere BizTalk Oracle Fusion Middleware. file. 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. and a few “pure” ESB vendors do not offer a traditional. and monitoring integrations Tools for wrapping integrations around legacy systems Libraries for custom integrations in a variety of environments Field mappings. type conversions. identifier normalization.

monitoring. and EAI integration suites should be reviewed and assessed based on the above listed criteria to achieve the CIM based integration. 5-7 . Simplifies change management and versioning Centralized integration cataloguing. or broadcast messages over IP Supports state-full. Table 5-4 provides an overview of most widely used integration technologies support for core criteria of the integration framework. high volume. Ability to encapsulate processes into composite services Minimizes custom code but is extensible. Provides debugging. and activity monitoring Orchestration Implementation Administration How it enables • managing a solution in production • • The widely used integration technologies such as Web Services/SOAP. definition. and simulation tools. ESB. process. multicast. Content and availability based dynamic routing. Reliable or guaranteed transactions with recoverability Point-to-point. and low latency. and discovery Centralized security. and exception management Business event. long-running processes. testing.Criterion Communication Description How it physically moves data from source to target How it moves data according to process rules How it enables developers to build solutions • • • • • • • • • Best-in-Class Attributes Synchronous or asynchronous.

6 Messaging Framework The middleware-messaging-based integration is considered an industry best practice.Enterprise Integration Suite Rationale Custom or out-ofthe-box proprietary integrations can be a good solution for simple problems. but also suffer from tobe-determined standards and general platform immaturity. easily bridging legacy environments with web services via proven integration patterns and open standards. Lacking Meets Exceeds 5. and lack central administration. EAI products are mature. Messaging provides interoperability between legacy and newly acquired modern enterprise 5-8 .Table 5-4 Integration Framework Technology Support for Core Criteria Criteria Application Transformation Communication Orchestration Implementation Administration Custom / Proprietary Web Services / SOAP ESB . but standards are in their infancy (or to be determined) and retrofitting legacy applications can be expensive. Legend ESBs bring central administration and orchestration to web services.Enterprise Service Bus EAI . do not scale well. so it is recommended that utilities review and adopt the messaging framework-based integration. but they are hard to reuse. Web services hold long-term promise for interoperability.

5-9 . The use of web services can be used instead of traditional point-to-point customized integrations. It also supports asynchronous event-oriented processing and mission critical communications. but using the ESB with process orchestration ensure correct routing of web-service enabled messages. where messages are not required to provide a reply in response to a request.systems. The ESB provides an infrastructure to support intelligently directed communication and mediated relationship among integrated applications as depicted in the diagram above. 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.

Figure 5-3 Adaptors Have Coupled Integration Methods 5-10 . which allows decoupling of the integration method. timing. When middleware is deployed.7 Integration Options A middleware platform allows decoupling of source / target integrations. the integration method is transparent to both the source and target systems.5. and processes. protocols. The diagrams below give two examples of various systems integrated using different methods.

there are many non-functional considerations that must be considered: • Do requests need to be authenticated and authorized? 5-11 . and middlewarebased integration can co-exist. Utilities should consider appropriate integration technologies after carefully reviewing each individual application’s requirements and the applications’ vendor-provided integration solutions. a single integration technology may not meet needs of all various applications. 5.Figure 5-4 Middleware Decouples Integration Methods As explained earlier. The web services.8 Other Considerations For each system and information flow. vendor-provided custom adapters.

just a template for how to design a solution to a particular problem.9 Integration Patterns Design patterns are general reusable solutions. cause a lot of rework. 5. the use of integration patterns can significantly reduce the cost and effort in performing integration because these patterns provide tested. designers. Successful designs require understanding many subtle issues that may not become visible until late in the implementation or even after deployment. Because the integration domain has a unique class of problems. proven development paradigms. fundamental architectural mistakes can be made that could. Integration patterns are specific design patterns for the integration of software applications and systems. cause a project to fail. They are particularly difficult to diagnose because the problems may appear as issues in a downstream system and not in the integration software layer. They are not components or reusable code. 5-12 . By reusing design patterns. but they are different in that they provide a solution to design issues rather than computational issues. Design patterns can be compared to algorithms. at a minimum. and coders who are familiar with the patterns. and in the worst case. Without clear answers to these questions. Design patterns can also be thought of as templates for the design of a piece of software. The use of integration patterns also improves documentation and code readability for architects.• • • • • • • • • • • • • 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. integrators can prevent subtle issues that can cause major problems.

Examples include the following: Message Routing: • • • Splitter Aggregator Routing slip Message Transformation: • • • Content filter Content enricher Claim check 5-13 . and system management. By implementing the common services using well-known integration patterns in the ESB technology being used.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”. reliability and maintainability can be improved further and costs reduced significantly when doing enterpriselevel integration. message transformation. Common patterns for integration cover issues in message routing. Many of them are applicable to the problems that occur when integrating distribution utility systems.

These standards can range from the simple standardization of desktop applications to back-office server technologies such as the use of operating systems.System Management: • • • Control bus Message store Smart proxy Common practice in integration today is to use integration patterns. the choice of languages such as Java or . Anyone embarking on an ESB-based integration of distribution systems should provide for the use of integration patterns and the development of common services.10. the use of Light-Weight Directory Access Protocol (LDAP). 5. and stop the service container itself. security protocols. 5. database platforms. start. and stop deployed components.10. In many cases.2 Implementation Technology Many integration products provide a “service container” for the execution of integration components. but before deciding or beginning any detailed analysis and design. XML. By deploying multiple service containers. 5. high availability and load balancing can be supported. proposed standard IEC 61968-1-1 Enterprise Service Bus Implementation Profile will leverage security standard technology as needed. within any large IT organization there is a set of IT standards with which to comply. start. these standards will impose some constraints on the types of integration solutions that can be pursued. Configure. Configure.10 IT Standards Generally.NET. Integration products also provide administrative tools to perform the following functions: • • • Deploy components to a service container once they have been implemented.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. The most common ones that can be used today are WS-Security and SSL/TLS. the integration team must review and be aware of the implications of these standards. Modern ESB platforms provide support and compliance with most potential IT standards. monitor. and even user interface design. 5-14 . monitor.

5.multispeak. Due to the plug-and-play design goal. queue overflow. Over time. MultiSpeak version 3 added additional message-based support and new applications. including IOUs and the international marketplace. MultiSpeak is a registered trademark of the National Rural Electric Cooperative Association. The following table goes into further detail on the comparison between MultiSpeak and CIM—it highlights some of the major information model differences.1. and thus it is also difficult to adapt to different business processes. 5. There are also modeling differences that make it difficult to perform simple translations between MultiSpeak and CIM.org) could be considered a “competing” specification for integration of software for distribution utilities. This has trade-offs that make MultiSpeak adaptors very close to plug-and-play. while IEC 61968 is focused towards all utilities. 5. the differences between the two are expected to be reduced. it is necessary to compare the two because. MultiSpeak has gone through several major versions that had different capabilities and used different technologies. generation. The stated goal of MultiSpeak is to achieve out-of-the-box integration for applications used by NRECA members.11. MultiSpeak could be a more suited messaging specification for a utility to adopt. NRECA has almost 1000 member electric cooperatives in 47 states. the MulitSpeak standard does not have a good mechanism for extending the information model.11 Comparison with MultiSpeak MultiSpeak ® (www. etc. 5-15 . IEC 61968 was designed to be transport-independent while MultiSpeak is transport-specific and based upon web services. For this reason.2 Comparison The CIM covers transmission.1. 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. but MultiSpeak is distribution focused. MultiSpeak is focused to meet the needs of electric cooperatives in the US.11. depending on the circumstances.Components can often be instrumented to permit detection of conditions of interest such as failures. which will enable even greater flexibility in integrating systems. MultiSpeak 4 will be released in 2009.1 MultiSpeak Background The MultiSpeak effort is funded by National Rural Electric Cooperative Association (NRECA). exceptions. From a technology perspective. but they are natively unable to connect to ESB infrastructures. there was no messaging defined. MultiSpeak version 1 focused on back-office applications and defined batch file data transfers between them. and distribution. MultiSpeak version 2 added support for both batch and message-based transfers.

SwitchBank) mspLineObject has GMLcomplex line and mspPointObject has grid location and rotation CIM Model managed with Enterprise Architect. may have multiple representations 5-16 . parent section) and node-oriented (from – to) connectivity Asset related attributes included within class definitions as needed or through simple grouping (e.Table 5-5 MultiSpeak and CIM Modeling Differences MultiSpeak Model Management Object identification Model managed using XML Schema with XML Spy objectId found in mspObject class mspObject is parent class for mspSwitchingDevice. and mspResultsBase. mspPointObject. where RDFS and XML Schemas are generated Naming class used to manage names for virtually all CIM classes Class Hierarchy Organized using packages. mspLineObject. Naming is parent for PowerSystemResource. where each ‘msp’ class may have subclasses Inheritance relationships and ‘Lists’ and ‘Banks’ for aggregations Supports both sectionoriented (section.g. mspDevice. whose descendant classes include Equipment and ConductingEquipment Relationships Wide variety of associations and aggregations are defined and managed in the model ConductingEquipment has terminals. which are grouped into ConnectivityNodes – does not support section oriented topology Asset model implemented where a PowerSystemResource can be comprised of one or more Asset instances Connectivity Asset Modeling Graphical Modeling Managed as an attribute of an instance..

outServiceDate. conductor information and load) (by the addition of rotating machine specific fields) mspElectricPoint motor generator (by the addition of phasing and load information) feederObject ohPrimaryLine ohSecondaryLine mspBankObject (by the addition of comments. and facilityID) mspLineObject (by the addition of GMLcomplex line) mspResultsBase (by the addition of engineering analysis fields) mspPointObject (by the addition of GML coordinate set. gridLocation. MultiSpeak mspSwitchingDevice (by the addition of switching specific fields. facilityID. See Figure 2-5) mspObject mspDevice (by the addition of deviceClass.The following class hierarchy diagram shows the MultiSpeak equivalent of the CIM UML class diagrams shown earlier in this report. and rotation) meter (by the addition of meter-specific fields) mspConnectivityLine (by the addition of from/to nodes or sectionID and parentSectionID) loadFlowResult shortCircuitAnalysisResult mspConnectivityPoint (by the addition of nodeID or sectionID and parentSectionID) mspMotorGenerator mspElectricLine (by the addition of phasing. See Figure 2-4) fakeNodeSection ugPrimaryLine ugSecondaryLine serviceLocation substation Figure 5-6 The MultiSpeak Class Hierarchy The following table outlines differences between CIM and MultiSpeak at the object attribute and relationship level: 5-17 . inServiceDate.

r0. ohSecondaryLine. mspElectricLine Conductor transformer. transformerBank PowerTransformer.Table 5-6 Comparison of CIM and MultiSpeak Object Level Differences MultiSpeak switchDeviceBank. x. r. ugPrimaryLine. g. TransformerWinding. x0 MultiSpeak identifies priVoltsLo. switch CIM Switch. g0ch Note that use of Conductor is very different in these models. MultiSpeak has ohPrimaryLine.secVoltsLo. priVoltsHi. x0. pcb MultiSpeak model currently more complete for AMR integration MultiSpeak model currently more complete for AMR integration Where MultiSpeak workOrder is focused on staking. 61968 has a much broader treatment of distribution work management OutageReport supports multiple steps and associated tracking of customers affected. with r. b0ch. secVoltsHigh. bch. r0. WindingTest. Asset CIM impedance model includes b. where each has a list of Conductors CIM Conductor has subclasses ACLineSegment and DCLineSegment. x. gch. Asset Key differences 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. ugSecondaryLine. customer Customer meter CustomerMeter workOrder Work outageEvent OutageReport 5-18 .

5. and Deploying Messaging Solutions”. Ali Vojdani.. “Achieving Reliability Objectives with the Aid of a Service Oriented Architecture”.MultiSpeak customerCall CIM TroubleTicket Key differences TroubleTicket tracks information needed for callbacks 5. K. Erl. G. 4. Tampa. O’Reilly: June 2004.. "Enterprise Service Bus". 2008 5-19 . Prentice Hall: 2004 2. DistribuTECH Conference Proceedings. S. “Applying Workflow Technologies to Integrate Utility Business Processes”. Building. R. “Comparison of the MultiSpeak Distribution Connectivity Model and the CIM Common Distribution Power System Model”. FL. McNaughton. Robinson. Neumann. Leonard. Hohpe. 6. 3. G. Bobby Woolf “Enterprise Integration Patterns: Designing. DistribuTECH 2005. O’Reilly: 2003. Chappell. Gregor. Shankar. Saint. Dave. Thomas.12 Further Reading 1. DistribuTECH 2005. “Service Oriented Architecture: A Field Guide to Integrating XML and Web Services”. B.

.

and Enterprise Service Bus (ESB) technologies. The utilitycentric information model called the Common Information Model can be used with industry best practices to reduce the cost and complexity of performing these integrations. Understanding CIM requires understanding key technologies such as UML. The number of interfaces rapidly becomes very large because there are so many needed areas of integration. 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. The GID subset of the standard is most applicable to the control-center-specific integration space. without establishing a methodology for managing the extensions. well-understood process for integration is desperately needed in the industry. A systematic. These include Service Oriented Architecture (SOA). The CIM is backed by key organizations including EPRI. or in some cases in ad-hoc fashion by desperate end users.6 SUMMARY Software applications in a distribution utility were typically built around departmental boundaries and were bridged by software built by the IT department. it is possible to get locked into a specific release of applications and the CIM standard. this situation becomes unmanageable because the software bridges are built by different people using diverse technologies. and OWL. and the IEC. RDF. and work. Practical considerations must be taken 6-1 . Business drivers and solid business cases can be built for doing integration this way. web services. assets. Because the CIM is used for various purposes. 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. 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. Inevitably. specific profiles are defined that describe a subset of the model that is applicable to those applications covered by the profile. however. XML. Using the CIM as part of an enterprise wide integration strategy requires selecting and utilizing one or more accepted technologies. The CIM is composed of packages specifically for representing electrical networks. IEEE.

but efforts are underway to make them more compatible. and no one technology is suited best for all situations. 6-2 . 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.into account when selecting one technology over another. A direct mapping between the two standards is not completely possible. MultiSpeak has little support for extensions (less flexibility than the CIM). whereas the CIM standard is designed to meet the needs of all utilities. but MultiSpeak leverages the fixed message specifications to achieve a higher degree of plug-and-play.

A TERMINOLOGY Term CDPSM CIM CIMug CIS CIS CPSM DMS DoS EAI EAM EIA EIM EMS EPRI ESB GDA GID GIS HSDA IEEE ISO IT JMS LDAP MDMS MOM mRID MultiSpeak MWM NRECA Definition Common Distribution Power System Model (IEC 61968-13) Common Information Model Common Information Model User Group Customer Information System Component Interface Specification Common Power Systems Model (IEC 61970-452) Distribution Management System Denial of Service Enterprise Application Integration Enterprise Asset Management Enterprise Integration Architecture Enterprise Information Model Energy Management System Electric Power Research Institute Enterprise Service Bus Generic Data Access Generic Interface Definition Geographic Information System High Speed Data Access Institute of Electrical and Electronics Engineers International Standards Organization Information Technology Java Message Service Lightweight Directory Access Protocol Meter Data Management System Message Oriented Middleware Master Resource ID Message specifications sponsored by NRECA Mobile Workforce Management National Rural Electric Cooperative Association .

Term OMG OMS OWL RDF RDFS SCADA SOA SSL TC TLS TSDA UML URI URL WG WMS WS-Security WSDL XMI XML Object Management Group Outage Management System Web Ontology Language Resource Description Format RDF Schema Definition Supervisory Control and Data Acquisition Service Oriented Architecture Secure Sockets Layer Technical Committee Transport Layer Security Time Series Data Access Unified Modeling Language Uniform Resource Identifier Uniform Resource Locator Working Group Work Management System Web Services Security) Web Services Definition Language XML Metadata Interchange eXtensible Markup Language A-2 .

us/CIMSpy21/download.altova.cimtool.com/products/xmlspy/xml_editor.ibm.uisol.us/ B-1 .html Power Info http://www.com.au/ CIMVian http://www.htm UISOL http://www.com/ XML Viewer/Editor CIM Modeling Tool CIM/XML Model Viewer CIM/XML Model Viewer CIMTool http://www.B COMMONLY USED TOOLS Tool Name Enterprise Architect Vendor Sparx Systems Description UML Modeling Tool UML Modeling Tool http://www.au/ Rational Rose IBM http://wwwhttp://www.com/ CIMSpy http://www.html http://www.com/uisol/CIMvian/CIMvian.altova.au/products/ea/index.html XMLSpy http://www.html Altova http://www.com.powerinfo.sparxsystems.sparxsystems.langdale.uisol.com/software/awdtools/developer/rose/index.com.org/ Langdale Consulting http://www.powerinfo.ibm.com 01.

C
LIST OF DISTRIBUTION RELEVENT IEC STANDARDS EFFORTS
Category Distribution Distribution Distribution Distribution Distribution Distribution Distribution Distribution Distribution Distribution Distribution Distribution Distribution Distribution Distribution Distribution EMS API EMS API CIM CIM CIS GID GID GID Standard 61968-1 61968-1-1 61968-1-2 61968-2 61968-3 61968-4 61968-5 61968-6 61968-7 61968-8 61968-9 61968-10 61968-11 61968-12 61968-13 61968-14 61970-1 61970-2 61970-301 61970-302 61970-401 61970-402 61970-403 61970-404 Group TC 57 WG 14 TC 57 WG 14 TC 57 WG 14 TC 57 WG 14 TC 57 WG 14 TC 57 WG 14 TC 57 WG 14 TC 57 WG 14 TC 57 WG 14 TC 57 WG 14 TC 57 WG 14 TC 57 WG 14 TC 57 WG 14 TC 57 WG 14 TC 57 WG 14 TC 57 WG 14 TC 57 WG 13 TC 57 WG 13 TC 57 WG 13 TC 57 WG 13 TC 57 WG 13 TC 57 WG 13 TC 57 WG 13 TC 57 WG 13 Title Interface Architecture and General Requirements Enterprise Service Bus Implementation Profile Naming and Design Rules. Glossary Network Operations Record and Asset Management Operational Planning and Optimization Maintenance and Construction Network Extension Planning Customer Support Meter Reading and Control Other Systems (e.g., ERP) CIM Extensions for Distribution Use Cases RDF Distribution model exchange (CDPSM) MultiSpeak Mappings and Profile EMS API Guidelines EMS API Glossary CIM Base (the core CIM) CIM – Financial, Energy Scheduling, and Reservations Component Interface Specification Framework Common Services Generic Data Access High Speed Data Access

C-1

GID GID GID CIM CIM CIM CIM CIM CIM CIM

61970-405 61970-406 61970-407 61970-450 61970-451 61970-452 61970-453 61970-501 61970-552

TC 57 WG 13 TC 57 WG 13 TC 57 WG 13 TC 57 WG 13 TC 57 WG 13 TC 57 WG 13 TC 57 WG 13 TC 57 WG 13 TC 57 WG 13

Generic Eventing and Subscription Program Invocation Time Series Data Access CIS Information Exchange Model Specification Guide SCADA CIS Transmission Network Model Exchange Profile (CPSM) CIM-based graphics exchange (SVG) CIM RDF Schema (CIM XML) CIM XML Model Exchange Format Format and rules for exchanging modeling information

61970-552-4 TC 57 WG 13

C-2

.

California 94303-0813 • USA 800. In the event you are uncertain whether you or your company may lawfully obtain access to this EPRI Intellectual Property. Together…Shaping the Future of Electricity © 2008 Electric Power Research Institute (EPRI). Electric Power Research Institute. and other leading experts to work collaboratively on solutions to the challenges of electric power.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. with major locations in Palo Alto. International participation represents nearly 15% of EPRI's total research. EPRI's members represent over 90% of the electricity generated in the United States. and environment. Although EPRI may make available on a case-by-case basis an informal assessment of the applicable U. you and your company acknowledge that this assessment is solely for informational purposes and not for reliance purposes.S. and foreign export laws and regulations is being undertaken by you and your company. and use. Palo Alto. export classification and ensure compliance accordingly. EPRI. and TOGETHER…SHAPING THE FUTURE OF ELECTRICITY are registered service marks of the Electric Power Research Institute. Charlotte. you acknowledge that it is your obligation to consult with your company’s legal counsel to determine whether this access is lawful. 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.S.3774 • 650.S. Tennessee. Palo Alto. Inc.313. This includes an obligation to ensure that any individual receiving access hereunder who is not a U. Inc. export classification for specific EPRI Intellectual Property. and foreign export laws and regulations. Printed on recycled paper in the United States of America 1016058 Electric Power Research Institute 3420 Hillview Avenue. citizen or permanent U. resident is permitted access under applicable U. 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. California. nonprofit center for public interest energy and environmental research.com .2121 • askepri@epri. was established in 1973 as an independent.epri. and demonstration program. including health. delivery. The Electric Power Research Institute (EPRI) The Electric Power Research Institute (EPRI). the Institute's scientists and engineers. safety.S. development.S. or foreign export laws or regulations. These solutions span nearly every area of electricity generation. participants.855. All rights reserved. California 94304-1338 • PO Box 10412.com • www. and Knoxville.S. North Carolina. EPRI brings together members.

Sign up to vote on this title
UsefulNot useful