IEC TS 62056-9-1:2016

IEC TS 62056-9-1 ®
Edition 1.0 2016-05
TECHNICAL
SPECIFICATION
colour
inside
Electricity metering data exchange – The DLMS/COSEM suite –
Part 9-1: Communication profile using web-services to access a DLMS/COSEM
server via a COSEM Access Service (CAS)

All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form
or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from
either IEC or IEC's member National Committee in the country of the requester. If you have any questions about IEC
copyright or have an enquiry about obtaining additional rights to this publication, please contact the address below or
your local IEC member National Committee for further information.

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

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

IEC Catalogue - webstore.iec.ch/catalogue Electropedia - www.electropedia.org
The stand-alone application for consulting the entire The world's leading online dictionary of electronic and
bibliographical information on IEC International Standards, electrical terms containing 20 000 terms and definitions in
Technical Specifications, Technical Reports and other English and French, with equivalent terms in 15 additional
documents. Available for PC, Mac OS, Android Tablets and languages. Also known as the International Electrotechnical
iPad. Vocabulary (IEV) online.

IEC publications search - www.iec.ch/searchpub IEC Glossary - std.iec.ch/glossary
The advanced search enables to find IEC publications by a 65 000 electrotechnical terminology entries in English and
variety of criteria (reference number, text, technical French extracted from the Terms and Definitions clause of
committee,…). It also gives information on projects, replaced IEC publications issued since 2002. Some entries have been
and withdrawn publications. collected from earlier publications of IEC TC 37, 77, 86 and

CISPR.
IEC Just Published - webstore.iec.ch/justpublished
Stay up to date on all new IEC publications. Just Published IEC Customer Service Centre - webstore.iec.ch/csc
details all new publications released. Available online and If you wish to give us your feedback on this publication or
also once a month by email. need further assistance, please contact the Customer Service
Centre: csc@iec.ch.
IEC TS 62056-9-1 ®
Edition 1.0 2016-05
TECHNICAL
SPECIFICATION
colour
inside
Electricity metering data exchange – The DLMS/COSEM suite –

Part 9-1: Communication profile using web-services to access a DLMS/COSEM

server via a COSEM Access Service (CAS)

INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
ICS 17.220.20; 35.100.01; 91.140.50 ISBN 978-2-8322-3329-0

– 2 – IEC TS 62056-9-1:2016 © IEC 2016
CONTENTS
FOREWORD . 4
1 Scope . 6
2 Normative references. 6
3 Terms, definitions and abbreviations . 7
4 Relation to the IEC 62056 smart metering architecture . 8
4.1 Overview. 8
4.2 Example: Using the S-FSK profile according to IEC 62056-8-3 . 8
5 Use cases . 8
5.1 General . 8
5.2 Use case: Device Access . 9
5.2.1 Overview . 9
5.2.2 On-demand Device Access . 9
5.2.3 Scheduled Device Access . 11
5.2.4 Device Access with Data-Notification . 14
5.3 Use case: Device groups . 15
6 Web services interface model . 15
7 Message organisation for the WS interface . 15
7.1 Overview. 15
7.2 IEC 62056 messages . 15
7.2.1 Overview . 15
7.2.2 General . 15
7.2.3 Verbs . 16
7.2.4 Nouns . 17
7.2.5 Payloads . 17
7.2.6 Payload for noun Device Access . 17
7.3 Common Message Envelope . 23
7.3.1 Overview . 23
7.3.2 General . 23
7.3.3 Message header structure . 23
7.3.4 Request message structure . 25
7.3.5 Response message structure . 27
7.3.6 Event message structure . 30
7.3.7 Fault message structure . 31
8 Interface specification . 32
8.1 Overview. 32
8.2 Interface using SOAP . 32
8.2.1 General . 32
8.2.2 WSDL structure . 33
8.2.3 SOAP envelope . 33
Annex A (informative) XML schema for the COSEM XML representation . 35
A.1 COSEMpdu . 35
A.2 XML schema for the payload definitions . 56
A.2.1 DeviceAccess . 56
A.2.2 DeviceGroup . 57
A.3 XML Schema for common message envelope . 57

