DLMS Blue Book 4Th Edition Internet

TECHNICAL REPORT
Companion Specification
for Energy Metering
COSEM
Identification System
and Interface Objects
DLMS User Association
device ä
language
message
specification
Reference number: DLMS UA 1000-1:2001, Fourth Edition

© Copyright 1997-2001 DLMS User Association
DLMS User Association, COSEM Identification System and Interface Objects, Fourth Edition
DLMS User Association DLMS UA 1000-1 ed.4 2/97

Table of Contents
1. Foreword.............................................................................................................................. 6
2. Scope ................................................................................................................................... 7
3. Introduction ......................................................................................................................... 8
3.1 Referenced Documents....................................................................................................... 8
3.2 Terms, Definitions and Abbreviations .................................................................................. 9
3.3 Revision History .................................................................................................................. 9
4. COSEM Interface Classes ................................................................................................. 10

4.1 Basic Principles................................................................................................................. 10
4.1.1 Introduction ..................................................................................................................... 10
4.1.2 Class Description Notation.............................................................................................. 11
4.1.3 Common Data Types ...................................................................................................... 12
4.1.4 Data formats for date and time notation.......................................................................... 13
4.1.5 The COSEM server model .............................................................................................. 15
4.1.6 COSEM Logical Device................................................................................................... 16
4.1.6.1 General......................................................................................................................... 16
4.1.6.2 COSEM Logical Device Name ...................................................................................... 16
4.1.6.3 The "Association View" of the Logical Device ............................................................... 16
4.1.6.4 Mandatory Contents of a COSEM Logical Device......................................................... 16
4.1.7 Authentication Procedures .............................................................................................. 17
4.1.7.1 Low Level Security (LLS) Authentication....................................................................... 17
4.1.7.2 High Level Security (HLS) Authentication ..................................................................... 17
4.2 The interface classes ........................................................................................................ 18
4.2.1 Data (class_id: 1) ............................................................................................................ 19
4.2.2 Register (class_id: 3) ...................................................................................................... 19
4.2.3 Extended Register (class_id: 4) ...................................................................................... 21
4.2.4 Demand Register (class_id: 5)........................................................................................ 22
4.2.5 Register Activation (class_id: 6) ...................................................................................... 24
4.2.6 Profile Generic (class_id: 7) ............................................................................................ 26
4.2.7 Clock (class_id: 8)........................................................................................................... 29
4.2.8 Script Table (class_id: 9) ................................................................................................ 32
4.2.9 Schedule (class_id: 10)................................................................................................... 33
4.2.10 Special Days Table (class_id: 11) ................................................................................... 36
4.2.11 Activity Calendar (class_id: 20) ....................................................................................... 37
4.2.12 Association LN (class_id: 15) .......................................................................................... 39
4.2.13 Association SN (class_id: 12) ......................................................................................... 43
4.2.14 SAP Assignment (class_id: 17) ....................................................................................... 45
4.2.15 Register Monitor (class_id: 21) ....................................................................................... 45
4.2.16 Utility Tables (class_id: 26) ............................................................................................. 46
4.2.17 Single Action Schedule (class_id: 22) ............................................................................. 47
4.3 Maintenance of the Interface Classes ............................................................................... 48
4.3.1 New Interface Classes .................................................................................................... 48
4.3.2 New Versions of Interface Classes ................................................................................. 49
4.3.3 Removal of Interface Classes ......................................................................................... 49
4.4 Protocol related Interface Classes..................................................................................... 49
4.4.1 IEC Local Port Setup (class_id: 19) ................................................................................ 49
4.4.2 PSTN Modem Configuration (class_id: 27) ..................................................................... 50
4.4.3 PSTN Auto Answer (class_id: 28) ................................................................................... 52

4.4.4 PSTN Auto Dial (class_id: 29)......................................................................................... 53

4.4.5 IEC HDLC Setup (class_id: 23)....................................................................................... 54
4.4.6 IEC Twisted Pair (1) Setup (class_id: 24)........................................................................ 55
4.5 Using Short Names for accessing attributes and methods ............................................... 56
4.5.1 Guidelines for Assigning Short Names............................................................................ 56
4.5.2 Reserved base_names for Special COSEM Objects....................................................... 61
4.6 Relation to OBIS ............................................................................................................... 62
4.6.1 Mapping of Data Items to COSEM Objects and Attributes .............................................. 62
4.6.1.1 Abstract COSEM Objects ............................................................................................. 62
4.6.1.2 Electrical Energy related COSEM Objects .................................................................... 69
4.6.2 Coding of OBIS Identifications ........................................................................................ 74
4.7 Previous Versions of Interface Classes ............................................................................. 75
4.7.1 Profile Generic, version 0................................................................................................ 75
4.7.2 Association SN, version 0 ............................................................................................... 78
5. COSEM Object Identification System (OBIS)................................................................... 80

5.1 Introduction ....................................................................................................................... 80
5.2 Scope................................................................................................................................ 80
5.3 OBIS Object identification system structure ...................................................................... 80
5.3.1 Value group A ................................................................................................................. 81
5.3.2 Value group B ................................................................................................................. 81
5.3.3 Value group C ................................................................................................................. 81
5.3.4 Value group D ................................................................................................................. 81
5.3.5 Value group E ................................................................................................................. 81
5.3.6 Value group F ................................................................................................................. 81
5.3.7 Manufacturer specific codes ........................................................................................... 81
5.4 Value group definitions...................................................................................................... 81
5.4.1 Value group A ................................................................................................................. 81
5.4.2 Value group B ................................................................................................................. 82
5.4.3 Value group C ................................................................................................................. 82
5.4.3.1 Abstract objects ............................................................................................................ 82
5.4.3.2 Quantities for electrical energy related objects ............................................................. 83
5.4.4 Value group D ................................................................................................................. 84
5.4.4.1 Electricity related objects .............................................................................................. 84
5.4.4.2 Value group D for country specific identifiers ................................................................ 86
5.4.5 Value group E ................................................................................................................. 87
5.4.5.1 Usage of value group E for current and voltage measurements ................................... 87
5.4.5.2 Usage of value group E for measuring angles .............................................................. 88
5.4.6 Value group F ................................................................................................................. 88
5.4.6.1 Usage of value group F for billing periods..................................................................... 88
5.4.7 Abstract objects .............................................................................................................. 89
5.4.8 Electricity-related General purpose objects..................................................................... 90
5.4.9 List objects...................................................................................................................... 91
5.4.10 Electricity data profile objects.......................................................................................... 92
5.5 Code presentation ............................................................................................................. 92
5.5.1 Reduced ID codes (e.g. for IEC 62056-21) ..................................................................... 92
5.5.2 Display ............................................................................................................................ 93
5.5.3 Special handling of value group F ................................................................................... 93
5.5.4 COSEM........................................................................................................................... 94
Bibliography................................................................................................................................ 95
Index ............................................................................................................................................ 96

Figures
Figure 1 – The three steps approach of COSEM: Modelling - Messaging - Transporting ................................. 7
Figure 2 – An interface class and its instances................................................................................................ 10
Figure 3 – The COSEM server model.............................................................................................................. 15
Figure 4 – Combined metering device ............................................................................................................. 15
Figure 5 – Overview of the interface classes ................................................................................................... 18
Figure 6 – The attributes when measuring sliding demand ............................................................................. 22
Figure 7 – The attributes when measuring current_average_value if number of periods is 1 ......................... 22
Figure 8 – The attributes if number of periods is 3 .......................................................................................... 23
Figure 9 – The generalised time concept......................................................................................................... 30
Figure 10 – OBIS code structure ..................................................................................................................... 81
Figure 11 – Quadrants for power measurement.............................................................................................. 84
Figure 12 – Reduced ID code presentation ..................................................................................................... 93
Tables
Table 1 – Class description template............................................................................................................... 11
Table 2 – Example of values and units ............................................................................................................ 21
Table 3 – Schedule .......................................................................................................................................... 33
Table 4 – Special Days Table .......................................................................................................................... 33
Table 5 – Reserved base_names for Special COSEM Objects ...................................................................... 62
Table 6 – Value group A codes........................................................................................................................ 82
Table 7 – Value group B codes........................................................................................................................ 82
Table 8 – Value group C codes (abstract objects)........................................................................................... 82
Table 9 – Value group C codes (electricity objects)......................................................................................... 83
Table 10 –Value group D codes (electricity) .................................................................................................... 84
Table 11 – Value group D codes (country specific) ......................................................................................... 86
Table 12 – Value group E codes (electricity) ................................................................................................... 87
Table 13 – Extended current/voltage measurement........................................................................................ 88
Table 14 – Extended angle measurement ....................................................................................................... 88
Table 15 – Abstract object codes..................................................................................................................... 89
Table 16 – General error messages ................................................................................................................ 90
Table 17 – General purpose codes (electricity) ............................................................................................... 90
Table 18 – General list objects ........................................................................................................................ 92
Table 19 – Profile codes (electricity) ................................................................................................................ 92
Table 20 – Example of display code replacement ........................................................................................... 93
Table 21 – Values of billing periods ................................................................................................................. 93

1. Foreword
Copyright
© Copyright 1997-2001 DLMS User Association.
This document is confidential. It may not be copied, nor handed over to persons outside the stan-
dardisation environment.
The copyright is enforced by national and international law. The "Berne Convention for the Protec-
tion of Literary and Artistic Works", which is signed by 121 countries world-wide, and other trea-
ties apply.
Acknowledgement
The actual document has been established by a team of experts working for the meter manufac-
turers DZG, Enermet, Schlumberger and Siemens, with input from other members of the DLMS
User Association and from working group members of standardisation bodies, e.g. IEC TC13
WG14 and CEN TC294 WG2.
Status of standardisation
The actual edition 4 of this document combines the contents of draft IEC 62056-62 (Interface Ob-
jects) and draft IEC 62056-61 (OBIS Object Identification System) submitted to IEC for FDIS cir-
culation.

2. Scope
This document specifies the functionality
of the meter which is available at its in- 1. Modelling COSEM Interface Objects
terface (internal issues concerning the
implementation are not covered by the n
io
specification) and how the functions and
i at
c
soVersion=0
the data can be accessed from the out- Register 0..n
s
Class_id=3,
rA
side. The complex functionality of the Attribute(s) Data Type Min Max Def
instance specific e
1. logical_name (static) octet-string
Us
meter is divided into generic building 2. value
3. scaler-unit
(dyn.)
(static) scal_unit_type
blocks. The COSEM specifications follow S
M
Method(s) m/o
DL
1. reset o
a three step approach as illustrated in
Figure 1:
Step 1:The meter model and data identi-

Protocol Services to access
fication (data model);
attributes and methods
Step 2:The mapping of the model into
2. Messaging Communication Protocol
protocol data units (pdu);
Step 3:The transportation of the bits and Messages :

bytes through the communication chan- Service_Id( Class_Id, Instance_Id, Attribute_Id/Method_Id )
nel.
Encoding: ( APDU )
The data model uses generic building C0 01 00 03 01 01 01 08 00 FF 02
blocks to define the complex functionality
of the metering equipment. It provides a .. .
EC,
view of this functionality of the meter, as I
O,
3. Transporting
it is available at its interface(s). The
IS
model does not cover internal, imple-
mentation specific issues. The communi-
cation protocol defines how the data can
be accessed and exchanged.
Figure 1 –
The three steps approach of COSEM:
Modelling - Messaging - Transporting
• The COSEM specification specifies metering domain specific interface classes. The
functionality of the meter is defined by the instances of these interface classes, called
COSEM objects. This is defined in the first part of this document. Logical names (OBIS
codes), identifying the COSEM objects are defined in the second part of this document.
• The attributes and methods of these COSEM objects can be accessed and used via the
messaging services of the Application layer.
• The lower layers of the protocol transport the information.

3. Introduction
Driven by the need of the utilities to optimise 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, nowa-
days the critical issues are system integration and interoperability.
The Companion Specification for Energy Metering (COSEM) addresses these challenges by look-
ing 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 ob-
jects). The specification of these objects forms a major part of COSEM.
The COSEM server model (comp. chapter 4.1.5) represents only the externally visible elements of
the meter. The client applications that support the business processes of the utilities, of the cus-
tomers 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 (see chapter 4) form a standardised library from which the
manufacturer can assemble (model) its individual products. The elements are designed such 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 instan-
tiation and their implementation are part of the product design and therefore left to the manufac-
turer. The concept of the standardised metering interface class library provides the different users
and manufacturers with a maximum of diversity without having to sacrifice interoperability.
The competitive energy markets require an ever-increasing amount of timely information concern-
ing the usage of electrical energy. Recent technology developments enable to build intelligent
static metering equipment, which are capable to capture, process and communicate this informa-
tion to all parties involved.
For further analysis of this information, for the purposes of billing, load-, customer- and contract
management, it is necessary to uniquely identify all data in a manufacturer independent way col-
lected manually or automatically, via local or remote data exchange.
The OBIS definition of Identification codes (see chapter 5) was based on:
draft DIN 43863-3 (December 1997), Electricity meters - Part 3: Tariff metering device as additional equip-
ment for electricity meters - EDIS - Energy Data Identification System
3.1 Referenced Documents

Ref. Title
DLMS UA 1000-2 COSEM Three Layer Connection Oriented Architecture, Second Edition (2001)
IEC 61268:1995 Alternating current static var-hour meters for reactive energy (classes 2 and 3)
IEC 61334-4-41:1996 Distribution automation using distribution line carrier systems - Part 4: Data com-
munication protocols - Section 41: Application protocols - Distribution line message
specification

Ref. Title
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 Electricity metering – Data exchange for meter reading, tariff and load control – Part
46 – Data link layer using HDLC-protocol
53- COSEM Application layer
61- OBIS Object Identification System
IEC 62056-62 Data exchange for meter reading, tariff and load control – Part 62: Interface
Classes
ANSI C12.19:1997 IEEE 1377:1998, Utility industry end device data tables
3.2 Terms, Definitions and Abbreviations

Abbreviation Explanation
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
base_name The short_name corresponding to the first attribute (“logical_name”)of a COSEM object..
Class_id Class identification code
COSEM Companion Specification for Energy Metering
COSEM object An instance of an interface class
DLMS Distribution Line Message Specification
GMT Greenwich Mean Time
HLS High Level Security
IC Interface Class
IEC International Electrotechnical Commission
LLS Low Level Security
LSB Least significant bit
m mandatory, used in conjunction with attribute and method definitions
MSB Most significant bit
o optional, used in conjunction with attribute and method definitions
OBIS Object Identification System
PDU Protocol data unit
UTC Universal Time Co-ordinated
3.3 Revision History

Version Date Author Comment
Release 1 01 April 1998 DLMS -UA initial version
First Edition 12 Nov. 1998 DLMS -UA considering comments received after R1
Second Edition 03 May 1999 DLMS -UA major rework, classes and associations added
Third Edition 29 Feb. 2000 DLMS -UA major rework, adapted to CDVs of IEC TC13, OBIS added
Fourth Edition 25 March 2001 DLMS -UA considering comments to CDVs by IEC National Committees

4. COSEM Interface Classes
4.1 Basic Principles
4.1.1 Introduction
This section 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 document uses the technique of object modelling.
An object is a collection of attributes and methods.
The information of an object is organised 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 ob-
ject. 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 generalised 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 2 illustrates these terms by means of an example:

Class Methods Object Attribute Values
class identifier Attributes Instantiation
Register class_id=3 Total Positive

Active Energy: Register
logical_name: octet-string
value: instance specific logical_name = [1 1 1 8 0]
... value= 1483
…
reset
Total Positive
Reactive Energy: Register
logical_name = [1 1 3 8 0]
value = 57
…
Figure 2 – An interface class and its instances

The interface class "Register" is formed by combining the features necessary to model the be-
haviour 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 "logi-
cal_name". The logical_name contains an OBIS identifier (see Clause 5 or IEC 62056-61). The
actual (dynamic) content of the register is carried by its "value" attribute.
Defining a specific meter means defining several specific registers. In the example of Figure 2 the
meter contains 2 registers; i.e. two specific COSEM objects of the class "Register" are instanti-
ated. This means that specific values are assigned to the different attributes. Through the instan-
tiation 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.1.2 Class Description Notation

This section 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.
Table 1 – Class description template
Class name Cardinality class_id, Version
Attribute(s) Data Type Min. Max. Def
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.1.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.
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 Clause 5
or IEC 62056-61).
Data Type Defines the data type of an attribute (see 4.1.3).
Min. Specifies if the attribute has a minimum value.
x The attribute has a minimum value.
<empty> The attribute has no minimal value.

Max. Defines if the attribute has a maximum value.
x The attribute has a maximum value.
<empty> 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.
<empty> 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 DLMS UA 1000-2 or IEC 62056-53.
Selective Access
The common methods READ/WRITE and GET/SET typically reference the entire attribute ad-
dressed. However, for certain attributes selective access to just part of the attribute may be pro-
vided. The part of the attribute is identified by specific selective access parameters. These selec-
tive access parameters are defined as part of the attribute specification.
4.1.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-long, Simple data types as defined in IEC 61334-4-41:1996 (A.12, Data).
unsigned, long-unsigned, Examples:
double-long-unsigned, integer Integer8 1 byte
boolean long Integer16 2 bytes
double-long Integer32 4 bytes
enum The elements of the enumeration type need to be defined in the sub-
section “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:1996.
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 sub-section “Attribute
Description”.
compact array The array elements need to be defined in the sub-section “Attribute
Description”.
structure The structure type needs to be defined in the sub-section “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.1.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

dayOfWeek: interpreted as unsigned8

range 1..7, 0xFF
1 is Monday
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
minute: interpreted as unsigned8
range 0..59, 0xFF
second: interpreted as unsigned8
range 0..59, 0xFF
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.
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 condi-
tions are manufacturer specific.

Bit is set if the basic timing information for the clock is presently taken from a timing source
c
different from the source specified in clock_base

d
This bit indicates that at least one bit of the clock status is invalid. Some bit 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.1.5 The COSEM server model

The COSEM server is structured into 3 hierarchical levels as shown in Figure 3:
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
Figure 3 – The COSEM server model
The following example (see Figure 4) 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
Objects “Total Energy” Register Register
“Total Volume” “Total Volume”
Register “Tariff 1”
LDN: COSEM logical
device name object A A
A
A: Association object
Figure 4 – Combined metering device

4.1.6 COSEM Logical Device

