Implementing DLMS/COSEM in

Smart Meters
Gordan Štruklec*1, Joško Maršić*2
*RIZ Transmitters Co., Božidarevićeva 13, 10000 Zagreb, Croatia
1
gordan.struklec@riz.hr
2
josko.marsic@riz.hr

Abstract—For some time now there have been initiatives
(European SmartGrids, GridWise) to develop new visions of the
future electric system – smart grid, triggered with the increasing
demand for electricity and the drive for lower carbon generation,
and made possible by new advances in technology. In order to
deliver electric energy reliably and efficiently to end-users, smart
system has to monitor and control demand appropriately. This
can be done through the use of smart meters. However, for long
there has been no unique and generally accepted protocol for
delivery and interpretation of meter data, what has generated
many problems and difficulties for both AMI system developers
and utility distributors. DLMS/COSEM is widely accepted
standard-based language for meter communication, whose main
goal is interoperability among metering equipment. Although it
is a well-defined protocol, integrating it into a meter sets new
challenges in front of a developer like resources management and
compatibility with current HW and SW platform.
A fully automated power delivery network that would be
able to monitor and control electricity flows to every customer
and node, ensuring two-way flow of electricity and real-time
information between the power plant and appliance and every
node in between, imposes the incorporation of new and
advanced technologies, many of which today come under the
term ‘smart metering’ [2].
Although not as broad set of technologies and solutions as
smart grid (Fig. 1), smart metering can encourage consumers
to reduce their demand (load) when prices are high or when
system reliability or power quality is at risk. In that way smart
meters enable the provision of services (like demand
management) to directly influence customer behavior and to
become an important part of a smart grid.

I. INTRODUCTION
A. Smart grids
The European Technology Platform SmartGrids defines
smart grids as electricity networks that can intelligently
integrate the behavior and actions of all users connected to it -
generators, consumers and those that do both – in order to
efficiently deliver sustainable, economic and secure electricity
supplies [1]. Every device that consumes electricity is part of
the grid – not only the devices (or equipment) owned and
operated by the utilities, but also everything connected to the
electricity network (appliances in homes, HVAC equipment,
streetlights in cities and towns). The four key elements of a
smart grid are identified as flexibility in fulfilling customer’s
needs, accessibility to all users, reliability in quality and in Fig. 1. Generalized diagram of a smart grid [1]
security of power supply, and interactivity [2]. Among all
other benefits, which smart grids offer to the utilities, end
users and community in general, a few of them play important B. Smart metering
roles in reducing carbon emissions and improving energy All the information that energy suppliers (service
efficiency. These benefits come from the optimization of grid providers) provide to their customers is based on the meter
operation and usage (e.g. reducing losses) and grid data. Based on this data the billing is carried out, anomalous
infrastructure on one side, and on the other providing energy consumption and fraud can be detected, warnings and
consumers with greater information and options for choice of alarms are sent (e.g. the remaining credit in the case of pre-
supply, allowing them to play a part in optimizing the paid contracts). Furthermore, the whole customer's
operation of the system. The latter can be achieved by helping consumption profile can be created and according to it various
consumers to participate in the market not only by using their tariff models can be offered to a customer in a new contract,
energy more efficiently (e.g. through smart metering) but also and in the case of irregular payment the customer can be
by allowing consumers to act also as producers selling back automatically switched off the grid (switching on the grid has
their excess electricity (e.g. plug-in electrical vehicles). to be done manually because of safety reasons). A two way
communication on this level is mandatory to allow intelligent
functions regarding demand side management, distributed
energy resources and energy savings. TABLE I
PROTOCOLS AND TECHNOLOGIES FOR AMR/AMI – FIELD OF APPLICATION
Main function of an Automatic Meter Reading (AMR)
system is gathering meter data for billing in an automated Field of application
way. Various standard-based techniques enable local or Data
Specification Home
remote connections to meters, e.g. IEC62056-21, IEC62056- Local Remote
AMI autom model
31, M-bus, GSM, GPRS, PSTN, Internet, PLC. AMR AMR
ation
According to demands set forth earlier in the texts, the
conventional functionality of AMR is changing in the IEC 61334 PLC Y Y Y
direction of smart multi-metering or multi-functional IEC 62056-21
Y Y
Advanced Metering Infrastructure (AMI) capable of creating 'FLAG'
value for energy consumers, network operators, metering IEC 62056-31
Y Y
operators and retailers. The term AMI refers to systems that Euridis
measure, collect and analyze energy usage data, from IEC 62056
Y Y Y Y Y
advanced devices such as electricity meters, gas, heat and/or DLMS/COSEM
water meters, through various communication media on EN 13757
Y Y Y Y
request or on a predefined schedule. Advanced functionalities M-bus
provided by an AMI system, like customers relation PRIME Y Y Y
management, demand side management, local power quality
monitoring etc., give the opportunity for various business
processes: customer management including supplier change, TABLE II
energy supply / billing, (pre)payment, load management, PROTOCOLS AND TECHNOLOGIES FOR AMR/AMI – SUPPORTED MEDIA
network condition and health monitoring, meter condition and Communication media supported
health monitoring, outage management or energy services [3]. Specification
Regarding (electricity) meters this means providing two- Local
GSM GPRS Internet PLC
bus
way communication and supporting various functionalities, of
which energy consumption measurement is basic, but today IEC 61334 PLC Y
even not the most demanding from a developer's point of IEC 62056-21
Y Y Y
view. An electricity meter has to provide the data about 'FLAG'
measured energy consumption and demand - if possible both IEC 62056-31
Y
imported and exported energy, about load profiles, power Euridis
quality, or customer information. The meter should also IEC 62056
Y Y Y Y Y
enable the functionalities like load monitoring and DLMS/COSEM
management, and event monitoring and logging. EN 13757 M-bus Y
PRIME Y

