CIM Standards Overview

and CIM’s Role in the Utility

Enterprise – Part 1
Terry Saxton
Xtensible Solutions
tsaxton@xtensible.net

1
Presentation Contents for Morning Session
Part 1
• What is “The CIM”
• How the CIM is used in the Utility
Enterprise
• Three Layer Architecture for
Organizing the CIM Standards
• Work flow from semantic model to
message/file assembly using CIM
• Layer 1 - CIM UML information
model and contents
– Who Manages the CIM UML Model?
- TC 57 Organization and Formal Liaisons
– Example: Substation model using CIM
– Demo of UML modelling Tool – Sparx
EA
Break
Part 2
• Layer 2 - Profiles for defining system
interfaces
– IEC 61970 network model exchange
– IEC 61968 message payloads for system
integration
• Layer 3 - Implementation syntax of
instance data
– CIM expressed in XML and RDF Schema
• Value of an Enterprise Semantic
Model (ESM) based on the CIM
• Case studies
• Where to get more CIM information
2
The IEC Common Information Model (CIM)
- What Is It?
• A set of standards to enable system integration and information exchange
based on a common information model
– Provides a general information model and message/file schemas for
messages/files exchanged between systems
• A key differentiator: The CIM standards are based on a Unified Modeling
Language (UML) based information model representing real-world objects
and information entities exchanged within the value chain of the electric
power industry
– Provides common semantics for all information exchanges
• Referred to as Model-Driven Integration (MDI)
– Not tied to a particular application’s view of the world
• But permits same model to be used by all applications to facilitate information sharing
between applications
– Maintained by IEC in Sparx Enterprise Architect (EA) modeling tools
– Many tools available
• Generating design artifacts and documentation
• Validation
– Enable data access to enterprise data warehouse in a standard way

3
Once again – What is the CIM?

• It’s more than a set of standards – it’s a solution!

• UML model can be customized or tailored to fit specific utility data
requirements
– Private extensions
– Merging and harmonizing with other standard models
– Subset can be published as a standard from a different SDO
• Example: NAESB Open Field Message Bus (OpenFMB) based on combined CIM and
61850 object models

• New interface profiles can defined for information exchange

• New design artifacts (e.g., XSDs) can be generated with same
tools used to develop the CIM standards

4
5
Smart Grid Conceptual Model – Diving Deeper
System Interoperability is the Goal

OpenADR

CIM CIM CIM

CIM CIM
CGMES

MultiSpeak

CIM NAESB ESPI (Green Button)

CIM
NAESB OpenFMB

ZigBee SEP

6
GWAC* Stack and the CIM Standards
Interoperability Categories
Political and Economic Objectives as
8: Economic/Regulatory Policy Embodied in Policy and Regulation

Strategic and Tactical Objectives

Organizational
CIM 7: Business Objectives Shared between Businesses

Alignment between Operational Business

6: Business Procedures Processes and Procedures

Awareness of the Business Knowledge

5: Business Context Related to a Specific Interaction

Informational Understanding of the Concepts Contained

4: Semantic Understanding in the Message Data Structures

Understanding of Data Structure in

3: Syntactic Interoperability Messages Exchanged between Systems

Mechanism to Exchange Messages between

2: Network Interoperability Multiple Systems across a Variety of Networks
Technical
Mechanism to Establish Physical
1: Basic Connectivity and Logical Connections between Systems

*GWAC – GridWise Architecture Council 7

Role of CIM in Smart Grid Architecture
- and in the Utility Enterprise

• CIM standards aim to simplify integration of

components and expand options for supply of
components by standardizing information exchanges
– Reduce complexity with clear consistent semantic modeling
across the enterprise
– Data sources: achieve a clear picture of data mastership in the
enterprise
– Data consumers: make ‘data of record’ available on demand to
qualified users
• CIM employs a canonical data model (CDM) strategy
for standardizing interfaces in the power system
operations and planning domain.

8
 What is a Canonical Data Model?

A common language, like

use of English in International
IEC standards
A common vocabulary or set
of semantics for creating
understanding

9
The Common Language Should Provide Relevant
Information To A User Regardless of Source

Materials
Management Construction
Engineering Concerns
Concerns Concerns

Operations Protection Maintenance

Concerns Concerns Concerns

10
The Common Language Should Provide Relevant
Information To A User Regardless of Source

Engineering Concerns Materials Management Concerns Construction Concerns

The logical view of how the type of
equipment fits (will fit) in the
electrical network. Nominal
configuration of “as-built” and
“future” states.
 Field Name
 Spatial Location
 Version
 Physical Connectivity
 Load Projections
 Capacity Requirements
 Compatible Unit
 Equipment Ratings
