Common Information Model for Sensors
Vinoth M. Mohan Noel N. Schulz
Mississippi State University Mississippi State University
vnm12@msstate.edu nschulz@engr.msstate.edu
Keywords: Common Information Model, Resource
Description Framework, Unified Modeling Language, Data
Integration, Semantic Web
Abstract
Sensors like current transformers and voltage
transformers are used to monitor the power systems and data
from these sensors are collected in appropriate computer
applications to observe the state of the power system. Phasor
Measurement Units (PMUs) get data from current and
voltage transformers and time-stamp them thereby paving
the way for wide-area monitoring of the power system. In
wide-are monitoring, the dynamic-view of the power system
may be observed across multiple utilities’ zones each using
many different computer applications. To enable these
computer applications to communicate with each other, a
common language is required with the ability to overcome
proprietary data constraints of power system applications.
This paper focuses on the common data model that is
required by sensors –CIM models and the storage format –
CIM/XML that is used to share data between applications.
1. INTRODUCTION
Most Energy Management Systems (EMS) and
Distribution Management Systems (DMS) developed by
vendors cannot communicate with each other due to
conflicting proprietary data formats. Utilities may have to
use the same vendor for multiple packages even if another
application with better features is available in the market due
to the data-format constraints. Inter/Intra-communications
between utilities can help to anticipate or mitigate any
undesired contingencies in the power system and also lead to
improved economic operation of utilities at times. The major
hindrance to interchange of data is the heterogeneity of the
software used by power companies and the variety of
different formats used to store data. This representation of
data in proprietary formats makes it difficult to exchange
data between other applications thereby requiring translator
programs to convert the data from one format to another.
Due to the myriad of translators required between all the
applications, a common format to cover all areas of data
exchange in power electrical domain has been adopted by
the Electric Power Research Institute (EPRI).
2. COMMON INFORMATION MODEL
Common Information Model (CIM) is a highly detailed
object-oriented model of the power system developed using
Anurag K. Srivastava
Mississippi State University
srivastava@ece.msstate.edu
Unified Modeling Language (UML). The Common
Information Model for power systems falls under two
standards:
a. IEC 61970-301: This IEC standard describes the power
system from an electrical point of view. The electrical
properties of equipment and the relationship they share
with other equipment are covered in this standard [1].
b. IEC 61968-11: This IEC standard describes
supplementary features required in a power system like
asset tracking, documentation work, consumers, and
resource planning [2].
2.1. Data Format issues
Most power system applications are tailor-made for a
particular functionality and they often use application-
specific file formats. In a power system utility, many such
applications are used and to enable communication between
them, the utilities always have to stick with the same
application vendor.
In a de-regulated environment, the utilities often have to
communicate with neighboring utilities that run applications
developed by different vendors. This creates communication
problems as the applications are normally built upon
proprietary data formats. Often different versions of same
application do not understand each other due to
modifications made to the original file-formats. An example
of this issue would be Microsoft Office Word 2007 and
Word 2003. The native storage extension for Word 2007 is
*.docx whereas Word 2003 uses *.doc. Word 2003 cannot
open a *.docx document unless the Compatibility Pack is
installed.
2.2. Need for Common Information Model
In the power industry, numerous applications/systems
are used and many are incompatible with other power
system applications. As a stopgap approach, most utilities
just use a point-to-point interface between applications.
To prevent this point-to-point interface, the Control
Center Application Program Interface (CCAPI) working
group (WG) was set up by the Electric Power Research
Institute (EPRI) to build the Common Information Model for
power systems. As the scope of CIM models increased, the
design of CIM was taken over by various International
Electrotechnical Commissions (IEC) working groups
primarily Technical Committee TC-57’s working groups 13
and 14. Common Information Model prescribes that utilities
use the highly detailed customizable CIM format that is
compatible with many applications. Moreover, this format
has the flexibility to add extra data to it in case an
application needs them, without invalidating the data format
[3].
Figure 1. Traditional Data Integration approach
Figure 2. CIM Data Integration
The detailed UML diagrams for the power system
provide the data format. This format combined with
eXtensible Markup Language (XML) and Resource
Description Framework (RDF) forms the CIM/XML
language that can be used as the communication language
between any two non-compatible applications. Figures 1 and
2 indicate the simplification provided by CIM integration
[4].
2.3. CIM Class Relationships
The Common Information Model when expressed in
eXtensible Markup Language along with the Resource
Description Format is a Formal Language. The basic
grammar for this language is set forth by IEC Technical
Committee TC-57’s Working Groups 13 and 14 in the form
of CIM/UML class diagrams. The Working Group 13
(WG13) mainly deals with CIM for Energy Management
Systems (EMS) and Working Group 14 (WG14) deals with
CIM for Distribution Management Systems (DMS).
The unique feature of the CIM grammar is that it is
abstract and generic. This generic property enables it to be
compatible with any application used in the power system
industry. Moreover, it provides the option of customization
for any application that needs additional properties. In
essence, the grammar can be extended to accommodate the
specific needs of individual applications without affecting
the core grammar.
As the Common Information Model is based on Object
Oriented Design (OOD) modeling [4], the basic object
oriented modeling concepts used in the CIM are described
below :
Class: A class is a kind of blueprint for any physical or
abstract thing in the world. It includes the characteristics and
behavior of that particular thing.
Object: An object is a particular instance of a class. For
example, for the class “Car”, “Ferrari 550 Barchetta” is a
particular instance and so it is an object.
The important relationships that one class shares with
other classes are as follows:
Inheritance: Inheritance enables sub-classes to inherit
characteristics and behavior from parent classes.
Association: Association describes the relationship between
classes wherein one is not the subset of another class.
Aggregation: Aggregation describes relationship where one
class is a collection of another class. For example, a
“website” is a collection of individual “web-pages”.
Figure 3 is the CIM model for AC/DC line segments
and it illustrates the various relationships between the
classes. The vertical flow of diagram from bottom to top
describes, ‘AC/DC line segments’ are a type of ‘Conductor’;
‘Conductor’ is a type of ‘Conducting Equipment’;
‘Conducting Equipment’ is a type of ‘Equipment’;
‘Equipment’ is a ‘Power System Resource’ [5].
The relationship between the classes ‘Conductor’ and
‘Conducting Equipment’ is Inheritance (Generalization). It
means the class ‘Conductor’ is a subclass of the class
‘Conducting Equipment’. It inherits all the characteristics of
the parent class and in addition has some extra
characteristics of its own.
The relationship between ‘Conductor Type’ and
‘Conductor’ is Association. The class ‘Conductor’ does not
contain the class ‘Conductor Type’ whereas it shares a
special association relation. The multiplicity at the ends of
the line denotes that the class ‘Conductor’ can be associated
with zero or one ‘Conductor Type’ class. Similarly the class
‘Conductor Type’ can be associated with zero or many
number of ‘Conductor’ classes.
The relationship between the classes ‘Equipment
Container’ and Equipment is Aggregation. Here it describes
 Phasor Measurement Units (PMU) are the important sensors
