IEC 61970-552:2013

IEC 61970-552 ®
Edition 1.0 2013-10
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
colour
inside
Energy management system application program interface (EMS-API) –
Part 552: CIMXML Model exchange format

Interface de programmation d’application pour système de gestion d'énergie
(EMS-API) –
Partie 552: Format d’échange de modèle CIMXML

All rights reserved. Unless otherwise specified, 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
either IEC or IEC's member National Committee in the country of the requester.
If you have any questions about IEC copyright or have an enquiry about obtaining additional rights to this publication,
please contact the address below or your local IEC member National Committee for further information.

Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite ni
utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et les
microfilms, sans l'accord écrit de la CEI ou du Comité national de la CEI du pays du demandeur.
Si vous avez des questions sur le copyright de la CEI ou si vous désirez obtenir des droits supplémentaires sur cette
publication, utilisez les coordonnées ci-après ou contactez le Comité national de la CEI de votre pays de résidence.

IEC Central Office Tel.: +41 22 919 02 11
3, rue de Varembé Fax: +41 22 919 03 00
CH-1211 Geneva 20 info@iec.ch
Switzerland www.iec.ch
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigenda or an amendment might have been published.

Useful links:
IEC publications search - www.iec.ch/searchpub Electropedia - www.electropedia.org
The advanced search enables you to find IEC publications The world's leading online dictionary of electronic and
by a variety of criteria (reference number, text, technical electrical terms containing more than 30 000 terms and
committee,…). definitions in English and French, with equivalent terms in
It also gives information on projects, replaced and additional languages. Also known as the International
withdrawn publications. Electrotechnical Vocabulary (IEV) on-line.

IEC Just Published - webstore.iec.ch/justpublished Customer Service Centre - webstore.iec.ch/csc
Stay up to date on all new IEC publications. Just Published If you wish to give us your feedback on this publication
details all new publications released. Available on-line and or need further assistance, please contact the
also once a month by email. Customer Service Centre: csc@iec.ch.

A propos de la CEI
La Commission Electrotechnique Internationale (CEI) est la première organisation mondiale qui élabore et publie des
Normes internationales pour tout ce qui a trait à l'électricité, à l'électronique et aux technologies apparentées.

A propos des publications CEI
Le contenu technique des publications de la CEI est constamment revu. Veuillez vous assurer que vous possédez
l’édition la plus récente, un corrigendum ou amendement peut avoir été publié.

Liens utiles:
Recherche de publications CEI - www.iec.ch/searchpub Electropedia - www.electropedia.org
La recherche avancée vous permet de trouver des Le premier dictionnaire en ligne au monde de termes
publications CEI en utilisant différents critères (numéro de électroniques et électriques. Il contient plus de 30 000
référence, texte, comité d’études,…). termes et définitions en anglais et en français, ainsi que
Elle donne aussi des informations sur les projets et les les termes équivalents dans les langues additionnelles.
publications remplacées ou retirées. Egalement appelé Vocabulaire Electrotechnique
International (VEI) en ligne.
Just Published CEI - webstore.iec.ch/justpublished
Service Clients - webstore.iec.ch/csc
Restez informé sur les nouvelles publications de la CEI.
Just Published détaille les nouvelles publications parues. Si vous désirez nous donner des commentaires sur
Disponible en ligne et aussi une fois par mois par email. cette publication ou si vous avez des questions
contactez-nous: csc@iec.ch.
IEC 61970-552 ®
Edition 1.0 2013-10
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
colour
inside
Energy management system application program interface (EMS-API) –

Part 552: CIMXML Model exchange format

Interface de programmation d’application pour système de gestion d'énergie

(EMS-API) –
Partie 552: Format d’échange de modèle CIMXML

INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
COMMISSION
ELECTROTECHNIQUE
PRICE CODE
INTERNATIONALE
CODE PRIX V
ICS 33.200 ISBN 978-2-8322-1180-9