A.4 WSDL for interface using SOAP . 58
Bibliography . 59

Figure 1 – Reference model for the COSEM Access Client to DLMS/COSEM server
connection via a COSEM Access Service . 6
Figure 2 – The smart metering architecture of IEC 62056. 8
Figure 3 – Use case: On-demand Device Access . 10
Figure 4 – Use case: Scheduled Device Access . 12
Figure 5 – Use case: Scheduled Device Access with Events . 13
Figure 6 – Use case: Device Access with Data-Notification . 14
Figure 7 – IEC 62056 messages between CAS Client and COSEM Access Service
(CAS) . 16
Figure 8 – DeviceAccess overview structure . 17
Figure 9 – DeviceGroups structure . 18
Figure 10 – CosemAccessDescriptor sub-structure . 19
Figure 11 – ACSEDescriptor sub-structure . 19
Figure 12 – XDLMSDescriptor substructure . 20
Figure 13 – cosemAccessResult substructure . 21
Figure 14 – errorResult substructure . 21
Figure 15 – ACSEResult substructure . 21
Figure 16 – XDLMSResult substructure . 22
Figure 17 – Common Message Envelope . 23
Figure 18 – Common Message header structure . 24
Figure 19 – RequestMessage structure . 26
Figure 20 – XML for RequestMessage to create DeviceAccess . 27
Figure 21 – ResponseMessage structure . 28
Figure 22 – XML for ResponseMessage on create DeviceAccess . 29
Figure 23 – EventMessage structure . 30
Figure 24 – XML for EventMessage on change of DeviceAccess . 31
Figure 25 – FaultMessage structure . 32
Figure 26 – XML for FaultMessage on create of DeviceAccess . 32
Figure 27 – SOAP message with RequestMessage . 34

– 4 – IEC TS 62056-9-1:2016 © IEC 2016
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
ELECTRICITY METERING DATA EXCHANGE –
THE DLMS/COSEM SUITE –
Part 9-1: Communication profile using web-services to access
a DLMS/COSEM server via a COSEM Access Service (CAS)

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.
The main task of IEC technical committees is to prepare International Standards. In
exceptional circumstances, a technical committee may propose the publication of a technical
specification when
• the required support cannot be obtained for the publication of an International Standard,
despite repeated efforts, or
• the subject is still under technical development or where, for any other reason, there is the
future but no immediate possibility of an agreement on an International Standard.
Technical specifications are subject to review within three years of publication to decide
whether they can be transformed into International Standards.
IEC TS 62056-9-1, which is a technical specification, has been prepared by IEC technical
committee 13: Electrical energy measurement and control.

The text of this technical specification is based on the following documents:
Enquiry draft Report on voting
13/1641/DTS 13/1662/RVC
Full information on the voting for the approval of this technical specification 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 62056 series, published under the general title Electricity metering
data exchange – The DLMS/COSEM suite, 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
• transformed into an International standard,
• reconfirmed,
• withdrawn,
• replaced by a revised edition, or
• amended.
A bilingual version of this publication may be issued at a later date.

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.
– 6 – IEC TS 62056-9-1:2016 © IEC 2016
ELECTRICITY METERING DATA EXCHANGE –
THE DLMS/COSEM SUITE –
Part 9-1: Communication profile using web-services to access
a DLMS/COSEM server via a COSEM Access Service (CAS)

