EN 61970-403:2008

SLOVENSKI STANDARD
01-november-2008
Aplikacijski programski vmesnik za sistem upravljanja z energijo (EMS-API) - 403.
del: Dostop do rodovnih podatkov (IEC 61970-403:2008)
Energy management system application program interface (EMS-API) -- Part 403:
Generic data access
Schnittstelle für Anwendungsprogramme für Netzführungssysteme (EMS-API) - Teil 403:
Allgemeiner Datenzugriff
Interface de programmation d'application pour système de gestion d'énergie (EMS-API) -
Partie 403: Accès aux données génériques
Ta slovenski standard je istoveten z: EN 61970-403: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-403
NORME EUROPÉENNE
August 2008
EUROPÄISCHE NORM
ICS 33.200
English version
Energy management system application program interface (EMS-API) -
Part 403: Generic data access
(IEC 61970-403: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 403: Allgemeiner Datenzugriff
Partie 403: Accès (IEC 61970-403:2008)
aux données génériques
(CEI 61970-403: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-403:2008 E
Foreword
The text of document 57/929/FDIS, future edition 1 of IEC 61970-403, 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-403 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-403: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 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).
IEC 61970-404 NOTE  Harmonized as EN 61970-404:2007 (not modified).
IEC 61970-405 NOTE  Harmonized as EN 61970-405:2007 (not modified).
IEC 61970-407 NOTE  Harmonized as EN 61970-407:2007 (not modified).
__________
– 3 – EN 61970-403: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-402 - Energy management system application EN 61970-402 2008
program interface (EMS-API) -
Part 402: Common services
OMG DAF 2002 Utility Management System (UMS) Data - -
Access Facility (DAF)
1)
Undated reference.
2)
Valid edition at date of issue.

IEC 61970-403
Edition 1.0 2008-06
INTERNATIONAL
STANDARD
Energy management system application program interface (EMS-API) –
Part 403: Generic data access
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
PRICE CODE
W
ICS 33.200 ISBN 2-8318-9851-X
– 2 – 61970-403 © IEC:2008(E)
CONTENTS
FOREWORD.4
INTRODUCTION.6
1 Scope.7
2 Normative references.8
3 Terms and definitions .8
4 Background .8
5 GDA read access.9
5.1 General .9
5.2 Read access requirements .9
5.3 GDA resource query module .11
5.3.1 General .11
5.3.2 Resource query module description.11
5.3.3 GDA resource query service .12
5.4 GDA filtered query module.13
5.4.1 General .13
5.4.2 Filtered query module description.13
5.4.3 Filtered query service.17
5.5 GDA extended query module .19
5.5.1 General .19
5.5.2 Extended resource query module description .19
5.5.3 Extended resource query service .22
6 GDA update.23
6.1 General .23
6.2 GDA update requirements.23
6.3 GDA update module .23
6.3.1 General .23
6.3.2 Solution approach.24
6.3.3 Resource update service module description.26
6.3.4 Resource update service.27
6.3.5 Adding and removing resources .28
7 GDA events .28
7.1 General .28
7.2 GDA events Mmdule.28
7.2.1 General .28
7.2.2 Events module description .28
7.2.3 Events service .29
8 GDA server status and capabilities.30
8.1 General .30
8.2 GDA server module .30
8.2.1 General .30
8.2.2 ServerStatus.30
8.2.3 ServerState .31
8.2.4 ServerCapabilities.31
8.2.5 GDA server module description.31
8.2.6 Status.31
Annex A (informative) Use of GDA proxies .32

61970-403 © IEC:2008(E) – 3 –
Annex B (informative) Implementation guidelines for GDA developers.33
Bibliography .38

Figure 1 – DAF resource query.11
Figure 2 – GDA filtered query .14
Figure 3 – Example of a complete query filter parse tree.15
Figure 4 – Extended resource query service UML .19
Figure 5 – Example property joining use case.20
Figure 6 – Join parse tree .21
Figure 7 – GDA update module .26
Figure 8 – GDA event model .28
Figure 9 – GDA server model .30