– 2 – 61970-552 © IEC:2013
CONTENTS
FOREWORD . 3
INTRODUCTION . 5
1 Scope . 6
2 Normative references . 6
3 Terms and definitions. 7
4 Model exchange header . 9
4.1 General . 9
4.2 CIMXML documents and headers . 9
4.3 Model and header data description . 10
4.4 Work flow . 12
5 Object identification . 13
5.1 URIs as identifiers . 13
5.2 About rdf:ID and rdf:about . 14
5.3 CIMXML element identification . 14
6 CIMXML format rules and conventions . 15
6.1 General . 15
6.2 Simplified RDF syntax . 16
6.2.1 General. 16
6.2.2 Notation . 16
6.2.3 Syntax definition . 16
6.2.4 Syntax extension for difference model . 21
6.3 CIMXML format style guide . 26
6.4 Representing new, deleted and changed objects as CIMXML elements . 27
6.5 CIM RDF schema generation with CIM profile . 27
6.6 CIM extensions . 28
6.7 RDF simplified syntax design rationale . 28
Bibliography . 30

Figure 1 – Model with header . 10
Figure 2 – Example work flow events . 12
Figure 3 – Example work flow events with more dependencies. 13
Figure 4 – CIMXML-based power system model exchange mechanism . 15
Figure 5 – Relations between UML, profile and CIMXML tools . 28

Table 1 – Header attributes . 11

61970-552 © IEC:2013 – 3 –
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
ENERGY MANAGEMENT SYSTEM APPLICATION
PROGRAM INTERFACE (EMS-API) –
Part 552: CIMXML Model exchange format

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 itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
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.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
International Standard IEC 61970-552 has been prepared by IEC technical committee 57:
Power systems management and associated information exchange.
The text of this standard is based on the following documents:
FDIS Report on voting
57/1386/FDIS 57/1402/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.
A list of all parts in the IEC 61970 series, published under the general title Energy management
system application program interface (EMS-API), can be found on the IEC website.

– 4 – 61970-552 © IEC:2013
The committee has decided that the contents of this publication will remain unchanged until the
stability 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.
IMPORTANT – The 'colour inside' logo on the cover page of this publication indicates
that it contains colours which are considered to be useful for the correct understanding
of its contents. Users should therefore print this document using a colour printer.

61970-552 © IEC:2013 – 5 –
INTRODUCTION
This International standard is part of the IEC 61970 series that define an Application Program
Interface (API) for an Energy Management System (EMS).
IEC 61970-301 specifies a Common Information Model (CIM): a logical view of the physical
aspects of an electric utility operations. The CIM is described using the Unified Modelling
Language (UML), a language used to specify, visualize, and document systems in an object-
oriented manner. UML is an analysis and design language; it is not a programming language.
In order for software programs to use the CIM, it must be transformed into a schema form that
supports a programmable interface.
IEC 61970-501 describes the translation of the CIM in UML form into a machine readable
format as expressed in the Extensible Markup Language (XML) representation of that schema
using the Resource Description Framework (RDF) Schema specification language.
IEC 61970-552 specifies how the CIM RDF schema specified in IEC 61970-501 is used to
exchange power system models using XML (referred to as CIMXML) defined in the 61970-45x
series of profile standards, such as the CIM Transmission Network Model Exchange Profile
described in IEC 61970-452.
– 6 – 61970-552 © IEC:2013
ENERGY MANAGEMENT SYSTEM APPLICATION
PROGRAM INTERFACE (EMS-API) –
Part 552: CIMXML Model exchange format

1 Scope
This International Standard specifies a Component Interface Specification (CIS) for Energy
Management Systems Application Program Interfaces. This part specifies the format and rules
for exchanging modelling information based upon the CIM. It uses the CIM RDF Schema
presented in IEC 61970-501 as the meta-model framework for constructing XML documents of
power system modelling information. The style of these documents is called CIMXML format.
Model exchange by file transfer serves many useful purposes. Profile documents such as
IEC 61970-452 and other profiles in the 61970-45x series of standards explain the
requirements and use cases that set the context for this work. Though the format can be used
for general CIM-based information exchange, specific profiles (or subsets) of the CIM are
identified in order to address particular exchange requirements. The initial requirement driving
the solidification of this specification is the exchange of transmission network modelling
information for power system security coordination.
This standard supports a mechanism for software from independent suppliers to produce and
consume CIM described modelling information based on a common format. The proposed
solution:
• is both machine readable and human readable, although primarily intended for
programmatic access,
• can be accessed using any tool that supports the Document Object Model (DOM) and other
standard XML application program interfaces,
• is self-describing,
• takes advantage of current World Wide Web Consortium (W3C) recommendations.
This document is the Level 2 Component Interface Specification document that describes in
narrative terms (with text and examples based on the CIM) the detailed definition of the
CIMXML format.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and
are indispensable for its application. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments)
applies.
IEC 60050 series, International Electrotechnical Vocabulary
IEC 61968-11, Application integration at electric utilities – System interfaces for distribution
management – Part 11: Common information model (CIM) extensions for distribution
IEC/TS 61970-2, Energy management system application program interface (EMS-API) –
Part 2: Glossary
IEC 61970-301, Energy management system application program interface (EMS-API) – Part
301: Common information model (CIM) base

