> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) <

1

Abstract—The IEC Common Information Model (CIM) is

central to many existing interoperability standards as well as many interoperability standards being developed for the Smart Grid. Where ‘CIM’ itself is often a generic term often applied to an ontology for a given domain, the IEC CIM as currently defined by IEC 61970/61968 standards can be viewed as core to the Smart Grid. At the same time, the CIM alone is not sufficient for interoperability. There are several dimensions to the problem, including the existence of other ontologies, the variety of ways an ontology can be leveraged to define standard interfaces, and the depth of integration.

Index Terms— Common Information Model, Interfaces, Interoperability, Smart Grid

I. INTRODUCTION HE efficient and cost-effective integration of systems and devices is dependent upon the existence of interfaces that

offer an adequate level of interoperability. The interfaces may be proprietary or standards-based in nature, where the preference is obviously towards open standards. The IEC Common Information Model (CIM) as defined by the IEC 61970/61968 standard is a domain model central to many existing and future Smart Grid standards. The original and ongoing intent of the CIM is to provide a basis for the definition of interfaces that improve interoperability. Where the initial focus of the CIM was control center applications related to electrical transmission, it is being continually extended, growing in scope and coverage [1]-[3]. Coverage is now good, but still improving, for electrical distribution [4]-[6]. Subject areas such as dynamic and energy markets are also being addressed. From the CIM, many dependent standards are being defined that can be leveraged by products to improve interoperability. However, there are many ways the CIM can be used to define standard interfaces for information exchanges. The standard can be used to either directly interface components or enable integration through an integration layer, such as an Enterprise Service Bus (ESB). Fig 1. illustrates examples of the variety of supporting standards and technologies that can be used to define interfaces that range from the standards based to the customized.

T. D. Nielsen is with Utility Integration Solutions, Inc. (UISOL), Lafayette, CA, USA.

S. A. Neumann is with Utility Integration Solutions, Inc. (UISOL), Lafayette, CA, USA.

Fig. 1. Integration approaches from standard to customized

Standards do not always support plug and play integration [7]. While some do, as is especially important for the integration of devices, other standards may be more oriented towards enterprise integration where the corresponding standards can have varying degrees of specificity, to the extent that in some cases the ‘standard’ can only be used as a suggested guide for custom integration.

II. THE CIM IN A FEDERATION OF ONTOLOGIES The IEC CIM is but one ontology that may be encountered

when performing integration for the Smart Grid [8-9]. This recognizes the fact that while there may be standards used within a domain that may leverage ontologies specific to a domain:

• A domain may sometimes have overlapping ontologies that are in use

• Products may also be used within the domain that are also used across other domains, where the products are largely domain independent

Fig. 2 illustrates the existence of overlapping ontologies. It

can be seen that some ontologies are defined by standards, and some may be defined by product vendors, recognizing that some product vendors have enough dominance in a space to avoid adoption of smaller scale standards.

CIM Interoperability Challenges Scott A. Neumann, Senior Member, IEEE; Terry D. Nielsen, Senior Member, IEEE.

T

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

> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) <

2

Fig. 2. Overlapping ontology definitions

There are a variety of means that can be used to realize, manage and/or document each of these ontologies. Some examples include:

• Unified Modeling Language (UML) • XML Schema • Entity-Relationship Model (ERM) • RDF Schema • Web Ontology Language (OWL) • Domain-specific XML dialect

The notion/exercise of the adoption of a common semantic

model as an ‘uber model’ to harmonize all of the overlapping models that currently exist would be equivalent to boiling the ocean. Even ‘if’ all of the products in the universe were to adopt a common semantic model, there would still be a significant distance to interoperability. Instead, we need to focus on mapping where needed. This would also have the benefit of not overly stifling needed innovation.

III. INFORMATION EXCHANGES The focus of integration and interoperability is the support

of meaningful information exchanges between interacting components. Information exchanges between interacting components are often realized as messages. Fig. 3 is an example related to the use of IEC 61968-9 for the integration of metering systems. This sequence diagram shows that a transactional message (e.g. creation of EndDeviceControls) can result in the subsequent creation and publication of a set of consequential event messages (EndDeviceEvents).

