IEC 61970-301:2003

INTERNATIONAL IEC
STANDARD 61970-301
First edition
2003-11
Energy management system application
program interface (EMS-API) –
Part 301:
Common Information Model (CIM) Base

Reference number
Publication numbering
As from 1 January 1997 all IEC publications are issued with a designation in the

60000 series. For example, IEC 34-1 is now referred to as IEC 60034-1.

Consolidated editions
The IEC is now publishing consolidated versions of its publications. For example,

edition numbers 1.0, 1.1 and 1.2 refer, respectively, to the base publication, the

base publication incorporating amendment 1 and the base publication incorporating

amendments 1 and 2.
Further information on IEC publications
The technical content of IEC publications is kept under constant review by the IEC,
thus ensuring that the content reflects current technology. Information relating to
this publication, including its validity, is available in the IEC Catalogue of
publications (see below) in addition to new editions, amendments and corrigenda.
Information on the subjects under consideration and work in progress undertaken
by the technical committee which has prepared this publication, as well as the list
of publications issued, is also available from the following:
• IEC Web Site (www.iec.ch)
• Catalogue of IEC publications
The on-line catalogue on the IEC web site (www.iec.ch/searchpub) enables you to
search by a variety of criteria including text searches, technical committees
and date of publication. On-line information is also available on recently issued
publications, withdrawn and replaced publications, as well as corrigenda.
• IEC Just Published
This summary of recently issued publications (www.iec.ch/online_news/ justpub)
is also available by email. Please contact the Customer Service Centre (see
below) for further information.
• Customer Service Centre
If you have any questions regarding this publication or need further assistance,
please contact the Customer Service Centre:

Email: custserv@iec.ch
Tel: +41 22 919 02 11
Fax: +41 22 919 03 00
INTERNATIONAL IEC
STANDARD 61970-301
First edition
2003-11
Energy management system application
program interface (EMS-API) –
Part 301:
Common Information Model (CIM) Base

 IEC 2003  Copyright - all rights reserved
No part of this publication may be reproduced or utilized in any form or by any means, electronic or
mechanical, including photocopying and microfilm, without permission in writing from the publisher.
International Electrotechnical Commission, 3, rue de Varembé, PO Box 131, CH-1211 Geneva 20, Switzerland
Telephone: +41 22 919 02 11 Telefax: +41 22 919 03 00 E-mail: inmail@iec.ch Web: www.iec.ch
PRICE CODE
Commission Electrotechnique Internationale XH
International Electrotechnical Commission
МеждународнаяЭлектротехническаяКомиссия
For price, see current catalogue

– 2 – 61970-301  IEC:2003(E)
CONTENTS
FOREWORD.4

INTRODUCTION.6

1 Scope.7

2 Normative references.7

3 Terms and definitions .7

4 CIM specification.8

4.1 CIM modeling notation.8
4.2 CIM packages.8
4.2.1 Core.10
4.2.2 Topology.10
4.2.3 Wires.10
4.2.4 Outage.10
4.2.5 Protection.10
4.2.6 Meas.10
4.2.7 LoadModel.10
4.2.8 Generation.10
4.2.9 Domain.11
4.3 CIM classes and relationships .11
4.3.1 Generalization.12
4.3.2 Simple association.12
4.3.3 Aggregation.13
4.4 CIM model concepts and examples .13
4.4.1 Transformer model.13
4.4.2 Connectivity model.14
4.4.3 Inheritance Hierarchy.17
4.4.4 Equipment Containers.19
4.5 Modeling tools .19
4.6 Modeling guidelines.20
4.6.1 Amendments to the CIM .20
4.6.2 CIM profiles.21
4.7 User implementation conventions.21

4.7.1 Naming.21
4.7.2 Use of Measurement-related classes .22
4.7.3 Number of Terminals for ConductingEquipment Objects .25
4.8 Examples.25

Annex A (normative) Common information model for control center application
program interface .26
Annex B (informative) CIM notation mapping from entity relationship diagram to class
diagram in UML .174

Bibliography.176

61970-301  IEC:2003(E) – 3 –
Figure 1 – CIM Part 301 Package Diagram .9

