Merging IEC CIM and DMTF CIM – A Step Towards an Improved Smart Grid Information Model

Abstract

In the envisioned future Smart Grid, ICT will be incorporated into the power system at all domains in order to improve the operation and management. The incorporation of ICT must be systematic and incremental. One enabler of this is a well-designed and shared information model. IEC61970-301 Common Information Model (CIM) standard exists for the power system. However, it has some drawbacks that decrease the potential adoption benefits and create the barrier of adoption. We explore this standard along with the DMTF CIM standard used in network management and discusses how the principles in the DMTF CIM can be used to extend the IEC CIM in order to address the aforementioned drawbacks.

1 Introduction

One possible definition of the Smart Grid is a next generation power system that incorporates the use of ICT in the generation, transmission, distribution, and end-use of electricity in order to improve the operation and management of the power grid, which can further lead to greater grid reliability, efficiency, and interoperability [1, 2]. Incorporating ICT into the current power grid is not straightforward. The present power system is a highly complex system built over a hundred year using mainly electrical signals to automate power grid operations. At the same time, many management tasks are still done by human operators at the control centers using mainly heuristics with some help of computerized systems for visualization. The transformation of the current power grid into the ideal envisioned ICT-integrated Smart Grid will most likely be a very long process spanning over decades. However, the grid operators can already obtain great benefits from partial incorporation of ICT, as the automation of some management tasks can increase the efficiency in problem detection and diagnosis which could save time and money. The most important notion is that the change must be systematic, incremental, and will contribute towards a fully ICT-integrated Smart Grid. One enabler of this change is a structured and shared information model. Having a well-defined and shared information model will, apart from accelerating the integration of ICT, improve the interoperability in the power system across all domains, from the generation down to the end-use domain.

Discussion on a shared power grid information model is not new. In fact, there exists IEC61970-301 Common Information Model (CIM) standard [3] developed by the International Electrotechnical Committee (IEC), that aims to enable integration among different applications and power utilities. The standard is also well-known to the power engineering community. However, the majority of power utilities do not use the IEC CIM. The potential barriers that prevent a widespread adoption are the required migration time, the intimidating size of the standard, and the uncertainty of expected benefits. In addition, the standard itself does not provide an exact specification on the implementation approach. This promotes flexibility but at the same time creates an integration barrier in conflict with its intended aim.

In this paper, we will be introducing industry standards from another domain, network management, which have been benefiting from various established standards. The purpose of this introduction is to briefly describe the evolution of management standards from a different domain and discuss what the power engineering community can learn from them. Then, we will be exploring the IEC CIM and the DMTF CIM [4] developed by the Distributed Management Task Force (DMTF) as used in network management. The DMTF CIM is similar to the IEC CIM in many ways but with some advantages that the IEC CIM lacks. Their similarities and differences will be discussed along with their weaknesses and strengths. Then, suggestions will be made on how the principles from DMTF CIM can be applied to extend IEC CIM. Finally, an IEC CIM integration plan is suggested.

The remaining part of this paper is organized as follows. Section 2 introduces and discusses network management standards. Sections 3 and 4 briefly describe the IEC CIM and DMTF CIM respectively. The two standards are compared in Sect. 5. Section 6 proposes an approach to merge the two CIMs. Then, Sect. 7 suggests an IEC CIM integration plan. Finally, Sect. 8 concludes.

2 Shared Information Models in Network Management

The power system can be compared to an IP-based networked system. For example, a power system is highly autonomous—the direction of power flow is governed by electrical signals and the voltage regulation under normal circumstances occurs in real-time without human intervention. An IP-based networked system works in a similar fashion. The routing of packets and transmission control are done without human intervention. The shared similarities are likely to exist also in their management approach. The lessons learned by the network management community will provide interesting insights to the power engineering community.