Fig. 3. Example sequence diagram

The set of information conveyed through an information

exchange is typically representative of a subset of the classes, attributes and relationships defined by a corresponding domain model. Within IEC TC57, this is known as a ‘contextual profile’. Fig. 4 describes the relationships between information models, contextual profiles and messages. These contextual profiles are often standardized themselves, providing a basis for the definition of related interface standards.

Fig. 4. The relationship between information models, contextual profiles and messages.

There are many ways in which the syntax of a message can

be defined. Some examples include: • XML schema • RDF schema • DDL for database table definitions

Unfortunately, for each of the above, there are many

possible variations. In the case of XML schema, which has been growing in popularity, the diversity has resulted in the development of ‘naming and design rules’. For example, UN/CEFACT has developed a Naming and Design Rules (NDR) specification. This specification places many restrictions and rules on the use of XML schema, even disallowing or limiting the use of many useful XML schema specification features. Even with such a specification it is still possible to have two independent parties start with the same domain model, same contextual profile for a message and use the same NDR specification and yet achieve results that are different enough to be a barrier to interoperability.

IV. INTEGRATION PATTERNS Integration patterns are used to describe common patterns

used for the exchange of information. The most basic is a request/reply pattern, where a client

sends a request message to a server, and waits for a response from the server.

Another pattern used for exchanges of Common Power System Models (CPSM) and Common Distribution Power System Models (CDPSM) is a simple file transfer.

Often overlooked is that of Extract Transform Load (ETL) as a way of exchanging information from one database to

> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) <

3

another. For integration of metering systems there are some unique

problems that are a consequence of the metering communication infrastructures, where requests can not be immediately satisfied. For this reason it is often necessary to use an asynchronous reply pattern where the result of a request may not be available to the client for many minutes.

V. INTERFACE DESIGN There are many ways that interfaces can be designed. Some

examples of how interfaces could be defined include the following:

• Language-dependent APIs • Web services • REST services • JMS messages • Binary protocols • File transfers

IEC 61968-1 describes a simple approach where each

message conveys a verb, noun and a payload [7]. It is otherwise transport independent and leaves many aspects of integration completely open. While IEC 61968 is most appropriate for some aspects of utility enterprise-level integration within a utility, there are many other standards that can be leveraged depending upon the focus of the integration, including some from OASIS, OPC UA, IEC 61850.

Fig 5 is one implementation approach provided as an

example (where many are possible) for IEC 61968, where an XML schema-based message envelope is used to convey a verb, noun and a payload.

Fig. 5. Example 61968 XML schema showing verb, noun and payload.

This structure would package the XML for a contextual profile, which would in turn still need to be packaged for conveyance via a technology such as web services or JMS. There still are a variety of options at that point. For example, there are many ways in which a WSDL for a web service can be defined. JMS does not have interoperability ‘on the wire’,

so a specific implementation needs to be chosen. In all cases there are a variety of ways that security many need to be addressed, recognizing that the interactions between two components can occur using the interface:

• Within an enterprise on a protected network • Anywhere within an enterprise • Between two enterprises, where a trust relationship

and protected communications have been established

• Between two components across the internet

There are other issues such as error handling. For example, given that a request might result in some error condition, there may be the need for some or all of the following:

• Course grained indication of success/failure • Fine grained error indications, where specific

elements of a request may each generate one or more errors that need to be reported in a machine readable manner

• User readable error indications It is important to recognize that an XSD or WSDL can not

capture all of the important semantics of an information exchange or interface. All parties that participate in an information exchange must both have a common view of the information and related semantics. One case that can be particularly complicated is an update transaction. For example, the update of a complex object such as a work order can be complex. Does the party doing the update need to submit a complete version of the work order, even if only an approval is being supplied? What happens when two parties are doing approvals in parallel? If a new line item is added is it additive or replace existing line items? Certainly the interfaces and rules need to be designed and documented rigorously.

VI. SHALLOW INTEGRATION ‘Shallow Integration’ is a principle of the Smart Grid, along

