EN 61970-402:2008

SLOVENSKI STANDARD
01-november-2008
Aplikacijski programski vmesnik za sistem upravljanja z energijo (EMS-API) - 402.
del: Skupne storitve (IEC 61970-402:2008)
Energy management system application program interface (EMS-API) -- Part 402:
Common services
Schnittstelle für Anwendungsprogramme für Netzführungssysteme (EMS-API) - Teil 402:
Allgemeine Dienste
Interface de programmation d'application pour systèmes de gestion d'énergie (EMS-API)
- Partie 402: Services communs
Ta slovenski standard je istoveten z: EN 61970-402:2008
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-402
NORME EUROPÉENNE
August 2008
EUROPÄISCHE NORM
ICS 33.200
English version
Energy management system application program interface (EMS-API) -
Part 402: Common services
(IEC 61970-402:2008)
Interface de programmation d'application Schnittstelle für Anwendungsprogramme
pour systèmes de gestion d'énergie für Netzführungssysteme (EMS-API) -
(EMS-API) - Teil 402: Allgemeine Dienste
Partie 402: Services communs (IEC 61970-402:2008)
(CEI 61970-402:2008)
This European Standard was approved by CENELEC on 2008-07-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, Bulgaria, Cyprus, the
Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia,
Lithuania, Luxembourg, Malta, the Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain,
Sweden, Switzerland and the 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

© 2008 CENELEC - All rights of exploitation in any form and by any means reserved worldwide for CENELEC members.
Ref. No. EN 61970-402:2008 E
Foreword
The text of document 57/928/FDIS, future edition 1 of IEC 61970-402, 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-402 on 2008-07-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) 2009-04-01
– latest date by which the national standards conflicting
with the EN have to be withdrawn (dow) 2011-07-01
Annex ZA has been added by CENELEC.
__________
Endorsement notice
The text of the International Standard IEC 61970-402:2008 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 61850-7-2 NOTE  Harmonized as EN 61850-7-2:2003 (not modified).
IEC 61968 NOTE  Harmonized in EN 61968 series (not modified).
IEC 61968-1 NOTE  Harmonized as EN 61968-1:2004 (not modified).
IEC 61968-3 NOTE  Harmonized as EN 61968-3:2004 (not modified).
IEC 61970-301 NOTE  Harmonized as EN 61970-301:2004 (not modified).
__________
– 3 – EN 61970-402:2008
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

1) 2)
IEC 61970-1 - Energy management system application EN 61970-1 2006
program interface (EMS-API) -
Part 1: Guidelines and general requirements

1) 2)
IEC/TS 61970-2 - Energy management system application CLC/TS 61970-2 2005
program interface (EMS-API) -
Part 2: Glossary
1)
IEC/TS 61970-401 - Energy management system application - -
program interface (EMS-API) -
Part 401: Component interface specification
(CIS) framework
1) 2)
IEC 61970-403 - Energy management system application EN 61970-403 2008
program interface (EMS-API) -
Part 403: Generic data access
1) 2)
IEC 61970-404 - Energy management system application EN 61970-404 2007
program interface (EMS-API) -
Part 404: High Speed Data Access (HSDA)

1) 2)
IEC 61970-405 - Energy management system application EN 61970-405 2007
program interface (EMS-API) -
Part 405: Generic Eventing and Subscription
(GES)
1) 2)
IEC 61970-407 - Energy management system application EN 61970-407 2007
program interface (EMS-API) -
Part 407: Time Series Data Access (TSDA)

OMG DAF 2002 Utility Management System (UMS) Data - -
Access Facility (DAF)
1)
Undated reference.
2)
Valid edition at date of issue.

