Blue Book Edition 13-Excerpt PDF
Blue Book Edition 13-Excerpt PDF
Blue Book Edition 13-Excerpt PDF
Companion Specification
for Energy Metering
CONTENTS
Foreword to this Excerpt ....................................................................................................... 13
Foreword .............................................................................................................................. 13
List of main technical changes in Edition 13 ..................................................................... 15
Introduction........................................................................................................................... 16
1 Scope ............................................................................................................................ 17
2 Referenced documents .................................................................................................. 18
3 Terms, definitions and abbreviated terms ...................................................................... 21
3.1 Terms and definitions related to the Image transfer process (see 4.4.6) ................ 21
3.2 Terms and definitions related to the S-FSK PLC setup ICs (see 4.10) ................... 22
3.3 Terms and definitions related to the PRIME NB OFDM PLC setup ICs (see
4.12) ..................................................................................................................... 22
3.4 Terms and definitions related to ZigBee® (see 4.15) ............................................. 23
3.5 Terms and definitions related to Payment metering ICs (see 4.6) .......................... 24
3.6 Terms and definitions related to the Arbitrator IC (see 4.5.12) .............................. 26
3.7 Abbreviated terms ................................................................................................. 26
4 The COSEM interface classes ....................................................................................... 32
4.1 Basic principles ..................................................................................................... 32
4.1.1 General ......................................................................................................... 32
4.1.2 Referencing methods ..................................................................................... 33
4.1.3 Reserved base_names for special COSEM objects ........................................ 33
4.1.4 Class description notation .............................................................................. 33
4.1.5 Common data types ....................................................................................... 36
4.1.6 Data formats .................................................................................................. 37
4.1.7 The COSEM server model ............................................................................. 41
4.1.8 COSEM logical device ................................................................................... 41
4.1.9 Information security ....................................................................................... 43
4.2 Overview of the COSEM interface classes ............................................................ 44
4.3 Interface classes for parameters and measurement data ...................................... 49
4.3.1 Data (class_id = 1, version = 0) ..................................................................... 49
4.3.2 Register (class_id = 3, version = 0) ............................................................... 50
4.3.3 Extended register (class_id = 4, version = 0) ................................................. 54
4.3.4 Demand register (class_id = 5, version = 0) ................................................... 55
4.3.5 Register activation (class_id = 6, version = 0) ................................................ 55
4.3.6 Profile generic (class_id = 7, version = 1) ...................................................... 56
4.3.7 Utility tables (class_id = 26, version = 0) ....................................................... 56
4.3.8 Register table (class_id = 61, version = 0) ..................................................... 56
4.3.9 Status mapping (class_id = 63, version = 0) .................................................. 56
4.3.10 Compact data (class_id = 62, version = 1) ..................................................... 56
4.4 Interface classes for access control and management .......................................... 61
4.4.1 Overview ....................................................................................................... 61
4.4.2 Client user identification ................................................................................ 61
4.4.3 Association SN class (class_id = 12, version 4) ............................................. 62
4.4.4 Association LN class (class_id = 15, version 3) ............................................. 62
Table 57 – OBIS codes for general and service entry objects – Electricity .......................... 191
Table 58 – OBIS codes for error register objects – Electricity ............................................. 195
Table 59 – OBIS codes for list objects – Electricity ............................................................. 195
Table 60 – OBIS codes for data profile objects – Electricity ................................................ 195
Table 61 – OBIS codes for Register table objects – Electricity ............................................ 196
Table 62 – Value group C codes – HCA .............................................................................. 197
Table 63 – Value group D codes – HCA .............................................................................. 198
Table 64 – Value group E codes – HCA .............................................................................. 198
Table 65 – OBIS codes for general and service entry objects – HCA .................................. 199
Table 66 – OBIS codes for error register objects – HCA ..................................................... 200
Table 67 – OBIS codes for list objects – HCA ..................................................................... 200
Table 68 – OBIS codes for data profile objects – HCA ........................................................ 201
Table 69 – OBIS codes for HCA related objects (examples) ................................................ 201
Table 70 – Value group C codes – Thermal energy ............................................................. 202
Table 71 – Value group D codes – Thermal energy ............................................................. 203
Table 72 – Value group E codes – Thermal Energy – Tariff rates ........................................ 204
Table 73 – OBIS codes for general and service entry objects – Thermal energy ................. 204
Table 74 – OBIS codes for error register objects – Thermal energy .................................... 206
Table 75 – OBIS codes for list objects – Thermal Energy Meters ........................................ 207
Table 76 – OBIS codes for data profile objects – Thermal energy ....................................... 207
Table 77 – OBIS codes for Thermal energy related objects (examples) ............................... 207
Table 78 – OBIS codes of the main objects in the gas conversion process data flow .......... 214
Table 79 – Value group C codes – Gas ............................................................................... 216
Table 80 – Value group D codes – Gas – Indexes and index differences............................. 219
Table 81 – Value group D codes – Gas – Flow rate ............................................................ 223
Table 82 – Value group D codes – Gas – Process values ................................................... 225
Table 83 – Value group D codes – Gas – Conversion related factors and coefficients ......... 228
Table 84 – Value group D codes – Gas – Natural gas analysis values ................................ 229
Table 85 – Value group E codes – Gas – Indexes and index differences – Tariff rates ........ 230
Table 86 – Value group E codes – Gas – Conversion related factors and coefficients ......... 231
Table 87 – Value group E codes – Gas – Calculation methods............................................ 232
Table 88 – Value group E codes – Gas – Natural gas analysis values – Averages .............. 232
Table 89 – OBIS codes for general and service entry objects – Gas ................................... 233
Table 90 – OBIS codes for error register objects – Gas ...................................................... 240
Table 91 – OBIS codes for list objects – Gas ...................................................................... 240
Table 92 – OBIS codes for data profile objects – Gas ......................................................... 241
Table 93 – Value group C codes – Water ............................................................................ 242
Table 94 – Value group D codes – Water ............................................................................ 242
Table 95 – Value group E codes – Water ............................................................................ 243
Table 96 – OBIS codes for general and service entry objects – Water ................................ 243
Table 97 – OBIS codes for error register objects – Water ................................................... 244
Table 98 – OBIS codes for list objects – Water Meters ........................................................ 244
Table 99 – OBIS codes for data profile objects – Water ...................................................... 245
Table 100 – OBIS codes for water related objects (examples) ............................................ 245
Table 101 – Value group C codes – Other media ................................................................ 246
Table 102 – Example of display code replacement .............................................................. 247
Table 103 – Value group F – Billing periods ........................................................................ 248
Foreword
Copyright
This document is confidential. It may not be copied, nor handed over to persons outside the
standardization environment.
The copyright is enforced by national and international law. The "Berne Convention for the
Protection of Literary and Artistic Works", which is signed by 176 countries world-wide, and
other treaties apply.
Liability
DLMS User Association Publications have the form of recommendations for international use.
While all reasonable efforts are made to ensure that the technical content of DLMS User
Association Publications is accurate, the DLMS User Association cannot be held responsible
for the way in which they are used or for any misinterpretation by any end user.
No liability shall attach to DLMS User Association or its directors, employees, servants or
agents including individual experts and members of its technical committees for any personal
injury, property damage or other damage of any nature whatsoever, whether direct or indirect,
or for costs (including legal fees) and expenses arising out of the publication, use of, or reliance
upon, this DLMS User Association Publication or any other DLMS User Association
Publications.
The DLMS User Association (DLMS UA) draws attention to the fact that it is claimed that
compliance with this document may involve the use of a patent concerning the Image transfer
procedure.
The DLMS UA takes no position concerning the evidence, validity and scope of this patent right.
The holder of this patent right has assured the DLMS UA that he/she is willing to negotiate
licenses either free of charge or under reasonable and non-discriminatory terms and conditions
with applicants throughout the world. In this respect, the statement of the holder of this patent
right is registered with the DLMS UA. Information may be obtained from Itron, Inc., Liberty Lake,
Washington, USA.
Attention is drawn to the possibility that some of the elements of this document may be the
subject of patent rights other than those identified above. The DLMS UA shall not be held
responsible for identifying any or all such patent rights.
The DLMS UA maintains on-line databases of patents relevant to their standards. Users are
encouraged to consult the databases for the most up to date information concerning patents.
Acknowledgement
The actual document has been established by the WG Maintenance of the DLMS UA.
Clauses 4.4.7 and 4.4.9 are based on parts of NIST documents. Reprinted courtesy of the
National Institute of Standards and Technology, Technology Administration, U.S. Department
of Commerce. Not copyrightable in the United States.
Status of standardization
• IEC 62056-6-1 Ed. 3:2017, Electricity Metering Data Exchange – The DLMS/COSEM suite
– Part 6-1: Object identification system (OBIS); and
• IEC 62056-6-2 Ed. 3:2017, Electricity Metering Data Exchange – The DLMS/COSEM suite
– Part 6-2: COSEM interface classes.
1. Addition of firmware – related objects to the mandatory list of objects to ensure that product
4.1.8.4
. certifications by the DLMS UA have improved traceability.
Addition of non-SI units, footnote for converted volume, formula to describe Force (Newtons)
2. 4.3.2
and alternate pressure units (g/cm 2 , atm) to Table 4.
Update to the G3-PLC setup interface classes: including the G3-PLC MAC setup (class_id = 91)
5. 4.13 and the G3-PLC 6LoWPAN adaptation layer setup (class_id = 92) to be in line with IUT-T
9903:2017.
Generic clause added to permit Data IC (class_id = 1) to be replaced with Register IC (class_id
6. 6
= 3) or Extended register IC (class_id = 4) in many applications, and related notes removed.
Additional value group C codes for reactive power inductive and capacitative, and line-to-line
11. 7.5.1
voltage.
12. 7.5.2.1 Additional value group D codes for average values for recording intervals 1 & 2.
Introduction
Object modelling and data identification
Driven by the business needs of the energy market participants – generally in a liberalized,
competitive environment – and by the desire to manage natural resources efficiently and to
involve the consumers, the utility meter became part of an integrated metering, control and
billing system. The meter is not any more a simple data recording device but it relies critically
on communication capabilities. Ease of system integration, interoperability and data security
are important requirements.
COSEM, the Companion Specification for Energy Metering, addresses these challenges by
looking at the utility meter as part of a complex measurement and control system. The meter
has to be able to convey measurement results from the metering points to the business
processes which use them. It also has to be able to provide information to the consumer and
manage consumption and eventually local generation.
COSEM achieves this by using object modelling techniques to model all functions of the meter,
without making any assumptions about which functions need to be supported, how those
functions are implemented and how the data are transported. The formal specification of
COSEM interface classes forms a major part of COSEM.
To process and manage the information it is necessary to uniquely identify all data items in a
manufacturer-independent way. The definition of OBIS, the Object Identification System is
another essential part of COSEM. It is based on DIN 43863-3:1997, Electricity meters – Part
3: Tariff metering device as additional equipment for electricity meters – EDIS – Energy Data
Identification System. The set of OBIS codes has been considerably extended over the years
to meet new needs.
COSEM models the utility meter as a server application – see 4.1.7 – used by client applications
that retrieve data from, provide control information to, and instigate known actions within the
meter via controlled access to the COSEM objects. The clients act as agents for third parties
i.e. the business processes of energy market participants.
The standardized COSEM interface classes form an extensible library. Manufacturers use
elements of this library to design their products that meet a wide variety of requirements.
The server offers means to retrieve the functions supported, i.e. the COSEM objects
instantiated. The objects can be organized to logical devices and application associations and
to provide specific access rights to various clients.
The concept of the standardized interface class library provides different users and
manufacturers with a maximum of diversity while ensuring interoperability.
1 Scope
The DLMS/COSEM specification specifies
a data model and communication protocols 1. Modelling COSEM Interface Objects
for data exchange with metering
equipment. It follows a three-step approach n
t io
as illustrated in Figure 1. cia
soVersion=0
As Max Def
Register 0..n Class_id=3,
Attribute(s) Data Type Min
Step 1 is specified in this document. It specifies the COSEM interface classes (ICs), the OBIS
object identification system, and the use of interface objects for modelling the various functions
of the metering equipment.
Step 2 and 3 are specified in the Green Book,DLMS UA 1000-2 Ed. 9. It specifies
communication profiles for various communication media and the protocol layers of these
communication profiles. The top layer in any profile is the DLMS/COSEM application layer. It
provides services to establish a logical connection between the client and the server(s). It also
provides the xDLMS messaging services to access attributes and methods of the COSEM
interface objects. The lower, communication profile specific protocol layers transport the
information.
Rules for conformance testing are specified in the “Yellow Book”, DLMS UA 1001-1
"DLMS/COSEM Conformance Test Process".
Terms are explained in the “White book” DLMS UA 1002, "COSEM Glossary of Terms".
2 Referenced documents
Reference Title
DLMS UA 1000-2 Ed. 9 DLMS/COSEM Architecture and Protocols, the “Green Book” Edition 9
DLMS UA 1001-1 DLMS/COSEM Conformance test and certification process, the “Yellow Book”
DLMS UA 1002 COSEM Glossary of terms, the “White Book”
Electromagnetic compatibility (EMC) – Part 2-8: Environment - Voltage dips and short
IEC TR 61000-2-8:2002
interruptions on public electric power supply systems with statistical measurement results
Distribution automation using distribution line carrier systems – Part 4: Data communication
IEC 61334-4-32:1996
protocols – Section 32: Data link layer – Logical link control (LLC)
Distribution automation using distribution line carrier systems – Part 4: Data communication
IEC 61334-4-41:1996
protocols – Section 41: Application protocols – Distribution line message specification
Distribution automation using distribution line carrier systems – Part 4-511: Data
IEC 61334-4-511:2000
communication protocols – Systems management – CIASE protocol
Distribution automation using distribution line carrier systems – Part 4-512: Data
IEC 61334-4-512:2001 communication protocols – System management using profile 61334-5-1 – Management
Information Base (MIB)
Distribution automation using distribution line carrier systems – Part 5-1: Lower layer
IEC 61334-5-1:2001
profiles – The spread frequency shift keying (S-FSK) profile
Electricity metering equipment (a.c.) – Particular requirements – Part 23: Static meters for
IEC 62053-23:2003
reactive energy (classes 2 and 3)
Technical report Electricity metering - Payment systems- Part 21: Framework for
IEC TR 62055-21:2005
standardization. 2005-8
Electricity metering – Data exchange for meter reading, tariff and load control –
IEC 62056-21:2002
Part 21: Direct local data exchange
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-31:1999
NOTE This Edition is referenced in the interface class “IEC twisted pair (1) setup”
(class_id: 24, version: 0)
Electricity metering data exchange – The DLMS/COSEM suite – Part 3-1: Use of local area
networks on twisted pair with carrier signalling
IEC 62056-3-1:2013
NOTE This Edition is referenced in the interface class “IEC twisted pair (1) setup”
(class_id: 24, version: 1)
13/1652/CDV, ELECTRICITY METERING DATA EXCHANGE – THE DLMS/COSEM SUITE
IEC 62056-8-6: 2017
– Part 8-6: High speed PLC ISO/IEC 12139-1 profile for neighbourhood networks
IEEE Standard for Information technology – Telecommunications and information exchange
ISO/IEC 8802-2:1998 between systems – Local and metropolitan area networks – Specific requirements – Part 2:
Logical Link Control
Information technology —Telecommunications and information exchange between systems
ISO/IEC 12139-1:2009 — Powerline communication (PLC) — High speed PLC medium access control (MAC) and
physical layer (PHY) — Part 1: General requirements
ISO/IEC/IEEE Information technology – Microprocessor Systems – Floating-Point arithmetic
60559:2011
ISO 4217 Codes for the representation of currencies and funds
SERIES E: OVERALL NETWORK OPERATION,TELEPHONE SERVICE, SERVICE
OPERATION AND HUMAN FACTORS - International operation – Maritime mobile service
ITU-T E.212 (05.2008)
and public land mobile service - The international identification plan for public networks
and subscriptions
3GPP TS 24.301 Technical Specification Group Core Network and Terminals; Non-Access-Stratum (NAS)
V13.4.0 (2016-01) protocol for Evolved Packet System (EPS); Stage 3
SERIES G: TRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS AND
NETWORKS – Access networks – In premises networks – Narrow-band orthogonal
ITU-T G.9903 Amd. frequency division multiplexing power line communication transceivers for G3-PLC
1:2013 networks
NOTE This Recommendation is referenced in version 0 of the G3-PLC setup classes.
Reference Title
ITU-T G.9903:2014 SERIES G: TRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS AND
NETWORKS – Access networks – In premises networks –
Narrow-band orthogonal frequency division multiplexing power line communication
transceivers for G3-PLC networks
NOTE This Recommendation is referenced in version 1 of the G3-PLC setup classes.
SERIES G: TRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS AND
NETWORKS - Access networks – In premises networks - Narrowband orthogonal frequency
ITU-T G.9903:2017 division multiplexing power line communication transceivers for G3-PLC networks
NOTE This Recommendation is referenced in current version of the G3-PLC setup classes.
SERIES G: TRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS AND
ITU-T G.9904:2012 NETWORKS – Access networks – In premises networks – Narrow-band orthogonal
frequency division multiplexing power line communication transceivers for PRIME networks
Heat cost allocators for the determination of the consumption of room heating radiators –
EN 834:1994
Appliances with electrical energy supply
EN 1434-1:2015 Heat meters – Part 1: General requirements
EN 1434-2:2015 Heat meters – Part 2: Constructional requirements
EN 13757-1:2014 Communication system for meters – Part 1: Data exchange
Communication systems for meters and remote reading of meters – Part 2: Physical and
EN 13757-2
link layer
Communication systems for and remote reading of meters – Part 3: Dedicated application
EN 13757-3:2004 layer
NOTE This standard is referenced in the “M-Bus client setup” interface class version 0.
Communication systems for meters – Part 3: Dedicated application layer
EN 13757-3:2018
NOTE This standard is referenced in the M-Bus client setup interface class version 1.
EN 13757-4:2013 Communication system for and remote reading of meters – Part 4: Wireless meter (Radio
meter reading for operation in SRD bands)
EN 13757-5:2015 Communication systems for meters – Part 5: Wireless M-Bus relaying
EN 13757-7:2018 Communication system for meters – Part 7: Transport and security services
IEEE 802.15.4: 2006 IEEE 802.15.4-2006 Standard for Information technology – Telecommunications and
information exchange between systems – Local and metropolitan area networks – Specific
requirements – Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer
also available as (PHY) Specifications for Low-Rate Wireless Personal Area Networks (WPANs) –
ISO/IEC/IEEE 8802-15-4 September 2006.
Ed 1.0
ETSI GSM 05.08 Digital cellular telecommunications system (Phase 2+); Radio subsystem link control
ANSI C12.19:2012 American National Standard For Utility Industry End Device Data Tables
ZigBee® Specification. The specification can be downloaded free of charge from
ZigBee® 053474
https://www.zigbee.org/zigbee-for-developers/zigbee-pro/
The following RFCs are available online from the Internet Engineering Task Force (IETF):
http://www.ietf.org/rfc/std-index.txt, http://www.ietf.org/rfc/
IETF STD 51 The Point-to-Point Protocol (PPP), 1994. (Also RFC 1661, RFC 1662)
RFC 1144 Compressing TCP/IP Headers for Low-Speed Serial Links, 1990
The PPP Internet Protocol Control Protocol (IPCP), 1992, Updated by: RFC 3241.
RFC 1332
Obsoletes: RFC 1172
The Point-to-Point Protocol (PPP) (Also: IETF STD 0051), 1994, Updated by: RFC 2153,
IETF STD 51 / RFC 1661
Obsoletes: RFC 1548
IETF STD 51 / RFC 1662 PPP in HDLC-like Framing, (Also: IETF STD 0051), 1994, Obsoletes: RFC 1549
Reference Title
RFC 1994 PPP Challenge Handshake Authentication Protocol (CHAP), 1996. Obsoletes: RFC
Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers,
RFC 2474
1998
RFC 2508 Compressing IP/UDP/RTP Headers for Low-Speed Serial Links, 1999
RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and
RFC 3095
uncompressed, 2001
RFC 3241 Robust Header Compression (ROHC) over PPP, 2002. Updates: RFC1332
RFC 4944 Internet Engineering Task Force (IETF). RFC 4944: Transmission of IPv6 Packets over
IEEE 802.15.4 Networks [online]. Edited by G. Montenegro, N. Kushalnagar and D. Culler.
September 2007
RFC 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL)
Profile, 2008
RFC 5905 Network Time Protocol Version 4: Protocol and Algorithms Specification, 2010.
RFC 6282 Internet Engineering Task Force (IETF). RFC 6282: Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks [online]. Edited by J. Hui, Ed. September
2011
Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks
RFC 6775
(6LoWPANs), 2012
ISO and IEC maintain terminological databases for use in standardization at the following
addresses:
Image binary data of a specified size Note 1 to entry: An Image can be seen as
a container. It may consist of one or multiple elements (image_to_activate)
which are transferred, verified and activated together.
ImageSize size of the whole Image to be transferred Note 1 to entry: ImageSize is
expressed in octets.
ImageBlock part of the Image of size ImageBlockSize Note 1 to entry: The Image is
transferred in ImageBlocks. Each block is identified by its ImageBlockNumber.
ImageBlockSize size of ImageBlock expressed in octets
ImageBlockNumber identifier of an ImageBlock. ImageBlocks are numbered sequentially, starting
from 0.
Image
ImageBlock 0 ImageBlockSize
ImageBlock 1
ImageBlock 2
ImageSize
ImageBlock 3
...
ImageBlock n-1
switch state <of a when in this functional state a service node is able to perform all Terminal functions.
service node> Additionally, it is able to forward data to and from other nodes in the same subnetwork. It
is a branch point on the tree structure [SOURCE: ITU-T G.9904:2012 8.1]
promotion the process by which a service node is qualified to switch (repeat, forward) data traffic
from other nodes and act as a branch point on the subnetwork tree structure. A
successful promotion represents the transition between Terminal and Switch state. When
a service node is in the Disconnected state, it cannot directly transition to Switch state
[SOURCE: ITU-T G.9904:2012 8.1]
demotion the process by which a service node ceases to be a branch point on the subnetwork tree
structure. A successful demotion represents the transition between Switch and Terminal
state [SOURCE: ITU-T G.9904:2012 8.1]
Term Definition
CAD Consumer Access Device; a ZigBee® gateway device that acts like an IHD within the
ZigBee® network, but has an additional connection to a different network (i.e. WiFi)
IHD in Home Display; a device that has a screen for the displaying of Energy information to
the consumer
install code a Hashed (via MMO) Pre-Configured Linked Key (PCLK) that is provided to a Trust
Center via out-of-band communications. A new device wishing to join the network would
need to send this install code to the Trust Center, which would allow the Trust Center to
execute the joining process, using this install code as part of the security information
link key * this is a key that is shared exclusively between two, and only two, peer application-layer
entities within a PAN
MAC address/IEEE these are used synonymously to represent the EUI-64 code allocated to the ZigBee®
address Radio
ZigBee® ZigBee® is a specification for a suite of high level communication protocols used to
create personal area networks built from small, low-power digital radios. ZigBee® is
based on an IEEE 802.15 standard. Though low-powered, ZigBee® devices often
transmit data over longer distances by passing data through intermediate devices to
reach more distant ones, creating a mesh network
ZigBee® client this is similar to the role of the DLMS/COSEM Client. For a greater understanding of the
interaction between the client and server the ZigBee® PRO specification should be read
ZigBee® coordinator * an IEEE 802.15.4-2003 PAN coordinator that is the principal controller of an IEEE
802.15.4-2003-based network that is responsible for network formation. The PAN
coordinator must be a full function device (FFD)
ZigBee® cluster a set of message types related to a certain device function (e.g. metering, ballast
control)
ZigBee® mirror a device which echoes data being published by a battery operated ZigBee® device,
allowing other network actors to obtain data while the battery operated device is
unavailable due to power saving
ZigBee® PRO an alternative name for the ZigBee® 2007 protocol. ZigBee® 2007, now the current stack
release, contains two stack profiles, stack profile 1 (simply called ZigBee®), for home
and light commercial use, and stack profile 2 (called ZigBee® PRO). ZigBee® PRO
offers more features, such as multi-casting, many-to-one routing and high security with
Symmetric-Key Key Exchange (SKKE), while ZigBee® (stack profile 1) offers a smaller
footprint in RAM and flash. Both offer full mesh networking and work with all ZigBee®
application profiles
ZigBee® router * an IEEE 802.15.4-2003 FFD participating in a ZigBee® network, which is not the
ZigBee® coordinator but may act as an IEEE 802.15.4-2003 coordinator within its
personal operating space, that is capable of routing messages between devices and
supporting associations
ZigBee® server this is similar to the role of the DLMS/COSEM Server. Note 1 to entry: For a greater
understanding of the interaction between the client and server the ZigBee® PRO
specification should be read.
ZigBee® Trust Center the device trusted by devices within a ZigBee® network to distribute keys for the purpose
* of network and end-to-end application configuration management
local communications mechanism of communicating with the meter over some media, within the vicinity of
that meter such as over a HAN or optical port
manual entry entering of a token to the payment metering installation via means of a manual
process
managed payment specialisation of credit mode that allows operation of an Account, Credit and possibly
mode Charges in a meter where the payment for the service is received by the utility after
the service has been consumed Note 1 to entry: When in managed payment mode
tokens are not normally used, however the credit is adjusted using the methods in
the “Credit” object. Note 2 to entry: The meter is allowed to go into an allowable
amount of debt before being credited from the client in line with a received cash
payment by the utility. Note 3 to entry: In this example cash is used as a generic term
for a real life payment of currency to the utility which could be executed as legal
tender, automated electronic transfer etc.
payment metering set of payment metering equipment installed and ready for use at a consumer’s
installation premise Note 1 to entry: This includes mounting the equipment as appropriate, and
where a multi-device installation is involved, the connection of each unit of
equipment as appropriate. It also includes the connection of utility supply network to
each supply interface, the connection of the consumer’s load interface, and the
commissioning of the equipment into an operational state as a payment metering
installation.
prepayment mode mode of operation of a meter in a payment system, whereby the consumer pays for
service in advance of consumption
post-payment method of operation of a payment system whereby a consumer may consume service
before paying for it Note 1 to entry: This term can be used interchangeably with the
term Credit mode when used in the context of operational modes. Note 2 to entry:
This term is usually used in conjunction with a system description whereas
Credit mode is used when referring to the operational mode of a meter or account.
remote communications transportation of a token or other message from a client to a server running a
payment metering application process via some form of WAN and access network.
This could be point to point, mesh radio, fibre optic connection etc. and may travel
through multiple devices and over multiple protocols before reaching the meter
repayable credit types such as emergency credit where an amount added to
current_credit_amount of a “Credit” object has to be repaid before the Credit is
selectable again
reserved credit amount of credit that is held in reserve in the account of a payment meter, for use at
a later time, at the discretion of the consumer Note 1 to entry: The mechanism for
reserving this credit may be subject to agreement between the utility supplier and the
consumer. For example a proportion of every token may be added to the reserve
Credit or the supplier might give the consumer an allowance every month, but these
arrangements will be project specific.
selectable specific state of a “Credit” object where the consumer’s immediate confirmation is
needed before it can be brought into use Note 1 to entry: For example, Emergency
Credit has the nature of a short-term loan and should therefore only be deployed with
the consumer’s agreement. The term refers respectively to the need to get
agreement and to the fact of having received agreement. Only a ”Credit” made (1)
Selectable can be (2) Selected / Invoked. Not all Credits need to be selected by an
external trigger, as in most cases the meter application automatically performs this
action.
selected/invoked specific state of a “Credit” object where the value of current_credit_amount is
included in the calculation of available_credit in the related “Account”.Note 1 to entry:
This is the state of a Credit before becoming In use and is considered in the
available_credit attribute of the “Account”, but is not yet being consumed by any
Charge (due to a higher priority Credit being In use.
service provision of a commodity (such as water, electricity gas or heat)
social credit credit that is given free of payment for reasons such as the relief of poverty Note 1 to
entry: Typically such a credit is given at fixed times (e.g. monthly) in limited amounts.
This particular type of credit could also be consumption based, such that that the
consumer must keep consumption below a limiting threshold in order to use the
social credit. This could be controlled by the consumer being disconnected if the limit
is breached. Note 2 to entry: Social credits are modelled of “Credit” objects of type
emergency_credit, time_based_credit, consumption_based_credit.
temporary debt transient liability to the meter that accrues when Charges are collected at a time
when all credits are exhausted Note1 to entry: This temporary debt amount is
accumulated in amount_to_clear in the “Account” object.
token self-contained package of data related to the purchase of credit or to other system
functions, embodied in a token carrier (q.v.). The token forms a link between source
and destination of the transaction. The token contents may reflect money, energy,
time, etc., in harmony with the currency declared in the meter Note 1 to entry:
Defined in IEC TR 62055-21:2005 as ““<Equipment-related definition>[sic]
information content including an instruction issued on a token carrier by a vending or
management system that is capable of subsequent transfer to and acceptance by a
specific payment meter, or one of a group of meters, with appropriate security”.
token carrier means of transferring a token from one system element to another, typically in
material “physical” or electronic “virtual” form Note 1 to entry: In a general sense, the
token refers to the instruction and information being transferred, while the token
carrier refers to the physical device being used to carry the instruction and
information, or to the communications medium in the case of a virtual token carrier.
token carrier interface interface between the token carrier and the payment metering installation Note 1 to
entry: For example, it may be a keypad for numeric tokens, or a physical token
carrier acceptor, or a communications connection to a local or remote machine for a
virtual token carrier interface. Note 2 to entry: The token carrier interface may also
be used to pass additional information to or from the payment meter, such as for the
purposes of payment system management.
top-up - credit token credit purchased by the consumer and capable of being delivered in the form of a
token (as well as by other means) in a physical or virtual token carrier
transient device transportation of a token within a payment metering installation through some
communications electronic communication mechanism involving a transient device. This could be
done by local radio, galvanic connection, optical connection etc. from various devices
e.g. HHT, mobile phone Note 1 to entry: In Home Displays are not classed as
transient devices despite the fact that they may operate in a transient manner as far
as the network is concerned. Transient devices shall be considered as devices that
join the network for a short time and only very rarely. In home displays are
considered to be on the network for long periods and only absent for very short
periods in comparison to the life of the network.
vend operation or transaction resulting in the available credit held on a payment meter to
be increased by use of a credit token Note 1 to entry: Vend would normally relate to
a transaction in conjunction with a vending system at a point of sale, resulting in the
creation of a token that can be transported by means of a physical or virtual token
carrier.
AA Application Association
AARE A-Associate Response – an APDU of the ACSE
Abbreviation Explanation
AARQ A-Associate Request – an APDU of the ACSE
ACSE Association Control Service Element
ADP Primary Station Address
ADS Secondary Station Address
AGA American Gas Association
AGA 8 Method for calculation of compressibility (Gas metering)
AGC Automatic Gain Control
AL Application layer
AP Application process
APDU Application Protocol Data Unit
APS Application Support Sublayer (ZigBee® term)
ARFCN Absolute radio-frequency channel number
ASE Application Service Element
A-XDR Adapted Extended Data Representation (IEC 61334-6)
base_name The short_name corresponding to the first attribute (“logical_name”) of a COSEM object
BCD Binary Coded Decimal
BER Bit Error Rate
CBCP CallBack Control Protocol (PPP)
CC Current Credit (S-FSK PLC profile)
CDMA Code Division Multiple Access
CENELEC European Committee for Electrotechnical Standardization
CHAP Challenge Handshake Authentication Protocol
CIASE Configuration Initiation Application Service Element (S-FSK PLC profile)
class_id Interface class identification code
CLI Calling Line Identity
COSEM Companion Specification for Energy Metering
COSEM object An instance of a COSEM interface class
CPAS Common Part Adaptation Sublayer
CRC Cyclic Redundancy Check
CSD Circuit Switched Data
CSMA Carrier Sense Multiple Access
CtoS Client to Server challenge
CU Currently Unused
DC Delta credit (S-FSK PLC profile)
DHCP Dynamic Host Configuration Protocol
DIB Data Information Block (M-Bus)
DIF Data Information Field (M-Bus)
DL Data Link
DLMS Device Language Message Specification
DLMS UA DLMS User Association
Abbreviation Explanation
DNS Domain Name Server
DSCP Differentiated Services Code Point
DSSID Direct Switch ID
EAP Extensible Authentication Protocol
eARFCN Enhanced Absolute radio-frequency channel number
EDGE Enhanced Data rates for GSM Evolution
EMC Emergency Credit (Payment metering)
ERP Enterprise Resource Planning
EUI-48 48-bit Extended Unique Identifier
EUI-64 64-bit Extended Unique Identifier
E-UTRA Evolved UMTS Terrestrial Radio Access
FCC Federal Communications Commission
FFD Full-Function Device
FIFO First-In-First-Out
FTP File Transfer Protocol
GCM Galois/Counter Mode, an algorithm for authenticated encryption with associated data
GMT Greenwich Mean Time. Replaced by Coordinated Universal Time (UTC).
GPRS General Packet Radio Service
GPS Global Positioning System
GSM Global System for Mobile Communications
HAN Home Area Network
HART Highway Addressable Remote Transducer; see http://www.hartcomm.org/ (in relation with
the Sensor manager interface class)
HDLC High-level Data Link Control
HES Head End System
HHT Hand Held Terminal
HLS High Level Security Authentication
HSDPA High-Speed Downlink Packet Access
HS-PLC High-Speed Power Line Carrier
IANA Internet Assigned Numbers Authority
IB Information Base
IC Interface Class (COSEM)
IC Initial credit (S-FSK PLC profile)
IEC International Electrotechnical Commission
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
IPCP Internet Protocol Control Protocol
IPv4 Internet Protocol version 4
IPv6 Internet Protocol version 6
ISO International Organization for Standardization
ISP Internet Service Provider
IT Information Technology
ITU-T International Telecommunication Union – Telecommunication
Abbreviation Explanation
KEK Key Encryption Key
LA Local Area
LAC Local Area Code
LAN Local Area Network
LCID Local Connection Identifier
LCP Link Control Protocol
LDN Logical Device Name
LBD (6)LoWPAN Bootstrapping Device
LLC Logical Link Control (sublayer)
LLS Low Level Security
LN Logical Name
LNID Local Node Identifier
LOADng 6LoWPAN Ad Hoc On-Demand Distance Vector Routing Next Generation (LOADng)
LQI Link Quality Indicator (ZigBee ® term)
LSB Least Significant Bit
LSID Local Switch Identifier
LTE Long Term Evolution (Wireless communication)
m mandatory
M2M Machine to Machine
MAC Medium Access Control
M-Bus Meter Bus
MCC Mobile Country Code
MD5 Message Digest Algorithm 5
MIB Management Information Base (S-FSK PLC profile)
MID Measuring Instruments Directive 2004/22/EC of the European Parliament and of the Council
MMO Matyas-Meyer-Oseas hash (ZigBee ® term)
MNC Mobile Network Code
MPAN (UK term) Meter Point Access Number – reference of the location of the Electricity meter on
the electricity distribution network.
MPDU MAC Protocol Data Unit
MSB Most Significant Bit
MSDU MAC Service Data Unit
MT Mobile Termination
NB Narrow-band
ND Neighbour Discovery
NTP Network Time Protocol
o optional
OBIS Object Identification System
OFDM Orthogonal Frequency Division Multiplexing
OTA Over the Air – Refers to Firmware Upgrade using ZigBee ®
PAN Personal Area Network (Term used in relation to G3-PLC 1 ) and ZigBee ®
Abbreviation Explanation
Pad Padding
PAP Password Authentication Protocol
PCLK Pre-Configured Link Key (ZigBee® term)
PDU Protocol Data Unit
PhL, PHY Physical Layer
PIB PLC Information Base
PIN Personal Identity Number
PLC Power Line Carrier
PLMN Public Land Mobile Network
PNPDU Promotion Needed PDU
POS Personal Operating Space (ZigBee ®)
POS Point Of Sale (Payment metering)
PPDU Physical Protocol Data Unit
PPP Point-to-Point Protocol
PSTN Public Switched Telephone Network
QoS Quality of Service
RB Radio Band
REJ PDU Reject Protocol Data Unit
RFC Request for Comments; a document published by the Internet Engineering Task Force
RFD Reduced Function Device
ROHC Robust Header Compression
RREP Route Reply
RREQ Route Request
RRER Route Error
RSRQ Reference Signal Received Quality
RSRP Reference Signal Received Power
RSSI Received Signal Strength Indication (ZigBee® term)
SAP Service Access Point
SAS Startup Attribute Set (ZigBee® term )
SCP Shared Contention Period
SE Smart Energy
SEP Smart Energy Profile (ZigBee® term )
S-FSK Spread – Frequency Shift Keying
SGERG88 Method for calculation of compressibility (Gas metering)
SHA Secure Hash Algorithm
SI International System of Units (Système International d’Unités)
SID Switch identifier
SMS Short Message Service
SMTP Simple Mail Transfer Protocol
SN Short Name
SNA Subnetwork Address
SSAS Service Specific Adaptation Sublayer
Abbreviation Explanation
SSCS Service Specific Convergence Layer
StoC Server to Client Challenge
TAB In the case of the EURIDIS profiles without DLMS and without DLMS/COSEM: data code.
In the case of profiles using DLMS or DLMS/COSEM: value at which the equipment is
programmed for Discovery
TABi List of TAB field
TCC Transmission Control Code (IPv4)
TCP Transmission Control Protocol
TFTP Trivial File Transfer Protocol
TOU Time of use
TTL Time To Live
UDP User Datagram Protocol
UMTS Universal Mobile Telecommunications System
UNC Unconfigured (S-FSK PLC profile)
UTC Coordinated Universal Time
VIB Value Information Block (M-Bus)
VIF Value Information Field (M-Bus)
VZ Billing period counter (Form Vorwertzähler in German, see DIN 43863-3)
wake-up trigger the meter to connect to the communication network to be available to a client (e.g.
HES)
WAN Wide Area Network
wM-Bus Wireless M-Bus
ZTC ZigBee® Trust Center
1)
In the case of the G3-PLC technology, PAN may be defined as PLC Area Network.
For specification purposes, this document uses the technique of object modelling.
Objects that share common characteristics are generalized as an interface class, identified with
a class_id. Within a specific IC, the common characteristics (attributes and methods) are
described once for all objects. Instantiations of ICs are called COSEM interface objects.
Manufacturers may add proprietary methods and attributes to any object; see 4.1.2.
reset
Total Positive
Reactive Energy: Register
logical_name = [1 1 3 8 0 255]
value = 57
…
The IC “Register” is formed by combining the features necessary to model the behaviour of a
generic register (containing measured or static information) as seen from the client (data
collection system, hand held terminal). The contents of the register are identified by the attribute
logical_name. The logical_name contains an OBIS identifier (see Clause 7). The actual
(dynamic) content of the register is carried by its value attribute.
Defining a specific meter means defining several specific objects. In the example of Figure 3,
the meter contains two registers; i.e. two specific instances of the IC “Register” are instantiated.
Through the instantiation, one COSEM object becomes a “total, positive, active energy register”
whereas the other becomes a “total, positive, reactive energy register”.
NOTE The COSEM interface objects (instances of COSEM ICs) represent the behaviour of the meter as seen from
the “outside”. Therefore, modifying the value of an attribute – for example resetting the value attribute of a register
– is always initiated from the outside. Internally initiated changes of the attributes – for example updating the value
attribute of a register – are not described in this model.
A short text describes the functionality and application of the IC. A table gives an overview of
the IC including the class name, the attributes, and the methods. Each attribute and method
shall be described in detail. The template is shown below.
2. … (…) … x + 0x…
3. … (…) … x + 0x…
1. … x + 0x…
2. … x + 0x…
3. … x + 0x…
Class name Describes the interface class (e.g. “Register”, “Clock”, “Profile generic”...).
NOTE 1 Interface classes names are mentioned in quotation marks.
Cardinality Specifies the number of instances of the IC within a logical device (see 4.1.8).
value The IC shall be instantiated exactly “value” times.
Min...max. The IC shall be instantiated at least “min.” times and at most “max.”
times. If min. is zero (0) then the IC is optional, otherwise (min. > 0)
“min.” instantiations of the IC are mandatory.
class_id Identification code of the IC (range 0 to 65 535). The class_id of each object is
retrieved together with the logical name by reading the object_list attribute of
an “Association LN” / ”Association SN” object.
- 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 ICs.
- class_id-s from 32 768 to 65 535 are reserved for user group specific ICs.
The DLMS UA reserves the right to assign ranges to individual manufacturers
or user groups.
version Identification code of the version of the IC. The version of each object is
retrieved together with the class_id and the logical name by reading the
object_list attribute of an “Association LN” / ”Association SN” object.
Within one logical device, all instances of a certain IC shall be of the same
version.
Version numbers are to be allocated by the DLMS User Association.
Attribute description
Describes each attribute with its data type (if the data type is not simple), its data format and
its properties (minimum, maximum and default values).
Method description
Describes each method and the invoked behaviour of the COSEM object(s) instantiated.
NOTE Services for accessing attributes or methods by the protocol are specified in DLMS UA 1000-2 Ed. 9, Clause
9.
Selective access
The xDLMS attribute-related services typically reference the entire attribute. However, for
certain attributes selective access to just a part of the attribute may be provided. The part of
the attribute is identified by specific selective access parameters. These are defined as part of
the attribute specification.
Selective access is available with the following interface class attributes and methods:
For repetitive dates, the unused parts shall be set to “not specified”.
For countries not using the Gregorian calendar, Month 1 is the starting month of
the calendar and the range of dayOfMonth may be different.
The elements dayOfMonth and dayOfWeek shall be interpreted together:
- if last dayOfMonth is specified (0xFE) and dayOfWeek is wildcard, this specifies the last
calendar day of the month;
- if last dayOfMonth is specified (0xFE) and an explicit dayOfWeek is specified (for example 7,
Sunday) then it is the last occurrence of the weekday specified in the month, i.e. the last
Sunday;
- if the year is not specified (0xFFFF), and dayOfMonth and dayOfWeek are both explicitly
specified, this shall be interpreted as the dayOfWeek on, or following dayOfMonth;
- if the year and month are specified, and both the dayOfMonth and dayOfWeek are explicitly
specified but the values are not consistent it shall be considered as an error.
Examples:
1) year = 0xFFFF, month =0x FF, dayOfMonth = 0xFE, dayofWeek = 0xFF: last day of the month in every year and
month;
2) year = 0xFFFF, month =0x FF, dayOfMonth = 0xFE, dayofWeek = 0x07: last Sunday in every year and month;
3) year = 0xFFFF, month = 0x03, dayOfMonth = 0xFE, dayofWeek = 0x07: last Sunday in March in every year;
4) year = 0xFFFF, month = 0x03, dayOfMonth = 0x01, dayofWeek = 0x07: first Sunday in March in every year;
5) year = 0xFFFF, month = 0x03, dayOfMonth = 0x16, dayofWeek = 0x05: fourth Friday in March in every year;
6) year = 0xFFFF, month = 0x0A, dayOfMonth = 0x16, dayofWeek = 0x07: fourth Sunday in October in every year;
7) year = 0x07DE, month = 0x08, dayOfMonth = 0x13, (2014.08.13, Wednesday) dayofWeek = 0x02 (Tuesday): error,
as the dayOfMonth and dayOfWeek in the given year and month do not match.
time OCTET STRING (SIZE(4))
{
hour,
minute,
second,
hundredths
}
Where:
hour: interpreted as unsigned
range 0…23, 0xFF,
minute: interpreted as unsigned
range 0…59, 0xFF,
second: interpreted as unsigned
range 0…59, 0xFF,
hundredths: interpreted as unsigned
range 0…99, 0xFF
For repetitive times the unused parts shall be set to “not specified”.
date-time OCTET STRING (SIZE(12))
{
year highbyte,
year lowbyte,
month,
day of month,
day of week,
hour,
minute,
second,
hundredths of second,
deviation highbyte,
deviation lowbyte,
clock status
}
The elements of date and time are encoded as defined above. Some may be set
to “not specified” as defined above.
In addition:
1 8 23 …widths
s e F
msb lsb msb …order
lsb
Where:
- s is the sign bit;
- e is the exponent; it is 8 bits wide and the exponent bias is +127;
- f is the fraction, it is 23 bits.
1 11 52 …widths
s e F
msb lsb msb …order
lsb
Where:
- s is the sign bit;
- e is the exponent; it is 11 bits wide and the exponent bias is +1 023;
- f is the fraction, it is 52 bits.
With this, the value is (if 0 < e < 2 047):
The encoding, including the tag of the data type is (all values are hexadecimal):
18 3F F0 00 00 00 00 00 00.
EXAMPLE 3 The decimal value “62056” represented in single floating-point format is:
Bit 31 Bits 30-23 Bits 22-0
Sign bit Exponent field: 10001110 Significand
0 Decimal value of exponent field 1.11100100110100000000000
0: + and exponent: 142-127 = 15 Decimal value of the significand: 1.8937988
1: -
The encoding, including the tag of the data type is (all values are hexadecimal): 17 47 72 68 00.
EXAMPLE 4 The decimal value “62056” represented in double floating-point format is:
Bit 63 Bits 62-52 Bits 51-0
Sign bit Exponent field: 10000001110 Significand
0 Decimal value of exponent 1.1110010011010000000000000000000000000000000000000000
0: + field and exponent: 1038- Decimal value of the significand: 1.8937988281250000
1: - 1023 = 15
The encoding, including the tag of the data type is (all values are hexadecimal): 18 40 EE 4D 00 00 00 00 00.
The example in Figure 5 shows how a combined metering device can be structured using the
COSEM server model.
Physical device
Combined metering device
The addressing of COSEM logical devices shall be provided by the addressing scheme of the
lower layers of the protocol stack used.
The LDN is defined as an octet-string of up to 16 octets. The first three octets shall carry the
manufacturer identifier 1. The manufacturer shall ensure that the LDN, starting with the three
octets identifying the manufacturer and followed by up to 13 octets, is unique for each and every
LD manufactured.
• instances of the IC “Association SN” – see 4.4.3 – are used with short name referencing;
• instances of the IC “Association LN” – see 4.4.4 – are used with logical name referencing.
Depending on the AA 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
– that can be accessed (‘seen’) within the given AA. In addition, access to attributes and
methods of these COSEM objects may also be restricted within the AA (for example a certain
type of client can only read a particular attribute of a COSEM object, but cannot write it). Access
right may also stipulate required cryptographic protection.
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.
• an active firmware identifier object that holds the identifier of the currently active firmware;
• an active firmware signature object that holds the digital signature of the currently active
firmware.
Note : The digital signature algorithm is not specified here.
If a Logical Device has multiple firmwares then an active firmware identifier object and an active
firmware signature object shall be present for each firmware.
—————————
1 Administered by the DLMS User Association, in cooperation with the FLAG Association.
In addition to the “Association” object modelling the AA with the public client, the management
logical device shall contain a “SAP assignment” object, giving its Service Access Point (SAP)
and the SAPs of all other logical devices within the physical device. The SAP assignment object
shall be readable at least by the public client.
If there is only one logical device within the physical device, the “SAP assignment” object may
be omitted.
• data access security controls access rights to the data held by a DLMS/COSEM server;
• data transport security allows the sending party to apply cryptographic protection to the
xDLMS APDUs sent. This requires ciphered APDUs. The receiving party can check or
remove this protection;
• COSEM data security allows protecting COSEM attribute values, as well as method
invocation and return parameters.
On the COSEM object level, information security is supported / managed by the following
objects:
Attribute description
logical_name Identifies the “Data” object instance. See Clauses 6 and 7.
value Contains the data.
CHOICE The data type depends on the
{ instantiation defined by the
-- simple data types logical_name and possibly from the
null-data [0], manufacturer. It has to be chosen so,
boolean [3], that together with the logical_name, an
bit-string [4], unambiguous interpretation is
double-long [5], possible. Any simple and complex data
double-long-unsigned [6], types listed in 4.1.5 can be used,
octet-string [9], unless the choice is restricted in
visible-string [10], Clause 6.
utf8-string [12],
bcd [13],
integer [15],
long [16],
unsigned [17],
long-unsigned [18],
long64 [20],
long64-unsigned [21],
enum [22],
float32 [23],
float64 [24],
date-time [25],
date [26],
time [27],
Attribute description
logical_name Identifies the “Register” object instance. See Clauses 6 and 7.
value Contains the current process or status value.
CHOICE The data type of the value depends
{ on the instantiation defined by
-- simple data types logical_name and possibly on the
null-data [0], choice of the manufacturer. It has to
bit-string [4], be chosen so that, together with the
double-long [5], logical_name, an unambiguous
double-long-unsigned [6], interpretation of the value is
octet-string [9], possible.
visible-string [10], When, instead of a “Data” object, a
utf8-string [12], “Register” object is used, (with the
integer [15], scaler_unit attribute not used or with
long [16], scaler = 0, unit = 255) then the data
unsigned [17], types allowed for the value attribute
long-unsigned [18], of the “Data” IC are allowed.
long64 [20],
long64-unsigned [21],
enum [22],
float32 [23],
float64 [24],
}
scaler_unit Provides information on the unit and the scaler of the value.
scal_unit_type ::= structure
{
scaler,
unit
}
scaler: integer
This is the exponent (to the base of 10) of the multiplication factor.
REMARK If the value is not numerical, then the scaler shall be set to 0.
unit: enum
Enumeration defining the physical unit; for details see Table 4 below.
Method description
reset (data) 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)
T = number_of_periods * period
T is the time interval used for the
calculation of the current_value of
N 2 1 a sliding demand register
period
t
start_time_current capture_time now
“Demand register” objects know the nature the of process value, which is described by the
attribute logical_name.
energy/period
period
last_average_value
current_average_value
0
t
start_time_current now start_time+period
A profile has a buffer to store the captured data. To retrieve only a part of the buffer, either a
value range or an entry range may be specified, asking to retrieve all entries that fall within the
range specified.
The list of capture objects defines the values to be stored in the buffer (using auto capture or
the method capture). The list is defined statically to ensure homogenous buffer entries (all
entries have the same size and structure). If the list of capture objects is modified, the buffer is
cleared. If the buffer is captured by other “Profile generic” objects, their buffer is cleared as
well, to guarantee the homogeneity of their buffer entries.
The buffer may be defined as sorted by one of the capture objects, e.g. the clock, or the entries
are stacked in a “last in first out” order. 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”
last_average_value attribute. It is just as simple to define a profile retaining the three largest
values of some period.
The set of data types is identified by the template_id attribute. The data type of each attribute
captured is held by the template_description attribute.
The client can reconstruct the data in the uncompacted form – i.e. including the COSEM
attribute descriptor, the data type and the data values – using the capture_objects, template_id
and template_description attributes.
1 2 3 4 5 6 7 8
For comparison, the A-XDR encoding of the same data as if they were accessed using a GET-
WITH-LIST service is shown in Table 8. Only the encoding of the result (SEQUENCE OF Get-
Data-Result) is shown.
NOTE The leading 00-s in each element are there to indicate the CHOICE “Data”
in Get-Data-Result.
1 2 3 4 5 6 7 8
Table 10 – “Compact data“ object attributes – Diagnostic and Alarm data example
For comparison, the A-XDR encoding of the data as if they were read from the buffer attribute
of a “Profile generic” object is shown in Table 11 (only the Data is shown).
Table 11 – Example diagnostic and alarm data read from “Profile generic” buffer
1 2 3 4 5 6 7 8
1 2 3 4 5 6 7 8
Logbook buffer 1
7 0-0:99.98.0.255 2 0 dyn. 2
array of structure 2
1
See Table 12.
2
The size is dynamic and depends on the number of entries captured.
For comparison, the A-XDR encoding of the same data when read from the buffer attribute of a
“Profile generic” object is shown in Table 15.
• the “Association SN” class – see 4.4.3 – and the “Association LN” class – see 4.4.4 – model
AAs. Their instances, the Association objects provide the list of objects accessible in each
AA, manage and control access rights to their attributes and methods. They also manage
the authentication of the communicating partners;
• the “SAP Assignment” class – see 4.4.5 – models the logical structure of the server;
• the “Image transfer” class – see 4.4.6 – models the firmware update process;
• the “Security setup” class – see 4.4.7 – models the elements of the security context.
“Security setup” objects are referenced from the “Association” objects and allow configuring
security suites and security policies and managing security material;
• the “Push setup” class – see 4.4.8 – models the push operation of the server;
• the “Data protection” class – see 4.4.9 – specifies the necessary elements to apply
cryptographic protection to COSEM object attribute values as well as to method invocation
and return parameters;
• the “Function control” class – see 4.4.10 – allows enabling and disabling functions in the
server;
• the “Array manager” class – see 4.4.11 – allows managing attributes of type array of other
interface objects;
• the “Communication port protection” class – see 4.4.12 – allows protection of ports against
unauthorised attempts at communication.
Each AA established between a client and a server can be used by several users on the client
side. The properties of the AA are configured in the server, using the “Association” and the
“Security setup” objects. All users of an AA on the client side use these same properties.
The security keys are known by the client and the server but they need not be known by the
users of the client.
The list of users – identified by their user_id and user_name – is known both by the client and
the server. In the server it is held by the user_list attribute of the “Association” objects.
NOTE 1 The way a client authenticates a user to log into a client system is outside the scope of this
specification.
During AA establishment, the user_id – belonging to the user_name – is carried by the calling-
AE-invocation-id field of the AARQ APDU.
NOTE 2 For this reason, this feature is not available with pre-established AAs.
If the user_id provided is on the user_list, the AA can be established – provided that all other
conditions are met – and the current_user attribute is updated. The value of this attribute can
be logged.
If the server does not “know” the user, the AA shall not be established. The server may silently
discard the request to establish the AA or it may send back an appropriate error message.
The user identification process is optional: if the user_list is empty – i.e. it is an array of 0
elements – the function is disabled.
DLMS/COSEM server
COSEM LDN
Clock
Profiles
Registers
3456789
Push triggers
Wh x 103 xDLMS
DataNotification
Push setup 1 service
Push setup 2
push_object_list
Push
Push setup 3
push_object_list
Single action schedule send_destination
Push setup n
push_object_list
_and_method
send_destination Push destination
push_object_list
_and_method e.g.
Push Script table pushsend_destination
method DLMS/COSEM client
_and_method
script 1 pushsend_destination
method
_and_method
push method
Register monitor(s) script 2
push method
Alarm register, script 3
Alarm descriptor
script n
The core element of modelling the push operation is the “Push setup” IC. The push_object_list
attribute contains a list of references to COSEM object attributes to be pushed.
When push uses a gateway, then the version of the gateway protocol for end devices without
WAN/NN knowledge is to be applied. This is described in the Green Book Edition 9, 10.7.4.3.
The various triggers (e.g. schedulers, monitors, local triggers etc.) call a script entry in a Push
“Script table” object (instances of the “Script table” IC) which invokes then the push method of
the related “Push setup” object. The destination, the communication media, the protocol, the
encoding, the timing as well as any retries of the push operation are determined by the other
attributes of the “Push setup” object.
Each trigger can cause the data to be sent to a dedicated destination. Therefore, for every
trigger or a group of triggers an individual “Push setup” object is available defining the content
and the destination of the push message as well as the communication medium used.
For the purposes of pushing data when an alarm occurs, Alarm monitor objects (instances of
the “Register monitor” IC) are available.
The alarms are held by Alarm register or Alarm descriptor objects, see 6.2.59.
NOTE 1 The structure of the Alarm descriptor as well as the alarm conditions need to be defined in a project
specific companion specification.
Alarm descriptor objects are monitored by Alarm “Register monitor” objects, see 6.2.13. The
actions attribute provides the link to the action_up and maybe the action_down scripts in the
Push “Script table” object – see 6.2.7 – which invoke then the push method of the desired “Push
setup” object. When an alarm occurs, the predefined set of data – that may include among other
data the Alarm register and Alarm descriptor objects – are pushed.
The push data is sent – when the conditions for pushing are met – using the unsolicited, non-
client/server type xDLMS service, the DataNotification service. When the data pushed is long,
it can be sent in blocks.
The push process takes place within the application context of the AA which is referenced by
the push_client_SAP attribute of the “Push setup” object. The security context is determined by
the “Security setup” object referenced from the “Association” object. The necessary data
protection parameters are defined in attribute push_protection_parameters which offers the
same options as defined in the “Data Protection” IC.
All information necessary to process the data received by the client shall be either:
In version 1 the possibility of data protection has been added offering the same options as
defined in the “Data protection” IC.
This version of the interface class is intended to facilitate the use of relative and absolute data
selection. It would be common practice to use an instance of the Push setup IC with relative
data selection for routine data push, and an instance of the Push setup IC with absolute data
for special cases.
The push takes place upon invoking the push method, triggered by a Push “Single action
schedule” object, by an Alarm “Register monitor” object, by a dedicated internal event or
externally. After the push operation has been triggered, it is executed according to the settings
made in the given “Push setup” object. Depending on the communication window settings, the
push is executed immediately or as soon as a communication window becomes active, after a
random delay. If the push was not successful, retries are made. Push windows, delays and
retries are shown in Figure 13.
push push
trigger attempt
not ok
not ok
not ok
ok
interface class that provide the necessary mechanisms and parameters to apply / verify /
remove protection on COSEM data.
NOTE 1 “Accessing” includes reading / writing / capturing / pushing COSEM object attributes or invoking
methods.
NOTE 2 When attributes and methods of COSEM objects are accessed directly, protection can be provided by
protecting the xDLMS APDUs as stipulated by the relevant security policy and the access rights.
NOTE 3 For definitions and abbreviations related to cryptographic security see DLMS UA 1000-2 Ed. 9, Clause
3.
Protection on COSEM data is aligned with and complements protection on xDLMS APDUs as
defined in DLMS UA 1000-2 Ed. 9, Clause 9.
The use cases for COSEM data protection include, but are not limited to:
Applying data protection between a DLMS/COSEM server and a third party allows keeping
critical / sensitive data confidential towards the client through which the third party accesses
the server. Signing COSEM data by a third party supports non-repudiation.
For end-to-end protection between third parties and servers, see also DLMS UA 1000-2 Ed. 9,
4.7 and 9.2.2.5.
The protection parameters are always controlled by the client with some elements filled in by
the server as appropriate.
The security suite is determined by the “Security setup” object referenced from the current
“Association SN” / “Association LN” object.
Figure 14 shows the COSEM model of data protection and the relationship of a “Data protection”
object with other COSEM objects.
For accessing attributes of other COSEM objects with protected data, there are two
mechanisms available:
• reading or writing the protection_buffer attribute. The protection_buffer can be also captured
in “Profile generic” objects or pushed using “Push setup” objects;
• invoking the get_protected_attributes / set_protected_attributes method.
For accessing a method of another COSEM object with protected data, the
invoke_protected_method method is available.
APDUs carrying service invocations to access attributes and methods of “Data protection”
objects are protected as stipulated by access rights to these attributes and methods, and by
“Security setup” security_suite and security_policy.
The master key and Certificates – as required by the security suite – are held by “Security
setup”.
protection_parameters_get is
used to apply protection when
protection_buffer is read. protection_object_list references attributes
APDUs carrying service invocations to access
attributes and methods of “Data protection” are the values of which are captured to or written
protection_parameters_set is from protection_buffer.
protected as stipulated by the access rights and used to remove protection when
by “Security setup” security_suite and protection_buffer is written.
security_policy.
Master key and Certificates are held by
“Security setup”. “Data protection” object Target COSEM object attributes and methods
COSEM attribute
1. logical_name COSEM
{class_id, attribute attribute
logical_name,
Capture to “Profile generic” COSEM
{class_id, attribute attribute
_index,logical_name,
data_index, restriction}
2. protection_buffer {class_id,
_index,logical_name, attribute_
data_index, restriction}
Push index, data_index, restriction}
Protection on COSEM data is applied and removed in the various cases as follows:
When the protection_buffer attribute is read the following steps are performed:
The invocation counter used when protection is applied / removed is related to the key used.
When the protection is applied the corresponding invocation counter is incremented. When the
key is changed the invocation counter shall be reset to 0.
To allow enabling and disabling of functions controlled by time, “Single action schedule” and
“Script table” objects are also specified.
Selected array : Activity calendar Unless already specified in the relevant interface class,
attr. 5 day_profile_table_active the data type of the entries in each selected array
identified by array_obejct_definition shall be defined
in a project specific companion specification..
insert_entry (entry_number = 6, The selected array becomes an array of 6 entries. The last entry
day_id = 9, day_schedule ) holds the day_scehdule for the day identified by day_id = 9.
day_id = 0, day_schedule
day_id = 2, day_schedule
day_id = 3, day_schedule
day_id = 5, day_schedule
day_id = 7, day_schedule
day_id = 9, day_schedule
The selected array remains an array of 5 entries, but the 2nd entry
update_entry (entry_number = 2, holds now the day_scehdule for the day identified by day_id = 9.
day_id = 9, day_schedule )
day_id = 0, day_schedule
day_id = 9, day_schedule
day_id = 3, day_schedule
day_id = 5, day_schedule
day_id = 7, day_schedule
remove_entries
(from_entry = 2 to_entry = 5) The selected array becomes now an array of 1 entry, which
holds the day_scehdule for the day identified by day_id = 9.
day_id = 0, day_schedule
Each instance references a single communication port by its logical name (OBIS code). If an
acceptable number of failed attempts is exceeded then the communication port is temporarily
locked. The lockout time may increase with each failed attempt, until a maximum lockout time
is reached.
A failed attempt is one that leads to discarding the APDU carrying a service request. The criteria
for detecting a failed attempt are out of the Scope of this document.
The objects count both the number of failed attempts between two resets and the cumulative
number of failed attempts.
It is possible to configure the communication ports such that they are locked to all attempts or
unlocked to all attempts.
1. reset(data) o o x + 0x50
The date information includes the elements year, month, day of month and day of week. The
time information includes the elements hour, minutes, seconds, hundredths of seconds, and the
deviation of the local time from UTC. The daylight saving time function modifies the deviation
of local time to UTC depending on the attributes; see Figure 17. 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
daylight_savings_deviation
local time
daylight_savings_begin daylight_savings_end
“Script table” objects contain a table of script entries. Each entry consists of a script identifier
and a series of action specifications. An action specification activates a method or modifies an
attribute of a COSEM object within the logical device.
A certain 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.
Table 16 – Schedule
12 xx-12-24 S1
33 xx-12-25 S3
77 97-03-31 S3
An “Activity calendar” object may coexist with the more general “Schedule” object and it can
even overlap with it. If actions in a “Schedule” object are scheduled for the same activation time
as in an “Activity calendar” object, the actions triggered by the “Schedule” object are executed
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” shall be executed at the correct time
within the sequence of actions requested by the “Schedule” object.
The “Activity calendar” object defines the activation of certain scripts, which can perform
different activities inside the logical device. The interface to the IC “Script table” is the same as
for the IC “Schedule” (see 4.5.3).
If an instance of the IC “Special days table” (see 4.5.4) 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.
Disconnected (0)
remote_reconnect
(d)
remote_disconnect
(c)
remote_disconnect Ready_for_
(b) reconnection (2)
remote_reconnect
(a)
manual_reconnect
(e)
manual_disconnect
(f)
local _disconnect
(g)
local_reconnect
(h)
Connected (1)
To define the behaviour of the disconnect control object for each trigger, the control mode shall
be set.
States
State number State name State description
0 Disconnected The output_state is set to FALSE and the consumer is disconnected.
1 Connected The output_state is set to TRUE and the consumer is connected.
2 Ready_for_reconnection The output_state is set to FALSE and the consumer is disconnected.
State transitions
Transition Transition name State description
Moves the “Disconnect control” object from the Disconnected (0) state directly
a remote_reconnect
to the Connected (1) state without manual intervention.
Moves the “Disconnect control” object from the Connected (1) state to the
b remote_disconnect
Disconnected (0) state.
Moves the “Disconnect control” object from the Ready_for_reconnection (2)
c remote_disconnect
state to the Disconnected (0) state.
Moves the “Disconnect control” object from the Disconnected (0) state to the
Ready_for_reconnection (2) state.
d remote_reconnect
From this state, it is possible to move to the Connected (2) state via the
manual_reconnect transition (e) or local_reconnect transition (h).
Moves the “Disconnect control” object from the Ready_for_connection (2)
e manual_reconnect
state to the Connected (1) state.
Moves the “Disconnect control” object from the Connected (1) state to the
Ready_for_connection (2) state.
f manual_disconnect
From this state, it is possible to move back to the Connected (2) state via the
manual_reconnect transition (e) or local_reconnect transition (h).
Moves the “Disconnect control” object from the Connected (1) state to the
Ready_for_connection (2) state.
From this state, it is possible to move back to the Connected (2) state via the
g local_disconnect
manual_reconnect transition (e) or local_reconnect transition (h).
NOTE 1 Transitions f) and g) are essentially the same, but their trigger
is different.
Moves the “Disconnect control” object from the Ready_for_connection (2)
state to the Connected (1) state
h local_reconnect
NOTE 2 Transitions e) and h) are essentially the same, but their trigger
is different.
The threshold value can be normal or emergency threshold. The emergency threshold is
activated via the emergency_profile defined by emergency profile id, emergency activation time,
and emergency duration. The emergency profile id element is matched to an emergency profile
group id: this mechanism enables the activation of the emergency threshold only for a specific
emergency group.
The parameters can be changed as usual. If the value of an attribute changes and this attribute
is present in the parameter_list attribute, the identifier and the value of that attribute is
automatically captured to the changed_parameter attribute. The time when the change of the
parameter occurred is captured in the capture_time attribute. These attributes may be captured
then by a “Profile generic” object. In this way, a log of all parameter changes can be built. For
the OBIS code of the Parameter monitor log objects, see 7.4.5.
NOTE 1 In the case of simultaneous or quasi simultaneous parameter changes the order of capturing and
logging the changed parameters has to be managed by the application.
Several “Parameter monitor” objects and corresponding “Profile generic” objects can be
instantiated to manage a number of parameter groups. The link between the “Parameter
monitor” object and the corresponding “Profile generic” object is via the capture_object attribute
of the “Profile generic” object.
NOTE 2 As the various parameters may be of different type and length, the entries in the profile column holding
the parameters will be also of different type and length. This can be managed for example by capturing different kind
of parameters into different Parameter list “Profile generic” objects and parameter logs.
NOTE 3 The “Profile generic” object holding the parameter change log may capture other suitable object
attributes, like the time attribute of the “Clock” object, and any other relevant values.
In addition, the measured values have to be monitored. These values may be related to a
physical quantity – raw values of voltage, current, resistance, frequency, digital output –
provided by the sensor, and the measured quantities resulting from the processing of the
information provided by the sensor.
It is necessary to monitor and often to log the relevant values in order to obtain diagnostic
information that allows:
For simpler sensors / devices, already existing COSEM objects – identifying the sensors,
holding measurement values and monitoring those measurement values – can be used.
Table 26 and Table 27 show examples of the various thresholds and the actions performed
when the thresholds are crossed.
The actions that can be requested are held in the actions attribute as an array of script
identifiers. The scripts – held by separate “Script table” objects – allow performing a wide range
of functions. There may be actions designed to inhibit the execution of other actions: these are
modelled as null-scripts, i.e. pointing to a script_identifier (0) of a “Script table” object.
NOTE 2 The “Arbitrator” objects do not contain the names of the actions, but their purpose and effect can be
deduced by looking at the relevant “Script table” objects.
The permissions are held in the permissions_table attribute as an array of bit-strings: each
element in the array represents one actor and each bit in the bit-string represents one action
from the actions array.
The weightings are held in the weightings_table attribute as a two-dimensional array: each line
represents one actor and there is one weight allocated to each possible action for that actor.
For actions designed to inhibit other actions a very high weight may be allocated compared to
the weight of the action that is to be inhibited.
Actions are requested by invoking the request_action method. The method invocation
parameters contain:
• the identifier of the actor. This element, an unsigned number, points to a line in the
permissions_table, weightings_table and most_recent_requests_table attributes;
NOTE 3 Names of the actors may be specified in project specific companion specifications.
• the list of actions requested, in the form of a bit-string. Each bit corresponds to one element
of the actions array: for the actions requested the bit is set to 1, for the actions not requested
(inactions) the bit is set to 0. An actor may request none, one, several or all actions in a
single request in one invocation. The reason to allow requesting multiple actions in a single
request is to allow the actor to request an action, and at the same time to prevent another
actor reversing that action.
NOTE 4 For example, an actor may request disconnecting the supply and preventing another actor to reconnect
it.
NOTE 5 An earlier action request by an actor can be cleared by not requesting the same action (i.e. by
requesting an inaction) in another invocation of the request_action method by the same actor. With
this, a request for inhibiting an action is lifted.
The most_recent_requests_table attribute holds the list of the most recent request of each
actor, in the form of an array of bit-strings: each element in the array represents the last request
of an actor, and each bit in the bit-string represents one action / inaction requested.
When the request_action method is invoked by an actor the AP carries out the following
activities:
• it checks the permissions_table attribute entry for the given actor to see if the actions
requested are permitted or not;
• it updates the most_recent_requests_table attribute by setting or clearing the bit in the bit-
string for that actor for each action requested that is also permitted (bit is set); or not
requested / not permitted (bit is cleared;
• it applies the weightings_table for the most_recent_requests_table: for each bit set in the
most_recent_requests_table the corresponding weight of each actor is applied;
• for each action, the weights are summed; and then
• if there is a unique highest total weight for an action, this value is written to the last_outcome
attribute and the corresponding script is executed. If there is no highest unique total weight,
nothing happens.
activate_pass_clndr_time
Remote or
activate_pass-calendar
local invocation
Register
Clock Single action sched. Script table Profile generic logical_name
logical_name logical_name logical_name logical_name value
time executed_script buffer scaler_unit
scripts ::= array
{script_logName,
…. {script_identifier, capture_objects
script_selector}
Actions {service_id,
…. type (wildcards) attribute / ….
method_id,param } ….
execution_time {time,
date} execute capture
A “Credit” object contains detailed information about one source of funds. There is one or
(usually) more “Credit” object(s) associated with an “Account”: for example, one object for token
credit and one object for emergency credit. Both of these objects can receive credit amounts
from tokens, but emergency credit can only receive credit amounts when it has been consumed
(entirely or partially) and when credit_configuration has bit 2 (Requires the credit amount to be
paid back) set.
There are several types of credit listed in IEC TR 62055-21:2005, and these are the types
supported by the ”Credit” IC. There can be zero or more instances of each type of Credit.
• reserved_credit: Credit that is held in reserve, which is released under specific conditions;
• emergency_credit: Accounting functions that deal with the calculation and transacting of
credit that is released only under emergency situations. Usually the amount of emergency
credit used is recovered from subsequently purchased credit token
NOTE 3 Emergency above refers to a time when a consumer does not have any token credit, and not to any
safety related situation.
There are several types of charge listed in IEC TR 62055-21:2005, but the following types,
distinguished by the trigger for collection, are the ones most useful in the COSEM accounting
model. There can be zero or more instances of each type of ”Charge” IC.
Figure 23 shows instances of “Account”, “Credit” and “Charge” interface classes with some of
their attributes and the relationships between those attributes. In this example:
a) There is one “Account”, two “Credit” and two “Charge” objects configured;
b) “Credit” 1 is of type token_credit and the low_credit_threshold and limit attributes are
configured to be 0;
c) Interaction between multiple classes is covered in this diagram. Detailed configuration of
individual “Credit” and “Charge” objects is not shown.
The operation of the payment metering function will be defined within the configuration of
“Charge”, “Credit”, and “Account” objects and disconnection rules.
NOTE 1 Disconnection rules are either application specific or can be modelled using an instance of the
“Arbitrator” IC, see 4.5.12.2.
If explicitly specified for a particular project, it is permissible for accounting to switch from credit
to prepayment mode, or from prepayment to credit mode, once an accounting configuration has
been correctly set up and the “Account” object has been activated. In the absence of any such
specification the operating mode should remain fixed for any particular “Account” once it has
been made active.
All “Credits” associated with one supply are listed in the credit_reference_list attribute of the
“Account” object. “Credits” move between states by:
• top-ups;
• the adjustment of current_credit_amount by method invocation; or
• the decrement of credit by charges.
This is explained in the state diagram in 4.6.3.2. 4.6.1 lists “Credit” types as defined in IEC TR
62055-21:2005.
All “Charges” associated with one supply are referenced in the charge_
reference_list attribute of the related “Account” object.
• between Local Network Access Points (LNAPs) and metering end devices (M interface);
• between Local Network Access Points (LNAPs) and Neighbourhood Network Access Points
(NNAPs); and
• for direct connection between a HHU and the metering end device.
IEC 62056-3-1:2013 specifies three communication profiles using the medium twisted pair with
carrier signalling:
• without DLMS;
• with DLMS; and
• with DLMS/COSEM.
IEC 62056-31:1999 supports only the first two profiles.
The new, DLMS/COSEM profile introduces a Support Manager Layer entity performing the
initialisation of the bus, discovery management, alarm management and communication speed
negotiation. It also allows higher baud rates up to 9 600 Bd. The Transport Layer supports
segmentation and reassembly.
The IC “IEC Twisted pair (1) set up” (class_id = 24, version = 0) supports the first two
communication profiles specified in IEC 62056-31:1999.
The new version 1 supports the DLMS/COSEM profile. With its introduction, the use of version
0 is deprecated.
The use of the communication profiles specified in IEC 62056-3-1:2013 requires using the
registration services provided by the Euridis Association: www.euridis.org.
The following COSEM interface objects are necessary to set up data exchange over the medium
Twisted pair with carrier signalling:
Transmission error. The time out TOE is elapsed without the byte being sent, leading to
Bit 0 EP-3F
a non-ability to send the remaining part of the frame.
Bit 1 EP-4F Reception error. The number of bytes received is higher than the maximum expected.
Expiry of TARSO wake-up while receiving an RSO frame. Not relevant for secondary
Bit 2 EP-5F
station (server); concerns the primary station (client) only.
In version 2, new capabilities are added to manage wake-up requests that may be in the form
of a wake-up call or a wake-up message e.g. an (empty) SMS message. After a successful
wake-up request, the device connects to the network. See also Annex A.
For both functions, additional security is provided by adding the possibility of checking the
calling number: calls or messages are accepted only from a pre-defined list of callers. This
feature requires the presence of a calling line identification (CLI) service in the communication
network used.
NOTE 2 The wake-up process is fully decoupled from AL services, i.e. a wake-up message cannot contain any
xDLMS service requests. This is to avoid creating a backdoor. xDLMS messages may be exchanged in SMS
messages once the wake-up process is completed.
For more information see the complete Blue Book.
In version 2 new capabilities are added to model the connection of the device to a
communication network. Network connection may be permanent, within a time window or on
invocation of the connect method.
An instance of the “GSM diagnostic” class stores parameters of the GSM/GPRS, UMTS, CDMA
or LTE network necessary for analysing the operation of the network.
A GSM diagnostic “Profile generic” object is also available to capture the attributes of the GSM
diagnostic object, see 7.4.5.
a) a DLMS/COSEM server hosted by a M-Bus master and exchanging dedicated M-Bus APDUs
with M-Bus slaves;
b) a DLMS/COSEM client hosted by a M-Bus master and exchanging DLMS/COSEM APDUs
with DLMS/COSEM servers hosted by M-Bus slaves;
In case a) instances of the following M-Bus interface classes are used to set up and manage
the M-Bus media in the DLMS/COSEM server:
An M-Bus slave device is identified with its Primary Address, Identification Number,
Manufacturer ID etc. as defined in EN 13757-3:2013, Clause 5, Variable Data Send and
Variable Data respond. These parameters are carried by the respective attributes of the M-Bus
client IC.
Values to be captured from an M-Bus slave device are identified by the capture_definition
attribute, containing a list of data identifiers (DIB, VIB) for the M-Bus slave device. The data
are captured periodically or on an appropriate trigger. Each data element is stored in an M-Bus
value object, of IC “Extended register”. M-Bus value objects may be captured in M-Bus “Profile
generic” objects, eventually along with other, non M-Bus specific objects. If the data type used
by M-Bus is not a data type specified in COSEM, then a data type conversion has to take place.
The conversion process is specified in EN13757-3:2018 Annex H.
Using the methods of “M-Bus client” objects, M-Bus slave devices can be installed and de-
installed.
It is also possible to send data to M-Bus slave devices and to perform operations like resetting
alarms, synchronizing the clock, transferring an encryption key etc.
Encryption key status provides information if encryption key has been set, transferred to M-Bus
slave device and is in use with M-Bus slave device.
In TCP-UDP/IP based communication profiles, all AAs between a physical device hosting one
or more COSEM client application processes and a physical device hosting one or more COSEM
server APs rely on a single TCP or UDP connection. The TCP or UDP entity is wrapped in the
COSEM TCP-UDP based transport layer. Within a physical device, each AP – client AP or
server logical device – is bound to a Wrapper Port (WPort). The binding is done with the help
of the SAP Assignment object. See 4.4.5.
On the other hand, a COSEM TCP or UDP based transport layer may be capable to support
more than one TCP or UDP connections, between a physical device and several peer physical
devices hosting COSEM APs.
When a COSEM physical device supports various data link layers – for example Ethernet and
PPP – an instance of the TCP-UDP setup object is necessary for each of them.
There shall be an instance of this IC in a device for each different network interface
implemented. For example, if a device has two interfaces (using the TCP-UDP/IPv4 profile on
both of them), there shall be two instances of the IPv4 setup IC in that device: one for each of
these interfaces.
There shall be an instance of this IC in a device for each different network interface
implemented. For example, if a device has two interfaces (using the UDP/IP and/or TCP/IP
profile on both of them), there shall be two instances of the IPv6 setup IC in that device: one
for each of these interfaces.
Instances of this IC hold the MAC address of the physical device (or, more generally, a device
or software.) There shall be an instance of this IC for each network interface of a physical
device.
NOTE 2 In the case of the three-layer HDLC based communication profile, the MAC address (lower HDLC
address) is carried by an IEC HDLC setup object.
NOTE 3 In the case of the S-FSK PLC communication profile, the MAC address is carried by a S-FSK Phy&MAC
setup object.
• the S-FSK Physical layer and the MAC sub-layer as defined in IEC 61334-5-1:2001 and IEC
61334-4-512:2001;
• the LLC sub-layer as specified in IEC 61334-4-32:1996.
The MIB variables / logical link parameters specified in IEC 61334-4-512:2001, IEC 61334-5-
1:2001, IEC 61334-4-32:1996 and ISO/IEC 8802-2:1998 respectively have been mapped to
attributes and/or methods of COSEM ICs. The specification of these elements has been taken
from the above standards and the text has been adapted to the DLMS/COSEM environment.
NOTE IEC 61334-4-512:2001 also specifies some management variables to be used on the Client side. However,
the Client side object model is not covered in this document.
For definitions related to S-FSK PLC profile see 3.2.
4.10.2 Overview
COSEM objects for setting up the S-FSK PLC channel and the LLC layer, if implemented, shall
be located in the Management Logical Device of COSEM servers.
Figure 27 shows an example with a COSEM physical device comprising three logical devices.
Each logical device shall contain a Logical Device Name (LDN) object. Each logical device
contains one or more Association objects, one for each client supported.
NOTE As in this example there is more than one logical device, the mandatory Management Logical Device contains
a SAP Assignment object instead of a Logical Device Name object.
Physical device
Logical device Y
Management logical device Logical device X
Intermediate
layer setup Association
Intermediate
objects objects
layer setup Association
Intermediate
Association objects Association
objects
layer setup Association Application
objects objects
Association objects Association
objects objects
objects objects Application
Association Association Application
objects
objects objects Application
objects
PLC channel Application
objects
setup objects Application
objects
PLC channel LDN object Application
objects
LDN / setup objects objects
PLC channel Application
SAP assignment LDN object
setup objects objects
object
The management logical device contains the setup objects of the physical and MAC layers of
the PLC channel, as well as setup objects for the intermediate layer(s). It may contain further
application objects.
The other logical devices, in addition to the Association and Logical Device Name objects
mentioned above, contain further application objects, holding parameters and measurement
values.
IEC 61334-4-512:2001 uses DLMS named variables to model the MIB objects and specifies
their DLMS name in the range 8…184. For compatibility with existing implementations, the short
names 8…400 [sic] are reserved for devices using the IEC 61334-5-1:2001 S-FSK PLC profiles
without COSEM. Therefore, when mapping the attributes and methods of the COSEM objects
specified in this document to DLMS named variables (SN mapping) this range shall not be used.
Table 23 shows the mapping of MIB variables to attributes and/or methods of COSEM ICs.
Note that on the one hand, not all MIB variables specified in IEC 61334-4-512:2001 have been
mapped to attributes and methods of COSEM ICs. On the other hand, some new management
variables are specified in this document.
ACSE management
NOTE In DLMS/COSEM the Association objects play
application-context-list variable 14
a similar role.
Application management
S-FSK Active initiator 51 / Attr. 2
active-initiator variable 15
(class_id = 51, version = 0)
MIB system objects
reporting-system-list variable 16 S-FSK Reporting system 56 / Attr. 2
list (class_id = 56, version
= 0)
Other MIB objects
reset-NEW-not-synchronized variable 17 S-FSK Active initiator 51 / Method 1
(class_id = 51, version = 0)
new-synchronization IEC 61334-5-1:2001, –
4.3.7.6
initiator-electrical-phase variable 18 50 / Attr. 2
For definitions related to the ISO/IEEE 8802-2 LLC layer see ISO/IEC 8802-2:1998, 1.4.2.
Figure 28 shows an example with a COSEM physical device comprising three logical devices.
Physical device
Logical device Y
Management Logical Device Logical device X
Intermediate
layer setup Association
Intermediate
objects objects
layer setup Association
Intermediate
Association objects Association
objects
layer setup Association Application
objects objects
Association objects Association
objects objects
objects objects Application
Association Association Application
objects
objects objects Application
objects
Application
objects
PRIME NB Application
objects
LDN object Application
PRIME
OFDM NB
PLC objects
LDN/SAP objects
OFDM
PRIME PLC
channel NB setup LDN object
Application
Assignment channel PLC
OFDM setup objects
object channel setup
Each logical device shall contain a Logical Device Name (LDN) object.
NOTE As in this example there is more than one logical device, the mandatory Management logical device contains
a “SAP Assignment” object instead of a Logical Device object.
Each logical device contains one or more “Association” objects, one for each client supported.
The management logical device contains the setup objects of the physical and MAC layers of
narrowband OFDM PLC profile for PRIME networks as well as setup objects for the intermediate
layer(s). It may contain further application objects.
The other logical devices, in addition to the “Association” and Logical Device Name objects
mentioned above, contain further application objects, holding parameters and measurement
values.
Table 24 shows the mapping of PRIME NB OFDM PLC PIB attributes to attributes of COSEM
ICs. Only variables related to the switch and Terminal nodes are mapped. Variables relevant
for the base node are not mapped, because the base node acts as a client regarding the
distribution network.
The attributes of instances of this IC shall be read only. They can be reset using the reset
method.
These attributes influence the functional behaviour of an implementation. These attributes may
be defined external to the MAC, typically by the management entity and implementations may
allow changes to their values during normal running, i.e. even after the device start-up sequence
has been executed.
COSEM objects for data exchange using G3-PLC, if implemented, shall be located in the
Management Logical Device of COSEM servers.
To set up and manage the DLMS/COSEM G3-PLC profile layers (including PHY, IEEE 802.15.4
MAC and 6LoWPAN), three ICs are specified:
As COSEM models only the server and not the client, the G3-PLC setup classes concern only
the RFD (Reduced Function Device) and not the PAN coordinator.
The attributes of instances of this IC shall be read only. They can be reset using the reset
method.
7. adp_broadcast_log_table x + 0x30
(static) long- unsigned 0 65535 2
_entry_TTL
Each PAN has one device designated as ZigBee® coordinator, which has responsibility for
creating and managing the network, and which normally acts also as a ZigBee® Trust Center
for the management of ZigBee® network, PCLK’s and APS Link keys.
There is a process of PAN creation (and corresponding destruction) which is performed by the
coordinator; this declares the existence of the network without any devices apart from the
coordinator forming part of it. Other ZigBee® devices can join a network created with
cooperation of the coordinator, and equally can choose to leave, or can be invited to leave by
the coordinator (this is not currently enforceable). Normally devices are members of the network
indefinitely; they do not repeatedly join and leave. To create a PAN the coordinator has to
receive an external trigger and needs to have setup information including:
• extended PAN ID;
• link keys or install code (for initial communication with new devices);
• radio channel information.
During the process of creating the PAN, the coordinator scans for nearby radio devices,
“exchanges” keys, chooses the short addresses, and confirms use of radio channels. Details of
the information available from the ZigBee® servers on each device are also exchanged.
NOTE 3 Full details of the joining process are documented in ZigBee® 053474, the ZigBee® specification.
More information on ZigBee® technology can be sought at http://www.zigbee.org/.
Figure 29 shows an example architecture with a Comms hub on the left, that comprises a
DLMS/COSEM server as well as the ZigBee® coordinator. The DLMS/COSEM server has
interface objects needed to set up and control the ZigBee® network and may have other
COSEM objects to support a metering application. Further, there are two native ZigBee®
devices and another DLMS/COSEM server – an electricity meter or another meter type – on the
right which is also a “normal” ZigBee® network device.
Any ZigBee® device can be “joined” to the network by remote control.
It is assumed that the Comms hub will also have a further network connection to the WAN, and
it is assumed that this is managed by existing DLMS structures – e.g. PSTN, GSM/3G, PLC etc.
– but this is out of scope of this document.
The role of COSEM interface objects in the process of creating / destructing the PAN is to set
up ZigBee® parameters and allow a DLMS/COSEM client to trigger actions, typically when
commissioning the installation, in a system where WAN communications between a central
system and a smart meter installation is by means of DLMS.
The use of ZigBee® setup classes in the ZigBee® coordinator and other DLMS/COSEM
ZigBee® devices is shown in Table 25.
This set of COSEM ICs supports the ZigBee® 2007 and ZigBee® PRO protocol stacks. The
ZigBee® IP protocol stack is not supported at this time.
NOTE 4 In the specification of the ZigBee® COSEM ICs, the length of the octet-strings is indicated for
information.
Instances of this IC are present in all devices where a DLMS/COSEM server controls the
ZigBee® Radio behaviour.
The ZigBee® tunnel setup objects would be present on the coordinator and on all other
DLMS/COSEM devices that are not connected to the WAN.
Creation of the tunnel is managed on demand and invisibly from the point of view of the
DLMS/COSEM client. The target device is implicitly identified by the COSEM addressing
information.
For new implementations in metering devices, only the current versions should be used.
Communication drivers at the client side should also support previous versions.
6 Relation to OBIS
6.1 General
This Clause 6 specifies the use of COSEM interface objects to model various data items.
It also specifies the logical names of the objects. The naming system is based on OBIS, the
Object Identification System: each logical name is an OBIS code.
The following rules for object instantiations are applicable with interface classes:
• if the use of IC “Data” is specified but it is not available in a given implementation, “Register”
or “Extended register” (with scaler = 0, unit = 255) may be used;
• when, instead of a “Data” object, a “Register” or “Extended register” object is used, then the
data types allowed for the value attribute of the “Data” IC are allowed.
OBIS codes are specified in the following subclauses:
• 6.2 specifies the use and the logical names of abstract COSEM objects, i.e. objects not
related to an energy type;
• 6.3 specifies the use and logical names for electricity related COSEM objects;
• 6.4 specifies the use and logical names for heat cost allocator (HCA) related COSEM
objects;
• 6.5 specifies the use and logical names for thermal energy related COSEM objects;
• 6.6 specifies the use and logical names for gas related COSEM objects;
• 6.7 specifies the use and logical names for water related COSEM objects;
NOTE The use and the logical names of COSEM objects related to other media / energy types are under
consideration.
• the detailed OBIS code allocations – for all media / energy types – are specified in Clause
7.
Unless otherwise specified the use of value group B shall be:
Table 26 – Use of value group C for abstract objects in the COSEM context
Value group C
Abstract objects (A = 0)
0 General purpose COSEM objects
1 Instances of IC "Clock"
2 Instances of IC “Modem configuration” and related IC-s
33 COSEM objects for data exchange using HS-PLC ISO/IEC 12139-1 networks
Value group C
Abstract objects (A = 0)
43 COSEM objects related to security: Instances of IC “Security setup” and “Data protection”
44 Instances of IC “Image transfer”, “Function control” and “Communication port protection”
objects
Example:
Identification of billing periods Billing period counter Identification of billing periods
relative to billing period counter VZ modulo 12, current relative to current billing period
value VZ = 5
Multiple billing Single billing period: Single billing period: Multiple billing
periods: Simple object or Simple object or periods:
Profile generic Profile generic Profile generic Profile generic
F = 112
10th last billing period gets twelve most recent (all)
• a value of a single historical billing period may be represented using the same IC as used
for representing the value of the current billing period. With F = 0…99, the billing period is
identified by the value of the billing period counter VZ. F = VZ identifies the youngest value,
F = VZ-1 identifies the second youngest value etc. F = 101…125 identifies the last, second
last …25th last billing period. (F = 255 identifies the current billing period). Simple objects
can only be used to represent values of historical billing periods, if “Profile generic” objects
are not implemented;
• a value of a single historical billing period may also be represented by “Profile generic”
objects, which are one entry deep, and contain the historical value itself and the time stamp
of the storage. With F = 0…99, the billing period is identified by the value of the billing period
counter VZ. F = VZ identifies the youngest value, F = VZ-1 identifies the second youngest
value etc. F=101 identifies the most recent billing period;
• values of multiple historical billing periods are represented with “Profile generic” objects,
with suitable controlling attributes. With F = 102…125 the two last, …25 last values can be
reached. F = 126 identifies an unspecified number of historical values;
• when values of historical billing periods are represented by “Profile generic” objects, more
than one billing periods schemes may be used. The billing period scheme is identified by
the billing period counter object captured in the profile.
For billing period / reset counters and for number of available billing periods the data type shall
be unsigned, long-unsigned or double-long-unsigned. For time stamps of billing periods, the
data type shall be double-long-unsigned (in the case of UNIX time), octet-string or date-time
formatted as specified in 4.1.6.1.
These objects may be related to energy type – see also 6.3.3 and 6.4.3 – and channels.
When the values of historical periods are represented by “Profile generic” objects, the time
stamp of the billing period objects shall be part of the captured objects.
• Active firmware identifier objects hold the identifier of the currently active firmware;
• Active firmware version objects hold the version of the currently active firmware;
NOTE Firmware version can be used to distinguish between different releases of a firmware identified by the same
Firmware identifier.
• Active firmware signature objects hold the digital signature of the currently active firmware.
The digital signature algorithm is not specified here.
These three elements are inextricably linked to the currently active firmware.
OBIS code
Abstract general purpose OBIS codes IC
A B C D E F
Program entries 1, Data 0 b 0 2 e 255
Time entries 1, Data 0 b 0 9 e 255
“UNIX clock” objects are instances of the Interface class “Data”, with data type double-long-
unsigned. They hold the number of seconds since 1970-01-01 00:00:00.
“High resolution clock” objects are instances of the Interface class “Data”, with data type long64-
unsigned. They hold the number of microseconds since 1970-01-01 00:00:00.
OBIS code
Clock objects IC
A B C D E F
Clock 8, Clock 0 b 1 0 e 255
UNIX clock 1, Data 0 b 1 1 e 255
High resolution clock 1, Data 0 b 1 2 e 255
• Instances of the IC “Modem configuration” – see 4.7.4 – define and control the behaviour of
the device regarding the communication through a modem;
• Instances of the IC “Auto connect” – see 4.7.6 – define the necessary parameters for the
management of sending information from the metering device to one or more destinations
and for connection to the network;
• Instances of the IC “Auto answer" – see 4.7.5 – define and control the behaviour of the
device regarding the auto answering function using a modem and handling wake-up calls
and messages.
Several instances 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 zero in value group D.
• MDI reset / End of billing period “Script table” objects define the actions to be performed at
the end of the billing period, for example the reset of maximum demand indicator registers
and archiving data. If there are several billing period schemes available, then there shall be
one script present in the array of scripts for each billing period scheme;
• Tariffication “Script table” objects define the entry point into tariffication by standardizing
utility-wide how to invoke the activation of certain tariff conditions;
• Disconnect control “Script table” objects hold the scripts to invoke the methods of
“Disconnect control” objects;
• Image activation “Script table” objects are is used to locally activate an Image transferred
to the server, at the date and time held by an Image activation “Single action schedule”
object;
• Push “Script table” objects hold scripts to activate the push operation. Normally every entry
in the array of scripts calls the push method of one “Push setup” object instance;
• Load profile control “Script table” allow to change attributes of “Profile generic” objects e.g.
to change the capture period and thus allow extended time control;
• M-Bus profile control “Script table” allow to change attributes of M-Bus related “Profile
generic” objects e.g. to change the capture period and thus allow extended time control;
• Function control “Script table” objects allow making changes to “Function control” objects;
• Broadcast “Script table” objects allow standardising utility wide the entry point into regularly
needed functionality.
OBIS code
Script table objects IC
A B C D E F
Global meter reset a
Script table 0 b 10 0 0 255
MDI reset / End of billing period a
Script table 0 b 10 0 1 255
Tariffication Script table 0 b 10 0 100 255
Activate test mode a
Script table 0 b 10 0 101 255
Activate normal mode a
Script table 0 b 10 0 102 255
Set output signals Script table 0 b 10 0 103 255
Switch optical test output b, c
Script table 0 b 10 0 104 255
Power quality measurement management Script 0 b 10 0 105 255
table 9, Script table
Disconnect control Script table 0 b 10 0 106 255
Image activation Script table 0 b 10 0 107 255
Push Script table 0 b 10 0 108 255
Load profile control Script table 0 b 10 0 109 255
M-Bus profile control Script table 0 b 10 0 110 255
Function control Script table 0 b 10 0 111 255
a
The activation of these scripts is performed by calling the execute() method to the script identifier 1 of the
corresponding script object.
b
The optical test output is switched to measuring quantity Y and the test mode is activated by calling the
execute method of the script table object 0.x.10.0.104.255 using Y as parameter; where Y is given by Clause
7.5.1, Table 50. The default value of A is 1 (Electricity).
EXAMPLE In the case of electricity meters, A = 1, default, execute (21) switches the test output to
display the active power + of phase 1.
c
The optical test output is also switched back to its default value when this script is activated.
OBIS code
Special days table objects IC
A B C D E F
Special days table 11, Special days table 0 b 11 0 e 255
OBIS code
Schedule objects IC
A B C D E F
Schedule 10, Schedule 0 b 12 0 e 255
OBIS code
Activity calendar objects IC
A B C D E F
Activity calendar 20, Activity calendar 0 b 13 0 e 255
OBIS code
Register activation objects IC
A B C D E F
Register activation 6, Register activation 0 b 14 0 e 255
Instances of Push “Single action schedule” objects activate scripts in Push “Script table”
objects, which invoke the push method of the appropriate “Push setup” objects.
Load profile control “Single action schedule” objects activate scripts in Load profile control
“Script table” objects and thus allow extended time control.
M-Bus profile control “Single action schedule” objects activate scripts in M-Bus profile control
“Script table” objects and thus allow extended time control.
Function control “Single action schedule” objects activate scripts in Function control “Script
table” objects.
OBIS code
Single action schedule objects IC
A B C D E F
End of billing period Single action schedule 0 b 15 0 0 255
Disconnect control Single action schedule 0 b 15 0 1 255
Image activation Single action schedule 0 b 15 0 2 255
Output control Single action schedule 22, Single action 0 b 15 0 3 255
Push Single action schedule schedule 0 b 15 0 4 255
Load profile control Single action schedule 0 b 15 0 5 255
M-Bus profile control Single action schedule 0 b 15 0 6 255
Function control Single action schedule 0 b 15 0 7 255
In general, the logical name(s) shown in the table below shall be used. See also 6.3.9 and
6.3.10.
OBIS code
Register monitor objects IC
A B C D E F
Register monitor 0 b 16 0 e 255
21, Register monitor
Alarm monitor 0 b 16 1 0…9 255
OBIS code
Parameter monitor objects IC
A B C D E F
Parameter monitor 65, Parameter monitor 0 b 16 2 e 255
OBIS code
Limiter objects IC
A B C D E F
Limiter 71, Limiter 0 b 17 0 e 255
OBIS code
Array manager objects IC
A B C D E F
Array manager 123 0 b 18 0 e 255
An instance of the “Account” – see 4.6.2 – IC holds the summary information for a given contract
and lists the “Credit” and “Charge” objects used by that “Account”. If more than one “Account”
is for any reason required in a given context then field D should be other than 0.
One or several instances of the “Credit” IC – see 4.6.3.4 – represent the different credit sources.
One or several instances of the “Charge” IC – see 4.6.4 – represent the different charges
applicable.
One or more instances of the “Token gateway” IC – see 4.6.5 – are available to enter tokens.
If only a single gateway is defined in a single “Account” then field E of the OBIS code shall be
zero. If more than one “Token gateway” object is for any reason required in a single “Account”
then field E should be other than 0.
The “Account” is linked to it’s associated “Credit”, “Charge” and “Token gateway” objects by
use of the value group D and B field such that an “Account” with D=0 should be linked to a
“Token gateway” with D=40 and have a “Credit” objects with D=10 and “Charge” objects with
D=20. Whereas an “Account” with D=1 should have “token gateway” with D=41, “Credit” objects
with D=11 and “Charge” objects with D=21 etc. Multiple “Credit” and “Charge” objects are
identified using different values in the value group E field. See also Additional Notes there
describing the “Max credit_limit” and „Max vend limit” objects there.
Instances of “Profile Generic“ IC hold the history of the token credit and of the charge collections
with a “Parameter Monitor” interface class monitoring a value used to trigger capture.
OBIS code
IEC local port setup objects IC
A B C D E F
IEC optical port setup 0 b 20 0 0 255
19, IEC local port setup
IEC electrical port setup 0 b 20 0 1 255
OBIS code
Standard readout objects IC
A B C D E F
General local port readout 0 b 21 0 0 255
General display readout 0 b 21 0 1 255
Alternate display readout 0 b 21 0 2 255
Service display readout 0 b 21 0 3 255
7, Profile generic
List of configurable meter data 0 b 21 0 4 255
Additional readout profile 1 0 b 21 0 5 255
…………..
Additional readout profile n 0 b 21 0 N 255
For the parametrization of the standard readout “Data” objects can be used.
OBIS code
IEC HDLC setup objects IC
A B C D E F
IEC HDLC setup 23, IEC HDLC setup 0 b 22 0 0 255
An instance of the IC “MAC address set up” IC stores the Secondary Station Address ADS.
Instances of the IC “Profile generic” IC instances allow the configuration of IEC 62056-3-1
readout lists.
For the parametrization of the IEC 62056-3-1 readout “Data” objects can be used.
• instances of the IC “M-Bus slave port setup” define and control the behaviour of M-Bus slave
ports of a DLMS/COSEM device. See 4.8.2;
• instances of the IC “M-Bus client” are used to configure DLMS/COSEM devices as M-Bus
clients. There is one “M-Bus client” object for each M-Bus slave. Value group B identifies
the M-Bus channels. See 4.8.3;
• M-Bus value objects, instances of the IC “Extended register”, hold the values captured from
M-Bus slave devices on the relevant channel. The link between the M-Bus client setup
objects and the M-Bus value objects is provided by the channel number.
• M-Bus “Profile generic” objects capture M-Bus value objects possibly along with other, not
M-Bus specific objects;
• M-Bus “Disconnect control” objects control disconnect devices of M-Bus devices (e.g. gas
valves);
• instances of the IC “Wireless mode Q” define and control the behaviour of the device
regarding the communication parameters according to mode Q of EN 13757-5:2015. A node
having more than one network address, i.e. a multi-homed node, will have multiple objects
of these types. See 4.8.4;
• M-Bus control log objects are instances of the IC “Profile generic”. They log the changes of
the state of the disconnect devices;
• instances of the IC “M-Bus master port setup” define and control the behaviour of M-Bus
master ports of DLMS/COSEM devices, allowing to exchange data with M-Bus slaves. See
4.8.5;
• instances of the IC ”DLMS/COSEM server M-Bus port setup” are used in DLMS/COSEM
servers hosted by M-Bus slave devices, using the DLMS/COSEM wired or wireless M-Bus
communication profile. See 4.8.6;
• instances of the IC “M-Bus diagnostic” hold information related to the operation of the M-
Bus network. See 4.8.7.
• Instances of the IC “TCP-UDP setup” – see 4.9.1 – handle all information related to the
setup of the TCP and UDP layer of the Internet based communication profile(s), and point
to the IP setup object(s) handling the setup of the IP layer on which the TCP-UDP
connection(s) is (are) used;
• Instances of the IC “IPv4 setup” – see 4.9.2 – handle all information related to the setup of
the IPv4 layer of the Internet based communication profile(s) and point to the data link layer
setup object(s) handling the setup of the data link layer on which the IP connections is (are)
used;
• Instances of the IC “IPv6 setup” – see 4.9.3 – handle all information related to the setup of
the IPv6 layer of the Internet based communication profile(s) and point to the data link layer
setup object(s) handling the setup of the data link layer on which the IP connections is (are)
used;
• Instances of the IC “MAC address setup” – see 4.9.4 – handle all information related to the
setup of the Ethernet data link layer of the Internet based communication profile(s);
• Instances of the IC “PPP setup” – see 4.9.5 – handle all information related to the setup of
the PPP data link layer of the Internet based communication profiles;
• Instances of the IC “GPRS modem setup” – see 4.7.7 – handle all information related to the
setup of the GPRS modem;
• Instances of the IC “SMTP setup” – see 4.9.6 – handle all information related to the setup
of the SMTP service.
NOTE The following objects have internet related OBIS codes, although they are not strictly related to use over the
internet only.
• Instances of the IC “GSM diagnostic” – see 4.7.8 – handle all diagnostic information related
to the GSM/GPRS network.
• Instances of the IC "NTP setup" – see 4.9.7 – handle all information related to the setup of
the NTP time synchronisation service;
• Instances of the IC “LTE monitoring ” – see 4.7.9 – allow monitoring LTE modems.
OBIS code
Push Setup IC
A B C D E F
Push setup 40, Push setup 0 b 25 9 0 255
• Instances of the IC “S-FSK Phy&MAC setup” – see 4.10.3 – handle all information related
to setting up the PLC S-FSK lower layer profile specified in IEC 61334-5-1:2001;
• Instances of the IC “S-FSK Active initiator” – see 4.10.4 – handle all information related to
the active initiator in the PLC S-FSK lower layer profile specified in IEC 61334-5-1:2001;
• Instances of the IC “S-FSK MAC synchronization timeouts” – see 4.10.5 – manage all
timeouts related to the synchronization process of devices using the PLC S-FSK lower layer
profile specified in IEC 61334-5-1:2001;
• Instances of the IC “S-FSK MAC counters” – see 4.10.6 – store counters related to the frame
exchange, transmission and repetition phases in the PLC S-FSK lower layer profile specified
in IEC 61334-5-1:2001;
• Instances of the IC “IEC 61334-4-32 LLC setup” – see 4.10.7 – handle all information related
to the LLC layer specified in IEC 61334-4-32:1996;
• Instances of the IC “S-FSK Reporting system list” – see 4.10.8 – hold information on
reporting systems in the PLC S-FSK lower layer profile specified in IEC 61334-5-1:2001.
• Instances of the IC “ISO/IEC 8802-2 LLC Type 1 setup” – see 4.11.2 – handle all information
related to the LLC layer specified in ISO/IEC 8802-2:1998 in Type 1 operation;
• Instances of the IC “ISO/IEC 8802-2 LLC Type 2 setup” – see 4.11.3 – handle all information
related to the LLC layer specified in ISO/IEC 8802-2:1998 in Type 2 operation;
• Instances of the IC “ISO/IEC 8802-2 LLC Type 3 setup” – see 4.11.4 – handle all information
related to the LLC layer specified in ISO/IEC 8802-2:1998 in Type 3 operation.
• an instance of the 61334-4-32 LLC SSCS setup – see 4.12.3 – holds the addresses related
to the CL_432 layer;
• an instance of the IC “PRIME NB OFDM PLC Physical layer counters” – see 4.12.5 – stores
counters related to the physical layers exchanges;
• an instance of the IC “PRIME NB OFDM PLC MAC setup” – see 4.12.6 – holds the necessary
parameters to set up the PRIME NB OFDM PLC MAC layer;
• an instance of the IC “PRIME NB OFDM PLC MAC functional parameters” – see 4.12.7 –
provides information on specific aspects concerning the functional behaviour of the MAC
layer;
• an instance of the IC “PRIME NB OFDM PLC MAC counters” – see 4.12.8 – stores statistical
information on the operation of the MAC layer for management purposes;
• an instance of the IC “PRIME NB OFDM PLC MAC network administration data” – see 4.12.9
– holds the parameters related to the management of the devices connected to the network;
• an instance of the IC “MAC address setup” – holds the MAC address of the device. See
4.12.10;
• an instance of the IC “PRIME NB OFDM PLC Application identification” – see 4.12.11 –
holds identification information related to administration and maintenance of PRIME NB
OFDM PLC devices.
• an instance of the IC “G3-PLC MAC layer counters” – see 4.13.3 – to store counters related
to the MAC layer exchanges;
• an instance of the IC “G3-PLC MAC setup” – see 4.13.4 – to hold the necessary parameters
to set up the G3-PLC MAC IEEE 802.15.4 layer;
• an instance of the IC “G3-PLC 6LoWPAN adaptation layer setup” – see 4.13.5 – to hold the
necessary parameters to set up the Adaptation layer.
• an instance of the IC “HS-PLC ISO/IEC 12139-1 MAC setup” – see 4.14.2 – holds the
necessary parameters for setting up the MAC layer;
• an instance of the IC “HS-PLC ISO/IEC 12139-1 CPAS setup” – see 4.14.3 – holds the
necessary parameters for setting up the CPAS;
• an instance of the IC “HS-PLC ISO/IEC 12139-1 IP SSAS setup” – see 4.14.4 – holds the
necessary parameters for setting up the IP SSAS;
• an instance of the IC “HS-PLC ISO/IEC 12139-1 HDLC SSAS setup” – see 4.14.5 – holds
the necessary parameters for setting up the HDLC SSAS.
OBIS code
Association objects IC
A B C D E F
Current association 0 0 40 0 0 255
Association, instance 1 12, Association SN 0 0 40 0 1 255
………….. 15, Association LN
OBIS code
SAP Assignment object IC
A B C D E F
SAP assignment of current physical 17, SAP assignment
0 0 41 0 0 255
device
OBIS code
COSEM logical device name object IC
A B C D E F
COSEM logical device name 1, Data a
0 0 42 0 0 255
a
If the IC “Data” is not available, “Register” (with scaler = 0, unit = 255) may be used.
OBIS code
Security setup objects IC
A B C D E F
Security setup 64, Security setup 0 0 43 0 e 255
Invocation counter objects hold the invocation counter element of the initialization vector. They
are instances of the IC “Data”. The value in value group B identifies the communication channel.
NOTE The same client may use different communication channels e.g. a remote port and a local port. The invocation
counter on the different channels may be different.
The value in value group E shall be the same as in the logical name of the corresponding
“Security setup” object.
OBIS code
Invocation counter objects IC
A B C D E F
Invocation counter 1, Data a
0 b 43 1 e 255
NOTE In earlier version of the Blue Book, these objects were called Frame counter objects.
a
If the IC “Data” is not available, “Register” (with scaler = 0, unit = 255) may be used.
Instances of the IC “Data protection” – see 4.4.9 – are used to apply / remove protection on
COSEM data, i.e. sets of attributes values, method invocation and return parameters. Value
group E numbers the instances.
OBIS code
Data protection objects IC
A B C D E F
Data protection 30, Data protection 0 0 43 2 e 255
OBIS code
Image transfer related objects IC
A B C D E F
Image transfer 18, Image transfer 0 0 44 0 e 255
OBIS code
Function control related objects IC
A B C D E F
Function control 122, Function control 0 0 44 1 e 255
OBIS code
Utility table objects IC
A B C D E F
Manufacturer tables 0-127 0 b 65 16 e 255
Manufacturer tables 128-255 0 b 65 17 e 255
...
Manufacturer tables 1920-2047 0 b 65 31 e 255
Std pending tables 0-127 0 b 65 32 e 255
Std pending tables 128-255 0 b 65 33 e 255
...
Std pending tables 1920-2047 0 b 65 47 e 255
Mfg pending tables 0-127 0 b 65 48 e 255
Mfg pending tables 128-255 0 b 65 49 e 255
...
Mfg pending tables 1920-2047 0 b 65 63 e 255
OBIS code
Compact data objects IC
A B C D E F
Compact data 62, Compact data 0 b 66 0 e 255
They are held by the value attribute of "Data" objects, with data type double-long-unsigned,
octet-string, visible-string, utf8-string, unsigned, long-unsigned. If more than one of those is
used, it is allowed to combine them into a "Profile generic" object. In this case, the captured
objects are value attributes of the device ID “Data” objects, the capture period is 1 to have just
actual values, the sort method is FIFO and the profile entries are limited to 1. Alternatively, a
“Register table” object – see 4.3.8 – can be used. See also Table 56.
OBIS code
Device ID objects IC
A B C D E F
Device ID 1…10 object (manufacturing 0 b 96 1 0…9 255
1, Data
number)
Device ID-s object 7, Profile generic 0 b 96 1 255 255
Device ID-s object 61, Register table 0 b 96 1 255 255
OBIS code
Metering point ID objects IC
A B C D E F
Metering point ID 1, Data 0 b 96 1 10 255
OBIS code
Parameter changes objects IC
A B C D E F
For names and OBIS codes see Table 56. 1, Data 0 b 96 2 e 255
The status is held by the value attribute of a “Data” object, with data type octet-string, boolean
or bit-string. Alternatively, the status is held by a “Status mapping” object, see 4.3.9, which
holds both the status word and the mapping of its bits to the reference table. If there are several
I/O control status objects used, it is allowed to combine them into an instance of the IC “Profile
generic” or “Register table”, using the OBIS code of the global state of I/O control signals object.
See also Table 56.
OBIS code
I/O control signal objects IC
A B C D E F
I/O control signal objects, contents
1, Data 0 b 96 3 0…4 255
manufacturer specific
I/O control signal objects, contents
63, Status mapping 0 b 96 3 0…4 255
mapped to a reference table
7, Profile generic or
I/O control signal objects, global 0 b 96 3 0 255
61, Register table
OBIS code
Disconnect control objects IC
A B C D E F
Disconnect control 70, Disconnect control 0 b 96 3 10 255
OBIS code
Arbitrator Objects IC
A B C D E F
20…
General-purpose Arbitrator 68, Arbitrator 0 b 96 3 255
29
The status carries binary information from a bitmap, and it shall be held by the value attribute
of a “Data” object, with data type boolean, bit-string, unsigned, long-unsigned, double-long-
unsigned, long64-unsigned or octet-string. Alternatively, the status is held by a “Status
mapping” object, see 4.3.9, which holds both the status word and the mapping of its bits to the
reference table. If there are several status of internal control signals objects used, it is allowed
to combine them into an instance of the IC “Profile generic” or “Register table”, using the OBIS
code of the global “Internal control signals” object. See also Table 56.
OBIS code
Internal control signals objects IC
A B C D E F
Internal control signals, contents
1, Data 0 b 96 4 0...4 255
manufacturer specific
Internal control signals, contents
63, Status mapping 0 b 96 4 0...4 255
mapped to a reference table
7, Profile generic or
Internal control signals, global 0 b 96 4 0 255
61, Register table
The status carries binary information from a bitmap, and it shall be held by the value attribute
of a “Data” object, with data type boolean, bit-string, unsigned, long-unsigned, double-long-
unsigned, long64-unsigned or octet-string. Alternatively, the status is held by a “Status
mapping” object, see 4.3.9, which holds both the status word and the mapping of its bits to the
reference table. If there are several status of internal control signals objects used, it is allowed
to combine them into an instance of the IC “Profile generic” or “Register table”, using the OBIS
code of the global ”Internal operating status” object. See also Table 56.
OBIS code
Internal operating status objects IC
A B C D E F
Internal operating status objects,
1, Data 0 b 96 5 0...4 255
contents manufacturer specific
Internal operating status objects,
63, Status mapping 0 b 96 5 0...4 255
contents mapped to a reference table
Internal operating status objects, 7, Profile generic or
0 b 96 5 0 255
global 61, Register table
Internal operating status objects can also be related to an energy type. See 6.3.7.
OBIS code
Battery entries objects IC
A B C D E F
For names and OBIS codes see Table 1, Data, 3, Register or
0 b 96 6 0...6 255
56. 4, Extended register
• For simple power failure monitoring, it is possible to count the number of power failure
events affecting all three phases, one of the three phases, any of the phases, and the
auxiliary supply;
• For advanced power failure monitoring, it is possible to define a time threshold to make a
distinction between short and long power failure events. It is possible to count the number
of such long power failure events separately from the short ones, as well as to store their
time of occurrence and duration (time from power down to power up) in all three phases, in
one of the three phases and in any of the phases;
• The number of power failure events objects are represented by instances of the IC “Data”,
“Register” or “Extended register” with data types unsigned, long-unsigned, double-long-
unsigned or long64-unsigned;
• The power failure duration, time and time threshold data are represented by instances of
the IC “Data”, “Register” or “Extended register” with appropriate data types;
• If power failure duration objects are represented by instances of the IC “Data”, then the
default scaler shall be 0, and the default unit shall be the second.
OBIS code
Power failure monitoring objects IC
A B C D E F
For names and OBIS codes see Table 1, Data, 3, Register or 0...
0 b 96 7 255
56. 4, Extended register 21
These objects may be collected in a “Power failure event log” object. See Table 71.
OBIS code
Operating time objects IC
A B C D E F
For names and OBIS codes see Table 1, Data, 3, Register or 0...
0 b 96 8 255
56. 4, Extended register 63
OBIS code
Status register objects IC
A B C D E F
The status register is held by the value attribute of a “Data” object, with data type bit-string,
unsigned, long-unsigned, double-long-unsigned, long64-unsigned or octet-string. It carries
binary information from a bitmap. It’s contents is not specified.
Alternatively, the status register may be held by the status_word attribute of a “Status mapping”
object, see 4.3.9. The mapping_table attribute holds mapping information between the bits of
the status word and entries of a reference table.
OBIS code
Event code objects IC
A B C D E F
For names and OBIS codes see Table 1, Data, 3, Register, or 0…
0 b 96 11 255
56. 4, Extended register 99
Events may also set flags in error registers and alarm registers. See also 6.2.59.
OBIS code
Consumer message objects IC
A B C D E F
OBIS code
Currently active tariff objects IC
A B C D E F
For names and OBIS codes see Table 1, Data, 3, Register, or 0…
0 b 96 14 255
56. 4, Extended register 15
OBIS code
Event counter objects IC
A B C D E F
For names and OBIS codes see Table 1, Data, 3, Register, or 0…
0 b 96 15 255
56. 4, Extended register 99
The security context is determined by the “Security setup” object which is which is visible in the
same AA (object_list).
NOTE The digital signature may be generated when the entry is captured or “on the fly”, when an entry is accessed.
• Meter open events are related to cases when the meter case is open;
• Terminal cover open events are related to cases when a terminal cover is removed (open);
• Tilt events are related to cases when the meter is not in its normal operation position;
• Strong DC magnetic field events are related to cases when the presence of a strong DC
magnetic field is detected;
• Metrology tamper events are related to cases when an anomaly in the operation of the
metrology is detected due to a perceived tamper;
• Communication tamper events are related to cases when an anomaly in the operation of the
communication interfaces is detected due to a perceived tamper.
The method of detecting the various tampers is out of the Scope of this document.
OBIS code
Meter tamper event related objects IC
A B C D E F
For names and OBIS codes see Table 1, Data, 3, Register, or
0 b 96 20 e 255
56. 4, Extended register
The individual bits of the error register may be set and cleared by a pre-defined selection of
events – see 6.2.51. Depending on the type of the error, some errors may clear themselves
when the reason setting the error flag disappears.
If more than one of those objects is used, it is allowed to combine them into one instance of the
IC "Profile generic". In this case, the captured objects are the value attributes “Data” objects,
the capture period is 1 to have just actual values, the sort method is FIFO, the profile entries
are limited to 1. Alternatively, an instance of the IC “Register table” can be used.
Error register objects can also be related to an energy type and to a channel. See 7.4.2, 7.5.5.2,
7.6.4.2, 7.7.4.2, 7.9.4.2.
OBIS code
Error register objects IC
A B C D E F
Error register 1…10 object 1, Data 0 b 97 97 0…9 255
Error profile object 7, Profile generic 0 b 97 97 255 255
Error table object 61, Register table 0 b 97 97 255 255
If more than one of those objects is used, it is also allowed to combine them into one instance
of the IC "Profile generic". In this case, the captured objects are the value attributes of “Data”
objects, the capture period is 1 to have just actual values, the sort method is FIFO, and the
profile entries are limited to 1. Alternatively, an instance of the IC “Register table” can be used.
Alarm filter objects are available to define if an event is to be handled as an alarm when it
appears. The different alarm filters are held by the value attribute of “Data” objects, with data
type bit-string, octet-string, unsigned, long-unsigned, double-long-unsigned or long64-
unsigned. The bit mask has the same structure as the corresponding alarm register object. If a
bit in the alarm filter is set, then the corresponding alarm is enabled, otherwise it is disabled.
Alarm filter objects act on Alarm register and Alarm descriptor objects the same way.
Alarm descriptor objects are available to persistently hold the occurrence of alarms. The
different alarm descriptors are of the same type as the corresponding Alarm register. When a
selected event occurs, the corresponding flag is set in the Alarm register as well as in the Alarm
descriptor objects. An alarm descriptor flag remains set even if the corresponding alarm
condition has disappeared. Alarm descriptor flags do not reset themselves; they can be reset
by writing the value attribute only.
NOTE The alarm conditions, the structure of the Alarm register / Alarm filter / Alarm descriptor objects are subject
to a project specific companion specification.
OBIS code
General list objects IC
A B C D E F
For names and OBIS codes see 7.4.3. 7, Profile generic 0 b 98 d e 255 a
a
F = 255 means a wildcard here. See 7.11.3.
OBIS code
Event log objects IC
A B C D E F
Event log 7, Profile generic a b 99 98 e 255 a
a
F = 255 means a wildcard here. See 7.11.3.
NOTE 1 Event logs may capture for example the time of occurrence of the event, the event code and other
relevant data.
NOTE 2 Project specific companion specifications may specify a more precise meaning of the instances of
the different event logs, i.e. the data captured and the number of events captured.
OBIS code
Inactive objects IC
A B C D E F
Inactive objects Any 0 b 127 0 e 255
If more than one of those is used, it is allowed to combine them into a "Profile generic" object.
In this case, the captured objects are value attributes of 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. Alternatively, a “Register table” object can be used. See also Table 57.
OBIS code
ID objects – Electricity IC
A B C D E F
Electricity ID 1…10 object 1, Data 1 b 0 0 0…9 255
Electricity ID-s object 7, Profile generic 1 b 0 0 255 255
Electricity ID-s object 61, Register table 1 b 0 0 255 255
For billing period / reset counters and for number of available billing periods the data type shall
be unsigned, long-unsigned or double-long-unsigned. For time stamps of billing periods, the
data type shall be double-long-unsigned (in the case of UNIX time), octet-string or date-time
formatted as specified in 4.1.6.1.
When the values of historical periods are represented by “Profile generic” objects, the time
stamp of the billing period objects shall be part of the captured objects.
Output pulse constant, reading factor, CT/VT ratio, nominal value, input pulse constant,
transformer and line loss coefficient values shall be represented by instances of the IC “Data”,
"Register" or “Extended register”. For the value attribute, only simple data types are allowed.
Measurement period, recording interval and billing period duration values shall be represented
by instances of IC “Data”, “Register” or “Extended register” with the data type of the value
attribute unsigned, long-unsigned or double-long-unsigned. The default unit is the second.
OBIS code
Measurement algorithm objects IC
A B C D E F
Measuring algorithm for active power 1 b 0 11 1 255
Measurement algorithm for active energy 1 b 0 11 2 255
Measurement algorithm for reactive power 1 b 0 11 3 255
Measurement algorithm for reactive energy 1 b 0 11 4 255
1, Data
Measurement algorithm for apparent power 1 b 0 11 5 255
Measurement algorithm for apparent 1 b 0 11 6 255
energy
Measurement algorithm for power factor
1 b 0 11 7 255
calculation
(1) (sum of) reactive power of each phase, calculated from the fundamental 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
Measurement algorithm for apparent power and energy
(0) not specified
(1) S =U×I , with voltage: only fundamental, and current: only fundamental
(2) S =U×I , with voltage: only fundamental, and current: all harmonics
(3) S =U×I , with voltage: only fundamental, and current: all harmonics and DC part
(4) S =U×I , with voltage: all harmonics, and current: only fundamental
(5) S =U×I , with voltage: all harmonics, and current: all harmonics
(6) S =U×I , with voltage: all harmonics, and current: all harmonics and DC part
(7) S =U×I , with voltage: all harmonics and DC part, and current: only fundamental
(8) S =U×I , with voltage: all harmonics and DC part, and current: all harmonics
(9) S =U×I , with voltage: all harmonics and DC part, and current: all harmonics and DC part
(10) 2 2
S = P +Q , with P: only fundamental in U and I, and Q: only fundamental in U and I,
where P and Q are polyphase quantities
(11) 2 2
S = P +Q , with P: all harmonics in U and I, and Q: only fundamental in U and I
where P and Q are polyphase quantities
(12) 2 2
S = P +Q , with P: all harmonics and DC part in U and I, and Q: only fundamental in U and I
where P and Q are polyphase quantities
(13) 2 2
S = ∑ P +Q , with P: only fundamental in U and I, and Q: only fundamental in U and I
where P and Q are single phase quantities
(14) 2 2
S = ∑ P +Q , with P: all harmonics in U and I, and Q: only fundamental in U and I
where P and Q are single phase quantities
(15) 2 2
S = ∑ P +Q , with P: all harmonics and DC part in U and I, and Q: only fundamental in U and I
where P and Q are single-phase quantities
Measurement algorithm for power factor calculation
(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.
value attributes of the electricity related metering point 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.
Alternatively, an instance of the IC “Register table” can be used. For detailed OBIS codes, see
Table 57.
OBIS code
Metering point ID objects IC
A B C D E F
Metering point ID 1…10 (electricity
1, Data a
1 b 96 1 0…9 255
related)
Metering point ID-s object 7, Profile generic 1 b 96 1 255 255
Metering point ID-s object 64, Register table 1 b 96 1 255 255
a
If the IC “Data” is not available, “Register” (with scaler = 0, unit = 255) may be used.
The status is held by the value attribute of a “Data” object, with data type boolean, bit-string,
unsigned, long-unsigned, double-long-unsigned, long64-unsigned or octet-string.
Alternatively, the status is held by a “Status mapping” object, which holds both the status word
and the mapping of its bits to the reference table.
If there are several electricity related internal operating status objects used, it is allowed to
combine them into an instance of the IC “Profile generic” or “Register table”, using the OBIS
code of the global internal operating status. For detailed OBIS codes, see Table 57.
OBIS code
Electricity related status objects IC
A B C D E F
Internal operating status signals,
electricity related, contents 1, Data 1 b 96 5 0...5 255
manufacturer specific
Internal operating status signals,
electricity related, contents mapped to 63, Status mapping 1 b 96 5 0...5 255
reference table
Electricity related status data,
1, Data 1 b 96 10 0...3 255
contents manufacturer specific
Electricity related status data,
63, Status mapping 1 b 96 10 0...3 255
contents mapped to reference table
One standard object per billing period scheme is defined. See also 7.5.5.3.
OBIS code
List objects – Electricity IC
A B C D E F
For names and OBIS codes see Table 7, Profile generic
1 b 98 d e 255 a
59.
a
F = 255 means a wildcard here. See 7.11.3.
Objects are also available to represent the number of occurrences when these thresholds are
exceeded, the duration of such events and the magnitude of the quantity during such events.
OBIS code
Threshold objects IC
A B C D E F
1...10,
13, 14,
16...20,
21...30,
33, 34,
36...40,
Threshold objects for 41...50,
1 b 0...63
instantaneous values 53, 54,
56...60,
1, Data, 31...34,
61...70,
3, Register, 73, 74, 35...38, 0...99,
4, Extended 76...80, 39...42, 255
register 82, 43...45
84...89
11, 12,
15, 31,
Threshold objects for 32, 35, 0...120,
harmonics of voltage, current 1 b 51, 52, 124...
and active power 55, 71, 127
72, 75,
90…92
For monitoring the supply voltage, a more sophisticated functionality is also available, that
allows counting the number of occurrences classified by the duration of the event and the depth
of the voltage dip. For OBIS codes, see 7.5.3.6, Table 57.
• for monitoring thresholds of instantaneous values, the logical name of the “Register monitor”
object may be the OBIS identifier of the threshold;
• for monitoring current average and last average values, the logical name of the “Register
monitor” object may be the OBIS identifier of the demand value monitored.
See Table 30.
OBIS code
Register monitor objects IC
A B C D E F
1 b c1 0-63
31,
Instantaneous values, under 0-120,
35,
limit / over limit / missing 1 b c2 39 124-
127 0-99,
21, Register monitor
1 b c1 0-63 255
4, 5,
Current average and last 0-120,
average values 14, 15,
1 b c2 24, 25 124-
127
c1 = 1-10, 13,14, 16-20, 21-30, 33,34, 36-40, 41-50, 53,54, 56-60, 61-70, 73,74, 76-80, 82, 84-89.
c2 = 11, 12, 15, 31, 32, 35, 51, 52, 55, 71, 72, 75, 90-92.
For the use of value group E, see Table 52 and Table 53.
Grouping the data by major categories supports the link between the data and the OBIS value
groups associated with them.
If more than one of those is used, it is allowed to combine them into a "Profile generic" object.
In this case, the captured objects are value attributes of the HCA 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. Alternatively, an instance of the IC “Register table” can be used. See also Table 65.
OBIS code
HCA ID 3IC
A B C D E F
HCA ID 1…10 object 1, Data 4 b 0 0 0…9 255
HCA ID-s object 7, Profile generic 4 b 0 0 255 255
HCA ID-s object 61, Register table 4 b 0 0 255 255
For billing period / reset counters and for number of available billing periods the data type shall
be unsigned, long-unsigned or double-long-unsigned. For time stamps of billing periods, the
data type shall be double-long-unsigned (in the case of UNIX time), octet-string, date or date-
time formatted as specified in 4.1.6.1. These objects may be related to channels.
When the values of historical periods are represented by “Profile generic” objects, the time
stamp of the billing period objects shall be part of the captured objects.
• Configuration entries are represented by instances of the IC "Data" with data type unsigned,
long-unsigned or octet-string or enumerated. Configuration entries can also be related to a
channel;
• Device measuring principle values are represented by instances of the IC “Data” with data
type unsigned or enumerated for the value attribute;
Enum Value
(0) Single sensor
(1) Single sensor + start sensor
(2) Dual sensor
(3) Triple sensor
Other reserved
OBIS code
Consumption IC
A B C a
Db Ec F
Integral value, current 0 255
OBIS code
Temperature IC
A B Ca Db Ec F
3, Register or
Temperature value, current 4, Extended 0
register
4, Extended 4,5
Minimum, Maximum of
register, or
temperature 4 b 3..7 255 255
7, Profile generic
3, Register,
4, Extended
Temperature test value 6
register, or
7, Profile generic
a
See Table 62– Value group C codes – HCA
b
See Table 63– Value group D codes – HCA
c
Value group E not used. Therefore, E shall be 255.
The different error registers are held by the value attribute of “Data”, “Register” or “Extended
register“ objects, with data type bit-string, octet-string, unsigned, long-unsigned, double-long-
unsigned or long64-unsigned.
OBIS code
Error register objects - HCA IC
A B C D E F
1, Data or
Error register objects 3, Register or 4 b 97 97 e 255
4, Extended register
These COSEM objects are used to model lists of any kind of data, for example measurement
values, constants, statuses, events. They are modelled by “Profile generic” objects. Examples
are present in 7.6.5.3.
OBIS code
List objects – HCA IC
A B C D E F
For names and OBIS codes see XX 7, Profile generic 4 b 98 d e 255 a
a
F = 255 means a wildcard here. See 7.6.
HCA related data profiles – identified with one single OBIS code – are used to hold a series of
measurement values of one or more similar quantities and/or to group various data. See also
7.6.4.4.
OBIS code
Data profile objects - HCA IC
A B C D E F
Data profile objects 7, Profile generic 4 b 99 1 e 255
Grouping the data by major categories supports the link between the data and the OBIS value
groups associated with them.
If more than one of those is used, it is allowed to combine them into a "Profile generic" object.
In this case, the captured objects are value attributes of the thermal meter 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. Alternatively, an instance of the IC “Register table” can be used. See also Table
73
OBIS code
Thermal energy meter ID IC
A B C D E F
Thermal energy meter ID 1…10 object 1, Data 5/6 b 0 0 0…9 255
Thermal energy meter ID-s object 7, Profile generic 5/6 b 0 0 255 255
Thermal energy meter ID-s object 61, Register table 5/6 b 0 0 255 255
For billing period / reset counters and for number of available billing periods the data type shall
be unsigned, long-unsigned or double-long-unsigned. For time stamps of billing periods, the
data type shall be double-long-unsigned (in the case of UNIX time), octet-string or date-time
formatted as specified in 4.1.6.1.
When the values of historical periods are represented by “Profile generic” objects, the time
stamp of the billing period objects shall be part of the captured objects.
• Configuration entries are represented by instances of the IC "Data" with data type unsigned,
long-unsigned or octet-string. Configuration entries can also be related to a channel;
• Conversion factor values are represented by instances of the IC “Data”, "Register" or
“Extended register”. For the value attribute, only simple data types are allowed;
• Threshold values are represented by instances of the IC "Register" or “Extended register”.
For the value attribute, only simple data types are allowed;
• Timing information for averaging, measurement, billing periods and recording interval is
presented by instances of IC “Data”, “Register” or “Extended register” with the data type of
the value attribute unsigned, long-unsigned or double-long-unsigned;
• Time entry values are represented by instances of IC “Data”, “Register” or “Extended
register” with the data type of the value attribute double-long-unsigned (in the case of UNIX
time), octet-string or date-time formatted as specified in 4.1.6.1.
OBIS code
Consumption IC
A B C a
Db Ec F
3, Register or
Energy, volume, mass
4, Extended register, 0...3, 7 255
values
or 7, Profile generic
3, Register or 0…99,
Integral value relative to
4, Extended register, 3, 8, 9 101...125,
billing periods
or 7, Profile generic 255
3, Register or 0,
Periodical value 4, Extended register, 1,12,13 1...9
or 7, Profile generic 5/6 b 1...7
3, Register or 0…99,
Set date value 4, Extended register, 2
or 7, Profile generic 101...125
Monitoring values are held by the value attribute of “Register” or “Extended register“ objects
with data types double-long,double-long-unsigned, octet-string, visible-string, integer,
long,unsigned, long-unsigned, long64, long64-unsigned, float32 or float64.
OBIS code
Monitoring values IC
A B Ca Db Ec F
4, Extended
Energy, volume, mass
register, or 1...7 5,15
Maximum of integral value
7, Profile generic 0...99,
3, Register, or 101...125
4, Extended 1, 4, 5, , 255
Power or flow rate values 8,9
register, or 12...15
7, Profile generic
3, Register or
Temperature or pressure 4, Extended
0 255
value, current register, or
7, Profile generic
4, Extended
Minimum, Maximum of 0...99,
register, or 4, 5, 14, 15
temperature or pressure 101...125
7, Profile generic 10... 13 0,
5/6 b
3, Register, or 1..9
Temperature or pressure
4, Extended 6,7
test, instantaneous value
register
5, Demand
Average values of
register, or 10,11
temperature or pressure
7, Profile generic
3, Register, or 255
4, Extended
Occurrence counters 20, 22, 24
register, or
7, Profile generic
1...13
3, Register, or
4, Extended
Occurrence durations 21, 23, 25
register, or
7, Profile generic
a
See Table 70 – Value group C codes – Thermal energy meter
b
See Table 71 – Value group D codes - Thermal energy meter
c
All other values reserved for further use (tariff rate E=0 means Total)
The different error registers are held by the value attribute of “Data”, “Register” or “Extended
register“ objects, with data type bit-string, octet-string, unsigned, long-unsigned, double-long-
unsigned or long64-unsigned.
OBIS code
List objects – Thermal energy meter IC
A B C D E F
For names and OBIS codes see XX 7, Profile generic 5/6 b 98 d e 255 a
a
F = 255 means a wildcard here. Also note 7.7.4.3.
6.6.1 General
The use of interface classes to represent various data is described in the following tables.
Grouping the data by major categories supports the link between the data and the OBIS value
groups associated with them.
If more than one of those is used, it is allowed to combine them into a "Profile generic" object.
In this case, the captured objects are value attributes of the gas 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. Alternatively, an instance of the IC “Register table” can be used. See also Table 89.
OBIS code
Gas ID IC
A B C D E F
Gas ID 1…10 object 1, Data 7 b 0 0 0…9 255
Gas ID-s object 7, Profile generic 7 b 0 0 255 255
Gas ID-s object 61, Register table 7 b 0 0 255 255
For billing period / reset counters and for number of available billing periods the data type shall
be unsigned, long-unsigned or double-long-unsigned. For time stamps of billing periods, the
data type shall be double-long-unsigned (in the case of UNIX time), octet-string or date-time
formatted as specified in 4.1.6.1.
When the values of historical periods are represented by “Profile generic” objects, the time
stamp of the billing period objects shall be part of the captured objects.
For the digital and analogue output configuration objects the enumerated values are specified
in Table 31 below.
(2) 2= 0–20 mA
(3) 3= Voltage output
• Output pulse constant values are represented by instances of the IC “Data”, "Register" or
“Extended register”. For the value attribute, only simple data types are allowed;
• Conversion factor values are represented by instances of the IC “Data”, "Register" or
“Extended register”. For the value attribute, only simple data types are allowed;
• Threshold values are represented by instances of the IC "Register" or “Extended register”.
For the value attribute, only simple data types are allowed;
• Nominal values of volume sensors are represented by instances of the IC "Register" or
“Extended register”. For the value attribute, only simple data types are allowed;
• Input pulse constant values are represented by instances of the IC “Data”, "Register" or
“Extended register”. For the value attribute, only simple data types are allowed;
• Interval and period values are represented by instances of IC “Data”, “Register” or
“Extended register” with the data type of the value attribute unsigned, long-unsigned or
double-long-unsigned;
• Time entry values are represented by instances of IC “Data”, “Register” or “Extended
register” with the data type of the value attribute octet-string, formatted as date-time in
4.1.6.1. The data types unsigned, integer, long-unsigned or double-long-unsigned can also
be used where appropriate;
• Station management information values are represented by instances of the IC "Register"
or “Extended register”. For the value attribute, only simple data types are allowed;
• Gas parameters for volume conversion currently used in compressibility calculation values
are represented by instances of the IC “Data”, "Register" or “Extended register”. For the
value attribute, only simple data types are allowed;
• Gas measuring method specific parameters, including gas parameters for Venturi
measurement and for density measurement are represented by instances of the IC “Data”,
"Register" or “Extended register”. For the value attribute, only simple data types are allowed.
• “Sensor manager” objects – see 4.5.11 – manage complex information related to sensors.
See 4.5.11. This interface class will be used by the following (metrological) sensors e.g. in
gas applications:
• absolute temperature;
• absolute pressure;
• velocity of sound;
• density of gas;
• relative density;
• gauge pressure;
• differential pressure;
• density of air.
Value group E of the OBIS code can be mapped to the value group C codes, identifying the
various physical quantities, see Table 79. The possible values are 41, 42, 44, 45...49.
EXAMPLE Absolute pressure sensor manager object OBIS code 7.0.0.15.42.255.
If there is more than one sensor for the same physical quantity, then value group B shall be
used to identify the sensors.
For detailed item names and OBIS codes see Table 89.
OBIS code
Gas related general purpose objects IC
A B C D E F
Configuration objects 1, Data 7 b 0 2 e 255
Output pulse constants converted /
1, Data 7 b 0 3 e 255
unconverted
Conversion factors 1, Data 7 b 0 4 e 255
3, Register or
Threshold values 7 b 0 5 e 255
4, Extended register
3, Register or
Nominal values volume sensor 7 b 0 6 e 255
4, Extended register
Input pulse constants 1, Data 7 b 0 7 e 255
Intervals and periods 1, Data 7 b 0 8 e 255
Time entries 1, Data 7 b 0 9 e 255
3, Register or 10,
Station management information 7 b 0 e 255
4, Extended register 11
Gas parameters for volume conversion,
1, Data, 3, Register or 4,
currently used in compressibility 7 b 0 12 e 255
Extended register
calculation
Gas measuring method specific 1, Data, 3, Register or 4, 13,
7 b 0 e 255
parameters Extended register 14
Sensor manager objects 67, Sensor manager 7 b 0 15 e 255
33…41, 0…99
Maximum of index Extended
51…62, 101…
differences over billing register, or
72…80, 126,
periods Profile generic
90…98 255
a
See Table 79 – Value group C codes – Gas
b
See Table 80 – Value group D codes – Gas – Indexes and index differences
c
See Table 85 – Value group E codes – Gas – Indexes and index differences – Tariff rates
OBIS code
Flow rate IC
A B Ca Db E F
Register or
Flow rate, instantaneous 0, 1, 2,
Extended 0 255
values 13,
register
15...18,
19…22,
Register,
35...38,
Flow rate current average Extended
39...42,
and last average values register or 0 255
55…58,
over averaging periods Demand
59…62,
register
63…66,
7 b 43 67…70
23…26,
Maximum of last averages of Extended 27…30,
flow rates relative to register or 255
measuring period Profile generic 43…46,
47…50
0…99,
Maximum of last averages of Extended
31…34, 101…
flow rates relative to billing register or 0
51…54 126,
period 1 Profile generic
255
a
See Table 79 – Value group C codes – Gas
b
See Table 81 – Value group D codes – Gas – Flow rate
OBIS code
Process values IC
A B Ca Db E F
Measurands of the gas
process in different 0, 2, 3,
conditions, average values, Register or 41, 42, 10, 11,
7 b 0 255
minima and maxima Extended register 44...49 13,
relative to different process 15…92
intervals
a
See Table 79 – Value group C codes – Gas
b
See Table 82 – Value group D codes – Gas – Process values
Only one calculation method per calculation process can be in use, but gas measurement
devices may have the capability to support various calculation methods. The choice of the
methods may depend on regulation, national or company requirements etc. The use of these
objects should be part of project specific companion specifications. The contents of the
calculation methods listed are not defined in this document.
The calculation method is held by the value attribute with data types octet-string, visible-string,
unsigned, long-unsigned or enumerated.
NOTE Calculation methods for compressibility factor Z can be found for example in ISO 12213-3, EN 12405-1, EN
12405-2 and AGA 8. EN 12405-1 also offers methods for volume conversion and EN 12405-2 for energy conversion.
OBIS code
Calculation methods IC
A B Ca Db Ec F
Data, Register
Calculation methods or Extended 7 b 51...55 12 0…20 255
register
a
See Table 79 – Value group C codes – Gas
b
See Table 83 – Value group D codes – Gas – Conversion related factors and coefficients
c
See Table 87 – Value group E codes – Gas – Calculation methods – Value group E codes – Gas – Calculation
methods
OBIS code
Natural gas analysis IC
A B Ca Db Ec F
Reference values of gas
8,9 0
analysis process
Gas characteristics
Register or 0,1
Process independent current
Extended 7 b 70 255
value, and weighted value 10...20,
register
Gas characteristics 60...84
Average values for current and 11…28
last intervals
a
See Table 79 – Value group C codes – Gas
b
See Table 84 – Value group D codes – Gas – Natural gas analysis values
c
See Table 88 – Value group E codes – Gas – Natural gas analysis values – Averages
One standard object per billing period scheme is defined. See also 7.8.6.3.
OBIS code
List objects - Gas IC
A B C D E F
For names and OBIS codes see Table 7, Profile generic
91 – OBIS codes for list objects – 7 b 98 d e 255 a
Gas.
a
F = 255 means a wildcard here. See 7.11.3.
Grouping the data by major categories supports the link between the data and the OBIS value
groups associated with them.
If more than one of those is used, it is allowed to combine them into a "Profile generic" object.
In this case, the captured objects are value attributes of the water meter 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. Alternatively, an instance of the IC “Register table” can be used. See also Table
96.
OBIS code
Water meter ID IC
A B C D E F
Water meter ID 1…10 object 1, Data 8/9 b 0 0 0…9 255
Water meter ID-s object 7, Profile generic 8/9 b 0 0 255 255
Water meter ID-s object 61, Register table 8/9 b 0 0 255 255
For billing period / reset counters and for number of available billing periods the data type shall
be unsigned, long-unsigned or double-long-unsigned. For time stamps of billing periods, the
data type shall be double-long-unsigned (in the case of UNIX time), octet-string or date-time
formatted as specified in 4.1.6.1. These objects may be related to channels.
When the values of historical periods are represented by “Profile generic” objects, the time
stamp of the billing period objects shall be part of the captured objects.
For item names and OBIS codes see 8/9 b 0 1 1,2, 255
Table 96. 1, Data 10..
12
• Program entries are represented by instances of the IC "Data" with data type unsigned,
long-unsigned or octet-string. Program entries can also be related to a channel;
• Threshold values are represented by instances of the IC "Register" or “Extended register”.
• Input pulse constants are represented by instances of the IC "Data", “Register” or “Extended
register” with data type unsigned, long-unsigned or octet-string. Input pulse constants
entries can also be related to a channel;
• Timing information for measurement and registration periods is presented by instances of
IC “Data”, “Register” or “Extended register” with the data type of the value attribute
unsigned, long-unsigned or double-long-unsigned;
• Time entry values are represented by instances of IC “Data”, “Register” or “Extended
register” with the data type of the value attribute double-long-unsigned (in the case of UNIX
time), octet-string or date-time formatted as specified in 4.1.6.1.
a
For item names and OBIS codes see Table 96.
Consumption values are held by the value attribute of “Register” or “Extended register“ objects
with data types double-long,double-long-unsigned, octet-string, visible-string, integer, long,
unsigned, long-unsigned, long64, long64-unsigned, float32 or float64.
OBIS code
Consumption IC
A B C a
Db Ec F
0-3 255
3, Register or
Accumulated volume
4, Extended register 1-3 0-99,
101-
125
8/9 b 1 0-12
Minimum, Maximum of
4, Extended register,
integral value over billing 4,5
or 7, Profile generic
periods
3, Register,
Integral test value 4, Extended register, 6 255
or 7, Profile generic
a
See. Table 93– Value group C codes - water meters
b
See. Table 94 – Value group D codes - water meters
c
All other values reserved for further use (tariff rate E=0 means Total)
Monitoring values are held by the value attribute of “Register” or “Extended register“ objects
with data types double-long,double-long-unsigned, octet-string, visible-string, integer,
long,unsigned, long-unsigned, long64, long64-unsigned, float32 and float64.
OBIS code
Monitoring values IC
A B C a
Db Ec F
3, Register,
4, Extended
Flow rate test value 6 255
register, or
7, Profile generic
OBIS code
Monitoring values IC
A B C a
Db Ec F
The different error registers are held by the value attribute of “Data”, “Register” or “Extended
register“ objects, with data type bit-string, octet-string, unsigned, long-unsigned, double-long-
unsigned or long64-unsigned.
OBIS code
List objects – Water meters IC
A B C D E F
List objects – water 7, Profile generic 8/9 b 98 d e 255 a
a
F = 255 means a wildcard here.
OBIS code
Data profile objects – Water meters IC
A B C D E F
Data profile objects 7, Profile generic 8/9 b 99 1 e 255
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 six value groups, all unused value groups shall be filled
with 255.
Octet 1 contains the binary coded value of A (A = 0, 1, 2 ...9) in the four rightmost bits. The four
leftmost bits contain the information on the identification system. The four leftmost bits set to
zero indicate that the OBIS identification system (version 1) is used as logical_name.
Within all value groups, the usage of a certain selection is fully defined; others are reserved for
future use. If in the value groups B to F a value belonging to the manufacturer specific range
(see 7.2.2) is used, then the whole OBIS code shall be considered as manufacturer specific,
and the value of the other groups does not necessarily carry a meaning defined neither by
Clause 4 nor Clause 7 of this Technical Report.
OBIS provides a unique identifier for all 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 document are used
for the identification of:
• logical names of the instances of the ICs, the objects, as defined in Clauses 4 and 6;
• data transmitted through communication lines, see 7.11.1;
• data displayed on the metering equipment, see 7.11.2.
This document applies to all types of metering equipment, such as fully integrated meters,
modular meters, tariff attachments, data concentrators etc.
To cover metering equipment measuring energy types other than electricity, combined metering
equipment measuring more than one type of energy or metering equipment with several physical
measurement channels, the concepts of medium and channels are introduced. This allows
meter data originating from different sources to be identified.
Value
Use of the value group
group
Identifies the media (energy type) to which the metering is related. Non-media related information is
A
handled as abstract data.
Generally, identifies the measurement channel number, i.e. the number of the input of a metering
equipment having several inputs for the measurement of energy of the same or different types (for
B example in data concentrators, registration units). Data from different sources can thus be identified.
It may also identify the communication channel, and in some cases it may identify other elements.
The definitions for this value group are independent from the value group A.
Identifies abstract or physical data items related to the information source concerned, for example
current, voltage, power, volume, temperature. The definitions depend on the value in the value group
A.
C
Further processing, classification and storage methods are defined by value groups D, E and F.
For abstract data, value groups D to F provide further classification of data identified by value groups A
to C.
Identifies types, or the result of the processing of physical quantities identified by values in value
D groups A and C, according to various specific algorithms. The algorithms can deliver energy and
demand quantities as well as other physical quantities.
E Identifies further processing or classification of quantities identified by values in value groups A to D.
Identifies historical values of data, identified by values in value groups A to E, according to different
F
billing periods. Where this is not relevant, this value group can be used for further classification.
• group B: 128…199;
• group C: 128…199, 240;
• group D: 128…254;
• group E: 128…254;
• group F: 128…254.
If any of these value groups contain a value in the manufacturer specific range, then the whole
OBIS code shall be considered as manufacturer specific, and the value of the other groups
does not necessarily carry a meaning defined in Clause 6 or 7.
In addition, manufacturer specific ranges are defined in Table 45 with A = 0, C = 96, in Table
57 with A = 1, C = 96, in Table 65 with A = 4, C = 96, in Table 73 with A = 5/6, C = 96, in Table
89 with A = 7, C = 96 and in Table 96 with A = 8/9, C = 96.
Table 39 – Rules for manufacturer, utility, consortia and country specific codes
—————————
2 Administered by the DLMS User Association (see Foreword).
NOTE 1 “b”, “c”, “d”, “e”, “f” means any value in the relevant value group.
NOTE 2 The range D = 50…99 is available for identifying objects, which are not represented by another
defined code, but need representation on the display as well. If this is not required, the range D
= 128…254 should be used.
NOTE 3 If the value in value group B is 65…127, the whole OBIS code should be considered as utility
specific and the value of other groups does not necessarily carry a meaning defined neither in
Clause 6 nor Clause 7.
NOTE 4 The usage of value group E and F are defined in consortia specific documents.
NOTE 5 The usage of value group E and F are defined in country specific documents.
Objects for which this Technical Report defines standard identifiers shall not be re-identified by
manufacturer, utility, consortia or country specific identifiers.
Notation: In the following tables, in the various value groups, “b”, “c”, ”d”, “e”, “f” signifies any
value in the respective value group. If only one object is instantiated, the value shall be 0. If a
value group is shaded, then this value group is not used.
NOTE The DLMS UA maintains a list of standard COSEM object definitions at www.dlms.com. The validity of
the combination of OBIS codes and class_id-s as well as the data types of the attributes are tested during
conformance testing.
Value group A
0 Abstract objects
1 Electricity related objects
…
4 Heat cost allocator related objects
5, 6 Thermal energy related objects
7 Gas related objects
8 Cold water related objects
9 Hot water related objects
…
15 Other media
All other Reserved
The following subclauses contain value group definitions B to F common for all values of value
group A.
Value group B
0 No channel specified
1…64 Channel 1..64
The range 65…127 is available for utility specific use. If the value of value group B is in this
range, the whole OBIS code shall be considered as utility specific and the value of other groups
does not necessarily carry a meaning defined neither in Clause 4 nor in Clause 7.
Value group C
Abstract objects (A = 0)
0…89 Context specific identifiers a
…
127 Inactive objects b
128…199, 240 Manufacturer specific codes
Objects that are already identified in this document shall not be re-identified by consortia
specific identifiers.
Value group D
Consortia specific identifiers (A = any, C = 93)
All values Reserved
NOTE At the time of the publication of this document, no consortia specific identifiers are
allocated.
Objects that are already identified in this document shall not be re-identified by country specific
identifiers.
Value group D
Country specific identifiers a
(A = any, C = 94)
00 Finland (Country calling code = 358) 50
01 USA (= Country calling code) 51 Peru (= Country calling code)
02 Canada (Country calling code = 1) 52 South Korea (Country calling code = 82)
03 Serbia (Country calling code = 381) 53 Cuba (= Country calling code)
04 54 Argentina (= Country calling code)
05 55 Brazil (= Country calling code)
Value group D
Country specific identifiers a
(A = any, C = 94)
06 56 Chile (= Country calling code)
07 Russia (Country calling code = 7) 57 Colombia (= Country calling code)
08 58 Venezuela (= Country calling code)
09 59
10 Czech Republic (Country calling code = 420) 60 Malaysia (= Country calling code)
11 Bulgaria (Country calling code = 359) 61 Australia (= Country calling code)
12 Croatia (Country calling code = 385) 62 Indonesia (= Country calling code)
13 Ireland (Country calling code = 353) 63 Philippines (= Country calling code)
14 Israel (Country calling code = 972) 64 New Zealand (= Country calling code)
15 Ukraine (Country calling code = 380) 65 Singapore (= Country calling code)
16 Yugoslavia a
66 Thailand (= Country calling code)
17 67
18 68
19 69
20 Egypt (= Country calling code) 70
21 71 Latvia (Country calling code = 371)
22 72
23 73 Moldova (Country calling code = 373)
24 74
25 75 Belarus (Country calling code = 375)
26 76
27 South Africa (= Country calling code) 77
28 78
29 79
30 Greece (= Country calling code) 80
31 Netherlands (= Country calling code) 81 Japan (= Country calling code)
32 Belgium (= Country calling code) 82 Mexico
33 France (= Country calling code) 83
34 Spain (= Country calling code) 84
35 Portugal (Country calling code = 351) 85 Hong Kong (Country calling code = 852)
36 Hungary (= Country calling code) 86 China (= Country calling code)
37 Lithuania (Country calling code = 370) 87 Bosnia and Herzegovina (Country calling code
= 387)
38 Slovenia (Country calling code = 386) 88
39 Italy (= Country calling code) 89
40 Romania (= Country calling code) 90 Turkey (= Country calling code)
41 Switzerland (= Country calling code) 91 India (= Country calling code)
42 Slovakia (Country calling code = 421) 92 Pakistan (= Country calling code)
43 Austria (= Country calling code) 93
44 United Kingdom (= Country calling code) 94
45 Denmark (= Country calling code) 95
46 Sweden (= Country calling code) 96 Saudi Arabia (Country calling code = 966)
47 Norway (= Country calling code) 97 United Arab Emirates (Country calling code =
971)
48 Poland (= Country calling code) 98 Iran (= Country calling code)
49 Germany (= Country calling code) 99
All other codes are reserved
a
With the dissolution of the former Yugoslavia into separate nations, country code 38 was
decommissioned.
• abstract general and service entry objects, see 7.4, Table 45;
• electricity related general and service entry objects, see Table 57;
• HCA related general and service entry objects, see Table 65;
• thermal energy related general and service entry objects, see Table 73;
• gas related general and service entry objects, see Table 89;
• water related general and service entry objects, see Table 96.
• abstract general and service entry objects, see 7.4, Table 45;
• electricity related general and service entry objects, see Table 57;
• HCA related general and service entry objects, see Table 65;
• thermal energy related general and service entry objects, see Table 73;
• gas related general and service entry objects, see Table 89;
• water related general and service entry objects, see Table 96.
b Protected configuration is characterized by the need to open the main meter cover to modify it, or to break a
metrological seal.
c Global status words with E = 0 contain the individual status words E = 1…4. The contents of the status words are
not defined in this document.
d
Time of power failure is recorded when either a short or long power failure occurs.
e
Duration of long power failure holds the duration of the last long power failure.
f The range D = 50…99 is available for identifying objects, which are not represented by another defined code, but
need representation on the display as well. If this is not required, the range D = 128…254 should be used.
Table 46 – OBIS codes for error registers, alarm registers and alarm filters – Abstract
Error register, alarm register and alarm filter objects – OBIS code
Abstract A B C D E F
Error register objects 1…10 0 b 97 97 0…9
Alarm register objects 1…10 0 b 97 98 0…9
Alarm filter objects 1…10 0 b 97 98 10…19
Alarm descriptor objects 1…10 0 b 97 98 20…29
NOTE The information to be included in the error objects is not defined in this document.
OBIS code
List objects – Abstract
A B C D E F
Data of billing period (with billing period scheme 1 if there
0 b 98 1 e 255 a
are more than one schemes available)
Data of billing period (with billing period scheme 2) 0 b 98 2 e 255 a
a
F = 255 means a wildcard here. See 7.11.3.
OBIS code
Register table objects – Abstract
A B C D E F
General use, abstract 0 b 98 10 e
OBIS code
Data profile objects – Abstract
A B C D E F
Load profile with recording period 1 a
0 b 99 1 e
Load profile with recording period 2 a
0 b 99 2 e
Load profile during test a
0 b 99 3 0
Connection profile 0 b 99 12 e
GSM diagnostic profile 0 b 99 13 e
Charge collection history (Payment metering) 0 b 99 14 e
Token credit history (Payment metering) 0 b 99 15 e
Parameter monitor log 0 b 99 16 e
Token transfer log (Payment metering) 0 b 99 17 e
LTE monitoring profile 0 b 99 18 e
Event log a
0 b 99 98 e
a
These objects should be used if they (also) hold data not specific to the energy type.
The quadrant definitions for active and reactive power ar shown in Figure 27.
90 ΣL i current (algebraic sum of the – unsigned – value of the currents in all phases)
91 L 0 current (neutral) a
92 L 0 voltage (neutral) a
NOTE The quadrant definitions are according to IEC 62053-23:2003, Figure C1.
Figure 27 – Quadrant definitions for active and reactive power
Value group D codes – Electricity (A = 1, C <> 0, 93, 94, 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
11 Cumulative minimum 2
12 Cumulative maximum 2
13 Minimum 2
14 Current average 2
15 Last average 2
16 Maximum 2
17 Time integral 7
18 Time integral 8
Value group D codes – Electricity (A = 1, C <> 0, 93, 94, 96, 97, 98, 99)
19 Time integral 9
20 Time integral 10
21 Cumulative minimum 3
22 Cumulative maximum 3
23 Minimum 3
24 Current average 3
25 Last average 3
26 Maximum 3
27 Current average 5
28 Current average 6
29 Time integral 5
30 Time integral 6
39 Missing threshold
40 Missing occurrence counter
41 Missing duration
42 Missing magnitude
46 Contracted value
55 Test average
56 Current average 4 for harmonics measurement
Value group D codes – Electricity (A = 1, C <> 0, 93, 94, 96, 97, 98, 99)
58 Time integral 4
7.5.3.3 Harmonics
Table 53 shows the use of value group E for the identification of harmonics of instantaneous
values of voltage, current or active power.
Value group E codes – Electricity – Measurement of harmonics of voltage, current or active power
(A = 1, C = 12, 32, 52, 72, 92, 11, 31, 51, 71, 90, 91, 15, 35, 55, 75, D = 7, 24, 56)
0 Total (fundamental + all harmonics)
1 1 st harmonic (fundamental)
2 2 nd harmonic
… n th harmonic
120 120 t h harmonic
Value group E codes – Electricity – Measurement of harmonics of voltage, current or active power
(A = 1, C = 12, 32, 52, 72, 92, 11, 31, 51, 71, 90, 91, 15, 35, 55, 75, D = 7, 24, 56)
126 All harmonics c
The model of the line and the transformer used for loss calculation is shown on Figure 28.
Legend:
- R Cu Line resistance losses, OBIS code 1.x.0.10.2.VZ
- X s Line reactance losses, OBIS code 1.x.0.10.3.VZ
- X m Transformer magnetic losses, OBIS code 1.x.0.10.0.VZ
- R Fe Transformer iron losses, OBIS code 1.x.0.10.1.VZ
- N p Number of turns on the primary side of the transformer
- N s Number of turns on the secondary side of the transformer
NOTE Serial elements of the transformer are normally low compared to that of the line, therefore they are not
considered here.
Figure 28 – Model of the line and the transformer for calculation of loss quantities
QI+QIV
R Cu is the serial resistive element of
51 L 2 Active line losses+ CuA 2 + = I h L2 x R Cu
2
the line loss, OBIS code
1.x.0.10.2.VZ
52 L 2 Active line losses– CuA 2 – = I 2 h L2 x R Cu QII+QIII
53…70 L 2 quantities, (See 33…48)
QI+QIV
R Cu is the serial resistive element of
71 L 3 Active line losses + CuA 3 + = I 2 h L3 x R Cu
the line loss, OBIS code
1.x.0.10.2.VZ
72 L 3 Active line losses - CuA 3 – = I 2 h L3 x R Cu QII+QIII
73…90 L 3 quantities (See 33…48)
91...
Reserved
255
NOTE In this table, no manufacturer specific range is available.
Value group E codes – Electricity – UNIPEDE voltage dips measurement (A = 1, C = 12, 32, 52, 72, D = 32)
Residual Duration ∆t s
Depth
voltage U 0,01 < ∆t < 0,1 < ∆t <
in % of U n 0,5 < ∆t < 1 1 < ∆t < 3 3 < ∆t < 20 20 < ∆t < 60
in % of U n 0,1 0,5
10%…<15% 90 > U > 00 01 02 03 04 05
85
15%…<30% 85 > U > 10 11 12 13 14 15
70
30%…<60% 70 > U > 20 21 22 23 24 25
40
60%…<90% 40 > U > 30 31 32 33 34 35
10
90%…<100% 10 > U > 0 40 41 42 43 44 45
NOTE These dip classes form a subset of the classes defined in IEC TR 61000-2-8, Table 2.
• value group A: 1;
• value group C: as defined in Table 50;
• value group D:
• 0: Billing period average (since last reset);
• 1, 2, 3, 6: (Cumulative) minimum / maximum 1;
• 8, 9, 10: Time integral 1 / 2 / 3;
• 11, 12, 13, 16: (Cumulative) minimum / maximum 2;
• 21, 22, 23, 26: (Cumulative) minimum / maximum 3;
There are two billing period schemes available (for example to store weekly and monthly
values). For each billing period scheme, the following general purpose objects are available:
• value group A = 1;
• value group C = 1…20, 21…40, 41…60, 61…80, 82, 84…89, 90… 92;
• value group D = 31, 35, 39 (under limit, over limit and missing thresholds);
• value group F = 0…99.
NOTE All quantities monitored are instantaneous values: D = 7 or D = 24.
When multiple thresholds are identified by value group F, then the Under limit / Over limit /
Missing Occurrence counter / Duration / Magnitude quantities relative to a threshold are
identified with the same value in value group F. In this case, value group F cannot be used to
identify values relative to billing period. However, such values can be held by “Profile generic”
objects.
Example:
- Over limit threshold #1 for current in any phase is identified with OBIS code 1-0:11.35.0*0;
- Over limit duration above threshold # 1 for current in any phase is identified with OBIS code 1-0:11.37.0*0.
To avoid ambiguity, value group F cannot be used to identify historical values of Under limit /
Over limit / Missing Occurrence counter / Duration / Magnitude quantities. For historical values
of these quantities “Profile generic” objects can be used and values related to previous billing
periods can be accessed using selective access.
Table 57 – OBIS codes for general and service entry objects – Electricity
OBIS code
General and service entry objects – Electricity
A B C D E F
Free ID-numbers for utilities
Complete combined electricity ID 1 b 0 0
Electricity ID 1 1 b 0 0 0
... … … … … …
Electricity ID 10 1 b 0 0 9
Billing period values/reset counter entries
(First billing period scheme if there are more than one)
Billing period counter (1) 1 b 0 1 0 VZ or
255
Number of available billing periods (1) 1 b 0 1 1
Time stamp of the most recent billing period (1) 1 b 0 1 2
Time stamp of the billing period (1) VZ (last reset) 1 b 0 1 2 VZ
Time stamp of the billing period (1) VZ -1 1 b 0 1 2 VZ -1
… … … … … … ...
Time stamp of the billing period (1) VZ -n 1 b 0 1 2 VZ -n
Billing period values/reset counter entries
(Second billing period scheme)
OBIS code
General and service entry objects – Electricity
A B C D E F
Billing period counter (2) 1 b 0 1 3 VZ or
255
Number of available billing periods (2) 1 b 0 1 4
Time stamp of the most recent billing period (2) 1 b 0 1 5
Time stamp of the billing period (2) VZ (last reset) 1 b 0 1 5 VZ
Time stamp of the billing period (2) VZ -1 1 b 0 1 5 VZ -1
... … … … … … ...
Time stamp of the billing period (2) VZ -n 1 b 0 1 5 VZ -n
Program entries
Active firmware identifier
1 b 0 2 0
(Previously: Configuration program version number)
Parameter record number 1 b 0 2 1
Parameter record number, line 1 1 b 0 2 1 1
Reserved for future use 1 b 0 2 1 2…
127
Manufacturer specific 1 b 0 2 1 128…
254
Time switch program number 1 b 0 2 2
RCR program number 1 b 0 2 3
Meter connection diagram ID 1 b 0 2 4
Passive calendar name 1 b 0 2 7
Active firmware signature 1 b 0 2 8
Output pulse values or constants
NOTE For units, see 4.3.2.
Active energy, metrological LED 1 b 0 3 0
Reactive energy, metrological LED 1 b 0 3 1
Apparent energy, metrological LED 1 b 0 3 2
Active energy, output pulse 1 b 0 3 3
Reactive energy, output pulse 1 b 0 3 4
Apparent energy, output pulse 1 b 0 3 5
Volt-squared hours, metrological LED 1 b 0 3 6
Ampere-squared hours, metrological LED 1 b 0 3 7
Volt-squared hours, output pulse 1 b 0 3 8
Ampere-squared hours, output pulse 1 b 0 3 9
Ratios
Reading factor for power 1 b 0 4 0
Reading factor for energy 1 b 0 4 1
Transformer ratio – current (numerator) a
1 b 0 4 2 VZ
Transformer ratio – voltage (numerator) a
1 b 0 4 3 VZ
Overall transformer ratio (numerator) a
1 b 0 4 4 VZ
Transformer ratio – current (denominator) a 1 b 0 4 5 VZ
Transformer ratio – voltage (denominator) a
1 b 0 4 6 VZ
Overall transformer ratio (denominator) a
1 b 0 4 7 VZ
Demand limits for excess consumption metering
Reserved for Germany 1 b 0 5
Nominal values
Voltage 1 b 0 6 0
Basic/nominal current 1 b 0 6 1
Frequency 1 b 0 6 2
Maximum current 1 b 0 6 3
OBIS code
General and service entry objects – Electricity
A B C D E F
Reference voltage for power quality measurement 1 b 0 6 4 VZ
Reference voltage for aux. power supply 1 b 0 6 5
Input pulse values or constants b
Time entries
Time expired since last end of billing period
1 b 0 9 0
(First billing period scheme if there are more than one)
Local time 1 b 0 9 1
Local date 1 b 0 9 2
Reserved for Germany 1 b 0 9 3
Reserved for Germany 1 b 0 9 4
Week day (0…7) 1 b 0 9 5
Time of last reset 1 b 0 9 6
(First billing period scheme if there are more than one)
Date of last reset 1 b 0 9 7
(First billing period scheme if there are more than one)
Output pulse duration 1 b 0 9 8
Clock synchronization window 1 b 0 9 9
Clock synchronization method 1 b 0 9 10
Clock time shift limit (default value: s) 1 b 0 9 11
Billing period reset lockout time 1 b 0 9 12
(First billing period scheme if there are more than one)
Second billing period scheme
Time expired since last end of billing period 1 b 0 9 13
Time of last reset 1 b 0 9 14
Date of last reset 1 b 0 9 15
Billing period reset lockout time 1 b 0 9 16
Coefficients
OBIS code
General and service entry objects – Electricity
A B C D E F
Transformer magnetic losses, X m 1 b 0 10 0 VZ
Transformer iron losses, R Fe 1 b 0 10 1 VZ
Line resistance losses, R Cu 1 b 0 10 2 VZ
Line reactance losses, X s 1 b 0 10 3 VZ
Measurement methods
Algorithm for active power measurement 1 b 0 11 1
Algorithm for active energy measurement 1 b 0 11 2
Algorithm for reactive power measurement 1 b 0 11 3
Algorithm for reactive energy measurement 1 b 0 11 4
Algorithm for apparent power measurement 1 b 0 11 5
Algorithm for apparent energy measurement 1 b 0 11 6
Algorithm for power factor calculation 1 b 0 11 7
Metering point ID (electricity related)
Metering point ID 1 (electricity related) 1 0 96 1 0
………
Metering point ID 10 (electricity related) 1 0 96 1 9
Internal operating status, electricity related
Internal operating status, global c
1 b 96 5 0
Internal operating status (status word 1) 1 b 96 5 1
Internal operating status (status word 2) 1 b 96 5 2
Internal operating status (status word 3) 1 b 96 5 3
Internal operating status (status word 4) 1 b 96 5 4
Meter started status flag 1 b 96 5 5
Electricity related status data
Status information missing voltage 1 0 96 10 0
Status information missing current 1 0 96 10 1
Status information current without voltage 1 0 96 10 2
Status information auxiliary power supply 1 0 96 10 3
Manufacturer specific d 1 b 96 50 e f
..................... … … … … … …
Manufacturer specific 1 b 96 99 e f
a 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.
b The codes for export active, reactive and apparent energy shall be used only if meters measuring import energy
and meters measuring export energy are connected to the pulse inputs.
c Global status words with E = 0 contain the individual status words E = 1…5. The contents of the status words are
not defined In this Technical Report.
d The range D = 50…99 is available for identifying objects, which are not represented by another defined code, but
need representation on the display as well. If this is not required, the range D = 128…254 should be used.
It should be noted, that some of the codes above are normally used for display purposes only,
as the related data items are attributes of objects having their own OBIS name. See Clause
4.
OBIS code
Error register objects – Electricity
A B C D E F
Error register 1 b 97 97 e
NOTE The information to be included in the error objects is not defined in this document.
OBIS code
List objects – Electricity
A B C D E F
Electricity related data of billing period (with billing period scheme 1 if
1 b 98 1 e 255 a
there are two schemes available)
Electricity related data of billing period (with billing period scheme 2) 1 b 98 2 e 255 a
a
F = 255 means a wildcard here. See 7.11.3.
OBIS code
Data profile objects – Electricity
A B C D E F
Load profile with recording period 1 1 b 99 1 e
Load profile with recording period 2 1 b 99 2 e
Load profile during test 1 b 99 3 0
Dips voltage profile 1 b 99 10 1
Swells voltage profile 1 b 99 10 2
Cuts voltage profile 1 b 99 10 3
Voltage harmonic profile 1 b 99 11 n th
Current harmonic profile 1 b 99 12 n th
Voltage unbalance profile 1 b 99 13 0
Power quality 1 b 99 14 0
Power failure event log 1 b 99 97 e
Event log 1 b 99 98 e
Certification data log 1 b 99 99 e
OBIS code
Register table objects – Electricity
A B C D E F
UNIPEDE voltage dips, any phase 1 b 12 32
UNIPEDE voltage dips, L 1 1 b 32 32
UNIPEDE voltage dips, L 2 1 b 52 32
UNIPEDE voltage dips, L 3 1 b 72 32
Extended angle measurement 1 b 81 7
General use, electricity related 1 b 98 10 e
This subclause 7.6 describes the naming of objects carrying HCA information in a COSEM
environment. The words used in this clause are those used in EN 834:1994, the corresponding
media standard.
The output from an HCA is "the temperature integral with respect to time", and it is only a
relative sum. The main parameter from a HCA is this integral. Time series of this integral may
be stored in the HCA for later readout. Other media related information available from a HCA
are temperature and rating factors.
1 Unrated integral b
2 Rated integral c
Table 65 – OBIS codes for general and service entry objects – HCA
OBIS code
General and service entry objects – HCA
A B C D E F
Free ID-numbers for utilities
Complete combined ID 4 b 0 0
ID 1 4 b 0 0 0
... ... ... ...
ID 10 4 b 0 0 9
Storage information
Status (VZ) of the historical value counter 4 b 0 1 1
Number of available historical values 4 b 0 1 2
Set date (target date) 4 b 0 1 10
Billing date 4 b 0 1 11
Configuration
Program version no. 4 b 0 2 0
Firmware version no. 4 b 0 2 1
Software version no. 4 b 0 2 2
Device measuring principle
Device measuring principle a
4 b 0 2 3
Conversion factors
Resulting rating factor, K 4 b 0 4 0
Thermal output rating factor, K Q 4 b 0 4 1
Thermal coupling rating factor overall, K C 4 b 0 4 2
Thermal coupling rating factor room side, K CR 4 b 0 4 3
Thermal coupling rating factor heater side, K CH 4 b 0 4 4
Low temperature rating factor, K T 4 b 0 4 5
Display output scaling factor 4 b 0 4 6
Threshold values
Start temperature threshold 4 b 0 5 10
Difference temperature threshold 4 b 0 5 11
Period information
Measuring period for average value 4 b 0 8 0
Recording interval for consumption profile 4 b 0 8 4
OBIS code
General and service entry objects – HCA
A B C D E F
Billing period 4 b 0 8 6
Time entries
Local time 4 b 0 9 1
Local date 4 b 0 9 2
Time stamp (local time) of the most recent billing period b
4 b 0 9 3
Manufacturer specific c
4 b 96 50 e f
.....................
Manufacturer specific 4 b 96 99 e f
a
This is an object of the type 'Data' enumerated, (0) single sensor, (1) single sensor + start sensor, (2) dual sensor,
(3) triple sensor.
b
In case of billing period schemes absence or event triggered, commonly calculated from local date and local time
information.
c
The range D = 50…99 is available for identifying objects, which are not represented by another defined code, but
need representation on the display as well. If this is not required, the range D = 128…254 should be used.
OBIS code
Error register objects – HCA
A B C D E F
Error registers 4 b 97 97 e
OBIS code
List objects – HCA
A B C D E F
HCA related data of billing period (with billing period scheme 1 if
4 b 98 1 e 255 a
there are two schemes available)
HCA related data of billing period (with billing period scheme 2) 4 b 98 2 e 255 a
a
F = 255 means a wildcard here. See 7.11.3.
OBIS code
Data profile objects – HCA
A B C D E F
Data profile objects 4 b 99 1 e
OBIS code
HCA related objects
A B C D E F
Consumption
Current unrated integral 4 b 1 0 0
Current rated integral 4 b 2 0 0
Rated integral, last set date 4 b 2 2 0 VZ
Monitoring values
Radiator temperature, current value 4 b 3 0
Radiator temperature, minimum value 4 b 3 4
Radiator temperature, maximum value 4 b 3 5
Flow temperature, test value 4 b 5 6
Room temperature, current value 4 b 7 0
Room temperature, minimum value 4 b 7 4
Room temperature, maximum value 4 b 7 5
Thermal energy meters can be used for measurement in heating (A=6) or cooling (A=5)
systems.
Value group A = 5 has been set aside for metering of cooling specific objects and value group
A = 6 for the metering of heat specific objects. The other value groups are identical for heating
and cooling.
8 Power
9 Flow rate
10 Inlet (Flow) temperature a
12 Temperature difference c
13 Pressure d
7 Instantaneous value c
8 Time integral 1 d
9 Time integral 2 e
10 Current average f
11 Last average g
12 Periodical value 2 a
13 Periodical value 3 a
14 Minimum of value 2
15 Maximum of value 2
Table 73 – OBIS codes for general and service entry objects – Thermal energy
OBIS code
General and service entry objects – Thermal energy
A B C D E F
OBIS code
General and service entry objects – Thermal energy
A B C D E F
Storage information
Status (VZ) of the historical /periodical value counter 5/6 b 0 1 1 f
OBIS code
General and service entry objects – Thermal energy
A B C D E F
a Information about where the (single) flow meter is inserted. A non-zero value is used when the flow meter is
located in the flow path.
b
Defines the pressure of the media, if not measured. The default value is 16 bar according to EN 1434-2:2015.
c The enthalpy of the thermal conveying liquid. This will be necessary when using media other than pure water.
The enthalpy is a part of the calculations when converting from mass to power.
d Part of the contract between the customer and the supplier. The threshold defines when to switch rate, and can
be used for diagnostic purposes, or to control limiting valves as well.
e Part of the contract between the customer and the supplier. The threshold may be used to set a 'flag', for
diagnostic purposes, or to control limiting valves.
f
Value group 'F' may be left unused, if there is only one set of historical / periodical values in the meter.
g
The instantiation of periods in a meter shall always start at period 1.
h If only one recording interval is implemented, then it shall be recording interval 1. If multiple recording intervals
are implemented, the recording interval 1 shall be the interval with the shorter period.
i In case of billing period schemes absence or event triggered, commonly calculated from local date and local
time information
j The range D = 50…99 is available for identifying objects, which are not represented by another defined code,
but need representation on the display as well. If this is not required, the range D = 128…254 should be used.
OBIS code
Error register objects – Thermal energy
A B C D E F
Error registers 5/6 b 97 97 e
NOTE The information to be included in the error objects is not defined in this document.
OBIS code
List objects – Thermal Energy Meters
A B C D E F
Thermal energy related data of billing period (with billing period
5/6 b 98 1 e 255 a
scheme 1 if there are two schemes available)
Thermal energy related data of billing period (with billing period 5/6 b 98 2 e 255 a
scheme 2)
a
F = 255 means a wildcard here. See 7.11.3.
OBIS code
Data profile objects – Thermal energy
A B C D E F
Consumption / load profile with recording interval 1 5/6 b 99 1 1
Consumption / load profile with recording interval 2 5/6 b 99 1 2
Consumption / load profile with recording interval 3 5/6 b 99 1 3
Profile of maxima with recording interval 1 5/6 b 99 2 1
Profile of maxima with recording interval 2 5/6 b 99 2 2
Profile of maxima with recording interval 3 5/6 b 99 2 3
Consumption / load profile during test 5/6 b 99 3 1
OBIS code
Thermal energy related objects (examples)
A B C D E F
Consumption
OBIS code
Thermal energy related objects (examples)
A B C D E F
Monitoring values
Energy, maximum value (current period) 5/6 b 1 5
Flow rate, Period value 2, previous storage 5/6 b 9 12 V Z-1
a
This object is a 'mirror' of the object 0.x.97.97.0.
b
This is the time during which the meter has not been able to calculate energy.
c
A further subdivision of error information.
• The first step is to measure either the amount of the volume or the mass of gas based on
various measuring principles, like volume, flow, density or mass measurement. Accuracy
can be improved by correcting the measurement error of the meter;
• In the case of volume measurement, the next step is to convert the volume measured at
metering conditions to volume at base conditions;
• In the final step, the energy is calculated from the volume at base conditions or the mass,
and the calorific value. The calorific value – either per volume unit or per mass unit – is
determined using gas analysis techniques.
The measurement technology and the implementation of the volume conversion and energy
calculation process depend on the application segment.
Conversion and calculation steps can take place at the measuring site by electronic devices, or
in the IT system.
For measurement of larger volumes, there are several devices involved in the process,
depending on installation and hazardous area requirements. Not only the final results, but also
interim values in the conversion and calculation process are of interest for checking and
controlling purposes.
Pulse
interface or
Gas meter Communication device
digital data
transmission
The meter is typically a diaphragm (positive displacement) meter, which may perform
mechanical temperature correction.
The information from the gas meter to the communication device may be transferred in the form
of pulses. Alternatively, the meter may be equipped with a digital interface, e.g. an encoder
turning the index reading to digital information.
Gas meter
Pulse interface or
transmission
digital data
In industrial applications, typically more functions are implemented at the measuring site than
in residential applications. This may include the calculation of the volume at base conditions,
and, if the calorific value is available (e.g. via remote communication), the calculation of the
energy.
The data logger stores data relevant for billing, data validation and process control.
The functions may be integrated in fewer devices, depending on the hazardous zone restrictions
and the level of integration of electronics.
Such gas stations are equipped with more than one pipe for the gas flow (multi
stream).Typically, volume conversion devices are installed on each pipe, because the
measurement is closely pipe related. Generally, there is one data logger and a device used to
determine the calorific value (e.g. gas chromatograph).
Depending on the design of these devices, selected functions may be implemented in a single
cabinet or physical device.
Calorific value
Volume conversion device 1 Volume conversion device 2
determination device
Temporary device
It may be equipped with disturbance registers used when the value of temperature, pressure or
compressibility is outside permissible metrological limits of plausibility, leading to an alert
condition. When such alert condition occurs, the gas conversion process switches to store
results in disturbance registers, until the alert conditions disappears.
Vc = Cf * Vm
where:
Vb = C x V
Where:
where Z is the compressibility factor allowing to take into account the difference in
compressibility between the gas measured and the ideal gas. It is a function of the pressure
and the temperature:
Z = f (P, T)
Settable gas properties and components are used for the compressibility calculation, combined
into one of several existing calculation methods. If the compressibility factor is not calculated,
it may be included as a fixed value in the calculation of the conversion factor. Below 1,5 bar,
the value of Z is usually set to 1.
If the pressure is not measured, it may be included as a fixed value in the calculation of the
conversion factor.
E = CalValue x V b
where CalValue is the calorific value, expressed in J/m 3 . Typically, it is measured by calorimeter
or gas chromatograph devices.
Volume at measuring
conditions
Manufacturer specific
Corrected volume
∆V = ∆Vc
Z = f (P, T) A/D A/D or
∆V = ∆Vm
Manufacturer specific
Energy
CalValue =
∆E = CalValue x ∆Vb E = ∆E + Eold
f(measurement)
The OBIS codes of the main objects in the data flow are shown in Table 78, with the following
assumptions:
• the conversion process passes through all four functions from metering to energy;
• the device has one single channel;
• the direction of the gas flow is forward;
• energy is the result of the conversion process from volume at base conditions to energy, by
applying the calorific value as factor;
• the data of interest are current values of absolute indexes and the gas process data.
Table 78 – OBIS codes of the main objects in the gas conversion process data flow
a A fixed value used to correct a scalar error on a meter: for example, if a meter under-registers volume by
0,5 %, then a correction factor value of 1,005 will compensate for the error.
b
See 7.8.1.3.3.
Compressibility, Z: effectively, the “difference” in compressibility between the gas being measured and
c
“noble” gas. For example, EN 12405, SGERG-88, AGA 8 give full information on this, though below 1,5
Bar (a) this is usually set to 1.
d The superior (or gross) calorific value can be seen as a conversion factor for converting volume to
energy although it is also used for the conversion algorithm.
Temperature of the gas, expressed in Kelvin. Volume conversion depends on Kelvin temperature
e
measurement. This may represent a measured value or a base condition, or a backup value, used if the
temperature sensor fails, as identified by the value of value group D.
Pressure of the gas, expressed in a suitable unit, in absolute terms, for example Bar (a). This means that
f the value is referenced to a perfect vacuum, as opposed to “Gauge” pressure, which is referenced to
current atmospheric conditions. This may represent a measured value or a base condition, or a backup
value, used if the pressure sensor fails, as identified by the value of value group D.
For gas metering, both general purpose and dedicated profiles are available:
• a general purpose “Profile generic” object captures one or several values. Such objects
have a general OBIS code / logical name that do not provide specific information on the
values captured. These profiles are also available with some fixed recording intervals;
• a dedicated “Profile generic” object captures only one value. The OBIS code / logical name
of such a dedicated ”Profile generic” object is “self-explanatory”, i.e. it reflects the OBIS
code of the object the value attribute of which is captured.
NOTE A time stamp and a status attribute may be captured in addition to the value(s) of interest.
In any case, the values captured are identified by the capture_objects attribute. See 7.8.6.4.
For the purposes of volume / mass / energy measurement, value group C identifies:
• the location of the device in the measurement chain: meter (encoder), converter, logger;
• the direction of the gas flow: forward or reverse;
• the qualifier of the measurement: undisturbed, disturbed, or absolute, where absolute value
is the sum of the values calculated under undisturbed and disturbed conditions.
• Value group C is also used for identifying process data.
For the purposes of gas analysis, a distinction is made between measured values generated by
gas analysing systems (C = 70) and parameters used for calculation (C = 0, D = 12).
41 Absolute temperature
42 Absolute pressure
43 Flow rate
44 Velocity of sound
45 Density (of gas)
46 Relative density
47 Gauge pressure
48 Differential pressure
49 Density of air
51 Correction factor
52 Conversion factor
53 Compressibility factor
54 Superior calorific value a
• indexes: current values and historical values relative to various billing periods;
• index differences: current and last values relative to measurement periods and billing
periods;
NOTE Index difference over a certain measurement or billing period is also known as consumption. For consumption,
thresholds may be defined, see Table 89.
• maximum of index differences over various measurement periods, relative to various billing
periods;
A distinction is made between value at metering conditions, corrected value and value at base
conditions (converted value). The applicability of these qualifiers depends on the location in the
measuring chain and in the gas volume conversion process.
In addition to the current values of the indexes, the following values are available:
• index differences for the current and the last measurement period (6 values each).
For billing periods 1, 3 and 4:
Table 80 specifies the use of value group D to identify gas related indexes and index
differences.
Value group D codes – Gas – Indexes and index differences (A= 7, C = 1…8, 11…16, 21…26, 31…36, 61…66)
Value group D codes – Gas – Indexes and index differences (A= 7, C = 1…8, 11…16, 21…26, 31…36, 61…66)
Value group D codes – Gas – Indexes and index differences (A= 7, C = 1…8, 11…16, 21…26, 31…36, 61…66)
Value group D codes – Gas – Indexes and index differences (A= 7, C = 1…8, 11…16, 21…26, 31…36, 61…66)
• current average, last average, and maximum of last average values measured over various
averaging periods, relative to various measurement and billing periods. Measurement period
2 and 3 shall be multiple of the averaging period of block demand / sliding demand
measurement.
• values at metering conditions, corrected value, value at base conditions (converted value)
and value at standard conditions;
NOTE Standard conditions refer to national regulations, which may differ from ISO standards
reference values for base conditions.
EXAMPLE Gas reference temperature at standard conditions is 0 °C, gas reference temperature at base
conditions is +15 °C.
For averaging period 2, block demand (default) or sliding demand is available. In the case of
sliding demand, the averaging period is split to sub-periods. The number of sub-periods is
carried by the object 7.b.0.8.35.255; see Table 89.
The last average values of the various flow rate quantities can be captured to load profiles, with
self-explanatory OBIS codes, see 7.8.6.4.
Table 81 specifies the use of value group D to identify gas related flow rate values.
16 Corrected value
Current average for averaging period 1
17 Value at base conditions
20 Corrected value
Last average for averaging period 1
21 Value at base conditions
32 Corrected value
Maximum of last averages for averaging period 1
33 relative to billing period 1 (default value = 1 day) Value at base conditions
35 Corrected value
Current average for averaging period 2
37 Value at base conditions
40 Corrected value
Last average for averaging period 2
41 Value at base conditions
48 Corrected value
Maximum of last averages for averaging period 2
49 relative to measurement period 3 (no default value) Value at base conditions
52 Corrected value
Maximum of last averages for averaging period 2
53 relative to billing period 1 (default value = 1 day) Value at base conditions
56 Corrected value
Current average for averaging period 3
57 Value at base conditions
60 Corrected value
Last average for averaging period 3
61 Value at base conditions
64 Corrected value
Current average for averaging period 4
65 Value at base conditions
68 Corrected value
Last average for averaging period 4
69 Value at base conditions
• instantaneous values;
• average, minimum and maximum values over various process intervals;
• value at metering conditions, value at base conditions; and value at standard conditions;
NOTE Standard conditions refer to national regulations, which may differ from ISO standards
reference values for base conditions.
EXAMPLE Gas reference temperature at standard conditions is 0 °C, gas reference temperature at base
conditions is +15 °C.
• for some quantities, backup, actual and preset values are available.
Table 82 specifies the use of value group D to identify gas related process values.
88 Average, process interval 5, interval since last event Value at base conditions
91 Average, process interval 6, interval between last two events Value at base conditions
For these values, average values over various averaging periods are also defined; see 7.8.4.5.
Table 83 specifies the use of value group D to identify gas conversion related factors and
coefficients values.
Table 83 – Value group D codes – Gas – Conversion related factors and coefficients
10 Actual
11 Preset
12 Method
All other Reserved
10 Superior a
Wobbe index 0 °C
11 Inferior b
Wobbe index 0 °C
12 Methane number
13 Total sulphur
14 Hydrogen sulphide H 2 S
15 Mercaptans
19 Inferior c
calorific value H i,n
20 Water H 2 O
60 Nitrogen N 2
61 Hydrogen H 2
62 Oxygen O 2
63 Helium He
64 Argon Ar
65 Carbon monoxide CO
66 Carbon dioxide CO 2
67 Methane CH 4
68 Ethene C 2 H 4
69 Ethane C 2 H 6
70 Propene C 3 H 6
71 Propane C 3 H 8
72 i-butane i-C 4 H 10
73 n-butane n-C 4 H 10
74 neo-pentane neo-C 5 H 12
75 i-pentane i-C 5 H 12
76 n-pentane n-C 5 H 12
77 Hexane C 6 H 14
79 Hexane+ C 6 H 14 +
81 Octane C 8 H 18
82 Nonane C 9 H 20
83 Decane C 10 H 22
84 Tetrahydrothiophene C 4 H 8 S
Table 85 – Value group E codes – Gas – Indexes and index differences – Tariff rates
Value group E codes – Gas – Indexes and index differences – Tariff rates
(A = 7, C = 1...8, 11...16, 21...26, 31...36, 61...66, D = 0…3, 6…98)
0 Total
1 Rate 1
63 Rate 63
Table 86 – Value group E codes – Gas – Conversion related factors and coefficients
Table 88 – Value group E codes – Gas – Natural gas analysis values – Averages
a Process independent current value is a gas analysis technology independent value, which is
generated asynchronous to processing cycles, but used for further calculations.
b Weighted value is the result of specific algorithms taking into account different values by weighting
their influence on the algorithm result.
There are four billing period schemes available (for example to store daily, monthly, yearly and
weekly values). For each billing period scheme, the following general purpose objects are
available:
Table 89 – OBIS codes for general and service entry objects – Gas
OBIS code
General and shows service entry objects – Gas
A B C D E F
Free ID-numbers for utilities
Complete combined gas ID 7 b 0 0
Gas ID 1 7 b 0 0 0
... … … ... ... ...
Gas ID 10 7 b 0 0 9
Billing period values / reset counter entries
(First billing period scheme if there are more than one)
VZ or
Billing period counter (1) 7 b 0 1 0
255
Number of available billing periods (1) 7 b 0 1 1
Time stamp of the most recent billing period (1) 7 b 0 1 2
Time stamp of the billing period (1) VZ (last reset) 7 b 0 1 2 VZ
Time stamp of the billing period (1) VZ-1 7 b 0 1 2 VZ -1
... ... ... ...
Time stamp of the billing period (1) VZ-n 7 b 0 1 2 VZ –n
Billing period values / reset counter entries
(Second billing period scheme)
VZ or
Billing period counter (2) 7 b 0 1 3
255
Number of available billing periods (2) 7 b 0 1 4
Time stamp of the most recent billing period (2) 7 b 0 1 5
Time stamp of the billing period (2) VZ (last reset) 7 b 0 1 5 VZ
Time stamp of the billing period (2) VZ-1 7 b 0 1 5 VZ -1
OBIS code
General and shows service entry objects – Gas
A B C D E F
... ... ... ...
Time stamp of the billing period (2) VZ-n 7 b 0 1 5 VZ -n
Billing period values / reset counter entries
(Third billing period scheme)
VZ or
Billing period counter (3) 7 b 0 1 6
255
Number of available billing periods (3) 7 b 0 1 7
Time stamp of the most recent billing period (3) 7 b 0 1 8
Time stamp of the billing period (3) VZ (last reset) 7 b 0 1 8 VZ
Time stamp of the billing period (3) VZ-1 7 b 0 1 8 VZ -1
... ... ... ...
Time stamp of the billing period (3) VZ-n 7 b 0 1 8 VZ -n
Billing period values / reset counter entries
(Fourth billing period scheme)
VZ or
Billing period counter (4) 7 b 0 1 9
255
Number of available billing periods (4) 7 b 0 1 10
Time stamp of the most recent billing period (4) 7 b 0 1 11
Time stamp of the billing period (4) VZ (last reset) 7 b 0 1 11 VZ
Time stamp of the billing period (4) VZ-1 7 b 0 1 11 VZ -1
... ... ... ...
Time stamp of the billing period (4) VZ-n 7 b 0 1 11 VZ -n
Configuration
Program version 7 b 0 2 0
Firmware version 7 b 0 2 1
Software version 7 b 0 2 2
Device version 7 b 0 2 3
Active firmware signature 7 b 0 2 8
Number of device channels 7 b 0 2 10
Pressure sensor, serial no. 7 b 0 2 11
Temperature sensor, serial no. 7 b 0 2 12
Calculator, serial no. 7 b 0 2 13
Volume sensor , serial no.
a
7 b 0 2 14
Density sensor, serial no. 7 b 0 2 15
Sensor (medium irrespective), serial no. 7 b 0 2 16
Digital output configuration 7 b 0 2 17
Analogue output configuration 7 b 0 2 18
Output pulse constants converted / unconverted
Volume forward at metering conditions 7 b 0 3 0
Volume reverse at metering conditions 7 b 0 3 1
Volume absolute b at metering conditions 7 b 0 3 2
Volume forward at base conditions 7 b 0 3 3
Volume reverse at base conditions 7 b 0 3 4
OBIS code
General and shows service entry objects – Gas
A B C D E F
Volume absolute at base conditions
b
7 b 0 3 5
Conversion factors
7 b 0 4 0
OBIS code
General and shows service entry objects – Gas
A B C D E F
Volume absolute at metering conditions
b
7 b 0 7 2
Volume forward at base conditions 7 b 0 7 3
Volume reverse at base conditions 7 b 0 7 4
Volume absolute at base conditions
b
7 b 0 7 5
Intervals and periods
Recording interval 1, for profile d
7 b 0 8 1
Recording interval 2, for profile d
7 b 0 8 2
Measurement period 1, for average value 1 7 b 0 8 3
Measurement period 2, for average value 2 7 b 0 8 4
Measurement period 3, for instantaneous value 7 b 0 8 5
Measurement period 4, for test value 7 b 0 8 6
Billing period 7 b 0 8 10
OBIS code
General and shows service entry objects – Gas
A B C D E F
Number of days (time expired) since last reset (First
7 b 0 9 0
billing period scheme if there are more than one)
Local time 7 b 0 9 1
Local date 7 b 0 9 2
Start of conventional gas day 7 b 0 9 3
Residual time shift e
7 b 0 9 4
Time of last reset (First billing period scheme if there are 7 b 0 9 6
more than one)
Date of last reset (First billing period scheme if there are 7 b 0 9 7
more than one)
Clock time shift limit 7 b 0 9 11
First billing period scheme
Number of days (time expired) since last reset (end of See above.
billing period)
Time of last reset See above.
Date of last reset See above.
Billing period reset lockout time (First billing period 7 b 0 9 12
scheme if there are more than one)
Second billing period scheme
Number of days (time expired) since last end of billing 7 b 0 9 13
period
Time of last reset 7 b 0 9 14
Date of last reset 7 b 0 9 15
Billing period reset lockout time 7 b 0 9 16
Third billing period scheme
Number of days (Time expired) since last end of billing 7 b 0 9 17
period
Time of last reset 7 b 0 9 18
Date of last reset 7 b 0 9 19
Billing period reset lockout time 7 b 0 9 20
Fourth billing period scheme
Number of days (time expired) since last end of billing 7 b 0 9 21
period
Time of last reset 7 b 0 9 22
Date of last reset 7 b 0 9 23
Billing period reset lockout time 7 b 0 9 24
OBIS code
General and shows service entry objects – Gas
A B C D E F
Ambient device temperature, average 15 minutes 7 b 0 11 1
Ambient device temperature, average 60 minutes 7 b 0 11 11
Ambient device temperature, average day 7 b 0 11 21
Ambient device temperature, average month 7 b 0 11 31
Gas parameters for volume conversion, currently
used in compressibility calculation
Reference pressure of gas analysis 7 b 0 12 8
Reference temperature of gas analysis 7 b 0 12 9
Superior Wobbe number 0 °C 7 b 0 12 10
Inferior Wobbe number 0 °C 7 b 0 12 11
Methane number 7 b 0 12 12
Total sulphur 7 b 0 12 13
Hydrogen sulphide H 2 S 7 b 0 12 14
Mercaptans 7 b 0 12 15
Water dew point (DP H 2 O) 7 b 0 12 16
Water (H 2 O) dew point outlet / normalised 7 b 0 12 17
Hydrocarbon dew point (DP C X H Y ) 7 b 0 12 18
Inferior calorific value H i,n 7 b 0 12 19
Water H 2 O 7 b 0 12 20
Density (of gas), base conditions 7 b 0 12 45
Relative density 7 b 0 12 46
Superior calorific value H s,n 7 b 0 12 54
Nitrogen N 2 7 b 0 12 60
Hydrogen H 2 7 b 0 12 61
Oxygen O 2 7 b 0 12 62
Helium He 7 b 0 12 63
Argon Ar 7 b 0 12 64
Carbon monoxide CO 7 b 0 12 65
Carbon dioxide CO 2 7 b 0 12 66
Methane CH 4 7 b 0 12 67
Ethene C 2 H 4 7 b 0 12 68
Ethane C 2 H 6 7 b 0 12 69
Propene C 3 H 6 7 b 0 12 70
Propane C 3 H 8 7 b 0 12 71
i-butane i-C 4 H 10 7 b 0 12 72
n-butane n-C 4 H 10 7 b 0 12 73
neo-pentane neo-C 5 H 12 7 b 0 12 74
i-pentane i-C 5 H 12 7 b 0 12 75
n-pentane n-C 5 H 12 7 b 0 12 76
Hexane C 6 H 14 7 b 0 12 77
Hexane share higher hydrocarbons C 6 H 14 % 7 b 0 12 78
Hexane+ C 6 H 14 + 7 b 0 12 79
Heptane C 7 H 16 7 b 0 12 80
OBIS code
General and shows service entry objects – Gas
A B C D E F
Octane C 8 H 18 7 b 0 12 81
Nonane C 9 H 20 7 b 0 12 82
Decane C 10 H 22 7 b 0 12 83
Tetrahydrothiophene 7 b 0 12 84
Gas parameters for Venturi measurement
K0 Densimeter Coefficient 7 b 0 14 1
K2 Densimeter Coefficient 7 b 0 14 2
Densimeter period for instantaneous measurement 7 b 0 14 10
Densimeter period for measurement period 15 minutes 7 b 0 14 11
Sensor manager
Manufacturer specific i)
7 b 96 50 e
.....................
Manufacturer specific 7 b 96 99 e
a
A volume sensor could be an external mechanical meter / encoder / electronic index.
b
Absolute in the sense that negative volume is summed as positive ABS().
c
An absolute temperature or absolute pressure outside these limits may affect the error status of the device.
OBIS code
General and shows service entry objects – Gas
A B C D E F
d
If multiple recording intervals are implemented, then recording interval 1 shall be the shorter.
e This value indicates the remaining time interval for soft time setting, where the clock is corrected in small
steps (equivalent to Clock object method 6).
f
Temperature heating is applied by stations with gas heating systems.
g
Application for control of battery environment or volume conversion device environmental control.
h Status words referring to a status table with fix status words or to any status table bits using mapped status
(class_id = 63).
i The range D = 50…99 is available for identifying objects, which are not represented by another defined code,
but need representation on the display as well. If this is not required, the range D = 128…254 should be used.
OBIS code
Error register objects – Gas
A B C D E F
Error registers 7 b 97 97 e
NOTE The information to be included in the error objects is not defined in this document.
OBIS code
List objects – Gas
A B C D E F
Gas related data of billing period (with billing period scheme 1 if
7 b 98 1 e 255 a
there are more than one schemes available)
Gas related data of billing period (with billing period scheme 2) 7 b 98 2 e 255 a
Gas related data of billing period (with billing period scheme 3) 7 b 98 3 e 255 a
Gas related data of billing period (with billing period scheme 4) 7 b 98 4 e 255 a
a
F = 255 means a wildcard here. See 7.11.3.
Event triggered means the termination of a billing period by events, e.g. by commands. (Therefore, the
b
profile entries are not equidistant in time).
OBIS code
Data profile objects – Gas
A B C D E F
Load profile with recording interval 1 7 b 99 1 4 a
Load profiles for indexes and index differences of volume, mass and energy 7 b 99 d c
e d
b
Table 96 – OBIS codes for general and service entry objects – Water
OBIS code
General and service entry objects – Water
A B C D E F
OBIS code
General and service entry objects – Water
A B C D E F
a In case of billing period schemes absence or event triggered, commonly calculated from local
date and local time information.
The range D = 50…99 is available for identifying objects, which are not represented by
b
another defined code, but need representation on the display as well. If this is not required,
the range D = 128…254 should be used.
OBIS code
Error register objects – Water
A B C D E F
Error registers 8/9 b 97 97 e
NOTE The information to be included in the error objects is not defined in this document.
OBIS code
List objects – Water Meters
A B C D E F
Water Meter related data of billing period (with billing period scheme
8/9 b 98 1 e 255 a
1 if there are two schemes available)
Water Meter related data of billing period (with billing period scheme 8/9 b 98 2 e 255 a
2)
a
F = 255 means a wildcard.
OBIS code
Data profile objects – Water
A B C D E F
Consumption/load profile 8/9 b 99 1 e
OBIS code
Water related objects
A B C D E F
Consumption
Current index, total 8/9 b 1 0 0
Current index, tariff 1 8/9 b 1 0 1
Current index, periodical, total, the two last periods 8/9 b 1 1 0 102
Monitoring values
Flow rate, maximum value, previous period 8/9 b 2 5 0 V Z-1
Forward temperature, billing date value, last billing period 8/9 b 3 3 0 101
Some value groups may be suppressed, if they are not relevant to an application:
A - B : C . D . E * F
IEC 304/02
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).
The manufacturer shall ensure that the combination of the OBIS code and the class_id (see
Clause 4) uniquely identifies each COSEM object.
7.11.2 Display
The usage of OBIS codes to display values is normally limited in a similar way as for data
transfer, for example according to IEC 62056-21:2002.
Some codes in value group C and D may be replaced by letters to clearly indicate the
differences from other data items; see Table 102.
The billing periods can be identified relative to the status of the billing period counter or relative
to the current billing period.
For electricity, there are two billing period schemes available in Table 57, each scheme defined
by the length of the billing period, the billing period counter, the number of available billing
periods and the time stamps of the billing period. See also 6.2.2 and 7.5.4.1.
For gas, there are four billing period schemes available, see Table 89.
With 0 < F < 99, a single billing period is identified relative to the value of the billing period
counter, VZ. If the value of the value group of any OBIS code is equal to VZ, this identifies the
most recent (youngest) billing period. VZ -1 identifies the second youngest, etc. The billing period
counter may have different operating modes, for example modulo-12 or modulo-100. The value
after reaching the limit of the billing period counter is 0 for the operating mode modulo-100 and
1 for other operating modes (for example modulo-12).
With 101 < F < 125, a single billing period or a set of billing periods are identified relative to the
current billing period. F=101 identifies the last billing period, F = 102 the second last / two last
billing periods, etc., F = 125 identifies the 25 th last / 25 last billing periods.
F = 126 identifies an unspecified number of last billing periods, therefore it can be used as a
wildcard.
F=255 means that the value group F is not used, or identifies the current billing period value(s).
For use of ICs for representing values of historical billing periods, see 6.2.2 and Table 103.
Value group F
7.11.4 COSEM
The usage of OBIS codes in the COSEM environment shall be as defined in Clause 6.
Annex A
(Informative)
Additional information on Auto answer and Auto connect ICs
NOTE This information is related to the “Auto answer” (class_id = 28, version = 2, see 4.7.5) and “Auto connect”
(class_id = 29, version = 2, see 4.7.6) interface classes.
Since the capabilities (e.g. connection time, number of parallel connections) of communication
networks (e.g. GPRS) are limited, devices e.g. meters are not permanently connected to the
communication network.
Devices may connect to the network in regular intervals or on special events either to send
unsolicited data or just to become accessible.
If a DLMS/COSEM client e.g. a Head End System needs to access a server e.g. a meter that is
not connected to the communication network a wake-up request can be sent. This may be a
wake-up call or a wake-up message, e.g. an SMS message. After successfully processing the
wake-up request the device connects to network.
Figure A. 1 below shows an example for a GSM/GPRS communication network. Please note
that the dashed lines represent the network services, the solid lines refer to possible application
layer services.
Head End
Wake Up
Call / SMS System
(COSEM client)
PDP
PULL context
PUSH
(2 way, initiated (1 way, initiated
by client) by server)
Meter
(COSEM server)
The basic network connectivity in the case of a mobile network (GPRS or equivalent service) is
modelled by the “Auto connect” IC. Depending on the mode the connection can be 'always on',
'always on in a time window' or 'only on after a wake-up'.
Annex B
(Informative)
Additional information to M-Bus client (class_id = 72, version 1)
State transitions of the encryption_key_status attribute for different use cases are shown in
Figure B. 1.
slave_deinstall
State (0)
No_encryption_key
transfer_key
set_encryption_key
slave_deinstall slave_deinstall
State (2)
State (1) encryption_key_transferred
encryption_key_set or
encryption key in slave preset
set_encryption_key
transfer_key
slave_deinstall
transfer_key set_encryption_key
State (3)
encryption_key_set
_and_transferred
set_encryption_key
transfer_key
State (4)
encryption_key_in_use
Annex C
(Informative)
Additional information on IPv6 setup class (class_id = 48, version = 0)
C.1 General
In most regards, IPv6 is a conservative extension of IPv4. Most transport and application-layer
protocols need little or no change to operate over IPv6; exceptions are application protocols
that embed internet-layer addresses, such as FTP or NTPv3.
IPv6 specifies a new packet format, designed to minimize packet-header processing. Since the
headers of IPv4 packets and IPv6 packets are significantly different, the two protocols are not
interoperable.
IPv6 addresses are typically composed of two logical parts: a 64-bit (sub-)network prefix used
for routing, and a 64-bit host part used to identify a host within the network.
The formats allowed for an IPv6 address are shown in Figure C. 1 (see
http://www.iana.org/assignments/ipv6-address-space/). Note that to facilitate the IPv6 address
writing, a specific notation defined in RFC 4291 has been specified by IETF (e.g. FF00::/8).
128 bits
IPv6 address
format IPv6 Prefix Interface Identifier
(IETF RFC 4291)
64 bits 64 bits
Where:
• Global Unicast is a routable address in the whole internet network and is composed as
follows:
• Global prefix assigned by IANA (see http://www.iana.org/assignments/ipv6-unicast-
address-assignments/);
• Subnet ID (SID) allocated by the network administrator; and
• Interface Identifier either generated from the interface's MAC address (using modified
EUI-64 format), or obtained from a DHCPv6 server, or assigned manually;
• Unique Local Unicast is an address only applicable to local network. This type of address is
not routable outside the local network. The Global ID and the Subnet ID (SID) are allocated
by the network administrator;
• Link Local Unicast is a unicast address allowed for a link local (without router). This type of
address is not routable outside a local link;
• Multicast is an address assigned to different devices of the network. Following the scope
(SC) of the address, the multicast group may be either Interface-local, Link-local, Admin-
local, Site-local, Organization-local or global. For more information about Flag and SC
(scope) parameters, see RFC 4291, 2.7.
It is important to note that there is no broadcast address defined in IPv6.
Annex D (Informative)
Overview of the narrow-band OFDM PLC technology for PRIME networks
For the specification of the PRIME narrow-band OFDM PLC setup classes, see 4.12.
NOTE This technology is supported by the PRIME Alliance, http://www.prime-alliance.org.
ITU-T G.9904:2012 specifies a physical layer, a medium access control layer and convergence
layers for cost-effective narrowband (<200 kbps) data transmission over electrical power lines,
intended for use in smart metering and smart grid applications. It is based on Orthogonal
Frequency Division Multiplexing (OFDM).
Annex E
(informative)
Overview of the narrow-band OFDM PLC technology for G3-PLC networks
For the specification of the G3 narrow-band OFDM PLC setup classes, see 4.13.
NOTE This specification is supported by the G3-PLC Alliance, http://www.G3-PLC.com.
ITU-T G.9903 specifies the physical, MAC and 6LoWPAN Adaptation layers of the G3-PLC
technology while ITU-T G.9901 deals with frequency bandplan allocation and associated
transmission level limitations.
Power line communication has been used for many decades, but a variety of new services and
applications require more reliability and higher data rates. However, the power line channel is
very hostile. Channel characteristics and parameters vary with frequency, location, time and
the type of equipment connected to it. The lower frequency regions from 10 kHz to 200 kHz are
especially susceptible to interference. Furthermore, the power line is a very frequency selective
channel. Besides background noise, it is subject to impulsive noise often occurring at 50/60 Hz
and group delays up to several hundred microseconds.
G3-PLC uses advanced modulation and channel coding techniques, which enables efficient use
of the limited bandwidth of the CENELEC bands and facilitates communication over the power
line channel. This combination enables a very robust communication in the presence of narrow-
band interference, impulsive noise, and frequency selective attenuation. The specification
addresses the following main objectives:
• a robust high-performance PHY layer based on OFDM and adapted to the narrow-band PLC
environment;
• a MAC layer of the IEEE 802.15.4 type (extended), well suited to low data rates;
• IPv6, the new generation of IP (Internet Protocol), which widely opens the range of potential
applications and services; and
• to allow good IPv6 and MAC interoperability, an Adaptation sublayer taken from the Internet
world (IETF) and called 6LoWPAN (RFC 4944 extended and RFC 6282). The adaptation
sub layer also embeds the LOADng routing algorithm to allow multi-hop mesh connectivity.
For more information about the extensions of IEEE 802.15.4, RFC 4944 and RFC 6282 (AKA
6LoWPAN) standards, and LOADng, see ITU-T G.9903:2014.
IEC 62056-8-5 specifies the DLMS/COSEM narrowband OFDM PLC profile for G3-PLC
networks.
Annex F
(informative)
Bibliography
IEC 61334-6 Distribution automation using distribution line carrier systems – Part 6: A-XDR encoding rule
IEC TR 62051:1999 Electricity metering – Glossary of terms
IEC TR 62051-1:2004 Electricity metering – Data exchange for meter reading, tariff and load control – Glossary of
terms – Part 1: Terms related to data exchange with metering equipment using
DLMS/COSEM
IEC 62056-46:2002 + Electricity metering – Data exchange for meter reading, tariff and load control –
AMD1:2006 Edition Part 46: Data link layer using HDLC protocol
1.1
IEC 62056-4-7 Electricity metering – Data exchange for meter reading, tariff and load control –
Part 47: COSEM transport layers for IPv4 networks
Electricity metering data exchange – The DLMS/COSEM suite – Part 5-3: DLMS/COSEM
IEC 62056-5-3
application layer
Electricity metering data exchange – The DLMS/COSEM suite – Part 6-1: Object
IEC 62056-6-1
identification system (OBIS)
Electricity metering data exchange – The DLMS/COSEM suite Part 6-2: COSEM interface
IEC 62056-6-2
classes
Electricity metering data exchange – The DLMS/COSEM suite Part 6-9: Mapping between
IEC 62056-6-9 the Common Information Model message profiles (IEC 61968-9) and DLMS/COSEM (IEC
62056) data models and protocols
Electricity metering data exchange – The DLMS/COSEM suite – Part 7-3: Wired and wireless
IEC 62056-7-3
M-Bus communication profiles for local and neighbourhood networks
Electricity metering data exchange – The DLMS/COSEM suite – Part 7-5 : Local data
IEC 62056-7-5
transmission profiles for Local Networks (LN)
IEC 62056-7-6 Electricity metering data exchange – The DLMS/COSEM suite – Part 7-6: The 3-layer,
connection-oriented HDLC based communication profile
IEC 62056-8-3 Electricity metering data exchange – The DLMS/COSEM suite – Part 8 3: Communication
profile for PLC S-FSK neighbourhood networks
Electricity metering data exchange – The DLMS/COSEM suite – Part 8 4: Communication
IEC 62056-8-4
profiles for narrow-band OFDM PLC PRIME neighbourhood networks.
Electricity metering data exchange – The DLMS/COSEM suite – Part 8-5: Narrow-band OFDM
IEC 62056-8-5
G3-PLC communication profile for neighbourhood networks
IEC 62056-8-20 Electricity metering data exchange – The DLMS/COSEM suite – Part 8-20: Mesh
communication profile for neighbourhood networks
IEC 62056-9-7 Electricity metering data exchange – The DLMS/COSEM suite – Part 9-7: Communication
profile for TCP-UDP/IP networks
ISO 12213-3 Natural gas – Calculation of compression factor – Part 3: Calculation using physical
properties
ISO/IEC 10646 Information technology – Universal Coded Character Set (UCS)
ISO/IEC 80000 Quantities and Units
EN 1434-3 Heat meters - Part 3: Data exchange and interfaces
EN 12405-1 Gas meters - Conversion devices - Part 1: Volume conversion
EN 12405-2 Gas meters - Conversion devices - Part 2: Energy conversion
ITU-T G.9901 SERIES G: TRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS AND NETWORKS
– Access Networks – In premises networks –
Narrow-band orthogonal frequency division multiplexing power line communication
transceivers – Power spectral density specification
3GPP TS 36.214 Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio
Access (E-UTRA); User Equipment (UE) procedures in idle mode.
3GPP TS 36.214 Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio
Access (E-UTRA); Physical layer; Measurements
ITU Recommendation Information technology – Open Systems Interconnection – Service definition for the
X.217 association control service element
ITU Recommendation Information technology – Open Systems Interconnection Connection-oriented protocol for the
X.227 association control service element: Protocol specification
DIN 43863-3 Electricity meters – Part 3: Tariff metering device as additional equipment for electricity
meters – EDIS – Energy Data Identification System
Internet Protocol, 1981. (Also IETF RFC 0791, RFC 0792, RFC 0919, RFC 0922, RFC 0950,
IETF STD 5
RFC 1112)
American Gas Association Report No 8. Compressiblity Factors of Natural Gas and other
AGA 8
related Hydocarbon Gases
Dictionary Gas 1997 Multilingual Dictionary of the Gas Industry (International Gas Union IGU)
Transmission Control Protocol (Also IETF STD 0007), 1981, Updated by: RFC 3168.
RFC 793
http://www.ietf.org/rfc/rfc793.txt
RFC 940 Toward an Internet Standard Scheme for Subnetting, 1985. http://www.ietf.org/rfc/rfc940.txt
RFC 950 Internet Standard Subnetting Procedure, 1985. http://www.ietf.org/rfc/rfc950.txt
RFC 2460 Internet Protocol, Version 6 (IPv6), 1998. http://www.ietf.org/rfc/rfc2460.txt
RFC 2473 Generic Packet Tunneling in IPv6, 1998. http://www.ietf.org/rfc/rfc2473.txt
RFC 2675 IPv6 Jumbograms, 1999. http://www.ietf.org/rfc/rfc2675.txt
RFC 2711 IPv6 Router Alert Option, 1999. http://www.ietf.org/rfc/rfc2711.txt
RFC 3775 Mobility Support in IPv6, 2004. http://www.ietf.org/rfc/rfc3775.txt
RFC 4291 IP Version 6 Addressing Architecture, 2006. http://www.ietf.org/rfc/rfc4291.txt
RFC 4302 IP Authentication Header, 2005. http://www.ietf.org/rfc/rfc4302.txt
RFC 4303 IP Encapsulating Security Payload (ESP), 2005. http://www.ietf.org/rfc/rfc4303.txt
RFC 5095 Deprecation of Type 0 Routing Headers in IPv6, 2007. http://www.ietf.org/rfc/rfc5095.txt