1 Scope
This part of IEC 62056, which is a Technical Specification, defines how DLMS/COSEM
servers can be accessed from a COSEM Access Client via an intermediate COSEM Access
Service (CAS) providing Web services. The DLMS/COSEM server contains an application
server supporting the data model of IEC 62056-6-1 / IEC 62056-6-2 and the application layer
of IEC 62056-5-3. The underlying communication layers between the CAS and the
DLMS/COSEM server are not covered by this specification. However, it is assumed that a
profile standard exists describing how the underlying communication technology is used in
conjunction with IEC 62056-6-1/ IEC 62056-6-2 and IEC 62056-5-3.
The Web services defined in this Technical Specification concern the G2 interface according
to the architecture defined in IEC 62056-1-0.
The contents of this document define the Web services between the COSEM Access Client
and the COSEM Access Service (CAS) as shown in Figure 1.
COSEM
COSEM DLMS/COSEM
DLMS/COSEM
Web services
Access Service
services
Access Client server
(CAS)
IEC
Figure 1 – Reference model for the COSEM Access Client to DLMS/COSEM
server connection via a COSEM Access Service
The COSEM Access Client identifies the DLMS/COSEM server by its system title (see
IEC 62056-5-3).
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and
are indispensable for its application. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any
amendments) applies.
IEC 61968-1:2012, Application integration at electric utilities – System interfaces for
distribution management – Part 1: Interface architecture and general recommendations
IEC 61968-100:2013, Application integration at electric utilities – System interfaces for
distribution management – Part 100: Implementation profiles
IEC 62056-1-0, Electricity metering data exchange – Part 1-0: Smart metering standardization
framework
CAS client
CAS provider
DLMS/COSEM
client
DLMS/COSEM
server
IEC 62056-5-3, Electricity metering data exchange – The DLMS/COSEM suite – Part 5-3:
DLMS/COSEM application layer
IEC 62056-6-1, Electricity metering data exchange – The DLMS/COSEM suite – Part 6-1:
Object Identification System (OBIS)
IEC 62056-6-2, Electricity metering data exchange – The DLMS/COSEM suite – Part 6-2:
COSEM interface classes
IEC 62056-8-3, Electricity metering data exchange – The DLMS/COSEM suite – Part 8-3:
Communication profile for PLC S-FSK neighbourhood networks
3 Terms, definitions and abbreviations
For the purposes of this document, the following terms, definitions and abbreviations apply.
ACSE Association Control Service Element
APDU Application Layer Protocol Data Unit
CAC COSEM Access Client
CAS COSEM Access Service
CAS Provider Interface providing Web services to access the CAS
CME Common Message Envelope
COSEM Companion Specification for Energy Metering
COSEM Access Client Client accessing the DLMS/COSEM server via the COSEM Access
Service CAS
COSEM Access Service Service entity providing Web service based COSEM access towards
the COSEM Access Client and acting as a DLMS/COSEM client
towards the DLMS/COSEM server
DLMS Device Language Message Specification
DLMS/COSEM server DLMS/COSEM server supporting the data models of IEC 62056-6-1
/ IEC 62056-6-2 and the application layer of IEC 62056-5-3
HES Head End System, also known as Data Collection System
IP Internet Protocol
ISO International Organization for Standardization
mRID CIM master resource identifier
NN Neighbourhood Network
NNAP Neighbourhood Network Access Point
REST REpresentational State Transfer
SOAP Simple Object Access Protocol
UUID Universal Unique Identifier
WAN Wide area network
WS Web services
WSDL Web Services Definition Language
xDLMS Extended DLMS
XML eXtensible Markup Language
XSD XML Schema
– 8 – IEC TS 62056-9-1:2016 © IEC 2016
4 Relation to the IEC 62056 smart metering architecture
4.1 Overview
Considering the smart metering architecture introduced in IEC 62056-1-0 the abstract model
of Figure 2 covers the communication between the HES and the NNAP as shown in Figure 2.
Where the HES acts as COSEM Access Client, the NNAP provides the COSEM Access
Service (CAS) and the DLMS/COSEM server corresponds to the metering device. The Web
services defined in this TS concern the G2 interface. Typically, the communication technology
used in the NN is not the same as the communication technology used in the WAN; i.e. the
NN does not necessarily support IP based communication.
4.2 Example: Using the S-FSK profile according to IEC 62056-8-3
When the S-FSK PLC profile is used between the NNAP (CAS) and the metering device
(DLMS/COSEM server), the system titles of the NNAP and the metering device are
exchanged during the registration process using the CIASE protocol. In this case the
information of the system titles shall be made available to the HES (COSEM Access Client)
prior to the establishment of any communication with the metering device.
Simple
Metering H1
consumer
device Home automation
display
DLMS/COSEM
system
server
G1 M
C
M
H2
G1
LNAP Local Network
Access Point
C C
DLMS/COSEM client
H3
NNAP Neighbourhood Network
CAS
Access Point
CAS provider
G2
G1
CAS client
COSEM Access
Client
HES Head End System
IEC
Figure 2 – The smart metering architecture of IEC 62056
5 Use cases
5.1 General
The use cases defined in the following subclauses are based on the reference model of
Figure 1; i.e. the use cases concern the messaging for the data exchange between a COSEM
Access Client and a DLMS/COSEM server via a CAS; the use cases cover the data exchange
processes between the actors involved. The use cases for the applications to support the
smart metering business processes are not considered.
The following actors are considered (see Figure 1):
WAN Wide Area Network
NN Neighbourhood Network
LN Local Network
• COSEM Access Client;
• COSEM Access Service;
• DLMS/COSEM server.
The use cases are supported by 3 generic types of messages (supporting the data exchange
processes) exchanged between the COSEM Access Client and the COSEM Access Service:
• WS-Request();
• WS-Response();
• WS-Event().
The COSEM Access Client issues a request by sending a WS-Request message to the
COSEM Access Service. The COSEM Access Service in return sends WS-Response
messages or WS-Event messages to the COSEM Access Client. The COSEM Access Client
expects one of the following results from the issued request:
• the request is successfully processed and a WS-Response message is returned in a
timely manner;
• the request is accepted, but results in a WS-Response message that returns an
application level error code or a fault;
• the request is accepted, the WS-Response message is returned and the results are sent
asynchronously to COSEM Access Client by means of WS-Event messages.
5.2 Use case: Device Access
5.2.1 Overview
The COSEM Access Client requests to access a set of COSEM objects in a set of
DLMS/COSEM servers.
The data exchange is initiated and managed by the COSEM Access Client using the
standardised services and processes defined in IEC 62056-5-3. In particular, the COSEM
Access Client assembles the DeviceAccess messages which encapsulate the corresponding
xDLMS APDUs. The DeviceAccess messages are transmitted to the COSEM Access Service
for processing and transmission to the DLMS/COSEM servers. Processing involves on-
demand or scheduled activation of exchanges with DLMS/COSEM servers and providing the
results of this exchange. For that purpose the COSEM Access Client uses the Web services
provided by the WS Provider in the COSEM Access Service.
5.2.2 On-demand Device Access
5.2.2.1 Overview
The requests are executed immediately by the CAS. Upon availability, the results are made
available by the CAS via Web services. The corresponding message sequence diagram is
shown in Figure 3.
– 10 – IEC TS 62056-9-1:2016 © IEC 2016
sd On-demand Device Access
COSEM Access COSEM Access DLMS/COSEM
Client Service server
WS-Request()
DLMS/COSEM-Request()
DLMS/COSEM-Response()
WS-Response()
IEC
Figure 3 – Use case: On-demand Device Access
5.2.2.2 Parameters
On demand access is defined by the following parameters:
DevicesReferenceList (mandatory element):
Specifies the list of DLMS/COSEM servers which need to be accessed via the CAS. Besides
the identification of the physical device the DeviceReferenceList also contains the
identification of the logical device of the server.
CosemAccessList (mandatory element):
Specifies the list of COSEM services to be invoked in the DLMS/COSEM servers defined in
DevicesReferenceList.
Activates (optional element):
For on-demand access the element Activates (optional element) is omitted, meaning that this
service is immediately activated.
NotOlderThan (optional element):
Any result from the DLMS/COSEM servers invoked by the CAS which is older than
“NotOlderThan” will no more be available at the CAS Provider.

