The DLMS User Association: What It Does and Why Certification Matters

The DLMS User Association: What It Does and Why Certification Matters — MeteringLab

The DLMS User Association: Architecture of a Global Metering Standard

Few organizations have shaped the landscape of smart metering interoperability as fundamentally as the DLMS User Association (DLMS UA). Founded in 1997 and headquartered in Geneva, the association operates as the custodian of the DLMS/COSEM standard — the dominant application-layer protocol suite for energy metering worldwide. Yet despite its influence, many engineers working adjacent to the metering stack have only a surface understanding of what the association actually does, how its certification program functions, and why conformance matters beyond a checkbox on a procurement tender.

This article dissects all three questions with the precision they deserve.

What Is DLMS/COSEM, Precisely?

The acronym confusion is worth clearing up immediately. DLMS (Device Language Message Specification) defines the application-layer messaging protocol — request/response services, authentication mechanisms, data encoding rules, and session management. COSEM (Companion Specification for Energy Metering) defines the object model: a structured, standardized way to represent all data inside a meter — readings, profiles, events, tariff structures, and device parameters — as a collection of typed interface classes.

Together, they form a coherent architecture published across the IEC 62056 series of standards. The object model in particular is what makes DLMS/COSEM genuinely powerful: rather than a proprietary flat-file export, every data point in a DLMS-compliant device is addressable through a well-defined OBIS code (Object Identification System), an interface class, and a set of attributes or methods. This structure is defined in IEC 62056-6-1 (OBIS codes) and IEC 62056-6-2 (interface classes).

The IEC 62056 Standard Series — Core Documents

Standard Title / Scope Relevance
IEC 62056-1-0 Introduction to the DLMS/COSEM architecture Overview and scope definitions
IEC 62056-2-0 Modelling of metering systems System architecture concepts
IEC 62056-3-1 Use of local port communication Optical port / RS-232 physical layer
IEC 62056-4-7 Transport layers for IPv4 and IPv6 networks TCP/IP and UDP transport wrappers
IEC 62056-5-3 DLMS/COSEM application layer Core APDU encoding, services, security
IEC 62056-6-1 Object Identification System (OBIS) Standardized data addressing
IEC 62056-6-2 COSEM interface classes Data, profile generic, clock, tariff objects
IEC 62056-8-3 DLMS/COSEM over S-FSK PLC Narrowband PLC physical/data link

The Role of the DLMS User Association

IEC publishes the standards, but the DLMS UA does the heavy engineering work that keeps those standards alive, maintained, and implementable. The association operates through several technical working groups, each focused on a specific domain: the application layer, object modeling, communication profiles, security, and testing methodology.

Standard Maintenance and Extension

The IEC 62056 series is not static. As metering architectures evolve — from simple AMR (automatic meter reading) to full AMI (advanced metering infrastructure) with bidirectional tariff control, distributed energy resource integration, and push-based notification — the object model must be extended. The DLMS UA drafts new interface class specifications, proposes new OBIS code assignments, and submits these to IEC TC13 (Technical Committee 13, Electrical Energy Measurement and Control) for formal standardization.

In practice, DLMS UA publishes Green Books — its own comprehensive technical documentation set — that often contain material ahead of the official IEC publication cycle. The Green Books serve as the authoritative implementation reference for manufacturers between IEC edition cycles. They are available to DLMS UA members and provide interface class definitions with all attribute details, method signatures, and encoding rules in a format more accessible than the formal IEC documents.

Communication Profiles

One of the most practically important outputs of the DLMS UA is the definition of communication profiles — complete specifications that combine a physical/data-link layer with the DLMS/COSEM application layer. Examples include:

  • HDLC-based profile — IEC 62056-4-6, commonly used over RS-485 or optical port connections
  • TCP/IP profile — using the DLMS wrapper defined in IEC 62056-4-7 over Ethernet, GPRS, or fiber backhaul
  • S-FSK PLC profile — for single-phase meters on narrowband power line carrier, IEC 62056-8-3
  • PRIME profile — OFDM-based PLC, widely deployed in Spanish and Latin American smart metering programs
  • G3-PLC profile — used extensively in French Linky meters and other EU deployments
  • Wi-SUN profile — emerging for mesh radio deployments in AMI backhaul scenarios