4.1.6.1 General
The COSEM Logical Device is a set of COSEM objects. Each physical device must contain a
"Management logical device".
The addressing of COSEM Logical Devices must be provided by the addressing scheme of the
lower layers of the protocol used.
4.1.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 4.2.14), or of a COSEM
object "COSEM Logical Device Name" (see 4.6.1.1.16).
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.1.6.3 The "Association View" of the Logical Device
In order to access COSEM objects in the server, an application association must be first estab-
lished. This characterises 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 (As-
sociation 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 clients 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 attrib-
utes and the availability of the methods (within the established association) can be found via spe-
cific methods provided by the Association objects (see 4.2.12, 4.2.13).
4.1.6.4 Mandatory Contents of a COSEM Logical Device
The following objects must be part of each COSEM logical device. They must be accessible for
GET/READ in all application associations with this logical device:
• COSEM logical device name object

• Current Association (LN or SN) object

4.1.7 Authentication Procedures

4.1.7.1 Low Level Security (LLS) Authentication
As described in DLMS UA 1000-2 or IEC 62056-53 the ACSE provides the authentication services
for low level security (LLS). Low level security authentication is typically used when the communi-
cation 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 4.2.12, 4.2.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 identifi-
cation. If yes, the client is authenticated and the association can be established.
4.1.7.2 High Level Security (HLS) Authentication
As described in DLMS UA 1000-2 or 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 pro-
tocol 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 pass 1 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_Authentication_Value" car-
ries the challenge CtoS.
The HLS authentication service, supporting pass 2 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 "Re-
sponding_Authentication_Value" carries the challenge StoC.
After pass 2 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 4.2.12, 4.2.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 en-
cryption 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's 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.
Base
4.2 The interface classes Data
The currently defined interface classes for meters and the rela- Register
tions between them are illustrated in Figure 5.
Extended Register
NOTES
Demand Register
The interface class "Base" itself is not specified explicitly. It contains only one
attribute "logical_name".
In the description of the "Demand Register", "Clock" and "Profile Generic" Clock
interface classes, the 2nd attributes are labelled differently than the 2nd attribute
of the "Data" interface class, namely "current_average_value", "time" and "buffer" Profile Generic
vs. "value". This is to emphasise the specific nature of the "value".
Association LN
Association SN
Register Activation
Script Table
Schedule
SAP Assignment
IEC optical port Setup
Activity Calendar
Register Monitor
Special Days Table
Single Action Schedule
PSTN modem config.
PSTN auto answer
PSTN auto dial
IEC HDLC Setup

Figure 5 – Overview of the interface classes
IEC Twisted Pair (1) Setup
Utility Tables

4.2.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
manufacturer specific configuration data and parameters having manufacturer specific logical
names.
Data 0..n class_id = 1, Version = 0

2. value instance specific
Specific Method(s) m/o
logical_name Identifies the data contained in value. Identifiers are specified in 4.6.1.
value Contains the data.

instance specific The data type of the value depends on
the instantiation defined by “logi-
cal_name”.
4.2.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 de-
scribed by the attribute "logical name" using the OBIS identification system (see 4.6.1).
Register 0..n class_id = 3, Version = 0

2. value (dyn.) instance specific
3. scaler_unit (static) scal_unit_type
1. reset o
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 ac-
cessed by a client.
The type has to be chosen such that, to-
gether with the logical_name, an unambi-
guous interpretation of the value is possi-
ble.
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 ele-
ments.
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;
details see below
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 // temperature (T) degree centi- K-273.15
grade
(10) currency // (local) currency
(11) m // length (l) meter m
(12) m/s // speed (v) m/s
3 3
(13) m // volume (V) m
3 3
(14) m // corrected volume m
3 3
(15) m /h // volume flux m /(60*60s)
3 3
(16) m /h // corrected volume flux m /(60*60s)
3 3
(17) m /d // volume flux m /(24*60*60s)
3 3
(18) m /d // corrected volume flux m /(24*60*60s)
-3 3
(19) l // volume 10 m
(20) kg // mass (m) kilogram kg
(21) N // force (F) newton N
(22) Nm // energy newtonmeter J = Nm = Ws
2
(23) Pa // pressure (p) pascal N/m
-5 2
(24) bar // pressure (p) bar 10 N/m
(25) J // energy joule J = Nm = Ws
(26) J/h // thermal power J/(60*60s)
(27) W // active power (P) watt W = J/s
(28) VA // apparent power (S)
(29) var // reactive power (Q)
(30) Wh // active energy W*(60*60s)
(31) VAh // apparent energy VA*(60*60s)
(32) varh // reactive energy var*(60*60s)
(33) A // current (I) ampere A
(34) C // electrical charge (Q) coulomb C = As
(35) V // voltage (V) Volt V
(36) V/m // electrical field strength (E) V/m
(37) F // capacity (C) farad C/V = As/V
(38) Ω // resistance (R) ohm Ω = V/A
Ωm /m resistivity (ρ) Ωm
2
(39) //
(40) Wb // magnetic flux (Φ) weber Wb = Vs
2
(41) T // induction (T) tesla Wb/m

Code // Unit Quantity Unit SI definition

(42) A/m // magnetic field strength (H) A/m
(43) H // inductivity (L) henry H = Wb/A
(44) Hz // frequency (f, ω) hertz 1/s
(45) Rac // active energy meter con- 1/(Wh)
stant
(46) Rre // reactive energy meter con-
stant
(47) Rap // apparent energy meter con-
stant
2 2
(48) Vh // V (60*60s)
2 2
(49) Ah // A (60*60s)
(50) kg/s // mass flux kg/s
(51) S mho // conductance siemens 1/Ω
(52) // reserved
... // ...
(253) // reserved
(254) other // other unit
(255) count // no unit, unitless, count 1
Table 2 – Example of values and units

Value Scaler Unit Data
3 3
263788 -3 m 263,788 m
593 3 Wh 593 kWh
3467 0 V 3467 V
4.2.3 Extended Register (class_id: 4)

Instances of an Extended Register class store a process value with its associated status, unit, and
time information. The Extended Register object knows the nature of the process value. The nature
of the value is described by the attribute "logical name" using the OBIS identification system.
Extended Register 0..n class_id = 4, Version = 0

Attribute(s) Data Type Min. Max. Def.
2. value (dyn.) instance specific
4. status (dyn.) instance specific
5. capture_time (dyn.) octet-string
1. reset o
For the definition of the attributes logical_name ... scaler_unit, see description of class "Register".
Status Provides an Extended Register specific status information. The data type and
encoding of the status must be provided for each instance of an Extended
Register.
Instance specific
Def Depending on the status type definition.

capture_time Provides an Extended Register specific date and time information showing
when the value of the attribute "value" has been captured.

octet-string, formatted as set in 4.1.4 for date_time.
Method Description
reset (data) This method forces a reset of the object. By invoking this method the attribute
value is set to the default value. The default value is an instance specific con-
stant.
The attribute status is set such that it shows that a reset method has been
invoked.
The attribute capture_time is set to the time of the reset execution.

data ::= integer(0)
4.2.4 Demand Register (class_id: 5)

Instances of a Demand Register class store a demand value with its associated status, unit, and
time information. The demand register measures and computes its current_average_value peri-
odically. The time interval T over which the demand is measured or computed is defined by speci-
fying "number_of_periods" and "period".
T = number_of_periods * period
T is the time interval
used for calculation
N 2 1 of the current_value
of a sliding demand
period register
t
start_time_current capture_time now
Figure 6 – The attributes when measuring sliding demand
The demand register delivers two types of demand: the current_average_value and the
last_average_value (see Figure 7 and Figure 8).
The demand register knows its type of process value which is described in "logical name" using
the OBIS identification system.
energy/period
period
last_average_value
current_average_value
0
t
start_time_current now start_time+period
Figure 7 – The attributes when measuring current_average_value if number of periods is 1

energy
3*period
lav4
lav5 -a1
a4
lav6
-a2 a5
lav3
-a3
cav
-a0 a3
a2
a1
period
a0
time
0 t1 t2 t3 now t4 t5 t6
sliding window (t3)
sliding window (t4)
sliding window (t5)
number_of_periods =3 sliding window (t6)

last_average_value: lav
current_average_value: cav
energy accumulated
during period k: ak
Figure 8 – The attributes if number of periods is 3
Demand Register 0..n class_id = 5, Version =

0
2. current_average_value (dyn.) instance specific 0
3. last_average_value (dyn.) instance specific 0
5. status (dyn.) instance specific
6. capture_time (dyn.) octet-string
7. start_time_current (dyn.) octet-string
8. period (static) double-long-unsigned 1
9. number_of_periods (static) long-unsigned 1 1
1. reset o
2. next_period o
For the attributes logical_name, scaler_unit, see description of class "Register".
status Provides demand register associated status information. The

type and encoding of the status must be provided for each in-
stance of a demand register.
instance specific
Def Depending on the status type definition.

current_average_value Provides the current value (running demand) of the energy accumu-
lated since start_time divided by number_of_periods*period.
Only simple data types shall be used.
last_average_value Provides the value of the accumulated energy (over the last num-
ber_of_periods*period) divided by number_of_periods*period. The
energy of the current (not terminated) period is not considered by the
calculation.
Only simple data types shall be used.
capture_time Provides the date and time when the last_average_value has been
calculated.
start_time_current Provides the date and time when the measurement of the cur-
rent_average_value has been started.
period Period is the interval between 2 successive updates of the
last_average_value. (number_of_periods*period is the denominator
for the calculation of the demand)
double-long-unsigned Measuring period in seconds
The behaviour of the meter after writing a new value to this attribute
must be specified by the manufacturer.
number_of_periods The number of periods used to calculate the last_average_value.
number_of_periods >= 1.
long-unsigned number_of_periods > 1 indicates that the
last_average_value represents “sliding demand”.
number_of_periods == 1 indicates that the
last_average_value represents "block demand".
The behaviour of the meter after writing a new value to this attribute
must be specified by the manufacturer.
Method Description
reset (data) This method forces a reset of the object. Activating this method provokes
the following actions:
The current period is terminated.
The current_average_value and the last_average_value are set to their
default values.
The capture_time and the start_time_current are set to the time of the
execution of reset(data).
data ::= integer(0)
next_period (data) This method is used to trigger the regular termination (and restart) of a
period. Closes (terminates) the current measuring period. Updates cap-
ture_time and start_time and copies current_average_value to
last_average_value, sets current_average_value to its default value.
Starts the next measuring period.
REMARK The old last_average_value (and capture_time) can be read
during the time “period”. The old current_average_value is not available
anymore at the interface.
data ::= integer(0)
4.2.5 Register Activation (class_id: 6)

An instance of the Register Activation class is used to handle different tariffication structures. It
specifies which Register, Extended Register and Demand Register objects are enabled if a spe-
cific Activation Mask is active (active_mask). All other register objects defined in regis-
ter_assignment not being part of the active_mask are disabled. All register objects not defined in
any register_assignment are enabled by default.

Register Activation 0..n class_id = 6, Version = 0

2. register_assignment (static) array
3. mask_list (static) array
4. active_mask (dyn.) octet-string
1. add_register o
2. add_mask o
3. delete_mask o
logical_name Contains an identifier for the group of masks (representing tariff/rates)

which are defined in the COSEM object. Normally this identifier is linked
to the nature of the registers which are defined in the regis-
ter_assignment (e.g. energy registers, demand registers, …).
register_assignment Specifies an ordered list of COSEM objects that are assigned to this
Register Activation object. The list can contain different kind of COSEM
objects (e.g. Register, Extended Register and Demand Register objects,
etc. ) simultaneously.
array object_definition
object_definition ::= structure
{
class_id: long-unsigned;
logical_name: octet-string (SIZE(6))
}
mask_list Specifies a list of register activation masks. Each entry (mask) is identi-
fied by its mask_name and contains an array of indices referring to the
registers assigned to the mask (the first object in register_assignment is
referenced by index 1, the second object by index 2, …,).
Array register_act_mask
register_act_mask ::= structure
{
mask_name: octet-string;
index_list: index_array
}
index_array ::= array unsigned
mask_name has to be uniquely defined within the object.
active_mask Defines the currently active mask. The mask is defined by its
mask_name (see mask_list).
octet-string This is a mask_name from the mask_list.
The active_mask defines the registers currently enabled, all other regis-
ters listed in the register_assignment are disabled.
Method Description
add_register (data) This method adds one more register to the attribute register_assignment.
The new register is added at the end of the array; i.e. the new register
has the highest index. The indices of the existing registers are not modi-
fied.
data ::= structure
{
class_id: long-unsigned
logical_name: octet-string;
}

add_mask (data) This method adds another mask to the attribute mask_list. If there exists
already a mask with the same name, the existing mask will be overwrit-
ten by the new mask.
data ::= register_act_mask (see above)
delete_mask (data) This method deletes a mask from the attribute mask_list. The mask is
defined by its mask name.
data ::= octet-string (mask_name)
4.2.6 Profile Generic (class_id: 7)

The Profile Generic class defines a generalised concept to store dynamic process values of cap-
ture objects. A capture object is either a register, a clock or a profile. The capture objects are col-
lected periodically or occasionally. A profile has a buffer to store the captured data. To retrieve a
part of the buffer, either a value range or an entry range may be specified, asking to retrieve all
entries whose values or entry numbers fall within the given range.
Assigning the corresponding objects to the profile specifies the capture objects the values of which
have to be retained (with method capture). The buffer has homogenous entries (all have the same
size and structure), and the assignment is defined statically. The modification of the capture object
assignment clears the buffer of the profile completely. All profiles capturing this modified profile will
be cleared as well to guarantee the homogeneity of their entries.
The buffer may be defined as sorted by one of the registers or by a clock, or the entries are
stacked in a "last in first out" order. So for example, it is very easy to build a "maximum demand
register" with a one entry deep sorted profile capturing and sorted by a demand register. It is just
as simple to define a profile retaining the three largest values of some period.
The size of profile data is determined by three parameters:

1. The number of entries filled. This will be zero after clearing the profile;
2. The maximum number of entries to retain. If all entries are filled and a capture () request oc-
curs, the least important entry (according to the requested sorting method) will get lost. This
maximum number of entries may be specified. Upon changing it, the buffer will be adjusted;
3. The physical limit for the buffer. This limit typically depends on the objects to capture. The ob-
ject will reject an attempt of setting the maximum number of entries that is larger than physi-
cally possible.
Profile Generic 0..n class_id = 7, Version = 1

2. buffer (dyn.) compact array or array x
3. capture_objects (static) array
4. capture_period (static) double-long-unsigned x
5. sort_method (static) enum x
6. sort_object (static) object_definition x
7. entries_in_use (dyn.) double-long-unsigned 0 0
8. profile_entries (static) double-long-unsigned 1 1
1. reset o
2. capture o
3. reserved from previous versions o
buffer The buffer attribute contains a sequence of entries. Each entry

contains values of the captured objects (as they would be re-

turned to a GET or READ.request). The sequence of the values
of the captured objects within the structure (see below) corre-
sponds to the order defined in the attribute capture_objects.
The sequence of the entries within the array (see below) is or-
dered according to the specified sort method. The buffer gets
filled by subsequent calls of the method capture ().
compact-array or array entry

entry ::= structure
instance specific
Default: The buffer is empty after reset
Remark 1: Reading the entire buffer delivers only those entries which
are “in use”
Remark 2: The value of a captured object may be replaced by “null-
data” if it can be unambiguously recovered from the previous value
(e.g. for time: if it can be calculated from the previous value and
capture_period; or for a value: if it is equal to the previous value)
selective access (see 4.1.2) to the attribute buffer may be

available (optional). The selective access parameters are as
defined below.
capture_objects Specifies the list of capture objects (registers, clocks and pro-
files) that are assigned to this profile object. Upon a call of the
capture () method, the specified attributes of these objects are
copied into the buffer of the profile.
array capture_object_definition
capture_object_definition ::= structure
{
attribute_index: integer;
data_index: long-unsigned
}
where attribute_index is a pointer to the attribute within the ob-
ject. attribute_index 1 refers to the first attribute (i.e. logi-
nd
cal_name), attribute_index 2 to the 2 , etc.); attribute_index 0
refers to all public attributes.
Where data_index is a pointer selecting a specific element of

the attribute. The first element in the attribute structure is iden-
tified by data_index 1. If the attribute is not a structure, then the
data_index has no meaning. If the capture object is the buffer
of a profile, then the data_index identifies the captured object of
the buffer (i.e. the column) of the inner profile.
data_index 0: references the whole attribute.
capture_period >= 1: Automatic capturing assumed. Specifies the capturing

period in seconds.
0: No automatic capturing; capturing is triggered exter-

nally or capture events occur asynchronously.
sort_method If the profile is unsorted, it works as a “first in first out” buffer (it
is hence sorted by capturing, and not necessarily by the time
maintained in the clock object). If the buffer is full, the next call
to capture () will push out the first (oldest) entry of the buffer to
make space for the new entry.

If the profile is sorted, a call to capture () will store the new en-
try at the appropriate position in the buffer, moving all following
entries and probably loosing the least interesting entry. If the
new entry would enter the buffer after the last entry and if the
buffer is already full, the new entry will not be retained at all.
enum (1) fifo (first in first out),

(2) lifo (last in first out),
(3) largest,
(4) smallest,
(5) nearest_to_zero,
(6) farest_from_zero
Def fifo
sort_object If the profile is sorted, this attribute specifies the register or
clock that the ordering is based upon.
capture_object_definition see above

Def no object to sort by (only possi-
ble with sort_method fifo or lifo)
entries_in_use Counts the number of entries stored in the buffer. After a call of
reset () the buffer does not contain any entries, and this value is
zero. Upon each subsequent call of capture (), this value will be
incremented up to the maximum number of entries that will get
stored (see profile_entries).
double-long-unsigned 0…profile_entries
Def 0
profile_entries Specifies how many entries should be retained in the buffer.
double-long-unsigned 1… (limited by physical size)

Def 1
Parameters for selective access to the buffer attribute

Access Parameter Comment
selector
value
1 range_descriptor In this case only buffer elements corresponding to the
range_descriptor shall be returned in the response.
2 entry_descriptor In this case only buffer elements corresponding to the en-
try_descriptor shall be returned in the response.
range_descriptor ::= structure

{
restricting_object capture_object_ Defines the register or clock restricting
definition the range of entries to be retrieved
from_value instance_specific Oldest or smallest entry to retrieve
to_value instance_specific Newest or largest entry to retrieve
selected_values array cap- List of columns to retrieve. If the array is
ture_object_ defini- empty (has no entries), all captured data
tion is returned. Otherwise only the columns
specified in the array are returned. The
type capture_object_definition is speci-
fied above (capture_objects)
}
entry_descriptor ::= structure
{

from_entry double-long- First entry to retrieve

unsigned
to_entry double-long- Last entry to retrieve.
unsigned to_entry==0: highest possible entry.
from_selected_value long-unsigned Index of first value to retrieve
to_selected_value long-unsigned Index of last value to retrieve.
to_selected_value==0: highest possible
selected_value.
}
Method Description
reset (data) Clears the buffer. The buffer has no valid entries afterwards,
entries_in_use is zero after this call. This call does not trigger
any additional operations of the capture objects, specifically, it
does not reset any captured buffers or registers.
data ::= integer(0)
capture (data) Copies the values of the objects to capture into the buffer by
reading <object_attribute> of each capture object. Depending
on the sort_method and the actual state of the buffer this pro-
duces a new entry or a replacement for the less significant en-
try. As long as not all entries are already used, the en-
tries_in_use attribute will be incremented.
This call does not trigger any additional operations within the
capture objects such as capture () or reset ().
NOTE that only some attributes of the captured objects might
be stored, not the complete object.
data ::= integer(0)
Behaviour of the object after modification of certain attributes