IEC 61970-402
Edition 1.0 2008-06
INTERNATIONAL
STANDARD
Energy management system application program interface (EMS-API) –
Part 402: Common services
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
PRICE CODE
W
ICS 33.200 ISBN 2-8318-9850-1
– 2 – 61970-402 © IEC:2008(E)
CONTENTS
FOREWORD.4
INTRODUCTION.6
1 Scope.7
2 Normative references.8
3 Terms and definitions .8
4 Background .8
5 Common services identifiers (normative).9
5.1 DAF resource identifiers interface .9
5.2 Extended resource ID service .10
5.2.1 General .10
5.2.2 get_uris().11
5.2.3 set_uris() .11
5.2.4 create_resource_ids() .12
6 Common services descriptions (normative) .12
7 IECTC 57Views (normative) .14
7.1 General .14
7.2 IECTC 57View motivations (informative) .14
7.2.1 General .14
7.2.2 Problem example (informative).15
7.2.3 IECTC 57View description (normative) .16
7.2.4 IECTC 57View examples (informative) .16
7.2.5 Node properties (normative).18
7.3 The IECTC 57Physical view (normative).18
7.3.1 General .18
7.3.2 IECTC 57Physical view hierarchy .19
7.4 The IECTC 57Eventing View (normative) .21
7.4.1 General .21
7.4.2 IECTC 57EventingView properties.21
8 Context support (normative).22
Annex A (informative) TC 57 Views discussion .23
Annex B (informative) Proxy architecture.28
Annex C (informative) The IEC 61970 services and mapping IEC 61968 verbs.29
Bibliography .36

Figure 1 – DAF resource identifiers model .9
Figure 2 – GDA extended resource identifiers model .11
Figure 3 – Resource descriptions .12
Figure 4 – Resource descriptions:SimpleValue .13
Figure 5 – Fictitious information model .15
Figure 6 – Fictitious populated model displayed in tree .15
Figure 7 – IECTC 57Views .16
Figure 8 – Example TC 57 PhysicalView (informative) .17
Figure 9 – Example IECTC 57EventingView (informative) .17

61970-402 © IEC:2008(E) – 3 –
Figure A.1 – Non-CIM-compliant example of a full mesh network of object classes and
instances .23
Figure A.2 – Non-CIM-compliant example of traditional view of utility data .24
Figure A.3 – Non-CIM-compliant example of customer data within a network view .24
Figure A.4 – Non-CIM-compliant example of a full mesh view .25
Figure A.5 – Subscribing to data using share path information .26
Figure A.6 – TC 57 View used as a subscription topic tree.27

Table 1 – DAF resource identifiers operations .10
Table 2 – GDA extended resource identifiers operations.11
Table 3 – DAF resource description iterator.13
Table 4 – Format of view version.18
Table 5 – First level associations used in the TC 57PhysicalView .19
Table 6 – Second level associations used in the TC 57PhysicalView.19
Table 7 – Third level associations used in the TC 57PhysicalView .20
Table 8 – Fourth level associations used in the TC 57PhysicalView .20
Table 9 – Fifth level associations used in the TC 57PhysicalView .20
Table 10 – Format of TC 57PhysicalView properties .21
Table 11 – Format of TC 57EventingView properties.22
Table C.1 – Mapping IEC 61968 verbs to IEC 61970 services .31

– 4 – 61970-402 © IEC:2008(E)
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
ENERGY MANAGEMENT SYSTEM APPLICATION
PROGRAM INTERFACE (EMS-API) –
Part 402: Common services
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.
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-402 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/928/FDIS 57/947/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.
A list of all parts of the IEC 61970 series, under the general title Energy management system
application program interface (EMS-API), can be found on the IEC website.

61970-402 © IEC:2008(E) – 5 –
This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.
The committee has decided that the contents of this publication will remain unchanged until 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.
A bilingual version of this publication may be issued at a later date.