The existence of standardized profiles means that a head-end system certified against the HDLC profile can communicate with any conformant meter over that profile without meter-by-meter integration work — in theory. In practice, conformance certification is what enforces this in theory becoming reality.

Why Certification Matters: The Interoperability Gap

The core problem that DLMS UA certification addresses is what practitioners call the interoperability gap — the space between a device that claims DLMS/COSEM compliance and one that actually interoperates correctly with third-party systems in the field.

DLMS/COSEM is a rich, complex protocol. IEC 62056-5-3 alone runs to hundreds of pages and defines dozens of optional features, multiple security suites, several authentication levels, and complex encoding rules based on ASN.1 BER/DER and AXDR (A-XDR, the COSEM-specific encoding variant). It is entirely possible to build a device that passes superficial interoperability tests while failing on edge cases: incorrect handling of partial-block transfers, malformed date-time attributes, non-conformant profile buffer behavior, or incorrect AARE (Associate-Response) PDU construction during session establishment.

Without systematic conformance testing against the full specification, these defects only surface in production — often after contracts have been signed, meters have been deployed in the field, and a utility discovers that 18 months of load profile data is inaccessible because the head-end system and the meter disagree on a timezone offset encoding.

The DLMS UA Conformance Testing Program

The DLMS UA operates a formal conformance testing program coordinated through its member network of accredited test laboratories. The program tests both server (meter/device) and client (head-end/data concentrator) implementations. Testing is structured around:

  1. Protocol conformance — Verifies that APDU encoding/decoding, service behavior, state machine transitions, and error handling conform to IEC 62056-5-3.
  2. Object model conformance — Verifies that interface class implementations correctly expose the required attributes and methods with correct data types and access rights as defined in IEC 62056-6-2.
  3. Communication profile conformance — Verifies correct behavior at the transport and data link layers for the specific declared profile (HDLC, TCP/IP, etc.).
  4. Security conformance — Verifies correct implementation of authentication levels (low-level, high-level HLS5 with GMAC), encryption using AES-GCM-128, and key management procedures.

Test cases are defined in the DLMS UA Conformance Test Specification, a living document maintained by the association. The test methodology follows principles from IEC 62056-4-11 and references ISO/IEC 9646 for OSI conformance testing philosophy.

Certification vs. Self-Declaration

Aspect Self-Declaration DLMS UA Certification
Test depth Vendor-defined scope; may omit edge cases Standardized test suite covering full specification
Independence Internal testing; potential conflict of interest Accredited third-party laboratory
Security testing Often limited or absent Mandatory security suite verification
Public registry No publicly verifiable record Listed in DLMS UA certified product database
Procurement leverage Difficult to enforce contractually Certification number is contractually verifiable
Re-test requirement Typically none Required on significant firmware/hardware changes
Profile specificity Often vague (“supports DLMS”) Profile-specific; explicit scope of certification

OBIS Codes: The Practical Heart of the Object Model

For working engineers, understanding OBIS codes is essential to working with DLMS/COSEM data. An OBIS code is a six-group identifier in the form A-B:C.D.E*F, where:

  • A — Medium (0=abstract, 1=electricity, 6=heat, 7=gas, 8=water)
  • B — Channel (meter number or input, 0 for single-channel devices)
  • C — Physical quantity (1=active power+, 2=active power-, 3=reactive power+Q1/Q2, etc.)
  • D — Measurement type (8=time-integral, 29=maximum demand, etc.)
  • E — Tariff rate or processing type
  • F — Billing period, storage index, or wildcard

For example, 1-0:1.8.0 is the universally recognized OBIS code for cumulative active energy import (kWh total), and 1-0:2.8.0 for active energy export. A head-end system that correctly parses OBIS codes can automatically understand what data a meter is reporting, regardless of manufacturer — this is the practical interoperability payoff of the standardized object model.