Planning and tracking material
requirements for construction and
maintenance. Information about
physical pieces of equipment.
 Asset Identifier
 Compatible Unit
 Equipment Component Type
 Equipment Manufacturer/Model
 Serial Number
 Location
 Equipment Location History
 Manufacturer Specifications
Lifecycle information regarding when
and how to install equipment:
 Field Name
 Location
 Equipment Manufacturer/Model
 Compatible Unit
 Equipment Ratings
 Work Order
 Work Design
 Installation Schedule &Budget
 Permits
 Manufacturer Specifications
 Safety Requirements

11
The Needs of Various Users –
Some Same, Some Different (continued)
Operations Concerns
Real-time condition of equipment and
electrical network necessary to
maintain reliable network operation:
 Field Name
 Schematics & Spatial Location
 Electrical Connectivity
 Operational Limits (dynamic)
 Equipment Status
 Clearances
 Network Measurements (voltage,
current, frequency)
 Equipment Faults
 Weather Measurements
 Operational Restrictions
Protection Concerns
Setting and configuring relays based
on equipment and network protection
requirements:
 Field Name
 Schematics
 Electrical Connectivity
 Maximum Capacity
 Zones Of Protection
 Equipment Status
 Clearances
 Network Measurements
(voltage, current, frequency,
transients)
 Equipment Faults
Maintenance Concerns
Lifecycle information regarding when
and how equipment is maintained:
 Field Name
 Location
 Equipment Manufacturer/Model
 Equipment Ratings
 Routine Maintenance
 Testing & Diagnostics
Procedures
 Equipment Condition
 Inspection Schedule
 Equipment Repair Records
 Site Service Records
 Maintenance Budget
 Safety Requirements
12
 Exchanging Common Language Messages Among Systems
Should Provide Relevant Information To Each System That
Is Harmonious With All Other Systems’ Information

Asset Catalog Planned Outage Crew

Blah, Blah, Blah, Blah, Blah, Blah,
Work Blah, Blah, Blah,
Service Connection Blah, Blah, Blah,
Organization, Organization, Organization,
Request Blah, Blah, Blah Blah, Blah, Blah
Organization, Blah, Blah, Blah
Blah, Blah, Blah, Blah, Blah, Blah
Organization,
Blah, Blah, Blah

Maintenance
Blah, Blah, Blah,
Organization,
Switching Schedule Meter Reading Load Data Set Load Control
Blah, Blah, Blah
Blah, Blah, Blah, Blah, Blah, Blah,
Blah, Blah, Blah, Blah, Blah, Blah,
Organization, Organization,
Organization, Organization,
Blah, Blah, Blah Blah, Blah, Blah
Blah, Blah, Blah Blah, Blah, Blah

For example, in each of the message exchanges depicted above, the same Organization is referenced
for different reasons. There should be NO inconsistencies about this Organization
13
For example, a common language-based logical
infrastructure facilitates collaboration among the many
applications involved in Asset Management

Asset Investment Planning Resource

Asset Program Management
Scheduling &
Asset Asset Planning Tool Program Mgmt. Planning
Strategy
Equip./Fleet
Budget Load Forecast Work Mgmt. Portal Management
Asset
Reliability
Portfolios SRCM Facility I&M Supply Chain
Analysis
Management
Executive
Network Contract Mgmt.
Dashboard
Risk Analysis
Contract
Management Asset Repository Management
Revenue
GIS Mobile
Regulatory OMS Workforce
Reporting CIS Metering Mgmt.

SCADA Work
CRM Mobile & Dispatching Collaboration
Financial & Reporting
Management
IVR eBusiness EMS DMS SA/DA
Work
Design
Customer Management Asset Operations
Asset Owner Asset Manager Service Provider
14
Application To Common Language Mapping –
The Typical Field to Field Process Is Cumbersome

• Individual fields of data models

from data sources are mapped to
each other
• Approach does not scale well as
the number of maps grows
exponentially with each new data
source
• Mapping is a challenge as
‘mappers’ must have an in depth
understanding of all relevant data
sources – a tall order!

15
Using A Semantic Model Simplifies & Scales Up The
Mapping Process
• What is a Semantic Model?
– The key ingredients that make up a semantic model are a vocabulary of
basic terms, a precise specification of what those terms mean and how
they relate to each other.
• How is it used?
– Before making mappings, a model (or an ontology) of a given business
domain is defined.
– The model is expressed in a knowledge representation language and it
contains business concepts, relationships between them and a set of rules.
– By organizing knowledge in a discrete layer for use by information
systems, semantic models enable communication between computer
systems in a way that is independent of the individual system
technologies, information architectures and applications.
– Compared to one-to-one mappings, mapping data sources to a common
semantic model offer a much more scaleable and maintainable way to
manage and integrate enterprise data.

