Loading header...

When a utility's software asks a meter "how much energy did you record at 2 AM?", something has to define exactly how that question is asked and how the answer comes back. That something is DLMS/COSEM.

What is DLMS/COSEM?

DLMS — Device Language Message Specification — is the messaging protocol. It defines how requests and responses are encoded and transmitted.

COSEM — Companion Specification for Energy Metering — defines the data model inside the meter: what objects exist, what attributes they have, and how they are addressed.

Together they form the dominant international standard for meter communication, maintained by the DLMS User Association and standardised as IEC 62056.

Think of COSEM as the database schema inside the meter, and DLMS as the SQL that queries it.

The Object Model

Everything inside a COSEM meter is an object. Each object belongs to an interface class that defines its structure.

classDiagram class CosemObject { +classId: uint16 +version: uint8 +logicalName: OBIS_code } class Data { +value: any +get() +set() } class Register { +value: float +scaler_unit: struct +get() +reset() } class ProfileGeneric { +buffer: array +capture_objects: list +get() +reset() } CosemObject <|-- Data CosemObject <|-- Register CosemObject <|-- ProfileGeneric

Some key interface classes:

Class ID Name Typical use
1 Data Serial number, firmware version, flags
3 Register Energy counters (kWh, kVArh)
4 Extended Register Register with timestamps
7 Profile Generic Load profiles, event logs
8 Clock RTC access
70 Disconnect Control Remote switch
71 Limiter Demand limit / load control

The Client–Server Model

The meter is always the server. The Head-End System (HES) or a handheld reader is the client. The client initiates all communication.

sequenceDiagram participant HES as HES (Client) participant M as Meter (Server) HES->>M: AARQ (Association Request) M-->>HES: AARE (Association Response — OK) HES->>M: GET.request (kWh register) M-->>HES: GET.response (value + unit) HES->>M: RLRQ (Release Request) M-->>HES: RLRE (Release Response)

The AARQ/AARE handshake is like a TCP connection setup — it establishes the application-layer association, negotiates security parameters, and authenticates the client before any data is exchanged.

DLMS Services

Three core services:

Service Direction Purpose
GET Client → Server Read an attribute
SET Client → Server Write an attribute
ACTION Client → Server Invoke a method (e.g. reset, connect, disconnect)

Each service has a request and a response (and a notification variant for unsolicited data).

Logical Device Names

Each meter may contain one or more logical devices — virtual meters sharing the same physical hardware. Each logical device has a name (e.g. ISE12345678) and its own set of COSEM objects.

The Management Logical Device (MLD) always exists and holds device-level objects like firmware version, serial number, and the association objects that control security.

Why DLMS/COSEM Matters

Before DLMS/COSEM, every meter vendor had their own proprietary protocol. A utility with five different meter brands needed five different software interfaces. DLMS/COSEM means any compliant meter from any vendor can be read by any compliant HES — interoperability.

Key Takeaway

DLMS is the envelope; COSEM is the letter inside. Understanding the object model — interface classes, logical names, attributes, and methods — is the key to reading, programming, and troubleshooting any smart meter in the field.