Membership Structure and Stakeholder Ecosystem

DLMS UA membership is open to utilities, meter manufacturers, software vendors, test laboratories, research institutes, and national standardization bodies. Members gain access to the Green Books, participate in technical working groups, and receive early visibility into upcoming standard revisions — a significant commercial advantage when planning multi-year product development cycles.

The association collaborates formally with IEC TC13, CENELEC TC13 in Europe, and coordinates with regional programs such as the EU Mandate M/441 framework that drove smart meter rollout specifications across member states. Its standards also underpin several national implementation frameworks — the Dutch P1 port specification, the Austrian smart meter rollout specification, and elements of the UK SMETS2 specification all reference DLMS/COSEM to various degrees.

Security in DLMS/COSEM: A Growing Focus

The most significant evolution in DLMS/COSEM over the past decade has been the security framework. Early deployments relied on low-level authentication — little more than a shared password. Modern deployments mandate High Level Security suite 5 (HLS5), which uses AES-128-GCM for both authenticated encryption and message integrity. The security objects are themselves modeled as COSEM interface classes (class ID 64 for security setup), meaning security configuration is queryable and manageable through the same DLMS/COSEM protocol stack used for metering data.

The DLMS UA certification program now includes security conformance as a mandatory component, reflecting the reality that a smart meter is an internet-accessible device with the ability to interrupt supply to premises — a non-trivial attack surface that demands rigorous verification.

Practical Implications for Utility Procurement

For utility engineers and procurement managers, the actionable takeaway is straightforward: DLMS UA certification should be a mandatory, non-negotiable tender requirement — not an optional preference. The certification number should be recorded, the scope of certification (which profile, which IEC 62056 edition) should be verified against the intended deployment, and re-certification obligations on firmware updates should be contractually specified.

Equally important: head-end system vendors should be held to the same standard. Client-side conformance is just as critical as server-side. A certified meter connected to a non-conformant head-end will still fail to interoperate reliably.

Key Standards

  • IEC 62056-1-0 — DLMS/COSEM architecture and system model overview
  • IEC 62056-4-6 — HDLC data link layer for local and remote communication
  • IEC 62056-4-7 — Transport layer using TCP/IP and UDP/IP
  • IEC 62056-5-3 — DLMS/COS

    Frequently Asked Questions

    What is the difference between DLMS and COSEM, and how do they work together?

    DLMS (Device Language Message Specification) defines the application-layer messaging protocol including request/response services, authentication, and session management, while COSEM (Companion Specification for Energy Metering) defines the object model for representing all meter data as typed interface classes. Together they form a coherent architecture where every data point is addressable through an OBIS code, interface class, and set of attributes or methods as defined in IEC 62056.

    What is an OBIS code and which IEC standard defines it?

    An OBIS code (Object Identification System) is a standardized addressing scheme that makes every data point in a DLMS-compliant meter uniquely addressable rather than using proprietary flat-file exports. OBIS codes are defined in IEC 62056-6-1 and work in conjunction with interface classes to create a well-defined data structure.

    Which IEC 62056 standard covers the core DLMS application layer and APDU encoding?

    IEC 62056-5-3 covers the DLMS/COSEM application layer and defines core APDU encoding, services, and security mechanisms. This is the foundational standard for understanding request/response messaging and authentication protocols in metering systems.

    What are DLMS UA Green Books and how do they differ from official IEC standards?

    Green Books are comprehensive technical documentation published by the DLMS User Association that contain interface class definitions with attribute details and method signatures in an implementation-friendly format. They serve as the authoritative reference between official IEC publication cycles and are available to DLMS UA members before formal IEC editions are released.

    Which IEC standard should I reference for TCP/IP and UDP transport in DLMS/COSEM networks?

    IEC 62056-4-7 defines the transport layers for IPv4 and IPv6 networks, providing the TCP/IP and UDP transport wrappers needed to carry DLMS/COSEM application-layer traffic over IP-based networks.

    Was this article helpful?