IEC 62056-62:2002

INTERNATIONAL IEC
STANDARD
62056-62
First edition
2002-02
Electricity metering –
Data exchange for meter reading,
tariff and load control –
Part 62:
Interface classes
Reference number
Publication numbering
As from 1 January 1997 all IEC publications are issued with a designation in the

60000 series. For example, IEC 34-1 is now referred to as IEC 60034-1.

Consolidated editions
The IEC is now publishing consolidated versions of its publications. For example,

edition numbers 1.0, 1.1 and 1.2 refer, respectively, to the base publication, the

base publication incorporating amendment 1 and the base publication incorporating

amendments 1 and 2.
Further information on IEC publications
The technical content of IEC publications is kept under constant review by the IEC,
thus ensuring that the content reflects current technology. Information relating to
this publication, including its validity, is available in the IEC Catalogue of
publications (see below) in addition to new editions, amendments and corrigenda.
Information on the subjects under consideration and work in progress undertaken
by the technical committee which has prepared this publication, as well as the list
of publications issued, is also available from the following:
• IEC Web Site (www.iec.ch)
• Catalogue of IEC publications
The on-line catalogue on the IEC web site (www.iec.ch/catlg-e.htm) enables
you to search by a variety of criteria including text searches, technical
committees and date of publication. On-line information is also available on
recently issued publications, withdrawn and replaced publications, as well as
corrigenda.
• IEC Just Published
This summary of recently issued publications (www.iec.ch/JP.htm) is also
available by email. Please contact the Customer Service Centre (see below) for
further information.
• Customer Service Centre
If you have any questions regarding this publication or need further assistance,
please contact the Customer Service Centre:
Email: custserv@iec.ch
Tel: +41 22 919 02 11
Fax: +41 22 919 03 00
INTERNATIONAL IEC
STANDARD
62056-62
First edition
2002-02
Electricity metering –
Data exchange for meter reading,
tariff and load control –
Part 62:
Interface classes
 IEC 2002  Copyright - all rights reserved
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 the publisher.
International Electrotechnical Commission 3, rue de Varembé Geneva, Switzerland
Telefax: +41 22 919 0300 e-mail: inmail@iec.ch IEC web site http://www.iec.ch
Commission Electrotechnique Internationale
PRICE CODE
XC
International Electrotechnical Commission
For price, see current catalogue

– 2 – 62056-62  IEC:2002(E)
CONTENTS
FOREWORD.4

INTRODUCTION.6

1 Scope.7

2 Normative references .7

3 Terms, definitions and abbreviations .8

4 Basic principles .9

4.1 General .9
4.2 Class description notation .10
4.3 Common data types.12
4.4 Data formats for date and time notation.12
4.5 The COSEM server model .14
4.6 COSEM logical device.15
4.6.1 General .15
4.6.2 COSEM logical device name.15
4.6.3 The “association view” of the logical device .15
4.6.4 Mandatory contents of a COSEM logical device.15
4.7 Authentication procedures.16
4.7.1 Low level security (LLS) authentication.16
4.7.2 High-level security (HLS) authentication .16
5 The interface classes.17
5.1 Data (class_id: 1) .17
5.2 Register (class_id: 3) .18
5.3 Extended register (class_id: 4) .20
5.4 Demand register (class_id: 5).21
5.5 Register activation (class_id: 6).24
5.6 Profile generic (class_id: 7) .25
5.7 Clock (class_id: 8).29
5.8 Script table (class_id: 9).32
5.9 Schedule (class_id: 10) .33
5.10 Special days table (class_id: 11) .36
5.11 Activity calendar (class_id: 20) .37

5.12 Association LN (class_id: 15) .39
5.13 Association SN (class_id: 12) .43
5.14 SAP assignment (class_id: 17) .45
5.15 Register monitor (class_id: 21) .46
5.16 Utility tables (class_id: 26) .47
5.17 Single action schedule (class_id: 22).48
6 Maintenance of the interface classes .48
6.1 New interface classes.49
6.2 New versions of interface classes.49
6.3 Removal of interface classes.49