II. DLMS/COSEM
For the implementation of an efficient AMI system the
devices have to be interoperable. There is a need to define
universal data protocols so that all the partners in the
communication chain can reliably and successfully receive
and send messages, and to unambiguously excerpt and
interpret useful data. There is a need for communication
standards. DLMS/COSEM is the common language such that
the partners can understand each other [4]. There are many
standards and protocols disposable for AMI. In Table I the
field of application for some of the AMR/AMI technologies
and protocols is presented [3]. Table II presents
communication media supported by these protocols.
DLMS/COSEM covers all the AMR/AMI application fields
and supports all the communication media (except maybe
wireless mesh networks). DLMS stands for “Device Language
Message specification” and it is a generalized concept for
abstract modeling of communication entities. COSEM is
“COmpanion Specification for Energy Metering” – it sets the
rules, based on existing standards, for data exchange with
energy meters.
DLMS/COSEM is usually promoted through the 3 step
approach (Fig. 2) [5]. COSEM defines the utility type and
communication media independent object model for metering
applications: object names and identifiers on the display
(OBIS code – Object Identification System), from abstract to
energy type specific codes. DLMS defines services to access
object elements transported by application protocol data units
(APDU), which are common to all objects. Finally,
DLMS/COSEM defines profiles to access communication
media like PSTN/GSM, Internet, Euridis, M-bus, or PLC.
Through these media packets are transported using
OSI/Internet based protocols like HDLC, TCP-UDP/IP,
ASN.1, or ACSE.
Every parameter in a meter is represented by a COSEM
object – instance of a class. All objects of the same class have
the same attributes and methods. For example, meter
parameters like active A+/A- or reactive R+/R- energy in first
tariff can be instances of the register or extended register class,
whereas maximum demand P+/P- or Q+/Q- can be of the class
register, extended register or profile generic. Register objects
are modeled through logical name, value and scaler-unit
attributes, while extended register objectts have two more
attributes: status and capture time. If e.gg. accumulated A+
energy in tariff 1 has to be read out of a meter, DLMS
provides GET-requests to acquire all needded object attribute
data - value and scaler-unit, whereby innformation can be
unambiguously interpreted.
Fig. 2. DLMS/COSEM 3 step approaach [5]
Further in text the real implementation ofo DLMS/COSEM
object model in a smart meter is presented with useful
guidelines and examples provided, whereaas some important
functional issues still had to be set forth.
III. MAKING THE METER SMA ART
As already stated in text, implementing DLMS/COSEM in
a meter gives to the meter the opportunitty to communicate
with other compatible devices in an AMI system,
s making it a
part of smart metering network. Is it really so?
s added on top of current protocolls’ stack.
Nowadays in Croatia there are still compatibility and
interoperability issues. There are many typpes of meters from
various manufacturers installed, suppporting various
communication protocols, mainly IEC620556-21 (optical, CS
or RS485 interface), IEC62056-31 andd DLMS/COSEM
(through optical or RS485 interface). To reaad out all meters of
all types one needs to use different PC softw ware because there
is no software that supports all protocols. InI addition to that,
although the meters support the samee DLMS/COSEM,
different variants of data modeling are used so that one PC
application fully understands only the messaages from a certain
data model and not from any other (tthis will be later
discussed). This imposes many questions to t the AMI system
integrators, and directly effects meter manufacturers,
m who
must comply with the utility supplier’s reequests in order to
bring their equipment on the market. Neverttheless, making the
meter DLMS/COSEM compliannt is a must, as a start off point
in the course of solving all menttioned issues.
A. Compatibility with ‘old’ harrdware and software
In order to easily integrate the
t new DLMS/COSEM meter
into existing AMI system, thhe most of the current meter
functions have to be further suppported. In the meter chosen for
this application [6] there are many
m functions which are the
basis to build-up the new smaart meter: active (A+, A-) and
reactive (R+, R-) energy measurement
m in 1-4 tariffs;
maximum active (P+, P-) and reeactive (Q+, Q-) demand in all
tariffs; energy and demand of the last 18 billing periods;
remote or local billing period reset; load profile for last 4
months; log book for last 64 events; current, voltage and
phase measurement; current annd last calendar year’s power
quality values like power failures, overvoltage and
undervoltage measurement annd logging; tamper detection;
number of readouts and connfiguration changes; real-time
clock, date and calendar; prograammable time switching table;
integrated ripple control reeceiver; tariff-switch inputs;
programmable LCD sequence; load limitation and switching
off/on; autonomous battery operation of 10 years; self-testing;
two-way optical IEC62056-21 communication
c interface; two-
way RS485 communication intterface or two-way IEC62056-
31 interface.
All these functions exhaustt almost all of the available
resources, FLASH and RAM inn the MCU. It was necessary to
make some decisions about reemoving some of the usually
unused features (of course it coould have been thought in the
course of building up the wholee new platform, but at the time
it was too expensive). Current trend
t in the market showed the
need for DLMS/COSEM, opticcal and RS485 interface. So the
decision was made to exclude IEC62056-31 interface and to
support DLMS through opticall and RS485 interface instead.
Although the new version of IE EC62056-31 (Euridis) proposes
the support also for DLMS, thee problem of the integration of
already installed and networkedd Euridis meters into a DLMS
supporting system will be solveed by the use of the smart data
concentrator with DLMS-Euridiis routing [7].
After the platform adjustmeents had been made, firmware
changes were in turn. The suppport for DLMS/COSEM was
B. Smart meter model
DLMS/COSEM is promotedd by DLMS UA, through the
two essential documents Greenn Book [8] and Blue Book [9].
All current meter data had to beb mapped to COSEM objects
according to the Blue Book, andd all data messaging according
to the Green Book.
First, all the objects were defined,
d enumerated and OBIS
code was appended to each object. OBIS uses six value
groups in a hierarchical structture (Fig. 3). Value group A
identifies the energy type meaasured, A=0 identifies abstract
codes, and A=1 identifies elecctricity codes. Value group B
identifies the measuring channnels. Value group C identifies
the physical quantity measured, while value group D identifies
the processing methods and country
c specific codes. Value
group E is used for identifying rates
r or can be used for further
classification. Value group F is used for iddentifying historical server address can be 1, 2 or 4 bytes. In the presented meter
values like billing periods or can be used for further the address is 1 or 4 bytes. In the meter model, when 1-byte
classification. Manufacturer specific codes are
a also possible. address is used it is always 0x03,0 to support management
logical device with logical adddress 0x01 (detailed coding of
address fields is explained in Green Book). If 4-byte
addressing is used (by default),, 2 bytes representing physical
device comprise of the meter seerial number’s 4 last digits. The
upper address is also 2 bytes, with
w management logical device
as the only logical device.
The question occurs - how to t address a networked meter,
i.e. if there are many meters onn the same bus? If a meter uses
only 1-byte address (and theree are such situation in praxis),
then the networking of many meters of the same type and
putting them to work (commuunicate with the client) seems
like mission impossible. It is so because they all have the
same logical device addresses. For this kind of situations 4-
Fig. 3. OBIS code structure [10] byte addressing is the most appropriate, because there is the
lowest probability that two or more
m devices with same address
would appear. In our meter eveen this situation is foreseen and
The 6-byte code in Fig. 3, ‘1.1.1.8.2.2555’, represents total if it happens, the physical addreess can be changed locally.
positive active energy in second tariff. Thhis object is of the Another question occurs – how h does a client know which
class register, with the OBIS code as itss first attribute or objects are supported in a meter? Well, there are mandatory
logical name. The second attribute – valuee is expressed with objects that need to be implemeented in every meter: COSEM
Unsigned32 data type while the third attriibute scaler-unit {- logical device name ‘0.0.42.0.00.255’ and current association
3,30} means the value should be scaled dow wn by 1000 and the ‘0.0.40.0.0.255’. Current asssociation object’s object_list
unit is Wh. Time object, e.g. is an abstract object of the clock attribute keeps the track of all the t objects implemented in the
class, with the logical name ‘0.0.1.0.0.255’. meter. After a client establishhes the application association
There are around 150 objects covering meter m functionalities connection with a server, it cann send a get_request to acquire
(half of them covering basic and most wanteed data). The space the object_list.
is left also for adding new objects. There is another important isssue which also needs a certain
Secondly, routines for packing object data into DLMS amount of consideration.
messages had to be developed. The 3-layeer HDLC protocol, To access an attribute or meethod of an object, it has to be
frame format type 3 is used to transmit packets through the referenced. COSEM application layer provides two
wires or optically. HDLC mode (9600bbps, 8N1) can be mechanisms to access the attributes: short name (SN)
entered directly through RS485 or throough Mode_E of referencing and logical name (LN) referencing. When SN
IEC62056-21. referencing is used, the attributtes and methods of objects are
Frame format is given in Table III, where w Flag=0x7E, mapped to DLMS named variaables. Each named variable is
addresses are 1,2 or 4 bytes long, control field is 1 byte and identified with a short name, which is a 2-byte unsigned
represents MAC command, HCS and FCS S are 2-byte frame integer. This is done during thee design of the meter. Attribute
check sequences, and in Info field logical link layer packets 1, the logical name of the objecct is mapped to a DLMS named
are sent. DLMS/COSEM application data is i sent in Info field variable identified by a base naame and all other attributes are
of the HDLC information command frame. referenced with short names thaat are offsets to the base name.
Except in the case of a few w special objects, there are no
TABLE III
HDLC FRAME FORMAT general rules defined for assigni
ing base names. This raises the
question of compatibility: if different
d meters use different
Frame Dest. Src.
Flag
format address address
Control HCS Info FCS Flag short names for the same objeccts, then data collector (client)
must have well-defined routtines to gather and not to
When considering addressing it has to be b pointed out that misinterpret the data. The proccedure goes like this: after the
the address consists of the lower and the uppper HDLC address. association application establishment, the client retrieves the
The lower address is physical device address, while the upper base names by reading the object_list attribute of the SN
is logical device address (one physical devvice can have many Association object. In the obbject_list the base names are
logical devices). The upper address is always present whereas associated to the correspondingg logical names, so the client
the lower can be omitted if not needed. It hhas to be mentioned can build up the mapping table.
that COSEM interface object model is based on the For our purpose the meter used LN referencing. This means
client/server paradigm. Client (PC applicaation) initiates the that each object is defined withh the logical name (OBIS code)
communication with a request and serveer (meter) answers and the class identifier (2-byte unsigned integer). In addition
with adequate response. Client address is always a 1 byte, and to this, attributes and methods have special identifiers within
each class (all of these are defined and can be easily found in The meter sends the value 1234 coded as unsigned 32-bit
[4] and [9]). Although supporting LN referencing means integer and attribute 3 (scaler-unit) {-3,30}. This means the
slightly more complex firmware than in the case of SN energy is 1,234 kWh. However, DLMS/COSEM gives the
referencing, it also gives the opportunity to support more opportunity for the developer to code this value also as 32-bit
objects than in the case of SN referencing. However, what signed integer, 8, 16 or 64-bit signed/unsigned integer, octet
seems to be the major advantage comparing to SN, LN object string or visible string. This also causes compatibility issues
names are understandable to all DLMS/COSEM supporting (at the time there is no software that covers all possible
equipment with no need for special mapping tables. In that variants of data interpretation) and problems for billing system
way the metering data can be acquired and parsed easily and management.
efficiently.
Fig. 4 shows the block diagram of the new meter after all C. Testing and verification
the functionalities were defined. After the meter object model had been developed, the
implementation had to be tested, verified and finally, certified.
R,S,T,N, 230V, 50Hz DLMS UA certifies a meter in the way that the client CTT
software [11] runs a sequence of tests on the meter and creates
report files, which are then verified by DLMS UA. If the
Analog Power
RCR meter passed all tests correctly a certificate is issued for that
RELAY: Front End supply meter type and the meter is listed on DLMS-compliant
Switch off/on
equipment list.
FRAM/
PC runs CTT tests locally through COM port. It tests the
EEPROM meter’s HDLC, APPL and COSEM layer. However, it does
not present the meter data in a user-friendly manner, so it is
Buttons,
Battery
good for testing only to the certain point. Unfortunately there
Tariff MCU
INPUTS is no commercial software which does this. There is a
switch
Optical
worthwhile attempt with free Icube software [12] which
interface- formats DLMS requests and responses in XML and is quite
LCD calibration easy to use. This is the issue that still needs to be worked on.
D. Further improvements
Communication interface
DLMS UA has recently made extensions to the protocol to
optical RS485 support more of the smart metering functionalities: multi-
metering, messages for the customer, load limitation,
connect/disconnect, firmware upgrade, status/fraud
monitoring. Messages for the customer are displayed on the
meter LCD or customer display. They can show the reason for
disconnect, threshold limitation values, impending credit
shortage etc. For this purpose new objects of Data class are
Fig. 4. Block diagram of the new meter
defined: ‘0.0.96.13.0.255’ customer port and ‘0.0.96.13.1.255’
display and customer port. Load limitation is handled by a
What still needs to be further considered is the presentation Limiter-class object and it enables remote setting of thresholds
of data values. For example, a client wants to read total and anticipation of credit shortage. Disconnect-class object
positive active energy out of a meter: object logical name supports remote, manual or local disconnect/reconnect in case
‘1.0.1.8.0.255’, class identifier 0x0003 - register, attribute 2 - of credit shortage, contract closure or emergency situations.
value (Fig. 5). These actions involve higher level of security to access the
object. For the purposes of firmware bug correction or adding
<GetRequest> new functionality there is new COSEM Image transfer class.
<GetRequestNormal> It enables remote update/upgrade of meter firmware.
<InvokeIdAndPriority Value="81" />
<AttributeDescriptor>
<ClassId Value="0003" />
<InstanceId Value="0101010800FF" />
<AttributeId Value="02" />
</AttributeDescriptor>
</GetRequestNormal>
</GetRequest>

