What is the DLMS protocol?

DLMS is a standard protocol that is used in electricity, water and gas meters around the world. This type of protocol is essential for reading data from meters of different types and from different manufacturers. Using this standard, the customer can communicate with the meter and communicate in the same "language." There is a potential for a major problem to arise. When the user has meters from different manufacturers that do not speak the same "language," there is a need to use different data collection systems, which is costly and complicated. It is then necessary to start by operating several reading systems and then convert the collected data to the same format to make it compatible. In addition, there may be a blockage from one meter manufacturer, and changing the meter to another model is not possible in this situation.

DLMS is a standard based on the following IEC standards:

  • IEC 62056-42 Physical Layer Services and Procedures for Connection-Oriented Asynchronous Data Exchange

  • IEC 62056-21 Direct local 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 standardized sub-standards with DLMS. The idea behind sub-standards is to remove unnecessary features. This makes the solutions easier to implement and more reliable.

  • India Standard 15959 (Part-1) 2011: data exchange for electricity meter reading, tariff and load control: accompanying specification

  • Indian Standard 15959 (Part 2) 2016: Data exchange for electricity meter reading, tariff and load control: accompanying specification part 2 for smart meter

  • Italian Standard UNI/TS 11291-11-2
  • Chinese standard DL/T698.45

As you can see, DLMS is very well documented, but it's not an easy protocol if you compare it with, for example, M-BUS, MeterBus, Profibus or other network buses. DLMS should not be compared to network buses, since their purpose is somewhat different, but such situations occur all the time. Fieldbuses are most commonly used in readers, so they will be used here as an example. The main difference between these protocols and DLMS is the amount of data. Typically, fieldbuses are used to read register values, and the data packet is very small. For example, a read payload may only have 16 bits of register address.

Read 2 registers on Modbus RTU request

01 03 02 58 00 02 44 60

Read 2 registers per DLMS request

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 is not DLMS?

DLMS is a very open protocol and does not define what kind of functionality a meter must support. It only describes how to communicate with the meters. Meters are very different, they measure different things, and their communication channels are very different. Some meters measure only a few things, and others measure hundreds, but they can all be DLMS certified. It's up to the user to decide what kind of meter they need.

Authentication levels allow different access rights

There are different levels of authentication in DLMS that are missing in network buses. Each authentication level provides a different type of counter control. Using the authentication levels, the customer can read the amount of electricity consumed, but cannot stop the meter. It is also worth answering the most frequently asked question, "How can the meter settings be changed to reduce electricity consumption?" Without authentication, the customer can normally read values from the meter, with low authentication the customer can set the time, and with high authentication the customer can do anything. Update the firmware, reset the meter, etc. Clearly, there is no need for levels of authentication in a closed system, and network buses do not need them, but in a DLMS it is necessary to establish communication with the counter before anything can be read from it. There are also pre-established connections that do not require access authentication, and the client can only read the value from the counter. Note! Not all meters support pre-established connections.

Secure connections using encryption

There is no real need to secure connections on network buses, but it is mandatory when data is transmitted wirelessly over Lora or other Mesh networks. DLMS supports three different ways to secure data.

  • Authentication

  • Encryption

  • Authentication and encryption

Logistics nomenclature and interfaces

In field bus protocols, you need to know the register address to read the value from the counter. If the register value is correct, the counter displays a certain value. If the type or model of the counter changes, the register address is different and must be updated. If the user has 10 counters, updating this information is not a big problem. Updating is completely different if you have 100,000 or even more counters. In DLMS there are interfaces that describe the type of data the user wants to get from the meter. The idea is simple: all meter manufacturers should use the same interfaces and logical nomenclature. A counter can be replaced with a new one when different counters use the same interfaces and logical names. This even makes it possible to change the meter model and manufacturer, while keeping the old data collection system.

Customer address

Each authentication level has its own client address. Thus, when the authentication level changes, the client address also changes. The client address is defined in the DLMS standard only when a connection is established without authentication. In an ideal world, all counter manufacturers use the same client addresses, but they are not defined in the DLMS standard, so different counters use different values. If the customer address is incorrect, the meter does not respond. Only the meter manufacturer knows what customer address can be used. Therefore, it is important that this value is documented. It can be found using "brute force," but it is simpler to read it from the documents.

Server address

Each counter must have a unique server address. Using this address, the counter knows what messages it is supposed to receive. In addition, the client also recognizes the sender of the message. If the connection is established using a Point To Point connection (TCP/IP, serial port, etc.), you can use the default server address of 1. The meter's serial number can usually be used as the server address. This allows several meters to work on the same network (UDP, radio, RS-485).

PDU and data packet

PDU size depends on the counter. If the counter does not have a large memory, the PDU size is smaller. data packet depends on the communication channel. If the communication channel is TCP/IP, for example, the data frame can be 1024 bytes. For wireless communication, the data packet may be 100 bytes, for example.

This is an example:

The data frame is 1 MB, but the counter has only 2 KB (PDU) of memory in which to store data. For this reason, all the data cannot be read at once. The size of the PDU (2 KB) is read from memory. When the PDU is full, it is sent through the communication channel. The data packet depends on the communication channel. So it may happen that the PDU is split into 20 frames, and each frame must be transmitted before the next PDU is requested. There are many counters that use a default data packet of 128 bytes and this is not a problem, but it can be a problem when the communication channel is changed from GPRS to Lora, for example.

We encourage you to take a look at CONSTEEL Electronics offerings, which include industrial DLMS protocol gateways for high-speed meter data reading.