61970-552 © IEC:2013 – 7 –
IEC 61970-501, Energy management system application program interface (EMS-API) – Part
501: Common Information Model Resource Description Framework (CIM RDF) schema
W3C: RDF/XML Syntax Specification
W3C: Extensible Markup Language (XML) 1.0
W3C: XSL Transformations (XSLT)
W3C: Document Object Model (DOM)
3 Terms and definitions
For the purposes of this International Standard, the terms and definitions contained in
IEC 60050 (for general glossary) and IEC 61970-2 (for EMS-API glossary definitions), as well
as the following apply.
3.1
Application Program Interface
API
set of public functions provided by an executable application component for use by other
executable application components
3.2
Common Information Model
CIM
abstract model that represents all the major objects in an electric utility enterprise typically
contained in an EMS information model
Note 1 to entry: 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 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.
3.3
CIMXML
serialisation format for exchange of XML data as defined in this document
3.4
Document Object Model
DOM
platform- and language-neutral interface defined by the World Wide Web Consortium (W3C)
that allows programs and scripts to dynamically access and exchange the content, structure
and style of documents
3.5
Document Type Definition
DTD
standard for describing the vocabulary and syntax associated with an XML document
Note 1 to entry: XML Schema and RDF are other forms that can be used.
3.6
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

– 8 – 61970-552 © IEC:2013
generation and transmission facilities so as to assure adequate security of energy supply at
minimum cost
3.7
Hypertext Markup Language
HTML
mark-up language used to format and present information on the Web
3.8
model
collection of data describing objects or entities real or computed
Note 1 to entry: In the context of CIM the semantics of the data is defined by profiles; refer to 3.9.
Note 2 to entry: In power system analysis, a model is a set of static data describing the power system. Examples of
Models include the Static Network Model, the Topology Solution, and the Network Solution produced by a power
flow or state estimator application.
3.9
profile
schema that defines the structure and semantics of a model that may be exchanged
Note 1 to entry: A Profile is a restricted subset of the more general CIM.
3.10
profile document
collection of profiles intended to be used together for a particular business purpose
3.11
Resource Description Framework
RDF
language recommended by the W3C for expressing metadata that machines can process
simply
Note 1 to entry: RDF uses XML as its encoding syntax.
3.12
RDF Schema
schema specification language expressed using RDF to describe resources and their
properties, including how resources are related to other resources, which is used to specify an
application-specific schema
3.13
Real-World Object
objects that belong to the real world problem domain as distinguished from interface objects
and controller objects within the implementation
Note 1 to entry: The real-world objects for the EMS domain are defined as classes in IEC 61970-301 Common
Information Model.
Note 2 to entry: 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 PowerTransformer,
GeneratingUnit, 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-552 © IEC:2013 – 9 –
3.14
Standard Generalized Markup Language
SGML
international standard for the definition of device-independent, system-independent methods of
representing texts in electronic form
Note 1 to entry: HTML and XML are derived from SGML.
3.15
Unified Modeling Language
UML
object-oriented modeling language and methodology for specifying, visualizing, constructing,
and documenting the artifacts of a system-intensive process
3.16
Uniform Resource Identifier
URI
Web standard syntax and semantic for identifying (referencing) resources (things, such as
files, documents, images).
3.17
eXtensible Markup Language
XML
subset of Standard Generalized Markup Language (SGML), ISO 8879, for putting structured
data in a text file
Note 1 to entry: This is an endorsed recommendation from the W3C. It is license-free, platform-independent and
well-supported by many readily available software tools.
3.18
eXtensible Stylesheet Language
XSL
language for expressing stylesheets for XML documents
4 Model exchange header
4.1 General
Model exchange typically involves the exchange of a collection of documents, each of which
contains instance data (referred to as a model) and a header. The structure and semantics of
each model are described by a profile, which is not included in the exchanged data. The overall
exchange is governed by a collection of profiles in a Profile Document.
A header describes the content of the model contained in a document e.g. the date the model
was created, description etc. The header may also identify other models and their relationship
to the present model. Such information is important when the models are part of a work flow
where, for example, the models have relations to each other, e.g. a model succeeds and/or
depends on another.
Subclauses 4.2 to 4.4 define the model with header data and work flow it is designed to
support.
4.2 CIMXML documents and headers
A CIMXML document is described by a single header. Multiple headers in a CIMXML document
are not allowed. Hence instance data in a CIMXML document adhere to a single profile.