Power System used in power system networks. PTs and CTs measure the
Resource high level voltages and currents and convert them to safe
operating level signals. Relays and PMUs are fed by CTs
and PTs. The voltages and currents sampled are converted
into digital format for further processing using relays. Relays
analyze these signals to provide the necessary protection.
Equipment Relays also calculate the sequence currents, real and reactive
Equipment power measurements. A conventional measuring device
Container
measures the quantities across the power system at different
instances of time. The measurements have to be
synchronized to get an accurate picture of the power system.
The measurements from the devices may not be
Conducting accurate due to improper calibration, aging of the devices.
Equipment Error may also be introduced due to noise in communication
networks when the data is transmitted from the field to
control center. The parameters of the sensors like accuracy,
accuracy class and total vector error are used by the state
estimator program to obtain a better estimate of the power
Conductor 0..* system states and measurements. State Estimation plays a
Conductor
Type 0..1 major role in calculating all the states of the power system.

3.1. Wide-Area Monitoring Using Phasor Measurement

DCLine ACLine
Segment Segment
Figure 3. CIM for AC/DC Line Segments
that the class ‘Equipment Container’ “contains” the class
Equipment. Conversely, the class equipment is “part-of” the
class ‘Equipment Container’.
2.4. CIM Class Usage
Even though, the CIM UML model has lots of
classes/attributes, not all the classes or attributes have to be
used. For example, all the classes in figure 3 may be
required by one application and another application might
need only one class. That means, ACLine Segment can
appear as a separate class of its own or it can be considered
as a Conductor, a Conducting Equipment, Equipment, Power
System Resource etc as needed [3]. Even if additional
classes are added to the same class diagram, it is not going to
affect the applications that are already using the existing
class diagrams thereby enabling customization of the CIM
class diagram according to the requirements of specific
applications.
3. SENSORS FOR GRID MONITORING:
The present day power system is monitored with
numerous measuring and control devices. Potential
Transformers (PT), Current Transformers (CT), relays, and
Units (PMU)
Traditionally, SCADA systems provide voltage, power
flow, frequency measurements and other values typically
taken once every two or four seconds. Moreover, SCADA
systems can monitor only small areas, as measurements from
far-away locations would have a time-lag associated with
them leading to loss of synchronization. Phasor
Measurement Units output voltages, currents, their
respective angles, and frequency rate-of-change at a very
fast rate (ex: 40 samples/second) and are time-synchronized
using GPS time pulses [6]. By installing PMUs at salient
positions of the power grid, the measurements from current
transformers and potential transformers connected to each
PMU can be time-tagged and sent to the control center. Due
to the time-synchronization of the measurements, wide-area
monitoring of the power system is possible [7]. Moreover as
the rate of data output is very fast, the dynamic-view of the
system can be had at all times leading to fast responses from
human operators or machine.
3.2. CIM For Sensors
As part of the research at Mississippi State University, a
Sensor Web is used to perform online monitoring and
control of power system. The Sensor Web is a semantic web
which is an evolving extension of World Wide Web (www)
[8]. In the semantic web, machine-understandable data is
used to perform automated tasks. As part of our
requirements, the sensor web is required to perform state
estimation, contingency analysis and other tasks using data
from the sensors. To perform state estimation, we require a)
equipment characteristics of Current Transformers, Potential
Transformers and PMUs and b) measurements from sensors.
 Power System