16
The CIM Semantic Model Provides a Semantic
Layer in an Enterprise Architecture
Composite Applications Business Intelligence

Web Services Integration Bus ETL DW

Common
Language

Generic Semantic
Model
Services Metadata

Apps.

17
 Subscribers:
Decoupled Information CIM App
Several Application Adapters Receive The Same Message
Each Adapter:
X.1 B.1
Exchange X.2 B.2 Parses Message, Pulling Out Data Needed By Application
Transforms Data (if necessary) to Local Application Format
X.3 Subscriber
X.4
X.5
Passes Data To Local Application And/Or Database
Through Most Appropriate Means

CIM App CIM App

X.1 A.1 X.1 C.1
X.2 Grid Dist X.2
X.3 Subscriber Wires DAC Wires X.3 C.3 Subscriber
X.4 A.4 X.4 C.4
X.5 A.5 Model Model X.5 VRU

Outage Distribution
Reporting EMS OMS Automation CIS

Message Type Instance: ChangedNetworkDataSet (Expressed In Common Language) ...

Event History Human Work Substation Data
AM/FM/GIS
Resources Management Automation Warehouse

CIM Publishers:
X.1 App CIM
X.2 Y.1 X.1
One Application Connector:
X.3 Subscriber Y.2 X.2 Obtains Data From Application And/Or Database
X.4 Y.3 X.3 Publisher Transforms Data (if necessary) to the “Common
X.5 Y.4 X.4
Y.5 X.5 Language” (a Canonical Data Model)
Puts Data Into Message Template
Publishes The Message (Fires & Forgets)
18
 We Need An Organizing Framework

• Let’s break it down

• The CIM standards include an information model expressed in UML
• Profiles for specifying a subset of the CIM classes and attributes for a
specific business context at a specific system interface or system
interaction
• Implementation models
– Use of XML to create serialized files and messages
• RDF Schema-based standards for power system model
exchange
• XML Schema-based standards for information message
payloads
– Could include ETL based on CIM for data base access
• DDLs for data tables
• But how do we organize these pieces?

19
GWAC Stack – Not an IT Architecture for the CIM Standards

Interoperability Categories
Political and Economic Objectives as
8: Economic/Regulatory Policy Embodied in Policy and Regulation

Strategic and Tactical Objectives

Organizational
CIM 7: Business Objectives Shared between Businesses

Alignment between Operational Business

6: Business Procedures Processes and Procedures

Awareness of the Business Knowledge

5: Business Context Related to a Specific Interaction

Informational Understanding of the Concepts Contained

4: Semantic Understanding in the Message Data Structures

Understanding of Data Structure in

3: Syntactic Interoperability Messages Exchanged between Systems

Mechanism to Exchange Messages between

2: Network Interoperability Multiple Systems across a Variety of Networks
Technical
Mechanism to Establish Physical
1: Basic Connectivity and Logical Connections between Systems

20
 CIM Layered Architecture*
Information and Semantic Models

Information Model
• Generalized model of all utility objects and their
CIM UML relationships
• Application independent, but defines all concepts
needed for any application

Context
Contextual layer restricts information
model
Profiles •
•
Specifies which part of CIM is used for given profile
Mandatory and optional
• Restrictions
• But cannot add to information model

Message Syntax Message syntax describes format for

Message/File
instance data
Format • Serialization of instance data
(XSD, RDF • Can re-label elements
Schema, OWL) • Change associations to define single structure for
message payloads
• Mappings to various technologies can be defined

* Based on UN/CEFACT CCTS (Core Component Technical Specification)

21
Layered Architecture for CIM Standards
Information
CIM Ext CIM/UML Bridging
CIM Bridge Foreign

Context
CPSM WG 14 Other UML
Profile Profiles Profiles Modelling

Message Rules
WG 13 WG 14
Logical
Assembly File Message Messages
Schemas
Structure Structure
CIM
RDF
XML
Exchange
NDR
Schema
Other
Rules
XML DataBase
CIM RDF OWL
Schema Schema

22
CIM Design Time Methodology

• Let’s consider how these layered CIM standards are

applied to solve the system interoperability problem
• First step is to link business process data exchanges
discovered by creating activity diagrams and sequence
diagrams and linking with a common semantic model
(such as the CIM model)
– Example sequence diagram

23
 Global methodological framework*
(Sub-Set,
Constraints, restrictions)
3
2 Contextual Model
4
or Business
Information Model Information Entity Message Conceptual
or Core Model
Components or
( CIM) Message
Assembly
(Exchanged at
CIM extensions app interfaces)