Any modification of one of the attributes describing the static
structure of the buffer will automatically call a reset () and this
call will propagate to all other profiles capturing this profile.
If writing to profile_entries is attempted with a value too large
for the buffer, it will be rejected.
Restrictions
When defining the capture objects, circular reference to the profile must be avoided.
Profile used to define a subset of preferred readout values
By setting profile_entries to 1, the profile object can be used to define a set of preferred readout-
values. In the "capture_objects" attributes those objects and attributes are pre-defined which
should be readable with one single command.
Setting capture_period to 1 ensures that the values are updated every second.
4.2.7 Clock (class_id: 8)

An instance of the clock interface class handles all information that is related to date and time, in-
cluding leap years and the deviation of the local time to a generalised time reference (Greenwich
Mean Time GMT). The deviation from the local time to the generalised time reference can change
depending on the season (e.g. summer time vs. wintertime). The interface to an external client is
based on date information specified in day, month and year, time information given in hundredths
of seconds, seconds, minutes and hours and the deviation from the local time to the generalised
time reference.

It also handles the daylight savings function in that way; i.e. it modifies the deviation of local time
to GMT depending on the attributes. The start and end point of that function is normally set once.
An internal algorithm calculates the real switch point depending on these settings.
Deviation
LocalTime
GMT
daylight_savings_begin daylight_savings_end
Figure 9 – The generalised time concept
Clock 0..1 class_id = 8, Version = 0

2. time (dyn.) octet-string
3. time_zone (static) long
4. status (dyn.) unsigned8
5. daylight_savings_begin (static) octet-string
6. daylight_savings_end (static) octet-string
7. daylight_savings_deviation (static) integer
8. daylight_savings_enabled (static) boolean
9. clock_base (static) enum
1. adjust_time o
2. adjust_to_measuring_period o
3. adjust_to_minute o
4. adjust_to_preset_time o
5. preset_adjusting_time o
6. shift_time o
time Contains the meter’s local date and time, its deviation to GMT
and the status. See also the description in 4.1.4.
When this value is set, only specified fields of the date_time are
changed. For example for setting the date without changing the
time, all time relevant octets of the date_time must be set to
“not specified”. The clock_status must always be set when
writing the time.

time_zone The deviation of local, normal time to GMT in minutes.
long
status The status is equal to the status read in time. See also the de-
scription in 4.1.4.

unsigned8, formatted as set in 4.1.4 for clock_status

daylight_savings_begin Defines the local switch date and time when the local time has
to be deviated from the normal time.
For generic definitions wildcards are allowed.

daylight_savings_end See above.

daylight_savings_deviation Contains the number of minutes by which the deviation in gen-
eralised time must be corrected at daylight savings begin.
integer Deviation range of up to ± 120 min

daylight_savings_enabled TRUE enables daylight savings function.
boolean
clock_base Defines where the basic timing information comes from.
enum (0) not defined

(1) internal crystal
(2) mains frequency 50 Hz
(3) mains frequency 60 Hz
(4) GPS (global positioning system)
(5) Radio Controlled
Method Description
adjust_time (data) Sets the meter’s time to the nearest (+/-) quarter of an hour
value (*:00, *:15, *:30, *:45).
data ::= integer (0).

adjust_to_measuring_period Sets the meter’s time to the nearest (+/-) starting point of a
(data) measuring period.
data ::= integer (0).

adjust_to_minute (data) Sets the meter’s time to the nearest minute.
If second_counter < 30 s, so second_counter is set to 0.

If second_counter ≥ 30 s, so second_counter is set to 0 and
minute_counter and all depending clock values are incre-
mented if necessary.
data ::= integer(0)

adjust_to_preset_time (data) This method is used in conjunction with the pre-
set_adjusting_time method. If the meter’s time lies between
validity_interval_start and validity_interval_end, then time is set
to preset_time.
data ::= integer(0)

preset_adjusting_time (data) Presets the time to a new value (preset_time) and defines a
validity_interval within which the new time can be activated.
data ::= structure

{
preset_time: octet-string;
validity_interval_start: octet-string;
validity_interval_end: octet-string
}

all octet-strings formatted as set in 4.1.4 for date_time.

shift_time (data) Shifts the time by n (-900 <= n <= 900) s.
data ::= long
4.2.8 Script Table (class_id: 9)

The IC Script table provides the possibility to trigger a series of actions by activating an execute
method. For that purpose Script table contains a table of script entries. Each table entry (script)
consists of a script_identifier and a series of action_specifications. An action_specification acti-
vates a method of a COSEM object or modifies attributes of a COSEM object within the logical de-
vice.
A specific script may be activated by other COSEM objects within the same logical device or from
the outside.
If two scripts have to be executed at the same time instance, then the one with the smaller index is
executed first.
Script Table 0..n class_id = 9, Version = 0

2. scripts (static) array
1. execute m
scripts Specifies the different scripts, i.e. the lists of actions.

array script
script structure
{
script_identifier: long-unsigned
actions: array action_specification
}
The script_identifier 0 is reserved. If speci-
fied with an execute method, it results in a
null script (no actions to perform).
action_specification structure
{
service_id: enum
class_id: long-unsigned
index: integer
parameter: service specific
}
where
service_id: defines which action shall be applied
to the referenced object
(1) write attribute
(2) execute specific method
index: defines (with service_id 1) which attrib-
ute of the selected object is affected or
(with service_id 2) which specific method is to be
executed.
The first attribute (logical_name) has index 1, the

first specific method has index 1 as well.

NOTE
The action_specification is limited to activate methods that do not produce any
response (from the server to the client).
Method Description
execute (data) Execute the script specified in parameter data.
data long-unsigned
If data matches one of the script_identifiers in

the script table, then the corresponding ac-
tion_specification is executed.
4.2.9 Schedule (class_id: 10)

The IC Schedule together with an object of the IC Special Days Table handles time and date
driven activities within a device. The following picture gives an overview and shows the interactions
between them:
Table 3 – Schedule
Index enable action switch_ validity_ exec_weekdays exec_specdays date range
(script) time window
Mo Tu We Th Fr Sa Su S1 S2 ... S8 S9 begin_ end_
date date
120 Yes xxxx:yy 06:00 0xFFFF x x x x x x 01-04-xx 30-09-xx

121 Yes xxxx:yy 22:00 15 x x x x x 01-04-xx 30-09-xx
122 Yes xxxx:yy 12:00 0 x 01-04-xx 30-09-xx
200 No xxxx:yy 06:30 x x x x x x 01-04-xx 30-09-xx
201 No xxxx:yy 21:30 x x x x x 01-04-xx 30-09-xx
202 No xxxx:yy 11:00 x 01-04-xx 30-09-xx
Table 4 – Special Days Table

Index special_ day_id
day_date
12 24-12-xx S1
33 25-12-xx S3
77 31-03-97 S3
Schedule 0..n class_id = 10, Version = 0

2. entries (static) array
1. enable/disable o
2. insert o
3. delete o
entries Specifies the scripts to be executed at given times. There is only one script

that can be executed per entry.

array schedule_table_entry
schedule_table_entry structure
{
index: long-unsigned
(1..9999)
enable: boolean
script_logical_name: octet-string
script_selector long-unsigned
switch_time: octet-string
validity_window: long-unsigned
exec_weekdays: bit-string
exec_specdays: bit-string
begin_date: octet-string
end_date: octet-string
}
script_logical_name: defines the logical name
of the script object
script_selector: defines the script_identifier of
the script to be executed.
switch_time accepts wildcards to define re-
petitive entries. The format of the octet-string
follows the rule set in 4.1.4 for time. valid-
ity_window defines a period in minutes, in
which an entry must be processed after
power fail. (time between defined switch_time
and actual power_up) 0xFFFF: the script
must be processed any time.
exec_specdays perform the link to the IC

Special Days Table, day_ID.
begin_date and end_date define the date pe-
riod in which the entry is valid (wildcards are
allowed). The format follows the rule set in
4.1.4 for date.
Method Description
enable/disable (data) Sets the disable bit of range A of entries to true and then enables
the entries of range B.
data ::= structure

{
firstIndexA;
lastIndexA;
firstIndexB;
lastIndexB
}
firstIndexA First index of the range that is disabled.

long-unsigned
lastIndexA Last index of the range that is disabled.
long-unsigned
firstIndexB First index of the range that is enabled.
long-unsigned
lastIndexB Last index of the range that is enabled.
long-unsigned
firstIndexA/B < lastIndexA/B : all entries of the range A/B are

disabled/enabled

firstIndexA/B == lastIndexA/B : one entry is disabled/enabled
firstIndexA/B > lastIndexA/B : nothing disabled/enabled
firstIndexA/B and lastIndexA/B > 9999: No entry is dis-

abled/enabled
insert (data) Inserts a new entry in the table. If the index of the entry exists
already the existing entry is overwritten by the new entry.
entry schedule_table_entry
data corresponding to entry
delete (data) Deletes a range of entries in the table.

data ::= structure
{
firstIndex;
lastIndex
}
firstIndex First index of the range that is deleted.
long-unsigned
lastIndex Last index of the range that is deleted.
long-unsigned
firstIndex < lastIndex: all entries of the range A/B are deleted
firstIndex ::= lastIndex : one entry is deleted
firstIndex > lastIndex : nothing deleted
Remarks concerning “inconsistencies” in the table entries:

If the same script should be executed several times at a specific time instance, then it is executed only once.
If different scripts should be executed at the same time instance, then the execution order is according to the
"index". The script with the lowest "index" is executed first.
Recovery after Power Fail
After a power failure the whole schedule is processed to execute all the necessary scripts that
would get lost during a power failure. For this the entries that were not executed during the power
failure must be detected. Depending on the validity window attribute they are executed in the cor-
rect order (as they would have been executed in normal operation).
Handling of Time Changes
There are four different "actions" of time changes:

1. time setting forward;
2. time setting backwards;
3. time synchronisation;
4. daylight saving action.
All these four actions need a different handling executed by the schedule in interaction with the
time setting activity.
Time setting forward*
This is handled the same way as a power failure. All entries missed are executed depending on
the validity window attribute. A (manufacturer specific defined) short time setting can be handled
like time synchronisation.
* Writing to the attribute "time" of the "Clock" object

Time setting backward*
This results in a repetition of those entries that are activated during the repeated time. A (manu-
facturer specific defined) short time setting can be handled like time synchronisation.
* Writing to the attribute "time" of the "Clock" object
Time synchronisation*
Time synchronisation is used to correct small deviations between a master clock and the local
clock. The algorithm is manufacturer specific. It must guarantee that no entry of the schedule gets
lost or gets executed twice. The validity window attribute has no effect, because all entries must be
executed like in normal operation.
* Using the method "adjust_time" of the "Clock" object
Daylight Saving
If the clock is forwarded then all scripts which fall into the forwarding interval (and would therefore
get lost) are executed.
If the clock is backwarded re-execution of the scripts which fall into the backwarding interval is
suppressed.
4.2.10 Special Days Table (class_id: 11)

The interface class allows defining dates, which will override normal switching behaviour for spe-
cial days. The interface class works in conjunction with the class "Schedule" or "Activity Calendar"
and the linking data item is day_id.
Special Days Table 0..1 class_id = 11, Version = 0

2. entries (static) array
1. insert o
2. delete o
entries Specifies a special day identifier for a given date.

The date may have wildcards for repeating special days like
Christmas.
array spec_day_entry
spec_day_entry structure
{
index: long-unsigned
specialday_date: octet-string
day_id: unsigned
}
the range of day_id must match the length
of the bitstring specialday_date formatting
follows the rule set in 4.1.4 for date.
exec_specdays in the related object of
interface class "Schedule"

Method Description
insert (data) Inserts a new entry in the table.
entry spec_day_entry
If a special day with the same index or with the same date as
an already defined day is inserted, the old entry will be over-
written.
delete (data) Deletes an entry in the table.

index Index of the entry that shall be deleted.
long-unsigned
data ::= long-unsigned
4.2.11 Activity Calendar (class_id: 20)

An instance of the Activity Calendar class is typically used to handle different tariffication struc-
tures. It is a definition of scheduled actions inside the meter, which follow the classical way of cal-
endar based schedules by defining seasons, weeks... It can coexist with the more general object
Schedule and can even overlap with it. If actions are scheduled for the same activation time in an
object Schedule and in the object Activity Calendar, the actions triggered by Schedule are exe-
cuted first.
After a power failure only the "last action" missed from the object Activity Calendar is executed
(delayed). This is to ensure proper tariffication after power up. If a Schedule object is present, then
the missed "last action" of the Activity Calendar must be executed at the correct time within the
sequence of actions requested by the Schedule.
The Activity Calendar defines the activation of certain scripts, which can perform different activities
inside the logical device. The interface to the object Script is the same as for the object Schedule.
(see 4.2.9)
If an instance of the interface class "Special Days Table" (see 4.2.10) is available, relevant entries
there take precedence over the Activity Calendar object driven selection of a day profile. The day
profile referenced in the "Special Days Table" activates the day_schedule of the day_profile_table
in the "Activity Calendar" object by referencing through the day_id.
Activity Calendar 0..1 class_id = 20, Version = 0

2. calendar_name_active (static) octet-string
3. season_profile_active (static) array
4. week_profile_table_active (static) array
5. day_profile_table_active (static) array
6. calendar_name_passive (static) octet-string
7. season_profile_passive (static) array
8. week_profile_table_passive (static) array
9. day_profile_table_passive (static) array
10. acti- (static) octet-string
vate_passive_calendar_time
1. activate_passive_calendar o
Attributes called ..._active are currently active, attributes called ..._passive will be activated by the
specific method activate_passive_calendar

calendar_name Typically contains an identifier, which is descriptive to the set of scripts

which are activated by the object.
season_profile Contains a list defining the starting date of a season. This list is sorted
according to season_start. Each season activates a specific
week_profile.
array season
season ::= structure

{
season_profile_name: octet-string
season_start: octet-string
week_name: octet-string
}.
Where:
season_profile_name is a user defined name
identifying the current season_profile;
season_start defines the starting time of the

season, formatted as set in 4.1.4 for date_time.
REMARK
The current season is terminated by the season_start of
the next season
week_name defines the week_profile active in this

season .
week_profile_table Contains an array holding the correlation between day_profiles for
every day of the week to be used in different seasons.
array week_profile
week_profile ::= structure
{
week_profile_name: octet-string;
monday: day_id;
tuesday: day_id;
wednesday: day_id;
thursday: day_id;
friday: day_id;
saturday: day_id;
sunday: day_id
}
day_id: unsigned
Where:
week_profile_name is a user defined name
identifying the current week_profile;
mondaydefines the day_profile valid on Monday;
…
sunday defines the day_profile valid on Sunday.
day_profile_table Contains a list of scripts and the corresponding activation times. Within
each day_profile the list is sorted according to start_time.
array day_profile
day_profile ::= structure

{
day_id: unsigned;
day_schedule: array (day_profile_action)
}
day_profile_action ::= structure

{
start_time: octet-string;

script_logical_name: octet-string;
script_selector: long-unsigned
}
where day_id is a user defined identifier, identi-

fying the current day_profile.
start_time: defines the time when the script is to

be executed (no wildcards); the format follows the
rule set in 4.1.4 for time.
script_logical_name: defines the logical name of

the script object
script_selector: defines the script_identifier of the

script to be executed
activate_passive_ Defines the time when the object itself calls the specific method acti-
calendar_time vate_passive_calendar. A definition with "not specified" notation in all
fields of the attribute will deactivate this automatism. Partial "not speci-
fied" notation in just some fields of date and time are not allowed.
Method Description
activate_passive_ This method copies all attributes called …_passive to the corresponding
calendar(data) attributes called …_active
data ::= integer(0)
4.2.12 Association LN (class_id: 15)

COSEM Logical Devices able to establish application associations within a COSEM context using
Logical Name references, model the associations through instances of the Association LN class. A
COSEM Logical Device has one instance of this IC for each association the device is able to sup-
port.
Association LN 0..MaxNbofAss. class_id = 15, Ver-

sion = 0
2. object_list (static) object_list_type
3. associated_partners_id associated_partners_type
4. application_context_name application-context-name
5. xDLMS_context_info xDLMS-context-type
6. authentica- mechanism-name
tion_mechanism_name
7. LLS_secret octet-string
8. association status enum
1. reply_to_HLS_authentication o
2. change_HLS_secret o
3. add_object o
4. remove_object o
logical_name Identifies the Association LN object instance. The value of this attrib-
ute is indicated to the client application during the application asso-
ciation establishment.
object_list Contains the list and the access right descriptor of all COSEM object
instances which are ‘visible’ – can be accessed – within the given as-

sociation.
object_list_type ::= array object_list_element
object_list_element ::= structure

{
version: unsigned;
access_rights: access_right;
}
access_right ::= structure

{
attribute_access: attribute_access_descriptor;
method_access: method_access_descriptor;
}
attribute_access_descriptor ::= array attribute_access_item
attribute_access_item ::= structure

{
attribute_id : integer;
access_mode : enum
{
no_access (0);
read_only (1) ;
write_only (2);
read_and_write (3);
}
access_selectors : array integer OPTIONAL;

}
method_access_descriptor ::= array method_access_item
method_access_item ::= structure

{
method_id : integer;
access_mode : boolean
}
The attribute_access_descriptor and the method_access_descriptor

always contain all implemented attributes or methods.
access_selectors contain a list of the supported selector values.
selective access (see 4.1.2) to the attribute object_list may be avail-

able (optional). The selective access parameters are as defined be-
low.
associated_partners_id Contains the identifiers of the COSEM client and the COSEM server
which are associated. This attribute contains the address of the Client
and Server Application Processes.
Associated_partners_id ::= structure

{
client_SAP: integer;
server_SAP: long-unsigned;
}
application_context_name In the COSEM environment it is intended that an application
context pre-exists and is referenced by its name during the estab-
lishment of an application association. This attribute contains the
name of the application context for that association.

application-context-name ::= OBJECT IDENTIFIER;
• See DLMS UA 1000-2 or IEC 62056-53

xDLMS_context_info Contains all the necessary information on the xDLMS context for
the given association
xDLMS-context-type ::= structure
{
conformance : bitstring(24) ;
max_receive_pdu_size : long-unsigned ;
max_send_pdu_size : long-unsigned ;
dlms_version_number : unsigned ;
quality_of_service : integer;
cyphering_info : octet-string
}
The conformance element contains the xDLMS conformance
block supported by the server.
The max_receive_pdu_size element contains the maximum
length for a xDLMS PDU, expressed in bytes, that the client may
send. This is the same as the server-max-receive-pdu-size pa-
rameter of the DLMS-Initiate.response pdu (see DLMS UA 1000-
2 or IEC 62056-53).
The max_send_pdu_size, in an active association contains the
maximum length for a xDLMS PDU, expressed in bytes, that the
server may send. This is the same as the client-max-receive-pdu-
size parameter of the DLMS-Initiate.request pdu (see DLMS UA
1000-2 or IEC 62056-53).
The dlms_version_number element contains the DLMS version
number supported by the server.
The quality_of _service element is not used.
The cyphering_info, in an active association, contains the dedi-
cated key parameter of the DLMS-Initiate.request pdu (see DLMS
UA 1000-2 or IEC 62056-53).
authentica- This attribute contains the name of the authentication mechanism
tion_mechanism_name for that association.
mechanism-name ::= OBJECT IDENTIFIER;
See DLMS UA 1000-2 or IEC 62056-53
No mechanism-name is required when no authentication is used.