Table 1 – DAF resource query operations.
Table 2 – GDA filtered query elements .15
Table 3 – GDA filtered query node types.15
Table 4 – GDA filtered query operation types.16
Table 5 – GDA filtered query OpFilterNode.16
Table 6 – GDA filtered query PropertyFilterNode .17
Table 7 – GDA filtered query ValueFilterNode.17
Table 8 – GDA filtered query operations .17
Table 9 – GDA filtered query join elements.21
Table 10 – GDA filtered query join types.22
Table 11 – GDA filtered query join nodes.22
Table 12 – GDA filtered query property join node.22
Table 13 – GDA extended resource query operations .23
Table 14 – GDA resource update service operations.27
Table 15 – GDA resource event service operations.29
Table 16 – GDA server status .31
Table 17 – GDA server state .31
Table 18 – GDA server capabilities.31
Table 19 – GDA server status operations .31

– 4 – 61970-403 © IEC:2008(E)
INTERNATIONAL ELECTROTECHNICAL COMMISSION
___________
ENERGY MANAGEMENT SYSTEM APPLICATION
PROGRAM INTERFACE (EMS-API) –
Part 403: Generic data access
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-403 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/929/FDIS 57/948/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-403 © 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-403 © IEC:2008(E)
INTRODUCTION
This standard is one of the IEC 61970 series parts that define services 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 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 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-403 Generic Data Access (GDA) defines services that are needed to access public
entity objects for the power system domain that are defined in the IEC 61970-3xx series:
Common Information Model (CIM). GDA permits a client to access data maintained by another
component (either an application or database) or system without any knowledge of the logical
schema used for internal storage of the data. Knowledge of the existence of the common
model is sufficient.
This request and reply oriented service is intended for synchronous, non-real time access of
complex data structures as opposed to high-speed data access of SCADA data, for example,
which is provided by IEC 61970-404, High Speed Data Access. An example where the GDA
would be used is for bulk data access of a persistent store to initialise an analysis application
with the current state of a power system network, and then storage of the results with
notification.
61970-403 © IEC:2008(E) – 7 –
ENERGY MANAGEMENT SYSTEM APPLICATION
PROGRAM INTERFACE (EMS-API) –
Part 403: Generic data access
1 Scope
This International Standard provides a generic request/reply-oriented data access mechanism
for applications from independent suppliers to access CIM data in combination with
IEC 61970-402: Common Services. An application is expected to use the Generic Data Access
(GDA) service as part of an initialisation process or an occasional information synchronization
step. GDA is generic in that it can be used by an application to access any CIM data. GDA is
also generic in that it also provides a back end storage mechanism independent query
capability that can be used to facilitate the creation of CIM data warehouses.
This specification provides a simple, concise service that meets the functionality requirements
of current and future applications while:
• avoiding unnecessary complexity;
• not requiring any specific database technology for implementation.
This service is designed to support interaction where the application or system requesting
information is developed, supplied, maintained, or operated by a separate agency from the
application supplying the data. Furthermore, the update portion of this service assumes that it
)
is undesirable for one system to directly write into another . To support these objectives, the
GDA capabilities are divided into three categories:
a) read access;
b) update access;
c) change notification events.
It should be noted that the update portion of this service does not support unconditional access
to critical real-time data. Rather, the update portion allows a requesting application to ask for
data to be changed in a service provider, but the service provider is under no obligation to
carry out that change at any particular time. Furthermore, a positive response from the update
service does not indicate that the update has occurred, but only that the service provider has
successfully received the request and that the request is syntactically and semantically correct.
GDA could be classified as an Enterprise Information Integration (EII) technology adapter
specialized to the power industry via the assumed use of the CIM. There are a number of EII
products currently available on the market, but there is no accepted cross-platform standard for
writing connectors for these products and overall these products do not take full advantage of a
common semantic model such as the CIM. In recommending GDA, WG 13 is recommending a
standard EII connector model in the form of a simpler, less expensive, and more specialized
interface.
___________
)
For more information on how 61970 excludes direct control of one application by another, see IEC 61970-402
Annex C: The IEC 61970 services and mapping IEC 61968 verbs.