Priority (optional element):
Defines the priority with which the CAS has to invoke the COSEM services listed in the
COSEMAccessList.
Expires (optional element):
Specifies the date and time when the CAS has to stop invoking the services listed in the
CosemAccessList.
5.2.2.3 Result
The result from the DLMS/COSEM server shall be delivered to the CAS Provider interface
upon availability. The result may be notified, directly transmitted to the COSEM Access Client
or queried by the COSEM Access Client. Only data which is “NotOlderThan” can be
successfully queried. Once delivered to the COSEM Access Client the result may not be
available in the CAS anymore.
The result of an “on-demand access” has the following form:
OnDemandDeviceAccess/CosemAccessList/CosemAccess[0.n]/CosemAccessResult[0.n]
Any error message shall contain sufficient information to locate the source of the error. In
particular three error locations shall be distinguished:
• to report errors on the DLMS/COSEM server level the CosemAccessResult is according to
COSEM APDU definitions in IEC 62056-5-3;
• to report errors on the communication between the DLMS/COSEM client interface of the
CAS and the DLMS/COSEM server the CosemAccessResult is extended according to
7.2.6.1.4;
• to report errors on the CAS level the CosemAccessResult is extended according to
7.2.6.1.4.
5.2.3 Scheduled Device Access
5.2.3.1 Overview
The execution time of the access to the DLMS/COSEM server by the CAS can be defined by
means of the “Activates” parameter. In particular, the execution may be performed once at a
specific point of time or the execution may be repeated several times. The corresponding
message sequence diagrams are shown in Figure 4 and Figure 5.

