This is the third post in a series of articles about integrating your GIS with the rest of the business units. This comes by means of an Enterprise Service Bus (ESB) that implements a decoupled integration. The objective of this series is to give you the know-how to build such a decoupled integration. The article draws only on proven industry standards and addresses how CIM data modeling can help you achieve decoupled integration. And most importantly, this article aims to empower your team to actively participate — even take control of — your integration efforts, including from design, through implementation, testing, and final acceptance.

In the first post, we presented the motivation for adopting an ESB integration model. This includes an overview of the advantages and disadvantages inherent to using ESB vendor-specific applications. Additionally, we described the concept of decoupled integration (one based on a simple contract), which frees the implementation from proprietary interfaces. Once freed from vendor constraints, you can decide the technology that best adapts to your GIS team, gaining control of the GIS side of the integration.

In the second post, we discussed the technical details implementing a decoupled integration using industry standards: RESTful services, and CIM data format. At least that was the objective when I was drafting the article. But as I was writing I chose to describe RESTful services in depth, and I decided to address CIM in a later post. It is now time to talk about CIM.

CIM Data Modeling: Behind the Model

Common Information Model (CIM) is a standard originally developed in North America by Electric Power Research Institute (EPRI), with the support of the North American Electric Reliability Council (NERC). The objective of CIM data modeling? To allow the exchange of information among power systems within — and among — utilities.

As its usability grew, CIM was officially adopted by the International Electrotechnical Commission (IEC). Today, it now comprises the IEC 61970-XXX collection of standards. From the start, CIM was conceived as a vocabulary to describe the components of a power system at an electrical level, as well as to establish relationships among these components. Thus, CIM (IEC 61970-301) was created as a semantic model, choosing the Unified Modeling Language (UML) for its definition. A thorough account of the CIM data modeling history, its current support as IEC 61970 standards, and the breath of applicability goes beyond the scope of this post. If you want to get a deeper understanding of CIM, you may want to start visiting the CIM User Group web page.

Now, let us focus our attention on using CIM data modeling for decoupled integration.

CIM Data Modeling for Power-Systems Integration at Utilities

The IEC 61970 family of standards describes, among other properties, the attributes of your electric assets, their coordinated location, and the interrelationships among the assets in a network. Does this sound like the way you describe the electric data in your GIS? Indeed.

With a single model, CIM is a good descriptor of the distribution network for GIS and OMS, the substation for SCADA, the transmission network for EMS, the whole smart grid — from generation (including distributed generators: wind, solar, etc.) to consumption at the meter, for ADMS. Furthermore, two other standards have been added to CIM. IEC 61968 provides asset tracking, work scheduling, and customer billing capabilities. IEC 62325 covers the data exchange between participants in electricity markets. So, CIM data modeling can also support your Asset Management System (AMS), your Work Management System (WMS), your Customer Information System (CMS), and more. Yet, most likely none of your enterprise applications uses CIM as their native data model.

But, what if all these systems could “speak” CIM?

Speaking the Common Language of CIM Data Modeling

Here is where the power of CIM manifests itself. In a CIM-Based integration, the single CIM data model is your common language for intersystem communication. (It is like speaking Euro-English in the European Union’s Parliament in Brussels, Belgium.) Every system participating in the integration interfaces with the ESB via a CIM-adaptor: a proprietary application that converts the native data model into a CIM descriptor. The system exposes its data by means of CIM-formatted messages broadcast to the ESB. The ESB acts as a “message router,” delivering the messages to the target applications. The target system, then, converts the CIM data into its internal native format, and processes it accordingly. The diagram below shows you the difference between a coupled (non-ESB) integration, and a CIM-Based integration via ESB.

Conclusion: CIM Data Modeling for Intersystem Communication

CIM offers the ultimate data model for decoupled integration: multiple independent systems communicating among themselves, regardless of the native data models. Each system exposing and end-point URL with a single RESTful service that accepts a CIM-message. And, as the back-bone, the ESB publishing messages throughout the network, or transferring specific request/response between a client and a service. You, are in control of your side of the integration. You are in control on how to build your GIS’s CIM-adaptor. You are in control of how to broadcast your data within CIM-messages. You are in control of how to convert a CIM-message request from a client into your native data, process the request, and reply with another CIM-message. All without having to deal with vendor-specific API’s. You are in control of your GIS/ESB integration.

This is probably enough for a general introduction to CIM data modeling, and its value within the context of decoupled integrations. I will follow up on this post with particular details about CIM-messaging: the standard, the verb/noun schema, the reduction of the general model into application specific profile, and other technical details. In addition, please note that CIM data modeling was conceived within the electric utility, but its extensions for WMS, AM, CIS and other domains make it useful to other types of utilities when integrating GIS with any of those (non-electric) systems.

Please, stay tuned.