Resource
1
* has two tags <Name> and </Name> which is used to denote
Measurement 1 * Measurement
Type
1
* the association or aggregation relationship that one class
1
* denoted using triplets: subject, predicate and object [11].
Measurement Measurement
Limit Value
sensorAccuracy
timeStamp
Figure 4. Measurement CIM classes [9]
In traditional CIM, current transformers and potential
transformers are substituted with measurement class CIM. In
our case, the equipment characteristics like accuracy,
accuracy class, and total vector error are required. These can
be taken from the IEC 61968-11 asset models. Moreover,
additional attributes are required by the sensor web for
documentation purposes. IEC 61968-11 already has the CIM
UML model for Current Transformers and Potential
Transformers. The measurement CIM also exists in the
61970-301. This means only the PMU CIM model needs to
be developed.
Figure 4 shows the Measurement CIM/UML model.
Having ‘sensorAccuracy’ and ‘timeStamp’ available with
every ‘Measurement Value’ should make the accuracy value
obtained from the asset CIM redundant. But in case the
measurement value is from a PMU, just using the
‘sensorAccuracy’ attribute of ‘Measurement Value’ class
would lead to error. This is because, the PMU gets its inputs
from the current transformers and/or voltage transformers
and so the output of the PMU device not only has the native
accuracy error associated with the PMU device, it also
carries the error that got introduced when the measurement
was originally made in the current or voltage transformer.
This means CIM asset models for current transformer,
voltage transformer and PMU would be useful while
performing State Estimation and other analysis methods. A
draft PMU model built using the UML software Enterprise
Architect is shown in the figure 5. The attributes chosen for
the classes in the diagram were chosen using SEL-421 relay
that can double up as PMU [10].
4. CIM/XML MESSAGES
To have the final communication language, the CIM
diagrams have to be implemented using XML. XML is used
to define metadata, which means ‘data about data’. For
example,
<Name>John</Name>
the name of a person “John”. The main drawback of XML is
its limitation to be expressed only in the form of a parent-
child relationship. This means it cannot be used to express
may share with another. To enable the XML to share
relationship with other classes, the Resource Description
Schema (RDF) is required. In RDF schema, the elements are
The CIM/UML models available in the IEC are data
models and not database schema. This means using the
CIM/UML models of the assets CT, PT and PMU and
measurement CIM model, the database has to be created in a
relational database and the tables need to be populated. The
tables were populated and a tool was written in C# to pull up
the data from the tables and write them in CIM/XML format.
For this CIM/XML data to be valid, it needs to be
validated against a relevant RDF schema. To validate the
document, RDF schema has to be generated for the
CIM/UML models of CTs, PTs and PMUs and measurement
CIM. This was achieved using the CIMtool plug-in [12]
available for the popular software Eclipse. The CIM *.XMI
file was generated using Enterprise Architect and this *.XMI
file was used to generate the RDF schema in
Eclipse/CIMtool.
The CIM/ XML messages were generated for the
assets CT, PT and PMU and also the associated
measurements. These CIM/XML files were validated against
the relevant RDF schemas that were earlier generated.
Figure 6 shows the steps that are involved in the generation
of a valid CIM/XML file.
The validation of these CIM/XML files was
incorporated into the sensor Web which reads the CIM/XML
and validates it. Figure 7 shows the entire process from
generation of CIM/XML models to where they are used.
Using the ‘Data Exporter’, power system raw data are read
and written in the CIM/XML format. Now this CIM/XML is
fed into the sensor web, which first validates it using a
suitable parser. The parsed data is then stored in spatial
database or in sensorML files. These data are fed into the
Sensor Observation Service (SOS) server which runs the
semantic web services. As of now, it is programmed to
perform State Estimation and Contingency Analysis using
the data that are present in the SensorML files and Spatial
Database.
Figure 8 shows the CIM/XML file that was generated
for the asset ‘Phasor Measurement Unit’. This CIM/XML
was generated using the CIM model for PMU that was
developed (Figure 5). The CIM/XML has information about
three classes, ‘PMU’, ‘PMUTypeAsset’ and
‘PMUProperties’. The values contained by each of the
attributes are just dummy values. This CIM/XML message is
 Figure 5. Draft CIM asset model for PMU