LLS_secret This attribute contains the authentication value for the LLS
authentication process.
association_status This attribute indicates the current status of the association,
which is modelled by that object.
Association-status : enum
{
(0) non-associated;
(1) association-pending;
(2) associated;
}
Parameters for selective access to the object_list attribute
• If no selective access is demanded, (no Access-Selection-Parameters parameter is present in

the GET.request (.indication) service invocation for the object_list attribute) the corresponding
.response (.confirmation) service shall contain all object_list_elements of the object_list attrib-
ute.

• When selective access is demanded to the object_list attribute (the Access-Selection-

Parameters parameter is present), the response shall contain a 'filtered' list of ob-
ject_list_elements, as follows:
Access Service parameters Comment

selector
value
1 NULL All information excluding the access_rights shall be in-
cluded in the response.
2 class_list Access by class. In this case only those ob-
ject_list_elements of the object_list shall be included in the
response, which have a class_id equal to one of the
class_id’s of the class-list.
No access_right information is included.
class_list ::= array class_id
class_id ::= long-unsigned
3 object_Id_list Access by object. The full information record of object in-
stances on the object_Id_list shall be returned.
object_Id_list ::= array object_Id
4 object_Id In this case the full information record of the required CO-
SEM object instance shall be returned.
object_Id ::= structure
{
}
Method Description
reply_to_HLS_ The remote invocation of this method delivers the client's “secretly”
authentication (data) processed “challenge StoC” (f(StoC)) back to the server as the data
service parameter of the invoked ACTION.request service. (see
4.1.7.2).
data ::= octet-string client’s response to the challenge
If the authentication is accepted, then the response (ACTION.confirm)

contains Result==OK and the server’s "secretly" processed "chal-
lenge CtoS" (f(CtoS)) back to the client in the data service parameter
of the response service.
data ::= octet-string server's response to the challenge
If the authentication is not accepted, then the Result parameter in the

response shall contain a non OK value, and no data shall be sent
back.
change_HLS_secret Changes the HLS secret (e.g. encryption key).
(data)
a
data ::= octet-string new HLS secret
Add_object(data) Adds the referenced object to the object_list.
data ::= object_list_element (see above)

Remove_object(data) Removes the referenced object from the object_list.
data ::= object_list_element (see above)

a
The structure of the “new secret” depends on the security mechanism implemented. The “new secret” may
contain additional checkbits and it may be encrypted.

4.2.13 Association SN (class_id: 12)

COSEM Logical Devices able to establish application associations within a COSEM context using
Short Name references, model the associations through instances of the Association SN class. A
COSEM Logical Device has one instance of this IC for each association the device is able to sup-
port.
The short_name of the Association SN object itself is fixed within the COSEM context. It is given in
4.5.2 as 0xFA00
Association SN 0..n class_id = 12, Version = 1

2. object_list (static) objlist_type
3. read_by_logicalname o
4. get_attributes&methods o
5. change_LLS_secret o
6. change_HLS_secret o
7. reserved from previous versions
8. reply_to_HLS_authentication o
object_list Contains the list of all objects with their base_names (short_name),
class_id, version and logical_name. The base_name is the DLMS
objectName of the first attribute (logical_name)
objlist_type ::= array objlist_element
objlist_element ::= structure
{
base_name: long;
version: unsigned;
}
selective access (see 4.1.2) to the attribute object_list may be avail-

able (optional). The selective access parameters are as defined be-
low.
Parameters for selective access to the object_list attribute

selec-
torvalue
1 class_id: long-unsigned Delivers the subset of the object_list for a specific class_id.
For the response: data ::= objlist_type
2 structure Delivers the entry of the object_list for a specific class_id
{ and logical_name.
class_id: For the response: data ::= objlist_element
long-unsigned;
logical_name:
octet-string
}
Method Description
read_by_logicalname Reads attributes for selected objects. The objects are specified by

(data) their class_id and their logical_name.

data ::= array attribute_identification
attribute_identification ::= structure
{
attribute_index: integer
}
where attribute_index is a pointer (i. e. offset) to the attribute within
the object.
a
attribute_index 0 delivers all attributes , attribute_index 1 delivers the
first attribute (i. e. logical_name), etc.).
For the response: data is according to the type of the attribute.

get_attributes& Delivers information about the access rights to the attributes and
methods(data) methods within the actual association. The objects are specified by
their class_id and their logical_name.
data ::= array object_identification
object_identification ::= structure

{
}
For the response

data ::= array access_description
access_description ::= structure

{
read_attributes: bit-string;
write_attributes: bitstring;
methods: bit-string
}
The position in the bitstring identifies the attribute/method (first posi-

tion ↔ first attribute, first position ↔ first method) and the value of the
bit specifies whether the attribute/method is available (bit set) or not
available (bit clear).
change_LLS_secret Changes the LLS secret (e.g. password).
(data) data ::= octet-string new LLS secret
change_HLS_secret Changes the HLS secret (e.g. encryption key).
b
(data) data ::= octet-string new HLS secret
reply_to_HLS_ The remote invocation of this method delivers the client's “secretly”
authentication (data) processed “challenge StoC” (f(StoC)) back to the server as the data
service parameter of the invoked ACTION.request service. (see
4.1.7.2).
If the authentication is accepted, then the response (ACTION.confirm)

contains Result==OK and the server’s "secretly" processed "chal-
lenge CtoS" (f(CtoS)) back to the client in the data service parameter
of the response service.
data ::= octet-string server's response to the challenge
If the authentication is not accepted, then the Result parameter in the

response shall contain a non OK value, and no data shall be sent

back.
a
If at least one attribute has no read access right under the current association, then a read_by_logicalname() to
attribute index 0 reveals the error message “scope of access violation” (see IEC 61334-4-41:1996, p. 221).
b
The structure of the “new secret” depends on the security mechanism implemented. The “new secret” may
contain additional checkbits and it may be encrypted.
4.2.14 SAP Assignment (class_id: 17)

The interface class SAP Assignment contains the information on the assignment of the logical de-
vices to their Service Access Points (SAP) (see DLMS UA 1000-2 or IEC 62056-46).
SAP Assignment 0..1 class_id = 17, Version = 0

2. SAP_assignment_list (static) asslist_type 0
1. connect_logical_device() o
SAP_assignment_list Contains the list of all logical devices and their SAP addresses within
the physical device.
asslist_type ::= array asslist_element

asslist_element ::= structure
{
SAP: instance specific;
(see remark below)
logical_device_name:
octet-string
}
REMARK The actual addressing is performed by the “lower” communication
layers. For a 3-layer connection oriented architecture more details can be
found in DLMS UA 1000-2 or IEC 62056-46.
Method Description
connect_logical_device(data) Connects a logical device to a SAP. Connecting to SAP 0 will
disconnect the device. More than one device cannot be con-
nected to one SAP (exception SAP 0)
data ::= asslist_element.
4.2.15 Register Monitor (class_id: 21)

This interface class allows to define a set of scripts (see 4.2.8) that are executed when the value
of an attribute of a monitored register type object (Data, Register, Extended Register, Demand
Register, etc.) crosses a set of threshold values.
The IC Register Monitor requires an instantiation of the IC Script Table in the same logical device.

Register Monitor 0..n class_id = 21, Version = 0

2. thresholds (static) array
3. monitored_value (static) value_definition
4. actions (static) array
thresholds Provides the threshold values to which the attribute of the referenced regis-
ter is compared.
array threshold
threshold: instance specific The threshold is of the same type as the

monitored attribute of the referenced ob-
ject.
monitored_value This defines which attribute of an object is to be monitored. Only values with
simple data types are allowed
value_definition ::= structure
{
class_id: long unsigned;
attribute_index: integer
}
actions Defines the scripts to be executed when the monitored attribute of the refer-
enced object crosses the corresponding threshold. The attribute “actions”
has exactly the same number of elements as the attribute “thresholds”. The
ordering of the action_items corresponds to the ordering of the thresholds
(see above).
array action_set
action_set ::= structure
{
action_up: action_item;
action_down: action_item
}
where action_up defines the action when the attribute data of the monitored
register crosses the threshold in the upwards direction and vice versa.
action_item ::= structure

{
script_logical_name: octet-string;
script_selector: long-unsigned
}
4.2.16 Utility Tables (class_id: 26)

An instance of the Utility Tables class encapsulates ANSI C12.19:1997 table data.
With this interface class definition, each "Table" is represented as an instance. The specific in-
stance is identified by its logical_name.

Utility tables 0..n class_id = 26, version = 0

2. table_ID (static) long-unsigned
3. length double-long-unsigned
4. buffer octet-string
table_ID Table number. This table number is as specified in the ANSI
standard and may be either a standard table or a
manufacturer’s table.
Length Number of octets in table buffer.
Buffer Contents of table.
Selective access (see 4.1.2) to the attribute buffer may be avail-
able (optional). The selective access parameters are as defined
below.
Parameters for selective access to the buffer attribute

selector
1 offset_access Access to table by offset and count using offset_selector for
parameter data.
2 index_access Access to table by element id and number of elements using
index_selector for parameter data.
offset_selector ::= structure

{
Offset double-long- Offset in octets to the start of
unsigned access area, relative to the start
of the table.
Count long-unsigned Number of octets requested or
transferred.
}
index_selector ::= structure

{
Index array of long- Sequence of indices to identify
unsigned elements within the table’s hier-
archy.
Count long-unsigned Number of elements requested
or transferred. Values of count
greater than 1 return up to that
many elements. A value of
zero, when given in the context
of a request, refers to the entire
subtree of the hierarchy starting
at the selection point.
}
4.2.17 Single Action Schedule (class_id: 22)

Many applications request periodic actions within a meter. These actions are not necessarily linked
to tariffication (activity calendar or schedule).

Single Action Schedule 0..n class_id = 22, version = 0

2. executed_script (static) script
3. type (static) enum
4. execution_time (static) array
Specific Service(s) m/o
executed_script Contains the logical name of the script table and the script selector of the
script to be executed.
script Structure
{
Script_logical_name octetstring
Script_selector long_unsigned
}
Logical_name and script_selector define the script to be executed.
type enum
(1) size of execution_time = 1; wildcard in date al-
lowed
(2) size of execution_time = n; all time values are the
same; wildcards in date not allowed
(3) size of execution_time = n; all time values are the
same; wildcards in date are allowed
(4) size of execution_time = n; time values may be
different; wildcards in date not allowed
(5) size of execution_time = n; time values may
be different; wildcards in date are allowed
execution_time Specifies the time of day the script is executed
array {octet-string, octet-string}
The two octet-strings contain time and date, in this
order, structure {
time: octet-string;
date: octet-string
}
time and date are formatted as defined in 4.1.4.
WILDCARDS in “time” are not allowed; seconds and

hundredths of seconds must be zero
4.3 Maintenance of the Interface Classes

Any modification of interface classes as described below in 4.3.2 will be recorded by moving the
old or obsolete version of an interface class into 4.7 "Previous versions of interface classes".
Versions of interface classes prior to the establishment of the current document are kept by the
DLMS UA only.
4.3.1 New Interface Classes

The DLMS UA reserves the right to be the exclusive administrator of interface classes.

4.3.2 New Versions of Interface Classes

Any modification of an existing interface class results in a new version (version ::= version+1) and
must be documented accordingly. The following rules must be followed:
a) new attributes and methods may be added;
b) existing attributes and methods may be invalidated BUT the indices of the invalidated attributes
and methods must not be re-used by other attributes and methods;
c) if these rules cannot be met, then a new interface class must be created;
d) new versions of COSEM interface classes are administered by the DLMS UA.
4.3.3 Removal of Interface Classes

Besides one association object and the logical device name object no instantiation of an interface
class is mandatory within a meter. Therefore even unused interface classes will not be removed
from the standard. They will be kept to ensure compatibility with possibly existing implementations.
4.4 Protocol related Interface Classes

Each communication device and / or protocol needs some setup parameters to be defined for
proper operation.
4.4.1 IEC Local Port Setup (class_id: 19)

Instances of this interface class define the operational parameters for communication using IEC
62056-21. Several ports can be configured. The logical_names shall be as defined in 4.6.1.1.10.
IEC Local Port Setup 0..n class_id = 19, Version = 0

2. default_mode (static) enum
3. default_baud (static) enum
4. prop_baud (static) enum
5. response_time (static) enum
6. device_addr (static) octet-string
7. pass_p1 (static) octet-string
8. pass_p2 (static) octet-string
9. pass_w5 (static) octet-string
10. response_timeout long-unsigned 1500 1500
default_mode Defines the protocol used by the meter on the port
enum (0) protocol according to IEC
62056-21 (modes A..E)
(1) protocol according to DLMS
UA 1000-2 or IEC 62056-46. Us-
ing this enumeration value all
other attributes of this class are
not applicable.
default_baud Defines the baud rate for the opening sequence
enum (0) 300 baud
(1) 600 baud
(2) 1 200 baud

(3) 2 400 baud

(4) 4 800 baud
(5) 9 600 baud
(6) 19 200 baud
(7) 38 400 baud
(8) 57 600 baud
(9) 115 200 baud
prop_baud Defines the baud rate to be proposed by the meter

enum (0) 300 baud
(1) 600 baud
(2) 1 200 baud
(3) 2 400 baud
(4) 4 800 baud
(5) 9 600 baud
(6) 19 200 baud
(7) 38 400 baud
(8) 57 600 baud
(9) 115 200 baud
response_time Defines the minimum time between the reception of a request

(end of request telegram) and the transmission of the response
(begin of response telegram).
enum (0) 20 msec
(1) 200 msec
device_addr Device address according to IEC 62056-21
octet-string
pass_p1 Password 1 according to IEC 62056-21
octet-string
pass_p2 Password 2 according to IEC 62056-21
octet-string
pass_w5 Password W5 reserved for national applications.
octet-string
response_timeout; Allows to adapt the timeout until a response is received to adapt to
different communication media.
value in msec
long-unsigned
4.4.2 PSTN Modem Configuration (class_id: 27)

An instance of the PSTN Modem Configuration class stores data related to the initialisation of mo-
dems, which are used for data transfer from/to a device. Several modems can be configured. The
logical_names shall be as defined in 4.6.1.1.2.
PSTN Modem Configuration 0..n class_id = 27, version = 0

1. logical_name (static) octetstring
2. comm_speed (static) enum 0 9 5
3. initialisation_string (static) array
4. modem_profile (static) array

comm_speed The communication speed between the device and the modem, not nec-
essarily the communication speed on the WAN.
enum: (0) 300 baud
(1) 600 baud
(2) 1 200 baud
(3) 2 400 baud
(4) 4 800 baud
(5) 9 600 baud
(6) 19 200 baud
(7) 38 400 baud
(8) 57 600 baud
(9) 115 200 baud
initialisation_string This data contains all the necessary initialisation commands to be sent to
the modem in order to configure it properly. This may include the configu-
ration of special modem features.
initialisation_string ::= array

initialisation_string_element ::= structure
{
request: octet-string;
response: octet-string
}
If the array contains more than one initialisation string element they are
subsequently sent to the modem after receiving an answer matching the
defined response.
REMARK
It is assumed that the modem is pre-configured such that it accepts the
initialisation_string.
If no initialisation is needed the initialisation string is empty.
modem_profile This data defines the mapping from Hayes standard com-
mands/responses to modem specific strings.
modem_profile::= array
{
modem_profile_element: octet-string
}
The modem_profile array must contain the corresponding strings for the
modem used in following order :
Element 0: OK
Element 1: CONNECT
Element 2: RING
Element 3 NO CARRIER
Element 4: ERROR
Element 5: CONNECT 1 200
Element 6 NO DIAL TONE
Element 7: BUSY
Element 8: NO ANSWER
Element 9: CONNECT 600
Element 12 CONNECT 9 600

4.4.3 PSTN Auto Answer (class_id: 28)

An instance of the PSTN Auto Answer class stores data related to the management of data
transfer between a device and a modem, which is used to answer incoming calls. Several modems
can be configured. The logical_names shall be as defined in 4.6.1.1.4.
PSTN Auto Answer 0..n class_id = 28, version = 0

2. mode (static) enum
3. listening_window (static) array
4. status (dyn) enum
5. number_of_calls (static) unsigned
6. number_of_rings (static) nr_rings_type
mode Defines the working mode of the PSTN line when the device is auto answer.
mode ::= enum
(0) Line dedicated to the device.
(1) Shared line management with limited number of calls al-
lowed. Once the number of calls is reached, the window
status becomes inactive until the next start date, what-
ever the result of the call.
(2) Shared line management with limited number of suc-
cessful calls allowed. Once the number of successful
communications is reached, the window status becomes
inactive until next start date.
(3) Currently no modem connected
(200..255) manufacturer specific modes
listening_window Contains the start and end instant when the window becomes active (for the
start instant), and inactive (for the end instant). The start_date defines im-
plicitly the period. Example: when day of month is not specified (equal to
0xFF) this means that we have a daily share line management. Daily,
monthly …window management can be defined.
listening_window ::= array window_element
window_element ::= structure

{
start _time: octet-string;
end_time: octet-string
}
start_time and end_time are formatted as set in 4.1.4 for date_time.
status Here is defined the status of the window.
status ::= enum
(0) Inactive: the device will manage no new incoming call. This
status is automatically reset to Active when the next listening
window starts.
(1) Active: the device can answer to the next incoming call.
(2) Locked. This value can be set automatically by the device or by
a specific client when this client has completed its reading ses-
sion and wants to give the line back to the customer before the
end of the window duration. This status is automatically reset to
Active when the next listening window starts.
number_of_calls This number is the reference used in modes 1 and 2.
When set to 0, this means there is no limit.

number_of_rings Defines the number of rings before the meter connects the modem. Two
cases are distinguished: number of rings within the window defined by at-
tribute “listening_window” and number of rings outside the “listen-
ing_window”.
nr_rings_type := structure
{
nr_rings_in_window: unsigned
(0: no connect in window);
nr_rings_out_of_window: unsigned
(0: no connect out of window)
}
4.4.4 PSTN Auto Dial (class_id: 29)

An instance of the PSTN auto dial class stores data related to the management data transfer be-
tween the device and the modem to perform auto dialling. Several modems can be configured.
The logical_names shall be as defined in 4.6.1.1.3.
PSTN Auto Dial 0..n class_id = 29, version = 0

2. mode (static) enum
3. repetitions (static) unsigned
4. repetition_delay (static) long-unsigned
5. calling_window (static) array
6. phone_list (static) array
mode Defines if the device can perform auto dialling.
mode ::= enum
(0) no auto dialling
(1) auto dialling allowed anytime
(2) auto dialling allowed within the validity time of the calling
window
(3) “regular” auto dialling allowed within the validity time of
the calling window; “alarm” initiated auto dialling allowed
anytime.
(200..255) manufacturer specific modes
repetitions The maximum number of trials in case of unsuccessful dialling attempts.
repetition_delay The time delay, expressed in seconds until an unsuccessful dial attempt
can be repeated.
repetition_delay 0 means delay is not specified.
calling_window Contains the start and end date/time stamp when the window becomes ac-
tive (for the start instant), or inactive (for the end instant). The start_date
defines implicitly the period. Example: when day of month is not specified
(equal to 0 x FF) this means that we have a daily share line management.
Daily, monthly …window management can be defined.
calling_window ::= array window_element
window_element ::= structure