The development of network management standards dated back to the 1980s. Many standards have emerged since then. Some of the well-known standards are Simple Network Management Protocol (SNMP) [5], Web-based Enterprise Management (WBEM) [7], and Network Configuration Protocol (NETCONF) [6]. From the start, SNMP has always been the most prominent network management standard due to its simplicity. However, although SNMP features are implemented in almost all mainstream network equipment, SNMP is mainly used only for network monitoring. Network administrators mostly turn to proprietary Command Line Interface (CLI) for the configuration of network devices. This led to the development of WBEM, a suite of network management technology consisting of the DMTF CIM as the information model standard, that aimed at unifying the management of distributed computing environments. Although still not as widely used as SNMP and CLI, WBEM gained a lot of attention. Variants of WBEM are implemented in major operating systems and there exist many WBEM-compliant applications. Later, IETF began the development of NETCONF that aimed to replace CLI for network configuration task. Unfortunately, the aim has not been achieved; potentially because it uses a less popular remote procedure call and less known information modeling language.

In the power system, there are many proprietary applications for the management of different parts of the system. Most of these applications provide monitoring and diagnostic capability. They can be compared to CLI but possibly with a graphical interface and with functions leaning towards monitoring instead of configuration. The IEC CIM standard is also used by some power utilities for the purpose of exchanging information with other utilities or for monitoring purpose. The IEC CIM and other related standards in the same series (to be explained in Sect. 3) are most similar to WBEM in network management. For example, the information model is object-oriented and the communication between devices is done over HTTP. The success of WBEM indicates that the power engineering community is going in the right direction. However, WBEM has some advantages over IEC CIM. With proper extension to IEC CIM, the standard could become more powerful and serve as the one standard that, as WBEM, unifies all management tasks in the power system at different subdomains.

3 IEC61970-301: Common Information Model

IEC61970-301 is a part of the IEC61970 series. The main purposes of the series are (1) to enable integration of different energy management system applications as well as the integration with legacy systems and (2) to facilitate data exchange between power utilities or between the control center and external systems.

3.1 Model Structure

IEC CIM is object-oriented. It is broken down into packages of related classes, with each class consisting of several attributes. The classes, however, do not have any class-specific methods as the possible set of operations depends on the interface type exposed by the application.

Fig. 1.

Possible component architecture for IEC CIM-compliant entities

3.2 Application Program Interface

IEC has specified a set of interfaces an application can provide. They are specified in the platform-independent Component Interface Specification (CIS) in IEC61970-4xx where xx is a number representing a specific interface type. The interface types are 402 common services [8], 403 generic data access [9], 404 high speed data access [10], 405 generic eventing and subscription [11], and 407 time series data access [12]. Part 402 serves as the basis for all interface types. Services for each interface type is valid for all implemented classes. For example, the read and update services defined in part 403 can be invoked on objects of any class that is implemented by an application exposing generic data access interface.

3.3 Model Exchange Language

It is up to the application developers to decide on a specific language used to exchange CIM models. IEC so far has provided one recommended encoding language in IEC61970-501 [13]. The language is a semantic web language, RDF/XML [14]—Resource Description Framework (RDF) [15] represented using XML syntax. The mapping from a CIM model to RDF model is often done by means of generation from CIM UML model file automatically by a script.

3.4 IEC CIM-Compliant Component Architecture

Based on the guidelines from the IEC, a possible component architecture for IEC CIM-compliant entities is depicted in Fig. 1. The processes involved in the interactions between the client and server are numbered and explained below.

• 1. The UML model representing the CIM is exported as a model file.

• 2. The model file is converted to an RDF schema file using an automated script.

• 3. The RDF schema is used to initialize the RDF store (RDF database).

• 4. Power data could be recorded during the systems operating state.

• 5. EMS2 employs CORBA to host the application interfaces.

  • 5.1. The codebase can contain program code in any programming language.

  • 5.2. A language-specific skeleton is generated from an Interface Definition Language (IDL) file specifying the interface to be exposed to clients

  • 5.3. The implementation of the skeleton resides in the codebase. These objects extend the skeleton to provide the logic for the defined methods.

  • 5.4. An Object Request Broker (ORB) is used as a medium for the server and client to communicate

• 6. The client, in this case, has the same architecture as the server

  • 6.1. The client codebase may contain code in a different programming language from the servers

  • 6.2. A language-specific stub is generated using the same IDL file as in the servers case

  • 6.3. An object reference, as the name suggests, acts as the reference to the remote object on the server. The client uses the object reference as if it resides locally on the client itself.

  • 6.4. An ORB is used to communicate with the server.

• 7. The requested power data is returned in RDF/XML format.

4 DMTF CIM: Common Information Model

4.1 Model Structure