Figure 2 – Example of generalization .12

Figure 3 – Example of Simple Association .13

Figure 4 – Example of Aggregation .13

Figure 5 – Transformer Model.14

Figure 6 – Connectivity Model.15

Figure 7 – Simple Network Example .16

Figure 8 – Simple Network Connectivity Modeled with CIM Topology.17

Figure 9 – Equipment Inheritance Hierarchy .18
Figure 10 – Equipment Containers .19
Figure 11 – Navigating from PSR to MeasurementValue .24
Figure 12 – Measurement placement .24
Figure A.1 – CIM Top Level Packages .26
Figure A.2 – Main .27
Figure A.3 – Main .28
Figure A.4 – Integer Datatypes .39
Figure A.5 – Float Datatypes .40
Figure A.6 – String Datatypes .41
Figure A.7 – Other Datatypes.42
Figure A.8 – Enumeration Datatypes.43
Figure A.9 – Main .63
Figure A.10 – Main .64
Figure A.11 – Hydro.65
Figure A.12 – Thermal .66
Figure A.13 – Main .98
Figure A.14 – Main .111
Figure A.15 – Main .121
Figure A.16 – Measurements .122
Figure A.17 – Quality .123
Figure A.18 – Main .131
Figure A.19 – Main .134

Figure A.20 – Main .137
Figure A.21 – Transformer Model.140
Figure A.22 – EquipmentContainment.141
Figure A.23 – InheritanceHierarchy.142
Figure A.24 – LineModel .143
Figure A.25 – RegulatingEquipment.144
Figure A.26 – VoltageControl.145
Table 1 – MeasurementType Naming Conventions.23
Table 2 – MeasurementValueSource Naming Conventions .24
Table B.1 – CIM Mapping Conventions .174

– 4 – 61970-301  IEC:2003(E)
INTERNATIONAL ELECTROTECHNICAL COMMISSION

___________
ENERGY MANAGEMENT SYSTEM APPLICATION

PROGRAM INTERFACE (EMS-API) –
Part 301: Common Information Model (CIM) Base

FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and non-
governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC provides no marking procedure to indicate its approval and cannot be rendered responsible for any
equipment declared to be in conformity with an IEC Publication.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
The International Electrotechnical Commission (IEC) draws attention to the fact that it is claimed that compliance
with this document may involve the use of a patent concerning a computer-based implementation of an object-
oriented power system model in a relational database. As such, it does not conflict with the development of any
logical power system model including the Common Information Model (CIM), where implementation of the model is

not defined.
The IEC takes no position concerning the evidence, validity and scope of this patent right.
The holder of this patent right, ICL, has assured the IEC that they are willing to grant a royalty free license to any
entity implementing this standard. This license is issued by default, and vendors wishing to take up the license are
not required to notify ICL. The statement of the holder of this patent right is registered with IEC. Information may
be obtained from:
ICL
Wenlock Way
West Gorton
Manchester
M12 5DR
United Kingdom (U.K.)
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights
other than those identified above. IEC shall not be held responsible for identifying any or all such patent rights.

61970-301  IEC:2003(E) – 5 –
International Standard IEC 61970-301 has been prepared by IEC technical committee 57:
Power system control and associated communications.

The text of this standard is based on the following documents:

FDIS Report on voting
57/656/FDIS 57/682/RVD
Full information on the voting for the approval of this standard can be found in the report on

voting indicated in the above table.

This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.
The committee has decided that the contents of this publication will remain unchanged until
2006. At this date, the publication will be
• reconfirmed;
• withdrawn;
• replaced by a revised edition, or
• amended.
A bilingual version of this standard may be issued at a later date.

– 6 – 61970-301  IEC:2003(E)
INTRODUCTION
This standard is part of the IEC 61970 series, which defines an Application Program Interface

(API) for an Energy Management System (EMS). This standard is based upon the work of the

EPRI Control Center API (CCAPI) research project (RP-3654-1). The principle objectives of

the EPRI CCAPI project are to:

– reduce the cost and time needed to add new applications to an EMS;

– protect the investment of existing applications or systems that are working effectively with