– 12 – IEC TS 62056-9-1:2016 © IEC 2016
sd Scheduled Device Access
COSEM Access COSEM Access DLMS/COSEM
Client Service server
WS-Request()
WS-Response(ACK)
DLMS/COSEM-Request()
DLMS/COSEM-Response()
DLMS/COSEM-Request()
DLMS/COSEM-Response()
WS-Request()
WS-Response()
IEC
Figure 4 – Use case: Scheduled Device Access
The use case Scheduled Device Access message exchange consists of the following process:
• the COSEM Access Client issues a request by sending a WS-Request message to
COSEM Access Service;
• the COSEM Access Service in return sends a WS-Response message acknowledging the
request to COSEM Access Client;
• the COSEM Access Service issues DLMS/COSEM-Request messages to the
DLMS/COSEM server according to the defined schedule and then processes the
DLMS/COSEM-Response messages received from COSEM server;
• the COSEM Access Client issues a request by sending a WS-Request message to the
COSEM Access Service requesting the results of the scheduled DLMS/COSEM requests;
• the COSEM Access Service sends a WS-Response message with the results of the
scheduled DLMS/COSEM requests to the COSEM Access Client.

sd Scheduled Device Access with Events
COSEM Access COSEM Access DLMS/COSEM
Client Service server
WS-Request()
WS-Response()
loop
DLMS/COSEM-Request()
DLMS/COSEM-Response()
WS-Event()
IEC
Figure 5 – Use case: Scheduled Device Access with Events
The use case Scheduled Device Access with Events message exchange consists of the
following process:
• the COSEM Access Client issues a request by sending a WS-Request message to the
COSEM Access Service;
• the COSEM Access Service in return sends a WS-Response message acknowledging the
request to the COSEM Access Client;
• the COSEM Access Service issues DLMS/COSEM-Request messages to the
DLMS/COSEM server according to defined schedule;
• the COSEM Access Service processes the DLMS/COSEM-Response messages and sends
WS-Event messages to the COSEM Access Client.
5.2.3.2 Parameters
Scheduled access uses the parameters listed in 5.2.2.2. For scheduled access the parameter
“Activates” becomes a mandatory element defining the details of the access schedule.
Activates (mandatory element)
Specifies the date and time when the CAS has to invoke the services listed in the
CosemAccessList. Start time, period, end time, validity window, according to the Schedule
(ISO 8601).
– 14 – IEC TS 62056-9-1:2016 © IEC 2016
5.2.3.3 Result
The result from scheduled access follows the definitions in 5.2.2.3.
5.2.4 Device Access with Data-Notification
5.2.4.1 Overview
The requests from the COSEM Access Client are used to set-up the Push operation in the
DLMS/COSEM server. With the response from CAS to the CAC the request (to set-up the
Push operation) is acknowledged. The actual Push operation in the DLMS/COSEM server
consists of sending Data-Notification APDUs to the CAS. The CAS then sends the received
Data-Notification APDUs via events to the COSEM Access Client. The corresponding
message sequence is diagram is shown in Figure 6.
sd Device Access with Data-Notification
COSEM Access COSEM Access DLMS/COSEM
Client Service server
WS-Request()
DLMS/COSEM-Request()
DLMS/COSEM-Response()
WS-Response()
loop
DLMS/COSEM-Data-Notification()
WS-Event()
IEC
Figure 6 – Use case: Device Access with Data-Notification
The use case Scheduled Device Access with Data-Notification message exchange consists of
the following process:
• the COSEM Access Client issues a request by sending a WS-Request message to the
COSEM Access Service;
• the COSEM Access Service in return sends a WS-Response message acknowledging the
execution of the request to the COSEM Access Client;
• the COSEM Access Service receives messages with DLMS/COSEM-Data-Notification
APDUs from the DLMS/COSEM server;
• the COSEM Access Service processes the DLMS/COSEM-Data-Notification APDUs and
sends the corresponding WS-Event messages to COSEM Access Client.
5.2.4.2 Parameters
Device Access with Data-Notification uses the parameters listed in 5.2.3.2.
5.2.4.3 Result
The result from Device Access with Data-Notification follows the definitions in 5.2.2.3.
5.3 Use case: Device groups
The COSEM Access Client requests the CAS to define a group of DLMS/COSEM servers.
6 Web services interface model
The interface follows the basic request/response and publish/subscribe patterns using Web
services as shown in Figure 3, in Figure 4 and in Figure 6. The Web service client issues a
request to the Web service provider in the CAS. The details of the interface are defined in
Clause 8.
Depending on the nature of the request and the availability of the communication medium
between the CAS and the DLMS/COSEM server, the Cosem Access Client may expect the
result as a response to the request immediately (synchronous operation), or delayed
(scheduled operation), or as an event triggered by the reception of a Data-Notification APDU
from the DLMS/COSEM server. The use case “On Demand Device Access” uses synchronous
operation whereas the use case “Scheduled Device Access” is based on scheduled operation.
The use case “Device Access with Data-Notification” is using events on Data-Notification.
7 Message organisation for the WS interface
7.1 Overview
The generic Request/Reply services are supported by different types of messages at the Web
service interfaces. The WS interface is constructed to accept messages consisting of a Verb,
a Noun and a Payload. The Noun identifies the type of the Payload that may be part of the
Request and of the Reply.
7.2 IEC 62056 messages
7.2.1 Overview
In the following the IEC 62056 information exchange messages in terms of a verb, a noun and
the payload are described. IEC 62056 messages are based on IEC 61968-1 and IEC 61968-
100 where only selected verbs are used and new nouns and payloads are defined.
7.2.2 General
IEC 61968-1 describes the information exchanges in terms of a verb, noun and payload.
Figure 7 shows the IEC 62056 messages between the COSEM Access Client and the COSEM
Access Service (CAS) described with the corresponding the verbs.