State Contingency
Enterprise Estimation Analysis
Architect CIM/UML

Power System
Data Semantic
UML to RDF
Web Service
conversion
Data
Exporter SOS
RDF server
schema

validates CIM/XML SensorML/

files Spatial
Power
CIM/XML Database
System Data
Figure 7. Sensor Web architecture
Figure 6. Steps Involved In CIM/XML Generation
 <cim:PMU rdf:ID="170">
<cim:PMU.burden>52</cim:PMU.burden>
<cim:PMU.IRIG-BSignalType>Demodulated</cim:PMU.IRIG-BSignalType>
<cim:PMU.timingAccuracy>+/-2</cim:PMU.timingAccuracy>
<cim:PMU.totalVectorError>1</cim:PMU.totalVectorError>
<cim:Naming.name>Phasor Measurement Unit</cim:Naming.name>
<cim:PMU.PMUTypeAsset rdf:Resource="#2700"/>
<cim:PMU.PMUAsset rdf:Resource="#5700"/>
</cim:PMU>
<cim:PMUTypeAsset rdf:ID="2700">
<cim:PMUTypeAsset.burden>52</cim:PMUTypeAsset.burden>
<cim:PMUTypeAsset.IRIG-BSignalType>Demodulated</cim:PMUTypeAsset.IRIG-BSignalType>
<cim:PMUTypeAsset.synchrophasorMessageRate>15</cim:PMUTypeAsset.synchrophasorMessageRate>
<cim:PMUTypeAsset.timingAccuracy>+/-0.2</cim:PMUTypeAsset.timingAccuracy>
<cim:PMUTypeAsset.totalVectorError>1</cim:PMUTypeAsset.totalVectorError>
<cim:Naming.name>PMUTypeAsset</cim:Naming.name>
<cim:PMUTypeAsset.PMU rdf:Resource="#170"/>
<cim:PMUTypeAsset.PMUProperties rdf:Resource="#3700"/>
<cim:PMUTypeAsset.PMUAssetModel rdf:Resource="#6700"/>
</cim:PMUTypeAsset>
<cim:PMUProperties rdf:ID="3700">
<cim:PMUProperties.currentRange>10</cim:PMUProperties.currentRange>
<cim:PMUProperties.frequencyTrackingRange>40-60</cim:PMUProperties.frequencyTrackingRange>
<cim:PMUProperties.GPSTime>UTC</cim:PMUProperties.GPSTime>
<cim:PMUProperties.phaseAngleRange>–179.99° to 180°</cim:PMUProperties.phaseAngleRange>
<cim:PMUProperties.samplingRate>20</cim:PMUProperties.samplingRate>
<cim:PMUProperties.voltageRange>30-150</cim:PMUProperties.voltageRange>
<cim:Naming.name>PMUProperties</cim:Naming.name>
<cim:PMUProperties.PMUTypeAsset rdf:Resource="#2700"/>
<cim:PMUProperties.PMUAsset rdf:Resource="#5700"/>
<cim:PMUProperties.PMUAssetModel rdf:Resource="#6700"/>
</cim:PMUProperties>

