Purpose and architecture
DLMS/COSEM is specified by DLMS User Association and the IEC 62056 family for data exchange with utility meters. DLMS supplies communication services; COSEM supplies object modelling. A head-end system normally acts as client and a meter as server. Supported push services can report scheduled data or events.
A particular operator's deployment must be confirmed from its documentation; a meter brand alone does not establish the protocol used.
Objects and OBIS
COSEM objects have an interface class, attributes, methods and a logical name represented by a six-byte OBIS code. A code such as 1.0.1.8.0.255 identifies a standardised active-energy quantity; it does not guarantee every meter implements that object. Check association view, scale, units and access rights.
Common classes include Data 1, Register 3, Extended Register 4, Demand Register 5, Profile Generic 7, Clock 8, Association LN 15 and Activity Calendar 20. Data may contain supported compound types. Demand Register concerns interval averages/current and last periods, not merely a maximum-power field.
Profiles and services
Communication profiles include suitable HDLC serial links, IP wrapper mappings and PLC arrangements. PRIME and G3-PLC are narrowband OFDM PLC technologies, not broadband PLC. Profile limits for addressing, segmentation and message size differ even when the COSEM model is shared.
xDLMS services include GET, SET and ACTION, with ACCESS and notifications where supported. Services and negotiated capabilities must be checked. A supported optical port or network interface is not by itself permission to write configuration.
Load profiles and AMI
Profile Generic stores rows defined by capture objects. Capture period can specify periodic collection; 15 minutes is common in some applications but not mandatory. A load profile may contain energy increments, power or other measurements. A familiar OBIS identifier does not guarantee identical columns everywhere.
An AMI architecture may include meters, PLC data concentrators, a head-end system and meter-data management. The HES reads and manages supported functions; MDM validates and processes data. Reading schedules depend on operational needs and capacity, not a universal daily/monthly rule.
Security
Association authentication, message protection and access rights are separate. No authentication, LLS and HLS do not automatically determine which objects can be operated. Security suites and policies select supported cryptographic mechanisms and whether messages are authenticated, encrypted or both.
AES-GCM and, in relevant suites, public-key mechanisms are available. Legacy MD5/SHA-1 HLS options are not recommendations for a new deployment. Key handling, invocation counters, identifiers and replay protection are essential. Check the actual meter profile and negotiated settings.
Commissioning and faults
Confirm the profile, addresses, objects, authentication and security policy. Read the association view before interpreting profiles; verify clocks, capture objects and push behaviour. Common faults include wrong OBIS assumptions, incompatible capabilities, PLC interference, radio coverage, key mismatch and lost counter state. DLMS/COSEM offers richer metering semantics than basic Modbus, but still requires implementation-level compatibility.