– 16 – IEC TS 62056-9-1:2016 © IEC 2016
get
create
delete
change
COSEM
COSEM
Access Service
Access Client
reply
CAS
created
deleted
changed
IEC
Figure 7 – IEC 62056 messages between CAS Client
and COSEM Access Service (CAS)
7.2.3 Verbs
The verbs used in the Request are also used to identify the Reply and the publication of an
Event which may be the consequence of the successful transaction initiated by the Request.
The following verbs are used in the IEC 62056 messages:
• ‘get’ is used in requests to query for objects of the type specified by the noun;
• ‘create’ is used in requests to create objects of the type specified by the noun;
• ‘delete’ is used in requests to delete objects of the type specified by the noun;
• ‘change’ is used in requests to change objects of the type specified by the noun;
• ‘reply’ is used in responses to requests;
• ‘created’ is used in events indicating that the objects specified by the noun have been
created;
• ‘deleted’ is used in events indicating that the objects specified by the noun have been
deleted;
• ‘changed’ is used in events indicating that the objects specified by the noun are have been
changed.
7.2.4 Nouns
Nouns are used to identify the type of information being exchanged. Each noun has a
corresponding XML Schema uniquely assigned to it. Nouns identify the use case supported by
the exchanged information.
The following nouns are used in the IEC 62056 messages:
• Device Access;
• Device Groups.
7.2.5 Payloads
Each noun identifies the payload structure which is specified with the corresponding XML
Schema. Depending on the situation, a payload may or may not be required in a message.
7.2.6 Payload for noun Device Access
7.2.6.1 Overview
7.2.6.1.1 General
The detailed XML schema for the Device Access payload is presented in A.2.1. The Figure 8
shows the structure of the payload for the noun Device Access.

