DLMS in nutshell

What is DLMS?

DLMS is a protocol standard that is used in Electricity- , water- and gas meters globally. Protocol standard is needed to read data from different meter types and manufacturers.Using this standard client can talk with the meter and speak the same "language".

This is a big problem. If you have meters from different manufacturers and meters don't speak the same "language" you need several different data collecting systems and this is expensive and complex. You need to maintain several reading systems and then transform collected data to same format so it comparable. Also you might be lock-out to one meter manufacturer and changing meter to to other model is not possible.

To improve compatibility there is a need for a standard and it's also mandatory that meters are certified. Without certification meter are not fully compatible. Small variations in the meters cause that meters don't fully co-operate and this is causing problems during the time.

In this document I'll simplify DLMS and explain what kind of functionality it offers and what you can do with it.I'll don't go deep. The idea is explain a few basics.

DLMS is a standard and it's based for the following IEC standards.

  • IEC 62056-21 Direct local data exchange
  • IEC 62056-42 Physical Layer Services and Procedures for Connection-Oriented Asynchronous Data Exchange
  • IEC 62056-46 Data link layer using HDLC protocol
  • IEC 62056-47 COSEM transport layers for IPv4 networks
  • IEC 62056-53 COSEM application layer
  • IEC 62056-61 OBIS Object identification system
  • IEC 62056-62 Interface objects

There are also nationalized sub-standards from DLMS. The idea of sub-standards is that non-necessary functionality is removed. This makes meters easier to implement and more robust.

  • India Standard 15959 (Part-1) 2011: Data exchange for electricity meter reading, tariff and load control: companion specification.
  • India Standard 15959 (Part-2) 2016: Data exchange for electricity meter reading,tariff and load control: companion specification part2 for smart meter.
  • Italy Standard UNI/TS 11291-11-2
  • Chinese Standard DL/T698.45

As you can see DLMS is very well documented, but it's not easy protocol if it's compared to example M-BUS, MeterBus, Profibus or other fieldbuses.
Comparing DLMS to fieldbuses is not right, because the purpose is different, but this is happening all the time. Fieldbuses are common most of readers, so I'm using them here as an example.
Main difference between those protocols and DLMS is amount of the data. Usually fieldbuses are used to read register values and the data size is very small. Example is read payload can be only 16 bits register address.

Modbus RTU request to read 2 registers.
01 03 02 58 00 02 44 60
DLMS request to read 2 registers.
7E A0 24 03 21 5A 5C F0 E6 E6 00 C0 03 C1 02 00 03 01 01 15 19 00 FF 02 00 00 05 01 00 1F 04 00 FF 02 00 31 8E 7E

What DLMS is not?

DLMS is a very open protocol and it doesn't define what kind of functionality meter must implement. It only describes how to communicate with the meters. Meters are very different. They measure different things and communication channels are very different. Some meters measure only a few things and some hundreds, but they might all have DLMS certificate. It depends from the user what kind of meter is needed.

Authentication levels allows different access rights

In DLMS there are different authentication levels, that are missing from the fieldbuses. Each authentication level gives different kind of control for the meter.
Using authentication levels client can read how much electricity is used, but is not allowed to close the meter. Or the most frequently asked question: "How I can change the scaler so electricity usage is reduced?"

Without authentication client can usually read values from the meter, using Low authentication client can set the time and with High authentication client can do everything. Update the firmware, reset meter, etc.
It's clear that there is no need for authentication levels in closed system and fieldbuses don't need them, but in DLMS you need to establish communication to the meter before you can read anything from the meter.

There are also pre-established connections that don't require authenticated connection and client can just read value from the meter. Note! All meters don't support pre-established connections.

Secured connections with ciphering

There is not real need for secured connections in fieldbuses, but it's mandatory when data is send Over The Air using Lora or different Mesh networks. DLMS Support three different ways to secure the data.

  • Authentication
  • Encryption
  • Authentication and Encryption

More information from secured connections.

Logical Name and interfaces

In fieldbus protocols you need to know register address to read value from the meter. If register value is correct meter returns some value. If you change the meter type or model, register address is different and it must update.
If you have 10 meters updating this information is not a big job. Updating this totally different if you have 100.000 meters or more.

In DLMS there are interfaces that describe what kind of data you want to get from the meter. Idea is that all meter manufacturers should use the same interfaces and Logical names.
Meter can be replaced to new one when different meters are using same interfaces and logical names. It makes possible even change meter model and manufacturer and old data collecting system can be used.

Client address

Each authentication level has own client address. So when authentication level changes also client address changes. There is a client address defined in DLMS standard only when connection is made without authentication.

In ideal world all the meter manufacturers were using same client addresses, but they are not defined in DLMS standard, so different meters are using different values.
If client address is wrong meter don't reply. Only meter manufacturer knows what client address can be used. So it's important that this value is documented. It can be find using brute force, but it's easier to read from the document.

Server address

Each meter must have unique server address. Using this address meter knows what messages to receive. Also client knows message sender.
If connection is made using Point To Point connection (TCP/IP, Serial port, etc) default server address 1 can be used.

Meter serial number can be usually used as server address. This makes possible that there are several meters operating in the same network (UDP, radio, RS-485).

PDU and frame size

Size of the PDU depends from the meter. If meter don't have a lot of memory PDU size is smaller. Frame size depends from the communication channel. If communication channel is example TCP/IP, frame size can be 1024 bytes. When communicating Over The Air, frame size can be example 100 bytes.

Here is an example:
Data size is 1MB, but meter have only 2KB (PDU) of memory where to save the data. Because of this all the data can't be read at once. Size of PDU (2 KB) is read at once to the memory. When PDU is full, it's send over communication channel. Size of frame depends from the communication channel. So it might be that PDU is split to 20 frames and each frame must delivery before asking next PDU.

There are a lot of meters that are using default frame size size 128 bytes and that is not an issue, but it might be an issue if communication channel is changed from GPRS to example Lora.