{
start _time: octet-string;
end_time: octet-string
}
start_time and end_time are formatted as set in 4.1.4 for date_time.
phone_list Contains phone numbers, the device modem has to call under certain con-

ditions. The link between entries in the array and the conditions are not
contained in here.
phone_list ::= array

{
phone_number: octet-string
}
4.4.5 IEC HDLC Setup (class_id: 23)

An instance of the HDLC Setup class contains all data necessary to set up a communication
channel according to DLMS UA 1000-2 or IEC 62056-46. Several communication channels can be
configured. The logical_names shall be as defined in 4.6.1.1.12.
IEC HDLC Setup 0..n class_id = 23, version = 0

2. comm_speed (static) enum 0 9 5
3. window_size_ (static) unsigned 1 7 1
transmit
4. window_size_ re- (static) unsigned 1 7 1
ceive
5. max_info_field_ (static) unsigned 32 128 128
length_transmit
6. max_info_field_ (static) unsigned 32 128 128
length_receive
7. in- (static) long-unsigned 20 1000 30
ter_octet_time_out
8. inactivity_time_ out (static) long-unsigned 0 120
9. device_address (static) long-unsigned 16 0x3FFD 0
comm_speed The communication speed supported by the corresponding port
Enum: (0) 300 baud
(1) 600 baud
(2) 1 200 baud
(3) 2 400 baud
(4) 4 800 baud
(5) 9 600 baud
(6) 19 200 baud
(7) 38 400 baud
(8) 57 600 baud
(9) 115 200 baud
This communication speed can be overridden if the HDLC mode
of a device is entered through a special mode of another protocol.
window_size_transmit The maximum number of frames that a device or system can
transmit before it needs to receive an acknowledgement from cor-
responding station. During logon a smaller value can be negoti-
ated.
window_size_receive The maximum number of frames that a device or system can re-
ceive before it needs to transmit an acknowledgement to the cor-
responding station. During logon a smaller value can be negoti-
ated.

max_info_length_transmit The maximum information field length that a device can transmit.
During logon a smaller value can be negotiated.
max_info_length_receive The maximum information field length that a device can receive.
During logon a smaller value can be negotiated.
Inter_char_time_out Defines the time, expressed in ms, over which, when any charac-
ter is received from the primary station, the device will treat the
already received data as a complete frame.
inactivity_time_out Defines the time, expressed in seconds over which, when any
frame is received from the primary station, the device will process
a disconnection.
When this value is set to 0, this means that the inactivity_time_out
is not operational.
device_address Contains the physical device address of a device:
In case of single byte addressing:
0x00 NO_STATION Address
0x01…0x0F Reserved for future use
0x10...0x7D Usable address space
0x7E ‘CALLING’ device address
0x7F Broadcast address
In case of double byte addressing:

0x0000 NO_STATION Address
0x0001..0x000F Reserved for future use
0x0010..0x3FFD Usable address space
0x3FFE ‘CALLING’ Physical Device address
0x3FFF Broadcast address
4.4.6 IEC Twisted Pair (1) Setup (class_id: 24)

An instance of the IEC Twisted Pair (1) Setup class contains all data which are necessary to set
up a communication channel according to IEC 62056-31:1999. Several communication channels
can be configured. The logical_names shall be as defined in 4.6.1.1.13.
IEC Twisted pair (1) Setup 0..n class_id = 24, version = 0

2. secondary_address (static) octet-string
3. primary_address_list (static) pri-
mary_adress_list
_type
4. tabi_list (static) tabi_list_type
5. fatal_error (dynamic) enum
secondary_address Secondary_address memorises the ADS of the Secondary Station
(see IEC 62056-31:1999) that corresponds to the real equipment.
octet-string (SIZE(6))
primary_address_list Primary_address_list memorises the list of ADP or Primary Station
physical addresses for which each logical device of the real
equipment (the Secondary Station) have been programmed (see
IEC 62056-31:1999).
primary_adress_list_type ::= array
{
primary_address_element
}

primary_address_element ::= octet-string (SIZE(1))

tabi_list tabi_list represents the list of the TAB(i) for which the real equip-
ment (the Secondary Station) has been programmed in case of
Forgotten Station Call (see IEC 62056-31:1999).
tabi_list_type ::= array tabi_element
tabi_element ::= integer
fatal_error FatalError represents the last occurrence of one of the fatal
errors of the protocols described in IEC 62056-31:1999.
The initial default value of this variable is "00"H. Then, each
fatal error is spotted.
enum (0) No-error ,
(1) t-EP-1F,
(2) t-EP-2F ,
(3) t-EL-4F,
(4) t-EL-5F,
(5) eT-1F,
(6) eT-2F,
(7) e-EP-3F,
(8) e-EP-4F,
(9) e-EP-5F,
(10) e-EL-2F
4.5 Using Short Names for

accessing attributes and methods
Attributes and methods of COSEM objects can be referenced in two different ways:
Using COSEM Logical Names: In this case the attributes and methods of a COSEM object are
referenced via the identifier of the COSEM object instance to which they belong.
The reference for an attribute is:

class_id, value of the 'logical_name' attribute, attribute_index;
The reference for a method is:

class_id, value of the 'logical_name' attribute, method_index;
attribute_index is used as the identifier of the required attribute.

method_index is used as the identifier of the required method.
Using Short Names: This kind of referencing is intended for use in simple devices. In this case
each attribute and method of a COSEM object is identified with a 13 bit integer. The syntax for the
Short Name is the same as the syntax of the name of a DLMS Named Variable.
4.5.1 Guidelines for Assigning Short Names

This clause gives guidelines for assigning short names for public attributes and methods.
Data Short name Remarks

class_id = 1, Version = 0
Attribute(s)
logical_name x x is the base_name of the object.
value x+8
Specific Method(s)

Register Short name Remarks

Attribute(s)
logical_name x x is the base name of the object.
value x+8
scaler_unit x+16
Specific Method(s)
reset x+40
Extended Register Short name Remarks

Attribute(s)
value x+8
scaler_unit x+16
status x+24
capture_time x+32
Specific Method(s)
reset x+56
Demand Register Short name Remarks

Attribute(s)
current_average_value x+8
last-average_value x+16
scaler_unit x+24
status x+32
capture_time x+40
start_time_current x+48
period x+56
number_of_periods x+64
Specific Method(s)
reset x+72
next_period x+80
Register Activation Short name Remarks

Attribute(s)
register_assignment x+8
mask_list x+16
active_mask x+24
Specific Method(s)
add_register x+48
add mask x+56
delete mask x+64

Profile Generic Short name Remarks

Attribute(s)
buffer x+8 Selective access to the buffer is pro-
vided using parameterised access.
capture_objects x+16
capture_period x+24
sort_method x+32
sort_object x+40
entries_in_use x+48
profile_entries x+56
Specific Method(s)
reset x+88
capture x+96
Clock Short name Remarks

Attribute(s)
time x+8
time_zone x+16
status x+24
daylight_savings_begin x+32
daylight_savings_end x+40
daylight_savings_deviation x+48
daylight_savings_enabled x+56
clock_base x+64
Specific Method(s)
adjust_time x+96
adjust_to_measuring_period x+104
adjust_to_minute x+112
adjust_to_preset_time x+120
preset_adjusting_time x+128
shift_time x+136
Script Table Short name Remarks

Attribute(s)
scripts x+8
Specific Method(s)
execute x+32
Schedule Short name Remarks

Attribute(s)
entries x+8
Specific Method(s)
enable/disable x+32
insert x+40
delete x+48

Special Days Table Short name Remarks

Attribute(s)
entries x+8
Specific Method(s)
insert x+16
delete x+24
Activity Calendar Short name Remarks

Attribute(s)
calendar_name_active x+8
season_profile_active x+16
week_profile_table_active x+24
day_profile_table_active x+32
calendar_name_passive x+40
season_profile_passive x+48
week_profile_table_passive x+56
day_profile_table_passive x+64
activate_passive_calendar_time x+72
Specific Method(s)
activate_passive_calendar x+80
Association SN Short name Remarks

Attribute(s)
a
object_list x+8 Selective access to the object_list is
provided using parameterised ac-
cess.
Specific Method(s)
read_by_logicalname() x+48 With this method the parameterised
access feature can also be used.
get_attributes&methods() x+56 With this method the parameterised
change_LLS_secret() x+64
change_HLS_secret() x+72
reply_to_HLS_authentication() x+88 With this method the parameterised
See also DLMS UA 1000-2 or IEC
62056-53.
a
The base name of the object "Association SN" corresponding to the current association is 0xFA00
SAP Assignment Short name Remarks

Attribute(s)
SAP_assignment_list x+8
Specific Method(s)
connect_logical_device() x+32

Register Monitor Short name Remarks

Attribute(s)
thresholds x+8
monitored_value x+16
actions x+24
Specific Method(s)
Utility Tables Short name Remarks

class_id = 26,Version = 0
Attribute(s)
table_ID x+8
length x+16
buffer x+24
Specific Method(s)
Single Action Schedule Short name Remarks

Attribute(s)
executed_script x+8
type x+16
execution_time x+24
Specific Method(s)
IEC Local Port Setup Short name Remarks

Attribute(s)
default_mode x+8
default_baud x+16
prop_baud x+24
response_time x+32
device_addr x+40
pass_p1 x+48
pass_p2 x+56
pass_w5 x+64
Specific Method(s)
PSTN Modem Configuration Short name Remarks

Attribute(s)
comm_speed x+8
initialisation_string x+16
modem_profile x+24
Specific Method(s)

PSTN Auto Answer Short name Remarks

Attribute(s)
mode x+8
listening_window x+16
status x+24
number_of_calls x+32
number_of_rings x+40
Specific Method(s)
PSTN Auto Dial Short name Remarks

Attribute(s)
mode x+8
repetitions x+16
repetition_delay x+24
calling_window x+32
phone_list x+40
Specific Method(s)
IEC HDLC Setup Short name Remarks

Attribute(s)
comm_speed x+8
window_size_transmit x+16
window_size_receive x+24
max_info_length_transmit x+32
max_info_length_receive x+40
inter_char_time_out x+48
inactivity_time_out x+56
device_address x+64
Specific Method(s)
IEC Twisted pair (1) Setup Short name Remarks

Attribute(s)
secondary_address x+8
primary_address_list x+16
tabi_list x+24
fatal_error x+32
Specific Method(s)
4.5.2 Reserved base_names for Special COSEM Objects

In order to grant access for devices offering accessing by short_names some short_names are
reserved as base_names for special COSEM objects. The reserved range of names is from
0xFA00 to 0xFFF8.

Table 5 – Reserved base_names for Special COSEM Objects

base_name (objectName) COSEM object
0x FA00 Association SN
0x FB00 Script Table (instantiation: “broad-
cast_receiver script”)
0x FC00 SAP Assignment
0x FD00 Register object containing the “COSEM
Logical Device Name” in the attribute
"value"
4.6 Relation to OBIS

The OBIS identification system serves as a basis for the COSEM logical names. The system of
naming COSEM objects is defined in the basic principles (see 4.1) the identification of real data
items is specified in Clause 5 or IEC 62056-61.
The following clauses define the usage of those definitions in the COSEM environment.
All codes, which are not explicitly listed, but below the manufacturer specific range (128 ..
255) are reserved for future use.
4.6.1 Mapping of Data Items to COSEM Objects and Attributes

This clause defines the usage of OBIS identifications and their mapping to COSEM objects of
certain interface classes and their attributes.
4.6.1.1 Abstract COSEM Objects
This subclause contains definitions for data items not directly linked to an energy type.
Value group C
Abstract objects (A = 0)
0 General purpose COSEM objects
1 COSEM objects of IC "Clock"
2 COSEM objects IC “PSTN Modem Configura-
tion” and related IC-s
10 COSEM objects of IC "Script Table"

11 COSEM objects of IC "Special Days Table"
12 COSEM objects of IC "Schedule"
13 COSEM objects of IC "Activity Calendar"
14 COSEM objects of IC “Register Activation”
15 COSEM objects of IC "Single Action Schedule"
20 COSEM objects of IC "IEC Local Port Setup"

21 Standard readout definitions
22 COSEM objects of IC “IEC HDLC Setup”
23 COSEM objects of IC "IEC Twisted Pair (1)
Setup"
40 COSEM objects of IC “Association SN/LN”

41 COSEM objects of IC “SAP Assignment”
42 COSEM Logical Device Name

65 COSEM objects of IC “Utility Tables”
128 .. 175 Manufacturer specific COSEM related abstract

objects
all other codes are reserved
4.6.1.1.1 Clock
This COSEM object controls the system clock of the physical device. It is an instance of the inter-
face class "Clock".
Clock OBIS identification

IC A B C D E F
Clock object Clock 0 x 1 0 x 0xFF
The usage of value group E shall be:

• if just one object is instantiated, value E shall be 0;
• if more then one object is instantiated in the same physical device, its value group E shall
number the instantiations from 0 to the needed maximum value.
4.6.1.1.2 PSTN Modem Configuration

This COSEM object defines and controls the behaviour of the device regarding the communication
through a PSTN Modem. It is an instance of the interface class "PSTN Modem Configuration ".
PSTN modem configuration OBIS identification

IC A B C D E F
PSTN modem configuration object PSTN mo- 0 x 2 0 0 0xFF
dem con-
figuration
The usage of value group B shall be:
• If more then one object is instantiated in the same physical device its value group B shall num-
ber the communication channel.
4.6.1.1.3 PSTN Auto Dial

This COSEM object defines and controls the behaviour of the device regarding the auto dialling
function using a PSTN Modem. It is an instance of the interface class "PSTN Auto Dial".
PSTN auto dial
PSTN auto dial OBIS identification

IC A B C D E F
PSTN auto dial object PSTN auto 0 x 2 1 0 0xFF
dial
4.6.1.1.4 PSTN Auto Answer

This COSEM object defines and controls the behaviour of the device regarding the auto answering
function using a PSTN Modem. It is an instance of the interface class "PSTN Auto Answer "

PSTN auto answer OBIS identification

IC A B C D E F
PSTN auto answer object PSTN auto 0 x 2 2 0 0xFF
answer
• if more then one object is instantiated in the same physical device its value group B shall num-
4.6.1.1.5 Script Tables

These COSEM objects control the behaviour of the device.
Several instances of the interface class "Script Table" are predefined and normally available as
hidden scripts only with access to the execute() method.
The following table contains only the identifiers for the "standard" instances of the listed scripts.
Implementation specific instances of these scripts should use values different from 0 in value
group D.
script table objects OBIS identification

IC A B C D E F
a
global meter reset Script Table 0 x 10 0 0 0xFF
a
MDI reset / end of billing period Script Table 0 x 10 0 1 0xFF
Tariffication script table Script Table 0 x 10 0 100 0xFF
a
Activate test mode Script Table 0 x 10 0 101 0xFF
a
Activate normal mode Script Table 0 x 10 0 102 0xFF
Set output signals Script Table 0 x 10 0 103 0xFF
Broadcast script table Script Table 0 x 10 0 125 0xFF
a
The activation of these scripts is performed by calling the execute() method to the script identifier 1 of the
corresponding script object.
The tariffication script table defines the entry point into tariffication by standardising utility-wide
how to invoke the activation of certain tariff conditions.
The broadcast script table allows standardising utility wide the entry point into regularly needed
functionality.
4.6.1.1.6 Special Days Table

This COSEM object defines and controls the behaviour of the device regarding calendar functions
on special days for clock control. It is an instance of the interface class "Special Days Table".
Special Days Table OBIS identification

IC A B C D E F
Special Days Table object Special 0 x 11 0 0 0xFF
Days Table
4.6.1.1.7 Schedule
This COSEM object defines and controls the behaviour of the device in a sequenced way. It is an
instance of the interface class "Schedule"

Schedule OBIS identification

IC A B C D E F
Schedule object Schedule 0 x 12 0 x 0xFF
The usage of value group E shall be:

• If just one object is instantiated, value E shall be 0
• If more then one object is instantiated in the same physical device its value group E shall num-
ber the instantiations from 0 to the needed maximum value.
4.6.1.1.8 Activity Calendar

This COSEM object defines and controls the behaviour of the device in a calendar-based way. It is
an instance of the interface class "Activity Calendar"
Activity Calendar OBIS identification

IC A B C D E F
Activity Calendar object Activity 0 x 13 0 0 0xFF
Calendar
4.6.1.1.9 Single Action Schedule

These COSEM objects control the behaviour of the device.
One instance of the interface class "Single Action Schedule" is predefined.
The following table contains only those identifiers for the "standard" instances of the listed "Single
Action Schedules".
Implementation specific instances of these interface classes should use values different from 0 in
value group D.
Single Action Schedule OBIS identification

IC A B C D E F
End of Billing Periode Single Ac- 0 x 15 0 0 0xFF
tion Sched-
ule
4.6.1.1.10 IEC Local Port Setup

This COSEM object defines and controls the behaviour of the device regarding the communication
parameters on the ports according to IEC 62056-21. It is an instance of the interface class "IEC
Local Port Setup"
IEC Port Setup OBIS identification

IC A B C D E F
IEC Optical Port Setup object IEC Local 0 x 20 0 0 0xFF
Port Setup
IEC Electrical Port Setup object IEC Local 0 x 20 0 1 0xFF
Port Setup
• If more than one object is instantiated in the same physical device its value group B shall num-

4.6.1.1.11 Standard Readout Profile

A set of COSEM objects is defined to carry the standard readout as it would appear with IEC
62056-21 (modes A to D).
Standard readout OBIS identification

IC A B C D E F
general local port readout Profile 0 0 21 0 0 0xFF
general display readout Profile 0 0 21 0 1 0xFF
alternate display readout Profile 0 0 21 0 2 0xFF
service display readout Profile 0 0 21 0 3 0xFF
list of configurable meter data Profile 0 0 21 0 4 0xFF
additional readout profile 1 Profile 0 0 21 0 5 0xFF
…………..
additional readout profile n Profile 0 0 21 0 N 0xFF
Standard readout objects can also be related to an energy type and to a channel. See Clause 5 or
IEC 62056-61.
4.6.1.1.12 HDLC Setup

This COSEM object defines and controls the behaviour of the device at the association negotiation
instant using HDLC protocol. It is an instance of the interface class "HDLC Setup".
HDLC Setup OBIS identification

IC A B C D E F
HDLC Setup object HDLC 0 x 22 0 0 0xFF
Setup
4.6.1.1.13 IEC Twisted Pair (1) Setup

This COSEM objects defines and controls the behaviour of the device regarding the communica-
tion parameters according to IEC 62056-31:1999. It is an instance of the interface class " IEC
Twisted Pair (1) Setup ".
IEC Twisted Pair (1) Setup OBIS identification

IC A B C D E F
IEC Twisted Pair (1) Setup object IEC 0 x 23 0 0 0xFF
Twisted
Pair (1)
Setup
4.6.1.1.14 Association Objects

A series of COSEM objects are used to identify association objects within a physical device.

Association objects OBIS identification