an EMS.
The principal task of the CCAPI project is to produce requirements and draft text for
standards to facilitate the integration of EMS applications developed independently by
different vendors, between entire EMS systems developed independently, or between an EMS
system and other systems concerned with different aspects of power system operations, such
as generation or Distribution Management Systems (DMS). This is accomplished by defining
application program interfaces to enable these applications or systems access to public data
and exchange information independent of how such information is represented internally. The
Common Information Model (CIM) specifies the semantics for this API. The Component
Interface Specifications (CIS) specify the content of the messages exchanged.
This part of the series, IEC 61970-301, defines the CIM Base set of packages which provide a
logical view of the physical aspects of Energy Management System information. Future IEC
61970-302 defines the financial and energy scheduling logical view. Future IEC 61970-303
defines the SCADA logical view. The CIM is an abstract model that represents all the major
objects in an electric utility enterprise typically needed to model the operational aspects of a
utility. This model includes public classes and attributes for these objects, as well as the
relationships between them.
The objects represented in the CIM are abstract in nature and may be used in a wide variety
of applications. The use of the CIM goes far beyond its application in an EMS. This standard
should be understood as a tool to enable integration in any domain where a common power
system model is needed to facilitate interoperability and plug compatibility between
applications and systems independent of any particular implementation.

61970-301  IEC:2003(E) – 7 –
ENERGY MANAGEMENT SYSTEM APPLICATION

PROGRAM INTERFACE (EMS-API) –
Part 301: Common Information Model (CIM) Base

1 Scope
The Common Information Model (CIM) is an abstract model that represents all the major

objects in an electric utility enterprise typically involved in utility operations. By providing a
standard way of representing power system resources as object classes and attributes, along
with their relationships, the CIM facilitates the integration of Energy Management System
(EMS) applications developed independently by different vendors, between entire EMS
systems developed independently, or between an EMS system and other systems concerned
with different aspects of power system operations, such as generation or distribution
management. This is accomplished by defining a common language (i.e., semantics and
syntax) based on the CIM to enable these applications or systems to access public data and
exchange information independently of how such information is represented internally.
The object classes represented in the CIM are abstract in nature and may be used in a wide
variety of applications. The use of the CIM goes far beyond its application in an EMS. This
standard should be understood as a tool to enable integration in any domain where a common
power system model is needed to facilitate interoperability and plug compatibility between
applications and systems independent of any particular implementation.
Due to the size of the complete CIM, the object classes contained in the CIM are grouped into
a number of logical Packages, each of which represents a certain part of the overall power
system being modeled. Collections of these Packages are progressed as separate
International Standards. This part of IEC 61970 specifies a base set of packages which
provide a logical view of the physical aspects of Energy Management System (EMS)
information within the electric utility enterprise that is shared between all applications. Other
standards specify more specific parts of the model that are needed by only certain
applications. Subclause 4.2 below provides the current grouping of packages into standards
documents.
2 Normative references
The following referenced documents are indispensable for the application of this document.
For dated references, only the edition cited applies. For undated references, the latest edition
of the referenced document (including any amendments) applies.

IEC 61850 (all parts), Communication networks and systems in substations
ISO 8601, Data elements and interchange formats - Information interchange - Representation
of dates and times
3 Terms and definitions
For the purposes of this part of IEC 61970, the terms and definitions given in IEC 60050,
Annex A of this document and the following apply.

– 8 – 61970-301  IEC:2003(E)
3.1
Energy Management System
EMS
computer system comprising a software platform providing basic support services and a set of

applications providing the functionality needed for the effective operation of electrical

generation and transmission facilities so as to assure adequate security of energy supply at

minimum cost
3.2
Application Program Interface
API
set of public functions provided by an executable application component for use by other