– 6 – 61970-402 © IEC:2008(E)
INTRODUCTION
This standard is one of the IEC 61970 series parts that define an application program interface
(API) for utility operational systems. This standard is based upon the work of the Electric Power
Research Institute (EPRI) Control Center API (CCAPI) research project (RP-3654-1).
The IEC 61970-4xx series specifies a set of interfaces that a component (or application) should
implement to be able to exchange information with other components and/or access publicly
available data in a standard way. The IEC 61970-4xx series component interfaces describe the
specific event types and message contents that can be used by applications independent of
any particular component technology. The implementation of these messages using a
particular component technology is described in the IEC 61970-5xx series of documents. Thus,
IEC 61970-4xx documents describe a Platform Independent Model (PIM), while IEC 61970-5xx
documents describe a Platform Specific Model (PSM).
IEC 61970-402 contains API services that are considered to be foundational. As such, all the
other parts in the IEC 61970-4xx series assume their existence. As a result, the services
described in IEC 61970-402 are required for any component that complies with the
IEC 61970-4xx series.
The component interface specifications refer to entity objects for the power system domain that
are defined in the IEC 61970-3xx series: Common Information Model (CIM).
This standard contains normative and informative text. Clauses are marked as normative or
informative. A subclause inherits its parent clause’s label unless overridden by the lower level
subclause label.
61970-402 © IEC:2008(E) – 7 –
ENERGY MANAGEMENT SYSTEM APPLICATION
PROGRAM INTERFACE (EMS-API) –
Part 402: Common services
1 Scope
This International Standard provides the base functionality considered necessary and common
that is provided by neither the normative standards incorporated by reference nor the new APIs
)
specified in the IEC 61970-403 to IEC 61970-449 generic interface standards. An application
is expected to use the Common Services in conjunction with the generic interfaces. These
application category independent interfaces include:
• IEC 61970-403: Generic Data Access (GDA)
• IEC 61970-404: High Speed Data Access (HSDA)
• IEC 61970-405: Generic Eventing and Subscription (GES)
• IEC 61970-407: Time Series Data Access (TSDA)
To support these objectives, the Common Services are divided into three categories:
a) Resource Identifiers – A common way of identifying classes, class attributes, and object
instances.
b) Resource Description – A common way of encoding values associated with classes, class
attributes, and object instances.
c) Views – A common way of presenting classes, class attributes, and object instances via
hierarchies.
IEC 61970-402 contains API services that are considered to be foundational. As such, all the
other parts in the IEC 61970-4xx series assume their existence. As a result, the services
described in IEC 61970-402 are required for any component that complies with the
IEC 61970-4xx series of standards.
Though the target of this IEC standard includes the control center technical domain, common
services encompass a general set of concepts that can be applied to many types of systems.
Examples of these systems include:
• Distribution management systems
• Work or asset management systems
• Geographic information systems
• Outage management systems
• Other types of operational business systems.
In recognition that the integration between applications in two or more of these systems is often
necessary, the intent of this specification is to address general common service requirements
to the extent that they are common to different types of systems while effectively addressing
the control center needs.
___________
)
At this time, only parts 402 to 408 exist. Additional generic services beyond are not yet under consideration.

– 8 – 61970-402 © IEC:2008(E)
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 61970-1, Energy management system application program interface (EMS-API) – Part 1:
Guidelines and general requirements
IEC 61970-2, Energy management system application program interface (EMS-API) – Part 2:
Glossary
IEC 61970-401, Energy management system application program interface (EMS-API) – Part
401: Component interface specification (CIS) framework
IEC 61970-403, Energy management system application program interface (EMS-API) – Part
403: Component Interface Specification (CIS) – Generic data access
IEC 61970-404, Energy management system application program interface (EMS-API) – Part
404: High Speed Data Access (HSDA)
IEC 61970-405, Energy management system application program interface (EMS-API) – Part
405: Generic Eventing and Subscription (GES)
IEC 61970-407, Energy management system application program interface (EMS-API) – Part
407: Time Series Data Access (TSDA)
OMG, Utility Management System Data Access Facility, document formal/2002-11-08
3 Terms and definitions
For the purposes of this document, the terms and definitions given in IEC 61970-2 apply.
NOTE Refer to International Electrotechnical Vocabulary, IEC 60050, for general glossary definitions.
4 Background
This International Standard specifies Component Interface Specifications (CIS) for Energy
Management Systems Application Program Interfaces (EMS-API). It specifies the interfaces
that a component (or application) shall implement to be able to exchange information with other
components (or applications) and/or to access publicly available data in a standard way (see
IEC 61970-1 for an overview of these standards). The goal of the creation of this document is
to improve the interoperability of control center applications and systems. This specification
provides a mechanism for applications from independent suppliers to access IEC 61970
Common Information Model (CIM) data using a common Application Program Interface (API)
for the purpose of supplementary processing, storage, or display.
IEC 61970-401, CIS Framework, provides an overview of the CIS documents in the
IEC 61970-4xx series. It explains the separation of these specifications into two major groups.
One group of standards, IEC 61970-402 to IEC 61970-449, defines a set of generic application
independent services that a component shall use for exchanging information with another
component or for accessing public data. However, as the generic interfaces do not specify
what specific data is exchanged, interoperability between products using IEC 61970-402 to
IEC 61970-449 is not guaranteed. The other group, IEC 61970-450 to IEC 61970-499, defines
the information content conveyed using the generic services that a particular component or
system exchanges with other components. While IEC 61970-402 to IEC 61970-449 specify

