ARTICLE 5: CIM - UNDER THE
HOOD
Authors; Lars-Ola (LOO), Kurt (KH), Becky (BI), Kendall (KD), Margaret (MG), Tanja (TK)
Change history
Version 4 April 28, 2015
2015-05-07, TK: Accepted all changes, kept change tracking; comments to parts of document nonassigned to me started with “(note TK: ” – discuss the coment and then remove. I added below my
figures what should look like a caption, but didn’t use any Word’s “insert caption” command until we
confirm which figures are to keep. Continued editing after our web conference.
2015-05-16 version 5, LOO: Accepted all previous changes and merged texts from myself, Kurt and
Kendall.
2015-05-26 version 6, BLI: Added text to separation of roles
2015-05-26 version 7 LOO: Accepted all changes.
2015-05-29 version 8 KDD: Added composition section details (more work to do but about right size.)
Some minor text edits in the profiles section. No changes or comments outside these two sections.
2015-06-04 version 9 KLH: Added comments and made minor text corrections and clarifications.
I’m concerned that this article goes deeper than is going to be useful for most readers without providing
at least a basic understanding of the CIM UML model. I think we need to add a short section on the CIM
UML with concrete examples and try to include the same concrete examples where ever possible
throughout the article.
The big picture
Scope statement; LOO
Primarily about (related) exchange governance. Each payload is typically not simply related to itself.
Tailoring local related exchanges
Separation of roles (might be intro, roadmap for reader); MG, TK
LOO would like to do a little intro on business values of the CIM.
Two styles of exchanges
-
Model based / relational exchange
Enterprise business process exchanges
Margaret had a good discussion of how CAISO has made this an important concern. Maybe we can get
a CAISO statement on the topic.
(note TK: Margaret & all, I’ve just put some thoughts in, feel free to remove/adapt/whatever; don’t
know whether to refer to EPRI CCAPI project?)
Historicaly, the initial CIM canonical model and its first profile (at that time called “CIMXML NERC
profile”) were created to allow for an EMS intra-application exchange of power system model data, such
as typically used in network analysis applications (state estimation, topology processing, power flow,
security analysis), as well as EMS-to-EMS import and export of network model snapshots. Very naturally
for this kind of usage, domain experts are expecting to work with “input and output data files”. This has
driven the initial efforts to produce a network model “data format” that contains semantics within the
data file itself (as a replacement to counting columns up to 72 characters in a text data file of some
format).
…
The base canonical CIM was covering the needs for network analysis studies, but the utility industry
wanted more, in particular in the realm of distribution operations, where business processes are (were?)
less dependent on the network analysis model, but in contrast needed to support data exchanges with
various enterprise systems. Canonical CIM started growing beyond the “pure network analysis” view to
support data exchanges between the distribution operations (DMS) and outage management systems
(OMS), asset record systems such as geographical information systems (GIS), work management systems
(WMS), customer management systems (CMS), meter data management systems (MDMS), various
network planning applications as well as market management systems and external systems (e.g.,
enterprise resource planning, etc.). When integrating the above systems, it is important to specify not
only the “what” (canonical data exchanged that those heterogenious systems and their internal data
stores will require to function properly in the enterprise environment), but also the “how” side of data
exchange. That “how” side is normally not file-based, but rather relies on an 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 some kind of envelope for the payloads that can then be
exchanged by virtually any transport. This is what IEC 61968-100 does.
(note TK: Margaret, here to hook the story of 61968-100? See also section “Messaging and the 61968100 WS and XSD structures”, you may want to pull some content of it up here.)
(note BI: Adding in text here to cover the markets for US and EU. It will also cover CAISO’s approach and
concerns in developing market interfaces and the separation of roles.)
During the formation of energy markets within the North American region, the need to standardize
market exchanges became apparent. At this time, a committee of Regional Transmission Owners was
formed to address the definition of the energy market supplemental model data and market
communications for the North American markets. These use cases were developed as the market
operation extensions which are now contained within CIM.
During the same time, the European Network of Transmission System Operators for Electricity (ENTSOE) was being formed to address the need for a European wide harmonization of network access and
communication. ENTSO-E supported the integration of member Transmission System Operator’s (TSO)
business requirements and use cases into the CIM. The additional use cases from ENTSO-E have been
developed and are included within the CIM market management.
(note TK: When done, remove the bullets below)
Focus of domain experts
Semantics
Requirements for persistence and QoS
Management of datasets, frames, exchange sequences
Sensible minimal exchanges
Focus of IT experts, more related to 61968-100, the story behind
the 100
Files, middleware, security
Efficiency, persistence, QoS delivery
Technology
Data structuring / schema / semantic model; KH
The CIM 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 are defined to specify the specific subset of classes,
associations and attributes from the CIM that are used for a particular data exchange.
Because the information included in a profile is based on the CIM canonical model the meaning of the
information is clearly understood. For instance, any profile that includes the class and attribute defining
the resistance of an AC transmission line (attribute “r” of the “ACLineSegment” class) will have the same
understanding of the data being exchanged.
The CIM UML model uses a type system that also helps to ensure a clear understanding of the
attributes. CIM data types are defined for common electrical quantities such as “ActivePower,”
“AngleRadians,” “Resistance,” and “Susceptance.” For instance, attribute “r” of the “ACLineSegment”
class uses the CIM data type “Resistance”.
In most cases a data exchange will need to reference data objects previously exchanged. For instance
the results of a power flow will reference the individual pieces of equipment from a network model that
was previously exchanged. When changes are made to a network model an incremental update can be
exchanged that will reference the objects that have been added, modified or deleted.
Data objects that may need to be referenced have to be kept persistent by the receiver of the data and
they must have unique, persistent identification. In 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 a
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.
data partitioning (Modeling Authority Sets concepts); LOO
(note TK: Be explicit in limiting the scope here to the big TSOs and not scare away the small DSOs who
need not bother with this.)
(note TK: By the way: what is “non-schema data”? Do you mean horizontal partitioning, also known as
sharding? If so, use an analogy, this may help others (who don’t know about MAS) understand the
topic).
As described in the “Data structuring” section CIM data is divided into profiles that enable exchange of
non-overlapping data facilitating a modular division of data in sets that can be exchanged when needed.
But in large interconnected power systems models describing the complete power system may become
very large. As a part of a power system is typically managed by an authority, e.g. an organization being
responsible for or operating the part, the CIM concept of a Model Authority Set has been created. In an
interconnected power system with multiple responsible organizations the Model Authority Sets are
defined by the boundaries between them. The Model Authority Set concept is another way to
modularize power system data and enable exchange of power system data that link together through
shared boundary definitions.
The canonical model , keep small; MG
UML and basic rules of CIM canonical model
With some rationale for things like unique class names, package changes agility
Non-cyclic dependencies, meaning of dependencies
Make reference to the existing guide, make that guide an IEC TR.
Local non-(IEC)standard extension
(note TK: Some of this is also available in the model management guide; here it would be good to cover
“watch for this” aspects learnt from experience.)
CIM exchange Profiles – deep dive ; KD
CIM exchange Profiles – deep dive
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 61968-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 work
in the domain of 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)
Is Based On
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 canonical model, profile, schema, and instance data are shown in Figure 1. We say
a particular profile “is based on” the canonical model from which it is a restriction. Each element of the
profile in turn “is based on” a specific part of the canonical model and hence derives a semantic.
Several CIM specific tools, such as the open source CIMTool (www.CIMTool.org), are available to help
define the profile and to generate standard schema artifacts. The IEC 62631-100 “Naming and Design
Rules” standard defines how profiles should map into XSD and similarly 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.
Profiling in detail
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
TopologicalNode
TopologicalNode
0..1
ConductingEquipment
0..1
UsagePoints
0..*
ConductingEquipment
Terminals
0..*
Conductor
+ length : Length
Switch
+ normalOpen : Boolean
+ open : Boolean
+ ratedCurrent : CurrentFlow
+ retained : Boolean
+ switchOnCount : Integer
+ switchOnDate : DateTime
FIGURE 2 SUBSET OF CIM CANONICAL MODEL
ConnectivityNode
0..1
Equipment
+ aggregate : Boolean
+ normallyInService : Boolean
UsagePoints
UsagePointLocation 0..*
0..1
UsagePointLocation
+ direction : String
+ geoInfoReference : String
+ type : String
+ mainAddress : StreetAddress
+ accessMethod : String
+ remark : String
+ siteAccessProfile : String
ConnectivityNode
Terminals
0..*
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
Terminals
0..*
Terminal
+ connected : Boolean
+ sequenceNumber : Integer
+ phases : PhaseCode
IN
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, 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 attributes1. The attributes here cover a number of different applications of the data that are
defined as multiple profiles.
1
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 3 SUBSET FOR BUS-BRANCH PROFILE
In Figure 3 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 classFigure 6 IEC profiling practices and standards 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 removed
as this us used for node-switch models and so is not required for our bus-branch profile. All association
cardinalities have been tightened so they are no longer optional. For some associations the minimum
and maximum cardinalities are the same, so the EnergyConsumer must have one Terminal association
while the ACLineSegment must now have two. Other 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 so 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 4 SUBSET FOR NODE-SWITCH PROFILE
A second profile is shown in Figure 4 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 5 END DEVICE PROFILE EXAMPLE
Moving outside of the functional model exchange, a simple End Device Profile example is shown in
Figure 5. 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 cardinalities have all been restricted and the
direction defined.
A profile may further restrict multiplicities of properties, or restrict the range of datatypes (e.g. require a
String to be less than 32 characters). These restrictions can be applied individually to properties by
modifying the multiplicity or assigning a restricted datatype. Even more complex restrictions are
possible via creating multiple profile classes or associations based on one canonical class. IEC 62325450 describes these advanced restriction capabilities, but using the simplest form of restrictions the
business case requires is recommended.
Selection of attribute properties is very straight forward with possible complication of requiring a
restricted datatype.
Association properties may be selected so that the association is wholly contained within the profile as
in the Bus-Branch and Node-Switch profiles in Figures 3 and 4. In the End Device Profile Example in
Figure 4 the UsagePointLocation association indicates there is an association to the UsagePointLocation
but the class is not within the profile. This implies that the class is present in another profile and so at
the instance data level there would be a dependency between the data defined by this End Device
Profile and data defined by another profile that contained the geographical data.
The profile also normally defines the direction of the association for serialization purposes, though the
semantics of both roles of the canonical model must be respected. In the case of XSD profiles
relationships can be expressed in terms of containment which requires the containing object to also be
exchanged within the same payload.
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
[need reference???].
CIM Canoncial Model
62325-301
61968-11
61970-301
Manual profile generation
IEC New Work Item Proposal
will describe rules
Profiles
61970-4xx
62325-305x
(regional profile)
61968-xx
(excluding:
61969-1
61968-11)
Manual profile generation
62325-450
62325-4xx
W3C RDF Schema
Generation 61970-501
W3C XML Schema generation
Schema for IT consumption
W3C RDF Schema
W3C XML Schema (XSD)
CIMXML payload
Syntax 61970-552
W3C RDF
W3C XML
Instance Data (Payload)
W3C RDF XML
Described by
RDF Schema
role A[0..1]
Described by role B[0..1]
XML Schema
role D[0..n]
FIGURE 6 IEC PROFILING PRACTICES AND STANDARDS
If document numbers listed a section that shortly describe each document is required.
A box section for those that want the details how to find CIM documents.
Figure 6 shows the relevant IEC and W3C standards involved in profiling. Note that profiles can be
based on any part of the canonical model from any working group and, in the case of project
implementations requiring it, local CIM extensions.
Of note is the introduction of a contextual profile (IEC 62325-450) from which further profiles are
derived. This contextual profile is useful for restricting the canonical model in a common manner for a
set of profiles as is required for example in the European market exchanges. The profiling techniques
are the same at both levels but only the final IEC 62325-45x series of profiles produce payload schema.
For the European market messages, the IEC 62325-450 performs more complex restrictions and enables
the individual IEC 62325-45x profiles to be simple profile selections and XSD serialization specifications.
Profiles for network analysis models and other closely related data are described in the IEC 61970-4xx
profiles and are typically serialized using RDF technology as described in IEC 61970-501 and IEC 61970552. Profiles for Metering, Assets, Work Management, and similar areas covered by IEC TC57 WG14
typically use XSD based messages and are described in IEC 61968-x standards. 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 (and special features); TK, BI
(note TK: Below is all new text, I hope it all sounds impartial – with the good, bad for all. There is
certainly space for improvements !)
Note LOO – Alan has examples of both CIMXML and XSD style messages. Alan put them in here.
<ns0:EventMessage xmlns:ns0 = "http://www.iec.ch/TC57/2011/schema/message">
<ns0:Header>
<ns0:Verb>changed </ns0:Verb>
<ns0:Noun>Switches </ns0:Noun>
<ns0:Revision>1 </ns0:Revision>
</ns0:Header>
<ns0:Payload>
<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>
</ns0:Payload>
</ns0:EventMessage>
<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:ACLineSegment.bch>0.0</cim:ACLineSegment.bch>
<cim:Conductor.length>1.0</cim:Conductor.length>
<cim:ACLineSegment.gch>0.0</cim:ACLineSegment.gch>
<cim:Equipment.aggregate>false</cim:Equipment.aggregate>
<cim:ConductingEquipment.BaseVoltage rdf:resource="#_63893f24-5b4e-407c9a1e-4ff71121f33c"/>
<cim:ACLineSegment.r0>0.3</cim:ACLineSegment.r0>
<cim:ACLineSegment.x0>0.3</cim:ACLineSegment.x0>
<cim:ACLineSegment.b0ch>0.0</cim:ACLineSegment.b0ch>
<cim:ACLineSegment.g0ch>0.0</cim:ACLineSegment.g0ch>
<cim:ACLineSegment.shortCircuitEndTemperature>160.0</cim:ACLineSegment.sho
rtCircuitEndTemperature>
</cim:ACLineSegment>
Previous sections have addressed the upper half of the Figure xyzProfiling, namely canonical CIM and
profile derivation from it by means of restrictions. This section addresses the rest, i.e., syntactic aspects
of profiles and considerations to take into account when selecting a syntax.
At present, standard CIM profiles get translated into one of two distinct flavours, both based on W3C
XML syntax; (note TK: here to refer to the picture and text below).
The very first CIM payload type was defined in early 2000’s (or late 1990?) 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 still today has been defined in such a way
that the instance data (expressed in RDF) looks very flat and importantly, leverages the file-scope
uniqueness of data as defined by that syntax – namely, through so called RDF identifiers. To ensure that
there is no nesting at all, at the previous step (profile definition), the user is supposed to apply shallow
relationships (like pointers) to objects, which will preserve the flatness of the data (note TK: here to
refer to something from the picture).
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 to define ontologies and
reason on them. On the negative side, the tooling support for validation, editing and parsing is
somewhat limited and may have a steep learning curve.
With the need of (initially: distibution) utility organisations to exchange data among heterogenious
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 miriad of tools supporting its development, 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. It is possible to use
the “shallow” references as in RDFS based profiles, however, there is no XSD native counterpart to RDF
identifiers - all the more that payloads may not use CIM mRID for identification, but rather the battery of
name-related classes, that have been added with 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.
Due to its widespread usage in the industry, majority of new XSD based profiles of 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” / online) data exchanges, as illustrated with e.g., metering profiles from IEC 61968-9.
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).
(note TK: When done, remove the three sets of bullets below)
Xsd and conforming XML
NDR details
References as hierarchical (nested) XSD.
References without MRID
Generalized references.
Rdf (RDFS, OWL)
RDF ID and MRID
Incremental
Open to other serialization forms or technologies CIM/E, JSON,
Thrift, proprietary binary, EXI …
Keep this section short but the concept needs to be covered.
Interoperability; LOO, TK, MG
Note LOO Move up to after the “Separation of Roles” section.
The CIM standard was already from its early beginning in 1994 intended to enable interoperability.
Originally it was interoperability between applications that has been widened to interoperability
between systems. Another widening was from applications for network analytics to work flows within a
utility and energy markets. The network analytics has also grown from power flow type of applications
to short circuit analysis, dynamics analysis etc. Yet another widening is support for network display
layout, geographical locations, assets information, asset health etc.
This widening is still ongoing and extensions are still added. In EU the consequence of the common
energy market, increased renewable production and reduction of CO2 emissions resulted in accelerated
use of CIM. When ENTSO-E started to use the CIM in its Common Grid Model Exchange Standard
(CGMES) needs to further extend the CIM were discovered.
The central architectural idea behind CIM is to describe data semantics such that exchanged data
objects can be traced back to the CIM semantics. An important feature of CIM is its capability to
describe relation between data objects, e.g.