IC A B C D E F
Current association Associta- 0 0 40 0 0 0xFF
tion LN/SN
Association, instance 1 Association 0 0 40 0 1 0xFF
LN/SN
…………..
Association, instance n Association 0 0 40 0 N 0xFF
LN/SN
4.6.1.1.15 SAP Assignment Object

One COSEM object is used to inform about the SAP assignments within a physical device.
SAP Assignment object OBIS identification

IC A B C D E F
SAP Assignment of current physical SAP As- 0 0 41 0 0 0xFF
device signment
4.6.1.1.16 COSEM Logical Device Name

Each COSEM Logical Device can be identified world-wide by its logical device name.
If addressing with Short Names, the COSEM Logical Device Name can always be found at the
same location. It is a Data or Register object at the base address 0xFD00.
COSEM Logical Device Name OBIS identification

IC A B C D E F
a
COSEM Logical Device Name Data 0 0 42 0 0 0xFF
a
In cases where the class “Data” is not available, the class “Register” (with scaler=0, unit=255) may be used.
4.6.1.1.17 Utility Tables

The following summarises the coding of ANSI Utility tables instances using the OBIS coding of
logical names.
A Use value of 0 to specify abstract object

B Instance of table set
C Use value 65 - signifies Utility tables specific definitions
D Table group selector
E Table number within group
F Use value 0xFF for data of current billing period
Utility Tables OBIS identification

IC A B C D E F
Standard tables 0-127 Utility Tables 0 x 65 0 n 0xFF
...
Manufacturer tables 0-127 Utility Tables 0 x 65 16 n 0xFF
...
Std Pending tables 0-127 Utility Tables 0 x 65 32 n 0xFF
...

Mfg Pending tables 0-127 Utility Tables 0 x 65 48 n 0xFF

...
4.6.1.1.18 Device ID
A series of COSEM objects is used to communicate ID numbers of the device. These can be
numbers defined by the manufacturer (manufacturing number) or defined by the user.
The different ID numbers are instances of the interface class "Data", with data type octet-string.
If more than one of those is used it is also allowed to combine them into one instance of the inter-
face class "Profile Generic". In this case the captured objects are the device ID data objects, the
capture period is 1 to have just actual values, the sort method is FIFO, the profile entries are lim-
ited to 1.
Device ID OBIS identification

IC A B C D E F
a
Device ID 1 object Data 0 x 96 1 0 0xFF
……
a
Device ID 10 object Data 0 x 96 1 9 0xFF
Device ID's object Profile ge- 0 x 96 1 0xF 0xFF

neric F
a
4.6.1.1.19 Parameter Changes

A set of simple COSEM objects describes the history of the configuration of the device. All values
are transported by instances of the interface class "Data".
Parameter changes OBIS identification

IC A B C D E F
a
Number of configuration program Data 0 x 96 2 0 0xFF
changes object
a
Date of last configuration program Data 0 x 96 2 1 0xFF
change object
a
Date of last time switch program change Data 0 x 96 2 2 0xFF
object
a
Date of last ripple control receiver pro- Data 0 x 96 2 3 0xFF
gram change object
a
Number of protected configuration pro- Data 0 x 96 2 10 0xFF
b
gram changes
a
Date of last protected configuration pro- Data 0 x 96 2 11 0xFF
b
gram change
a
b
Protected configuration is characterised by the need to open the main meter cover to modify it.
4.6.1.1.20 I/O Control Signals

These COSEM objects define and control the status of I/O lines and the pulse duration of physical
pulse outputs of the device.

Status is defined by an instance of the interface class "Data".
4.6.1.1.21 Internal Status

These COSEM objects define the internal status of control signals and the internal operating
status.
The interface class used for these objects is "Data" with data type octet-string. This data type is
used to transport binary information from a bitmap.
4.6.1.1.22 Power Failures

Different possibilities to represent values coming from power failure monitoring of the device are
available. Simple counting of events is represented by COSEM objects of interface class "Data"
with data type unsigned or long unsigned. If more sophisticated information is presented the CO-
SEM object shall be of interface class "Profile Generic".
4.6.1.1.23 Error Values

A series of COSEM objects is used to communicate error indications of the device.
The different error values are instances of the interface class "Data", with data type octetstring.
face class "Profile Generic". In this case the captured objects are the device ID data objects, the
capture period is 1 to have just actual values, the sort method is FIFO, the profile entries are lim-
ited to 1.
Error values OBIS identification

IC A B C D E F
a
Error 1 object Data 0 0 97 97 0 0xFF
…… …
a
Error 10 object Data 0 0 97 97 9 0xFF
Error profile object Profile ge- 0 0 97 97 0xF 0xFF

neric F
a
Error code objects can also be related to an energy type and to a channel. See Clause 5 or IEC
62056-61.
4.6.1.2 Electrical Energy related COSEM Objects
4.6.1.2.1 Value Group D Definitions

The different values as defined by value group D, and which do not represent data of previous
billing periods, are modelled in following way:
• Cumulative values are represented by COSEM objects which are instances of interface class
"Register"
• Maximum and minimum values are represented by COSEM objects which are instances of in-
terface class "Profile Generic" with sorting method maximum or minimum, depth according to
implementation and captured objects according to implementation. A single maximum value or

minimum value can alternatively be represented by an COSEM object which is an instance of

the interface class "Extended Register"
• Current and last average values are the respective attributes of COSEM objects which are in-
stances of interface class "Demand Register", using the OBIS code of the current value as
logical name
• Time integral values are represented by COSEM objects which are instances of interface class
"Register" or "Extended Register"
4.6.1.2.2 Data of previous billing periods

COSEM treats values or lists of values for several billing periods as profiles.
With value group F having a value between 0 and 99, and 101 direct access to data of previous
billing periods is available. (see Clause 5.4.6 or IEC 62056-61, "Value group F"). This is managed
by COSEM objects of interface class "Profile Generic" which are 1 entry deep and contain the
timestamp of the storage in addition to the stored value.
NOTE: no previous values are available for values of type current and last average.
With value group F having a value between 102 and 126 the data are represented by COSEM objects which are instances
of interface class "Profile Generic", with suitable values for the controlling attributes.
4.6.1.2.3 Electricity ID Numbers

The different Electricity ID numbers are instances of the interface class "Data", with data type oc-
tetstring.
face class "Profile Generic". In this case the captured objects are the Electricity ID data objects,
the capture period is 1 to have just actual values, the sort method is FIFO, the profile entries are
limited to 1.
Electricity ID OBIS identification

IC A B C D E F
a
Electricity ID 1 object Data 1 x 0 0 0 0xFF
……
a
Electricity ID 10 object Data 1 x 0 0 9 0xFF
Electricity ID's object profile 1 x 0 0 0x 0xFF

FF
a
4.6.1.2.4 Entries related to billing periods

Those values are represented by instances of the interface class "Data" with data type unsigned.
Historical data related entries OBIS identification

IC A B C D E F
a
Billing period counter object Data 1 x 0 1 0 0xFF
a
Number of available billing period Data Data 1 x 0 1 1 0xFF
object
a
The time stamps of previous data values shall be part of the captured objects within the COSEM
objects representing the data of previous billing periods. The values can also be related to a chan-
nel.

4.6.1.2.5 Program Entries

Those values are represented by instances of the interface class "Data" with data type unsigned or
long unsigned.
Program entries OBIS identification

IC A B C D E F
a
Configuration program version number Data 1 x 0 2 0 0xFF
object
a
Time switch program number object Data 1 x 0 2 2 0xFF
a
RCR program number object Data 1 x 0 2 3 0xFF
a
Program entries can also be related to a channel. See Clause 5 or IEC 62056-61.
4.6.1.2.6 Input and Output Pulse Constants, Nominal Values

These values are represented by instances of the interface class "Register".
4.6.1.2.7 Ratios
These values are represented by instances of the interface class "Data" with useful data types.
4.6.1.2.8 Threshold Values

These values are represented by instances of the interface class "Register Monitor" by defining
the monitored register, the threshold itself and the actions to be performed, when a threshold is
crossed.
4.6.1.2.9 Measurement- Registration – Period Values, Time Entries

These values are represented by instances of the interface class "Data", or "Register".
Time entries OBIS identification

IC A B C D E F
a
Clock synchronisation method Data 1 x 0 9 10 0xFF
a
Synchronisation method: enum

(0) no synchronisation
(1) adjust to quarter
(2) adjust to measuring period
(3) adjust to minute
(4) adjust to hour
(5) adjust to preset time
4.6.1.2.10 Measurement Algorithm for Active Power

These values are represented by instances of the interface class "Data".
Measurement Algorithm for active power

Measurement Algorithm for active OBIS identification

power
IC A B C D E F
Measuring algorithm Data 1 x 0 11 1 0xFF
Measuring algorithm: enum

(0) not specified
(1) only the fundamental of voltage and current is used
(2) all harmonics of voltage and current are used
(3) only the DC part of voltage and current is used
(4) all harmonics and the DC part of voltage and current are
used
4.6.1.2.11 Measurement Algorithm for Active Energy

Measurement Algorithm for active energy
Measurement Algorithm for active OBIS identification

energy
IC A B C D E F
The same enumeration applies for integrated values of active power as described in 4.6.1.2.10.
4.6.1.2.12 Measurement Algorithm for Reactive Power

Measurement Algorithm for reactive OBIS identification

power
IC A B C D E F
(0) not specified;
(1) (sum of) reactive power of each phase, calculated from the funda-
mental of the per-phase voltage and the per-phase current;
(2) polyphase reactive power calculated from polyphase apparent power
and polyphase active power;
(3) (sum of) reactive power calculated from per-phase apparent power
and per-phase active power,
4.6.1.2.13 Measurement Algorithm for Reactive Energy

Measurement Algorithm for reactive OBIS identification

energy
IC A B C D E F
The same enumeration applies for integrated values of reactive power as described in 4.6.1.2.12.

4.6.1.2.14 Measurement Algorithm for Apparent Power

Measurement Algorithm for apparent OBIS identification

power
IC A B C D E F

(1) not specified
(2) S =U ⋅I , with voltage: only fundamental, and current: only funda-
mental
(3) S =U ⋅I , with voltage: only fundamental, and current: all harmonics
(4) S =U ⋅I , with voltage: only fundamental, and current: all harmonics
and DC part
(5) S =U ⋅I , with voltage: all harmonics, and current: only fundamental
(6) S =U ⋅I , with voltage: all harmonics, and current: all harmonics
(7) S =U ⋅I , with voltage: all harmonics, and current: all harmonics and
DC part
(8) S =U ⋅I , with voltage: all harmonics and DC part, and current: only
fundamental
(9) S =U ⋅I , with voltage: all harmonics and DC part, and current: all
harmonics
(10) S =U ⋅I , with voltage: all harmonics and DC part, and current: all
harmonics and DC part
(11) S = P2 + Q2 , with P: only fundamental in U and I, and Q: only
fundamental in U and I,
where P and Q are polyphase quantities
(12) S = P2 + Q2 , with P: all harmonics in U and I, and Q: only funda-
mental in U and I
(13) S = P2 + Q2 , with P: all harmonics and DC part in U and I, and Q:
only fundamental in U and I
(14) S = å P2 + Q2 , with P: only fundamental in U and I, and Q: only
fundamental in U and I
where P and Q are single phase quantities
(15) S = å P2 + Q2 , with P: all harmonics in U and I, and Q: only funda-
mental in U and I
(16) S = å P2 + Q2 , with P: all harmonics and DC part in U and
I, and Q: only fundamental in U and I
4.6.1.2.15 Measurement Algorithm for Apparent Energy


Measurement Algorithm for apparent OBIS identification

energy
IC A B C D E F
The same enumeration applies for integrated values of apparent power as described in 4.6.1.2.14.
4.6.1.2.16 Measurement Algorithm for Power Factor Calculation

Measurement Algorithm for power factor calculation
Measurement Algorithm for power OBIS identification

factor calculation
IC A B C D E F
(0) not specified;
(1) displacement power factor: the displacement between fundamental voltage
and current vectors, which can be calculated directly from fundamental active
power and apparent power, or another appropriate algorithm;
(2) true power factor, the power factor produced by the voltage and
current including their harmonics . It may be calculated from apparent
power and active power, including the harmonics;
4.6.2 Coding of OBIS Identifications

To identify different instances of the same interface class they have to differ in their logical_name.
In COSEM the logical_name is taken from the OBIS definition (see Clause 5 or IEC 62056-61).
OBIS codes are used within the COSEM environment as an octet-string[6]. Each octet contains
the unsigned value of the corresponding OBIS value group, coded without tags.
If a data item is identified by less than 6 value groups, all unused value groups must be filled with
0xFF.
Octet 1 contains the binary coded value of A (A = 1, 2, ...8) in the four rightmost bits. The 4 left-
most bits contain the information on the identification system. The 4 leftmost bits set to zero indi-
cate that the OBIS identification system (version 1) is used as logical_name .
Identification system used 4 leftmost bits of octet 1 (MSB left)

OBIS, see Clause 5 or IEC 62056-61 0000
0001
Reserved for future use ...
1111
Within all value groups the usage of a certain selection is fully defined, others are reserved for fu-
ture use. Value group A is fully defined respective reserved for all possible values. No defined
value group item within groups B to F exists above 127.
The usage of the code space 128 to 254 (0xFE) characterises a manufacturer specific code. If one
value in a group B to F is used above 127 the whole code is characterised as manufacturer spe-
cific and even the other value groups (with the exception of group A) are not necessarily bearing
any meaning defined by this standard.

4.7 Previous Versions of Interface Classes
This chapter lists those interface class definitions which where included in previous editions of this
document. The previous interface class versions differ form the current versions by at least one
attribute and/or method and by the version number.
For new implementations in metering devices only the current versions shall be used.
Communication drivers at the client side must also support previous versions.
4.7.1 Profile Generic, version 0

The version listed here was valid in edition 1 and is replaced as of edition 2 and 3.
Profile 0..n Class_id=7, version=0
Attribute(s) Data Type Min Max Def
2. buffer (dyn.) array X
3. capture_objects (static) array
4. capture_period (static) double-long-unsigned X
5. sort_method (static) enum X
6. sort_object (static) ObjectDefinition X
7. entries_in_use (dyn.) double-long-unsigned 0 0
8. profile_entries (static) double-long-unsigned 1 1
1. reset () o
2. capture () o
3. get_buffer_by_range () o
4. get_buffer_by_index () o
buffer The buffer attribute contains a sequence of entries. Each en-
try contains values of the captured objects (as returned by
calling read(current_value)). The sequence is ordered ac-
cording to the specified sort method. The buffer gets filled by
subsequent calls to capture ().
array Entry
Entry ::= structure
Instance Specific
Def The buffer is empty at installation.
Remark: Reading
the entire buffer
delivers only those
entries which are “in
use”
Capture_objects Specifies the list of capture objects (registers, clocks and pro-
files) that are assigned to this profile object. Upon a call of the
capture () service, the specified attributes of these objects are
copied into the buffer of the profile.
array ObjectDefinition
ObjectDefinition ::= stucture {

attribute_index: unsigned
}
where attribute_index is a pointer to the attribute within the
object. attribute_index=1 refers to the first attribute (i.e. logi-
nd
cal_name), attribute_index =2 to the 2 , etc.)
Capture_period >= 1: Automatic capturing assumed. Specifies the capturing
period in seconds
0: no automatic capturing, capturing is trigger externally
or capture events occur asynchronously
sort_method If the profile is unsorted, it works as a „first in first out“ buffer
(it is hence sorted by capturing, and not necessarily by the
time maintained in the clock object). If the buffer is full, the
next call to capture () will push out the first (oldest) entry of
the buffer to make space for the new entry.
If the profile is sorted, a call to capture () will store the new
entry at the appropriate position in the buffer, moving all fol-
lowing entries and probably loosing the least interesting entry.
If the new entry would enter the buffer after the last entry and
if the buffer is already full, the new entry will not be retained at
all.
enum 1: fifo, 2: lifo (last in first out), 3: larg-
est, 4. smallest, 5. nearest_to_zero, 6.
farest_from_zero
Def fifo
sort_object If the profile is sorted, this attribute specifies the register or
clock that the ordering is based upon.
ObjectDefinition see above
Def no object to sort by (only possible with
sort_method= fifo or lifo)
entries_in_use Counts the number of entries stored in the buffer. After a call
of reset () the buffer does not contain any entries, and this
value is zero. Upon each subsequent call of capture (), this
value will be incremented up to the maximum number of en-
tries that will get stored (see profile_entries).
double-long- 0…profile_entries
unsigned
Def 0
profile_entries Specifies, how many entries should be retained in the buffer.
double-long- 1… (limited by physical size)
unsigned
Def 1
Method Description
reset (data) Clears the buffer. The buffer has no valid entries afterwards,
entries_in_use is zero after this call. This call does not trigger
any additional operations of the capture objects, specifically, it
does not reset any captured buffers or registers.
data = integer(0)
capture (data) Copies the values of the objects to capture into the buffer by
calling read(<object_attribute>) of each capture object. De-
pending on the sort_method and the actual state of the buffer
this produces a new entry or a replacement for the less signifi-
cant entry. As long as not all entries are already used, the en-
tries_in_use attribute will be incremented.

This call does not trigger any additional operations within the
capture objects such as capture () or reset ().
Note that only some attributes of the captured objects might be
stored, not the complete object.
data = integer(0)
write (...) Any write access to one of the attributes describing the static
structure of the buffer will automatically call a reset () and this
call will propagate to all other profiles capturing this profile.
If writing to profile_entries is attempted with a value too large
for the buffer, it will be set to the maximum possible value (re-
stricted by physical size, typically laid down in the firmware).
get_buffer_by_range (data) Reads all entries between the given limits.

restricting_object in ObjectDefinition
Defines the register or clock re-
stricting the range of entries to be
retrieved.
from_value in instance_specific
Oldest or smallest entry to re-
trieve.
to_value in instance_specific
Newest or largest entry to retrieve.
selected_values in List of columns to retrieve:
array ObjectDefinition
If the array is empty (has no en-
tries), all captured data is re-
turned. Otherwise only the col-
umns specified in the array are
returned. The type ObjectDefini-
tion is specified above (Capture_-
Objects)
entries out See entries_in_use above.
array (of instance_- out Sorted sequence of entries con-
specific_value) taining the requested values of the
capture objects.
data = structure {restricting_object; from_value; to_value; se-
lected_values}.
In the response “data” is an array of instance_specific_value.
get_buffer_by_index (data) Read all entries between the given limits.
From_index in double-long-unsigned
First entry to retrieve.
to_index in double-long-unsigned
Last entry to retrieve.
from_selected_valu in long-unsigned
e index of first value to retrieve
to_selected_value in long-unsigned
index of last value to retrieve.
entries out See entries_in_use above.
array of instance_- out Sorted sequence of entries con-
specific_value taining the requested values of the
capture objects.
data = structure {from_index; to_index; selected_values}.
In the response “data” is an array of instance_specific_value.

4.7.2 Association SN, version 0

The version listed here was valid in edition 1 and is replaced as of edition 2 and 3.
1
Device Association View 0..1 class_id=12, version=0
Attribute(s) Data Type Min Max Def
2. object_list (static) objlist_type
1. getlist_by_classid o
2. getobj_by_logicalname o
3. read_by_logicalname() o
4. get_attributes&services() o
5. change_LLS_secret() o
6. change_HLS_secret() o
7. get_HLS_challenge() o
8. reply_to_HLS_challenge() o
logical_name Identifies the type of the client-server association