61970-402 © IEC:2008(E) – 9 –
application category independent message exchange mechanisms, IEC 61970-450 to
IEC 61970-499 specify application category dependent CIM derived message contents.
The IEC 61970-4xx series of documents describes the specific event types and message
contents that shall be used by applications independent of any particular component
technology. The implementation of these messages using a particular component technology is
described in the IEC 61970-5xx series of documents. As part of the IEC 61970-4xx series, this
document contains a Level 1 Platform Independent Model (PIM) that describes in narrative
terms (with text and the Unified Modeling Language (UML)) the interface functionality to be
standardized. The IEC 61970-5xx series of documents describes a Level 2 or Platform Specific
Model (PSM) that apply IEC 61970-4xx series specifications to particular platforms.
As explained in IEC 61970-401, a major aspect of the IEC 61970-4xx series is that they take
maximum advantage of existing industry standards. Of particular importance are standards
developed by the OPC (originally OLE for Process Control) and OMG (Object Management
Group). However, these standards are missing certain functionalities considered important for
the environment in which the IEC 61970 standards will be applied.
IEC 61970-402 contains API services that are considered to be foundational. As such, all the
other parts in the IEC 61970-4xx series assume their existence. As a result, the services
described in IEC 61970-402 are required for any component that complies with the
IEC 61970-4xx series.
5 Common services identifiers (normative)
5.1 DAF resource identifiers interface
This document normatively includes by reference the modelling contained in the Utility
)
Management System (UMS) Data Access Facility (DAF) resource identifiers module . This
module defines a generic means that shall be used to identify CIM resources (power system
related classes, class attributes, and object instances). The DAF resource identifiers module
defines several classes and one service as illustrated in Figure 1.
ResourceID
ResourceIDSequence
container : ULongLong
fragment : ULongLong
0.*0.* 0.*0.*
ResourceIDService
get_resource_ids()
get_uris()
URI URISequence
0.*0.*
0.*0.*
IEC  872/08
Figure 1 – DAF resource identifiers model

___________
)
See OMG, Utility Management System Data Access Facility, document formal/2002-11-08.