Technological derivation
XSD, OWL,RDFS, SQL …etc
Business Process
1 Study:
Exchanged Data 5 Implementation Message Model
or
analysis Ex: outage Validation Syntax Binding
Management XML Exchanged Data

DMS OMS

* Derived from UN/Cefact CCTS (Core Component Technical Specification)

24
CIM Design Time Methodology

• Another Example
– Need to exchange an Energy Transaction between System A and
System B
– Illustrates in more detail the design artifacts generated at each
step
– Important to note all design is done in UML using Sparx
Enterprise Architect with choice of CIM Tools
– Final step is to automatically generate XML or RDF schemas from
the UML

25
 Abstract
From Information/
Model
Semantic
Information Model Model
to
Syntactic Model
Context/
Ex: Energy Transaction
Profiles

UML World Message

Assembly

XML Syntactic World <?xml version="1.0" encoding="UTF-8"?>

<xsd:element
name=« MT_EnergyTransaction">
<xsd:sequence>

Message <xsd:element
name=« EnergyTransaction"/>
Syntactic
<xsd:sequence>
Syntax <xsd:element name=« Name"/>
<xsd:element name=« Type"/>
</xsd:sequence> Model
</xsd:element>
26
 Information/Semantic Model Expressed in UML
(Unified Modeling Language) Notation
Class Name usually describes things in the real world

Class Attributes describe

significant aspects about the thing

This Specialization indicates that an

“EnergyTransaction” is a type of
“Document.” “EnergyTransaction”
inherits all of the attributes from Document

Associations
Aggregation is a variant of Association and connect
indicates a class is a collection or container classes and
of other classes, but if the container is are
destroyed, its contents are not. assigned a
role that
describes the
relationship

27
 Abstract
Information/ Model
From Semantic
Information Model Model
to
Syntactic Model
Context/
Profiles

UML World

XML Syntactic World

Syntactic
Model
28
 Context/Profiles Various tools available to create Profiles

String
Length Only “code”
changed to attribute
exactly 6 retained

Association
inherited from
parent Document
String class, cardinalities
Length changed to “1”
changed to
max of 4

29
 Abstract
Information/ Model
From Semantic
Information Model Model
to
Syntactic Model
Context/
Profiles

UML World Message

Assembly

XML Syntactic World

Syntactic
Model
30
Message Assembly

31
 Abstract
Information/ Model
From Semantic
Information Model Model
to
Syntactic Model
Context/
Profiles

UML World Message

Assembly

XML Syntactic World <?xml version="1.0" encoding="UTF-8"?>

<xsd:element
name=« MT_EnergyTransaction">
<xsd:sequence>

Message <xsd:element
name=« EnergyTransaction"/>
<xsd:sequence> Syntactic
Syntax <xsd:element name=« Name"/>
<xsd:element name=« Type"/>
</xsd:sequence> Model
</xsd:element>
32
To Summarize
• The CIM information model standard expressed in UML is used is
the source of the semantics needed for a particular exchange
• A Profile specifies the restricted subset of the CIM classes and
attributes for specific business context
– This is the CDM (Canonical Data Model) for a particular information
exchange
• An Implementation Technology, such as XML, is used to create the
schema for serializing the instance data as files or messages,
resulting in
– Standards for power system models
– Standards for information message payloads
• The good news --- most of the power system models and message
schemas needed by a utility are already defined as IEC standards
– 61970 series: Power system models for operations and planning (T&D)
– 61968 series: Message schemas for enterprise integration (T&D)

33
Let’s look at each layer of the CIM standards

Information and Semantic Models

Information Model
• Generalized model of all utility objects and their
CIM UML relationships
• Application independent, but defines all concepts
needed for any application

Context
Contextual layer restricts information
model
Profiles •
•
Specifies which part of CIM is used for given profile
Mandatory and optional
• Restrictions
• But cannot add to information model

Message Syntax Message syntax describes format for

Message/File
instance data
Format • Can re-label elements
(XSD, RDF • Change associations to define single structure for
Schema, OWL) message payloads
• Mappings to various technologies can be defined

34
Foundational Relationships Of The CIM

PowerSystemResource Organisation
Electrical Network Role Used For Entities Performing Roles Such
Planning, Operations, etc. As Operations, Tax Authority

Asset Person
Physical Plant Filling A Role People Performing Roles Such
Such As A Transformer, Pole, etc. Dispatcher, Field Operator, etc.

Location
Where To Find Something By
Customer
Industrial, Commercial, & Residential
GPS, Address, Electronically, etc.
Which Can Have Multiple Accounts

Document
Information Containers Such As
Trouble Ticket, Work Orders, etc.

