DLMS/COSEM and IEC 62056: The Complete Guide to Smart Meter Data

What you’ll learn: This guide covers the full DLMS/COSEM technology stack — from the conceptual object model through OBIS identification codes, transport layer options, security mechanisms, and certification pathways. You will understand how IEC 62056 parts map to real implementation decisions, how DLMS/COSEM compares with competing standards, and what you need to specify, procure, or test a conformant smart metering system. Written for utility engineers, AMI architects, and product managers working on electricity, gas, water, and heat metering.

1. Why a Universal Meter Data Standard Matters

Before DLMS/COSEM, every meter manufacturer invented its own data model. A utility deploying three vendors’ meters needed three distinct head-end integrations, three sets of decoder libraries, and three maintenance contracts. Interoperability was theoretical; lock-in was structural.

The Device Language Message Specification / Companion Specification for Energy Metering (DLMS/COSEM) solves this by defining a single, internationally standardised way for meters to model, identify, and exchange data. It underpins IEC 62056, the family of standards that has become the de-facto global framework for smart meter communication. Today it is deployed in hundreds of millions of meters across Europe, Asia, Latin America, Australia, and beyond.

For a high-level orientation before diving into the technical layers, see DLMS/COSEM Explained: The Global Standard for Smart Meter Communication.

2. The IEC 62056 Standard Family: A Structural Map

IEC 62056 is not a single document but a multi-part series maintained by IEC Technical Committee 13. Understanding which part does what is essential before specifying a system.

2.1 Core Parts Overview

For a complete walkthrough of every part in the series, see IEC 62056 Series Explained: The Complete Guide to Every Part.

2.2 IEC 62056-21: The Optical Port Legacy

IEC 62056-21 deserves special mention because it predates the full DLMS/COSEM stack yet remains embedded in a massive installed base. It defines the physical optical interface (typically an IEC 61107-style probe), baud-rate negotiation, and five communication modes (A through E). Mode E is the gateway to full DLMS/COSEM over the optical port. Modes A–D are simpler ASCII-based exchanges still used for configuration and local readout. Hundreds of millions of meters deployed before 2015 rely on this interface for field maintenance. IEC 62056-21: The Optical Port Standard That Still Powers Millions of Meters provides the full technical breakdown.

3. The COSEM Object Model: Architecture Deep Dive

COSEM is an object-oriented data model. Everything a meter knows — an energy register, a load profile, a tariff schedule, a clock, a disconnect relay — is modelled as an instance of a defined interface class. This abstraction is what makes interoperability possible.

3.1 Interface Classes

Each interface class specifies:

• Attributes — readable/writeable data items (e.g., the current value of an energy register)
• Methods — executable actions (e.g., reset a maximum demand, execute a disconnection)
• Class ID — a 16-bit integer uniquely identifying the class in the IEC 62056-6-2 registry
• Version — revision number for backward-compatibility management

Key interface classes used in almost every electricity meter deployment:

3.2 Logical Devices and Physical Devices

A single physical meter may host multiple logical devices. This is critical for multi-utility meters (electricity + gas + water) or multi-tenant scenarios. Each logical device has its own address and its own set of COSEM objects. The management logical device (address 1) always exists and controls access to other logical devices.

3.3 Associations and Access Control

Communication between a client (HES or handheld) and a server (meter) is always in the context of an application association. Each association has:

• A defined client address (e.g., public client = 16, management client = 1)
• An authentication level: None, Low Level Security (LLS — shared password), or High Level Security (HLS — challenge-response)
• An access rights profile that grants or restricts GET/SET/ACTION on individual attributes and methods

4. OBIS: The Universal Measurand Identification System

Every COSEM object instance is identified by a six-octet logical name — its OBIS code. OBIS (Object Identification System) is defined in IEC 62056-6-1 and provides unambiguous identification of any energy, demand, power quality, or configuration value across any meter type.

4.1 OBIS Code Structure

The six value groups are denoted A–F:

Example: 1.0.1.8.0.255 — electricity (A=1), no channel (B=0), active energy (C=1), time integral 1 / cumulative (D=8), total tariff (E=0), current value (F=255) = Total active energy import, current billing period.

For a complete lookup reference including power quality, reactive, and multi-phase codes, see the OBIS Code Reference Guide: Every Metering Engineer’s Cheat Sheet.

5. DLMS: The Communication Protocol Layer

DLMS is the protocol that serialises COSEM object access requests and responses. It is derived from ISO/IEC 15954 (Manufacturing Message Specification) and adapted for metering. The protocol stack has distinct layers.

5.1 Application Layer: xDLMS Services

The core services defined in IEC 62056-5-3:

• GET — read one or more attributes; supports selective access (date range, entry range, conditional)
• SET — write an attribute value
• ACTION — invoke a method
• GET-WITH-LIST / SET-WITH-LIST — batch read/write, reduces round trips significantly
• PUSH (Notification) — meter-initiated data transmission, configured via the Push Setup object (class 40)
• AARQ / AARE — association request/response for session establishment
• RLRQ / RLRE — association release

5.2 Data Encoding: ASN.1 and AXDR

DLMS data is encoded using A-XDR (Adapted eXternal Data Representation), a simplified subset of ASN.1 BER. Each data item is tagged with a type byte:

• 0x09 = octet-string
• 0x0A = visible-string
• 0x12 = unsigned16
• 0x06 = unsigned32 (double-long-unsigned)
• 0x01 = array
• 0x02 = structure

Understanding the type-length-value (TLV) encoding is essential for writing DLMS parsers or debugging hex captures from optical port or PLC traces.

5.3 Transport Layers

DLMS/COSEM is transport-agnostic. The same APDU sits on top of multiple lower layers:

For the two dominant PLC physical layers, the technical trade-offs are analysed in G3-PLC vs PRIME: Which Powerline Standard Wins for Smart Metering? and the deployment landscape in PRIME vs G3-PLC: The Two Powerline Standards Fighting for Smart Grid Dominance.

For wireless sub-GHz communication serving gas, water, and heat sub-meters, see Wireless M-Bus (EN 13757): The European Standard for Heat and Water Meter Wireless Communication.

6. Security in DLMS/COSEM

Security is not an add-on; it is architecturally integrated into DLMS/COSEM through the General Ciphering and General Signing mechanisms defined in IEC 62056-5-3 and IEC 62056-8-3.

6.1 Security Suite Architecture

Three Security Suites are defined:

• Suite 0 — AES-128-GCM for authenticated encryption; GMAC for authentication-only
• Suite 1 — AES-256-GCM (for deployments requiring higher key strength)
• Suite 2 — Elliptic Curve (ECDSA, ECDH) for asymmetric key establishment and digital signatures

6.2 Key Hierarchy

• Global Encryption Key (GEK) — symmetric key for encrypting data exchanged over the network
• Authentication Key (AK) — used for GMAC-only (integrity without confidentiality)
• Unicast Encryption Key (UEK) — per-association derived key
• Master Key (MK) — used exclusively for wrapping/unwrapping the GEK during key update
• Invocation Counter (IC) — 32-bit counter per security context; protects against replay attacks; must never repeat

The invocation counter is one of the most operationally sensitive parameters. If a meter’s flash is corrupted and the IC rolls back after firmware recovery, replayed frames could be accepted. Conformant implementations persist the IC to non-volatile memory with redundancy.

6.3 Higher-Layer Security Integration

IEC 62056 security operates at the application layer. It can and should be combined with transport-layer security (TLS 1.2/1.3 for TCP/IP deployments). IEC 62351 specifies the broader security framework for power system communication and applies directly to smart metering infrastructure. The interaction between IEC 62056 application-layer security and IEC 62351 is detailed in IEC 62351: Cybersecurity Standards for Power Systems and Smart Metering.

7. Profile Generic: Load Profiles and Interval Data

The Profile Generic interface class (class ID 7) is the workhorse of AMI data collection. It is a generalised time-series container.

7.1 Key Attributes of Profile Generic

• Capture objects (attribute 3): The ordered list of COSEM object attributes that are captured into each entry. Typically: clock timestamp, energy import, energy export, reactive energy, power quality flags.
• Capture period (attribute 4): Interval in seconds (e.g., 900 = 15-minute intervals).
• Sort method (attribute 5): How entries are ordered (FIFO, LIFO, nearest, etc.).
• Buffer (attribute 2): The actual stored data, readable with selective access.
• Entries in use (attribute 7): Number of filled rows — essential for partial reads.

7.2 Selective Access

Rather than downloading the entire buffer on every read cycle, a HES uses selective access to request entries by:

• Range descriptor: FROM timestamp TO timestamp (most common for incremental reads)
• Entry descriptor: FROM entry-index TO entry-index (useful when time-sync is uncertain)

Correct implementation of selective access is critical for AMI scalability. A head-end reading 500,000 meters every 15 minutes that fetches full buffers instead of deltas will saturate any communication network.

8. DLMS/COSEM for Multi-Utility and Non-Electricity Metering

DLMS/COSEM is explicitly designed for gas, water, and heat metering, not just electricity. The OBIS A-group code identifies the medium. Gas meters (A=7) and water meters (A=8) use volume registers and flow profiles. Heat meters (A=6) use energy, volume, and temperature differential registers.

The DLMS User Association maintains medium-specific COSEM profiles. For heat metering specifically, the interface with EN 1434 accuracy classes creates distinct measurement requirements — see EN 1434: The Standard for Heat Meters — Accuracy, Classes, and Compliance.