– 10 – 61970-402 © IEC:2008(E)
Table 1 – DAF resource identifiers operations
Operation Example signature Throws
get_resource_ids ResourceIDSequence get_resource_ids LookupError
(URISequence uris)
get_uris URISequence get_uris LookupError
(ResourceIDSequence ids)
)
The DAF resource identifiers module employs Universal Resource Identifiers (URI’s) and
Resource ID’s to identify utility resources. A URI is a string used as a name that conforms to
the Universal Resource Identifier standard (see reference 5). For example, a URI for the class
of transformers might be “http://utility.com/Planning/Production/CIM-schema-cimu09a#
Transformer”. A resource ID on the other hand consists of a more compact 128 bit (16 octets)
ID number. The DAF specification defines arrays of Resource ID’s and URI’s in
ResourceIDSequence and URISequence respectively.
The DAF resource identifiers module requires that Universal Resource Identifiers (URI’s) be
unique and that within a DAF Server Resource ID’s be unique. Furthermore, for any resource
exposed by a DAF server there is only one associated resource ID and one associated URI.
The DAF ResourceID Service includes two methods called get_resource_ids and get_uris to
translate URI’s to Resources and visa versa. The get_resource_ids method takes a set of
URI’s as input and returns an equal and corresponding set of Resource ID’s as output. The
get_uris method takes a set of Resource ID’s as input and returns an equal and corresponding
set of URI’s as output.
5.2 Extended resource ID service
5.2.1 General
However, in practice it is possible that a single unique resource ID may be associated with
)
many URI’s . For example, consider a resource ID service provider deployed for planning and
operations applications. In this case, a resource such as a substation bus may be associated
with two URI’s (names) where each URI is associated with a different legacy application for
example “utility.com/Planning/Production#Bus123” and “utility.com/EMS/Production#BusAB7”.
In order to deal with this more complicated use case, the Extended Resource ID Service adds
a view name parameter to the DAF Resource ID get_uris method. The view name parameter is
used to determine the scope of the URI.
The extended resource ID service also adds the ability to set URI’s given a view name and to
allocate resource ID’s in a server as shown in Figure 2. Thus, the common services identifiers
interface as described in Table 2, can be seen as a complementary extension of the DAF
identifiers interface.
___________
)
IETF RFC 2396 for more information on URI’s.
)
For example, consider a IEC 61970-404: High Speed Data Access (HSDA) Server presenting nodes within an
IECTC 57PhysicalView hierarchy. Because the HSDA interface does not support a client query to retrieve the
Resource ID’s of all breakers in a substation for example, a performance bottleneck can occur during HSDA
subscription configuration when a client assembles a list of pathnames to subscribe to. However, the Resource
ID’s for all breakers in a substation can be retrieved using a IEC 61970-403: Generic Data Access query. The
Extended Resource Identification Service provider can then be used to translate the retrieved Resource ID’s to
HSDA server pathnames since the combination of a HSDA Server name and a IECTC 57PhysicalView pathname
provides a unique URI. Therefore, the Extended Resource Identifiers Service supplies required functionality to
eliminate the subscription configuration bottleneck by allowing a client to pass in a view name to the Resource
Identification Service provider when querying for HSDA pathnames.

61970-402 © IEC:2008(E) – 11 –
ResourceID
container: ULongLong
ResourceIDSequence
fragment: ULongLong
0.n0.n
ExtendedResourceIDService
get_uris()
set_uris()
create_resource_ids()
URI URISequence
IEC  873/08
0.n0.n
Figure 2 – GDA extended resource identifiers model

Table 2 – GDA extended resource identifiers operations
Example signature Throws
Operation
get_uris URISequence get_uris LookupError
(char view_name, ResourceIDSequence ids)
set_uris void set_uris UpdateError
(char view_name, ResourceIDSequence ids,
URISequence uris)
create_resource_ids ResourceIDSequence create_resource_ids UnknownResource
(ResourceID prototype, int how_many)

5.2.2 get_uris()
This operation accepts a sequence of resource identifiers as well as a view name and returns
the corresponding URI-references. The returned sequence is the same length as the input
sequence and in the same order. If the server does not recognize a particular resource
identifier or is not responsible for its translation, the operation will raise a LookupError
exception.
5.2.3 set_uris()
)
This operation accepts a sequence of resourceID’s and URI’s as well as a view name . Each
URI is associated with each ResourceID within the scope of the view name. The ResourceID
and URI sequences must be the same length. If the server does not recognize a particular
resource identifier or is not responsible for its translation, an UpdateError is thrown.
___________
)
It is recommended but not mandatory that ExtendedResourceID clients that also act as IEC 61970-404:High
Speed Data Access (HSDA), IEC 61970-407:Time Series Data Access (TSDA), or IEC 61970-505:Generic
Eventing and Subscription (GES) servers use IECTC 57View derived pathnames as URI’s and that these
pathnames are derived from the one of the standard views such as IECTC 57PhysicalView. When the
IECTC 57PhysicalView is used to create the pathname, the URI’s used shall correspond to the
IECTC 57PhysicalView pathname preceded by the name of the server. For more information on the format of
path names, see IEC 61970-404: High Speed Data Access.