35
Who Manages the CIM UML Model?
- TC 57 Organization and Formal Liaisons

UCA International
WG19 User groups
Architecture
WG13 WG 10
EMS-API Substation
Automation
CIM/61850 CIGRE
Harmonization SC D2-24
WG14 WG17 SC B5-38
SIDMS DER

TC57
WG16
WG18
Energy
Hydro IEEE
Markets Conveners
Advisory Group PES PSCC
CAG Security
WG3 WG20 SubComm
Telecontrol Power Line
Protocols Carrier
WG21
WG15
Grid System
Security
Interfaces
Legend

CIM-based

61850-based
36
IEC TC57 CIM Packages
cl a ss P a ck a geDependenci es

WG13 I EC 61970 TC 57C I M ::C ombi nedV er si on

Operations/Planning + date: Date [0..1] = 2011-09-09 {readOnly}

+ version: String [0..1] = iec61970CIM15v3... {readOnly}
Network Models (from TC57CIM)

I EC 61970::I EC 61970C I M V er si on

+ date: Date [0..1] = 2011-09-09 {readOnly}

+ version: String [0..1] = IEC61970CIM15v33 {readOnly}

WG14 I EC 61968 I EC 61968::I EC 61968C I M V er si on

+ date: Date [0..1] = 2011-08-10 {readOnly}

Operations/Planning + version: String [0..1] = IEC61968CIM11v13 {readOnly}
Assets and Back Office (from TC57CIM)
System Integration
I EC 62325::I EC 62325C I M V er si on

+ date: Date [0..1] = 2011-04-28 {readOnly}

+ version: String [0..1] = IEC62325CIM01v07 {readOnly}
WG16 I EC 62325

Deregulated
Market (from TC57CIM) P a ck a geDependenci esC I M V er si on
Communications + date: Date [0..1] = 2011-05-07 {readOnly}
+ version: String [0..1] = 6 {readOnly}

P a ck a geDependenci es

(from TC57CIM)

37
WG13 CIM Packages - 61970
cl a ss I EC 61970Dependenci es

I EC 61970C I M V er si on

+ date: Date [0..1] = 2011-09-09 {readOnly}

+ version: String [0..1] = IEC61970CIM15v33 {readOnly}

Loa dM odel O ut a ge P r ot ect i on

Gener a t i on

Gener a t i onDy na mi cs P r oduct i on

(from Generation) (from Generation)

W i r es
Equi v a l ent s

C ont r ol A r ea

St a t eV a r i a bl es

SC A DA

O per a t i ona l Li mi t s Topol ogy

M ea s

C or e

A uxi l i a r y Equi pment

Doma i n

C ont i ngency Di a gr a mLa y out

38
 Concepts: Generalization/Inheritance
cl a ss Document a t i onExa mpl eI nher i t a nce

IdentifiedObject
C or e::P ow er Sy st emResour ce

C or e::Equi pment
• Equipment: Specialization of
Release 14 PowerSystem Resource
W i r es::P ow er Tr a nsf or mer

C or e::
• ConductingEquipment:
C onduct i ngEqui pment
Release 15 Specialization of Equipment

W i r es::Sw i t ch
• Switch: Specialization of
Conducting Equipment
W i r es::P r ot ect edSw i t ch
• ProtectedSwitch: Specialization of
Switch
• Breaker: Specialization of
W i r es::B r ea k er ProtectedSwitch

39
 cl a ss Na mi ngHi er a r chy P a r t 1

Naming and C or e::I dent i f i edO bj ect

Container +
+
+
aliasName: String [0..1]
mRID: String [0..1]
name: String [0..1]

Hierarchy
Part 1 C or e::
C or e:: C or e::
C onnect i v i t y NodeC ont a i ner P ow er Sy st emResour ce
Geogr a phi ca l Regi on
+Region 0..1

+Regions 0..*

C or e:: C or e:: +EquipmentContainer

SubGeogr a phi ca l Regi on Equi pment C ont a i ner 0..1

+Region
+Region 0..1 0..1
+Equipments
C or e::
0..*
Equi pment

+Lines 0..*
P l a nt
Li ne

+Substations 0..*

+Substation C or e::
Subst a t i on
0..1

+Substation 1

+VoltageLevels 0..*

C or e::
V ol t a geLev el
+VoltageLevel
0..1

0..* +Bays

C or e::
+Bays 0..* Bay

40
 cl a ss Na mi ngHi er a r chy P a r t 2

C or e::I dent i f i edO bject

Naming and +
+
+
aliasName: String [0..1]
mRID: String [0..1]
name: String [0..1]

Equipment
Hierarchy M ea s::
M ea sur ement
+Measurements

