ARTICLE 5: CIM - UNDER THE
HOOD
Lars-Ola Österlund, Kurt Hunter, Kendall Demaree, Margaret Goodrich, Alan McMorran, Tatjana Kostic
Scope
This article provides an overview of CIM based data exchanges, how they are created and how they may
be implemented within the enterprise or between utility entities. The primary purpose is to explain how
the CIM can be used to generate exchange packages and how those packages enable an integration
framework. Using the Common Information Model (CIM) as a basis for all exchange payloads ensures
the exchange content is clearly defined in a standard way and the data is interpreted the same across
different business domains.
Setting the stage
Early History – Transmission Data Exchange
The initial CIM canonical model was created to allow EMS-to-EMS import and export of network models
and to avoid the proprietary data formats that complicated data exchange between EMS systems.
However, it was discovered almost immediately that this model could also be used to exchange power
system data used in network analysis such as power flows, topology processing, state estimation, etc.
These subsets of data became known as profiles (see “CIM Profiles for Data Exchanges” for more
information). NERC was the first to suggest and define requirements for a profile that contained
sufficient data to solve a power flow. This resulted in the first profile known as the Common Power
System Model (CPSM) profile. The CPSM profile would be used by utilities and interconnections to
generate more accurate models and enhance grid reliability.
Once the data content of the profile was defined, the next step was to define the data format that
would be used within the data file itself. The canonical CIM supports both detailed node-breaker and
bus-branch models for network analysis applications. However, the CPSM profile was intended for use
in operational systems (EMS) and hence supports node-breaker models with detailed substations
including breakers, disconnectors, measurements, equipment structures within substations etc. This is
different from bus-branch models intended for power flow applications where all substation detail has
been replaced by power flow busses.
Network models have many object types (e.g. Breakers, Disconnectors, Measurements, VoltageLevels
etc.) and relationships between them. Representing these relationships in exchange documents can be
made by references (pointers) or by inclusion of the referenced data at the place of the reference.
Documents based on XML Schema can include referenced data by hierarchical nesting. Hierarchical
nesting was the only mechanism to support references in XML Schema when CPSM was created.
Hierarchical nesting of references has drawbacks; the same data may be referenced multiple times
resulting in duplication or the data is not available and can be referenced in another document. As a
result, it was decided to use a modified version of the RDF XML exchange format. This satisfies all the
industry requirements for the data exchange format and avoids the drawbacks imposed by XML
Schema. Hence, the CIMXML exchange format described in the IEC 61970-552 standard was created in
which all relationships are expressed as references.
The CPSM profile has since evolved into an extensive standard supporting many network analysis
applications as well as network related data such as locations and schematic diagrams, e.g. the ENTSO-E
CIM standard for Common Grid Model Exchange Standard (CGMES).
Recent Additions – Distribution and Market Data Exchange
While the base canonical CIM covers the needs for network analysis studies, the utility industry wanted
more. In particular, in the realm of distribution operations, where business processes were less
dependent on the network analysis model, but needed to support data exchanges with various
enterprise systems. The canonical CIM started growing beyond the network analysis view to support
data exchanges across the distribution domains including distribution operations (DMS), outage
management systems (OMS), geographical information systems (GIS), work management systems
(WMS), customer management systems (CMS), meter data management systems (MDMS) and various
distribution network planning applications. As the industry become more de-regulated, the base
canonical CIM grew to support market management systems as well as other external systems (e.g.,
enterprise resource planning, etc.). When integrating the above systems, it is important to specify not
only what data is exchanged, but also how the data is exchanged. This is typically described by expected
sequences of messages among interacting systems and typically relies on some kind of enterprise
messaging infrastructure with required qualities of service (e.g., guaranteed delivery, speed of delivery,
traffic logging for audit trails, security, etc.) – especially important for the case of business to business
(B2B) exchanges. It is also usual practice to provide a standard envelope for the payloads that can then
be exchanged by virtually any transport. A full description of the standard envelop and the various
messaging infrastructures that could be used are described in the IEC 61968-100 standard.
Now, we see the tendency for transmission utilities needing to integrate their enterprise systems and
they are taking advantage of the standard canonical CIM model and experience from the distribution
world. The inverse is also true, i.e., larger distribution utilities see the advantage in leveraging
distribution network models within many of their business processes and they are actively taking
advantage of the canonical CIM model and experience from the transmission world.
The following sections will show how the canonical CIM and profiling techniques can be used to define
data exchanges and provide a framework to integrate various enterprise systems in the electrical
industry.
The canonical model
The CIM canonical model is represented in Unified Modeling Language (UML) diagrams. There are 3
base packages contained in the canonical model:
1. IEC61970 – contains the base power system model including all base domain data types. These
classes and attributes are used by the other 2 packages as needed to fully specify the power
system models used by their domains.
2. IEC61968 – contains the classes and attributes used to model the distribution system and the
operational systems within the utility. These systems include the CIS, OMS, DMS, GIS, AMI,
MDM, etc.
3. IEC62325 – contains the classes and attributes used to model the market systems for the North
American and European style markets. These systems include the Day Ahead and Real-time
Markets.
Each package contains a set of objects/classes that describes things in the real world. An object or class
is a noun or thing that is owned or operated by an entity. An object or class is defined in terms of
attributes and relationships (associations both within and between other packages). A class attribute
describes significant aspects about the class such as the rating or resistance. Associations connect
classes and are assigned a role that describes the relationship in each direction. A single class in the
canonical CIM can have multiple relationships, but most relationships in the CIM simply carry the
referenced class name as the role.
Besides the packages and classes, there are a specific set of concepts that are also expressed in the UML
symbols:


Inheritance/Specialization
Simple association or relationship
The rules and conventions for naming of packages, classes, attributes, associations and data types are
fully defined in the CIM Model Managers Guide, an IEC Technical Report (IEC6xxxx-xxx).
Inheritance/Specialization
In UML, an arrow with an enclosed arrowhead is used to represent both inheritance and specialization.
An example of this symbol is shown between the Equipment class and the PowerSystemResource class
in Figure 2 below. In the figure, the equipment class inherits from the PowerSystemResource class and
therefore “inherites” all the attributes and associations of the PowerSystemResource or any classes that
are in that lineage. The equipment class is also a specialization of the PowerSystemResource class. In
that same figure, ConductingEquipment is a specialization of the Equipment class.
Simple Association/Relationship
A simple association is shown in UML as a single line with no arrowhead on either end. Each association
has a role name and a multiplicity. The multiplicity defines how many of the opposite class can be
associated to the far end. For example, if you have 0..n TapChangers that have an association to 0..1
RegulationSchedules, it means a tap changer can have 0 or 1 regulation schedules or 0 or 1 regulation
schedules can apply to 0 or many tap changers.
Local non-(IEC) standard extensions
Most implementations of the CIM include extensions based on the specific needs of the utility.
Extensions may be implemented in several ways but the recommended method is to generate a specific
package and sub-class the new classes as needed. A full explanation of how to implement non-standard
extensions is provided in the CIM Model Managers Guide.
CIM profiles for data exchanges
Overview
In this section we take a closer look at CIM profiles, how they are created and some of the different
capabilities and uses of profiles. Profiles describe the payload part of exchanges as might be exchanged
in files or as the payload section of message based exchanges described in IEC61968-100. The reason
for profiling is to naturally impart a degree of consistency and uniformity that enables development of
individual implementations but additionally, and most importantly, enhances and streamlines system
data integration activities.
CIM profiles are descriptions of a restricted part of the overarching CIM canonical model which are
relevant to a particular implementation such as an exchange. Profiles and the process of profiling are
performed in the schema. The end result of profiling is normally a concrete schema governing an
implementation such as an XSD or RDFS (RDF schema) that IT professionals can use to implement,
validate, or otherwise assist in the actual exchange of instance data supporting a business process.
CIM Canoncial Model
(UML)
Derived From
Profile
(OWL, UML, …)
Generates To
Profile Schema
(e.g. XSD, RDFS, … )
Conforms To
Instance Data
(XML, RDF/XML …)
FIGURE 1 PROFILE RELATIONSHIPS
The relationships of the canonical model, profile, schema, and instance data are shown in Figure 1. We
say a particular profile “is derived from” the canonical model from which it is a restriction. Each
element of the profile in turn “is derived from” a specific part of the canonical model and hence derives
a semantic.
Several CIM specific tools are available to help define the profile and to generate standard schema
artefacts.1 The IEC 62361-100 “CIM Profiles to XML Schema Mapping” standard defines how profiles
should map into XSD and similarly the IEC 61970-501 describes how RDFS (RDF Schema) is produced
from a profile definition. IT professionals can then leverage the standard IT schema artefacts in
implementations that manage instance data within business processes.
Examples
In its simplest form a profile is a selection of the specific parts of interest from the complete canonical
model.
CIM Canonical Model
EndDevices
0..*
UsagePoint
0..1
EndDevice
+ critical : Boolean
+ initialCondition : String
+ initialLossOfLife : PerCent
+ lotNumber : String
+ purchasePrice : Money
+ serialNumber : String
+ type : String
+ utcNumber : String
+ amrSystem : String
+ installCode : String
+ isPan : Boolean
+ isVirtual : Boolean
+ timeZoneOffset : Minutes
IdentifiedObject
+ mRID : String
+ name : String
+ description : String
PowerSystemResource
Equipments
0..*
UsagePoint
+ amiBillingReady : AmiBillingReadyKind
+ checkingBilling : Boolean
+ connectionState : UsagePointConnectedKind
+ estimatedLoad : CurrentFlow
+ grounded : Boolean
+ isSdp : Boolean
+ isVirtual : Boolean
+ minimalUsageExpected : Boolean
+ nominalServiceVoltage : Voltage
+ outageRegion : String
+ phaseCode : PhaseCode
+ ratedCurrent : CurrentFlow
+ ratedPower : ActrivePower
+ readCycle : String
+ serviceDeliveryRemark : String
+ servicePriority : String
ConnectivityNode
0..1
Equipment
+ aggregate : Boolean
+ normallyInService : Boolean
TopologicalNode
TopologicalNode
0..1
ConductingEquipment
0..1
UsagePoints
0..*
ConductingEquipment
Terminals
0..*
Conductor
+ length : Length
UsagePoints
UsagePointLocation 0..*
0..1
UsagePointLocation
+ direction : String
+ geoInfoReference : String
+ type : String
+ mainAddress : StreetAddress
+ accessMethod : String
+ remark : String
+ siteAccessProfile : String
ConnectivityNode
Switch
+ normalOpen : Boolean
+ open : Boolean
+ ratedCurrent : CurrentFlow
+ retained : Boolean
+ switchOnCount : Integer
+ switchOnDate : DateTime
Terminals
0..*
Terminals
0..*
Terminal
+ connected : Boolean
+ sequenceNumber : Integer
+ phases : PhaseCode
ACLineSegment
+ b0ch : Susceptance
+ bch : Susceptance
+ g0ch : Conductance
+ gch : Conductance
+ r : Resistance
+ r0 : Resistance
+ x : Reactance
+ x0 : Reactance
EnergyConsumer
+ customerCount : Integer
+ grounded : Boolean
+ p : ActivePower
+ pfixed : ActivePower
+ pfixedPct : PerCent
+ q : ActivePower
+ qfixed : ActivePower
+ qfixedPct : PerCent
FIGURE 2 SUBSET OF CIM CANONICAL MODEL
1
Specific tools include CIMTool (www.CIMTool.org), Sparx Enterprise Architect Release 12,
CIMContextor (www.cimug.org).
In Figure 2, we have a subset of the complete CIM Canonical model looking at a small section of the UML
covering the functional and metering components. Here the model inheritance tree is shown along with
all of the attributes2. The attributes cover a number of different applications of the data that are defined
as multiple profiles.
The connectivity information for node-breaker and bus-branch models are shown in the upper right of
Figure 2. Each ConductingEquipment has a number of Terminals corresponding to the number physical
connection points at the ConductingEquipment. In a node-breaker model, the connections are described
by ConnectivityNodes and the Terminals refer to the ConnectivityNodes where they are connected. As
closed Breakers or Disconnectors have zero impedance a network model builder (also called topology
processor) removes and replaces them with a power flow buse connecting all injections and non-zero
impedance elements. The TopologicalNode represents the power flow busses in canonical CIM and the
Terminal also has a reference to TopologicalNode.
Node-breaker example from IEC 61970-301 Figure 10
SS2
SS2
400
400 KV
KV
SS1-SS2
SS1-SS2
BB1
BB1
Volts
(KV)
P1
(MW)
CN5
P2
(MW)
CN4
BR1
BR1
CN3
Cable1
CN2
Cable2
CN1
Cable3
BR3
BR3
DC2
SS1
SS1
CN6
Explanations
Terminal
CNx ConnectivityNode
TPx TopologicalNode
BRx Breaker
BBx BusbarSection
SSx Substation
xKV Voltagelevel
Tx PowerTransformer
SSx-SSy Line
Measurement
CN8
T1
Resulting bus TopologicalNode x (TPx)
in substation SS2 voltage level 400KV
after removal of closed switches
BR3, DC2 and BR1. TPx contain
ConnectivityNodes that has been
reduced i.e. CN6, CN5, CN4, CN3
SS4
SS4
CN7
110KV
110KV
BB1
TPx
Cable1
T1
FIGURE 3 EXAMPLE COMPUTATION OF A POWER FLOW BUS
Figure 3 shows how the Breakers/Disconnectors BR3, DC2 and BR1 as well as ConnectivityNodes CN6,
CN5, CN4 and CN3 are replaced by the power flow bus TopologicalNode TPx. TopologicalNode TPx
connect the equipment BusbarSection BB1 (where there is a voltage Measurement), PowerTransformer
T1 and ACLineSegment Cable1.
Node-breaker and bus-branch models can be easily combined by converting bus-branch
ToplogicalNodes into ConnectivityNodes and then merging the two.
2
The EndDevice and Terminal inheritance trees have been reduced to improve clarity, but all
attributes have been retained
Bus-Branch Profile
EnergyConsumer
+ mRID : String
+ name : String
+ p : ActivePower
+ q : ActivePower
ACLineSegment
+ mRID : String
+ name : String
+ length : Length
+ bch : Susceptance
+ gch : Conductance
+ r : Resistance
+ x : Reactance
ConductingEquipment
1
TopologicalNode
+ mRID : String
+ name : String
TopologicalNode
1
Terminals
1
Terminals
2
Terminals
1..*
Terminal
+ mRID : String
+ name : String
+ connected : Boolean
+ sequenceNumber : Integer
+ phases : PhaseCode
ConductingEquipment
1
FIGURE 4 SUBSET FOR BUS-BRANCH PROFILE
In Figure 4 we can see a subset of this canonical model in a small Bus-Branch profile. Four of the classes
from the original canonical model have been used with a subset of attributes from each. The
inheritance has been collapsed and the mRID and name attribute from IdentifiedObject have been
retained in the four classes. EnergyConsumer retains only the p and q attributes from the canonical
model class and all other attributes have been omitted from the profile. The ACLineSegment class
retains only the basic attributes required for simple power flow with the zero-sequence attributes from
the canonical model discarded for this profile.
At the Terminal level we retain the link to TopologicalNode as this is the CIM class for representing a
computed bus in a bus-branch representation of a model. The ConnectivityNode association is not
retained as this is used for node-switch models and is not required for our bus-branch profile. All
association multiplicities have been tightened so they are no longer optional. For some associations the
minimum and maximum multiplicities are the same, so the EnergyConsumer must have one Terminal
association while the ACLineSegment must now have two. Other classes have a restricted minimum and
unrestricted maximum, so the TopologicalNode must have at least 1 Terminal. The direction of the
association is also defined at the profile such that an implementation knows which side of the
association should be serialised.
Node-Switch Profile
EnergyConsumer
+ mRID : String
+ name : String
+ p : ActivePower
+ q : ActivePower
Switch
+ mRID : String
+ name : String
+ normalOpen : Boolean
+ open : Boolean
+ retained : Boolean
ConnectivityNode
+ mRID : String
+ name : String
ConductingEquipment
1
ConnectivityNode
1
Terminals
1
Terminals
2
ConductingEquipment
1
Terminals
Terminals
1..*
Terminal
+ mRID : String
+ name : String
+ connected : Boolean
+ sequenceNumber : Integer
+ phases : PhaseCode
2
ACLineSegment
+ mRID : String
+ name : String
+ length : Length
+ b0ch : Susceptance
+ bch : Susceptance
+ g0ch : Conductance
+ gch : Conductance
+ r : Resistance
+ r0 : Resistance
+ x : Reactance
+ x0 : Reactance
ConductingEquipment
1
FIGURE 5 SUBSET FOR NODE-SWITCH PROFILE
A second profile is shown in Figure 5 that is similar to that of the Bus-Branch profile, re-using 3 of the 4
classes with the addition of the Switch and ConnectivityNode. While the Terminal and EnergyConsumer
class attributes are the same, the ACLineSegment also includes the zero-sequence attributes, and the
Switch class from the canonical model is included with a subset of its attributes. In this profile, the
Terminal-ConnectivityNode association is used rather than the Terminal-TopologicalNode, requiring the
inclusion of the ConnectivityNode class and the corresponding relationship to Terminal and the removal
of the TopologicalNode.
End Device Profile
EndDevice
+ serialNumber : String
+ type : String
+ amrSystem : String
+ installCode : String
+ isPan : Boolean
EndDevices
1..*
UsagePoint
1
UsagePoint
+ mRID : String
+ phaseCode : PhaseCode
+ ratedPower : ActrivePower
UsagePointLocation
0..1
UsagePoints
0..*
Equipments
1
EnergyConsumer
+ mRID : String
+ customerCount : Integer
+ grounded : Boolean
+ p : ActivePower
+ q : ActivePower
FIGURE 6 END DEVICE PROFILE EXAMPLE
Moving outside of the functional model exchange, a simple End Device Profile example is shown in
Figure 6. This uses the EndDevice and UsagePoint classes with a small subset of their attributes. The
EnergyConsumer class is re-used with some additional attributes added from the canonical model. The
general UsagePoint-Equipments relationship has been restricted to only apply to EnergyConsumer (a
subclass of Equipment) and, as with the other profiles, the multiplicities have all been restricted and the
direction defined.
How IEC uses CIM profiling
The IEC has standardized certain profiles using selected technologies and different options within the
flexibility of the profiling process. These techniques are available for any organization using CIM
standards and are often employed where specific business processes need exchange implementations
that have not been standardized and may include local CIM canonical model extensions as discussed in
the CIM modelling guide.
Tables 1, 2 and 3 below show the relevant IEC and W3C standards involved in profiling. These standards
describe the domain models and the companion profiling standards that have been developed to date.
It is anticipated that additional standards will be developed as new use cases or requirements are
defined.
Type of Standard
CIM Canonical Model
CIM Canonical Model
Profile Standards
IEC 61970 Standards for Transmission
IEC 61970-301
IEC 61970-302
IEC 61970-4xx Profile
(the CPSM Profile is IEC61970-452)
IT Schema
IEC 61970-501
Instance Data
IEC 61970-552
Type of Standard
CIM Canonical Model
IEC 61968 Standards for Distribution
IEC 61968-11
Profile Standards
IEC 61968-3 through IEC 61968-14
(the Metering and Control Profile
standard is IEC 61968-9)
IT Schema
W3C XML Schema
IEC 62361-100
IEC 61968-100
Description
Base Power System Model
Base Dynamics Model
One or more companion
standards that define a profile
based on a use case
W3C RDF Reduced Schema
Describes how the RDF
Reduced Schema is produced
and used
W3C RDF XML as described by
RDF Schema. Describes how
the RDF XML is produced.
This is also known as the
payload.
Description
Base Distribution Operations
Model
One or more companion
standards that define a set of
messaging profiles based on
an operational system and its
use cases
The W3C XML Schema
standard describes how the
XML Schema (XSD) is
Instance Data
W3C XML
Type of Standard
CIM Canonical Model
Profile Standards
IEC 62325 Standards for Markets
IEC 62325-301
IEC 62325-305
IEC 62325-450
IEC 62325-452
IT Schema
W3C XML Schema
IEC 62361-100
Instance Data
W3C XML
produced and used.
The IEC62361-100 companion
standard describes the XSD to
XML mapping that is required
for the CIM XML message
payload.
The IEC 61968-100 companion
standard describes the
Message Envelop which
contains the Header and the
Payload.
The W3C XML standard
describes the XML format.
Description
Base Market Model
One or more companion
standards that provide the
profiling guidelines (IEC62325305 ad IEC62325-450) or
define a profile based on a use
case (IEC62325-452)
The W3C XML Schema
standard describes how the
XML Schema (XSD) is
produced and used.
The IEC62361-100 companion
standard describes the XSD to
XML mapping that is required
for the CIM XML message
payload.
The W3C XML standard
describes the XML format.
Profiles can be derived from any part of the canonical model from any working group and, in the case of
project implementations requiring it, from local CIM extensions.
By design, the CIM profiling practice allows the same information to be exchanged in multiple
technologies, though in practice this does not typically occur. It is common for profiles to make
references to CIM data exchanged in different technologies, so the best technology choice can be made
for each business exchange.
Payload serialization level
Previous sections have addressed the canonical CIM and profile derivation from it by means of
restrictions. This section addresses the syntactic aspects of profiles and considerations for selecting a
syntax.
At present, standard CIM profiles get translated into one of two distinct flavours, both based on W3C
XML syntax, as graphically illustrated in Figure (A) for RDF Schema or RDFS and Figure 7(B) for XML
Schema or XSD.
(a)
(b)
FIGURE 7 – SAMPLE EXTRACT FROM (A) RDFS-BASED AND (B) XSD-BASED PROFILE.
The very first CIM payload type was defined in 1999 using W3C RDF Schema (RDFS) and the payload
instance data was thus serialised as a special dialect of XML, called RDF. The RDFS representation of a
profile has been defined in IEC 61970-501, and the instance data format, or the payload serialisation
format compliant to that schema has been called CIMXML and defined in IEC 61970-552. The subset of
RDFS used for some CIM profiles has been defined in such a way that the instance data expressed in
RDF, (Figure (A)) looks very flat and leverages the file-scope uniqueness of data as defined by that
syntax through RDF identifiers. In the profile (Figure Error! Reference source not found.(A)), this
corresponds to the attribute ‘ref’ (blue circle) and in the data file (Figure a) to the value in rdf:ID. To
ensure that there is no nesting at all, at the previous step (profile definition), the user is supposed to
apply shallow relationships (ref’s) to objects, which will preserve the flatness of the data.
RDFS based profiles are widely used for bulk network data model exchanges, for either full models or
the increments thereof. The syntax in itself is simple and the language allows the definition of ontologies
and reason on them. On the challenging side, the tooling support for validation, editing and parsing is
somewhat limited and may have a steep learning curve.
With the need of utility organisations to exchange data among heterogeneous systems and often
without the need for network models, the second flavour of syntax for payload types emerged as a
natural choice well suited for enterprise integration: “vanilla” XML that validates against the W3C XML
Schema (also referred to as XSD). The translation of CIM profiles into the XSD syntax is defined in IEC
62361-100 and is widely used for standard as well as for custom profiles. This syntax is the mainstream
integration technology with a myriad of tools supporting its development. It is well understood by both
application developers and integrators and is an integral part of web-enabled technologies. The profiles
defined with the XSD syntax in mind have no limitation in structure and are indeed often reflecting the
“navigation path” through relationships from the canonical CIM model. A graphical example is given in
Figure (B), with the red rectangle. It is possible to use the “shallow” references as in RDFS based profiles
(blue circle); however, there is no XSD native counterpart to RDF identifiers. Payloads may use CIM mRID
for identification but since distribution normally requires multiple names for a specific device, a battery
of name-related classes was added in base CIM15 to support object registries. XSD syntax also allows
multiple profiles for a single type (e.g., a street address with only street name, street number and postal
code; and a street address with all the available descriptors); defined locally or globally. Finally, the work
is in progress to support modularity of payload types by enabling the inclusion of a “profile snippet” into
multiple profiles. A sample instance data that may comply to an XSD-based profile is shown in Figure
(B).
…
<cim:Line rdf:ID="_4d03f2b7-ee96-4357-9d93-49e94b9ce6e9">
<cim:IdentifiedObject.name>container of L1230814041
</cim:IdentifiedObject.name>
<cim:Line.Region rdf:resource="#_c1d5bfc88f8011e08e4d00247eb1f55e"/>
</cim:Line>
<cim:BaseVoltage rdf:ID="_49bc162b-c206-40f7-acfb-051973aafe74">
<cim:BaseVoltage.nominalVoltage>10.50 </cim:BaseVoltage.nominalVoltage>
<cim:IdentifiedObject.description>Base Voltage
Level</cim:IdentifiedObject.description>
<cim:IdentifiedObject.name>10.50 kV</cim:IdentifiedObject.name>
</cim:BaseVoltage>
<cim:ACLineSegment rdf:ID="_49bc162b-c206-40f7-acfb-051973aafe74">
<cim:IdentifiedObject.name>L1230814041 </cim:IdentifiedObject.name>
<cim:Equipment.EquipmentContainer rdf:resource="#_4d03f2b7-ee96-4357-9d9349e94b9ce6e9"/>
<cim:ACLineSegment.r>0.1</cim:ACLineSegment.r>
<cim:ACLineSegment.x>0.1</cim:ACLineSegment.x>
<cim:ConductingEquipment.BaseVoltage rdf:resource="#_63893f24-5b4e-407c9a1e-4ff71121f33c"/>
…
</cim:ACLineSegment>
…
<m:Switches xsi:schemaLocation="http://iec.ch/TC57/2012/Switches#
Switches.xsd" xmlns:m="http://iec.ch/TC57/2012/Switches#"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<m:Switch>
<m:mRID>b9cd8d2a-56a2-45e3-89d0-caaabb9e2985 </m:mRID>
<m:normalOpen>false </m:normalOpen>
</m:Switch>
<m:Switch>
<m:mRID>567fdc86-0ccd-4a96-a318-bdc1a3015643 </m:mRID>
<m:normalOpen>true </m:normalOpen>
</m:Switch>
</m:Switches>
FIGURE 8 – SAMPLE (A) RDF AND (B) XML SYNTAX FOR CIM-BASED DATA.
Due to its widespread usage in the industry, the majority of new XSD based profiles for the standard CIM
are defined using XSD syntax, in particular those that support processes outside network model
exchanges. The syntax is equally well suited for configuration (“static” / bulk) and for operation
(“dynamic” / on-line) data exchanges, as illustrated with metering profiles from IEC 61968-9. On the
challenging side, there is at present no native mechanism for referencing objects and referencing may
be exclusively through dedicated naming classes.
Note that in theory, a profile defined for use with RDFS syntax can also be expressed with XSD syntax;
the other way round is possible only in a special case where the profile gets defined as if it were for
RDFS syntax, i.e., flat, with exclusive use of references.
Messaging and the 61968-100 WS and XSD structures
Once the message profile standards were generated it became necessary to define how these messages
would be implemented and integrated into the utility enterprise. While the existing XSD message
profiles were complete, these standards lacked the detailed information required to apply these
messages in the enterprise integration. To address this issue, the IEC 61968-100 standard was
developed. This standard defines a common message envelope composed of the following interface
components:



the content (or payload) of data exchanges among the actors
the contents of the header and optional request/reply constructs
definition of the transport used in the exchange
Once we have defined these components and how they will be implemented, we can specify concrete
data exchange payloads and all actors concerned with any given payload can progress in parallel and
independently of each other. They can also implement and test their local applications independently
as long as everybody programs to the agreed interfaces.
To allow for this level of flexibility, it is best to adopt an interface specification whose technologies are
independent of the hardware platform, operating system or programming language. This is the
approach also recommended and followed by utility enterprise integration standards such as IEC 61968.
In the section “Anatomy of an interface”, we will dissect a message derived from one such sample
interface.
Anatomy of an interface
We will analyze a message compliant with an interface that has the properties discussed above. The left
side of Figure 7 shows the general approach to defining communication interfaces by using
encapsulation or nesting. Those familiar with the OSI reference model for communication protocols will
recognize the idea: the object of the exchange (payload) is nested deepest and wrapped into some kind
of envelope. That envelope then becomes the object of exchange (payload) one level up and is again
wrapped into another kind of envelope. We have denoted three levels in our example:
– L1, the first level, that we will call domain interface level (Message payload);
– L2, the second level, that we will call message interface level (Message envelope); and,
– L3, the third level, that we will refer to as transport interface level (Transport message).
The fact that we can clearly separate the levels means that we can independently develop and test
“real” software at each level, while “mocking” the functionality of the other levels. This is an important
aspect of any project execution or implementation effort.
L3:
Transport
message
L2:
Message
envelope
L1:
Domain
data
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
… …
</soapenv:Header>
SOAP
Header
<soapenv:Body>
<msg:CreateEndDeviceControls>
<msg:Header>
<msg:Verb>?</msg:Verb>
<msg:Noun>?</msg:Noun>
<!--Optional:-->
… …
</msg:Header>
<!--Optional:-->
<msg:Request>
<!--Optional:-->
<msg:StartTime>?</msg:StartTime>
<!--Optional:-->
<msg:EndTime>?</msg:EndTime>
<!--Zero or more repetitions:-->
<msg:ID>?</msg:ID>
</msg:Request>
<!--Optional:-->
<msg:Payload>
<edc:EndDeviceControls>
<edc:EndDeviceControl>
<!--Optional:-->
<edc:mRID>?</edc:mRID>
<edc:description>?</edc: description>
<edc: drProgramLevel>?</edc:drProgramLevel>
… …
</edc:EndDeviceControl>
</edc:EndDeviceControls>
<msg:Format>?</msg:Format>
</msg:Payload>
</msg:CreateEndDeviceControls>
</soapenv:Body>
</soapenv:Envelope>
Message
envelope
SOAP
Body
Domain
data
FIGURE 7 – SAMPLE SOAP MESSAGE
Let us now look at the right hand side of Figure 10. This shows a set of very concrete technology choices.
– The domain interface level L1 reflects the payload whose type is called EndDeviceControls and it has
been derived from the canonical distribution CIM (defined in IEC 61968-9 and IEC 61968-11,
respectively), and is compliant with the W3C XML Schema format. That specific domain payload allows
an actor to send control actions to end devices (such as smart meters) by providing the identity of the
end device and the program level for demand response.
– The message interface level L2 reflects the message envelope expressed also in W3C XML Schema
format as defined in IEC 61968-100. This is the level where we need to provide extra information that is
required by the software that handles message exchanges on a bus and that does not need to “unpack”
the payload, but just to route it to the correct receiving applications. Typical information that must be
specified are the verb and the noun – telling what needs to be done (verb) with the content of the
payload (noun).
– Finally, the transport interface level L3 reflects the standard SOAP message (often meant when one
says Web Service), with the SOAP header and the whole of level L2 encapsulated in the SOAP message
body.
There may be cases where a single actor needs to exchange some of the messages within a single
organization and in a simplified way, without need for platform independence and overhead of, e.g. a
Web Service (and its SOAP implementation). To support this kind of exchange, we could simply skip the
transport interface level L3 and pass around the message envelope of level L2 with its containing
payload in level L1 by using a JMS broker (in a standard way, as in IEC 61968-100) or some other means
for message exchange.
The example above has used the payload (L1) in W3C XML format. Given the structure of the envelope
(L2), it allows embedding domain payloads in literally any format, including W3C RDF format.
Alternately, for certain data exchange scenarios, simple file exchange may be sufficient in which case the
domain payload (L1) would simply be the file to exchange; in this case, some non-standard preconfiguration needs to take place ( e.g. to state the URI of the file on a file system).
Interoperability
Overview
The CIM standard was always intended to enable interoperability. Originally it was interoperability
between applications that was expanded to interoperability between systems. Another expansion of
scope was from applications for network analysis to work processes and energy markets within a utility.
The network analysis has also grown from power flow applications to short circuit analysis, dynamics
analysis etc. Yet another expansion is support for network display layout, geographical locations, asset
information, asset health etc.
This expansion is ongoing and extensions are still added. In the EU, the adoption of the common energy
market, increased renewable production and reduction of CO2 emissions resulted in accelerated use of
the CIM. When ENTSO-E started to use the CIM in its Common Grid Model Exchange Standard (CGMES),
further CIM extentions were discovered.
The central architectural idea behind CIM is to describe data semantics such that exchanged data
objects can be traced back to the canonical CIM semantics. CIM supports this by its capability to
describe relationships between objects:


Equipment in the functional model (PowerSystemResurce CIM class) relate to physical
equipment in the asset model (Asset CIM class). This makes it possible to answer a question like;
what is the serial number and actual short circuit current (asset model) of the breaker I am
currently using in position Q1 (functional model) in my substation?
Registered resources in the market model relate to generating units in the functional model.
This is useful when a production schedule from the market is validated with Congestion Forecast
(CF) (e.g. in intra-day CF / day-ahead CF) or used in a Security Constrained Unit Commitment
(SCUC).
These are just a few examples of many relationships between the different parts of the CIM.
Relationships like this enable cross navigation between data exchanged according to different profiles.
Two use cases building on the above examples are:


A Supervisory Control and Data Acquisition (SCADA) system typically records how many times a
breaker operates. Knowing which breaker in the asset registry is used in the circuit monitored by
SCADA can then be used to tell the asset registry how many times the breaker has been
operated. This is needed to determine breaker wear.
A market system typically deals with net production from registered units at the plant level.
Knowing what functional generating units corresponds to a registered unit makes it possible to
map registered unit net production schedules on functional unit gross production also
considering outages and de-ratings. This mapping is needed for Congestion Forecast (CF) and
Security Constrained Unit Commitment (SCUC).
Relationships between objects require a concise global identification mechanism such that objects are
uniquely referenced and not mixed with each other. Human generated names have the drawback that
different objects are likely to have the same name, e.g. the substation name “Airport” may exist in many
places. Additionally names may need to change over time, but unique identification must be persistent.
Hierarchical naming is a usual way to get more precision as with postal addresses, internet addresses
etc. But naming schemes like this require authority support and administration for its maintenance. In
the CIM, the Master Resource ID (mRID) identification scheme is recommended for object identification.
For interoperability to be achieved data objects that need to be referenced have to be kept persistent by
the receiver of the data and they must have unique, persistent identification. In the CIM, the class
IdentifiedObject has been defined specifically as a superclass for any class that needs to be persistent
after it is initially exchanged. The master resource identifier attribute, “mRID,” of IdentifiedObject is
included in the CIM to provide a common method for persistent, unique identification. When used in a
data exchange the “mRID” is required to be unique within the context of the exchange. Global
uniqueness is achieved by using Universally Unique Identifiers (UUIDs), which is strongly recommended,
but not required.
In an ideal data exchange, UUIDs would be used as the mRIDs to uniquely identify all objects, but this
cannot always be achieved when working with existing applications that already have other established
methods of unique identification. In this case CIM naming attributes and classes such as the “name”
attribute on “IdentifiedObject” or the alternate name classes “Name,” “NameType,” and
“NameTypeAuthority” can be leveraged.
As mentioned above CIM has grown considerably since its creation. This has resulted in a reputation
that CIM is continuously changing which is actually true with respect to all extensions. The early parts
however have been stable, in particular in recent years. When a new model is added to the CIM it hasn’t
typically been implemented yet. As implementations appear, issues are normally discovered and
corrections are needed. Hence newer parts of the CIM are initially less stable; however, as
interoperability tests vet the CIM standards and usage increases, the model stabilizes. As the usage of
CIM has increased, the standards groups have attempted to initiate extensions that would ensure the
impact on existing implementations is minimized.
Data structuring / schema / semantic model
The CIM canonical model (see The canonical model) includes a very large number of classes and each
class has associations describing relationships with other classes. Most classes also have attributes
describing characteristics of the class. Any given work flow or data exchange will use only a fraction of
the classes, associations and attributes defined in the CIM. Profiles (see CIM profiles for data
exchanges) are defined to specify the specific subset of classes, associations and attributes from the CIM
that are used for a particular data exchange. It is these profiles that are tested in the Interoperability
tests. The tests ensure the exchange content is complete and that the participating actors can exchange
the profile and interpret it properly. For example, in a CPSM test, the instance data corresponding to
the profile content is exchanged and the participants are then required to use that data to solve a Power
Flow. This proves the participant is able to accept the data and interpret properly.
Each profile will result in a set of tests that will validate the profile contents and prove that the test
participants can accurately receive and act on the data. The exact tests will depend on the profile and
the use cases that were originally used to generate the profile.
Data composition by receiving systems
One of the main objectives of the CIM is to support utility business processes which normally require the
assembly or composition of data from a number of sources. These sources may use different exchange
technologies, different (but related) schema or structure, and different content which is often
referencing content from other sources.
Schema partitioning
Profile EQ
Class1
MRID
attr1
attr2
Class3
Class2
attr3
attr1
attr2
attr3
attr4
attr1
attr2
01
02
03
04
05
Instances from source 2
07
Instances from source 1
Instance partitioning
06
08
09
0a
0b
0c
0d
0e
0f
10
11
12
13
14
15
16
17
Profile TP
FIGURE 11 DATA PARTITIONING BY INSTANCE AND BY SCHEMA
As shown in Figure 11 by the vertical and horizontal axes, there are two main ways CIM data is
partitioned.
1) Partition by instance – e.g. by transmission operators or modeling authority
2) Partition by schema using profiles – e.g. by the kind of data: such as static network
equipment model (EQ) or topology data (TP)
TSO n
TSO 1
Outage
Coordinator
Network model part
Network model part
Approved Outages
Load Forecast
Day Ahead
Network Analysis
Load values
Figure 12 Business process consuming data from multiple sources
Figure 12 shows a business process (day ahead network analysis in this case) consuming data of
different forms from a number of sources, including multiple transmission system operator (TSO)
entities.
CIM
canonical
model
Legend
Conforms to
Derived From
Payload
exchange
Outage
Profile schema
Load Forecast
Profile schema
Profiling
process
Network Model
Profile schema
Outage Coordinator
Load Forecast
TSO 1
CIM
payload
TSO N
CIM
payload
CIM
payload
CIM
Payload
payload exchange
Day Ahead Network Analysis
FIGURE 8 BUSINESS PROCESS COMPOSING CIM DATA
Figure 8 shows how the exchanges of Figure 12 can be implemented using CIM. By considering all
exchanged data to be conforming to a common semantic model, we can describe how data from
different technologies, different sources, and different profiles will compose within a receiving system.
We expect the semantics and object identities to be valid across technologies such that, for example,
outages (exchanged by XSD based XML) could relate to the network model (exchanged by RDF oriented
CIM/XML). Additionally we may exchange both full models and incremental changes to be applied to
full model descriptions. Data from different sources and different profiles can link together given the
sources orchestrate consistent identities where such references are required.
At the most detailed level the data receiver may compose information by matching object identities,
typically and most conveniently by MRID when available. IEC does not standardize internals of business
process implementations, but the interface standards are designed such that a business process can
implement a consistent composed model of the various input standards. The following examples show
how this composition of various payloads functionally occurs at an object instance level.
payload 1
class A
MRID=1
attr1= X
payload 2
Receiver
unordered
class A
MRID=1
attr2=Y
class A
MRID=1
attr1=X
attr2=Y
FIGURE 9 COMPOSITION OF ATTRIBUTES ON AN OBJECT
Figure 14 shows an example of how a receiver with CIM data can compose new attributes on the same
business object instance. Such a case would be useful, for example, in combining powerflow equipment
model data for a generator (MRID=1) with dynamic simulation model data for the same generator from
another source.
payload 1
Receiver
class A
MRID=1
payload 2
Proxy
class A
MRID=1
class B
MRID=2
class A
MRID=1
unordered
class B
MRID=2
FIGURE 10 COMPOSITION OF REFERENCES AMONG OBJECTS
Figure 10 shows how a receiver can compose references across payloads. Typically the referenced
object (MRID=1) would be consumed from payload 1 before consuming a reference (payload 2), though
technically the payloads could be consume in any order.
Conclusion
When it was originally envisioned, the goal of the CIM was to provide interoperability between systems,
allow data exchanges to be easily defined and implemented and enable an enterprise architecture that
would shorten the time to integration. The extensive canonical model provided by the CIM provides the
common semantics that can be used to generate standard and custom profiles for use in data exchange
and enterprise integration. The CIM profiling approach makes organization of exchange payloads
consistent, where both producers and consumers agree upon meaning. But additionally, and perhaps
more importantly, the receiver has a clear understanding of how data from multiple sources, spanning
multiple profiles and exchange technologies, can be readily and unambiguously composed into a
cohesive model suitable for business analysis. As such, profiles and the profile methodology provide the
foundation to reach the goal. They support data exchange between applications or systems and provide
an integration framework to connect disparate systems into a complete enterprise architecture while
enabling full interoperability.
Definitions
The following table provides common terms and their definitions.
Term
Canonical CIM
Definition
This is an abstract model of domain or data exchange (our CIM UML).
Profile
This is a restriction of canonical CIM, a small subset of it as required for a
specific interface for external data exchanges. We use a profiling tool to
reduce canonical CIM to the desired content, and the tool produces a
schema that will govern the format of the instance data to be exchanged.
Payload
This is an instance of Profile according to a given syntax. We currently use
XML complying with RDFS or XSD.
Message
This is an instance of message envelope, e.g. Message.xsd (61968100),that includes one or more Payloads. It also contains the full context of
data exchange (verb, noun, etc.) to let the receiver know what to do with
the received payload.
Dataset
Model
Electrical network model
Base model
As built model
TBD
Data that describes an existing entity or thing.
A model or data describing an electrical network.
An electrical network model used as part of a case.
an electrical network model that corresponds to a constructed network
Case
Full model
Difference model or
Incremental model
complete set of inputs to a network analysis study case
A complete description of an electrical network model
TBD
Further Readings
– up to 6 items
CIM modelling guide
CIM Primer
A. deVos, October 2000, "Simplified RDF Syntax for Power System Model Exchange",
http://www.langdale.com.au/DAF/PSModelExchange.Pdf.
A. deVos, S. Widergren, J. Zhu, "XML for CIM Model Exchange", 22nd IEEE Int. Conf. On Power Industry
Computer Applications (PICA), Conference Proceedings, Sydney, Australia, May 2001, pp31- 37.
Authors
Lars-Ola Österlund is with ABB Enterprise Software, Västerås, Sweden.
Kurt Hunter is with Siemens Smart Grid, Minnetonka, MN, USA.
Kendall Demaree is with Alstom Grid, Inc., Redmond, WA, USA.
Margaret Goodrich is with Project Consultants, LLC, Shell Knob, MO, USA.
Alan McMorran is with Open Grid Systems Ltd., Glasgow, UK.
Tatjana Kostic is with ABB Corporate Research, Baden-Daettwil, Switzerland.