IEC
Figure 8 – DeviceAccess overview structure
Fields that can be optionally supplied include the following:

– 18 – IEC TS 62056-9-1:2016 © IEC 2016
• DeviceReferenceList: Specifies the list of DLMS/COSEM servers which need to be
accessed via the CAS. Besides the identification of the physical device the
DeviceReferenceList also contains the identification of the logical device of the server;
• CosemAccessList: Specifies the list of DLMS/COSEM services to be invoked with the
DLMS/COSEM servers defined with DevicesReferenceList;
• Activates: Specifies the date and time when the CAS has to invoke the DLMS/COSEM
services listed in the CosemAccessList. Start time, period, end time, validity window,
according to the “Schedule” definitions of ISO 8601;
• Expires: Specifies the date and time when the CAS has to stop invoking the
DLMS/COSEM services listed in the CosemAccessList;
• Created: Contains the date and time when the DeviceAccess has been created;
• Updated: Contains the date and time when the DeviceAccess has been updated;
• Priority: Defines the priority with which the CAS has to invoke the DLMS/COSEM services
in the COSEMAccessList;
• NotOlderThan: Any result from the DLMS/COSEM servers invoked by the CAS which is
older than “NotOlderThan” will no more be available at the WS Provider of the CAS;
• AcceptDataNotification: Specifies if Data-Notification APDUs from the DLMS/COSEM
servers are accepted. When not defined then the Data-Notification APDUs are discarded.
7.2.6.1.2 DeviceGroups
The GroupReference element of DeviceAccess (see Figure 8) corresponds to the GroupID
attribute of DeviceGroups (see Figure 9).

IEC
Figure 9 – DeviceGroups structure
DeviceGroups consist of a set of DeviceGroup elements where each element consists of the
GroupID and a list of DeviceIDs.
7.2.6.1.3 CosemAccessDescriptor
7.2.6.1.3.1 General
The CosemAccessDescriptor element of the DeviceAccess (see Figure 8) is shown in
Figure 10.
IEC
Figure 10 – CosemAccessDescriptor sub-structure
The CosemAccessDescriptor consists of the ACSEDescriptor or the XDLMSDescriptor
element.
7.2.6.1.3.2 ACSEDescriptor
The ACSEDescriptor element of the DeviceAccess (see Figure 8) is shown in Figure 11.

