Choose another country or region to see content specific to your location.

Interoperability standard for energy meters – an Indian experience

by Kaushik Ghosh

The electricity utilities all over the world have invested huge sum of money in electronic metering assets over the past two decades or so. The primary motivation to switch to electronic metering has been the potential use of the information that these meters could provide. The data provided by most of the electronic meters can not only be used for billing, but also be harnessed for a host of other business processes like revenue protection, tariff design, energy accounting, load analysis, load control etc. Since different manufacturers use different techniques to store, encode and transfer the data; the need to evolve a mechanism that allows seamless integration into a unified data collection system was long recognized. Most of the existing and proposed solutions required huge reinvestment into new capital assets.

The utility, meter manufacturers and software developers, in an exemplary collaborative effort; came forward with an innovative solution to the problem, which not only alleviated the need for reinvestment into metering assets, but was also easier to manage and deploy. This paper reviews the basic tenets of the solution that has already been developed and being deployed in the country.

Contextual background

Issues associated with electronic metering, electronic reading and deployment of integrated data management solutions are not new to any utility. Many forums round the world have tried to address these issues. The general approach so far has been to adopt one of the many proposed standards of data exchange or “protocols” for electronic meters. Some attempts have also been made to use standards of data exchange coupled with standards of data interpretation. System integrators around the world have long realized that due to practical problems it has been near impossible to integrate different makes of meters using this technique even if they used the same “protocols”. For reasons well understood by the experts in the industry, such attempts have seldom yielded truly manufacturer-independent application software.

After reviewing the various options for data communication protocols; the utility industry forum concluded that most of the existing solutions did not meet the basic requirement of being able to harness the capabilities of the existing installed base of metering assets. Moreover adoption of such a technique would also not guarantee a truly manufacturer-independent system solution. While setting its strategy, the utility- industry forum did not lose sight of its key objective viz. to have unified high level application software that can be integrated with any compliant meter.

Most importantly they did not let their vision be stifled by having to choose one of the many available protocol options. However, they took note of the fact that many system integrators around the world have adopted a technique where

meters with diverse protocols could co-exist. These system integrators wrote their own application programming interfaces (API) to collect data from various meters and convert them into their own internal data format. Conceptually this is similar to use of “drivers” in electronic printers – each type of printer has its own capabilities and hence its own command structure; but the installation of the printer driver provides an interface between the printer and the operating system of the PC, so that the operation is seamless to the user.

The beauty of the Indian solution is that it has the flexibility of this second approach and yet congruence has been achieved by creating a de facto standard common data format which is open for anyone’s use. This not only allowed use of the existing metering assets but also put the onus of providing the application programming interface (API) on the meter manufacturers.

What is the essential difference between the two aforementioned models – one involving a common communication protocol and the other using an API to convert to a common data format? At a very conceptual level, the difference between the two approaches is evident from the diagram below. While it presents an over-simplistic view, it helps to appreciate why it makes greater sense to have the conversion intelligence at the PC end. Clearly, the complexity involved in making diverse meters talk a common PC language (protocol) is far greater than the complexity involved in converting the meter’s language to a common PC language at the PC by its powerful operating system.

Status of development

The forum for the development of the interoperability standard was formed in October 2004. Currently it has 8 member organizations. In this arrangement, each meter manufacturer provides a set of Application Programming Interfaces (API) for collecting data from their meters. Currently, two API’s have been developed:

(i) API for collecting data from meters and converting to respective manufacturer-specific format so that the data can be interpreted by the manufacturer’s application software

(ii) API for converting data from the manufacturer specific format to a Common Data Format (CDF) in XML (eXtensible Markup Language) so that any third-party software can use it for customer business applications. XML is well suited for platform-independent open applications of this nature and is also easily adaptable to future expansions.

Three of the leading meter manufacturers have already developed these two API’s. A third API for collecting CMRI data from HHU is also in the anvil. One of the leading utilities has already deployed the software in mass scale operation for collecting data from these three manufacturer meters using application software developed by one of the leading software development houses. More than 20,000 meters are being read using this interoperability system, a vast majority of which are using GSM as the communication medium.

The current specification “Universal meter reading and common format” is in version 1.60 and is freely downloadable from The forum also plans to develop a third set of API for transferring data in manufacturer specific format from the CMRI directly into the PC for conversion.

The system architecture

The system has clearly defined responsibilities which are traceable in case of any discrepancies. This is important for any multi party development. Each of the three elements – meter, its driver software and the application software have distinct roles to play in the overall system. The meter and the driver software together are responsible for measuring and providing the data in the standard interoperability format. However, the application software is responsible for creating (making the call and holding the line in a GSM AMR for example) and scheduling the communication link. Data security is an end to end responsibility so that data integrity can be guaranteed up to the database level. Providing the database suitable to the application is the responsibility of the application software. Data security can be managed by any open standard public domain technology so that it is verifiable and yet secure.

Benefits from the system
The common data format is a unique and open that has combined the benefits of open standards while maintaining the efficiency of manufacturer specific protocols. However, the most compelling argument in its favour has been its economic benefits.

a. Addresses installed base of meters: Each utility has a huge installed base of electronic meters. The interoperability standard achieved the objective of integration of these meters without having to invest into new metering assets. Traditional “standard protocols approach” required the utilities to reinvest into metering assets.

b. Flexibility to adapt: The interoperability standard has demonstrated the flexibility to adapt to diverse customer needs. Utilities around the world are deregulating and there is huge diversity of customer needs. The standard is designed to adapt to this continuously evolving requirement specification of the meters.

c. Retains the efficiency and comprehensiveness of individual meter communication protocols: Each meter design is different in its basic architecture. Collection of data from meters is not just discrete interrogation of information; most often it involves large file transfers of critical information which are optimized for speed and data security. The interoperability standard retains this innate strength of individual meter protocols and does not unnecessarily impose any protocol that would involve high communication overheads. This is particularly important in the context of recurring costs involved in handling bulk data.

d. Data security and integrity: Metering data is used for billing and hence is prone to fraud attempts like corruption, spoofing and eaves-dropping. Meter designers deploy different techniques to ensure data integrity by authentication and encryption.

The interoperability standard ensures that this security is retained while transferring data from the meters to the data collection systems so that end to end security can be built.

e. Portability to application software: The API’s allow easy integration with existing software for billing and revenue protection etc.

f. Practical and administratively inexpensive solution: Promulgation of any meter communication protocol would mean that each meter manufacturer will have to get conformity certification from independent agencies. We are all familiar with most of such standards, where the certification of conformity does not guarantee seamless interoperability. More complicated is the fact that the resolution of disputes arising out of mismatch of software becomes a nightmare. Since meter application software are written in low-level language, it will be almost impossible to decipher the reasons for failure when a utility finds that an application software was not running satisfactorily with a particular meter. It would be next to impossible to fix accountability in such cases

Clearly the system provides compelling benefits over traditional approaches of protocol standardization. The Indian experiment which started with the initiative of a few manufacturers, a utility and a software development house is fast being adopted by other manufacturers and electricity utilities. The interoperability standard has made the integration of existing metering assets with the new billing software possible. It is amply evident that this solution is not only a sufficient and elegant solution to the problem, but is also the most desirable solution.