Fig. 5. Typical DLMS/COSEM request

 IV. CONCLUSION
Smart meters are crucial part of an AMI system. Adding
smart features to a meter means a must have for the utility
provider, for the manufacturer it means fundamental step on
the way to the market, for the developer it means more
complex firmware, adjusting current (or new) HW/SW
platform, solving problems like compatibility, interoperability
and many more. DLMS/COSEM approach not only helps
solving these issues, but also makes the process of smart
meter development much easier.
Although DLMS/COSEM is a well defined protocol and
object model, certain matters still have to be defined with
more details (too broad data presentation possibilities,
unnecessary short name referencing). Besides, the lack of the
PC client application which includes all (or most of) DLMS
features and which is able to interpret data in a user-friendly
way makes the integration process more difficult and more
time-consuming.
Nevertheless, at the moment DLMS/COSEM is the right
choice to make smart meters really smart and to talk to each
other. And it seems to stay that way for some time.

REFERENCES
[1] (2011) The SmartGrids – European Technology Platform website.
[Online]. Available: http://www.smartgrids.eu/
[2] J. S. Jones, “Smart Meters for Smart Grids”, in Metering International,
2006, Issue 4, p. 70-71.
[3] “D2.1/4 State-of-the-art technologies & protocols”, The OPEN meter
Consortium, 2009.
[4] (2011) DLMS UA website. [Online]. Available:
http://www.dlms.com/information/whatisdlmscosem/index.html
[5] G. Kmethy, “IEC 62056 DLMS/COSEM workshop. Part 2: Main
concepts ”, Metering Europe, Vienna, Sep. 21, 2009.
[6] Trofazno brojilo EBT308-kombi. Technical Specification, RIZ
Transmitters, Zagreb, Croatia, 2011.
[7] GDL208 GPRS Data Logger. Technical specification, RIZ
Transmitters, Zagreb, Croatia, 2011.
[8] “DLMS/COSEM: Architecture and Protocols”, Ed.7.0, DLMS UA,
2009.
[9] “COSEM: Identification System and Interface Classes”, Ed.10.0,
DLMS UA, 2010.
[10] G. Kmethy, “IEC 62056 DLMS/COSEM workshop. Part 5: COSEM
data model”, Metering Europe, Vienna, Sep. 21, 2009.
[11] (2011) EuroDCS Energiedaten AG website. [Online]. Available:
http://www.eurodcs.com/dienstleistungen/dlms_index.htm
[12] (2011) Icube software website. [Online]. Available:
http://www.icube.ch/dlmscosem.html