0..*
+PowerSystemResource
C or e::
0..1 P ow er Sy st emResour ce Ta pC ha nger

Part 2 C omposi t eSw i t ch

0..1 +CompositeSwitch
C or e::
Equi pment

P r oduct i on::Gener a t i ngU ni t

+Gener atingUnit 0..1

+SynchronousMachines 1..*

Rot a t i ngM a chi ne Sy nchr onousM a chi ne

+Switches 0..*

C or e::
Sw i t ch
C onduct i ngEqui pment

Fuse

Regul a t i ngC ondEq C onduct or

Jumper

Di sconnect or DC Li neSegment

Gr oundDi sconnect or St a t i cV a r C ompensa t or A C Li neSegment

C onnect or
P r ot ect edSw i t ch Fr equency C onv er t er

B usba r Sect i on
Loa dB r ea k Sw i t ch Shunt C ompensa t or

Ener gy C onsumer
Junct i on
B r ea k er

Ser i esC ompensa t or

Rect i f i er I nv er t er

Gr ound

Ener gy Sour ce

41
Names

cl a ss Na mes

I dent i f i edO bject

+ aliasName: String [0..1]

+ mRID: String [0..1]
+ name: String [0..1]

+IdentifiedObject 1

+Names 0..*

Na me Na meTy pe Na meTy peA ut hor i t y

+Names 1 +NameTypes 0..1
+ name: String [0..1] +NameType + description: String [0..1] 0..* + description: String [0..1]
0..* +NameTypeAuthority
+ name: String [0..1] + name: String [0..1]

42
 cl a ss M a i n

Connectivity C or e::
I dent i f i edO bject

and
Topology C or e::
P ow er Sy st emResour ce
M ea s::
M ea sur ement

+Measurements 0..*

Model C or e::
0..1 +Terminal

Equi pment C or e:: 1..* +Terminal

+Terminals
Ter mi na l
0..* +Terminal +BusNameMarker
+ConductingEquipment 1 +Terminals 0..*
0..1
0..*
C or e:: B usNa meM a r k er
C onduct i ngEqui pment Bus/Branch bus
+ConnectivityNode 0..1
naming specificaiton
static model.
C or e::
+ConnectivityNodes 0..* C onnect i v i t y Node

+ConnectivityNodeContainer

1 +ConnectivityNodes 0..*
C or e::
C onnect i v i t y NodeC ont a i ner Switch/Node
static Model
0..1 +TopologicalNode 0..1 0..1
+TopologicalNode
+ConnectivityNodeContainer 0..* +TopologicalNode
Topol ogi ca l Node

+TopologicalNodes 1..* 0..1 Bus/Branch

C or e:: +AngleRef_TopologicalNode
calculated Model
Equi pment C ont a i ner

+TopologicalIsland 1 0..1 +AngleRef_TopologicalIsland

Topol ogi ca l I sl a nd

C ont r ol A r ea ::C ont r ol A r ea

+ netInterchange: ActivePower [0..1]

+ pTolerance: ActivePower [0..1]
+ type: ControlAreaTypeKind [0..1]

43
Converting a Circuit to CIM Objects

• Example to show how voltage levels, current

transformers, power transformers and generators are
modelled
• Circuit contains a single generating source, load, line and
busbar. The circuit also contains two power transformers
resulting in three voltage levels of 17kV, 33kV and 132kV

Taken from Alan McMorran, Common Information Model Primer: First Edition., EPRI, Palo Alto,
CA: 2011, 1024449. Second Edition now available.

44
Example Circuit as a Single Line Diagram

EnergyConsumer ACLineSegment

Breaker

Breaker

BusbarSection

Breaker

GeneratingUnit

Current measurement
SynchronousMachine represented by
Measurement connected
to Terminal

45
Transformer Class Diagram
CIM Release 15
ConductingEquipment with
associations to types of
TransformerEnds for
electrical connectivity

Winding terminal for

balanced transformer model
network connection

TransformerTank added for

distribution transformer
windings so each phase
winding could be modeled

Winding terminal for

unbalanced transformer
model network connection

Previously included in
Winding class

46
Balanced Transformer Model

Contains legacy attributes for

resistance, reactance,
conductance, susceptance,

For backward compatibility,

can consider as optional

47
Balanced Transformer Instance for
Transformer 17-33 - Release 15
Transformer 17-33 is represented
as four CIM objects plus
optional objects
Connections from the transformer
to the network are made
directly from the
PowerTransformer via
association to
PowerTransformerEnd

48
Unbalanced Distribution Transformer with
Multiple Tanks Instance Example

49
Example Circuit with Full CIM Mappings

