Common Information Model (CIM) CIMplified – Part 1 – The Basics

Early in my career, I taught a night school graduate course. It was about computer methods to solve electric grid simulations. It was basically a math course. The math was tough. I had two problems. First, half the class consisted of full-time sleepy utility engineers. They had to race from their jobs to the class. The others were international students. English was their second language. So, I had to communicate the complex subject simply. Instead of dealing with the math first, I decided to tell stories of how things worked. Then I would teach math.

Like my college course, the Common Information Model (CIM) is complicated. Yet, its concept is quite simple. But it does use terms that may be hard to understand. The purpose of this blog is to explain in a simple way how and why it came about. I will tell what it is and isn’t. And what some of the terms mean.

In the Beginning

CIM started as a solution to this problem. Vendors built grid control systems, called Energy Management Systems (EMS), from scratch. It was hopeless for one vendor’s program to share data with another. It was worse than that. When utilities upgraded to a new product even with the same vendor, porting the data from the old system to the new one was often impossible. Early efforts attempted to model a standard architecture. That effort essentially stalled. By the early 1990s, the Electric Power Research Institute (EPRI) formed the Control Center Applications Program Interface (CCAPI). Its action was to focus on the data interfaces rather than on the architecture. Then whenever one system had to talk to another, they could use a standard set of data. The team had an aha moment. Not to focus on the mechanics of implementation but on the information – to create an information model. Thus, the CIM was born!

Problem solved. Well, in theory. To quote a common cliché: easier said than done. Getting agreement required a lot of work.

As the work progressed, the team thought it would be great to enshrine CIM as a standard. But EPRI is not a standards body. So, the team decided to work with the International Electrotechnical Commission (IEC) to create a standard. IEC agreed. It created working group 13 of the Technical Committee 57 (Power Systems Management and Associated Information Exchange) to make the standard. The CIM continued to evolve as various parties, including EPRI, continued to invest in using it. The first standard issued was 61970 after years of debate among the industry volunteers on the working group. Other CIM working groups and standards and sub-standards have followed since.

The Canonical Model

The team had two big ideas. The first was to create a canonical information model. What on earth does canonical mean? Canonical comes from the Latin, Canonicus. It means a set of rules. Canon law, for example, is a set of religious rules. A canonical information model is a single representation of data and data relationships. It is a common language (or lingua franca) that everyone can agree on. For example, English is the standard language or lingua franca for international business. CIM would be the lingua franca for everything power systems. Not to be muddied by different vendor’s terms and formats. It needs to be independent of any actual vendor system. It shouldn’t even favor terms from a type of system, like a Geographic Information System (GIS), EMS, or a power flow program.

The simple idea is to move data from one system to another easily. Take, for example populating data from GIS to an ADMS (Advanced Distribution Management System). GIS has its own information model. ADMS has its own. GIS converts its data to the canonical model. ADMS consumes the data from the canonical model into its own information system. In that way, each program only must deal with one translation. GIS doesn’t have to worry about what system it is exchanging data with either.

A Semantic Depiction

The other idea was to create a standardized way of documenting and communicating this canonical model. The teams did not want to select a database vendor technology. Instead, they tried to make a semantic representation. Here we go again. What does semantic mean? Semantics comes from ancient Greek and simply means the study of meaning. The team selected a technology called Unified Modeling Language or UML for CIM’s representation. UMS is a graphic representation of information that represents things. It shows additional information about things. It illustrates relationships. It represents the meaning of things.

UML is a graphical representation of everything you ever wanted to know about the electric grid in its simplest form. It must be huge, then? Yes, it is. It continues to grow as the utility industry grows.

What CIM is and is Not

The CIM is a collection of information about nearly everything about the electric grid. Even though it is a single model, three different IEC standards with multiple parts define it. It also is not static. It continues to grow. Volunteers refine it. CIM is not a database schema. No computer program can use it to do anything. No one application or data set uses the entire CIM, just as no one novel uses the entire English language. The important thing is that when two different applications describe the same thing with CIM, they describe it the same way, and they can more readily integrate (i.e., exchange information).

What’s Next

Part 2 will dig a bit deeper into how CIM is structured. It will discuss how CIM uses subsets. It will answer the question that if it can’t do anything, how is CIM converted into something people can implement. Part 2 is coming soon. Stay tuned.