IEC
Figure 11 – ACSEDescriptor sub-structure
ACSEDescriptor consists of the aarq, aare, rlrq and rlre elements. These elements are
representation of DLMS/COSEM ACSE APDUs. Only request DLMS/COSEM ACSE APDUs
may be present in the ACSEDescriptor.
7.2.6.1.3.3 XDLMSDescriptor
The XDLMSDescriptor element of the DeviceAccess (see Figure 8) is shown in Figure 12.

– 20 – IEC TS 62056-9-1:2016 © IEC 2016

IEC
Figure 12 – XDLMSDescriptor substructure
The XDLMSDescriptor consists of elements that are representation of DLMS/COSEM xDLMS
APDUs. Only request DLMS/COSEM xDLMS APDUs may be present in the XDLMSDescriptor.

7.2.6.1.4 CosemAccessResult
7.2.6.1.4.1 General
The CosemAccessResult element of the DeviceAccess (see Figure 8) is shown in Figure 13.

IEC
Figure 13 – cosemAccessResult substructure
CosemAccessResult consists of the ACSEResult, XDLMSResult or ErrorResult element.
The errorResult element of the DeviceAccess (see Figure 8) is shown in Figure 14.

IEC
Figure 14 – errorResult substructure
In the case when the ACSEResult or XDLMSResult cannot be returned the ErrorResult is
used. The errorResult element consist of ErrorIdent and ErrorDetail.
• ErrorIdent: Contains the identification of the error that have occurred during the
processing of the DeviceAccess message. The following values are defined:
– Communication Error (1);
– Internal CAS Error (2);
• ErrorDetail: Contains the text of the error detail.
7.2.6.1.4.2 ACSEResult
The ACSEResult element of the DeviceAccess element (see Figure 8) is shown in Figure 15.

IEC
Figure 15 – ACSEResult substructure

– 22 – IEC TS 62056-9-1:2016 © IEC 2016
ACSEResult consists of the aarq, aare, rlrq and rlre elements. These elements are
representation of DLMS/COSEM ACSE APDUs. Only response DLMS/COSEM ACSE APDUs
may be present in the ACSEResult.
7.2.6.1.4.3 XDLMSResult
The XDLMSResult element of the DeviceAccess (see Figure 8) is shown in Figure 16.

IEC
Figure 16 – XDLMSResult substructure

XDLMSResult consists of elements that are representation of DLMS/COSEM xDLMS APDUs.
Only response DLMS/COSEM xDLMS APDUs may be present in the XDLMSResult.
7.3 Common Message Envelope
7.3.1 Overview
All messages use a common message envelope (CME) as defined in IEC 61968-100.
7.3.2 General
Messages are constructed with several sections, including:
• Header: Required for all messages (except for fault response messages). The header is
providing a common structure for all service interfaces;
• Request: optional. The Request field defines commonly used parameters needed to
qualify ‘get’ query requests, or identify specific objects for ‘delete’, ‘cancel’ or ‘close’
requests. Not used for event or response messages;
• Reply: Required only for response messages to indicate success, failure and error details.
Not used for request or event messages;
• Payload: Used to convey message information as a consequence of the ‘Verb’ and ‘Noun’
combination in the message Header. Required for ‘create’, ‘change’ and ‘execute’
requests. Payload is also required for event messages. Optional in other cases as
described in Annex B of IEC 61968-100:2013. The payload structure provides options for
payload compression.
Figure 17 provides a generalized view of the high-level message structure:

IEC
Figure 17 – Common Message Envelope
7.3.3 Message header structure
The header is common to request, response and event messages. The header has two
required fields that shall be populated, these include:
• V
...