EN 61970-301:2004

SLOVENSKI STANDARD
01-maj-2004
Energy management system application program interface (EMS-API) - Part 301:
Common Information Model (CIM) Base (IEC 61970-301:2003)
Energy management system application program interface (EMS-API) -- Part 301:
Common Information Model (CIM) base
Anwendungsprogramm-Schnittstelle für Netzführungssysteme (EMS-API) -- Teil 301:
Allgemeines Informationsmodell (CIM), Basismodell
Système de gestion d'énergie - Interface de programmation d'application (EMS-API) --
Partie 301: Base de Modèle d'Information Commun (CIM)
Ta slovenski standard je istoveten z: EN 61970-301:2004
ICS:
29.240.30 Krmilna oprema za Control equipment for electric
elektroenergetske sisteme power systems
35.200 Vmesniška in povezovalna Interface and interconnection
oprema equipment
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD EN 61970-301
NORME EUROPÉENNE
EUROPÄISCHE NORM March 2004
ICS 33.200
English version
Energy management system application program interface (EMS-API)
Part 301: Common Information Model (CIM) Base
(IEC 61970-301:2003)
Système de gestion d'énergie –  Anwendungsprogramm-Schnittstelle für
Interface de programmation d'application Netzführungssysteme (EMS-API)
(EMS-API) Teil 301: Allgemeines Informationsmodell
Partie 301: Base de Modèle d'Information (CIM), Basismodell
Commun (CIM) (IEC 61970-301:2003)
(CEI 61970-301:2003)
This European Standard was approved by CENELEC on 2004-02-01. CENELEC members are bound to
comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this European
Standard the status of a national standard without any alteration.

Up-to-date lists and bibliographical references concerning such national standards may be obtained on
application to the Central Secretariat or to any CENELEC member.

This European Standard exists in three official versions (English, French, German). A version in any other
language made by translation under the responsibility of a CENELEC member into its own language and
notified to the Central Secretariat has the same status as the official versions.

CENELEC members are the national electrotechnical committees of Austria, Belgium, Cyprus, Czech
Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia,
Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Slovakia, Slovenia, Spain, Sweden,
Switzerland and United Kingdom.

CENELEC
European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung

Central Secretariat: rue de Stassart 35, B - 1050 Brussels

© 2004 CENELEC - All rights of exploitation in any form and by any means reserved worldwide for CENELEC members.

Ref. No. EN 61970-301:2004 E
Foreword
The text of document 57/656/FDIS, future edition 1 of IEC 61970-301, prepared by IEC TC 57, Power
systems management and associated information exchange, was submitted to the IEC-CENELEC
parallel vote and was approved by CENELEC as EN 61970-301 on 2004-02-01.
The following dates were fixed:
– latest date by which the EN has to be implemented
at national level by publication of an identical
national standard or by endorsement (dop) 2004-11-01
– latest date by which the national standards conflicting
with the EN have to be withdrawn (dow) 2007-02-01
The International Electrotechnical Commission (IEC) and CENELEC draw 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 and CENELEC take 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 the IEC. Information may be obtained from:
ICL
Wenlock WAY
West Gorton
Manchester
M12 5DR
United Kingdom
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 and CENELEC shall not be held responsible for
identifying any or all such patent rights.
Annex ZA has been added by CENELEC.
__________
Endorsement notice
The text of the International Standard IEC 61970-301:2003 was approved by CENELEC as a
European Standard without any modification.
__________
- 3 - EN 61970-301:2004
Annex ZA
(normative)
Normative references to international publications
with their corresponding European publications
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.
NOTE When an international publication has been modified by common modifications, indicated by (mod), the relevant
EN/HD applies.
Publication Year Title EN/HD Year
IEC 61850 Series Communication networks and systems EN 61850 Series
in substations
ISO 8601 1988 Data elements and interchange formats EN 28601 1992
- Information interchange -
Representation of dates and times

NORME CEI
INTERNATIONALE IEC
61970-301
INTERNATIONAL
Première édition
STANDARD
First edition
2003-11
Interface de programmation d'application
pour système de gestion d'énergie (EMS-API) –
Partie 301:
Base de modèle d'information commun (CIM)

Energy management system application
program interface (EMS-API) –
Part 301:
Common Information Model (CIM) base

 IEC 2005 Droits de reproduction réservés  Copyright - all rights reserved
Aucune partie de cette publication ne peut être reproduite ni No part of this publication may be reproduced or utilized in any
utilisée sous quelque forme que ce soit et par aucun procédé, form or by any means, electronic or mechanical, including
électronique ou mécanique, y compris la photocopie et les photocopying and microfilm, without permission in writing from
microfilms, sans l'accord écrit de l'éditeur. 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
CODE PRIX
Commission Electrotechnique Internationale PRICE CODE XJ
International Electrotechnical Commission
Международная Электротехническая Комиссия
Pour prix, voir catalogue en vigueur
For price, see current catalogue

61970-301  IEC:2005 – 3 –
CONTENTS
FOREWORD.7
INTRODUCTION.11