with loose coupling and layered systems. In short shallow integration dictates that a client using an interface provided by a service need only have minimal knowledge of the internal models and working of that service in order to interact. This is important, as integrations will generally evolve to include a more diverse set of services, the complexities of ‘deep integration’ would exponentially increase the complexities of integration.

VII. INTEROPERABILITY TESTING While it may seem obvious, it is important to state that

interoperability testing is the key to interoperability. Often standards are developed without any plan for interoperability testing. The ideal situation is one where implementations of a standard are implemented against a draft of a standard, where lessons learned, corrections and elimination of ambiguities can be factored into the final draft of a standard.

> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) <

4

Fig 6 describes an integration bus that is being used for the

IEC 61968-9 interoperability testing efforts.

text

ClientProducts

ESB w/ WS, JMS

ServerProduct

ClientProducts Browser

Relational Database

ServerProducts

VendorProducts

Providing Service Interfaces

VendorProducts

Using Client Interfaces

WS

JDB

C

JMS

Server with ESB Implementation

Web ServerWeb pagesH

TTP

WS

JMS

HTT

P

Test Coordinators and Witnesses

JMS

ClientProducts

ClientProducts

Vendor ProductsListening for

Events via JMS or WS

WS

Integration Processes

Fig. 6. IEC 61968-9 interoperability testing using an integration bus.

The IEC 61968-9 interoperability testing efforts allowed for some level of variation between vendor implementations:

• Products could take on client, server and/or listener (event subscriber) roles

• Products could communicate using JMS or web services

• Implementation frameworks (e.g. J2EE, .Net) were the choice of the vendor

Fig 7 shows the web interface used by a test witness, so that

each message exchanged between two (or more) processes for a given test can be tracked, retrieved and analyzed.

Fig. 7. Example test witness web interface.

A non-obvious benefit to a web interface for

interoperability testing is that testing can be performed virtually, where all participants are in remote locations. The elimination of travel requirements makes it easier to perform more interoperability testing more often.

VIII. EXTENSIBLILITY AND EVOLUTION Even once a standard is defined with rigid interoperability

guarantees, we often still need to recognize the need for extensions and evolution. Simple examples of extension an evolution include:

• Model extensions, including new classes, attributes and relationships to reflect extensions to the standard or extended product capabilities

• New enumerations, to define types, codes, status values, etc.

• Optional message elements become required The approaches to be taken are not often clear, especially

with respect to interfaces based upon XML schemas [11]. For example, UN/CEFACT Naming and Design Rules prohibit the use of extensibility mechanisms such as ‘any’ elements. In contrast, interfaces defined by MultiSpeak make strategic use of ‘any’ elements in order to permit vendors to define extensions to interfaces.

However, information exchanges defined using RDF

schema (e.g. network model exchanges) are based on simple triple (object/attribute/value) structures which are implicitly extensible. These RDF exchanges through the benefit of IEC 61970 standards also provide clearer semantics for handling changes than do those based on XML schemas.

In all cases, where allowed, the introduction of a new

element in any information exchange requires a common understanding of the nature and use of the element by all parties that wish to use the element. At the same time there is a strong desire to have changes be backward compatible. In the area of web services, OASIS has defined useful rules related to evolution of interfaces, use of namespaces, etc.

IX. FURTHER EFFORTS For the last few years, annual testing of portions of the CIM

standard has resulted in an improved levels of interoperability associated with the transmission and distribution model exchanges using RDF files. The research and development described here and the associated interoperability testing for ESB based implementation of the IEC 61968-9 standard should also achieve a similar level of interoperability after several iterations of the testing and refinements in the standards and vendors offerings.

X. CONCLUSION In conclusion, the notion of ‘CIM compliance’ still leaves a

> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) <

5

large distance to achieve interoperability. This paper certainly did not attempt to provide a comprehensive treatment of this topic. Interoperability testing will be extremely important to insure that standards development efforts achieve the interoperability goals of the Smart Grid.

ACKNOWLEDGMENTS It is important to acknowledge Margaret Goodrich of

SISCO for her efforts in support of CIM-related interoperability testing. It is also important to acknowledge the efforts of the CIM model managers who have worked to extend, evolve and improve the CIM, as well as those companies and experts that provide their time and knowledge to develop needed standards.