A notable consumer-side implementation of DLMS/COSEM for electricity is the Dutch DSMR P1 port. The P1 port exposes a local DSMR-formatted telegram — but in later generations it references COSEM objects and OBIS codes directly. Full technical detail at DSMR P1 Port Standard: How Dutch Smart Meters Share Data With Your Home.

9. DLMS/COSEM vs Competing Standards

9.1 DLMS/COSEM vs ANSI C12

North America uses a parallel but distinct standards family: ANSI C12.19 (data model), C12.18 (optical port), and C12.22 (network communication). The ANSI model uses a table-based structure rather than an object-oriented interface class model. Both achieve interoperability within their respective ecosystems; the choice is almost entirely determined by geography and regulatory mandate. A detailed technical comparison is at ANSI C12.19 vs DLMS/COSEM: The North American vs European Meter Data Standard. For the complete ANSI family, see ANSI C12 Standards Suite: The Complete Guide for North American Metering.

9.2 Summary Comparison Table

10. Certification and the DLMS User Association

The DLMS User Association (DLMS UA) is the industry body that governs the specification, maintains the Green Book and Blue Book, and operates a conformance testing program. Certification matters for three practical reasons:

1. Procurement protection: A certified meter has passed structured conformance tests, reducing integration risk when deploying multi-vendor AMI.
2. Regulatory compliance: Several European national mandates (including MID-based rollouts) effectively require DLMS/COSEM conformance.
3. Long-term interoperability: Certified devices carry version-tagged interface class support, enabling head-end upgrades without meter replacements.

The testing program, certification tiers, and what the Green Book and Blue Book actually contain are covered in depth at The DLMS User Association: What It Does and Why Certification Matters.

11. Metrological and Legal Compliance Context

DLMS/COSEM governs data communication. It does not specify metrological accuracy — that is the domain of separate standards. Utilities must ensure their meters comply with both layers:

• EU Measuring Instruments Directive (2014/32/EU — MID): Annex MI-003 specifies accuracy requirements for electricity meters deployed for billing purposes across EU member states.
• OIML R 46: The international recommendation for active electrical energy meters, widely referenced outside the EU. Detailed at OIML R 46: The International Standard for Active Electrical Energy Meters.
• IEC 62053 series: Accuracy class specifications for electricity meters (classes 0.1S through 2 for active energy; classes 0.5S through 3 for reactive energy).
• WELMEC guides: WELMEC publishes application guides for MID conformity assessment, including guides specifically for software-heavy smart meters where DLMS/COSEM firmware is part of the legal measuring instrument scope.

Metrological parameters — energy register values, timestamps, status flags — are typically placed in the meter’s “sealed” software partition. Access control through DLMS/COSEM associations must be configured such that management clients cannot write to metrology-class objects without breaking the metrological seal.

12. Implementation Guidance: Common Pitfalls

12.1 Invocation Counter Management

Frequently Asked Questions

What is the difference between IEC 62056-3-1 and IEC 62056-3-2 in terms of transport layer implementation?

IEC 62056-3-1 defines HDLC framing for local area network connections (optical/RS-485), while IEC 62056-3-2 specifies the WRAPPER protocol for IP-based transport over TCP-UDP networks. The choice depends on whether your deployment uses direct meter connections or networked IP infrastructure.

Why do utilities still need to support IEC 62056-21 optical port modes A through E if DLMS/COSEM is the modern standard?

Hundreds of millions of meters deployed before 2015 rely on IEC 62056-21 for field maintenance and local readout, making it essential for legacy system support even though Mode E provides the gateway to full DLMS/COSEM over the optical port. Utilities must maintain backward compatibility across their installed base.

What is the functional difference between OBIS identification codes (IEC 62056-6-1) and COSEM interface classes (IEC 62056-6-2)?

OBIS codes provide the hierarchical code structure that uniquely identifies all measurands in a meter, while COSEM interface classes define the object model architecture and normative registry for how those measurands are structured and accessed. Together they form the data identification and modeling foundation of the COSEM standard.

How do broadband PLC transport options in IEC 62056-4-32 compare to narrowband PLC in IEC 62056-4-7 for last-mile smart meter connectivity?

IEC 62056-4-32 uses OFDM-based broadband PLC (G3-PLC, PRIME) for higher bandwidth applications, while IEC 62056-4-7 specifies narrowband S-FSK PLC (IEC 61334) for lower-bandwidth, longer-range deployments; the choice depends on your distribution network topology and data throughput requirements.

Which IEC 62056 part should I reference when specifying the complete end-to-end meter communication system architecture?

IEC 62056-8-3, the Companion Specification for Energy Metering (COSEM), ties together the individual parts and provides profile-level specification guidance for implementing a conformant system across object model, transport, and security layers.

Was this article helpful?
👍 Yes
👎 No