DLMS Meter, OBIS and HES Integration: An AMI Buyer Verification Checklist

“Supports DLMS/COSEM” is a useful starting point in product evaluation, but it does not by itself demonstrate end-to-end interoperability.

In an advanced metering infrastructure (AMI) project, a DLMS smart meter must exchange the required data and commands with a gateway, data concentrator or Head-End System (HES). Establishing a physical or network connection is only one part of that process.

The meter and the upper-level systems must also align on:

• COSEM objects and interface classes
• OBIS identifiers
• Referencing method
• Supported services and conformance block
• Communication profile
• Authentication and security settings
• Client access rights
• Data types, units and scalers
• Event and profile definitions
• HES object mapping

COSEM defines how metering data and functions are represented as objects, while OBIS provides standardized identifiers for the corresponding data and object instances. The DLMS application layer provides the services used to establish associations and access object attributes and methods.

For an AMI project buyer, the key question is therefore not only:

Does this meter support DLMS/COSEM?

It is:

Does this specific meter configuration provide the required objects, security settings and communication profile, and operate correctly with the project’s concentrator and HES?

What Does Interoperability Mean in an AMI Project?

Interoperability means that devices and systems can exchange and correctly use the information required by the project.

A typical AMI data chain may include:

DLMS Smart Meter
→ Communication Network
→ Gateway or Data Concentrator
→ Head-End System
→ MDM / Billing / Utility Platform

The metering device typically acts as a DLMS server, while the HES or data concentrator typically acts as a client. The exact roles, however, depend on the communication and system architecture.

A successful connection does not prove that the HES can:

• Read every required measurement
• Interpret each object correctly
• Retrieve load profiles
• Process events and alarms
• Apply the correct units and scalers
• Establish the required secure association
• Execute authorized remote operations
• Recover correctly after communication interruption

Interoperability should therefore be evaluated for the selected meter model, firmware version, communication module, concentrator architecture and HES configuration.

DLMS Application Layer, COSEM Objects and OBIS Identification

DLMS, COSEM and OBIS serve related but different functions.

The COSEM data model defines how metering data and device functions are represented through interface classes, objects, attributes and methods.

Examples may include objects for:

• Active and reactive energy
• Voltage and current
• Active and reactive power
• Load profiles
• Tariff registers
• Clock information
• Event logs
• Communication status
• Disconnect-control functions

The DLMS application layer provides client-server services for establishing associations, reading and writing attributes, and invoking supported methods. Depending on the project configuration, it may also apply authentication and cryptographic protection.

The OBIS identification system provides standardized identifiers for metering data and related object instances. Its structured identification groups can describe characteristics such as the measured resource, measurement quantity, processing, tariff or historical value, depending on the data item.

A buyer should therefore verify more than the statement “DLMS supported.” The technical evaluation should identify which objects, attributes, methods, services and communication profiles are actually implemented.

Why an OBIS Code Alone Is Not Enough

An OBIS code is important, but it does not by itself define full compatibility.

Project buyers should also confirm:

• Full logical name and object instance
• COSEM interface class
• Attribute number
• Method, where applicable
• Data type
• Unit and scaler
• Read, write or execute permission
• Reading method
• Capture period
• Profile capture objects
• Buffer size
• Selective-access support
• Logical-name or short-name referencing
• Supported services
• Conformance block
• Association view

Two meters may expose the same or a similar OBIS identifier but implement different interface classes, profile structures, access rights or data formats.

Before procurement, the utility, HES provider or system integrator should prepare a required object list.

Meter, Data Concentrator and HES Communication Chain

In some projects, the HES communicates directly with meters. In others, communication is handled through a data concentrator.

DLMS Meter
→ PLC / RF / Cellular / Other Network
→ Data Concentrator
→ HES

DLMS/COSEM can be implemented over multiple communication profiles. The required profile and testing scope should be confirmed against the selected product, communication technology, concentrator design and project requirements.

The role of the data concentrator may differ significantly between projects. Buyers should confirm whether the concentrator:

• Acts as a DLMS client toward the meters
• Transparently forwards communication
• Stores and aggregates meter data
• Schedules local reading tasks
• Supports store-and-forward operation
• Exposes or forwards processed data to the HES
• Performs protocol or data translation
• Manages local retries and recovery

Project teams should also verify:

• Addressing structure
• Session and timeout behavior
• Number of meters per concentrator
• Reading schedule
• Retry mechanism
• Offline storage
• Recovery after network interruption
• Remote configuration responsibilities
• Firmware-management responsibilities

A meter that works correctly during direct laboratory testing may behave differently when deployed through the actual communication network and concentrator.

Authentication, Security and Access Rights

DLMS/COSEM projects may use different authentication and security configurations.

The technical specification should identify:

• Client identity
• Association parameters
• Authentication mechanism
• Security suite
• Security policy
• Encryption and authentication requirements
• Client system title
• Key types and key lifecycle
• Invocation-counter handling
• Access rights for each client
• Secure read, write and action operations
• Commissioning process
• Key replacement or renewal procedure

The same meter may expose different objects and permissions to different clients. A public client may only access basic identification data, while an authorized utility client may access billing profiles, event logs or control functions.

Therefore, “supports DLMS/COSEM” does not explain which association, security configuration or access model is implemented.

Why DLMS Support Does Not Guarantee HES Compatibility

A DLMS meter may still fail to integrate with a specific HES because of differences in:

• Applicable specification edition
• Logical-name or short-name referencing
• Conformance block
• Supported services
• Association view
• COSEM object list
• OBIS implementation
• Communication profile
• Security configuration
• Client access rights
• Event definitions
• Time handling
• Firmware behavior
• HES-side mapping

Compatibility should be verified through documentation review, object mapping, sample testing and pilot integration.

A connection to a generic DLMS client is useful evidence, but it does not reproduce every field network, concentrator, utility workflow or HES implementation.

Compliance, GCP Compatibility and Project Validation

Compliance certification, compatibility certification and project validation are different levels of evidence.

DLMS UA Compliance Certification

DLMS UA compliance certification evaluates whether a product conforms to the applicable DLMS UA Core Specifications, including the relevant Blue Book and Green Book requirements.

A Certificate of Compliance is useful technical evidence, but it does not prove that the product supports every object, security configuration or project workflow required by a specific utility.

Compatibility Certification Against a Defined GCP

Compatibility certification is assessed separately against one or more defined Generic Companion Profiles (GCPs).

For AC electricity smart meter projects, buyers may need to determine whether the utility specification references a profile such as the DLMS UA AC Electricity Smart Meter Generic Companion Profile.

A GCP can improve consistency by defining selected functional and configuration choices. However, not every AMI project requires the same GCP.

Compatibility certification provides evidence against the selected GCP, but it does not demonstrate compatibility with every utility HES or project workflow.

Utility and Project-Specific Validation

A utility may also require:

• Its own companion specification
• Approved device lists
• Laboratory reports
• Security documentation
• Sample evaluation
• Field pilot testing
• Formal acceptance testing

Neither compliance nor GCP-based compatibility certification replaces validation using the actual meter configuration, communication network, concentrator, security settings and HES.

Pre-Deployment and Acceptance Test Checklist

Before rollout, AMI buyers should verify the following:

Acceptance testing should use the actual project environment or a technically representative setup.

How YTL Can Support Model-Specific Technical Evaluation

Zhejiang Yongtailong Electronic Co., Ltd. (YTL) manufactures energy metering and power measurement products for smart metering, AMI/AMR, prepaid metering and communication-enabled energy applications.

For projects requiring DLMS/COSEM, YTL can support initial model-specific technical evaluation based on the project’s:

• Target market
• Electrical requirements
• Required object list
• Communication architecture
• Security requirements
• Data concentrator design
• HES specification

Project support may include:

• Smart meter model evaluation
• Communication-module review
• OBIS and object-list confirmation
• Security-requirement review
• Data concentrator architecture discussion
• Documentation review
• Sample testing
• Pilot-integration technical support, subject to project scope
• Project-based OEM/ODM evaluation

Product capabilities vary by model, firmware, communication module and project configuration. DLMS/COSEM support, OBIS object lists, security settings, certifications and HES compatibility should be confirmed for the selected product and tested in the intended project environment.

FAQ

What is a DLMS meter?

A DLMS meter is a metering device that uses the DLMS/COSEM framework to exchange structured data with clients such as data concentrators or Head-End Systems.

What is an OBIS code?

An OBIS code provides standardized identification for metering data and related object instances. Buyers should also verify the logical name, interface class, attributes, data type, scaler and access rights.

Does DLMS support guarantee HES compatibility?

No. HES compatibility also depends on the object list, OBIS implementation, referencing method, conformance block, communication profile, security configuration, firmware and HES mapping.

What is the difference between compliance and compatibility certification?

Compliance certification evaluates conformity with the applicable DLMS UA Core Specifications. Compatibility certification is assessed against a defined Generic Companion Profile. Neither replaces project-specific HES validation.

Does GCP compatibility mean compatibility with every HES?

No. It provides evidence against the selected GCP, but a utility’s HES, security configuration, object mapping and workflow still require project-specific testing.

What should buyers request from a DLMS meter supplier?

Buyers should request the applicable specification edition, referencing method, conformance block, communication profile, object list, OBIS identifiers, interface classes, access rights, security configuration, firmware details and relevant certification documents.

What role does a data concentrator play?

Depending on the architecture, a concentrator may act as a DLMS client, transparently forward communication, store and aggregate data or perform protocol and data translation before information reaches the HES.

Should AMI buyers perform pilot integration testing?

Yes. Pilot testing helps verify the meter, communication network, data concentrator, security configuration and HES together under representative project conditions.

Conclusion

DLMS/COSEM provides a structured framework for meter-data exchange, but “supports DLMS” is only the beginning of an AMI technical evaluation.

Project buyers should verify:

• DLMS/COSEM configuration
• COSEM objects and OBIS identifiers
• Referencing method and conformance block
• Security and access rights
• Communication profile
• Data concentrator behavior
• HES object mapping
• Certification scope
• Pilot-test results

The most reliable procurement process combines documentation review, model-specific confirmation, sample testing and validation with the intended communication network, data concentrator and HES.

Planning a DLMS smart metering or AMI project? Share your required object list, communication architecture, security requirements, HES specification and pilot scope with YTL for initial model-specific technical evaluation.

Official References

• DLMS User Association — Core Specifications
• DLMS User Association — Qualification
• DLMS User Association — Generic Companion Profiles
• IEC 62056-5-3:2023 — DLMS/COSEM Application Layer
• IEC 62056-6-1:2023 — Object Identification System (OBIS)
• IEC 62056-6-2:2023 — COSEM Interface Classes