EN 61970-552:2016

SLOVENSKI STANDARD
01-februar-2017
1DGRPHãþD
SIST EN 61970-552:2014
Aplikacijski programski vmesnik za sistem upravljanja z energijo (EMS-API) - 552.
del: Format CIMXML za izmenjavo skupnega informacijskega modela
Energy Management System Application Program Interface (EMS-API) - Part 552:
CIMXML Model Exchange Format
Schnittstelle für Anwendungsprogramme für Netzführungssysteme (EMS-API) - Teil 552:
CIM-XML-Modell Austauschformat
Interface de programmation d'application pour systèmes de gestion d'énergie (EMS-API)
- Partie 552 : format d'échange de modèle CIMXML
Ta slovenski standard je istoveten z: EN 61970-552:2016
ICS:
29.240.30 Krmilna oprema za Control equipment for electric
elektroenergetske sisteme power systems
33.200 Daljinsko krmiljenje, daljinske Telecontrol. Telemetering
meritve (telemetrija)
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD EN 61970-552

NORME EUROPÉENNE
EUROPÄISCHE NORM
December 2016
ICS 33.200 Supersedes EN 61970-552:2014
English Version
Energy management system application program interface
(EMS-API) - Part 552: CIMXML Model exchange format
(IEC 61970-552:2016)
Interface de programmation d'application pour système de Schnittstelle für Anwendungsprogramme für
gestion d'énergie (EMS-API) - Netzführungssysteme (EMS-API) -
Partie 552: Format d'échange de modèle CIMXML Teil 552: CIM-XML-Modell Austauschformat
(IEC 61970-552:2016) (IEC 61970-552:2016)
This European Standard was approved by CENELEC on 2016-11-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 CEN-CENELEC
Management Centre 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 CEN-CENELEC Management Centre has the
same status as the official versions.
CENELEC members are the national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia, Cyprus, the Czech Republic,
Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia,
Lithuania, Luxembourg, Malta, the Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Turkey and the United Kingdom.

European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung
CEN-CENELEC Management Centre: Avenue Marnix 17, B-1000 Brussels
© 2016 CENELEC All rights of exploitation in any form and by any means reserved worldwide for CENELEC Members.
Ref. No. EN 61970-552:2016 E
European foreword
The text of document 57/1752/FDIS, future edition 2 of IEC 61970-552, prepared by
IEC/TC 57 "Power systems management and associated information exchange" was submitted to the
IEC-CENELEC parallel vote and approved by CENELEC as EN 61970-552:2016.

The following dates are fixed:
(dop) 2017-08-01
• latest date by which the document has to be
implemented at national level by
publication of an identical national
standard or by endorsement
• latest date by which the national (dow) 2019-11-01
standards conflicting with the
document have to be withdrawn
This document supersedes EN 61970-552:2014.

Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CENELEC [and/or CEN] shall not be held responsible for identifying any or all such
patent rights.
This document has been prepared under a mandate given to CENELEC by the European Commission
and the European Free Trade Association.

Endorsement notice
The text of the International Standard IEC 61970-552:2016 was approved by CENELEC as a
European Standard without any modification.
In the official version, for Bibliography, the following notes have to be added for the standards indicated:

IEC 61968-11 NOTE Harmonized as EN 61968-11.
IEC 61970-1 NOTE Harmonized as EN 61970-1.
Annex ZA
(normative)
Normative references to international publications
with their corresponding European publications

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.

NOTE 1 When an International Publication has been modified by common modifications, indicated by (mod), the relevant
EN/HD applies.
NOTE 2 Up-to-date information on the latest versions of the European Standards listed in this annex is available here:
www.cenelec.eu
Publication Year Title EN/HD Year

IEC 60050 Series International Electrotechnical Vocabulary - -
IEC/TS 61970-2 -  Energy management system application CLC/TS 61970-2 -
program interface (EMS-API) -
Part 2: Glossary
IEC 61970-501 2006 Energy management system application EN 61970-501 2006
program interface (EMS-API) -
Part 501: Common Information Model
Resource Description Framework (CIM
RDF) schema
W3C -  RDF/XML Syntax Specification - -
W3C -  XSL Transformations (XSLT) - -
W3C -  Document Object Model (DOM) - -

