Introduction

When utilities discuss smart meter interoperability, DLMS/COSEM is often one of the first standards mentioned.

It has become an important technology in smart metering, particularly in electricity metering, and is also relevant to smart water.

But an important practical question remains:

Does every smart metering deployment need DLMS/COSEM?

The answer depends on the complete architecture.

Utilities have different meter types, communication technologies, device capabilities, battery constraints, HES and MDMS architectures, operational requirements and long-term strategies.

Other approaches, such as LwM2M, can also play a role in IoT device management and lifecycle control.

The important lesson is therefore not that one protocol is universally better than another.

It is that protocol selection should follow the AMI architecture — not the other way around.

Key Takeaways

• DLMS/COSEM provides a structured framework for representing and exchanging metering information.
• DLMS/COSEM is an application-level framework, not a communication network.
• COSEM objects, OBIS codes and DLMS services are central concepts for understanding how it works.
• Standardization can support multi-vendor interoperability, but supporting the standard does not automatically prove interoperability.
• HES and MDMS architecture remain critical when integrating multiple meter vendors.
• DLMS/COSEM is relevant to smart water, but battery consumption and low-power communication require additional consideration.
• LwM2M has a different emphasis, particularly around lightweight IoT device management and lifecycle control.
• DLMS/COSEM and LwM2M should not automatically be treated as direct substitutes; they can potentially coexist in an architecture.
• Protocol selection should start with data, communication frequency, battery life, device management, HES and MDMS requirements.
• End-to-end testing under realistic conditions is more informative than a standards-compliance statement alone.

What Is DLMS/COSEM?

DLMS stands for Device Language Message Specification.

COSEM stands for Companion Specification for Energy Metering.

DLMS/COSEM provides an international framework for representing and exchanging information between metering devices and systems such as Head-End Systems (HES).

At a high level:

• COSEM defines how meter information and functionality are represented.
• DLMS provides mechanisms for accessing and exchanging that information.

Instead of treating a smart meter as a collection of proprietary registers, the framework provides a structured approach for representing meter data and functions.

This becomes particularly useful when a utility needs to integrate equipment from multiple vendors.

DLMS/COSEM Is Not a Communication Network

One of the most common misunderstandings is to treat DLMS/COSEM as a communication technology.

It is not.

DLMS/COSEM operates at the application level and can work over different communication technologies.

Depending on the architecture, the underlying network could involve:

• Cellular
• NB-IoT
• LTE-M
• RF
• PLC
• Ethernet
• Other communication technologies

A simplified AMI architecture is:

Smart Meter → Communication Network → HES → MDMS → Utility Applications

The communication network transports the information.

DLMS/COSEM defines how metering information and services are represented and exchanged.

This separation matters because the communication technology and application protocol do not necessarily have to change together.

The Three Concepts You Need to Understand

Three concepts are particularly useful when approaching DLMS/COSEM:

1. COSEM objects
2. OBIS codes
3. DLMS services

1. COSEM Objects

COSEM represents meter functionality using objects.

A meter may expose objects representing:

• Energy registers
• Instantaneous values
• Load profiles
• Clock
• Communication settings
• Tariff information
• Event logs
• Security parameters
• Device information

Instead of simply saying that a particular register contains a reading, the system can represent the measurement as a defined object with specific attributes and behaviour.

This structured model becomes increasingly valuable when different manufacturers are involved.

2. OBIS Codes

OBIS stands for Object Identification System.

OBIS provides a standardized way of identifying meter data.

An OBIS identifier can describe characteristics such as:

• What is being measured
• Which measurement channel is involved
• What type of quantity is represented
• How the value is being used

This gives the HES or another client system a structured way of identifying information.

However, utilities should not assume that OBIS codes automatically guarantee interoperability.

Different devices can support different objects, profiles, optional features and manufacturer-specific extensions.

The actual implementation still matters.

3. DLMS Services

DLMS provides mechanisms used by a client to access information from the meter.

In a typical architecture:

Smart Meter = Server

HES = Client

The HES establishes communication with the meter and requests information from relevant COSEM objects.

A simplified sequence can be:

Connect → Authenticate → Request Data → Meter Responds → HES Processes Data

Actual exchanges can become more complex when security, association, block transfers, selective access and different communication profiles are involved.

Why DLMS/COSEM Matters for Interoperability

The major attraction of DLMS/COSEM is standardization.

Without a common approach, a utility could end up with:

Vendor A meter → Proprietary protocol

Vendor B meter → Proprietary protocol

Vendor C meter → Proprietary protocol

The HES would then require separate integrations for each vendor.

With a standardized approach, the architecture can move closer to:

Multiple Meter Vendors → Common Metering Model → HES

This does not eliminate integration work.

It can, however, reduce unnecessary vendor dependency and provide a common framework for exchanging metering information.

For infrastructure expected to operate for 10–15 years or more, that flexibility can be significant.

Standardized Does Not Mean Automatically Interoperable

This is one of the most important practical lessons.

Two vendors can both state that their meters support DLMS/COSEM and still require significant integration work.

Implementations can differ in:

• Supported objects
• Optional features
• Communication profiles
• Security configuration
• Association handling
• Data access methods
• Event handling
• Firmware functionality
• Manufacturer-specific extensions

Therefore:

“Supports DLMS/COSEM” is not the same as “has been proven interoperable with our AMI architecture.”

Utilities should test the actual implementation.

HES Interoperability

The HES becomes particularly important when multiple meter vendors are involved.

A utility may eventually have:

• Different meter manufacturers
• Different meter models
• Different firmware generations
• Different communication technologies
• Different device capabilities

The HES needs to manage this complexity without creating a separate operational silo for every vendor.

Utilities should therefore ask:

• Can the HES support multiple meter vendors?
• Can it manage different device models?
• Can it maintain different configurations?
• Can it handle different supported object sets?
• Can it expose consistent data to the MDMS?
• Can it accommodate future device technologies?

MDMS Interoperability

The MDMS introduces another important layer.

Different meters may produce information in different structures, even when they use the same underlying standard.

The MDMS needs to transform this information into a consistent representation that downstream systems can use.

A simplified architecture might look like:

Meter A / Meter B / Meter C → HES → MDMS → Common Data Representation → Billing / Analytics / Operations

Ideally, downstream applications should not need to know which manufacturer produced the meter.

They should consume consistent information.

This abstraction is one of the valuable outcomes of a well-designed AMI architecture.

DLMS/COSEM and Smart Water

Although COSEM includes “Energy Metering” in its name, the DLMS/COSEM framework can also be relevant to smart water metering.

Water meters may need to expose information such as:

• Cumulative consumption
• Flow information
• Reverse flow
• Leak indicators
• Valve status
• Battery status
• Events
• Diagnostics
• Device configuration

A standardized data model can help utilities integrate different meter manufacturers into a common AMI environment.

However, smart water introduces additional considerations.

Unlike many electricity meters, smart water meters are frequently:

• Battery powered
• Installed underground
• Expected to operate for many years
• Connected using low-power communication
• Required to transmit relatively small amounts of data

The protocol implementation therefore needs to be considered together with the meter's energy budget.

DLMS/COSEM and Low-Power Communication

DLMS/COSEM does not require a high-bandwidth network.

The application protocol can be carried over different communication technologies, including architectures involving:

• NB-IoT
• LTE-M
• RF
• PLC
• Other low-power or wireless technologies

However, application-level compatibility does not automatically guarantee good field performance.

A protocol may work well in laboratory conditions but behave differently when the meter is:

• Underground
• In a poor coverage area
• Operating with a weak signal
• Experiencing repeated communication retries
• Running on a limited battery budget

Protocol evaluation should therefore include realistic deployment conditions.

The Hidden Challenge: Battery Consumption

For mains-powered equipment, additional communication exchanges may have relatively little impact on operating cost.