– 8 – 61970-403 © IEC:2008(E)
Though the target of this IEC standard includes the utility control center technical domain,
generic data access encompasses a general set of concepts that can be applied to many types
of systems. Examples of these systems include:
• Energy and distribution management systems
• Work and asset management systems
• Geographic information systems
• Outage management systems
• Other types of technically oriented 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 GDA requirements to the extent
that they are common to different types of systems while effectively addressing utility operation
application specific needs.
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-402, Energy management system application program interface (EMS-API) – Part
402: Component interface specification (CIS) – Common services
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 part of IEC 61970 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 utility operational applications and systems. This specification
provides a mechanism for applications from independent suppliers to access 61970 Common
Information Model (CIM) data using a common service for the purpose of supplementary
processing, storage, or display.

61970-403 © IEC:2008(E) – 9 –
In IEC 61970-401, the 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. Added “However, as the generic interfaces do
not specify what specific data is exchanged, interoperability between products using IEC 61970
402-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 application
category independent message exchange mechanisms, IEC 61970-450 to IEC 61970-499
specify application category dependent CIM derived message contents.
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 a certain functionality considered important for
the environment in which the 61970 standards will be applied.
IEC 61970-402 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
generic application category independent interfaces include this document as well as:
• IEC 61970-404: High Speed Data Access (HSDA)
• IEC 61970-405: Generic Eventing and Subscription (GES)
• IEC 61970-407: Time Series Data Access (TSDA)
IEC 61970-403 Generic Data Access (GDA) defines services that are needed to access public
entity objects for the power system domain that are defined in the IEC 61970-3xx series:
Common Information Model (CIM). GDA permits a client to access data maintained by another
component (either an application or database) or system without any knowledge of the logical
schema used for internal storage of the data. Knowledge of the existence of the common
model is sufficient.
5 GDA read access
5.1 General
This specification describes two forms for GDA read access. The first, originally standardized
within the OMG as the Utility Management System (UMS) Data Access Facility (DAF), provides
clients a basic ability to query for instance data and metadata. The second extends UMS DAF
to provide clients a more advanced ability whereby clients can perform more advanced query
filtering and joining.
5.2 Read access requirements
GDA read access requirements address the problem of obtaining data from an operational data
store on a read-only basis. This includes information describing a real or simulated state of the
system together with the system's model data. GDA read access should be sufficient for
integrating many applications and systems in a near-real-time or non-real-time mode.
___________
)
At this time, only parts 402 to 408 exist. Additional generic services beyond are not yet under consideration.

– 10 – 61970-403 © IEC:2008(E)
Target applications expected to use this interface are listed in the draft IEC 61970-401 CIS
Framework document. The requirements for the Read Access interface are:
a) Interfaces shall define a standard way to access data appropriate to utility operational
systems in general.
b) Interfaces shall support navigation and access to instance data and metadata within a
single CIM context from:
• third party near-real-time applications developed independently of the GDA read access
provider, including analysis and decision support applications;
• foreign systems that require input from the GDA read access provider on a near-real-
time or non-real-time basis, such as other control systems, customer management
systems, trading systems and asset management systems.
c) The facility shall provide access to data organized in a complex schema (in particular the
CIM) which contains:
• multiple classes of data. Models may contain between one hundred and one thousand
classes;
• class attributes belonging to a variety of fundamental types including boolean, integer,
floating point, string, and time;
• reference relationships, which may be single or many-valued;
• inheritance relationships.
d) Interfaces shall provide an efficient means to obtain and join large groups of related data,
such as selected attribute values for multiple instances. A filtering capability shall be
provided to limit the amount of data returned when querying large systems.
e) Interfaces shall not require the use of query. It must be possible to implement the facility for
a wide range of extent systems, and most of these do not support a standard query
language for their real-time data. That is, a GDA provider does not necessarily need to
provide a means to query schema to offer a meaningful implementation. For example,
applications that are aware of the CIM data model and terminology a priori and use it
directly in the API to make direct requests for data do not need a schema query capability.
f) Interfaces shall support a form of read transaction. When a read transaction is used to
bracket a series of data access operations, the data obtained are self-consistent and in
some sense defined by the underlying system.
g) Interfaces shall take the form of a mapping that can accommodate future change in the
CIM. The mapping shall define how classes, attributes and associations in the CIM
correspond to constructs or usage patterns in the proposed interfaces.
h) Interfaces shall provide a means to query and join normalized and de-normalized CIM data.
That is, it shall be possible to retrieve CIM data where the constructs or usage patterns
consist of de-normalized views of CIM data.
i) Interfaces shall define GDA in a manner that supports programming language
independence.
j) The GDA shall not include any services that do not provide for implementation
independence.
k) It must be possible to access CIM data via the standard mapping in the same way
irrespective of the underlying CIM implementation.
l) The interface should be simple and easy to implement to enable standardization and
encourage implementation by suppliers and integrators.