• Maps to
– 17 CIM classes
– 45 CIM objects
• Could be
extended further
with addition of
objects for
– control areas
– equipment
owners
– measurement
units
– generation and
load curves
– asset data

50
WG14 CIM Packages - 61968
pk g I EC 61968Dependenci es

I EC 61968C I M V er si on

+ date: Date [0..1] = 2011-08-10

+ version: String [0..1] = IEC61968CIM11v13

Loa dC ont r ol P a y ment M et er i ng

M et er i ng

A sset I nf o
C ommon

A sset s

C ust omer s

W or k

M ea s C or e

(from IEC61970) (from IEC61970)

Doma i n

(from IEC61970)

51
 cl a ss C ommonO v er v i ew

IdentifiedObject IdentifiedObject
+Location 0..1

Common
Loca t i on C oor di na t eSy st em
0..* +CoordinateSystem
+ direction: String [0..1] + crsUrn: String [0..1]
+ electronicAddress: ElectronicAddress [0..1] P osi t i onP oi nt

Concepts +
+
+
geoInfoReference: String [0..1]
mainAddress: StreetAddress [0..1]
phone1: TelephoneNumber [0..1]
+Location

1
+PositionPoints

0..*
+
+
sequenceNumber: Integer [0..1]
xPosition: String [0..1]

in 61968
+ yPosition: String [0..1]
+ phone2: TelephoneNumber [0..1]
+ zPosition: String [0..1]
+ secondaryAddress: StreetAddress [0..1]
+ChangedLocation
+ status: Status [0..1]

CIM + type: String [0..1] 0..1

IdentifiedObject
O r ga ni sa t i on
IdentifiedObject +ChangedOrganisationRole
+ electronicAddress: ElectronicAddress [0..1] +Organisation +Roles
O r ga ni sa t i onRol e
+ phone1: TelephoneNumber [0..1]
0..1 0..* 0..1
+ phone2: TelephoneNumber [0..1]
+Organisations
+ postalAddress: PostalAddress [0..1]
+ streetAddress: StreetAddress [0..1] 0..*
«informative»

+ActivityRecords IdentifiedObject
A ct i v i t y Recor d
IdentifiedObject 0..*
Document + createdDateTime: DateTime [0..1]
+Documents «informative» 0..* + reason: String [0..1]
+ createdDateTime: DateTime [0..1] + severity: String [0..1]
0..* +ActivityRecords
+ docStatus: Status [0..1] + status: Status [0..1]
+ electronicAddress: ElectronicAddress [0..1]
+ type: String [0..1]
+ lastModifiedDateTime: DateTime [0..1]
+ revisionNumber: String [0..1]
+ status: Status [0..1]
+ subject: String [0..1] +ChangedDocument +ConfigurationEvents
+ title: String [0..1] 0..1 C onf i gur a t i onEv ent
+ type: String [0..1] 0..*
0..* + effectiveDateTime: DateTime [0..1]
+ConfigurationEvents + modifiedBy: String [0..1]
0..*
+ remark: String [0..1]
+ConfigurationEvents

A gr eement Ti meSchedul e
+ signDate: Date [0..1] + disabled: Boolean [0..1]
+ validityInterval: DateTimeInterval [0..1] + offset: Seconds [0..1]
+ recurrencePattern: String [0..1]
+ recurrencePeriod: Seconds [0..1]
+ scheduleInterval: DateTimeInterval [0..1]
IdentifiedObject
Ti meP oi nt
+TimeSchedule 0..*
+ dateTime: DateTime [0..1]
1 + relativeTimeInterval: Seconds [0..1]
+TimePoints
+ sequenceNumber: Integer [0..1]
+ status: Status [0..1]
+ window: DateTimeInterval [0..1]
52
How The CIM Handles Location For Logical Devices And/Or
The Physical Asset Performing The Device’s Role
cl a ss A sset sO v er v i ew

IdentifiedObject
IdentifiedObject +AssetInfo +AssetModel IdentifiedObject
A sset Funct i on
+AssetDatasheet A sset I nf o A sset M odel
0..1 0..1 + configID: String [0..1]
0..1 + firmwareID: String [0..1]
+AssetInfo 0..1 + hardwareID: String [0..1]
+ password: String [0..1]
+PowerSystemResource
+ programID: String [0..1]
IdentifiedObject 0..*
C or e:: P r oduct A sset M odel
P ow er Sy st emResour ce
+ corporateStandardKind: CorporateStandardKind [0..1] +ProductAssetModel +Manufacturer OrganisationRole
+PowerSystemResources
+PowerSystemResources
0..* 0..* + modelNumber: String [0..1]
M a nuf a ct ur er
+ modelVersion: String [0..1] 0..* 0..1
+ usageKind: AssetModelUsageKind [0..1]
+ weightTotal: Weight [0..1]

