- Aug 25, 2021 7:47 pm GMT
Why write a blog about the Common Information Model or CIM? Because it is not well understood. And electric utilities need to exchange data from one corporate system to another. One way to exchange data is to create unique adapters for each pair of systems. Unfortunately, doing this can become a support nightmare. Using CIM, utilities only need a CIM adapter for each application. These may be commercially available or built into the application themselves.
In my first blog CIM CIMfplied – Part 1, I wrote about how industry experts created CIM. They had two big ideas. The first was to create a vendor and program-neutral way of defining everything you wanted to know about the grid. In that way, when utilities want to exchange data, they could export their data to CIM. Then when another program wished to consume the data, it gets it in the CIM language.
The second big idea was to create an industry-standard way of documenting this standard model. The idea was not to present the CIM in standard database format, like a schema. Instead, the experts chose a much more general form. They decided to represent CIM graphically. That way, they would show objects as boxes, relationships, and associations using lines and arrows. They selected a tool called unified modeling language or UML.
UML uses a variety of diagrams. For example, CIM relies heavily on class diagrams. A class is a kind of object, equivalent to a table, where every element has the same column. An example is a disconnecting device. So, for example, a switch is a member of disconnecting device class.
CIM also a contextual model. Stay with me. That means utilities can use CIM in certain situations to exchange information between two specific systems, such as between GIS and ADMS (Advanced Distribution Management System).
What makes a contextual model? Profiles. A profile is another common term in the CIM world. Profile has lots of meanings. In photography, it means a picture of someone standing sideways. The social media world represents a person’s profile, as a photo (not usually in profile), and often hobbies and interests. A CIM profile is none of that. A profile is a subset of CIM that has a specific purpose. Remember that CIM is one great big model. Just one. There is one CIM, many profiles.
Take the example of GIS providing data to ADMS. That process doesn’t need all the CIM data. Nor is all the data in the GIS needed in the ADMS. So, a GIS to ADMS profile specifies only that data in one system required for the other. A profile then within the CIM world is known as a contextual model. A profile has a particular purpose or context.
What exactly does the subset look like? Say a utility wants to deliver data from their GIS to SCADA (System Control and Data Acquisition). GIS has tons of information about conduits, duct banks, and poles. SCADA doesn’t use any of that. SCADA does need information about transformers, but it doesn’t usually need the exact location or the manufacturer. But it does require the MVA rating. So, a profile for data transfer between SCADA and GIS could have a limited set of classes – transformers yes, poles no. It would also have a limited set of characteristics of the classes, also called attributes for those classes in the profile. MVA rating, yes, manufacturer, no.
All we must do to transfer data from an ADMS to GIS is to use a profile. Not so fast. Like the entire CIM, a profile is in UML format. UML is computer-readable like a Visio diagram. But it’s not in a form that makes data easy to exchange. But you can create software from a UML subset. With a minor amount of fiddling, you can configure a database from UML. Some vendors have done this, even though it is not the native purpose of the CIM. So no, you can’t use it directly for information exchange. You must transform it first into something a real computer system understands. Pictures or diagrams won’t do it.
Serialization is the process that codes the UML to a simple machine-readable form. Here is how it works. First, we create a profile – a shrunk-down purpose-built UML diagram. It will have a limited number of classes, and each class will have a limited number of attributes. When data is exchanged between two parties, they need agreement on what is exchanged. This is the purpose of the UML of the profile. Next, we put this diagram through a translation program. This tells the sender what information to extract.
So, after all this, out pops a series of codes that computers understand. That output is usually XML. XML stands for extensible markup language. XML is a self-describing code. It’s a text string. It uses funny characters like “<” and “>” to denote that something next is coming. For example, <car>, < brand>,<enginetype>. The XML schema defines the way the data will be presented. The actual XML stream contains the data itself. <car> Ford, V8. It says to expect the text car first, followed by the brand and the engine. I’ve simplified this concept greatly, but you get the idea.
CIM includes standards for serializing in XML. There is commercially available software for doing just that. Implementers don’t have to dream up everything from scratch.
So CIM and its profiles give users a way to exchange grid information effectively. In my next blog, I will touch on some of the nuances of how CIM models real electrical systems. Then I’ll unravel the numbering system of the various standards that make up the collection of CIM standards. Recall there is only one CIM, but many standards. Stay tuned for Part 3.
Get Published - Build a Following
The Energy Central Power Industry Network is based on one core idea - power industry professionals helping each other and advancing the industry by sharing and learning from each other.
If you have an experience or insight to share or have learned something from a conference or seminar, your peers and colleagues on Energy Central want to hear about it. It's also easy to share a link to an article you've liked or an industry resource that you think would be helpful.