Figure 8. CIM/XML Messages For Phasor Measurement Device Asset Model

validated by the sensor web, and then the dummy data is
extracted from this file and stored in the appropriate
database to perform various pre-programmed tasks. At
present, many utilities just shy away from CIM/XML as it is
an overhead to enable CIM/XML for existing legacy
applications. Alternatively, many application vendors now
incorporate CIM features in their latest products so as to
ease the burden off the utilities that choose to go with latest
edition of an application.
5. SUMMARY
A common language is required by applications that
wish to communicate with each other. EPRI initiated the
development of Common Information Model for power
systems to enable application integration. The CIM/UML
model and CIM/RDF file accomplish the task of forming the
common language between applications thereby enabling
‘plug-and-play’ capability for the power system applications.
In power systems where wide-area monitoring is done, CIM
messages have to be exchanged between applications
operating under different utilities. The existing CIM models
for CT and PT were used and new model for PMU was
developed. These asset models in addition to the
measurement CIM is used by the sensor web to perform
automated tasks like state estimation, contingency analysis
and other tasks.
6. ACKNOWLEDGEMENT
This research was funded through United States
Department of Homeland Security/ Oak Ridge National Lab
Funds: 63886, Office of Naval Research (ONR) Grant No.
N00014-02-1-0623 and N00014-08-1-0080.
7. REFERENCES
[1] “Common Information Model (CIM)”: CIM 10 Version,
EPRI, Palo Alto, CA: 2001, 1001976.
[2] http://www.ucaiug.org/CIMug/default.aspx. Official site
for Common Information Modeling for power systems.
 [3] Dr Alan W. McMorran: "An Introduction to IEC 61970-