IEC 61970-552 ®
Edition 2.0 2016-09
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
INTERNATIONALE
ICS 33.200 ISBN 978-2-8322-3637-6

– 2 – IEC 61970-552:2016 © IEC 2016
CONTENTS
FOREWORD . 3
INTRODUCTION . 5
1 Scope . 6
2 Normative references. 6
3 Terms and definitions . 7
4 CIMXML version . 9
5 Model exchange . 9
5.1 General . 9
5.2 Rules for CIMXML documents and headers . 9
5.3 Model and header data description . 10
5.4 Work flow . 13
6 Object identification . 14
6.1 URIs as identifiers . 14
6.2 About rdf:ID and rdf:about . 15
6.3 CIMXML element identification . 16
6.4 Older ID formats . 17
6.5 Object type . 17
6.5.1 General . 17
6.5.2 References to a more generic type than the actual . 17
7 CIMXML format rules and conventions . 19
7.1 General . 19
7.2 Simplified RDF syntax . 19
7.2.1 General . 19
7.2.2 Notation . 20
7.2.3 Syntax definition (normative) . 20
7.2.4 Syntax extension for difference model . 26
7.3 CIMXML format style guide . 31
7.4 Representing new, deleted and changed objects as CIMXML elements . 32
7.5 CIM RDF schema generation with CIM profile . 32
7.6 CIM extensions . 33
7.7 RDF simplified syntax design rationale . 33
Bibliography . 35

Figure 1 – Model with header . 10
Figure 2 – Example work flow events . 13
Figure 3 – Example work flow events with more dependencies . 14
Figure 4 – CIM PSR – Location data model . 17
Figure 5 – CIMXML-based power system model exchange mechanism . 19
Figure 6 – Relations between UML, profile and CIMXML tools . 33

Table 1 – CIMXML version . 9
Table 2 – Header attributes . 11

IEC 61970-552:2016 © IEC 2016 – 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.
This second edition cancels and replaces the first edition published in 2013. This edition
constitutes a technical revision.
This edition includes the following significant technical changes with respect to the previous
edition:
a) New Clause 4 that defines the versioning of CIMXML format described in this document.
b) Subclause 5.1, the statement on work flow support is removed.
c) Subclause 5.2, Statement about mandatory header added. Rules how to use the header
added. The discussion on management of multiple CIMXML documents and archives is
removed.
– 4 – IEC 61970-552:2016 © IEC 2016
d) Subclause 5.3, FullModelDocumentElement removed, minor version added to profile URI
and the meaning of the header is elaborated in Table 2.
e) Subclause 6.2 the description of rdf:ID and rdf:about has been updated.
f) Subclause 6.3 introduce the new urn:uuid form and discuss the backwards compatibility.
g) New Subclause 6.4 added on support of older UUID formats.
h) New Subclause 6.5 discussing object types added.
i) Subclause 7.2.3.3, Position of header described and duplicate rows removed.
j) Document identification and references between documents updated in Table 2 and
Subclauses 7.2.3.4 and 7.2.4.6.
k) Subclause 7.2.3.7, A compound element can never be a root element.
l) Subclause 7.2.3.9, description of compound containment added.
m) Subclauses 7.2.3.4 and 7.2.4.7.3, More clarification of cascading delete.
The text of this standard is based on the following documents:
FDIS Report on voting
57/1752/FDIS 57/1773/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.
The committee has decided that the contents of this publication will remain unchanged until
the stability date indicated on the IEC website 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.
IEC 61970-552:2016 © IEC 2016 – 5 –
INTRODUCTION
This part of IEC 61970 is part of the series of standards 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.
This part of IEC 61970 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 – IEC 61970-552:2016 © IEC 2016
ENERGY MANAGEMENT SYSTEM APPLICATION
PROGRAM INTERFACE (EMS-API) –
Part 552: CIMXML Model exchange format

1 Scope
This part of IEC 61970 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 part of IEC 61970 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.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their
content constitutes requirements 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 60050, International Electrotechnical Vocabulary (all parts)
IEC TS 61970-2, Energy management system application program interface (EMS-API) –
Part 2: Glossary
IEC 61970-501:2006, 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, XSL Transformations (XSLT)
W3C, Document Object Model (DOM)