Equipment in the functional model (PowerSystemResurces) relate to physical equipment in the
asset model. This makes it possible to answer a question like; what is the serial number and
actual short circuit current of the breaker I am currently using in position Q1 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
(e.g. in IDCF/DACF) or used in a Security Constrained Unit Commitment (SCUC).
These are just a few examples of many relations between the different parts of the CIM. Relations like
this enable cross navigation between data exchanged according to different profiles. Two use cases
building on the above examples are


A 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 plant level.
Knowing what physical generating units corresponds to a registered unit makes it possible to
map registered unit net production schedules on physical unit gross production also considering
outages and de-ratings. This mapping is needed for Congestion Forecast and Security
Constrained Unit Commitment.
Relations between objects require a concise global identification mechanism such that objects are
uniquely referenced and not mixed with each other. Human generated names has 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 way get more precisionas with location or internet addresses. But naming
schemes like this require authority support and administration for its maintenance. For CIM it has been
decided to use a Master Resource ID (mRID) to identify objects. The mRID is intended to support
computer identification of objects and processing of relations. The CIM standard strongly advice the use
of UUIDs as mRID. A UUID is a machine generated 128 bit value that is globally unique with a very high
probability. The mRID cannot replace human readable names and CIM support multiple human readable
names for an object.
When extending CIM it is important to have use cases such as those mentioned above in mind such that
the relations are added to support navigation across profiles. The relations like this need to be present
in the CIM canonical model to facilitate cross navigation between profiles. Hence a good modelling
practice is to make sure that data shared by different profiles are described in the canonical CIM. The
description shall also be precise with clear semantics to avoid that the same data is used to mean
different things in different profiles. Unclear description of a CIM class, attribute or relation has resulted
in investigations to figure out the semantics over the past years. So spending time in creating good
descriptions make it easier for future users to use the model correctly and avoid duplicate use for
different things. Another benefit by being specific is that data that may look the same actually are
different when reading the description for the data.
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 but as interoperability
tests are conducted and usage increases the model stabilizes. As the usage of CIM has increased
standardization work has also become much more careful in making extensions such that impact on
existing implementations is minimized.
Messaging and the 61968-100 WS and XSD structures; TK, MG,
BI
(note TK: Margaret, Becky and all, I used as a starter my own text from a chapter that I contributed with
colleagues, to the in-preparation ISTE-Wiley book on demand response; please feel free to modify /
shorten / whatever. Before the text below, in the book chapter, I talked about enterprise and B2B
integration atop a semantically aware enterprise messaging infrastructure, a la our 61968-1 IRM. The
intro text down to the “Anatomy of an interface” would maybe better fit somewhere in the
introduction, maybe the part on 61968-100 where we talk about both domain and integration concepts,
then refer to subsequent sections?)
To come up to a running software, the first set of objectives is to specify interfaces:
– what is the content (or payload) of data exchanges among actors?
– how is it modelled (in the canonical information model) and how is it translated into an
implementation artefact (i.e., some kind of data schema)?
– by which transport it gets exchanged?
while satisfying the requirements, including those related to interoperability. Once we have answered
these questions and started specifying concrete data exchange payloads, all actors concerned with any
given payload can progress in parallel and independently of each other by implementing and testing
their local applications as long as everybody programs to the agreed interfaces.
To allow for this level of flexibility, it is best to adopt for interface specification those technologies that
are independent of 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 properties discussed above. Left side of
Figure xyz-SOAP 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 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,
– L2, the second level, that we will call message interface level, and,
– L3, the third level, that we will refer to as transport interface level.
In theory, one could go further up and wrap content of L3 into some fourth level, L4, but for our
purposes, these three levels are sufficient. The fact that we can clearly separate them 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.
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
L3:
Transport
message
L2:
Message
envelope
L1:
Domain
data
<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 xyz-SOAP – Sample SOAP message
Let us now look at the right hand side of Figure xyz-SOAP. 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 that is compliant with the W3C XML Schema format. That specific domain payload
allows one, for instance, 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. 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 e.g. 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).
(note TK: Do we really want to address here again incremental changes? This would mean describing
61968-100 verbs ‘execute’ and ‘executed’, and if so, one would have to describe all the other verbs. We
can, of course do that, but do we have enough space?
(note TK: When done, remove the two bullets below)
(note TK: When settled on content, think of adapting the title of this whole section to something more
catchy and less technical)
Use of payload profiles, either RDF or XSD
Incremental changes
Data composition by receiving systems; KD, KH, MG
The main objective of CIM is to support utility business processes and these 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 other content.
CIM based integration enables systems to more readily compose and utilize data originating from
multiple sources and potentially with different (but related) structure and content.
Schema partitioning
Profile EQ
Class1
MRID
attr1
attr2
Class3
Class2
attr3
attr1
attr2
attr3
attr4
attr1
attr2
01
02
03
04
05
MAS or Resource B
07
08
MAS or Resource A
Instance partitioning
06
09
0a
0b
0c
0d
0e
0f
10
11
12
13
14
15
16
17
Profile TP
FIGURE 7 DATA PARTITIONING BY INSTANCE AND BY SCHEMA
As shown in Figure 4 there are two main ways CIM data is partitioned.
1) Model Authority Sets partition by instance – e.g. by transmission operators
2) Profiles partition by schema – e.g. by network model
Data may be exchanged in different technologies. For example, a network model exchanged using RDF
XML technology and network outage data exchanged using XSD based XML. We expect the semantics
and object identities to be valid across technologies such that the outages could relate to the network
model. Additionally we may exchange both full models and incremental changes to be applied to full
model descriptions.
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 focus upon the receiver here, but of course data providers must adhere to
standards in order for the receiver to benefit.
TSO 1
TSO n
Network model part
Network model part
Outage coordinator
Approved Outages
Business Process
Load values
Load Forecast
Profile A schema
CIM
Information
model
Legend
Conforms to
Profile B schema
Profiling
process
Profile Z schema
CIM – app1
CIM – app2
payload
CIM - appN
payload
payload
Payload
exchange
payload
IsBasedOn
Payload
exchange
CIM – receiver1
FIGURE 8 BUSINESS PROCESS COMPOSING DATA
Too some, the composition of CIM data is obvious, but for clarity and in preparation for describing more
complex situations, we go through how CIM objects compose.
We describe a generalized “receiver model context” (RMC) in which CIM data is to be composed within
the business process. This context defines each business object to be uniquely defined by an MRID.
Thus references to business objects within that context can be implemented using MRID’s. 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.
payload 1
class A
MRID=1
attr1= X
RMC
unordered
payload 2
class A
MRID=1
attr2=Y
payload 1
class A
MRID=1
attr1=X
attr2=Y
RMC
class A
MRID=1
unordered
class A
MRID=1
payload 2
Proxy
class A
MRID=1
class B
MRID=2
FIGURE 9 OBJECT LEVEL COMPOSITION
class B
MRID=2
payload 1
RMC
class A
MRID=1
unordered
class A
MRID=1
payload 2
Proxy
class A
MRID=1
class B
MRID=2
class B
MRID=2
Figure 9 shows an example of how a receiver with CIM data can compose new data.
<< Still some work in this section. Break double figures apart. Add short conclusion. Intend to be only
slightly longer, or about the same size when delete this paragraph. Remove “Resource” from
schema/instance partitioning diagram. Maybe combine the object example to show both references
and attributes composition in same diagram.>>
Abbreviations (note TK: do we need this?)
DMS –
EMS –
more…
Definitions
(1) Canonical CIM:
This is an abstract model of domain or data exchange (our CIM UML).
(2) Profile:
This is a restriction of canonical CIM, a small subset of it as required for a specific interface for external
data exchanges (although people may take the same approach for internal system interfaces). We use a
profiling tool to reduce canonical CIM to the desired content, and the tool produces for us a schema that
will govern the format of the instance data to be exchanged.
(3) Payload:
This is an instance of Profile according to a given syntax. We use XML (complying with RDFS or XSD); in
future we may want to use something else (e.g. JSON format); others may already be using something
else based on CIM, or CIM extensions or not related to CIM at all. (note TK: this is L1 from Figure xyzSOAP)
(4) Message:
This is an instance of message envelope, e.g. Message.xsd (61968-100), that includes among others one
or more Payloads (3). It also contains the full context of data exchange (verb, noun, etc.) to let the
receiver know what to do with the received payload. (note TK: this is L2 from Figure xyz-SOAP)
(5) Dataset:
TBD
(6) Models:
Model – Data that describe an existing entity or thing.
Power network model – A model or data describing a power network.
Base model – A power network model used as part of a case.
As built model – a power network model that correspond a constructed power network
Case – complete set of inputs to an analytical study case.
Full model – A complete description of a power network model.
Difference model or Incremental model:
Note LOO Mover or remove the below
A description of a power network model relative another full model. Assume X and Y are full models and
Δ is a difference or incremental model. Then the following is true
 A new full Y model can be created from an existing full model X and a difference model
Δ, i.e. Y=X+Δ
 A new full model Y just created from an existing full model X and a difference model Δ
can be used to recreate the existing full model X by subtracting the difference model Δ,
i.e. X=Y-Δ
Any two full models X and Y can be used to create difference model such that one of the full
models can be recreated from the other by adding the created difference model, i.e. if Δ1=X-Y
then X=Y+Δ1 and if Δ2=Y-X then Y=X+Δ2 and Δ1=- Δ2.
Further Readings
– up to 6 items
(note TK: ensure to include CIM model management guidelines and CIM primer - thise leaves place for 4
more)
Authors
– one line per author
Tatjana Kostic is with ABB Corporate Research, Baden-Daettwil, Switzerland.