executable application components
4 CIM specification
4.1 CIM modeling notation
The CIM is defined using object-oriented modeling techniques. Specifically, the CIM
specification uses the Unified Modeling Language (UML) notation, which defines the CIM as a
group of packages.
Each package in the CIM contains one or more class diagrams showing graphically all the
classes in that package and their relationships. Each class is then defined in text in terms of
its attributes and relationships to other classes.
The UML notation is described in Object Management Group (OMG) documents and several
published textbooks.
4.2 CIM packages
The CIM is partitioned into a set of packages. A package is a general purpose means of
grouping related model elements. There is no specific semantic meaning. The packages have
been chosen to make the model easier to design, understand and review. The common
information model consists of the complete set of packages. Entities may have associations
that cross many package boundaries. Each application will use information represented in
several packages.
The comprehensive CIM is partitioned into the following packages for convenience, where
packages are grouped to be handled as a single standard document as shown:

IEC 61970-301
– Core
– Domain
– Generation
– Generation Dynamics
– LoadModel
– Meas
– Outage
– Production
– Protection
– Topology
– Wires
61970-301  IEC:2003(E) – 9 –
Future IEC 61970-302
– Energy Scheduling
– Financial
– Reservation
Future IEC 61970-303
– SCADA
IEC 61968
– Assets
– Consumer
– Core2
– Distribution
– Documentation
Note that the package boundaries do not imply application boundaries. An application may
use CIM entities from several packages.
Figure 1 shows the packages defined for IEC 61970-301 CIM Base and their dependency
relationships. The dashed line indicates a dependency relationship, with the arrowhead
pointing from the dependent package to the package on which it has a dependency.
Generation LoadModel Outage Protection
Meas
Wires
Topology
Core <>
Domain
IEC  2608/03
Figure 1 – CIM Part 301 Package Diagram
The following Subclauses summarize the contents of each CIM package. Annex A contains
the specification for each of the CIM packages.
NOTE 1 The package definitions are loosely based on the “Conformance Blocks” that were defined for the CIM
specification version 7 defined in the EPRI CCAPI project.

– 10 – 61970-301  IEC:2003(E)

NOTE 2 The contents of the CIM defined in this specification were obtained from a straight conversion of the

CCAPI CIM static information model defined in the CCAPI CIM Version 10.

NOTE 3 Annex B contains a mapping of the information modeling notation used in the CCAPI CIM Version 7 to
the UML used in this standard specification. This Annex is intended to assist those readers who have previously
worked with the CCAPI CIM and who now need to adopt the new UML notation. Those readers not acquainted with

the previous CCAPI CIM notation may choose to not read Annex B.

4.2.1 Core
This package contains the core Naming, PowerSystemResource, EquipmentContainer, and

ConductingEquipment entities shared by all applications plus common collections of those

entities. Not all applications require all the Core entities. This package does not depend on

any other package, but most of the other packages have associations and generalizations that

depend on it.
4.2.2 Topology
This package is an extension to the Core package that in association with the Terminal class
models Connectivity, that is the physical definition of how equipment is connected together. In
addition, it models Topology, that is the logical definition of how equipment is connected via
closed switches. The Topology definition is independent of the other electrical characteristics.
4.2.3 Wires
The Wires package is an extension to the Core and Topology package that models
information on the electrical characteristics of Transmission and Distribution networks. This
package is used by network applications such as State Estimation, Load Flow and Optimal
Power Flow.
4.2.4 Outage
This package is an extension to the Core and Wires packages that model information on the
current and planned network configuration. These entities are optional within typical network
applications.
4.2.5 Protection
This package is an extension to the Core and Wires packages that model information for
protection equipment such as relays. These entities are used within training simulators and
distribution network fault location applications.
4.2.6 Meas
The Meas package contains entities that describe dynamic measurement data exchanged

between applications.
4.2.7 LoadModel
This package provides models for the energy consumers and the system load as curves and
associated curve data. Special circumstances that may affect the load, such as seasons and
daytypes, are also included here.
This information is used by Load Forecasting and Load Management.
4.2.8 Generation
The Generation package is divided into two subpackages: Production and Generation
Dynamics.
61970-301  IEC:2003(E) – 11 –

4.2.8.1 Production
This package provides models for various kinds of generators. It also models production

costing information which is used to economically allocate demand among committed units

and calculate reserve quantities.

This information is used by Unit Commitment and Economic Dispatch of Hydro and Thermal

Generating Units, Load Forecasting, and Automatic Generation Control applications.