IEC 61970-552:2016 © IEC 2016 – 7 –
3 Terms and definitions
For the purposes of this document, the terms and definitions contained in IEC 60050 (for
general glossary) and IEC TS 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
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 instances, objects or entities, real or computed. In the context of
CIM the semantics of the data is defined by profiles, see: 4.9. Hence a model can contain
equipment data, power flow initial values, power flow results etc.

– 8 – IEC 61970-552:2016 © IEC 2016
Note 1 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.
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 Modelling Language
UML
object-oriented modelling language and methodology for specifying, visualizing, constructing,
and documenting the artefacts 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)
IEC 61970-552:2016 © IEC 2016 – 9 –
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 style sheets for XML documents
4 CIMXML version
The CIMXML version is implemented as an XML processing instruction that appears before
the CIMXML document, refer to Table 1.
Table 1 – CIMXML version
XML processing instruction Version Revision date
iec61970-552 2.0 2014-03-12
Example:


xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:cim="http://iec.ch/TC57/2004/CIM-schema-cim10#"
…

5 Model exchange
5.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 as well as the header 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 CIMXML document shall consists of a header and a model section.
A header section describes the content of the model section 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.
5.2 Rules for CIMXML documents and headers
A CIMXML document is described by a single header. Multiple headers in a CIMXML
document are not allowed.
– 10 – IEC 61970-552:2016 © IEC 2016
The header section shall always be the first element in a CIMXML document. The header
section elements are
• FullModel element, refer to 7.2.3.4.
• DifferenceModel element, refer to 7.2.4.6.
The data in the model section is defined by one or more profiles listed within the header.
Elements in a CIMXML document may have references to elements (resources) in other
CIMXML documents.
As a single header element is allowed in a CIMXML document the model section may only
contain elements that the header can describe. If multiple headers are needed a CIMXML
document shall be created for each header.
5.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.
IEC
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 class Model. The following is a bottom up description of
these classes:
• The Statements class represent a set of Definition (refer to 7.2.3.5) and/or Description
(refer to 7.2.3.6) elements.
• The FullModel (refer to 7.2.3.4) class represent the full model header and its contents is
described by the Model class.
IEC 61970-552:2016 © IEC 2016 – 11 –
• The DifferenceModel (refer to 7.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 data and not the CIMXML document A new rdf:about
identification is generated for created documents only when the model data has changed.
A repeated creation of documents from unchanged model data should have the same
rdf:about identification as previous document generated from the same model data.
The ordering of xml elements in the generated document is insignificant except for the
FullModel element that always appear first in a document. The Model class attributes are
described in Table 2.
Table 2 – Header attributes
Class Attribute Description
Model created The date when the document was created.
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. The number of UTF-8 characters is limited
to 2000.
Model modelingAuthoritySet A urn/uri referring to the organisation or role sourcing the model in the
CIMXML document. Models from the same organisation or role but for
different profiles shall have the same urn/uri.
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 an integer that is changed in synchronisation with
the rdf:about identifier, refer to description of the Model class preceding
this table.
Model DependentOn References to other models that the model in 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.
The referenced models are identified by the FullModel rdf:about attribute
(see 7.2.3.4) for full model documents and by DifferenceModel rdf:about
attribute (see 7.2.4.6) for difference model documents.
The references are maintained by the producer of the CIMXML document
and the references are valid for the model with version and identifier (see
description of Model class preceding this table) for which the document
was created.
The use of DependentOn by a consumer is optional. If a consumer of a
document have also consumed the DependentOn documents it is
expected that no dangling references are present in the currently
consumed document.
Model Depending All documents depending on the model described by this document. This
role is not intended to be included in any document exchanging instance
data.
– 12 – IEC 61970-552:2016 © IEC 2016
Class Attribute Description
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 the
models that are superseded by the model in this document. A model can
supersede one or more models, for each superseded model one
Supersedes reference is included in the header. The referenced models
are identified by the FullModel rdf:about attribute (see 7.2.3.4) for full
model documents and by DifferenceModel rdf:about attribute (see
7.2.4.6) for difference model documents.
The references are maintained by the producer of the CIMXML document
and are valid for the model with version and identifier (see description of
Model class preceding this table) for which the document was created.
The use of Supersedes by a consumer is optional. If a consumer of a
document have also consumed the Supersedes documents it is expected
that no dangling references are present in the currently consumed
document.
Model SupersededBy All models superseding this model. This role is not intended to be
included in any document exchanging instance data.

If a document is regenerated from a received and unchanged model all attributes in Table 2
shall be the same as in the originally received document. But if a received model is in any
way modified none of the attributes may be different depending on the nature of the
modifications.
DependentOn, Depending, Supersedes and SupersededBy describe the situation in the
system where the document was generated at the time of generation. The use of the
references in a receiving system is optional and a receiving system may or may not use the
references depending on the use case, refer also to 5.4.
The profile attribute is a URI having the following format for IEC profiles:
• http://iec.ch///-///
where text in is replaced by a describing text, e.g.
• http://iec.ch/TC57/2011/61970-452/Equipment/2/1
The profile URI shall be treated as indivisible where the full string conveys the identification of
a profile. Hence software is not supposed to parse and interpret substrings of the profile URI,
e.g. year, standard, part etc.
Other organizations using the CIMXML serialization may have other profile URIs.
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 (7.2.3.3).
2) Statement elements appear as Definition (7.2.3.5) or Description elements (7.2.3.6).
3) Literal attributes, e.g. Model.created, appears as literal property elements (7.2.3.8).
4) Roles appear, e.g. Model.Supersedes, as resource property elements (7.2.3.11).
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.
7) A document may be regenerated multiple times from the same model. Documents
regenerated from an unchanged model keep the identification (Model rdf:about)
unchanged from a previous document generated from the same model.