62056-62  IEC:2002(E) – 3 –
Annex A (normative) Protocol related interface classes.50

A.1 IEC local port setup (class_id: 19) .50

A.2 PSTN modem configuration (class_id: 27) .51

A.3 PSTN auto answer (class_id: 28).52

A.4 PSTN Auto dial (class_id: 29).54

A.5 IEC HDLC setup (class_id: 23) .55

A.6 IEC twisted pair (1) setup (class_id: 24) .56

Annex B (normative) Data model and protocol .58

Annex C (normative) Using short names for accessing attributes and methods .59

C.1 Guidelines for assigning short names .59
C.2 Reserved base_names for special COSEM objects .64
Annex D (normative) Relation to OBIS .65
D.1 Mapping of data items to COSEM objects and attributes .65
D.1.1 Abstract COSEM objects .65
D.1.2 Electrical energy related COSEM objects .73
D.2 Coding of OBIS identifications .77
Annex E (informative) Previous versions of interface classes.79
Bibliography.80
Index .81
Figure 1 – An interface class and its instances .9
Figure 2 – The COSEM server model.14
Figure 3 – Combined metering device.14
Figure 4 – Overview of the interface classes.17
Figure 5 – The attributes when measuring sliding demand .21
Figure 6 – The attributes when measuring current_average_value
if number of periods is 1 .21
Figure 7 – The attributes if number of periods is 3 .22
Figure 8 – The generalized time concept .30
Figure B. 1 – The three step approach of COSEM.58

– 4 – 62056-62  IEC:2002(E)
INTERNATIONAL ELECTROTECHNICAL COMMISSION

____________
ELECTRICITY METERING – DATA EXCHANGE

FOR METER READING, TARIFF AND LOAD CONTROL –

Part 62: Interface classes
FOREWORD
1) The IEC (International Electrotechnical Commission) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of the 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, the IEC publishes International Standards. 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. The 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 the 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 National Committees.
3) The documents produced have the form of recommendations for international use and are published in the form
of standards, technical specifications, technical reports or guides and they are accepted by the National
Committees in that sense.
4) In order to promote international unification, IEC National Committees undertake to apply IEC International
Standards transparently to the maximum extent possible in their national and regional standards. Any
divergence between the IEC Standard and the corresponding national or regional standard shall be clearly
indicated in the latter.
5) The IEC provides no marking procedure to indicate its approval and cannot be rendered responsible for any
equipment declared to be in conformity with one of its standards.
The International Electrotechnical Commission (IEC) draws attention to the fact that it is claimed that compliance
with this International Standard may involve the use of a maintenance service concerning the stack of protocols on
which the present standard IEC 62056-62 is based.
The IEC takes no position concerning the evidence, validity and scope of this maintenance service.
The provider of the maintenance service has assured the IEC that he is willing to provide services under
reasonable and non-discriminatory terms and conditions with applicants throughout the world. In this respect, the
statement of the provider of the maintenance service is registered with the IEC. Information (see also chapter 4.6.2
and Annex E) may be obtained from:
DLMS User Association
Geneva / Switzerland
www.dlms.ch
International Standard IEC 62056-62 has been prepared by IEC technical committee 13:
Equipment for electrical energy measurement and load control.
The text of this standard is based on the following documents:
FDIS Report on voting
13/1270/FDIS 13/1276/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.
———————
Device Language Message Specification.

62056-62  IEC:2002(E) – 5 –
This publication has been drafted in accordance with the ISO/IEC Directives, Part 3.

Annexes A, B, C and D form an integral part of this standard.

Annex E is for information only.

The committee has decided that the contents of this publication will remain unchanged until

2006. 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 – 62056-62  IEC:2002(E)
INTRODUCTION
Driven by the need of the utilities to optimize their business processes, the meter becomes

more and more part of an integrated metering and billing system. Whereas in the past the

commercial value of a meter was mainly generated by its data acquisition and processing

