DLMS/COSEM is the set of specifications that lets meters and central systems from different manufacturers understand each other. COSEM models the meter as a set of objects of standardized classes, OBIS gives each data item a unique code and DLMS defines how it is requested and sent. Many markets require it for advanced metering.
Why DLMS/COSEM exists
An energy meter produces dozens of data items: active and reactive energy by direction, voltages, currents, demand, events, the state of the disconnect relay. If each manufacturer names and delivers them in its own way, a utility’s central system gets tied to a single supplier. DLMS/COSEM solves that problem with a common language to describe a meter and to talk to it.
Regulators in many markets adopt it for advanced metering, typically the DLMS/COSEM protocol under IEC 62056, with security suite 1 and non-repudiation where required, and they rule out migrating to closed or proprietary protocols. This guide explains the concept; it does not replace the specifications, which are published by the DLMS User Association.
The pieces
The DLMS User Association maintains the specifications and groups them in books:
| Book | What it describes |
|---|---|
| Blue Book | The COSEM model and the OBIS identification system |
| Green Book | The DLMS application layer, the lower layers and the communication profiles |
| White Book | The glossary of COSEM terms |
These specifications are adopted in the IEC 62056 family of standards.
COSEM: the meter as a set of objects
COSEM does not describe the meter’s circuit, but what the central system can read and command. Each function of the meter is modeled as an object, and each object belongs to a standardized interface class. The classes form an extensible library: the specification allows up to 65,535 interface classes.
An example helps to understand the idea, without going into the detail of each class:
- A register stores a value with its unit, such as accumulated active energy.
- A load profile stores a series of values by interval, which is the consumption curve.
- A clock stores the meter’s date and time.
- A disconnect control represents the disconnect and reconnect relay.
- An event log stores the facts: cover opening, loss of voltage, configuration changes.
Each object has attributes, which are the data it holds, and methods, which are the actions it accepts. Reading the accumulated energy is reading an attribute. Commanding a disconnect is invoking a method of the disconnect object.
Because the model is the same for everyone, a central system can ask any meter «what objects do you have?» and receive a list it understands.
OBIS: the name of each data item
Each object is identified by an OBIS code. The code has a fixed structure and assigns values to commonly used measurement data. The same code identifies the logical name of an object instance, the data item that travels over the communication line and the data item shown on the meter display.
OBIS is not limited to electricity: its codes also identify gas, water or thermal energy. The codes are controlled by the DLMS User Association, so there are no manufacturer-specific codes for the standardized data.
DLMS: how it is requested and sent
The DLMS layer defines the dialogue. It works with a client-server model:
- Server: the end device, normally the meter.
- Client: the head-end system or the concentrator.
The client opens an association with the server, requests or writes attributes, invokes methods and closes the session. The meter responds. That structure allows the same dialogue to travel over different media: the specification is independent of the communication technology and defines profiles that place it over lower layers. The technologies in AMI communications carry the same DLMS messages.
Security is applied at the application layer: it can apply, verify and remove cryptographic protection when needed. Non-repudiation requirements rely on that capability. The algorithms and levels are taken from the official specifications and from the meter supplier.
- Association. The client introduces itself to the meter and agrees the security level
- Object selection. It is identified by its OBIS code
- Attribute read. The meter returns the value with its unit and timestamp
- Association release. The session ends
- Recording in the system. The data moves on to data management
What to consider when buying or integrating
- Object declaration. Ask for the list of objects and OBIS codes that each meter model implements, and compare it with what the system needs: energy by direction, load profile, events, disconnect control.
- Communication profiles. Check that the meter uses a profile compatible with the chosen network.
- Security. Define the authentication and encryption level and who holds the keys. A meter’s keys must not be the factory ones.
- Interoperability tests. Require tests with the real central system and not only compliance declarations.
- Meter display. Since the same OBIS labels the display, the field technician can compare the local value with the one that reaches the system.
Frequent mistakes
- Assuming «DLMS» is enough. Two meters that claim DLMS/COSEM compliance can implement different objects. What counts is the object list.
- Leaving the default security configuration. A meter with factory keys in production is an open door; see IEC 62351 and industrial cybersecurity IEC 62443 as design criteria.
- Ignoring time. A load profile with drifted time assigns consumption to the wrong intervals.
- Not documenting the OBIS codes used. Years later nobody knows which data item was which.
To go further, see what smart metering is, AMI architecture: meter, concentrator and central system and remote reading, disconnect and reconnect. Reading a meter from a master SCADA, with handshake, password, readout and closing, is described in IEC 61107: Meter Reading Protocol.
How Tiza Group can help
The dialogue between a meter and a central system is integrated like any field protocol: the data map is defined, communication is verified, failure cases are tested and everything is documented. At Tiza Group we work on SCADA and gateway integration and communications engineering, worldwide and remotely. If you need to integrate meters into your system, contact us and we will quote.
Related guides
- Smart metering (AMI): what it is and how it works
- AMI architecture: meter, concentrator and central system
- AMI communications: PLC, RF mesh and cellular
- DNP3 (IEEE 1815)
- IEC 61850 versus IEC 104, DNP3 and Modbus
- IEC 61107: Meter Reading Protocol
References
- IEC 62056 family of standards (electricity metering data exchange): public IEC catalogue, webstore.iec.ch.
- DLMS User Association, Core Specifications, dlms.com/core-specifications: Blue Book, Green Book and White Book.
Frequently asked questions
What do DLMS and COSEM stand for?
DLMS is the message specification: how a system requests data from a meter and how the meter responds. COSEM is the model specification: what objects a meter has and what each one means. Together they are called DLMS/COSEM and are adopted in the IEC 62056 family of standards.
What is an OBIS code?
It is the code that identifies each data item of a meter, such as imported active energy or the voltage of a phase. The code has a fixed structure that assigns values to commonly used measurement data. The same code identifies the data item in communication and on the meter display.
Does a DLMS/COSEM meter from one manufacturer work with another manufacturer's central system?
That is the goal of the standard, but real interoperability depends on which objects and options each manufacturer implements. That is why it pays to require interoperability tests with the central system before buying, in addition to the compliance declaration.