IEC 61970-552:2016 © IEC 2016 – 13 –
8) A DifferenceModel or FullModel document generated from the same model will have the
same identification and same Supersedes. Hence a DifferenceModel and a FullModel
document can be used interchangeably. However, if a receiving system want a full model
equivalent with the model in the FullModel document the DifferenceModel document must
be applied to a full model corresponding to the superseded.
5.4 Work flow
A work flow is described by a sequence of exchange events. The model description in 5.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.
IEC
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 a DifferenceModel
document. The situation in Figure 2 represents a simple case. A more complex situation is
shown in Figure 3.
– 14 – IEC 61970-552:2016 © IEC 2016

IEC
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.
6 Object identification
6.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 stability of identifiers over time also requires the following
• An identifier shall be created for any object when its existence become know. Note that
objects in a model may or may not represent real physical equipment.
• An identifier for an object, e.g. a deleted object, is not allowed to be reused.

IEC 61970-552:2016 © IEC 2016 – 15 –
The standard for an URN containing a UUID is defined by the Internet Engineering Task Force
RFC 4122,
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,
ISO/IEC 9834-8:2005 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. Also other forms than the URI is allowed but not
recommended.
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 characters are lower case conforming to W3C (ISO 8859/1 8-bit single-byte coded
graphic character set known as Latin Alphabet No. 1.
An example of the URN form is shown below
”urn:uuid:26cc8d71-3b7e-4cf8-8c93-8d9d557a4846”.
6.2 About rdf:ID and rdf:about
A CIMXML element can be identified by two different RDF constructs:
• rdf:ID
• rdf:about
In RDF the rdf:ID identification has the specific meaning that the identifier is unique within a
document while the rdf:about identification means the identifier is unique within a name
space. If the UUID name space urn:uuid is used for the rdf:about identification the identifiers
are globally unique. Hence CIMXML promote using rdf:about identification in the UUID name
space for all identifiers.
– 16 – IEC 61970-552:2016 © IEC 2016
In the past an rdf:ID meant the introduction of a new resource or object while rdf:about meant
a reference to an elsewhere introduced resource or object. This distinction is no longer used.
As both are UUIDs they have the same meaning. For backwards compatibility both are
allowed but the rdf:about form is the preferred.
Identifiers in the FullModel and DifferenceModel elements shall always use the rdf:about
identification in the UUID name space, i.e. starting with “urn:uuid:”.
6.3 CIMXML element identification
Resource 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 6.1) as further described below.
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 U
...