4.2.8.2 Generation dynamics
This package provides models for prime movers, such as turbines and boilers, which are

needed for simulation and educational purposes.
This information is used by the Unit Modeling for Dynamic Training Simulator applications.
4.2.9 Domain
The Domain package is a data dictionary of quantities and units that define datatypes for
attributes (properties) that may be used by any class in any other package.
This package contains the definition of primitive datatypes, including units of measure and
permissible values. Each datatype contains a value attribute and an optional unit of measure,
which is specified as a static variable initialized to the textual description of the unit of
measure. Permissible values for enumerations are listed in the documentation for the attribute
using UML constraint syntax inside curly braces. String lengths are listed in the
documentation and are also specified as a length property.
4.3 CIM classes and relationships
The class diagram(s) for each CIM package shows all the classes in the package and their
relationships. Where relationships exist with classes in other packages, those classes are
also shown with a note identifying the package which owns the class.
Classes and objects model what is in a power system that needs to be represented in a
common way to EMS applications. A class is a description of an object found in the real world,
such as a power transformer, generator, or load that needs to be represented as part of the
overall power system model in an EMS. Other types of objects include things such as
schedules and measurements that EMS applications also need to process, analyze, and
store. Such objects need a common representation to achieve the purposes of the EMS-API
standard for plug-compatibility and interoperability. A particular object in a power system with
a unique identity is modeled as an instance of the class to which it belongs.

It should also be noted that the CIM is defined to facilitate data exchange. As defined in this
document, CIM entities have no behavior other than default create, delete, update and read.
In order to make the CIM as generic as possible, it is highly desirable to make it easy to
configure for specific implementations. In general it is easier to change the value or domain of
an attribute than to change a class definition. These principles imply that the CIM should
avoid defining too many specific sub-types of classes. Instead the CIM defines generic
classes with attributes giving the type name. Applications may then use this information to
instantiate specific object types as required. Applications may need additional information to
define the set of valid types and relationships.
Classes have attributes that describe the characteristics of the objects. Each class in the CIM
contains the attributes that describe and identify a specific instance of the class. Only the
attributes that are of public interest to EMS applications are included in the class descriptions.

– 12 – 61970-301  IEC:2003(E)

Each attribute has a type, which identifies what kind of attribute it is. Typical attributes are of
type integer, float, boolean, string, and enumeration, which are called primitive types.

However, many additional types are defined as part of the CIM specification. For example,

Compensator has a MaximumkV attribute of type Voltage. The definition of data types is

contained in the Domain Package described in Subclause 4.2.9.

Relationships between classes reveal how they are structured in terms of each other. CIM

classes are related in a variety of ways, as described in the Subclause below.

4.3.1 Generalization
A generalization is a relationship between a more general and a more specific class. The
more specific class can contain only additional information. For example, a Power
Transformer is a specific type of Power System Resource. Generalization provides for the
specific class to inherit attributes and relationships from all the more general classes above it.
Figure 2 is an example of generalization. In this example, taken from the Wires package, a
Breaker is a more specific type of Switch, which in turn is a more specific type of
ConductingEquipment, which is itself a more specific type of PowerSystemResource. A
PowerTransformer is another more specific type of PowerSystemResource.
PowerSystemResource
(from Core)
ConductingEquipment PowerTransformer
(from Core)
Switch
Breaker
IEC  2609/03
Figure 2 – Example of generalization
4.3.2 Simple association
An association is a conceptual connection between classes. Each association has two roles.
Each role is a direction on the association that describes the role the target class (i.e., the
class the role goes to) has in relation to the source class (i.e., the class the role goes from).
Roles are given the name of the target class with or without a verb phrase. Each role also has
multiplicity/cardinality, which is an indication of how many objects may participate in the given
relationship. In the CIM, associations are not named.
For example, in the CIM there is an association between a TapChanger and a Regulation
Schedule (See Figure 3, which is taken from the Wires package).

61970-301  IEC:2003(E) – 13 –

Multiplicity is shown at both ends of the association. In this example, a TapChanger object

may have 0 or 1 RegulationSchedules, and a RegulationSchedule may belong to 0, 1, or more