61970-403 © IEC:2008(E) – 11 –
5.3 GDA resource query module
5.3.1 General
Structures and interface semantics relevant to basic read access requirements have been
substantially covered by the scope of the Object Management Group (OMG) Utility
Management System (UMS) Data Access Facility (DAF) standard, to which the read access
portion of this standard refers. Specifically, this document normatively includes by reference
the UML contained in the UMS DAF resource query interface.
5.3.2 Resource query module description
The DAF resource query module provides UML as shown below. See Figure 1:
ResourceID
(from DAFDescriptions)
container: ULongLong
fragment: ULongLong
0.*
ResourceIDSequence
PropertyID
ClassID
(from DAFDescriptions)
(from DAFDescriptions)
PropertySequence
ResourceQueryService
get_values()
get_related_values()
get_extent_values()
Association
get_descendent_values()
property: PropertyID
type: ClassID
00.n.n
ResourceDescription
(from DAFDescriptions)
AssociationSequence
ResourceDescriptionIterator
(from DAFDescriptions)
next_n()
max_left()
IEC  887/08
destroy()
Figure 1 – DAF resource query
The GDA resource query module employs a set of classes for relating and identifying classes,
class properties and instances defined in the DAF resource identifiers and resource description
modules. For more information about these modules, see the DAF specification and
IEC 61970-402: Common services.

– 12 – 61970-403 © IEC:2008(E)
5.3.3 GDA resource query service
5.3.3.1 General
Resource descriptions are obtained from operations on the resource query service. The
interface provides a family of three base operations and one advanced operation intended to
be easy to use. The base operations are: get_values(), get_extent_values(), and
get_related_values(). A fourth operation, get_descendent_values(), is a generalization of the
other three and is capable of greater optimization. See Table 1.
Table 1 – DAF resource query operations
Operation Example signature Throws
ResourceDescription get_values
UnknownResource,
get_values
QueryError
(ResourceID resource, PropertySequence properties)
ResourceDescription get_extent_values
UnknownResource,
get_extent_values
QueryError
(PropertySequence properties, ClassID class_id)
ResourceDescription get_related_values
UnknownResource,
get_related_values
(PropertySequence properties, Association association,
QueryError
ResourceID source)
ResourceDescription get_descendent_values
UnknownResource,
get_descendent_values
(PropertySequence properties, AssociationSequence path,
QueryError
ResourceIDSequence sources, AssociationSequence tail)

Each operation on this interface performs a single query. Each resource description returned
by a query contains values for a subset of the properties requested. The property values
appear in the same order as the properties that were passed to the query, although some may
be omitted. A property value is omitted when it is not available from the data provider for the
particular resource, or when the property identifier is unrecognised. This behaviour makes it
possible to federate multiple query services where each answers part of the query. On the
other hand, if the property is recognized but the data provider detects that it is not a member of
the resource’s class, the QueryError exception is raised. Similarly, QueryError is raised if the
data provider determines that a property is many-valued (a resource description cannot
represent multiple values for a property).
From a client’s perspective, there is always exactly one resource query service in a given
context. (Annex A: Use Of GDA Proxies describes how multiple data providers are handled.) A
context is a set of applications running to meet a specific business need. For example,
contexts might include test, long term planning, or simulation. Context does not appear as a
parameter in any GDA service. It is assumed that there can be a separate provider for any one
service and context.
5.3.3.2 get_values()
This query requests a resource description for a single resource given by its resource identifier.
If the resource identifier is unknown to the data provider, the UnknownResource exception is
raised. For more information about these modules, see the DAF specification.