capabilities, nowadays the critical issues are system integration and interoperability.

The Companion Specification for Energy Metering (COSEM) addresses these challenges by

looking at the meter as an integrated part of a commercial process which starts with the

measurement of the delivered product (energy) and ends with the revenue collection.

The meter is specified by its “behaviour” as seen from the utility's business processes. The
formal specification of the behaviour is based on object modelling techniques (interface
classes and objects). The specification of these objects forms a major part of COSEM.
The COSEM server model (see 4.5) represents only the externally visible elements of the
meter. The client applications that support the business processes of the utilities, of the
customers and of the meter manufacturers make use of this server model. The meter offers
means to retrieve its structural model (the list of objects visible through the interface), and
provides access to the attributes and specific methods of these objects.
The set of different interface classes form a standardized library from which the manufacturer
can assemble (model) its individual products. The elements are designed so that with them
the entire range of products (from residential to commercial and industrial applications) can
be covered. The choice of the subset of interface classes used to build a meter, their
instantiation and their implementation are part of the product design and therefore left to the
manufacturer. The concept of the standardized metering interface class library provides the
different users and manufacturers with a maximum of diversity without having to sacrifice
interoperability.
62056-62  IEC:2002(E) – 7 –
ELECTRICITY METERING – DATA EXCHANGE

FOR METER READING, TARIFF AND LOAD CONTROL –

Part 62: Interface classes
1 Scope
This part of IEC 62056 specifies a model of a meter as it is seen through its communication
interface(s). Generic building blocks are defined using object oriented methods, in the form of
interface classes to model meters from simple up to very complex functionality.
2 Normative references
The following normative documents contain provisions which, through reference in this text,
constitute provisions of this part of IEC 62056. For dated references, subsequent amend-
ments to, or revisions of, any of these publications do not apply. However, parties to
agreements based on this part of IEC 62056 are encouraged to investigate the possibility of
applying the most recent editions of the normative documents indicated below. For undated
references, the latest edition of the normative document referred to applies. Members of IEC
and ISO maintain registers of currently valid International Standards.
IEC 60050-300:2001, International Electrotrechnical Vocabulary – Electrical and electronic
measurements and measuring instruments – Chapter 311: General terms relating to
measurements – Chapter 312: General terms relating to electrical measurements – Chapter
313: Types of electrical measuring instruments – Chapter 314: Specific terms according to the
type of instrument
IEC 61334-4-41:1996, Distribution automation using distribution line carrier systems – Part 4:
Data communication protocols – Section 41: Application protocols – Distribution line message
specification
IEC 62051:1999, Electricity metering – Glossary of terms
IEC 62056-21, Data exchange for meter reading, tariff and load control – Part 21: Direct local
data exchange
IEC 62056-31:1999, Electricity metering – Data exchange for meter reading, tariff and load
control – Part 31: Using local area networks on twisted pair with carrier signalling

IEC 62056-46:2001, Electricity metering – Data exchange for meter reading, tariff and load
control – Part 46: Data link layer using HDLC-protocol
IEC 62056-53:2001, Electricity metering – Data exchange for meter reading, tariff and load
control – Part 53: COSEM Application layer
IEC 62056-61:2001, Electricity metering – Data exchange for meter reading, tariff and load
control – Part 61: OBIS Object identification system
ANSI C12.19:1997 / IEEE 1377:1997, Utility Industry End Device Data Tables
———————
To be published.
– 8 – 62056-62  IEC:2002(E)
3 Terms, definitions and abbreviations

3.1 Terms and definitions
For the purpose of this part of IEC 62056 the terms and definitions given in IEC 60050-300

and IEC 62051, as well as the following apply.

3.1.1
base_name
the short_name corresponding to the first attribute (“logical_name”) of a COSEM object