object_list Contains the list of all objects with their short_name (DLMS ObjectName
2
of the first attribute), class_id, version and logical_name.
Objlist_type ::= array objlist_element
objlist_element ::= structure {
short_name: Integer16;
version: unsigned;
}
Method Description
getlist_by_classid(data) Delivers the subset of the object_list for a specific class_id.

data ::= class_id: long-unsigned
For the response: data ::= objlist_type

getobj_by_logicalname Delivers the entry of the object_list for a specific logical_name and
(data) class_id.
data ::= stucture {
}
For the response: data ::= objlist_element
read_by_logicalname Reads attributes for specific objects. The objects are specified by their
(data) class_id and their logical_name.
1
Per client server association
2
Note: Within an client-server association, there are never two objects with the same class_id and logical_name differ-
ing only in the versions.

data ::= array AttributeIdentification

AttributeIdentification ::= stucture {
attribute_index: unsigned
}
where attribute_index is a pointer (i. e. offset) to the attribute within the
object.
3
attribute_index = 0 delivers all attributes , attribute_index = 1 delivers the
first attribute (i. e. logical_name), etc.).
For the response: data is according to the type of the attribute
get_attributes&services(d Delivers information about the access rights to the attributes and services
ata) within the actual association. The objects are specified by their class_id
and their logical_name.
data ::= array ObjectIdentification
ObjectIdentification ::= structure {
}
For the response data::=array AccessDescription
AccessDescription ::= structure {
read_attributes: bit-string;
write_attributes:bitstring;
services: bit-string
}
The position in the bitstring identifies the attribute/service (first position ↔
first attribute, first position ↔ first service) and the value of the bit speci-
fies whether the attribute/service is available (bit set) or not available (bit
clear).
change_LLS_secret(data) Changes the LLS secret (e.g. password).
data ::= octet-stringnew LLS secret
change_HLS_secret(data) Changes the HLS secret (e.g. encryption key).
4
data ::= octet-string new HLS secret
get_HLS_challenge(data) Asks the server for the client “challenge” (e.g. random number).
data ::= octet-string client challenge
reply_to_HLS_challenge Delivers the “secretly” processed “challenge” back to the server.
(data)
If the authentication is accepted, then the response is successful [0]. If the
authentication is not accepted, then the response is set to data-access-
error [1].
3
If at least one attribute has no read access right under the current association, then a read_by_logicalname() to attrib-
ute index = 0 reveals the error message “scope-of-access-violated” (comp. IEC 61334-4-41:1996, p. 221).
4
The structure of the “new secret” depends on the security mechanism implemented. The “new secret” may contain
additional checkbits and it may be encrypted.

5. COSEM Object Identification System (OBIS)
5.1 Introduction
The competitive electricity market requires an ever-increasing amount of timely information con-
cerning the usage of electrical energy. Recent technology developments enable to build intelligent
static metering equipment, which are capable to capture, process and communicate this informa-
tion to all parties involved. For further analysis of this information, for the purposes of billing, load-,
customer- and contract management, it is necessary to uniquely identify all data in a manufacturer
independent way collected manually or automatically, via local or remote data exchange.
The definition of identification codes was based on DIN 43863-3 December:1997, Electricity me-
ters – Part 3: Tariff metering device as additional equipment for electricity meters – EDIS – Energy
Data Identification System
5.2 Scope
The Object Identification System (OBIS) defines the identification codes (ID-codes) for commonly
used data items in electricity metering equipment. This standard specifies the overall structure of
the identification system and the mapping of all data items to their identification codes.
The Object Identification System (OBIS) provides a unique identifier for all and every data within
the metering equipment, including not only measurement values, but also abstract values used for
configuration or obtaining information about the behaviour of the metering equipment. The ID
codes defined in this standard are used for identification of
• logical names of the various instances of the Interface Classes, or objects, as defined in
Clause 4 or IEC 62056-62;
• data transmitted through communication lines (see 5.5.1);
• data displayed on the metering equipment (see 5.5.2).
This standard applies to all types of electricity metering equipment, like fully integrated meters,
modular meters, tariff attachments, data concentrators etc.
To cover metering equipment measuring other energy types than electricity, combined metering
equipment measuring more than one type of energy or metering equipment with several physical
measurement channels, the concept of channels and medium are introduced. This allows meter
data originating from different sources to be identified. While this standard fully defines the struc-
ture of the identification system for other media, the mapping of non-electrical energy related data
items to ID codes needs to be completed separately. In co-operation with CEN TC294, WG2 some
non-electrical codes are already implemented.
5.3 OBIS Object identification system structure

OBIS codes are a combination of six value groups, which describe – in a hierarchical way – the
exact meaning of each data item (see Figure 10).

A B C D E F
Figure 10 – OBIS code structure
5.3.1 Value group A

The value group A defines the characteristic of the data item to be identified (abstract data, elec-
tricity-, gas-, heat-, water-related data).
5.3.2 Value group B

The value group B defines the channel number, i.e. the number of the input of a metering equip-
ment having several inputs for the measurement of energy of the same or different types (e.g. in
data concentrators, registration units). Data from different sources can thus be identified. The
definitions for this value group are independent from the value group A.
5.3.3 Value group C

The value group C defines the abstract or physical data items related to the information source
concerned, e.g. current, voltage, power, volume, temperature. The definitions depend on the value
of the Value group A. Measurement, tariff processing and data storage methods of these quanti-
ties are defined by value groups D, E and F.
For abstract data the hierarchical structure of the 6 code fields is not applicable.
5.3.4 Value group D

The value group D defines types, or the result of the processing of physical quantities identified
with the value groups A and C, according to various specific algorithms. The algorithms can deliver
energy and demand quantities as well as other physical quantities.
5.3.5 Value group E

The value group E defines the further processing of measurement results identified with value
groups A to D to tariff registers, according to the tariff(s) in use. For abstract data or for measure-
ment results for which tariffs are not relevant, this value group can be used for further classifica-
tion.
5.3.6 Value group F

The value group F defines the storage of data, identified by value groups A to E, according to dif-
ferent billing periods. Where this is not relevant, this value group can be used for further classifi-
cation.
5.3.7 Manufacturer specific codes

If any value group C to F contains a value between 128 and 254 the whole code is considered as
manufacturer specific.
5.4 Value group definitions
5.4.1 Value group A

The range for value group A is 0 to 15.

Table 6 – Value group A codes

Value group A
0 Abstract objects
1 Electricity-related objects
4 Heat cost allocator related objects

5 Cooling related objects
6 Heat-related objects
7 Gas-related objects
8 Cold water-related objects
9 Hot water related objects
5
All other possible values are reserved .
5.4.2 Value group B

The range for value group B is 1 to 255.
Table 7 – Value group B codes

Value group B
0 No channel specified
1 Channel 1
…
64 Channel 64
65…127 Reserved
128 .. 254 Manufacturer specific codes
255 Reserved
With implementations that contain one channel only, even not channel-specific data can be as-
signed to channel 1.
5.4.3 Value group C

The range for value group C is 0 to 255.
5.4.3.1 Abstract objects
Abstract objects are data items, which are not related to a certain type of physical quantity.
Table 8 – Value group C codes (abstract objects)

Value group C
Abstract objects (A = 0)
a
0…89 Context specific identifiers
94 Country specific identifiers
96 General service entries, see 5.4.7

97 General error messages, see 5.4.7
98 General list objects, see 5.4.9
5
Administered by the DLMS User Association

b
127 Inactive objects
128…254 Manufacturer specific codes
All other Reserved
a
Context specific identifiers identify objects specific to a certain
protocol and/or application. For the COSEM context the identifiers are
defined in Clause 4 or IEC 62056-62.
b
An inactive object is an object, which is defined and present in a
meter, but which has no assigned functionality.
5.4.3.2 Quantities for electrical energy related objects

Table 9 – Value group C codes (electricity objects)
Value group C
Electricity related objects (A = 1)
0 General purpose objects (see 5.4.8)
1 ΣLi Active power+
2 ΣLi Active power-
3 ΣLi Reactive power+
4 ΣLi Reactive power-
5 ΣLi Reactive power QI
6 ΣLi Reactive power QII
7 ΣLi Reactive power QIII
8 ΣLi Reactive power QIV
9 ΣLi Apparent power+
10 ΣLi Apparent power-
11 Current: any phase
12 Voltage: any phase
13 Average power factor
14 Supply frequency
15 ΣLI Active power QI+QIV+QII+QIII
16 ΣLI Active power QI+QIV-QII-QIII
17 ΣLi Active power QI
18 ΣLi Active power QII
19 ΣLi Active power QIII
20 ΣLi Active power QIV
21 L1 Active power+
22 L1 Active power-
23 L1 Reactive power+
24-30 L1 etc. (see 4-10)
a
31 L1 Current
32 L1 Voltage
33 L1 Power factor
34 L1 Frequency
35-40 L1 Active power ... etc. (see 15-20)
41 L2 Active power+
42 L2 Active power-
44-60 L2 etc. (see 24-40)
61 L3 Active power+
62 L3 Active power-

64-80 L3 etc. (see 24-40)

b
81 Angles
82 Unitless quantity (pulses or pieces)
91 L0 current (neutral)
92 L0 voltage(neutral)
96 Electricity-related service entries, see 5.4.7

97 Electricity-related error messages
98 Electricity list
99 Electricity data profile see 5.4.10
…127 Reserved
128 .. 254 Manufacturer specific code

255 Reserved
NOTES
• L i Quantity is the value (to be measured) of a measurement sys-
tem connected between the phase i and a reference point. In 3
phase 4-wire systems the reference point is the neutral. In 3
phase 3-wire systems the reference point is the phase L 2 .
• Σ L i quantity is the total measurement value across all systems.
a
For details of extended codes, see 5.4.5.1
b
For details of extended codes, see 5.4.5.2
The quadrant definitions are according to IEC 61268:1995 - Annex E, Figure E.1.
Figure 11 – Quadrants for power measurement
5.4.4 Value group D

The range for value group D is 0 to 255.
5.4.4.1 Electricity related objects
Table 10 –Value group D codes (electricity)
Value group D
Electricity related objects A = 1, C <> 0, 96,97,98,99
0 Billing period average (since last reset)
1 Cumulative minimum 1
2 Cumulative maximum 1
3 Minimum 1
4 Current average 1
5 Last average 1
6 Maximum 1
7 Instantaneous value
8 Time integral 1
9 Time integral 2
10 Time integral 3
13 Minimum 2
14 Current average 2
15 Last average 2
16 Maximum 2

23 Minimum 3
25 Last average 3
26 Maximum 3
29 Time integral 5
30 Time integral 6
31 Under limit threshold

32 Under limit occurrence counter
33 Under limit duration
34 Under limit magnitude
35 Over limit threshold
36 Over limit occurrence counter
37 Over limit duration
38 Over limit magnitude
39 Missing threshold
40 Missing occurrence counter
41 Missing duration
42 Missing magnitude
55 Test average
58 Time integral 4
128 .. 254 Manufacturer specific codes

all other Reserved
NOTES
Averaging Scheme 1
Controlled by measurement period 1 (see 5.4.8) a set of registers is calculated by a meter-
ing device. (codes 1..6). The typical usage is for billing purposes.
Averaging Scheme 2
ing device. (codes 11..16). The typical usage is for billing purposes.
Averaging Scheme 3
ing device. (codes 21..26). The typical usage is for instantaneous values.
Averaging Scheme 4
Controlled by measurement period 4 (see 5.4.8) a test average value. (code 55) is calculated
by the metering device.
Last average
The value of the demand register at the end of the last measurement period.
Current average 5
The value of a current demand register using recording interval 1 as time base.
Current average 6
The value of a current demand register using recording interval 2 as time base.
Time integral 1
Without the inclusion of a billing period code (F <> 255): time integral of the quantity calcu-
lated from the origin (first start of measurement) to the instantaneous time point.