For a battery-powered smart water meter, the situation is different.

Every communication event consumes energy.

Additional exchanges may result from:

• Authentication
• Session establishment
• Data requests
• Retries
• Diagnostics
• Configuration changes
• Remote commands
• Firmware management

Across a single transaction, the difference may appear insignificant.

Across thousands of transactions over many years, it can become important.

The question should therefore not simply be:

“Does the meter support DLMS/COSEM?”

It should also be:

“What is the energy impact of the actual implementation?”

DLMS/COSEM vs LwM2M

LwM2M, or Lightweight Machine-to-Machine, is an IoT device-management framework designed around lightweight communication and device lifecycle management.

It has a different emphasis from DLMS/COSEM.

DLMS/COSEM

Its strengths include:

• Standardized metering data models
• Structured meter objects
• Data identification
• Metering services
• Multi-vendor metering interoperability
• Utility-oriented data exchange

LwM2M

Its strengths include:

• Device management
• Device provisioning
• Remote configuration
• Monitoring
• Firmware management
• Lightweight IoT communication
• Resource-oriented device models

This leads to an important distinction:

DLMS/COSEM is strongly metering-oriented, while LwM2M is strongly device-management and IoT-oriented.

They should therefore not automatically be treated as direct substitutes.

Could DLMS/COSEM and LwM2M Coexist?

Yes.

A modern IoT architecture does not necessarily need one technology to perform every function.

Different layers can use different mechanisms.

For example, one approach could provide standardized meter data representation while another provides device lifecycle management.

A simplified architecture might be:

Meter → Communication Layer → Device Management / Application Layer → HES → MDMS → Utility Applications

The exact architecture depends on the deployment.

The key lesson is:

Do not force one protocol to solve every problem.

Why Different Utilities Make Different Choices

Utilities can make different protocol decisions because their requirements are different.

Relevant factors include:

• Existing AMI infrastructure
• Meter type
• Communication technology
• Device processing capability
• Battery constraints
• HES architecture
• MDMS architecture
• Regulatory requirements
• Cybersecurity requirements
• Device-management requirements
• Vendor ecosystem
• Long-term lifecycle strategy

A protocol that fits one deployment well may be unnecessarily complex — or insufficient — for another.

This is why copying another utility's technology stack without understanding its architecture can be risky.

Don't Choose the Protocol First

One of the common mistakes in AMI procurement is starting with the protocol.

A better approach is to start with requirements.

What data do we actually need?

• Daily consumption?
• Hourly consumption?
• Interval data?
• Events?
• Diagnostics?
• Leak information?

How frequently must the meter communicate?

• Once per day?
• Several times per day?
• On demand?
• Near real time?

What is the battery-life requirement?

• Five years?
• Ten years?
• Fifteen years?

What device-management capabilities are required?

• Configuration?
• Diagnostics?
• Firmware updates?
• Remote commands?

What must the HES support?

• Multiple meter vendors?
• Multiple communication technologies?
• Large-scale device management?

What must the MDMS receive?

• Raw readings?
• Validated data?
• Events?
• Profiles?
• Diagnostics?

Only after these questions are answered should protocol selection become clearer.

Testing Matters More Than the Specification

A protocol specification can describe what should happen.

A field test shows what actually happens.

A proper interoperability programme should test:

Meter → Network → HES → MDMS

under realistic conditions.

Testing should include:

• Normal data collection
• Missing communication
• Retries
• Duplicate messages
• Delayed messages
• Incorrect timestamps
• Device resets
• Configuration changes
• Security failures
• Firmware updates
• Meter replacement

The failure cases are particularly important.

A system that works only when everything is perfect is not necessarily ready for a large-scale AMI deployment.

What Utilities Should Ask Vendors

Which DLMS/COSEM Features Are Supported?

Request the actual implementation details rather than relying only on a general compliance statement.

Which Objects and OBIS Codes Are Available?

Do not assume the standard automatically provides every function required by the project.

Which Communication Profiles Are Supported?

