Understanding DLMS/COSEM From Meter Data to Standardized Communication
A practical view from studying the DLMS/COSEM Colored Books
Smart meters are often described as devices that measure and transmit energy consumption. But while studying DLMS/COSEM, I realized that behind a simple meter reading there is a complete structure that defines what the data means, how it is identified, how it is exchanged, and how we can verify that different implementations follow the same rules.
This is where DLMS/COSEM becomes important. It provides a standardized way for smart meters and other devices to represent and exchange information and supports interoperability between devices and systems from different manufacturers.
After studying the DLMS/COSEM Colored Books, I found it more useful to think of the standard not as one single protocol, but as a set of connected concepts. Each part answers a different question, and together they form the complete picture.
Why Do We Need DLMS/ COSEM ?
Imagine a utility company managing several million meters sourced from a handful of different manufacturers. Every meter measures broadly similar parameters:
- Active and reactive energy
- Voltage and current fluctuations
- Power quality and load profiles
- Billing data, events, and system alarms
Without a shared standard, a utility’s head-end system would need a custom integration for every meter brand it deploys, and every firmware update would risk breaking that integration again. DLMS/COSEM solves this by introducing a standardized model for describing meter information and standardized mechanisms for accessing it.
The underlying idea is simple to state but harder to build:
the communication system should understand what the data represents, not just how it is transmitted.
Decoding the Framework: The Four Colored Books
The specification is split across four core documents known as the “Colored Books,” which fit together as a family of connected concepts:
Book
What It Does for the Grid
Now in its 18th edition, it treats a meter as a collection of COSEM objects and defines OBIS codes—hierarchical identifiers that describe data independent of a manufacturer’s naming conventions.
Now in its 12th edition, it answers how data is exchanged by defining the application layer and communication profiles using a client-server model.
Defines the conformance testing and certification process. Infinity Egypt supports this phase by supplying advanced ZERA meter testing solutions.
Provides a shared glossary of terms to prevent terminology drift and ensure engineering teams communicate effectively across the board.
Stay Updated
Subscribe to receive selected company announcements, product developments, technical insights, training updates and industry news from the energy-measurement sector.
DLMS and COSEM – Two Concepts That Work Together
The names DLMS and COSEM are usually mentioned together, but they have different roles.
DLMS stands for Device Language Message Specification. It is related to the services and language used to exchange information between devices.
COSEM provides the object-oriented model used to represent the functions and information available in a device.
A simple way I found to remember the difference is:
COSEM describes the information.
DLMS defines how that information is exchanged.
This distinction becomes much easier to understand when looking at the Blue and Green Books together.
The Blue Book: What Does the Meter Contain?
The Blue Book focuses on the COSEM and OBIS application models. One point that became clear to me while studying it is that a meter is not treated simply as a group of raw values.
Instead, the meter’s functions and information are represented using COSEM objects. So, rather than saying that a meter contains a number representing energy, we can think of it as containing an object representing a specific energy measurement, with defined attributes and methods.
This object-oriented approach gives the data a clear structure and makes it easier to identify.
The idea is also important from an interoperability point of view. The Head-End System does not need to know the internal software structure of each meter. It only needs to understand the standardized interface.
COSEM Interface Classes
COSEM objects are based on interface classes. An interface class defines the standardized structure of a particular type of functionality and specifies the attributes and methods that an object can have.
Attributes can contain values or information, while methods allow specific operations to be performed.
This creates a common structure that manufacturers can implement in their own products. From a system point of view, this means that the Head-End System can work with the standardized interface instead of depending on the internal implementation of each meter.
This is one of the main reasons I see the object-oriented model as an important part of interoperability.
OBIS: How Do We Know What the Data Represents?
After understanding the object model, the next question for me was: how do we know exactly what a specific object or value represents?
This is where OBIS becomes important.
OBIS, or Object Identification System, provides a structured way to identify data and COSEM objects. The different parts of an OBIS identifier provide information about what the object represents, such as the type of energy or resource, measurement channel, physical quantity, processing method, tariff, and other information.
At first, OBIS codes can look like a long sequence of numbers. However, I think the more important point is not memorizing the numbers. It is understanding that an OBIS code gives meaning and identity to the data.
This allows a client system to request a specific piece of information without depending on the manufacturer’s internal naming convention.
From Data Modeling to Communication
Once we know what information exists in the meter and how it is modeled, another question comes up: how does the client actually communicate with the meter?
This is where the Green Book becomes important. It covers the DLMS application layer, lower layers, and communication profiles.
A simple way I use to separate the two concepts is:
Blue Book: What is the data?
Green Book: How do we exchange it?
This separation makes the relationship between the data model and the communication part much easier to understand.
The Client–Server Model
DLMS/COSEM commonly uses a client-server communication model.
In a typical smart metering system, the meter acts as the server, while the Head-End System or another communication device acts as the client. The client sends a request, the meter processes it, and then the meter returns a response.
Conceptually, a simple reading operation can be represented as:
Client → Request → COSEM Object/Attribute → Meter Processing → Response → Client
The actual communication process is more detailed, but this simple sequence helped me understand the overall idea.
The client is not simply asking the meter to send some bytes. It is requesting a defined piece of information through a standardized application model.
Reading Data Is More Than Sending a Number
For example, imagine that a system wants to read an energy value from a smart meter. Before that can happen, several things need to be defined:
- Which object represents the measurement?
2. How is that object identified?
3. Which attribute contains the required value?
4. How is the request represented?
5. How should the meter respond?
6. Which communication profile carries the message?
This is why I would not describe DLMS/COSEM as just a simple communication protocol. There is a complete chain behind a data reading:
Identification → Data Model → Application Service → Communication → Response
Each part has its own role.
The Green Book and Communication Profiles
Another important point is that DLMS/COSEM is not limited to one physical communication medium.
The same application-level information can be exchanged over different communication technologies by using the appropriate communication profile. This is especially useful in smart metering because the communication environment can be different from one deployment to another.
Depending on the application, a meter may communicate through optical communication, HDLC-based communication, TCP/IP-based communication, cellular networks, or other supported profiles.
For me, this separation between the application model and the communication medium is one of the reasons DLMS/COSEM can be applied across different smart metering infrastructures.
Association and Access to the Meter
Before a client can access the meter’s objects, a communication context needs to be established. This is where the concept of an association becomes important.
An association can be viewed as the relationship established between the client and the server that defines how they communicate and what can be accessed.
Depending on the configuration and security requirements, authentication and other security mechanisms can also be involved.
This is important because smart meters are no longer isolated measuring devices. They exchange information remotely, and some of this information can be operationally or commercially sensitive. Therefore, interoperability alone is not enough; controlled access and appropriate security mechanisms are also required.
Why Security Matters
As smart meters become part of larger infrastructures, information is exchanged remotely and regularly. This introduces security requirements such as authentication, access control, data protection, secure communication, and protection against unauthorized access.
One point I found important is that security should not be considered completely separately from the communication model. It needs to be considered as part of the overall system design.
The Yellow Book: How Do We Know It Really Works?
At this stage, another practical question comes to mind: if a manufacturer says that a device supports DLMS/COSEM, how can we verify that it actually conforms to the relevant specifications?
This is where the Yellow Book becomes important. It deals with DLMS/COSEM conformance testing and certification and provides a structured way to evaluate implementations.
For real projects, this is very important. A standard only becomes useful when different implementations actually follow it. Testing provides the link between saying “we implemented the standard” and being able to demonstrate that the implementation conforms to it.
The DLMS User Association qualification process evaluates products against the core specifications, with compliance certification based on the Blue and Green Books.
Compliance Is Not the Same as Interoperability
There is also an important distinction between compliance and interoperability.
A device may implement the required DLMS/COSEM functionality and pass the relevant compliance requirements. However, in a real project, specific application profiles and system requirements can determine whether two devices will actually work together in the intended use case.
That is why certification and compatibility mechanisms are important, especially in large-scale smart metering systems.
The objective is not only to have devices that individually follow a standard, but to have an ecosystem where different devices and systems can communicate reliably.
The White Book: Understanding the Language
The fourth book is the White Book, which provides the COSEM glossary of terms.
At first, a glossary may seem less important than protocols, communication, or object models. But while working through the different concepts, I found that terminology is actually very important.
If two engineers use the same term but understand it differently, the implementation can become inconsistent even if both have strong technical knowledge.
The White Book therefore provides a common language for the concepts used throughout the DLMS/COSEM specifications.
This is also why I think the four Colored Books should not be studied as four separate documents. They complement each other.
Putting the Four Books Together
A simple way I use to remember the relationship between the Colored Books is to think about the question each one answers:
🔵 Blue Book — What is the data and how is it modeled?
🟢 Green Book — How is the information exchanged?
🟡 Yellow Book — How do we verify conformance?
⚪ White Book — What do the technical terms mean?
Together, they give a much more complete picture of DLMS/COSEM.
The Blue Book gives us the data model.
The Green Book gives us the communication mechanisms.
The Yellow Book gives us the testing and qualification perspective.
The White Book gives us the common terminology.
A Practical Way to Think About DLMS
For me, the easiest way to understand DLMS/COSEM is to imagine a conversation between a smart meter and a monitoring system.
The monitoring system needs a specific measurement. First, it needs to know what information it is looking for. That information is represented through the COSEM object model and identified using mechanisms such as OBIS.
Then, the client needs a standardized way to request the information. This is where DLMS application services and the communication architecture become relevant.
The meter processes the request and returns the requested information. Finally, testing and certification provide confidence that the implementation follows the expected rules.
I like to simplify the whole journey as:
What? → Where? → How? → Is it compliant?
Or, more technically:
COSEM Model → OBIS Identification → DLMS Services & Communication → Conformance Testing
For me, this is much easier to understand than trying to memorize individual definitions.
Why DLMS/COSEM Is Important for Smart Metering
The value of DLMS/COSEM is not only in reading electricity consumption. Its bigger value is in creating a standardized framework for exchanging information.
As smart grids and smart metering systems become more advanced, meters are expected to provide much more than a single cumulative energy value. They may provide load profile information, tariff-related data, power quality information, events and alarms, communication and device management information, configuration data, and historical measurements.
Managing all of this information requires a structured and scalable approach. This is where the object-oriented data model, standardized identification, application services, communication profiles, and conformance testing become valuable together.
DLMS/COSEM has also expanded beyond traditional electricity metering and can be applied to areas such as water, gas, and other smart management and monitoring applications.
Looking Ahead: How DLMS/COSEM Is Evolving
The smart metering landscape is evolving rapidly, and DLMS/COSEM is continuing to develop to address new communication, interoperability, and security requirements.
Advanced Cybersecurity & Cryptography: As smart meters become part of remotely accessible infrastructure, interoperability alone is not enough. Strong security mechanisms are also required. DLMS/COSEM includes advanced cryptographic mechanisms such as AES-GCM and elliptic-curve-based key agreement. Looking further ahead, the DLMS User Association has also published a position paper on the transition toward post-quantum cryptography, highlighting the need to prepare smart metering infrastructure for long-term security requirements.
Expanding Communication Networks: DLMS/COSEM is not limited to traditional metering communication technologies. The standard supports communication over a growing range of technologies, including Wi-SUN, LoRaWAN, and NB-IoT. This allows the same standardized DLMS/COSEM data model and application approach to be used across different communication environments and emerging smart-device applications.
The ACESM GCP Compatibility Program: One important lesson from smart metering deployments is that compliance with a standard does not automatically guarantee that two specific devices will work together seamlessly in every real-world scenario. To address this gap, the DLMS User Association launched the ACESM GCP Compatibility Qualification Program in 2026. The program provides a structured way to verify compatibility and interoperability between DLMS-based smart metering solutions from different manufacturers. The latest ACESM GCP release is Edition 1.1.1.
Expanding Horizons: Egypt's National Energy Transformation
Egypt’s smart metering landscape is evolving as part of the country’s broader efforts to modernize its electricity infrastructure. The Ministry of Electricity and Renewable Energy has been implementing a large-scale program to replace around 38 million traditional electricity meters with smart prepaid meters. By mid-2025, approximately 12 million smart meters had been installed.
Recent developments also show how smart metering is becoming increasingly connected to centralized digital systems. In June 2026, the Egyptian Electricity Holding Company (EEHC) signed a protocol with e& Egypt to deploy smart meters at e& sites nationwide and integrate them with EEHC’s centralized Meter Data Management (MDM) and Unified Head-End System (UHES) platforms. The integration is intended to support reliable data collection, consumption analysis, fault detection, and more efficient meter and billing management.
From a DLMS/COSEM perspective, developments like these highlight the importance of standardized and vendor-independent data exchange. This is particularly relevant in large-scale metering environments where meters, communication systems, and head-end platforms may come from different manufacturers. In fact, DLMS/COSEM is already part of EEHC’s smart-meter technical requirements through the IEC 62056 framework.
Looking ahead, the role of standardized data exchange is likely to extend beyond traditional meter reading. The DLMS User Association is already developing standardized solutions for areas such as electric-vehicle charging, distributed energy resources, energy flexibility, storage, and remote sensing. For example, the Electric Vehicle Charging Station GCP addresses use cases such as dynamic power management, overload protection, and peak shaving.
Conclusion
When I first came across DLMS/COSEM, it seemed complicated because it brings together object classes, identifiers, services, communication layers, security mechanisms, and testing.
After going through the Colored Books, I found that the relationship between these concepts makes the standard much easier to understand.
The Blue Book helps explain how information inside a device is modeled and identified.
The Green Book explains how that information can be exchanged through standardized communication mechanisms.
The Yellow Book provides the testing perspective needed to verify conformance.
The White Book provides the terminology needed to understand the language of the standard consistently.
The main takeaway for me is that DLMS/COSEM is not simply about reading data from a meter. It is about creating a common way for devices to represent information, identify it, exchange it, control access to it, and verify that implementations follow the same rules.
That is what makes DLMS/COSEM an important foundation for interoperable smart metering and modern energy data exchange.
References & Further Reading
- DLMS User Association, DLMS UA Specifications – Blue Book: COSEM and OBIS Application Models.
- DLMS User Association, DLMS UA Specifications – Green Book: DLMS/COSEM Architecture and Protocols.
- DLMS User Association, DLMS/COSEM Conformance Test and Certification Process – Yellow Book.
- DLMS User Association, COSEM Glossary of Terms – White Book.
- DLMS User Association, Core Specifications and Qualification Documentation.