– 10 – 61970-552 © IEC:2013
In case multiple and possibly related CIMXML documents need to be kept together they shall
be collected in an archive, e.g. zip.
4.3 Model and header data description
A description of a model is attached as header data to the model. Figure 1 describes the model
with header information.
class Header Model
Model
+Depending 0.*
+ created :DateTime
+DependentOn 0.*
+ scenarioTime :DateTime
«Primitive»
+ description :String
URI
+ modelingAuthoritySet :URI [0.1]
+SupersededBy 0.*
{root}
+ profile :URI [1.*]
+ version :String
+Supersedes 0.*
FullModelDocumentElement
+forwardDifferences
Statements
DifferenceModel FullModel
0.1
+reverseDifferences
0.1
IEC  2767/13
Figure 1 – Model with header
In Figure 1 the classes FullModel, DifferenceModel and Statements describe the model data
while the header is described by the classes Model and Description. The following is a bottom
up description of these classes:
• The FullModelDocumentElement class represents any of the elements that may appear in a
full model document. It has the two sub types Statements or FullModel, both are further
described below. A full model document typically contains one FullModel element and one
set of Definition elements.
• The Statements class represent a set of Definition (refer to 6.2.3.5) and/or Description
(refer to 6.2.3.6) elements.
• The FullModel (refer to 6.2.3.4) class represent the full model header and its contents is
described by the Model class.
• The DifferenceModel (refer to 6.2.4.6) class represents the difference model header. The
content is described by the Model class, the association role forwardDifferences and
association role reverseDifferences. Both association roles may have one set of
Statements.
• The Model class describes the header content that is the same for the FullModel and the
DifferenceModel. A Model is identified by an rdf:about attribute. The rdf:about attribute
uniquely describe the model and not the document where the header exists. Hence multiple
documents created from the same unchanged data model will have the same rdf:about.
This also means that a model change result in a new rdf:about next time a document is
created.
61970-552 © IEC:2013 – 11 –
The Model class attributes are described in Table 1.
Table 1 – Header attributes
Class Attribute Description
Model created The date when the model was created (note this is typically not when the
CIMXML document was created which is after this time).
Model scenarioTime The date and time that the model represents, e.g. the current time for an
operational model, a historical model or a future planned model.
Model description A description of the model, .e.g. the name of person that created the
model and for what purpose.
Model modelingAuthoritySet A URN describing the equipment model sourcing the data in a CIMXML
document, e.g. a model for the whole or a part of a country.
Model profile A URN describing the Profiles that governs this model. It uniquely
identifies the Profile and its version.
Model version A description of the version of the model sourcing the data in a CIMXML
document. Examples are
– Variations of the equipment model for the ModelingAuthoritySet
– Different study cases resulting in different solutions.
The version attribute is a custom string that is changed in synchronisation
with the rdf:about identifier, refer to description of the Model class above.
Model DependentOn A reference to the models that the model described by this document
depends on, e.g.
– A load flow solution depends on the topology model it was computed
from
– A topology model computed by a topology processor depends on the
network model it was computed from.
Model Depending All models depending on this model. This role is not intended to be
included in any document exchanging instance data.
Model Supersedes When a model is updated the resulting model supersedes the models that
were used as basis for the update. Hence this is a reference to CIMXML
documents describing the updated models.
Model SupersededBy All models superseding this model. This role is not intended to be
included in any document exchanging instance data.