This matters when using cellular, RF, PLC or other communication technologies.

What Security Mechanisms Are Implemented?

Understand authentication, encryption, key management and access levels.

How Has Interoperability Been Tested?

Ask for actual evidence rather than relying only on documentation.

How Does the Meter Behave Under Poor Communication Conditions?

This is particularly important for low-power deployments.

What Is the Impact on Battery Life?

Evaluate the complete communication process rather than the protocol name alone.

How Are Firmware Updates Handled?

Device lifecycle management should be considered from the beginning.

Can the HES Manage Multiple Vendors?

This connects directly to the interoperability strategy discussed in Article #24.

A Practical Comparison

The comparison between DLMS/COSEM and LwM2M is not about declaring one technology the winner.

They have different strengths and address different architectural requirements.

The appropriate choice depends on the complete system architecture, including the meter, communication network, HES, MDMS, device-management requirements and lifecycle strategy.

Practical Lessons From AMI Deployments

1. Standards Do Not Eliminate Engineering

A standard provides a framework. The implementation determines real-world performance.

2. Interoperability Must Be Demonstrated

A compliance statement is not a substitute for end-to-end testing.

3. Protocol Choice Should Follow Architecture

Do not select a protocol simply because it is widely used elsewhere.

4. Low-Power Devices Need Special Consideration

A protocol implementation that works well in a mains-powered device may require careful optimization in a battery-powered smart water meter.

5. Device Management Is Becoming Increasingly Important

Modern AMI is moving beyond simple meter reading toward:

• Remote configuration
• Diagnostics
• Firmware management
• Device monitoring
• Richer data services

6. Different Deployment Environments Can Justify Different Technologies

There is no universal AMI architecture.

The appropriate solution depends on the meter, network, HES, MDMS, operational requirements and lifecycle strategy.

7. Future Flexibility Matters

A protocol decision made today can influence a utility's ability to introduce new meter vendors, communication technologies and software platforms years later.

The Real Question Is Not “Which Protocol?”

The better question is:

“What do we need the meter and AMI platform to do over the next 10–15 years?”

If the primary requirement is standardized metering data exchange across multiple vendors, DLMS/COSEM can be attractive.

If the architecture places greater emphasis on lightweight IoT device management, remote lifecycle control and broader IoT integration, LwM2M may be attractive.

In some architectures, different technologies may also coexist.

The decision should therefore be based on:

Meter + Communication + HES + MDMS + Security + Operations + Lifecycle

—not on the protocol name alone.

Conclusion

DLMS/COSEM remains an important technology for standardized smart-meter data exchange.

Its structured object model, data identification mechanisms, application services and support for different communication profiles make it useful for multi-vendor utility environments.

But the practical lesson is not that every utility should choose DLMS/COSEM.

The comparison with LwM2M demonstrates something more important: different technologies can solve different architectural problems.

For smart water in particular, utilities need to consider not only interoperability and functionality, but also:

• Battery life
• Communication efficiency
• Device-management requirements
• Firmware lifecycle
• HES integration
• MDMS integration
• Security
• Long-term maintainability

The most suitable protocol is the one that fits the meter, communication network, HES, MDMS, security architecture, operational model and long-term business requirements as one system.

Don't choose the protocol first. Design the architecture first — and then choose the protocol that fits it.

Related Smart Metering Topics

• Interoperability in Multi-Vendor AMI Systems
• Head-End Systems (HES) Explained: The Communication Hub of AMI
• Meter Data Management Systems (MDMS) Explained: Turning Data into Information
• Smart Metering System Architecture: End-to-End Design for Utilities
• NB-IoT vs LoRaWAN in Real Deployments: What Actually Happens in the Field
• NB-IoT vs LoRaWAN vs LTE-M: Choosing the Right IoT Connectivity for Smart Utilities
• Firmware Management in AMI: The Hidden Operational Challenge
• Smart Meter Battery Life Explained: Why “10 Years” Is Not Just a Specification