REFERENCES [1] Becker, D.; Falk, H.; Gillerman, J.; Mauser, S.; Podmore, R.

Schneberger, L.; “Standards-based approach integrates utility applications”, Computer Applications in Power, IEEE, Volume 13, Issue 4, Oct. 2000 Page(s):13 – 20.

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

[3] Vojdani, A.; “Tools for Real-Time Business Integration and Collaboration”, IEEE PES vol. 18, May 2002.

[4] Lambert, E.; Fremont, J.; Bouquet, C.; “Method and applications of IEC common information model standard for distribution operations : A path towards smart grids development”, SmartGrids for Distribution, 2008. IET-CIRED. CIRED Seminar, 23-24 June 2008 Page(s):1 – 4.

[5] EPRI, “The Common Information Model for Distribution: An Introduction to the CIM for Integrating Distribution Applications and Systems”. Palo Alto, CA, 2008. 1016058. Available at: http://mydocs.epri.com/docs/public/000000000001016058.pdf.

[6] Clark G. L.; “Leveraging Application Integration and Developing Standards to enable the Next Generation Distribution operating system at Alabama Power Company” presented at the joint DNP and UCA International/CIM Users Group Meeting Tampa Florida, 2008.

[7] Neumann, S.; Nielsen, T.; “Distance to Integrate: Is the Hype of Plug and Play Integration Doing the Industry Large Disservice”, DistribuTech 2008.

[8] Neumann, S.; DeVos, A.; Widergren, S.; Britton J.; “Use of the CIM Ontology”, DistribuTech 2006.

[9] EPRI, “Report to NIST on the Smart Grid Interoperability Standards Roadmap”, June 2009.

[10] Neumann S.; “Enterprise Service Bus Implementation Profile: Integration Using IEC 61968”, EPRI Technical Report 1018795

[11] Nielsen, T.D.; Neumann, S.A.; King, T.L.; “A methodology for managing model extensions when using the common information model for systems integration”; Power & Energy Society General Meeting, 2009. PES '09. IEEE 26-30 July 2009 Page(s):1 – 5.

Scott Neumann (M’1981,SM’2009) is a systems architect with over 29 years experience in the electrical utility industry. Scott provides expertise in architecture, business process management, enterprise application integration, and information modeling relevant to systems used by electric utilities. His specialties include development of energy management system applications, and definition and development of open system architectures, modeling, and systems integration. An internationally recognized expert in the area of T&D open system architecture, Scott focuses

on utility industry needs including distribution, energy management systems, and energy markets. Scott earned a bachelor degree in electrical engineering from the University of Minnesota. He is a member of the IEEE Power Engineering and Computer societies. Scott contributes actively to a variety of industry standards efforts, including the CIM, IEC, CIGRE, and MultiSpeak.

He is the U.S. chairman for Technical Committee 57 of the International Electrotechnical Commission, which is responsible for standards related to power systems management and associated information exchanges. Scott participates in several working groups within TC 57, and serves as U.S. technical lead for Working Group 14, developing standards for the integration of distribution systems and metering system integration.

Terry Nielsen (M’1987, SM’2002) received the B.S.

in Electrical Engineering from Iowa State University in 1987. Terry has experience in defining, developing, and implementing software solutions for the utility industry. With more than twenty years in the development of distribution management systems (DMS), outage management systems (OMS), and energy management system (EMS) applications, Terry focuses on the practical implementation of utility business principles and operational practices. Terry is a specialist in

operational business and process integration with Customer Information Systems (CIS), mobile data systems, Supervisory Control and Data Acquisition (SCADA) systems, Advanced Metering Infrastructure (AMI) systems and Geospatial Information Systems (GIS). He also provides specialized financial analysis and utility business modeling. Terry is a senior member of the Institute of Electrical and Electronics Engineers (IEEE), where he serves on the Transmission and Distribution Committee’s (Distribution Subcommittee) Working Group on Distribution Reliability. He has also served on the DistribuTECH Advisory Committee since 2001. Terry is an active member of the Geospatial Information and Technology Association (GITA) and the IEC TC 57 WG16.

.