3.1.2
class_id
class identification code
3.1.3
COSEM object
an instance of an interface class
3.2 Abbreviations
AARE Application Association Response
AARQ Application Association ReQuest
ACSE Application Control Service Element
APDU Application Protocol Data Unit
ASE Application Service Element
A-XDR Adapted eXtended Data Representation
COSEM Companion Specification for Energy Metering
DLMS Distribution Line Message Specification
GMT Greenwich Mean Time
HLS High-level Security
IC Interface Class
LLS Low Level Security
LN Logical Name
LSB Least Significant Bit
M Mandatory
MSB Most Significant Bit
O Optional
OBIS OBject Identification System
PDU Protocol Data Unit
SAP Service Access Point
SN Short Name
62056-62  IEC:2002(E) – 9 –
4 Basic principles
4.1 General
This subclause describes the basic principles on which the COSEM interface classes are

built. It also gives a short overview on how interface objects (instantiations of the interface

classes) are used for communication purposes. Meters, support tools and other system
components that follow these specifications can communicate with each other in an
interoperable way.
Object modelling: for specification purposes this standard uses the technique of object
modelling. An object is a collection of attributes and methods.
The information of an object is organized in attributes. They represent the characteristics of
an object by means of attribute values. The value of an attribute may affect the behaviour of
an object. The first attribute in any object is the “logical_name”. It is one part of the
identification of the object.
An object offers a number of methods to either examine or modify the values of the attributes.
Objects that share common characteristics are generalized as an interface class with a
class_id. Within a specific class the common characteristics (attributes and methods) are
described once for all objects. Instantiations of an interface class are called COSEM objects.
Manufacturers may add proprietary methods or attributes to any object, using negative
numbers.
Figure 1 illustrates these terms by means of an example:
Methods
Class Object      Attribute Values

Attributes  Insta ntiation
class identifier
Total Positive
Register  cla ss_id=3
Active Energy: Register
logical_name: octet-string
logical_name = [1 1 1 8 0 255]
value: instance specific
... value = 1483
reset
Total Positive
Reactive Energy: Register
logical_name = [1 1 3 8 0 255]
value = 57
IEC  305/02
Figure 1 – An interface class and its instances
The interface class “register” is formed by combining the features necessary to model the
behaviour of a generic register (containing measured or static information) as seen from the
client (central unit, hand held terminal). The contents of the register are identified by the
attribute “logical_name”. The logical_name contains an OBIS identifier (see IEC 62056-61).
The actual (dynamic) content of the register is carried by its “value” attribute.

– 10 – 62056-62  IEC:2002(E)
Defining a specific meter means defining several specific registers. In the example of Figure 1

the meter contains two registers; i.e. two specific COSEM objects of the class “register” are

instantiated. This means that specific values are assigned to the different attributes. Through

the instantiation one COSEM object becomes a “total, positive, active energy register”

whereas the other becomes a “total, positive, reactive energy register”.

REMARK The COSEM objects (instances of interface classes) represent the behaviour of the meter as seen from

the “outside”. Therefore, modifying the value of an attribute must always be initiated from the outside (e.g.

resetting the value of a register). Internally initiated changes of the attributes are not described in this model
(e.g. updating the value of a register).

4.2 Class description notation

This subclause describes the notation used to define the interface classes.
A short text describes the functionality and application of the class. A table gives an overview
of the class including the class name, the attributes and the methods (class description
template):
Class name Cardinality class_id, version
Attribute(s) Data type Min. Max. Def
1. logical_name (static) octet-string
2. …. (.) ….
3. …… (.) ….
Specific method(s) (if required) m/o
1. …. ….
2. …. ….
Each attribute and method must be described in detail.
Class name Describes the class (e.g. register, clock, profile, .)
Cardinality Specifies the number of instances of the class within a logical device (see
4.5).
value The class shall be instantiated exactly “value”
times.
min.max.
The class shall be instantiated at least “min.” times
and at most “max.” times. If min. is zero (0) then the
class is optional, otherwise (min. > 0) "min."
instantiations of the class are mandatory.
class_id Identification code of the class (range 0 to 65 535). The class_id can be
obtained from an “association” object. The class_id's from 0 to 8 191 are
reserved to be specified by the DLMS UA. Class_id's from 8 192 to 32 767