61970-403 © IEC:2008(E) – 13 –
5.3.3.3 get_extent_values()
This query requests a description for each resource of a given class, that is, for each member
of the class extent set. The class is given by its ClassID, which is a resource identifier.
• If the resource identifier is unknown to the data provider, the UnknownResource exception
is raised.
• If it is recognized but does not represent a class, the QueryError exception is raised.
For more information about these modules, see the DAF Specification.
5.3.3.4 get_related_values()
This query requests a description for each resource associated with a given source resource.
The source is specified by a ResourceID, and the association by an association structure
(defined below). The data provider evaluates the association for the source resource, which
yields zero or more result resources. For each result resource, the data provider evaluates the
given properties and generates a resource description, which is returned through the iterator.
• If the source resource identifier is unknown to the data provider, the UnknownResource
exception is raised.
• If the data provider does not recognize the property specified in the association, the
UnknownAssociation exception is raised.
Since data providers sometimes have only partial information, it is possible that the association
is recognized but its value is not available for the given source resource. In that case, the
UnknownAssociation exception is also raised. This distinguishes the case where no information
is available from the case where the association value is empty. If the data provider detects an
error in the association or determines that it is not type compatible with the source resource (as
defined below), the QueryError exception is raised. For more information about these modules,
see the DAF Specification.
5.3.3.5 get_descendent_values()
This query is a generalization of the foregoing queries and is designed for clients that form
queries in a generic manner. It also provides the greatest opportunity for optimisation on the
part of the data provider. For more information about these modules, see the DAF
Specification.
5.4 GDA filtered query module
5.4.1 General
The GDA filtered query module enhances access to metadata and instance data maintained in
a GDA read access server. Specifically, GDA filtered query extends the GDA resource query
interface by adding the ability to specify property values that are used to qualify a resource
query. In structured query language (SQL) terms, the addition of filters to GDA read access is
equivalent to adding a “where” clause. GDA filters allow clients to more precisely define what
information they are interested in receiving. For methods in the GDA’s resource query service
interface, the GDA’s filtered resource query service interface adds a filter based on a
property’s value.
5.4.2 Filtered query module description
5.4.2.1 General
Figure 2 below illustrates the GDA filtered queries model.

– 14 – 61970-403 © IEC:2008(E)

ValueFilterNode
PropertyFilterNode
Operator
Value : SimpleValue
ClassID : Class ID
PropertyID : PropertyID
0.0.11
0.0.11
OpFilterNode FilterNode FilterNodeType
0.0.11
11 11 11
1.1.**
PropertySequence
(from DAFQuery)
FilterNodes
FilteredQueryService
get_filtered_related_values()
get_filtered_extent_values()
get_filtered_decendent_values()
AssociationSequence
(from DAFQuery)
ResourceID
1.1.**
ClassID
(from CSIdentifiers)
(from DAFQuery)
Association
container : ULongLong
(from DAFQuery)
fragment : ULongLong
property : PropertyID
type : ClassID
IEC  888/08
Figure 2 – GDA filtered query
GDA filtering is accomplished by logically AND’ing or OR’ing one or more property value
comparisons. Property value comparisons are only made on the returned sequence of resource
descriptions of a query. That is, the values of properties returned by a query are used to filter
the returned set of resource descriptions. A property value comparison is made by passing in a
property ID and a constant value. This constant value is compared against the returned value
for the selected property ID. The diagram below (see Figure 3) illustrates how a filter tree can
be constructed when using the Filtered Query Module:

61970-403 © IEC:2008(E) – 15 –
Ex: (((A = 5) or (B < 3)) and C = “Main”)
Op filter node
Property filter node
and
Value filter node
or =
C
Main
= <
A 5 3
B
IEC  889/08
Figure 3 – Example of a complete query filter parse tree
5.4.2.2 FilterNode
A filter is constructed from a triple of filter nodes. A filter node is a generic atomic element that
can be used to hold an Op filter node, Property filter node, or a Value filter node. Filter node
triples are joined together to create a complete query filter consisting of a sequence of AND’ed
or OR’ed filters each of which consists of a triple of filter nodes. Table 2 describes GDA filtered
query elements.
Table 2 – GDA filtered query elements
Element name Description
FilterNodeType Indicates whether the FilterNode is an OPFilterNode, a
ProperyFilterNode, or a ValueFilterNode
OpFilterNode An optional element containing an OpFilterNode
PropertyFilterNode An opt
...