The profile attribute is a URI having the following format:
http://iec.ch///-//
e.g. http://iec.ch/TC57/2011/61970-452/Equipment/2
The UML in Figure 1 translates into CIMXML elements as follows:
1) A leaf class in Figure 1 (DifferenceModel, Statements and FullModel) appears as class
elements under the document element (6.2.3.3).
2) Statement elements appear as Definition (6.2.3.5) or Description elements (6.2.3.6).
3) Literal attributes, e.g. Model.created, appears as literal property elements (6.2.3.8).
4) Roles appear, e.g. Model.Supersedes, as resource property elements (6.2.3.10).
5) Inherited attributes and roles appear directly as elements under the leaf class following
the rules 3, 4 and 5 above.
6) A CIMXML model document is identified by a Model rdf:about attribute (implicit in the
UML). Hence the roles DependentOn and Supersedes are references to the Model
rdf:about attribute.
– 12 – 61970-552 © IEC:2013
7) A full model document may be regenerated multiple times from the same source data.
Full model documents regenerated from unchanged source data keep the model
identification (Model rdf:about) unchanged from the original full model document.
8) When generating a full model document superseding a differential the new full model
document will have the same model identification (Model rdf:about) as the differential if
the model is unchanged since the differential was created. Hence it is an alternate to
the differential.
4.4 Work flow
A work flow is described by a sequence of exchange events. The model description in 4.3
supports work flow events related in time with the Model.Supersedes attribute and events
related to profiles with the Model.DependentOn attribute. An example of this is shown in
Figure 2.
State
Equipment Topology
Variables
E1 T1 S1
S2
T2
S3
Time
E2
S4
T3
S5
E3
E3
T4
S6
E4
Profile
Full model
DifferentialModel
DependentOn
IEC  2768/13
Supersedes
Figure 2 – Example work flow events
In this example, a solved network model is exchanged as a collection of models governed by a
Profile Document comprising Equipment, Topology, and State Variables documents. The left
time line in Figure 2 represents how the Equipment model document is exchanged over time.
The center time line shows how new Topology results are exchanged over time and the
Equipment models on which each depends. The right most time line shows how multiple State
Variable documents are exchanged and the Topology documents on which they depend. Also
note that the equipment model E3 is represented both by a full and an incremental document.
The situation in Figure 2 represents a simple case. A more complex situation is shown in
Figure 3.
61970-552 © IEC:2013 – 13 –
Equipment Topology
T1
E1
Profile
E -C
E-A1 Full Model
TA
Differential
E -B1
Model
TB
DependentOn
Supersedes
E-B2
E A2
TABa
TABb
E AB
T2b
E2
IEC  2769/13
Figure 3 – Example work flow events with more dependencies
The CIMXML documents in Figure 3 may be created from a data modeller environment where
multiple change tracks of a model appear in parallel, e.g. the equipment model has three
tracks E-Ax, E-Bx and E-C that eventually merge into the full model E2 superseding the
equipment model tracks.
A receiver of the CIMXML documents may use any of the topology documents TA, TB, TABa or
T2b with the equipment model from E2. As the sender (the data modeller in this example) only
verified T2b with E2 this is the only combination that is supposed to fit together. Concerning
T2b the receiver may choose to apply TB and TABb to T1 instead of using T2b.
5 Object identification
5.1 URIs as identifiers
UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier) can be
used to identify resources in such a way that the
• identifiers can be independently and uniquely allocated by different authorities. This is a big
advantage with the UUID.
• identifiers are stable over time and across documents.
If, in addition, the UUID is embedded in a Uniform Resource Name (URN) then the document
can be simplified by the elimination of XML base namespace declarations (xml:base attributes).
The URN is a concise, fixed-length, absolute URI.
The standard for an URN containing a UUID is defined by the Internet Engineering Task Force
RFC 4122.
– 14 – 61970-552 © IEC:2013
RFC 4122 specifies the syntax of the URN and how the UUID portion following the last colon is
allocated. The algorithm is aligned with, and technically compatible with, IEC 9834-8:2004
Information Technology, "Procedures for the operation of OSI Registration Authorities:
Generation and registration of Universally Unique Identifiers (UUIDs) and their use as ASN.1
Object Identifier components" ITU-T Rec. X.667, 2004.
CIMXML elements are identified by a URI. A URI can have two forms:
• URL
• URN
The URL and URN forms have fundamentally different structures, i.e.:
• URL form; protocol://authority/path?query#fragment where the protocol in CIMXML is http
• URN form: urn:namespace:specification where the namespace in CIMXML is uuid.
The URN specification format is summarized below
• 8 character hex number
• a dash “-“
• 4 character hex number
• a dash “-“
• 4 character hex number
• a dash “-“
• 4 character hex number
• a dash “-“
• 12 character hex number
where letters are lower case.
An example of the URN form is shown below
• ”urn:uuid:26cc8d71-3b7e-4cf8-8c93-8d9d557a4846”.
5.2 About rdf:ID and rdf:about
A CIMXML element can be identified by two different RDF constructs:
• rdf:ID
• rdf:about
The use of rdf:ID and rdf:about has a specific meaning that does not align with their definition
in RDF. The meanings are:
• an rdf:ID specifies the life of object globally, i.e. its creation or deletion.
• an rdf:about is a reference to an existing object.
5.3 CIMXML element identification
Object identification is so central in RDF that all elements representing objects are identified
with a rdf:ID or rdf:about XML attribute. All classes in CIM that inherit IdentifiedObject have the
UML object identification attribute IdentifiedObject.mRID. The attribute is implicitly mapped to
the rdf:ID/rdf:about XML attribute.
A CIMXML document may only use the URN form (see 5.1) as further described below.