are reserved for manufacturer specific interface classes. Class_id's from
32 768 to 65 535 are reserved for user group specific interface classes.
DLMS UA reserves the right to assign ranges to individual manufacturers
or user groups.
Version Identification code of the version of the class. The version can be obtained
from an “association” object.
Within one logical device all instances of a certain class must be of
the same version.
62056-62  IEC:2002(E) – 11 –
Attribute(s) Specifies the attribute(s) that belong to the class.

(dyn.) Classifies an attribute that carries a process value,

which is updated by the meter itself.

(static) Classifies an attribute which is not updated by the
meter itself (e.g. configuration data).
logical_name octet-string The logical name is always the first attribute of a class.
It identifies the instantiation (COSEM object) of this

class. The value of the logical_name conforms to

OBIS (see IEC 62056-61).
Data type Defines the data type of an attribute (see 4.3).
Min. Specifies if the attribute has a minimum value.
x The attribute has a minimum value.
The attribute has no minimal value.
Max.
Defines if the attribute has a maximum value.
x
The attribute has a maximum value.
The attribute has no maximum value.
Def Specifies if the attribute has a default value. This is the value of the
attribute after reset.
x The attribute has a default value.
The default value is not defined by the class definition.
.
Specific Provides a list of the specific methods that belong to the object
method(s)
Method Name () The method has to be described in the subsection
"Method description".
m / o Defines if the method is mandatory or optional.
m (mandatory) The method is mandatory.
o (optional) The method is optional.
Attribute description
Describes each attribute with its data type (if the data type is not simple), its data formats and

its properties (minimum value, maximum value and default value).
Method description
Describes each method and the invoked behaviour of the instantiated COSEM object(s).
NOTE Services for accessing attributes or methods by the protocol are described in IEC 62056-53.
Selective access
The common methods READ/WRITE and GET/SET typically reference the entire attribute
addressed. However, for certain attributes selective access to just part of the attribute may be
provided. The part of the attribute is identified by specific selective access parameters. These
selective access parameters are defined as part of the attribute specification.

– 12 – 62056-62  IEC:2002(E)
4.3 Common data types
The following list contains some data types common to all interface classes.

Simple data types Data types carrying one data item only

integer, long, double- Simple data types as defined in IEC 61334-4-41, clause A.12,

long, unsigned, long- Data
unsigned, double-long- Examples:

unsigned, boolean integer Integer8 1 byte
long Integer16 2 bytes
double-long Integer32 4 bytes
enum The elements of the enumeration type need to be defined in the
subsection “Attribute description”.
Any not listed value for an enumeration is reserved by default.
real32, real64 Real data types according to the REAL specification of
IEC 61334-4-41.
visible-string, octet-string An ordered sequence of ASCII-characters respectively octets
(8-bit bytes).
bit-string An ordered sequence of boolean values.
Complex data types More than one data item is included, or the data item itself
is not simple.
array The array elements need to be defined in the subsection
“Attribute description”.
compact array The array elements need to be defined in the subsection
“Attribute description”.
structure The structure type needs to be defined in the subsection
“Attribute description”.
instance specific The data type of the attribute needs to be specified in the
instantiation of the object for a particular meter (instance
model).
4.4 Data formats for date and time notation
Date and time notations are normally using octet-string as data type, but the formatting of the
data is defined precisely.
date octet-string{ year highbyte, year lowbyte, month, day of month,
day of week }
year: interpreted as unsigned16
range 0.big
0xFFFF = not specified
year highbyte and year lowbyte reference the 2 bytes of the
unsigned 16
month: interpreted as unsigned8
range 1.12, 0xFD,0xFE,0xFF
1 is January
0xFD= daylight_savings_end
0xFE= daylight_savings_begin
0xFF = not specified
dayOfMonth: interpreted as unsigned8
range 1.31, 0xFD, 0xFE, 0xFF
nd
0xFD = 2 last day of month
0xFE = last day of month
0xE0 to 0xFC = reserved
0xFF = not specified
62056-62  IEC:2002(E) – 13 –
dayOfWeek: interpreted as unsigned8