TapChanger objects.
RegulationSchedule
TapChanger
0.n 0.1
Tapchangers RegulationSchedule

IEC  2610/03
Figure 3 – Example of simple association

4.3.3 Aggregation
Aggregation is a special case of association. Aggregation indicates that the relationship
between the classes is some sort of whole-part relationship, where the whole class “consists
of” or “contains” the part class, and the part class is “part of” the whole class. The part class
does not inherit from the whole class as in generalization.
Figure 4 illustrates an aggregation between the TopologicalIsland class and the
TopologicalNode class, which is taken from the Topology package. As shown, a
TopologicalNode can be a member of exactly one TopologicalIsland, but a TopologicalIsland
can contain any number (but at least one) of TopologicalNodes.
TopologicalIsland
TopologicalNode
1 1.n
TopologicalIsland TopologicalNodes

IEC  2611/03
Figure 4 – Example of Aggregation
4.4 CIM model concepts and examples
The CIM classes, attributes, types, and relationships are specified in Annex A. Annex A
comprises a complete description of the CIM.
To help understand how to interpret the CIM, four examples are given in the following
paragraphs. The first is a portion of the Wires package class diagram illustrating how a
PowerTransformer is modeled. The second illustrates how the important concept of
Connectivity is modeled in the CIM. The third shows the inheritance hierarchy of devices
modeled in the CIM. The fourth illustrates the important concept of equipment containers.
4.4.1 Transformer model
Figure 5 shows a portion of the Wires class diagram, which models a PowerTransformer
device.
As shown, a PowerTransformer is a specialized class of Equipment, which is a specialized
class of a PowerSystemResource, as is ConductingEquipment and TapChanger. This is
shown by the use of the generalization-type of relationship, which uses an arrow to point to
the general class, and permits the PowerTransformer to inherit attributes from both Equipment
and PowerSystemResource.
A PowerTransformer also has a TransformerWinding, which is modeled with an aggregation-
type of relationship using a diamond symbol to point from the part class to the whole class. As
shown, a PowerTransformer may have (or contain) one or more TransformerWindings, but a
TransformerWinding may belong to (or be a member of) only one PowerTransformer.

– 14 – 61970-301  IEC:2003(E)

The TransformerWinding has other relationships as well:

– a generalization relationship with ConductingEquipment;

– an association relationship with the WindingTest class, such that a TransformerWinding

object may be TestedFrom from 0, 1, or more WindingTest objects;

– an aggregation relationship with the TapChanger class, such that a TransformerWinding

object may have 0, 1, or more TapChanger objects associated with it.

Annex A contains a complete description of each class in Figure 5 along with the definition of

all the attributes and relationships supported in each class.

PowerSystemResource
(from Core)
Equipment
PowerTransformer TapChanger
(from Core)
0.0.nn
+PowerTransformer
00.n.n
11 11
+ TapChangers
+TapChangers
+MemberOf_PowerTransformer
+HeatExchanger 0.0.11
HeatExchanger
+ Contains_TransformerWindings
+RegulationSchedule
1.1.nn
0.0.11
ConductingEquipment
TransformerWinding
RegulationSchedule
(from Core)
+TransformerWinding
0.0.nn
+To_TransformeWindings
+From_TransformerWinding
+ From_WindingTests
+To_WindingTest
0.0.nn
WindingTest
IEC  2612/03
Figure 5 – Transformer model
4.4.2 Connectivity model
Figure 6 shows the Topology class diagram which models connectivity between different
types of ConductingEquipment. Also included is a portion of the Meas package class diagram
dealing with measurements to illustrate how measurements are associated with conducting
equipment.
61970-301  IEC:2003(E) – 15 –