1 Scope.13
2 Normative references.13
3 Terms and definitions .13
4 CIM specification.15
4.1 CIM modeling notation .15
4.2 CIM packages.15
4.3 CIM classes and relationships .21
4.4 CIM model concepts and examples .27
4.5 Modeling tools.41
4.6 Modeling guidelines.41
4.7 User implementation conventions .43
4.8 Examples.51

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

Bibliography .369

Figure 1 – CIM Part 301 Package Diagram.17
Figure 2 – Example of generalization .25
Figure 3 – Example of Simple Association .25
Figure 4 – Example of Aggregation .27
Figure 5 – Transformer Model .29
Figure 6 – Connectivity Model .31
Figure 7 – Simple Network Example .33
Figure 8 – Simple Network Connectivity Modeled with CIM Topology .35
Figure 9 – Equipment Inheritance Hierarchy .37
Figure 10 – Equipment Containers .39
Figure 11 – Navigating from PSR to MeasurementValue .47
Figure 12 – Measurement placement.51
Figure A.1 – CIM Top Level Packages.53
Figure A.2 – Main .55
Figure A.3 – Main .57
Figure A.4 – Integer Datatypes.81
Figure A.5 – Float Datatypes.83
Figure A.6 – String Datatypes .85
Figure A.7 – Other Datatypes.87

61970-301  IEC:2005 – 5 –
Figure A.8 – Enumeration Datatypes .89
Figure A.9 – Main .129
Figure A.10 – Main .131
Figure A.11 – Hydro.133
Figure A.12 – Thermal .135
Figure A.13 – Main .205
Figure A.14 – Main .233
Figure A.15 – Main .253
Figure A.16 – Measurements .255
Figure A.17 – Quality .257
Figure A.18 – Main .275
Figure A.19 – Main .281
Figure A.20 – Main .287
Figure A.21 – Transformer Model .293
Figure A.22 – EquipmentContainment .295
Figure A.23 – InheritanceHierarchy .297
Figure A.24 – LineModel .299
Figure A.25 – RegulatingEquipment .301
Figure A.26 – VoltageControl .303

Table 1 – MeasurementType Naming Conventions .47
Table 2 – MeasurementValueSource Naming Conventions.49
Table B.1 – CIM Mapping Conventions.365

61970-301  IEC:2005 – 7 –
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:2005 – 9 –
International Standard IEC 61970-301 has been prepared by IEC technical committee 57:
Power systems management and associated information exchange.
This bilingual version (2005-03) replaces the English version.
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.
The French version of this standard has not been voted upon.
This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.
IEC 61970 consists of the following parts, under the general title Energy management system
application program interface (EMS-API):
Part 1: Guidelines and general requirements
Part 2: Glossary
Part 301: Common Information Model (CIM) base
Part 401: Component interface specification framework
The committee has decided that the contents of this publication will remain unchanged until
the maintenance result date indicated on the IEC web site under "http://webstore.iec.ch" in
the data related to the specific publication. At this date, the publication will be
• reconfirmed;
• withdrawn;
• replaced by a revised edition, or
• amended.
61970-301  IEC:2005 – 11 –
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 principal 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 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:2005 – 13 –
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 – Represent-
ation 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.

61970-301  IEC:2005 – 15 –
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:2005 – 17 –
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.

61970-301  IEC:2005 – 19 –
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.
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.

61970-301  IEC:2005 – 21 –
4.2.8 Generation
The Generation package is divided into two subpackages: Production and Generation
Dynamics.
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.

61970-301  IEC:2005 – 23 –
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.
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 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.

61970-301  IEC:2005 – 25 –
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).
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.

61970-301  IEC:2005 – 27 –
Figure 4 illustrates an aggregation between the TopologicalIsland class and the Topological
Node 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.
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.

61970-301  IEC:2005 – 29 –
PowerSystemResource
(from Core)
Equipment
PowerTransformer TapChanger
(from Core)
0.0.nn
+PowerTransformer
00.n.n
11 11
+ TapChangers
+TapChangers
+MemberOf_PowerTransformer
+HeatExchanger 00.11
HeatExchanger
+ Contains _TransformerWindings
+RegulationSchedule
11.n.n
0.0.11
ConductingEquipment
TransformerWinding
RegulationSchedule
(from Core)
+TransformerWinding
00.n.n 11
+To_TransformeWindings
+From_TransformerWinding
+From_WindingTests
+To_WindingTest
00.n.n
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:2005 – 31 –
Naming
(from Core)
PowerSystemResource
(from Core)
+Terminals
+ConductingEquipm ent
0.0.nn
00.1.1
ConductingEquipment Terminal
(from Core) (from Core)
00.n.n
+Terminals
0.0.11
+Terminal
+MemberOf_EquipmentContainer
E quipmentContainer
(from Core)
+ConnectivityNode
+ConnectivityNodes
0.0.11
00.n.n
ConnectivityNode
+Measurements
0.0.nn
00.n.n
Measurement
+ConnectivityNodes
(from Meas)
+TopologicalNode
Switch/Node
Model
00.1.1
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.

61970-301  IEC:2005 – 33 –
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
...