range 1.7, 0xFF
1 is Monday
0xFF = not specified
For repetitive dates the unused parts must be set to “not

specified”.
time octet-string {hour, minute, second, hundredths}

hour: interpreted as unsigned8

range 0.23, 0xFF
0xFF = not specified
minute:interpreted as unsigned8
range 0.59, 0xFF
0xFF = not specified
second: interpreted as unsigned8
range 0.59, 0xFF
0xFF = not specified
hundredths: interpreted as unsigned8
range 0.99, 0xFF
0xFF = not specified}
For repetitive times the unused parts must be set to “not
specified”.
deviation Integer16 –720.720:
in minutes of local time to GMT
0x8000 = not specified
clock_status Unsigned8 interpreted as 8 bit string
The status bits are defined as follows:
a
bit 0 (LSB): invalid value
b
bit 1: doubtful value
c
bit 2: different clock base
d
bit 3: invalid clock status
bit 4: reserved
bit 5: reserved
bit 6: reserved
e
bit 7 (MSB): daylight saving active
date_time octet-string
{
year highbyte
year lowbyte
month
day of month
day of week
hour
minute
second
hundredths of second
deviation highbyte
deviation lowbyte
clock status
}
Individual fields of date_time are encoded as defined above.
Some may be set to “not specified“ as described above in date
and time.
– 14 – 62056-62  IEC:2002(E)
a
Time could not be recovered after an incident. Detailed conditions are manufacturer specific (e.g. after the

power to the clock has been interrupted).

b
Time could be recovered after an incident but the value cannot be guaranteed. Detailed conditions are
manufacturer specific.
c
Bit is set if the basic timing information for the clock is at the actual moment taken from a timing source
different from the source specified in clock_base.

d
This bit indicates that at least one bit of the clock status is invalid. Some bits may be correct. The exact

meaning shall be explained in the manufacturer’s documentation.

e
Flag set to true: the transmitted time contains the daylight saving deviation (summer time), Flag set to false:

the transmitted time does not contain daylight saving deviation (normal time).

4.5 The COSEM server model
The COSEM server is structured into three hierarchical levels as shown in Figure 2:
Level 1: Physical device
Level 2: Logical device
Level 3: Accessible COSEM objects
COSEM physical device A
COSEM
COSEM Logical device 2
Management logical
device
COSEM Objects
COSEM Objects
IEC  306/02
Figure 2 – The COSEM server model
The following example (see Figure 3) shows how a combined metering device can be
structured using the COSEM server model.
Physical device
Combined metering device
Management logical Logical device 2 Logical device 3
Logical device
device
LDN
LDN
LDN
Register
Register
Register
Objects
“total energy”
“total volume”
“total volume”
Register “tariff 1”
LDN: COSEM logical
device name object A
A
A
A: Association object
IEC  307/02
Figure 3 – Combined metering device

62056-62  IEC:2002(E) – 15 –
4.6 COSEM logical device
4.6.1 General
The COSEM logical device is a set of COSEM objects. Each physical device shall contain a
“management logical device”
The addressing of COSEM logical devices shall be provided by the addressing scheme of the
lower layers of the protocol used.

4.6.2 COSEM logical device name

