DLMS/COSEM

IEC 62056 · COSEM object model and DLMS messages on one page · meter and DCU

One meter, two jobs. COSEM is the shape of the data: which objects exist and what they are called. DLMS is the conversation that reads and writes those objects. OBIS codes are the names inside COSEM. A companion profile such as IDIS picks which of those objects a certified meter must carry.

Where a COSEM object sits

Indent is depth. Color is the job in the nest above. The physical device and the logical device are not COSEM objects. The physical device holds logical devices. The logical device holds a flat list of objects. Those objects are siblings. An object does not hold the devices above it, and it does not hold another object. A few objects hold a flat list of names, and those names point at siblings.

Three lists of names

Each box is one COSEM object. The table is the attribute that holds the list. Every row is another object that already sits in the logical device. The OBIS cell stays blue. A cell that names an object uses the object color. Green is only the reading, attribute 2. Purple, orange, and red replace that object color when the job is the session, another action, or the disconnect.

Three meters, three lists

The meter’s list is attribute 2 of the current association. These are shapes, not a vendor ICD. This wiki does not hold those ICDs.

OBIS — six groups in the name

1A · medium
electricity

0B · channel
none

1C · quantity
active import

8D · processing
time integral

0E · tariff
total

255F · history
current value

Printed form: 1-0:1.8.0*255. Checklist short form: 1.8.0.

Interface classes a village read actually touches

Class numbers are the public COSEM interface-class identifiers (IEC 62056-6-2). A manufacturer still chooses which instances to expose. That list is the vendor ICD, or an IDIS / Generic Companion Profile certificate when the meter has one. See where register work goes.

Association and keep-alive

The interface classes above are the easier part, once a driver is in place. Building that driver is the larger job. From the 30 Sep–1 Oct workshop: a pluggable driver per meter type can be pulled off the shelf for pre-approved meters, and each meter OEM has its own way through the heartbeat side of the login and heartbeat process. The open-server note records three outcomes: an OEM-agnostic head end, a local mirror inside the headend when the cloud is down, and talking to various gateways.

Association

Login is standardized. IEC 62056, through the Blue Book and Green Book, defines one association-establishment procedure. The client sends AARQ. The meter answers with AARE. The exchange is ACSE (Association Control Service Element). Authentication is defined: no security, Low Level Security, or High Level Security and its algorithms. A DLMS-certified meter is supposed to implement this same handshake. Association is one of the more rigorously conformance-tested parts. Yellow Book testing and the Qualification Program check it. The exchange is drawn under DLMS — the messages.

Keep-alive

Heartbeat is where the base standard leaves gaps. DLMS/COSEM does not mandate one universal heartbeat message.

• Push. Data notification and push are in later parts of the Green Book. Some manufacturers use them for a periodic “I’m alive”, or for event pushes. Interval, trigger, and which OBIS or push object are configurable. Those choices vary.
• Transport keep-alive. The TCP/IP wrapper profile is IEC 62056-47. That is infrastructure, not one standardized application-layer message.
• No single certifying body enforces one heartbeat payload format industry-wide.

Integration still takes engineering effort between two DLMS-certified meters.

Companion profiles

IDIS locks the open choices of base DLMS/COSEM into a companion profile: device model, security setup, association behavior, event codes, firmware update, and the rest of that package. IDIS-certified meters from different manufacturers are meant to be plug-and-play against a compliant head-end, without a custom driver per vendor. The IDIS Association merged into DLMS UA in November 2021. Certification now runs through the DLMS UA qualification portal and DNV’s accredited lab. From the same workshop notes, that profile is the closest existing answer to the heartbeat gap. Sources and package history stay on the register checklist.

National companion specifications go further than base IEC 62056 for one market. The UK GB Companion Specification (GBCS) under SMETS, the Netherlands DSMR profile, and other national utility profiles pin security, association parameters, and sometimes push or keep-alive for that market. They do not necessarily align across countries.

The Qualification Program checks AARQ/AARE and general protocol conformance. The Yellow Book and the Conformance Test Tool (CTT) are that check. Conformance to the base standard still leaves vendor-specific options: extra OBIS codes, security variants, and event and push behavior. Head-end integration stays non-trivial.

DLMS — the messages

DCU · client

Meter · server

AARQ — open an association

→

AARE — accept, with the context

GET class 3, 1-0:1.8.0*255, attribute 2

→

GET response — value. Scaler and unit are attribute 3.

ACTION on class 70 — open or close

→

ACTION response — result

SET writes an attribute. GET and SET also have with-list forms so one exchange carries several registers. A block transfer carries a long profile buffer. Event notification and data notification let the meter push without a fresh GET.

IDIS — how it shows up in the schema

Logical device After association, class 15 attribute 2 is the object list: every instance this meter exposes.

Register · class 3 · 1-0:1.8.0*255 Required by the companion profile. Two certified meters expose this same instance.

Clock Same pattern. The profile names the use case. The schema is still class + OBIS + attribute.

Manufacturer instance May sit in the same object list. The certificate does not cover it. Read it from that model’s ICD.

GET addressclass 3 · 1-0:1.8.0*255 · attr 2 responsethe energy value IDIS in that responsenowhere — the mark is which instance had to be there

Event tables in an IDIS package are values inside an existing event or alarm object, not a new OBIS group. Package history stays on the register checklist.

Documents

Piece	Where it is written	What you use it for
OBIS names	IEC 62056-6-1 · Blue Book	Which code is import energy, voltage, clock
Interface classes	IEC 62056-6-2 · Blue Book	Attributes and methods of Register, Clock, Profile, Disconnect
Application messages	IEC 62056-5-3 · Green Book	Associate, GET, SET, ACTION
Which objects this meter has	Vendor ICD, or an IDIS / DLMS UA companion certificate	The gap between “DLMS” and a second manufacturer’s meter
Conformance tests	Yellow Book	Lab proof, separate from a brochure claim

Full Blue and Green Books are on the DLMS UA shop and in the member portal. Free excerpts are on the knowledge hub. The Yellow Book is the qualification process, for members.

A certified read is still a COSEM address inside a DLMS GET. The package catalog stays on the register checklist.

COSEM object Association and keep-alive Register checklist IDIS Village standards DLMS User Association ↗