– 12 – 61970-402 © IEC:2008(E)
5.2.4 create_resource_ids()
This operation accepts a resource ID for a prototypical resource as well as an integer indicating
how many new resource ID’s to create and returns one or more ResourceID values.
The return value is a sequence of valid ResourceID values. None of the resource identifiers
designates an extant resource at the time it is returned. None of identifiers returned is equal to
any previously returned identifier. The prototype is the resource identifier of an existing
resource. The new resource identifiers will be managed by the same data provider as the
)
prototype . A null resource identifier may be provided, in which case the implementation will
select a data provider. The integer how_many indicates the number of resource identifier
values to be produced. The operation will return a sequence of at most this many resource
identifier values. (If less than how_many are returned, then the client may make another
request.)
6 Common services descriptions (normative)
This document normatively includes by reference the modelling contained in the Utility
Management System (UMS) Data Access Facility (DAF) Resource Descriptions Module. This
module defines a generic means to exchange information about CIM resources (power system
related classes, class attributes, and object instances). The DAF Resource Descriptions Model
defines several classes and one service as illustrated in Figure 3 and Figure 4 below:
ResourceID
(from CSIdentifiers)
container : ULongLong
fragment : ULongLong
ResourceDescription
0.0.nn PropertyID
ResourceDescriptionSequence
PropertyValueSequence
0.0.nn
ResourceDescriptionIterator
PropertyValue
property : PropertyID
next_n()
value : SimpleValue
max_left()
destroy()
IEC  874/08
Figure 3 – Resource descriptions
___________
6)
Note that the prototype parameter is only useful when an aggregating resource ID service provider is acting as a
Proxy Server. For more information about Proxy Servers, see Annex B.

61970-402 © IEC:2008(E) – 13 –
ULongLong
Blob
(from CSIdentifiers)
blob_data : Variant
ULongLongSequence
high : unsigned long
blob_data_type : String
0.0.**
low : unsigned long
0.0.11
0.0.11
SimpleValue
DateTime DateTimeSequence
intValue : long
0.0.11
unsignedValue : unsigned long
0.0.**
stringValue : string
booleanValue : boolean
doubleValue : double
Complex
0.0.11
intValues : longSequence
ComplexSequence
real : double
shortValue : short
imaginary : double
0.0.**
unsignedValues : unsignedLongSequence
stringValues : stringSequence
booleanValues : booleanSequence
0.0.11
doubleValues : unsignedLongSequence
shortValues : shortSequence ResourceID
ResourceIDSequence
(from CSIdentifiers)
(from CSIdentifiers)
container : ULongLong
0.0.**
fragment : ULongLong
0.0.11
SimpleValueType
0.0.11
URI
URISequence
(from CSIdentifiers)
(from CSIdentifiers)
0.0.**
IEC  875/08
Figure 4 – Resource descriptions:SimpleValue
Table 3 – DAF resource description iterator
Operation Example signature Throws
Next_n boolean next_n IteratorError
(unsigned long n, ResourceDescriptionSequence descriptions)
max_left unsigned long max_left IteratorError
destroy void destroy IteratorError

In Table 3, time is expressed by a 64 bit unsigned number (a ULongLong) which counts the
number of 100 nanosecond units passed since 15 October 1582 00:00 UTC (the date of
Gregorian reform to the Christian calendar). This convention is adopted from the CORBA Time
Service, which in turn takes it from the X/Open DCE Time Service.
Complex numbers are used in a range of scientific applications and especially in power system
analysis. In the DAF, complex numbers are expressed in Cartesian form.
SimpleValues are the object of properties; their role in the resource description framework was
outlined in the previous clause. The DAF defines a SimpleValue as a discriminated union,
where SimpleValueType is the discriminant. Fundamentally, a SimpleValue can be a resource
identifier or a literal. The basic type of literal is a string to which the DAF adds explicit
representation of the types defined above and (the largest variant of) each CORBA intrinsic
type.
A property value specifies a property by its resource identifier and its associated value for a
given resource. The types ResourceID and SimpleValue are defined in the DAFBasic module.