Naming
(from Core)
PowerSystemResource
(from Core)
+Terminals
+ConductingEquipm ent
0.0.nn
0.0.11
ConductingEquipment Terminal
(from Core) (from Core)
0.0.nn
+Terminals
0.0.11
+Terminal
+MemberOf_EquipmentContainer
E quipmentContainer
(from Core)
+ConnectivityNode
+ConnectivityNodes
0.0.11
0.0.nn
ConnectivityNode
+Measurements
0.0.nn
0.0.nn
Measurement
+ConnectivityNodes
(from Meas)
+TopologicalNode
Switch/Node
Model
0.0.11
TopologicalNode
+TopologicalNodes
1.1.nn
Bus/Branch
Model
+TopologicalIsland
TopologicalIsland
IEC  2613/03
Figure 6 – Connectivity model
To model connectivity, Terminal and Connectivity classes are defined. A Terminal belongs to
one ConductingEquipment, although ConductingEquipment may have any number of
Terminals. Each Terminal may be connected to a ConnectivityNode, which is a point where
terminals of conducting equipment are connected together with zero impedance. A
ConnectivityNode may have any number of terminals connected, and may be a member of a
TopologicalNode (i.e., a bus), which is in turn a member of a TopologicalIsland.
TopologicalNodes and TopologicalIslands are created as a result of a topology processor
evaluating the “as built” topology and the actual switch positions.

– 16 – 61970-301  IEC:2003(E)

EquipmentContainers, which are a specialization of a PowerSystemResource, may contain
zero or more ConnectivityNodes. The associations, ConductingEquipment – Terminal and

Terminal – ConnectivityNode, capture the as built topology of an actual power system

network. For each Terminal connected to a ConnectivityNode, the associations of the other

Terminal(s) connected to the same ConnectivityNode identify the ConductingEquipment

object(s) that are electrically connected.

To model the analog values such as voltage and power, each Terminal has an association

with a Measurement class from the Meas package. Although not shown in Figure 6, a

Measurement object is associated with at least one MeasurementValue object. Each

MeasurementValue object is an instance of a measurement from a specific source, for

example, a telemetered measurement. In a study context, the measurement values would
have a calculation source instead.
Annex A contains a complete description of each class in Figure 6 along with the definition of
all the attributes and relationships supported in each class.
4.4.2.1 Connectivity and containment example
To illustrate how the connectivity model and containment model would appear as objects, a
small example is presented in Figure 7. The example shows a transmission line with a T-
junction spanning two substations and a substation having two voltage levels with a
transformer between them. The transmission line consists of two different cables. One of the
voltage levels is shown with a busbar section having a single busbar and two very simple
switchgear bays connecting to the busbar.
SS2
400 kV
SS1 - SS2
SS1
Cable1 Cable2
12 345 MW
Cable3
12 345 kV
BB1
12 345 MW
SS4
T1
110 kV
IEC  2614/03
Figure 7 – Simple Network Example
Figure 8 shows how connectivity is modeled in the CIM as well as one way (but not
necessarily the only way) containment is modeled for the diagram in Figure 6. The shaded
square boxes represent EquipmentContainers, and the white square boxes represent
ConductingEquipment. Darker shading indicates the EquipmentContainer is higher up in the
containment hierarchy (i.e., Substation is highest, VoltageLevel next, etc.). White circles
represent ConnectivityNodes, and black small circles represent Terminals. A Terminal
belongs to a ConductingEquipment, and a ConnectivityNode belongs to an Equipment
Container. This means that the borders (or contact points) between ConductingEquipment are
their Terminals interconnected via ConnectivityNodes.

61970-301  IEC:2003(E) – 17 –

SS 2
400 kV
BB1
SS1 - SS2
Volts (kV)
P1
SS1
(MW) SS3
CN5
DC2 CN4 CN3 CN2 CN1
Cable 1 Cable 2
BR1
BR3
P2 (MW)
CN6
TW 1
CN8
T 1
TW 2
SS4
CN7
110 kV
IEC  2615/03
Figure 8– Simple network connectivity modeled with CIM topology
The Line SS1-SS2 has two ACLineSegments – Cable1 and Cable2. A collapsed Substation
SS3 with ConnectivityNode CN2 models the connection point between the ACLineSegments
as well as a T-junction to Cable3, which provides a connection to Substation 4. Each
ACLineSegment has two Terminals. Cable1 is connected to CN3 and CN2 via these
Terminals. CN3 is contained by the VoltageLevel 400 kV. The breaker BR1 has two term
...