301 & 61968-11: The Common Information Model”
available at www.cimphony.org/cimphony/cim-intro.pdf
[4] Jian Wu – “Data Modeling for Shipboard Power System”
, MS Thesis, Department of Electrical & Computer
Engineering, Mississippi State University, 2004,
http://library.msstate.edu/content/etd/show.asp?etd=etd-
03252004-220340
[5] Xiaofeng Wang: “Data Modeling and Data Exchange for
Electrical Distribution Networks” – Dissertation for Doctor
of Philosophy, Michigan Technological University, Nov
2001
[6] RTDMS training available at
http://www.naspi.org/resources/training/2008_0122/rtdms_tr
aining_package.pdf
[7] Reynaldo Francisco Nuqui: "State Estimation and
Voltage Security Monitoring Using Synchronized Phasor
Measurements", Department of Electrical & Computer
Engineering, Virginia Tech, 2001
http://scholar.lib.vt.edu/theses/available/etd-07122001-
030152/unrestricted/rnuqui_dissertation.pdf
[8] http://www.w3.org/2001/sw/ . W3C official website for
semantic web related activities.
[9] Robin Podmore, David Becker, Rob Fairchild, Marck
Robinson: “Common Information Model – A Developer’s
Perspective” in Proc. System Sciences, 1999. HICSS-32.
Proceedings of the 32nd Annual Hawaii International
Conference, pp-6
[10] http://www.selinc.com/sel-421.htm.
SEL-421 Instruction Manual available at Schweitzer
Engineering Laboratories (SEL) website.
[11] http://www.w3.org/TR/rdf-concepts/. W3C website
explaining RDF concepts.
[12] www.cimtool.org. Website for the Eclipse plug-in
CIMtool.
8. BIOGRAPHIES:
Vinoth M. Mohan is an M.S.E.E. student at Mississippi
State University. He received his B.E degree in Electrical
and Electronics Engineering from Panimalar Engineering
College, India in 2005. He worked as a software
programmer in Infosys Technologies Limited, India for
around 2 years before pursuing his MS degree. His interests
include electrical generation, transmission, distribution
networks and quantum mechanics.
Noel N. Schulz received her B.S.E.E. and M.S.E.E. degrees
from Virginia Polytechnic Institute and State University in
1988 and 1990, respectively. She received her Ph.D. in EE
from the University of Minnesota in 1995. She has been an
Associate Professor in the ECE department at Mississippi
State University since July 2001.She currently holds the
TVA endowed professorship in power systems engineering.
Her research interests are in computer applications in power
system operations including artificial intelligence
techniques. She is a NSF CAREER award recipient. She has
been active in the IEEE Power & Energy Society and served
as Secretary for 2004-2007 and Treasurer for 2008-2009.
She was the 2002 recipient of the IEEE/PES Walter Fee
Outstanding Young Power Engineer Award. Dr. Schulz is a
member of Eta Kappa Nu and Tau Beta Pi.
Anurag K. Srivastava received his Ph.D. degree from
Illinois Institute of Technology (IIT), Chicago, in 2005, M.
Tech. from Institute of Technology, India in 1999 and B.
Tech. in Electrical Engineering from Harcourt Butler
Technological Institute, India in 1997. He has been working
as Assistant research professor at Mississippi State
University since September 2005. Before that, he worked as
research assistant and teaching assistant at IIT, Chicago,
USA and as Senior Research Associate at Electrical
Engineering Department at the Indian Institute of
Technology, Kanpur, India as well as Research Fellow at
Asian Institute of Technology, Bangkok, Thailand. His
research interest includes real time simulation, power system
modeling, power system security, power system
deregulation and artificial intelligent application in power
system. Dr. Srivastava is member of IEEE, IET, Power &
Energy Society, Sigma Xi and Eta Kappa Nu. He is recipient
of several awards and serves as reviewer for IEEE
Transactions, international journals and conferences.