中文简体
English
русский
Quick Product Search
Contact us to learn how we can use our expertise to bring you high-quality products.
2026-06-19
Introduction: Two Standards, One Industry
The global smart metering industry is governed by a small number of internationally recognized standards, but two dominate the conversation: STS (Standard Transfer Specification) and DLMS/COSEM (Device Language Message Specification / Companion Specification for Energy Metering). Both are indispensable. Both are codified by the International Electrotechnical Commission (IEC). Both serve overlapping but distinct functions. And yet, despite their shared relevance, they are frequently misunderstood — particularly in relation to each other.
Misunderstanding breeds poor procurement decisions. Utilities sometimes specify STS or DLMS as an either-or choice, not realizing that the two standards address different problem domains. Regulators sometimes frame STS as a legacy system destined for obsolescence, missing the reality that STS has evolved continuously and serves a security function that no other standard replicates. And manufacturers sometimes treat dual-standard compliance as an engineering afterthought rather than a strategic necessity.
This article provides a rigorous, technically grounded comparison of STS and DLMS/COSEM — their origins, architectures, security models, application domains, and the emerging path toward convergence. The goal is not to declare a winner, but to equip utilities, engineers, and procurement decision-makers with the knowledge they need to make informed choices about when, where, and how to deploy each standard — or both together.
Origins and Evolution
STS was developed in South Africa in the early 1990s as a response to a specific challenge: enabling secure, decentralized prepaid electricity metering in environments where telecommunications infrastructure was unreliable or nonexistent. The original specification defined a method for generating encrypted numeric tokens that could be purchased at a point-of-sale terminal, transmitted to the consumer verbally, via SMS, or on a printed receipt, and entered into the meter keypad to credit the consumer's energy balance.
Over three decades, STS has evolved far beyond its origins. The current specification, codified as the IEC 62055 series, comprises multiple parts:
Today, STS is deployed in over 120 countries, with an installed base estimated at more than 100 million compliant meters. It is the de facto standard for prepaid electricity metering in Africa, South and Southeast Asia, and parts of Latin America — regions where prepaid models are essential for revenue assurance in markets with limited billing infrastructure.
Technical Architecture: How STS Tokens Work
At the heart of STS is the credit token — a 20-digit encrypted numeric string that encodes a specific transaction (typically a credit purchase, but also including key changes, tariff updates, meter test commands, and other management operations). The token generation process follows a well-defined cryptographic protocol:
Key hierarchy: Every STS-compliant meter is manufactured with a unique set of cryptographic keys arranged in a hierarchical structure. At the top of the hierarchy is the Master Key, held by the STS Association's Key Management Authority. Beneath the Master Key are a series of Decoder Keys — each meter receives its own Decoder Key, which is derived from the Master Key through a secure key generation ceremony. The Decoder Key is never transmitted in the clear; it is loaded into the meter's secure memory during manufacturing or during a secure key change operation.
Token generation: When a consumer purchases electricity credit, the vending system (the point-of-sale terminal or online platform) generates a token by encrypting the transaction data — the amount of credit, the meter's serial number, the current tariff index, and a timestamp — using the meter's Decoder Key. The encryption algorithm (STS uses a proprietary algorithm defined in IEC 62055-41) produces a 20-digit numeric output: the token.
Token transmission: The token is delivered to the consumer through whatever communication channel is available — verbally, via SMS, on a printed receipt, or electronically. The security of the token does not depend on the security of the transmission channel; the token itself is cryptographically protected.
Token decoding: The consumer enters the 20-digit token into the meter's keypad. The meter's onboard STS decoder uses its stored Decoder Key to decrypt the token, verify its authenticity, extract the transaction data, and execute the corresponding operation (crediting the energy balance, changing the tariff, etc.).
This architecture has several important properties. First, it is stateless from the perspective of the transmission channel — the token carries all the information necessary to execute the transaction, and the security of the transaction does not depend on the confidentiality or integrity of the channel used to deliver the token. Second, it is cryptographically secure — without the meter's Decoder Key, it is computationally infeasible to generate a valid token. Third, it is auditable — the key management infrastructure maintained by the STS Association provides a complete chain of custody for every key in the hierarchy, enabling forensic investigation if fraud or key compromise is suspected.
STS Is Not a Legacy System
A persistent misconception frames STS as a legacy technology that is being superseded by smart metering standards like DLMS. This characterization is inaccurate. STS has evolved continuously since its inception, incorporating advances in cryptographic controls, key management practices, and token lifecycle governance:
Controlled token rotation: The STS specification defines token types with defined lifetimes. A credit token generated with one set of cryptographic parameters will not be accepted by a meter that has been updated to newer parameters. This ensures that the token encryption algorithm can be refreshed over time without requiring wholesale replacement of the meter fleet — a critical feature for long-lived infrastructure with 10- to 15-year service lives.
Key change protocols: STS defines secure procedures for changing a meter's Decoder Key, including dual-key-change tokens that allow a meter to transition from one key to another without a window of vulnerability. These procedures are essential for maintaining the security of the installed base as the Master Key or intermediate keys are periodically rotated.
Lifecycle governance: The STS Association's Key Management Authority maintains a comprehensive governance framework for the entire key lifecycle — from key generation and distribution to revocation and destruction. This framework is regularly audited and updated to reflect evolving good practices in cryptographic key management.
Formal certification program: The STS Association operates a product certification program that requires manufacturers to submit their meters for rigorous testing against the STS specification. Certified products are listed in a public register, providing utilities with confidence that certified meters will correctly generate, receive, and process STS tokens in compliance with the standard.
These capabilities are not the hallmarks of a legacy system. They are the hallmarks of a mature, actively maintained standard that continues to evolve in response to changing security requirements and market demands.
Origins and Structure
DLMS/COSEM was developed by the DLMS User Association as a comprehensive framework for smart metering communication and data management. Unlike STS, which focuses narrowly on secure token-based transactions, DLMS/COSEM addresses the full scope of smart metering functionality: data acquisition, communication, interoperability, and multi-utility support. The standard is codified through the IEC 62056 series, commonly referred to by the color of their specification covers:
The COSEM data model is the distinguishing feature of DLMS. Rather than defining a fixed set of registers or data points, COSEM defines an extensible library of interface classes, each representing a specific metering function. A meter manufacturer implements the relevant interface classes for the meter's capabilities, and a head-end system queries and manipulates these objects through standardized DLMS Application Layer services. This approach provides a level of abstraction and interoperability that is not possible with proprietary or register-based communication protocols.
Multi-Utility Support
DLMS/COSEM's one significant strengths is its native support for multiple utility types. The COSEM object model includes interface classes specifically designed for electricity, water, gas, and heat metering. A DLMS-compliant water meter implements the appropriate COSEM interface classes for flow measurement, volume registers, and leak detection. A DLMS-compliant gas meter implements classes for gas volume, pressure and temperature compensation, and flow rate monitoring. A DLMS-compliant heat meter implements classes for thermal energy calculation, flow and return temperature measurement, and heat carrier volume.
This multi-utility capability means that a single DLMS-based data collection infrastructure — head-end systems, communication networks, data management platforms — can serve electricity, water, gas, and heat meters from multiple manufacturers. The utility does not need to deploy separate data collection systems for each utility type, and interoperability between manufacturers is ensured by the common COSEM data model and DLMS communication protocol.
Companion Profiles for Interoperability
While the COSEM data model provides a comprehensive library of interface classes, the real world requires constraints. A utility cannot practically support every possible combination of COSEM interface classes, communication parameters, and security mechanisms. To address this, the DLMS User Association defines Companion Profiles — pre-defined subsets of the DLMS/COSEM specification that constrain the implementation to a manageable set of options while maintaining interoperability within the profile's scope.
Companion Profiles serve a critical function in the DLMS ecosystem. They allow utilities to specify their metering requirements in terms of a profile (e.g., "DLMS Companion Profile for Electricity Metering, Level 3") rather than enumerating individual COSEM classes and parameters. Manufacturers design their products to comply with specific profiles, and interoperability testing validates compliance. This significantly reduces the complexity of procurement specifications and interoperability assessments.
Multi-Layer Security Architecture
DLMS implements a multi-layer security architecture that protects metering data at every stage of the communication process:
TLS (Transport Layer Security): Provides channel-level encryption and authentication for the communication link between the meter and the data collection system. TLS ensures that all data transmitted between the meter and the head-end system is encrypted and that both parties are authenticated, preventing eavesdropping, tampering, and impersonation attacks on the communication channel.
SAS (Security Architecture for Smart Metering): An application-level security suite defined by the DLMS User Association that provides end-to-end security for DLMS messages. SAS uses public-key cryptography for key exchange and authentication, and symmetric-key cryptography for message encryption and integrity protection. SAS operates independently of the transport layer, providing security even when messages pass through intermediate systems (data concentrators, gateways) that may not be fully trusted.
AES (Advanced Encryption Standard): Used within the SAS framework for symmetric-key encryption of DLMS message payloads. AES provides strong encryption with efficient performance on the constrained hardware platforms used in smart meters.
This layered security architecture provides defense in depth: even if one layer is compromised, the remaining layers continue to protect the metering data. The combination of channel-level security (TLS) and application-level security (SAS) is particularly robust, as it protects against both network-level attacks (packet sniffing, man-in-the-middle) and application-level attacks (message tampering, replay attacks).
Dimension 1: Core Capabilities
The fundamental difference between STS and DLMS lies in their core capabilities:
STS is a transaction security standard. Its primary function is to enable secure, auditable prepaid transactions between a vending system and a meter. STS defines how tokens are generated, encrypted, transmitted, and decoded. It does not define how the meter communicates with a central system, how consumption data is collected, or how the meter is configured for demand management or time-of-use tariffs. STS is silent on these matters because they are outside its scope.
DLMS/COSEM is a communication and data management standard. Its primary function is to define how meters communicate with data collection systems, how meter data is structured and accessed, and how interoperability between manufacturers is achieved. DLMS defines the data model (COSEM), the communication protocol (DLMS Application Layer), the security mechanisms (TLS, SAS, AES), and the interoperability constraints (Companion Profiles). It does not define a specific prepaid transaction mechanism — although, as the Liaison Agreement demonstrates, it provides the infrastructure to carry one.
This distinction is not a weakness of either standard. It is a reflection of their different design intents. STS was designed to solve a specific problem — secure prepaid transactions in low-infrastructure environments. DLMS was designed to solve a different problem — comprehensive smart metering communication and interoperability. The fact that the two standards address different problem domains is precisely what makes them complementary.
Dimension 2: Application Scenarios
The application scenarios for STS and DLMS reflect their different core capabilities:
STS is predominantly deployed in prepaid electricity metering scenarios. A utility installs STS-compliant prepaid meters in consumers' premises, sets up vending points (physical kiosks, mobile banking integrations, online platforms) where consumers purchase electricity credit, and uses the STS token system to securely transfer credit from the vending system to the meter. The meter's primary function — from the consumer's perspective — is to display the remaining credit balance and disconnect the supply when the credit is exhausted.
STS is also used in limited postpaid scenarios, primarily as a management tool. Utilities can use STS tokens to change tariffs, update meter configurations, perform remote testing, and execute other management operations on the meter fleet. However, these uses are secondary to the prepaid transaction function.
DLMS/COSEM is deployed across a broad spectrum of smart metering scenarios. These include:
DLMS is also increasingly used in prepaid scenarios, although this has historically required integration with STS or the development of proprietary prepaid mechanisms. The STS-DLMS Liaison Agreement addresses this gap by defining a standard approach for carrying STS tokens over DLMS communication channels.
Dimension 3: Security Models
The security models of STS and DLMS are designed for different threat contexts and are inherently complementary:
STS security operates at the transaction level. The security guarantee is that a valid token can only be generated by a system that possesses the correct cryptographic key for the target meter. The token's security is independent of the channel used to deliver it — whether the token is spoken over a phone call, printed on a piece of paper, or transmitted electronically, the cryptographic protection is the same. This design reflects STS's origin in environments where the communication channel between the vending system and the meter cannot be trusted or controlled.
The STS security model also provides non-repudiation: because every token is generated using a specific key in the STS key hierarchy, and the key hierarchy is maintained under strict governance by the STS Association's Key Management Authority, it is possible to trace any token back to the key used to generate it and, ultimately, to the entity responsible for that key. This provides a strong audit trail for fraud investigation and dispute resolution.
DLMS security operates at the communication level. The security guarantee is that data transmitted between the meter and the data collection system is encrypted, authenticated, and protected against tampering and replay attacks. DLMS provides security for the communication channel — the link between the meter and the head-end system — regardless of the application data being carried. This design reflects DLMS's role as a communication standard, where the primary threat is unauthorized access to or manipulation of the data in transit.
The DLMS security model provides confidentiality and integrity for all data exchanged between the meter and the collection system. It protects consumption data from interception, prevents unauthorized configuration changes, and ensures that event notifications are genuine. However, DLMS security does not by itself guarantee the authenticity of prepaid transactions — that is the role of STS.
The complementary nature of these security models is precisely what makes the STS-DLMS convergence valuable. A dual-standard meter protected by STS transaction-level security and DLMS communication-level security benefits from both: tokens are cryptographically protected regardless of the channel, and all data exchanged over the communication link is encrypted and authenticated regardless of the application.
The January 2026 STS-DLMS Liaison Agreement defined a specific technical mechanism for integrating STS token transactions into the DLMS/COSEM communication framework: the Generic Companion Profile.
Technical Mechanism
The integration works as follows:
This mechanism preserves the security guarantees of both standards. The STS token is protected by STS's transaction-level cryptography. The communication channel is protected by DLMS's communication-level security. Neither standard's security is compromised by the presence of the other.
Why This Matters
The fusion path has several practical advantages:
Single communication infrastructure: Utilities can use a single DLMS-based communication network to handle both smart metering data collection and prepaid token delivery, rather than maintaining separate communication systems for each function.
Reduced latency: STS tokens delivered electronically via DLMS are processed immediately, compared to the delays inherent in physical or verbal token delivery methods.
Improved auditability: Token delivery and processing events are logged in the DLMS communication records, providing utilities with a complete, timestamped audit trail that was not previously available when tokens were delivered through non-electronic channels.
Enhanced consumer experience: Consumers in DLMS-connected deployments can purchase and receive electricity credit electronically, without visiting a physical vending point or entering 20-digit codes manually.
The practical realization of STS-DLMS convergence depends on manufacturers producing meters that implement both standards. This requires firmware architectures that maintain separate processing engines for STS and DLMS, connected through a middleware layer that routes payloads between the communication stack and the appropriate engine.
Several manufacturers have already brought dual-standard products to market. SOOCIA (Zhejiang Songxia electric meter Co., Ltd.) offers a relevant example. As a member of both the STS Association and the DLMS User Association, SOOCIA has developed its DDS722 (single-phase) and DTS722 (three-phase) meter series to comply with both standards. These meters implement STS token processing for prepaid functionality and DLMS/COSEM communication for smart metering data exchange, providing utilities with a single hardware platform that supports both operational models.
The engineering challenge of dual-standard implementation is non-trivial. The firmware must manage concurrent access to shared resources (display, relay, real-time clock, non-volatile memory), handle potential conflicts between STS and DLMS operations (e.g., a disconnect command issued via STS while the meter is communicating via DLMS), and maintain compliance with both standards' respective testing and certification requirements. However, the increasing market demand for integrated solutions, combined with the technical framework provided by the Liaison Agreement, is driving a growing number of manufacturers to invest in dual-standard product development.
The decision to deploy STS, DLMS, or both depends on the utility's specific context:
Deploy STS when:
Deploy DLMS when:
Deploy both when:
In practice, the "deploy both" scenario is becoming increasingly common, particularly in emerging markets where utilities are simultaneously addressing revenue collection challenges (through prepaid metering) and modernizing their grid infrastructure (through smart metering). The STS-DLMS Liaison Agreement, with its Generic Companion Profile integration mechanism, provides the technical foundation for this dual deployment approach.
STS and DLMS/COSEM are not competitors. They are complementary standards that address different — and increasingly overlapping — requirements in the global metering industry. STS provides unmatched transaction-level security for prepaid metering. DLMS/COSEM provides a comprehensive, interoperable framework for smart metering communication and data management. The January 2026 Liaison Agreement between the STS Association and the DLMS User Association represents a mature recognition of this complementarity and a concrete commitment to making dual-standard solutions work.
For utilities, manufacturers, and technology decision-makers, the key takeaway is this: understanding the strengths and limitations of each standard is essential for making informed procurement and deployment decisions. STS is not a legacy technology to be replaced by DLMS; it is a living standard with a critical security function. DLMS is not a prepaid solution that competes with STS; it is a communication framework that can carry STS tokens as efficiently as it carries any other application data.
The future of smart metering is not about choosing one standard over another. It is about using the right standard for the right function — and, where those functions coexist, integrating them through the mechanisms that the Liaison Agreement provides. As the metering industry continues its global evolution toward smarter, more connected, and more flexible infrastructure, the STS-DLMS convergence will be one of the defining technical developments of the decade.
Recommended Products
With over 30 years of experience in electricity metering, we specialize in the design, manufacturing, and supply of energy meters. Our product portfolio covers multiple series, including mechanical, electronic, and smart meters.
Contact Us
+86-577-62711702
Zhejiang Soocia Electric Meter Co., Ltd.：
No.21-23 Shanggong Road, Shangwu Industrial Zone, Liushi Town, Yueqing City, Zhejiang Province, China
Huaxia Power Transmission And Distribution Equipment Co., Ltd.：
No. 222 Weisan Road, Yueqing Economic Development Zone, Yueqing City, Zhejiang Province, China
Industrial & Commercial Power Systems