With a billing period code included (0<=F<100): time integral of the quantity calculated from
the origin to the end of the billing period given by the billing period code.
Time integral 2
Without the inclusion of a billing period code(F <> 255): Time integral of the quantity calcu-
lated from the beginning of the current billing period to the instantaneous time point.
With a billing period code included (0<=F<100): Time integral of the quantity calculated over
the billing period given by the billing period code.
Time integral 3
Time integral of the positive difference between the quantity and a prescribed threshold
value.
Time integral 4 ("Test time integral”)
Time integral of the quantity calculated over a time specific to the device or determined by
test equipment.
Time integral 5
used as a base for load profile recording: Time integral of the quantity calculated from the
beginning of the current recording interval to the instantaneous time point for recording
period 1.
Time integral 6
used as a base for load profile recording: Time integral of the quantity calculated from the
beginning of the current recording interval to the instantaneous time point for recording
period 2.
Under limit values
Values under a certain threshold (e.g. dips).
Over limit values
Values above a certain threshold (e.g. swells).
Missing values
Values considered as missing (e.g. interruptions).
For identifiers of abstract objects see 5.4.7.
For identifiers of electricity related General purpose objects see 5.4.8.

5.4.4.2 Value group D for country specific identifiers
This table specifies the identifiers for country specific applications. Wherever possible the phone
codes are used. In this table there are no reserved ranges for manufacturer specific codes. The
usage of value group E and F are defined in country specific documents.
Table 11 – Value group D codes (country specific)

Value group D
a
Country specific identifiers (A = 0, C = 94)
00 Finnish identifiers
01 USA identifiers
02 Canadian identifiers
07 Russian identifiers
10 Czech identifiers
11 Bulgarian identifiers
12 Croatian identifiers
13 Irish identifiers
14 Israeli identifiers
15 Ukraine identifiers
16 Yugoslavian identifiers
27 South African identifiers
30 Greece identifiers
31 Dutch identifiers
32 Belgian identifiers
33 French identifiers

34 Spanish identifiers
35 Portuguese identifiers
36 Hungarian identifiers
38 Slovenian identifiers
39 Italian identifiers
40 Romanian identifiers
41 Swiss identifiers
42 Slovakian identifiers
43 Austrian identifiers
44 United Kingdom identifiers
45 Danish identifiers
46 Swedish identifiers
47 Norwegian identifiers
48 Polish identifiers
49 German identifiers
55 Brazilian identifiers
61 Australian identifiers
62 Indonesian identifiers
64 New Zealand identifiers
65 Singapore identifiers
81 Japanese identifiers
86 Chinese identifiers
90 Turkish identifiers
91 Indian identifiers
a
Must be limited to two characters
NOTE 1 All other codes reserved
NOTE 2 Objects that are already identified in this document but not
included in 5.4.4.2 must not be re-identified by a country specific iden-
tifier.
5.4.5 Value group E

The range for value group E is 0 to 255.
Table 12 – Value group E codes (electricity)

Value group E
Electrical energy related objects (A=1)
0 Total
1 Rate 1
2 Rate 2
3 Rate 3
.. ...
9 Rate 9
.. …
63 Rate 63
128…254 Manufacturer specific code

all other Reserved
This table is not valid if one of the following separate specifications for value group E apply.
5.4.5.1 Usage of value group E for current and voltage measurements
The following table show the meaning of the group E value while measuring current or voltage.

Table 13 – Extended current/voltage measurement

Value group E
Electrical energy related objects (A = 1); current/voltage
measurement (C = 31, 51, 71, 32, 52 or 72; D = 7)
0 Total
st
1 1 harmonic (fundamental)
nd
2 2 harmonic
th
… n harmonic
th
127 127 harmonic
128…254 manufacturer specific

255 Reserved
5.4.5.2 Usage of value group E for measuring angles

The following table shows the meaning of the group E value while measuring angles.
Table 14 – Extended angle measurement

Value group E
Electrical energy related objects (A = 1); angle measurement (C = 81; D = 7)
Angle U(L1) U(L2) U(L3) I(L1) I(L2) I(L3) I(L0) <=
From
U(L1) (00) 01 02 04 05 06 07
U(L2) 10 (11) 12 14 15 16 17
U(L3) 20 21 (22) 24 25 26 27
I(L1) 40 41 42 (44) 45 46 47
I(L2) 50 51 52 54 (55) 56 57
I(L3) 60 61 62 64 65 (66) 67
I(L0) 70 71 72 74 75 76 (77)
^ To (Reference)
For identifiers of abstract objects see 5.4.7.

For identifiers of electricity related General purpose objects see 5.4.8.
5.4.6 Value group F

The range for value group F is 0 to 255.
In all cases, if value group F is not used, it is set to 255.
5.4.6.1 Usage of value group F for billing periods
Value group F specifies the allocation to different billing periods (sets of historical values) for the
objects with following codes:
• Value Group A: 1
• Value Group C: 1 to 99
• Value Group D: 0 to 3; 6; 8 to 13; 16; 21 to 23; 26.
This allocation is valid for 0<=F<100.

5.4.7 Abstract objects

Table 15 – Abstract object codes
Abstract objects, general service entries OBIS code
A B C D E F
Device ID numbers (non energy/channel related)
Complete device ID (manufacturing number) 0 0 96 1
Device ID 1 0 0 96 1 0
............ … … …
Device ID 10 0 0 96 1 9
Parameter changes, calibration and access
Number of configuration program changes 0 x 96 2 0
Date of last configuration program change 0 x 96 2 1
Date of last time switch program change 0 x 96 2 2
Date of last ripple control receiver program change 0 x 96 2 3
Status of security switches 0 x 96 2 4
Date of last calibration 0 x 96 2 5
Date of next configuration program change 0 x 96 2 6
a
Number of protected configuration program changes 0 x 96 2 10
a
Date of last protected configuration program change 0 x 96 2 11
Input/output control signals
State of the input control signals 0 x 96 3 1
State of the output control signals 0 x 96 3 2
State of the internal control signals 0 x 96 4 0
Internal operating status 0 x 96 5 0
Battery entries
Battery use time counter 0 x 96 6 0
Battery charge display 0 x 96 6 1
Date of next change 0 x 96 6 2
Battery voltage 0 x 96 6 3
Number of power failures
Total failure of all three phases longer than internal autonomy 0 0 96 7 0
Phase L1 0 0 96 7 1
Phase L2 0 0 96 7 2
Phase L3 0 0 96 7 3
Operating time
Time of operation 0 x 96 8 0
Time of registration rate 1 0 x 96 8 1
… … … … … …
Environmental related parameters
Ambient temperature 0 x 96 9 0
Manufacturer specific 0 x 96 50 x x
.....................
Manufacturer specific 0 x 96 96 x x
a
Protected configuration is characterized by the need to open the main meter cover to modify it, or to break a
metrological seal.
REMARK If a value field is shaded, then this value group is not used. “x” is equal to any value within the range.

Table 16 – General error messages

Abstract objects, general error messages OBIS code
A B C D E F
a
Error object 0 x 97 97 x
REMARK If a value field is shaded, then this value group is not used. “x” is equal to any value within the range.
a
If only one object is instantiated, the value shall be 0
In the manufacturer specific objects only those values shall be placed, which are not represented
by another defined code, but need representation on the display as well. If this is not required, the
code shall use the possibilities of a value group above 127.
5.4.8 Electricity-related General purpose objects

Table 17 – General purpose codes (electricity)
Electricity related General purpose objects OBIS-code
A B C D E F
Free ID-numbers for utilities
Complete combined electricity ID 1 x 0 0
Electricity ID 1 1 x 0 0 0
...
Electricity ID 10 1 x 0 0 9
Billing period values/reset counter entries
Billing period counter 1 x 0 1 0
Number of available billing periods 1 x 0 1 1
Time stamp of the billing period VZ (last reset) 1 x 0 1 2 VZ
Time stamp of the billing period VZ-1 1 x 0 1 2 VZ-1
......................................................... ..... ...... ...... .......
Time stamp of the billing period VZ-n 1 x 0 1 2 VZ-n
Program entries
Configuration program version number 1 x 0 2 0
Parameter record number 1 x 0 2 1
Time switch program number 1 x 0 2 2
RCR program number 1 x 0 2 3
Meter connection diagram ID 1 x 0 2 4
Output pulse constants
RLW (Active energy, metrological LED ) 1 x 0 3 0
RLB (Reactive energy, metrological LED) 1 x 0 3 1
RLS (Apparent energy, metrological LED) 1 x 0 3 2
RAW (Active energy, output pulse) 1 x 0 3 3
RAB (Reactive energy, output pulse) 1 x 0 3 4
RAS (Apparent energy, output pulse) 1 x 0 3 5
Ratios
Reading factor for power 1 x 0 4 0
Reading factor for energy 1 x 0 4 1
b a
Transformer ratio – current (numerator) 1 x 0 4 2 V-y
b a
Transformer ratio – voltage (numerator) 1 x 0 4 3 V-y
b a
Overall transformer ratio (numerator) 1 x 0 4 4 V-y
b a
Transformer ratio – current (denominator) 1 x 0 4 5 V-y
b a
Transformer ratio – voltage (denominator) 1 x 0 4 6 V-y
b a
Overall transformer ratio voltage (denominator) 1 x 0 4 7 V-y
Nominal values
Voltage [V] 1 x 0 6 0
Basic/nominal current [A] 1 x 0 6 1
Frequency [Hz) 1 x 0 6 2
Maximum current [A] 1 x 0 6 3

Electricity related General purpose objects OBIS-code

A B C D E F
a
Reference voltage for power quality measurement 1 x 0 6 4 V-y
Input pulse constants
REW [Imp/kWh] (active energy) 1 x 0 7 0
REB [Imp/kvarh] (reactive energy) 1 x 0 7 1
RES [Imp/kVAh] (apparent energy) 1 x 0 7 2
Measurement-/registration-period duration
a
Measurement period 1, for average value 1 1 x 0 8 0 V-y
a
Measurement period 2, for average value 2 1 x 0 8 1 V-y
a
Measurement period 3, for instantaneous value 1 x 0 8 2 V-y
Measurement period 4, for test value 1 x 0 8 3
a
Recording interval 1, for load profile 1 x 0 8 4 V-y
a
Recording interval 2, for load profile 1 x 0 8 5 V-y
a
Billing period 1 x 0 8 6 V-y
Time entries
Time expired since last end of billing period 1 x 0 9 0
Local time 1 x 0 9 1
Local date 1 x 0 9 2
Reserved 1 x 0 9 3
Reserved 1 x 0 9 4
Week day (0..7) 1 x 0 9 5
Time of last reset 1 x 0 9 6
Date of last reset 1 x 0 9 7
Output pulse duration 1 x 0 9 8
Clock synchronization window 1 x 0 9 9
Clock synchronization method 1 x 0 9 10
Coefficients
a
Transformer magnetic losses 1 x 0 10 0 V-y
a
Transformer thermal losses 1 x 0 10 1 V-y
a
Line resistance losses 1 x 0 10 2 V-y
a
Line reactance losses 1 x 0 10 3 V-y
Measurement methods
Algorithm for active power measurement 1 x 0 11 1
Algorithm for active energy measurement 1 x 0 11 2
Algorithm for reactive power measurement 1 x 0 11 3
Algorithm for reactive energy measurement 1 x 0 11 4
Algorithm for apparent power measurement 1 x 0 11 5
Algorithm for apparent energy measurement 1 x 0 11 6
Algorithm for power factor calculation 1 x 0 11 7
a
y can be set at any value between –1 and n ; for current values group F is not used.
b
If a transformer ratio is expressed as a fraction the ratio is numerator, divided by denominator. If the transformer ratio is
expressed by an integer or real figure, only the numerator is used.
REMARK If the value field F is shaded, then value group F is not used.
It has to be observed, that some of the codes above are normally not used, as the related data
items are covered by attributes of already defined objects (application dependent). See Clause 4
or IEC 62056-62.
5.4.9 List objects

Lists – identified with one single OBIS code – are defined as a series of any kind of data (e.g.
measurement value, constants, status, events).

Table 18 – General list objects

General list objects OBIS code
A B C D E F
a
Data of billing period 0 x 98 1 x VZ
a
see 5.5.3
5.4.10 Electricity data profile objects

Data profiles – identified with one single OBIS code – are defined as a series of measurement val-
ues of the same type or of groups of the same kind consisting of a number of different measure-
ment values.
Table 19 – Profile codes (electricity)

Electricity data profile objects OBIS-code
A B C D E F
a
Load profile with recording period 1 1 X 99 1 x
a
Load profile with recording period 2 1 X 99 2 x
Load profile during test 1 X 99 3 0
Dips voltage profile 1 X 99 10 1 0
Swells voltage profile 1 X 99 10 2 0
Cuts voltage profile 1 X 99 10 3 0
th
Voltage harmonic profile 1 X 99 11 n 0
th
Current harmonic profile 1 X 99 12 n 0
Voltage unbalance profile 1 X 99 13 0 0
a
Event log 1 x 99 98 x
a
Certification data log 1 x 99 99 x
a
If only one object of each kind is instantiated, the value shall be 0
5.5 Code presentation

Depending on the environment used the presentation of codes can be slightly different.
5.5.1 Reduced ID codes (e.g. for IEC 62056-21)

To comply with the syntax defined for protocol modes A to D of IEC 62056-21, the range of ID
codes is reduced to fulfil the limitations which are usually applied to the number of digits and the
ASCII representation of them. All value groups are limited to a range of 0 .. 99 and within that to
the limits given in the relevant chapters.
Some value groups may be suppressed, if they are not relevant to an application:
Optional value groups: A,B,E,F
Mandatory value groups: C,D
To allow the interpretation of shortened codes delimiters are inserted between all value groups:

A - B : C . D . E * F
Figure 12 – Reduced ID code presentation
The delimiter between value groups E and F can be modified to carry some information about the
source of a reset (& instead of * if the reset was performed manually).
For compatibility with existing implementations, in value group A an identifier for an energy type
may be used even for abstract objects.
5.5.2 Display
The usage of OBIS codes to display values is normally limited in a similar way as for data transfer,
e.g. according to IEC 62056-21.
Some codes may be replaced by letters to indicate clearly the differences from other data items:
Table 20 – Example of display code replacement

Value group C
OBIS code Display code
96 C
97 F
98 L
99 P
5.5.3 Special handling of value group F

Identifying values from previous billing periods uses the group F field to indicate the actual time
periods/point.
Table 21 – Values of billing periods
Value group F
VZ+1 Future period
VZ Period 1
VZ-1 Period 2
VZ-2 Period 3
VZ-3 Period 4
VZ-4 ...
etc.
101 Most recent value

102 Two most recent values
….
125 25 most recent values
126 unspecified number of most recent
values
The value of the most recent (youngest) billing period is identified using the ID-code VZ (state of
the billing period counter), and the second youngest is identified by the code VZ-1 etc. The oper-
ating mode of the billing period counter can differ, e.g. modulo-12 or modulo-100. The value that is
represented after reaching the limit of the billing period counter, contains the billing period value
code 0 for modulo-100, and 1 for other (e.g. modulo-12).

Values above 100 allow to identify profiles which contain values of more than one billing period.
The maximum allowed value for this is 125.
The value 126 identifies a profile with values of an unspecified number of billing periods.
For thresholds the value group F contains a reference into several threshold levels for the same
quantity (if applicable).
5.5.4 COSEM
The usage of OBIS codes in the COSEM environment is defined in Clause 4 or IEC 62056-62.

Bibliography
IEC 61334-6:1998, Distribution automation using distribution line carrier systems - Part 6: A-XDR
encoding rule
ITU Recommendation X.217 (04/95) - Information technology - Open Systems Interconnection -

Service definition for the association control service element
ITU Recommendation X.227 (04/95) - Information technology - Open Systems Interconnection

Connection-oriented protocol for the association control service element: Protocol specification
IEEE 754:1985 Standard for Binary Floating-Point Arithmetic

Index
AARE, 9 Demand, 18, 22, 23, 25, 26, 45, 57, 85
AARQ, 9 Demand Register (class_id: 5), 22
abstract, 62, 67, 80, 81 Device ID, 68, 69, 89
Abstract COSEM Objects, 62 Electrical Energy related COSEM Objects, 69
Abstract objects, 63, 82, 86, 88, 89, 90, 93 Electricity, 82, 83, 84, 87, 90, 92
Acknowledgement, 6 Electricity ID Numbers, 70
ACSE, 9, 17 encryption, 17, 42, 44
Activation, 24, 25, 37, 38, 57, 62, 64 Entries related to billing periods, 70
active, 11, 14, 20, 24, 25, 37, 41, 52, 59, 71, 72, error, 45, 51, 55, 56, 61, 69, 79, 82, 84, 90
74, 83, 90, 91 error Values, 69
Activity Calendar, 37, 65 Extended, 9, 21, 24, 25, 57, 70, 84, 88
Algorithm, 30, 36, 71, 72, 73, 74, 81, 91 Extended Register, 21
angle, 20, 84, 88 Foreword, 6
APDU, 9 frequency, 21, 31, 83
apparent, 20, 21, 72, 73, 74, 83, 90, 91 fundamental, 72, 73, 74, 88
ASE, 9 Gas, 81, 82
Association, 11, 16, 17, 39, 41, 43, 59, 62, 66, 67, General purpose, 62, 83, 90
78 General service, 82, 89
Association LN (class_id: 15), 39 GMT, 9, 14, 29, 30
Association Objects, 66 Guidelines for Assigning Short Names, 56
Association SN (class_id: 12), 43 harmonic, 72, 73, 74, 88, 92
Authentication, 16, 17, 39, 41, 42, 43, 44, 59, 79 HDLC, 9, 54, 61, 62, 66
A-XDR, 9 HDLC Setup, 66
base_name, 9, 43, 56, 61, 62 Heat, 81, 82
Basic Principles, 10 I/O Control Signals, 68
Battery, 89 IEC HDLC Setup, 54
billing period, 64, 65, 67, 69, 70, 81, 84, 85, 88, IEC Local Port Setup, 49
90, 91, 92, 93 IEC Twisted Pair (1) Setup, 55, 66
Broadcast, 55, 64 Input and Output Pulse Constants, Nominal
Calendar, 36, 37, 38, 39, 47, 59, 62, 64, 65 Values, 71
calibration, 89 instantiation, 8, 10, 11, 12, 13, 19, 45, 49, 62, 65
challenge, 17, 42, 44, 78, 79 interface classes, 18
channel, 17, 54, 63, 69, 70, 80, 82, 89 Internal Status, 69
Class Description Notation, 11 Introduction, 8
Clock, 11, 14, 18, 26, 28, 29, 30, 35, 36, 58, 62, limit, 26, 52, 85, 93
63, 71, 75, 91 load profile, 85, 91, 92
Coding of OBIS Identifications, 74 logical device, 11, 15, 16, 32, 37, 39, 43, 45, 49,
Common Data Types, 12 55, 62, 67
Complex data types, 13 losses, 91
configuration, 12, 19, 50, 60, 62, 63, 68, 71, 80, Maintenance of the Interface Classes, 48
89, 90 manufacturer specific, 11, 14, 19, 35, 36, 52, 62,
control signals, 89 74, 81, 82, 83, 84, 85, 87, 89
Copyright, 6 Mapping of Data Items, 62
COSEM Interface Objects, 10 maximum, 12, 26, 41, 53, 54, 63, 65, 69, 76, 84,
COSEM Logical Device Name, 67 85, 90, 94
COSEM Object Identification System (OBIS), 80 Measurement, 71
country specific, 82, 86, 87 meter reset, 64
current, 8, 72, 73, 74, 81, 83, 84, 85, 87, 88, 90, minimum, 12, 50, 69, 84, 85
91, 92 Modem, 50, 51, 52, 53, 60, 62, 63
current association, 17 Monitor, 45, 46, 60, 71
Data, 11, 12, 13, 19, 20, 21, 22, 23, 25, 26, 30, 32, New Interface Classes, 48
33, 34, 35, 36, 37, 39, 43, 45, 46, 47, 48, 49, 50, New Versions of Interface Classes, 49
52, 53, 54, 55, 56 OBIS, 6, 7, 9, 11, 12, 19, 62, 63, 64, 65, 66, 67,
Data format, 12, 13 68, 69, 70, 71, 72, 73, 74
Data formats for date and time notation, 13 object_list, 16, 39, 42, 43, 59, 78
Data of previous billing periods, 70 Parameter Changes, 68
daylight saving, 14 password, 17, 44, 50, 79

PDU, 7, 9, 41 Schedule, 33, 35, 36, 37, 47, 48, 58, 60, 62, 64,
physical device, 15, 16, 45, 55, 63, 64, 65 65
Port Setup, 49, 60, 62, 65 Scope, 7
power factor, 74, 83, 91 script, 32, 33, 34, 35, 38, 46, 48, 58, 60, 62, 64
power fail, 34, 35, 37, 69, 89 Script Table, 32, 64
Previous Versions of Interface Classes, 75 secret, 17, 39, 41, 42, 43, 44, 45, 59, 78
profile, 11, 18, 26, 27, 29, 37, 38, 51, 58, 66, 68, selective access, 12, 27, 28, 39, 41, 43, 47, 58
75, 91, 92 server model, 8, 15
profile Generic (class_id: 7), 26 simple data types, 13, 24, 46
program, 89, 90 Single Action, 47, 48, 60, 62, 65
program changes, 68 Single Action Schedule, 47, 65
Program Entries, 71 Special Days, 33, 34, 36, 59, 62, 64
proprietary, 10 Special Days Table, 36, 64
Protocol related Interface Classes, 49 Standard Readout Profile, 66
PSTN, 50, 52, 53, 60, 61, 62, 63, 64 Status of standardisation, 6
PSTN Auto Answer, 52, 63 Table of Contents, 3
PSTN Auto Dial, 53, 63 Terms, Definitions and Abbreviations, 9
PSTN Modem Configuration, 50, 63 test mode, 64
quadrant, 84 Threshold Values, 71
Rate, 25, 87 Time, 9, 13, 14, 18, 84, 85, 89, 90, 91
Ratios, 71, 90 Time Changes, 35
RCR, 71, 90 Time integral, 70, 84, 85
reactive, 8, 11, 20, 72, 83, 90, 91 time setting, 35
readout, 29, 62, 66 time switch, 68, 71, 89
Referenced Documents, 8 Total, 87, 88, 89
Referencing COSEM objects, using SN, 56 Twisted Pair, 9, 61, 62, 66
Register, 11, 18, 19, 21, 23, 25, 27, 28, 46, 57, 60, Utility Tables, 46, 47, 60, 63, 67, 68
62, 67, 69, 81 Value Group A, 74, 81, 82, 88, 93
Register Activation, 24 Value Group B, 63, 64, 65, 66, 81, 82
Register Monitor, 45 Value Group C, 62, 81, 82, 83, 88, 93
Relation to OBIS, 62 Value Group D, 64, 65, 69, 81, 84, 86, 88
Removal of Interface Classes, 49 Value Group E, 63, 65, 81, 86, 87, 88
Reserved base_names, 61 Value Group F, 70, 81, 88, 91, 93, 94
Revision History, 9 voltage, 20, 72, 73, 74, 81, 83, 84, 87, 88, 89, 90,
SAP, 16, 40, 45, 59, 62, 67 91, 92
SAP Assignment, 45 Water, 81, 82
SAP Assignment Object, 67


DLMS Blue Book 4Th Edition Internet

Uploaded by

Copyright:

Available Formats

DLMS Blue Book 4Th Edition Internet

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DLMS Blue Book 4Th Edition Internet

Uploaded by

Copyright:

Available Formats

TECHNICAL REPORT

DLMS User Association

Reference number: DLMS UA 1000-1:2001, Fourth Edition

DLMS User Association DLMS UA 1000-1 ed.4 2/97

4. COSEM Interface Classes ................................................................................................. 10

DLMS User Association DLMS UA 1000-1 ed.4 3/97

4.4.4 PSTN Auto Dial (class_id: 29)......................................................................................... 53

5. COSEM Object Identification System (OBIS)................................................................... 80

DLMS User Association DLMS UA 1000-1 ed.4 4/97

DLMS User Association DLMS UA 1000-1 ed.4 5/97

© Copyright 1997-2001 DLMS User Association.

DLMS User Association DLMS UA 1000-1 ed.4 6/97

Step 1:The meter model and data identi-

Step 3:The transportation of the bits and Messages :

• The lower layers of the protocol transport the information.

DLMS User Association DLMS UA 1000-1 ed.4 7/97

3.1 Referenced Documents

DLMS User Association DLMS UA 1000-1 ed.4 8/97

3.2 Terms, Definitions and Abbreviations

3.3 Revision History

DLMS User Association DLMS UA 1000-1 ed.4 9/97

4. COSEM Interface Classes

4.1 Basic Principles

The information of an object is organised in attributes. They represent the characteristics of an

Figure 2 illustrates these terms by means of an example:

Register class_id=3 Total Positive

Figure 2 – An interface class and its instances

DLMS User Association DLMS UA 1000-1 ed.4 10/97

4.1.2 Class Description Notation

Each attribute and method must be described in detail.

value The class shall be instantiated exactly “value” times.

DLMS User Association DLMS UA 1000-1 ed.4 11/97

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

(static) Classifies an attribute which is not updated by the meter

x The attribute has a minimum value.

<empty> The attribute has no minimal value.

x The attribute has a maximum value.

<empty> The attribute has no maximum value.

x The attribute has a default value.

<empty> The default value is not defined by the class definition. .

m (mandatory) The method is mandatory.

o (optional) The method is optional.

4.1.3 Common Data Types

DLMS User Association DLMS UA 1000-1 ed.4 12/97

bit-string An ordered sequence of boolean values.

4.1.4 Data formats for date and time notation

year: interpreted as unsigned16

month: interpreted as unsigned8

dayOfMonth: interpreted as unsigned8

DLMS User Association DLMS UA 1000-1 ed.4 13/97

dayOfWeek: interpreted as unsigned8

time octet-string {hour, minute, second, hundredths}

deviation Integer16 -720..720:

clock_status Unsigned8 interpreted as 8 bit string

The status bits are defined as follows:

DLMS User Association DLMS UA 1000-1 ed.4 14/97

different from the source specified in clock_base

4.1.5 The COSEM server model

Level 1: Physical Device