– 14 – 61970-402 © IEC:2008(E)
Each resource description identifies a single resource, by its resource identifier, and zero or
more property values for that resource. The properties must be single valued; no provision is
made for returning more than one value per property within a resource description. The class
of the resource can be included in the resource description as the value of the type property
(refer to the schema section for details).
Queries that return information about more than one resource return an iterator. The resource
description iterator allows a client to access a large query result sequentially, several resources
at a time. This is necessary to control the amount of information that gets passed to it at one
time. It also enables implementations to overlap the client and server processing of query
results, if necessary.
The client and the data provider should cooperate to manage the lifetime of the iterator and the
resources it consumes. The destroy() and next_n() methods allow the client and data provider
respectively to indicate that the iterator may be destroyed.
In addition, the data provider may autonomously destroy the iterator at any time (for resource
management or other reasons). If a client detects that an iterator has been destroyed, it will not
interpret this condition in itself as either an indication that the end of the iteration has been
reached, or as a permanent failure of the data provider.
7 IECTC 57Views (normative)
7.1 General
This clause describes a standard way to present CIM resources in a non-opaque or well-known
)
view .
7.2 IECTC 57View motivations (informative)
7.2.1 General
The standard interface description languages used by component execution systems such as
Microsoft’s Common Object Model (COM), OMG’s Common Object Request Broker
Architecture (CORBA), or Web Services provide mechanisms by which components can
announce interface information about the public properties and methods they supply and
consume. Using these technologies, a component publishes its interface metadata.
Components that wish to attach to the system at large can discover interface metadata to
determine how they might interact with system components. Interface announcement and
discovery at this level provides a key piece in the construction of an interoperable
infrastructure.
However, the use of component interface metadata alone fails to address one important
element required to more closely attain interoperability. The missing element unsupported by
the off the shelf use of the above component execution system technologies is instance object
metadata. While it is useful to know component interface type information, it is also useful to
know what specific instances of objects are being supplied by which components as well as
schema associated with these objects. Announcement and discovery of individual instance
object metadata facilitates a greater degree of “interoperability especially when combined with
a common information model. When presented a well-known view of available object instances,
components can programmatically discover what data is available, and automated attachment
to the system at large is facilitated.
Given the potential limitations of interface description languages with regards to instance
object metadata, an additional design construct must be introduced. IEC 61970-403: Generic
___________
)
By contrast, GES, HSDA and TSDA servers have an opaque view; that is, a GES, HSDA or TSDA server
presents data with few fixed requirements as to the “names” or organization of the nodes and node properties.
For the most part the “names” and organization are determined by the server. This is called an opaque view. A
non-opaque or well known view on the other hand specifies rules for how nodes in a view appear.

61970-402 © IEC:2008(E) – 15 –
Data Access allows a client to browse instance data, however some severs may only expose
an HSDA, TSDA, or GES interface. In this case, the IECTC 57Views provide the capability to
browse instance data in a standard way.
7.2.2 Problem example (informative)
The CIM consists of a full mesh network of information with multiple N to N relationships
between objects. As a result, it is difficult to present a populated CIM model to the user in a
simple Graphical User Interface (GUI). On the other hand, hierarchical views are readily
understandable. For example, consider the fictitious information model illustrated in Figure 5:
Utility
Owns Operates
Substation
IEC  876/08
Figure 5 – Fictitious information model
Using this information model, a populated model can be displayed in a tree as illustrated in
Figure 6:
Main
Racine Woburn
IEC  877/08
Figure 6 – Fictitious populated model displayed in tree
The view above consists of three nodes. The top node called “Main” is a branch node because
it acts as the “parent” to the two “child” nodes below it. The bottom nodes are leaf nodes
because there are no nodes below them. Assume we want to subscribe to data related to a
substation owned by a utility via a hierarchical view of the CIM. However, from browsing the
tree above several questions remain unanswered:
• Is the Main a utility or a substation?
• Assuming Main is a utility, is Racine owned or operated by Main?
Knowing the information model is not enough. In order to effectively display a populated model
in a tree we also need to know:
• Type information for
...