The COSEM logical device can be identified by its unique COSEM logical device name. This
name can be retrieved from an instance of IC “SAP assignment” (see 5.14), or of a COSEM
object “COSEM logical device name” (see D.1.1.17).
This name is defined as an octet-string of up to 16 octets. The first three octets uniquely
identify the manufacturer of the device . The manufacturer is responsible for guaranteeing the
uniqueness of the octets that follow (up to 13 octets).
4.6.3 The “association view” of the logical device
In order to access COSEM objects in the server, an application association shall first be
established. This characterizes the context within which the associated applications will
communicate. The major parts of this context are
• information on the application context;
• information on the COSEM context;
• information on the authentication mechanism used;
• etc.
This information is contained in a special COSEM object, the “association” object. There are
two types of this association object defined. One for associations using short name
referencing (association SN) and one for using logical name referencing (association LN).
Depending on the association established between the client and the server different access
rights may be granted by the server. Access rights concern a set of COSEM objects – the
visible objects – which can be accessed (‘seen’) within the given association. In addition,
access to attributes and methods of these COSEM objects may also be restricted within the
association (e.g. a certain type of client can only read a particular attribute of a COSEM object).
The list of the visible COSEM objects – the “association view” – can be obtained by the client
by reading the “object_list” attribute of the appropriate association object. Additional
information about the access rights (read only, write only, read and write) to the attributes and
the availability of the methods (within the established association) can be found via specific
attributes (Logical name referencing, see 5.12) or special methods (Short name referencing,
see 5.13) provided by the association objects.
4.6.4 Mandatory contents of a COSEM logical device
The following objects shall be part of each COSEM logical device. They shall be accessible
for GET/READ in all application associations with this logical device:
– COSEM logical device name object
– current association (LN or SN) object.
———————
Administered by the DLMS User Association

– 16 – 62056-62  IEC:2002(E)
4.7 Authentication procedures
4.7.1 Low level security (LLS) authentication

As described in IEC 62056-53 the ACSE provides the authentication services for low level
security (LLS). Low level security authentication is typically used when the communication

channel offers adequate security to avoid eavesdropping and message (password) replay.

For LLS all the authentication services are provided by the ACSE. The association objects

provide only the method/attribute (see 5.12, 5.13) to change the “secret” (e.g. password).

For LLS authentication the client transmits a “secret” (e.g. a password) to the server, by using

the “Calling_Authentication_Value” parameter of the COSEM-OPEN.request service primitive
of the client application layer. The server checks if the received “secret” corresponds to the
client identification. If yes, the client is authenticated and the association can be established.
4.7.2 High-level security (HLS) authentication
As described in IEC 62056-53 the ACSE provides part of the authentication services for high-
level security (HLS). High-level security authentication is typically used when the
communication channel offers no intrinsic security and precautions have to be taken against
eavesdroppers and against message (password) replay. In this case, a 4-pass authentication
protocol is foreseen. The 4-pass authentication allows the authentication of the client as well
as of the server in the following way.
Pass1: The client transmits “challenge” CtoS (e.g. a random number) to the server.
Pass2: The server transmits “challenge” StoC (e.g. a random number) to the client.
Pass3: The client processes StoC in a secret way (e.g. encrypting with a secret key). The result
– f(StoC) – is sent back to the server. The server checks if f(StoC) is the result of
correct processing and – if correct – the server accepts the authentication of the
client.
Pass4: If the client is authenticated, the server processes CtoS in a secret way (e.g.
encrypting with a secret key). The result – f(CtoS) – is sent back to the client. The
client checks if f(CtoS) is the result of the correct processing and – if correct – the
client accepts the authentication of the server.
The HLS authentication service, supporting Pass1 is provided by the COSEM-OPEN.request
service primitive of the client application layer. The parameter "Security_Mechanism_Name"
carries the identifier of the HLS mechanism, and the parameter "Calling_Authen-
tication_Value" carries the challenge CtoS.
The HLS authentication service, supporting Pass2 is provided by the COSEM-OPEN.response
service primitive of the server application layer. The parameter "Security_Mechanism_Name"

carries the identifier of the HLS mechanism, and the parameter "Responding_
Authentication_Value" carries the challenge StoC.
After Pass2, the association is formally established, but the access of the client is restricted
to the method "reply_to_HLS_authentication" of the current "association" object.
Pass3 and Pass4 are supported by the method reply_to HLS_authentication of the
association object(s), (see 5.12, 5.13). If both passes are successfully executed, then full
access is granted according to the current association. Otherwise, either the client or the
server aborts the association.
In addition, the association object provides the method to change the HLS “secret” (e.g. the
encryption key): change_HLS_secret.
REMARK  After the client has issued the change_HLS_secret() (or change_LLS_secret() ) method it expects a
response from the server acknowledging that the secret has been changed. It is possible that the server transmits
the acknowledgement, but due to communication problems the acknowledgement is not received at the client-side.
Therefore, the client does not know if the secret has been changed or not. For simplicity reasons, the server does
not offer any special support for this case; i.e. it is left to the client to cope with this situation.