There are two ways to represent the CIM: Managed Object Format (MOF) is used as a written form of representation while UML class diagram is used as a visual form. The model is divided into three conceptual layers: Core Model, Common Models, and Extended Models. The Core Model includes information applied to all network management domains. The Common Models include information applied to specific areas although independent of implemented technology. Information that is technology-specific is modeled in the Extended Models.

4.2 Application Program Interface

The DMTF CIM defines two types of interface called intrinsic and extrinsic method. Intrinsic methods are methods that are defined in the CIM namespace and can be used to manipulate all classes and instances. The examples of such methods are GetClass, GetInstance, DeleteClass, and DeleteInstance. Extrinsic methods are methods that are defined in the CIM schema on CIM classes and can only be invoked on instances of those classes. These methods are closely related to the management functions of a particular type of devices such as reset() on CIM_LogicalDevice and setAlarmState() on CIM_AlarmDevice.

4.3 Model Exchange Language

xmlCIM is the DMTF CIM’s model exchange language in which XML is used to describe CIM structure such as CIM classes, instances, and qualifiers. To regulate how the data is represented as XML elements and attributes, both the Document Type Definition (DTD) and XML Schema Definition (XSD) are used.

Fig. 2.

Possible component architecture for DMTF CIM-compliant entities

4.4 DMTF CIM-Compliant Component Architecture

The DMTF has defined an exact approach for two CIM-compliant entities to interact with each other. CIM-XML is a protocol for exchanging CIM data and manipulating CIM object instances or classes. It uses xmlCIM as the payload over HTTP transport protocol. See Fig. 2 for the component architecture of DMTF CIM-compliant entities and their interactions. The processes involved in the interactions are numbered in the figure and explained below.

• 1. An XML or MOF file encoding a CIM model is used to populate the database

• 2. The database can be a relational database; the structure depends on the implementation of the server

• 3. The server must be able to send and receive HTTP requests and responses; it must also be able to query from and manipulate the database

• 4. CIM client must possess the same communication capabilities as the server

• 5. The xmlCIM request is sent as a payload in an HTTP request from the CIM client to the CIM server

• 6. The server sends an HTTP response with an xmlCIM response as a payload

5 Comparison of IEC CIM and DMTF CIM

5.1 Comparing Technical Specifications

(See Table 1).

Table 1. Summary of IEC CIM and DMTF CIM technical specifications

5.2 Similarities of the Two Standards

The two standards have many things in common. For example, both aim at solving system integration problem in their respective disciplines and are object-oriented. They both define intermediate formats for exchanging data or performing operations. In addition, they define common services for operations and data exchange that apply to all object types; these include basic create-read-update-delete operations on classes and properties such as get_values(), create_resource(), delete_resource() defined as part of the CIS for generic data access in IEC CIM [9] and GetInstance, GetClass, DeleteClass in DMTF CIM [16].

5.3 Differences Between the Two Standards

Despite the same aim to solve integration problem in their respective disciplines, the DMTF CIM was created as a result of a more ambitious goal which is to faciliate network management tasks. On the other hand, the IEC CIM was intended to be used as a standard for data exchange or public access of power system data. This led to the different levels of operations that can be done on their class instances.

In the IEC CIMs case, a limited number of operations were defined as part of its common interface specifications; each operation is closely-related to the type of interface and applies to all classes and instances in the associated CIM models. Such operations were also defined in the DMTF CIM in the form of intrinsic methods. However, DMTF CIM also defines extrinsic methods for specific classes. This is missing from the IEC CIM because it was not intended that the operations and management in the power system will be done by means of manipulating CIM instances. In other words, it was not considered necessary in the design of the IEC CIM. As a result, the IEC CIM has a simpler schema. In contrast, the DMTF CIM has a more complex schema with each CIM class having a specific set of defined methods.

6 Merging IEC CIM and DMTF CIM

The strength of the IEC CIM is the comprehensiveness of the standard. Most of the power entities in the generation and transmission, and some in the distribution domain, have been included in the model. This provides a taxonomy for the power system that will improve the interoperability between power utilities and applications. Unfortunately, the size of the standard and the open-ended implementation method can create uncertainty in adopting it for practical use. In other words, much of the job is left in the hands of the application developers to decide on the necessary classes, platform, and programming language. Moreover, the benefits may seem limited to obtaining data on specific power components without the ability to actually manipulate them programmatically. In order to fully reap the benefits from the standard, extensions are required. Due to the similarity between IEC CIM and DMTF CIM coupled with the success of DMTF CIM, we propose that some principles in DMTF CIM are applied to IEC CIM as the needed extensions. The applied principles are listed in this section.