61970-552 © IEC:2013 – 15 –
CIMXML files contain XML elements describing CIM objects (ACLineSegments, Substations
etc.). The CIM has lots of association roles that show up as references in the XML elements
(typically as rdf:resource or rdf:about attributes). CIM data is exchanged in different CIMXML
documents that depend on each other as described in Clause 4. Some references then cross
CIMXML document boundaries. A consequence of this is that the identification of a CIM object
must be stable during its life time. Otherwise referencing objects across document boundaries
will break.
A common practice in object oriented systems is to assume all objects have an identifier that is
unique in space and time which means:
• Different objects are assigned different identifiers.
• Identifiers once assigned are never reused even if the original object having it is gone.
The URN form as described in 5.1 is used as CIMXML element identification with the following
differences
• the prefix “urn:uuid:” is replaced by an underscore “_”. The underscore avoids a numeric
starting character for the non-base part of the identifier.  Starting the non-base part of the
identifier with a numeric character is invalid RDF. The underscore is added in all cases to
simplify parsers, even if the UUID starts with a non-numeric character.
• the prefix is defined as an xml:base=“urn:uuid:”
Some examples:
• rdf:ID=”_26cc8d71-3b7e-4cf8-8c93-8d9d557a4846”.
• rdf:about=”#_26cc8d71-3b7e-4cf8-8c93-8d9d557a4846”.
6 CIMXML format rules and conventions
6.1 General
Given the CIM RDF Schema described in IEC 61970-501, a power system model can be
converted for export as an XML document (see Figure 3). This document is referred to as a
CIMXML document. All of the tags (resource descriptions) used in the CIMXML document are
supplied by the CIM RDF schema. The resulting CIMXML model exchange document can be
parsed and the information imported into a foreign system.
Proprietary
CIM
Power System
in UML
Data
CIM RDF Importer/
Schema Exporter
specify
Power
reference
RDF
System Data
Syntax
as
CIM XML
IEC  2770/13
Figure 4 – CIMXML-based power system model exchange mechanism

