IEEE Power & Energy Magazine - January/February 2016 - 72

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 2. Profile relationships.

The relationships of the canonical model, profile, schema,
and instance data are shown in figure 2. 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 artifacts. [specific
tools include cImTool (www.cImTool.org), sparx enterprise architect release 12, and cImcontextor (www.cimug.
org).] Iec standard 62361-100, CIM Profiles to XML Schema
Mapping, defines how profiles should map into XsD, and
similarly Iec 61970-501 describes how rDfs is produced
from a profile definition. IT professionals can then leverage
the standard IT schema artifacts in implementations that
manage instance data within business processes.

Examples
added to the cIm, it typically is not implemented right away.
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 the cIm has increased, the standards groups
have attempted to initiate extensions that would ensure the
impact on existing implementations is minimized.

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. a full explanation of how to implement nonstandard extensions is provided in the "cIm model
management" document.

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 outlined in Iec 61968-100. The reason
for profiling is to naturally impart a degree of consistency
and uniformity that enables the 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 that 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 rDf schema (rDfs)
that IT professionals can use to implement, validate, or otherwise assist in the actual exchange of instance data supporting a business process.
72

ieee power & energy magazine

In its simplest form, a profile is a selection of the specific
parts of interest from the complete canonical model. In
figure 1, 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 attributes. (The endDevice and Terminal inheritance trees have been reduced to
improve clarity, but all attributes have been retained.) The
attributes cover a number of different data applications that
are defined as multiple profiles.
The connectivity information for node-breaker and
bus-branch models is shown in the upper right of figure 1.
each conductingequipment has a number of terminals corresponding to the number of 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 bus
connecting all injections and nonzero impedance elements.
The Topologicalnode represents the power flow buses in
canonical cIm, and the terminal also has a reference to
Topologicalnode.
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 connects the equipment
Busbarsection BB1 (where there is a voltage measurement),
PowerTransformer T1 and aclinesegment cable1.
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 Identifiedobject.mrID and Identifiedobject.name attribute from Identifiedobject have been retained in the four
classes. energyconsumer retains only the p and q attributes
january/february 2016

http://www.cImTool.org http://www.cimug http://www.Identifiedobject.name

Table of Contents for the Digital Edition of IEEE Power & Energy Magazine - January/February 2016