+Assets 0..*
+Assets +OrganisationRoles OrganisationRole
+Location 0..1 +Assets IdentifiedObject
A sset O r ga ni sa t i onRol e
IdentifiedObject A sset 0..* 0..*
0..*
C ommon::Loca t i on + acceptanceTest: AcceptanceTest [0..1]
+ critical: Boolean [0..1]
+ direction: String [0..1]
+ electronicAddress: ElectronicAddress [0..1]
+ electronicAddress: ElectronicAddress [0..1]
+ geoInfoReference: String [0..1] +Location +Assets + initialCondition: String [0..1]
+ initialLossOfLife: PerCent [0..1]
+ mainAddress: StreetAddress [0..1] A sset O w ner
0..1 0..* + lifecycle: LifecycleDate [0..1]
+ phone1: TelephoneNumber [0..1]
+ lotNumber: String [0..1]
+ phone2: TelephoneNumber [0..1]
+ purchasePrice: Money [0..1]
+ secondaryAddress: StreetAddress [0..1] +Assets
+ serialNumber: String [0..1]
+ status: Status [0..1]
+ status: Status [0..1] 0..*
+ type: String [0..1]
+ type: String [0..1]
+ utcNumber: String [0..1]

0..1 +AssetContainer

C omM edi a A sset C ont a i ner

53
Types Of Document Relationship Inherited
By All Assets

AssetModel
number : String
version : String

0.. n

0..n Document 0..n PowerSystem

(f rom DocumentationPa...) Resource
0..n (from Core)

Qu ali ficationRequirem ent

qualificationID : String
MaintenanceProcedure
type : String

AssetRating
AssetProperty
ratingType : String
propertyType : String InspectionRoutine
property : String
propertyValue : String (f ro m As setsIns pec tio n)
ratingValue : Float
units : String
units : String

54
Activity Records
cl a ss t mpA ct i v i t y Recor d

IdentifiedObject
C ommon::
Document +Documents
0..*
IdentifiedObject
C ommon::
O r ga ni sa t i on

+Organisations 0..*

IdentifiedObject «informative»
A sset s::A sset

«informative» IdentifiedObject
+Assets +Assets
0..* 0..*
I nf C ommon::
+ActivityRecords P er son
«informative»
+ActivityRecords 0..* 0..*
+ActivityRecords 0..* +ErpPersons 0..*
+ScheduledEvents 0..*
IdentifiedObject +ActivityRecords
IdentifiedObject C ommon::A ct i v i t y Recor d «informative»
I nf C ommon:: 0..*
Schedul edEv ent + createdDateTime: DateTime [0..1]
+ reason: String [0..1]
+ severity: String [0..1]
+ status: Status [0..1]
+ type: String [0..1]

I nf O per a t i ons:: I nf W or k :: M et er i ng:: I nf A sset s:: I nf C ust omer s::

P SREv ent W or k St a t usEnt r y EndDev i ceEv ent Fa i l ur eEv ent C ompl i a nceEv ent

55
WG16 CIM Market Extensions
cl a ss M a i n

I EC 62325C I M V er si on

+ date: Date [0..1] = 2011-04-28 {readOnly}

+ version: String [0..1] = IEC62325CIM01v07 {readOnly}

M a r k et C ommon

M a r k et O per a t i ons M a r k et M a na gement

56
CIM UML Release Cycles

• 61970 CIM UML tries for annual release cycle

• Basis for IEC 61970-301 CIM Base Fifth Edition
• Word document auto-generated from the UML electronic model
• Information system and Profile documents are synchronized with
UML model release
• 61968 CIM UML different update cycles
• Basis for IEC 61968-11 CIM Distribution Information Exchange
Model
• 62325 CIM UML on another update cycle
• Basis for IEC 62325-301 CIM for Deregulated Markets
• Complete CIM UML available as a combined model on CIMug
Sharepoint site:
– Title: draft CIM16 + DCIM12 + MCIM02
– Name: iec61970cim16v13_iec61968cim12v05_iec62325cim02v05

57
CIM UML in Enterprise Architect

• The CIM UML model is maintained in Sparx Enterprise

Architect (EA)
• Current Official CIM Releases of UML Model
– iec61970cim16v29a_iec61968cim12v08_iec62325cim03v01a
(official release 16 WG13)
– iec61970cim17v04_iec61968cim12v09_iec62325cim03v01a
(updated by WG14)
– iec61970cim17v07_iec61968cim12v10_iec62325cim03v02
(current model release)
• Go to UML model in EA

58
Break

59