– 16 – 61970-552 © IEC:2013
6.2 Simplified RDF syntax
6.2.1 General
RDF syntax provides many ways to represent the same set of data. For example, an
association between two resources can be written with a resource attribute or by nesting one
element within another. This could make it difficult to use some XML tools, such as XSL
processors, with the CIMXML document.
Therefore, only a subset of the RDF Syntax is to be applied in creating CIMXML documents.
This syntax simplifies the work of implementers to construct model serialization and de-
serialization software, as well as to improve the effectiveness of general XML tools when used
with CIMXML documents. The reduced syntax is a proper subset of the standard RDF syntax;
thus, it can be read by available RDF de-serialization software.
The following subsections define a subset of the RDF Syntax. This simplified syntax is for
exchanging power system models between utilities. The aim of the specification is to make it
easier for implementers to construct de-serialization software for RDF data, to simplify their
choices when serializing RDF data, and to improve the effectiveness of general XML tools such
as XSLT processors when used with the serialized RDF data.
The reduced syntax is a proper subset of the standard RDF syntax. Thus, it can be read by
RDF de-serialization software such as SirPAC [8] . In this, it differs from other proposals for a
simplified syntax, such as [9], [10].
The reduced syntax does not sacrifice any of the power of the RDF data model. That is, any
RDF data can be exchanged using this syntax. Moreover, features of RDF such as the ability to
extend a model defined in one document with statements in second document are preserved.
6.2.2 Notation
The simplified syntax is defined in the following section. Each kind of element is defined in a
subsection beginning with a model of the element, followed by some defining text, and a
reference to the RDF grammar. The semantics of the element are not detailed (refer to the
RDF recommendation [3] for that information). The notation for the element model is as
follows:
a) A symbol in italics in the position of an element type, attribute name or attribute value
indicates the type of name or value required. The symbol will be defined in the text.
b) The symbol rdf stands for whatever namespace prefix is chosen by the implementation for
the RDF namespace. Similarly the symbol cim stands for the chosen CIM namespace
prefix.
c) A comment within the element model indicates the allowed content. A symbol in italics
stands for a kind of element or other content defined in the text. A construction (a | b)
indicates that a and b are alternatives. A construction a* indicates zero or more repetitions
of a.
d) All other text in the model is literal.
6.2.3 Syntax definition
6.2.3.1 General
The syntax definition is enriched with examples. The examples should help to get a better
understanding of the formal syntax definition. The same example is used for several syntax
definitions. The syntax focused in the example is indicated in bold.
______________
Numbers in square brackets refer to the bibliography.

61970-552 © IEC:2013 – 17 –
6.2.3.2 Name space URIs defined in this specification
The following name spaces are defined in this specification:
• cim-model-description_uri described by xmlns:md
• difference-model-namespace-uri described by xmlns:dm
Their values are defined as:
• xmlns:md=”http://iec.ch/TC57/61970-552/ModelDescription/1#”
• xmlns:dm=”http://iec.ch/TC57/61970-552/DifferenceModel/1#”
6.2.3.3 Document element
xmlns:cim=”cim-namespace-uri”
xmlns:md=”cim-model-description_uri”>


xmlns:cim=”cim-namespace-uri”
xmlns:md=”cim-model-description_uri”
xml:base="urn:uuid:">


Example:

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:cim="http://iec.ch/TC57/2004/CIM-schema-cim10#"
xmlns:md="http://iec.ch/TC57/61970-552/ModelDescription/1#"
xml:base="urn:uuid:">

a) The element type is rdf:RDF.
b) The RDF namespace must be declared as http://www.w3.org/1999/02/22-rdf-syntax-ns#
c) The CIM namespace must be declared. With newer versions of the CIM schema the version
needs to be adjusted in the CIM name space. Parties exchanging documents have to agree
on the used version.
d) Other namespaces may be declared.
e) The xml:base attribute shall always be present, refer to 5.3.
The RDF [3] grammar clause: 6.1.
6.2.3.4 FullModel element

|compound-property)* –->

Example:

2008-12-24

– 18 – 61970-552 © IEC:2013
7bc97430bf88"/>
V32
http://polarenergy.com/2008/NorthPoleTSO Model.modelingAuthoritySet>
Santa Claus made a study case peak load summer base
topology solution
http://iec.ch/TC57/61970-
456/StateVariables/1

1) The full model element introduces a new model.
2) The value of the about attribute, model-uri, is a name chosen by the implementation.
The model-uri uniquely identifies a document and is the name referenced by other
documents, e.g. by Supersedes or DependentOn, as indicated in Figure 2.
6.2.3.5 Definition element

(literal-property|resource-property|compound-property)*
-->


(literal-property|re
...