6.1 Defining Device-Specific Operations for IEC CIM Classes

The lack of defined device-specific operations in IEC CIM standard prevents full integration of third-party applications that can directly manipulate power components. For example, it may be possible for an application to import a list of relevant power components, perform calculations, and suggest the actions to be done on specific components. However, the instructed actions must be carried out manually by personnels interacting directly with the targeted components or using a separate mediating application. It will be much more efficient if a third-party application can directly invoke operations on targeted components. However, device-specific operations must be standardized in order to ensure compatibility between the application and affected devices. As a result, we propose that the IEC CIM be extended to include device-specific operations equivalent to extrinsic methods in the DMTF CIM. This could be done incrementally for certain power components that are normally maintained by control centers.

6.2 DMTF-CIM-Like Component Architecture for IEC CIM-Compliant Entities

The implementation approach for IEC CIM-compliant entities is not a part of the IEC CIM standard. This is not a problem for IEC CIM-compatible applications implemented and used within a single power utility. However, it can create a problem with third-party applications that use IEC CIM but take a different approach to implement the exposing application program interfaces or use a different language to encode exchanged data. To address this issue, the IEC CIM standard must provide a specific implementation instruction.

One can deduct from the CIS documents that one possible implementation approach is to use CORBA for the communication between two entities exchanging CIM data. However, remote procedure call-based implementation is no longer a popular choice as evident from the unsuccessful push of IETF for NETCONF. We suggest an alternative component architecture that makes use of the approach used by the DMTF CIM in which CIM data is sent as an HTTP payload. The payload for the IEC CIM data requests and responses can be in RDF/XML as suggested in IEC61970-501. In case the IEC CIM is extended to include more complex device-specific operations, the invocation of operations can still be done using this alternative approach. The extension necessary is only to define shared RDF vocabularies to support operation invocation. Figure 3 illustrates the proposed alternative component architecture. The numbering is explained below.

• 1. A UML model file describing an IEC CIM model gets converted into an RDF schema file using a script.

• 2. The database can either be a relational database or an RDF store; using a relational database is simpler but requires program code to construct RDF/XML messages while using an RDF store complicates the query but RDF/XML messages can be constructed easily from the query results.

• 3. EMS1 can operate on any platform as long as it possesses the capabilities to send and receive HTTP requests and responses, parse RDF/XML messages, and manipulate the database.

• 4. EMS2 must possess the same capabilities as EMS1.

• 5. EMS2 sends an RDF/XML message requesting for CIM data or invoke operations as an HTTP request’s payload.

• 6. EMS1 sends an RDF/XML message containing the requested CIM data or acknowledgement as an HTTP response’s payload.

Fig. 3.

Alternative component architecture for IEC CIM-compliant entities

Fig. 4.

IEC CIM integration plan

7 IEC CIM Integration Plan: What Must Happen?

It can be expected that a widespread adoption of IEC CIM will span over decades. Figure 4 depicts a likely integration cycle. First, the IEC CIM standard series are extended as proposed in Sect. 6. Then, both the utility-operating control centers and third-party applications start adopting the IEC CIM as necessary. The control centers have to also implement device-specific methods required by in-house or third-party applications. In case a method not included by the standards is needed, a proposal should be submitted to the IEC to be considered for future revision of the standards. The process then repeats.

8 Conclusions

Present power grid management relies largely on human operators and heuristics. This is envisioned to change in the future Smart Grid where ICT is more tightly integrated into the power system to increase management efficiency which could save time and money for grid operators. A step that will contribute to this change is the establishment of a shared information model that can be used across all domains in the power system. In this paper, we discuss a known standard in the power engineering community, IEC61970-301: CIM, and propose extensions using principles adopted by another successful standard used in network management domain—DMTF CIM. The extensions include the incorporation of device-specific operations and a simpler component architecture. Extending the IEC CIM with device-specific operations will make possible the direct control of power components from third-party applications, while a simpler component architecture can speed up the adoption rate of IEC CIM.