62056-62  IEC:2002(E) – 17 –
5 The interface classes
Base
The currently defined interface classes for

Data
meters and the relations between them are

illustrated in Figure 4. Register

Extended register
NOTE 1 The interface class “base” itself is not specified
Demand register
explicitly. It contains only one attribute "logical_name".

NOTE 2 In the description of the "demand register",
nd Clock
“clock” and “profile generic” interface classes, the 2

nd
attributes are labelled differently from that of the 2

Profile generic
attribute of the “data” interface class, namely
"current_average_value", “time” and “buffer” vs. “value”.
This is to emphasize the specific nature of the “value”. Association LN
Association SN
Register activation
Script table
Schedule
SAP assignment
IEC local port setup
Activity calendar
Register monitor
Special days table
Single action schedule
PSTN modem config.
PSTN auto answer
PSTN auto dial
IEC HDLC setup
IEC twisted pair (1) setup
Utility tables
IEC  308/02
Figure 4 – Overview of the interface classes
5.1 Data (class_id: 1)
A data object stores data related to internal meter object(s). The meaning of the value is
identified by the logical_name. The data type of the value is instance specific. Data is typically
used to store configuration data and parameters.

– 18 – 62056-62  IEC:2002(E)
Data 0.n class_id = 1, version = 0

Attribute(s) Data type Min. Max. Def

1. logical_name (static) octet-string

2. value instance specific
Specific method(s) m/o
Attribute description
logical_name Identifies the data contained in value. Identifiers are specified in

clause D.1 and in IEC 62056-61.

value
Contains the data.
instance specific The data type of the value depends on
the instantiation defined by
“logical_name”.
5.2 Register (class_id: 3)
A register object stores a process value or a status value with its associated unit. The register
object knows the nature of the process value or of the status value. The nature of the value is
described by the attribute “logical name” using the OBIS identification system (see clause D.1
and in IEC 62056-61).
Register 0.n class_id = 3, version = 0
Attribute(s) Data type Min. Max. Def
1. logical_name (static) octet-string
2. value (dyn.) instance specific
3. scaler_unit (static) scal_unit_type
Specific method(s) m/o
1. reset o
Attribute description
value Contains the current process or status value.
instance specific The data type of the value depends on
the instantiation defined by
“logical_name” and possibly from the
manufacturer. Therefore, this attribute
must provide the value and the data
type when it is accessed by a client.

The type has to be chosen so that,
together with the logical_name, an
unambiguous interpretation of the
value is possible.
scaler_unit
Provides information on the unit and the scaler of the value.
If the value uses a complex data type, the scaler and unit apply to all
elements.
scal_unit_type:
structure { scaler, unit }
scaler: integer This is the exponent (to the base of
10) of the multiplication factor
REMARK If the value is not numerical then
the scaler shall be set to 0.
unit: enum
Enumeration defining the physical unit;
for details see below.
62056-62  IEC:2002(E) – 19 –
Method description
reset (data)
This method forces a reset of the object. By invoking this method

the value is set to the default value. The default value is an

instance specific constant.
data ::= integer(0)
unit ::= enum
Code // Unit Quantity Unit SI definition
(1) a // time year
(2) mo // time month
(3) wk // time week 7*24*60*60 s

(4) d // time day 24*60*60 s
(5) h // time hour 60*60 s
(6) min. // time minute 60 s
(7) s // time (t) second s
(8) ° // (phase) angle degree
rad*180/π
(9) °C // degree K-273.15
temperature (Θ)
centigrade
(10) currency // (local) currency
(11) m // length (l) meter m
(12) m/s // speed (v)
...