The electricity utilities all over world have invested a huge sum of money in electronic metering over the years. These meters have been purchased from different manufacturers. Since different manufacturers deploy different techniques to transfer the data, there is a need to evolve an interoperability standard that allows seamless integration of the data between various electronic meters and also provide integration with other developed application software like billing, load profile analysis, revenue protection analysis etc. irrespective of the type of meter in the field.
In this context, many attempts have been made around the world; people have tried to evolve common standards of communicating with and interpreting data from the meter. These approaches so far has been to adopt one of the many proposed standards of data exchange for electronic meters. Some attempts have also been made to use standards of data exchange coupled with standards of data interpretation.
Such attempts have not yet yielded manufacturer-independent high level software and were also having the following issues in implementing the same:
Existing installed base of meters: The countries having huge installed base of meters & millions of rupees have been invested in the procurement of these metering assets. The interoperability standard should be designed such that existing installed base of electronic meters can be read and integrated into the application software. Any new data reading protocol (like IEC 62056-21) would be unable to meet this requirement.
Flexibility to adapt: The standard must be designed to adapt to the continuously evolving requirement specification of the meters regardless of the requirements specific to a customer, utility or country.
Portability to application software: The standard should be such that it can be easily ported into existing (and yet to be developed) application software for billing, revenue protection, load and engineering analysis. In this context, any new meter- data reading protocol would mean communication interface level implementation on this software, which is not only difficult, sometimes impossible to achieve.
Practical approach: Over the years different bodies in the world have tried to standardize the data communication protocol with meters with the intention to design unique software that would be able to read all meters but none of them have achieved the goal of unique software.
Retaining the efficiency and comprehensiveness of individual meter communication protocols: Collection of data from meters involves large file transfers of critical information. Hence speed and accuracy are of prime importance. Any superset standard that unnecessarily tries to impose a data communication standard rather than a data interoperability standard tends to be sub optimal in its performance.
Hardware Limitation: Requirement of specific hardware in to the meter in order to provide interoperable solution, rather the solution should be hardware independent so that it could provide backward & forward compatibility.
Communication Protocol: Keeping rapid changes in meter protocol as per the requirement, the solution should be independent of communication protocol. Rather the same should have capability to adapt standard or any non standard protocol whether available nationally or internationally.
Administratively inexpensive solution: Acceptance & implementation of any meter communication protocol would mean that each meter manufacturer will have to get conformity certification from independent agencies. Since meter application software are written in low level language, it will be almost impossible to trace the reasons for failure when an 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.
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 asic 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, metering assets, but also put the onus of providing the application programming interface (API)on the meter manufacturers.
MIOS (Metering Interoperable System) under IEEMA took the initiative and suggested a solution on interoperability which provides best way to move forward for existing meters as well as all the future meters to come. The solution does not bind meter manufacturer for doing things in particular way. All meter manufacturers will have to supply APIs complying with the specification. The solution proposed will allow other parties (meter vendors as well as software vendors) to come & join. The proposed solution provides scope for both the vendors (meter, software) to use innovative ways of providing solution.
It is proposed that an interoperability standard be so defined that it meets all the requirements outlined above and does not lose sight of the key objectives of the electricity utilities.
According to this proposal, all meter manufacturers will continue to maintain their existing meter designs as optimised for their architecture and as they deem fit. However, they will each provide an executable plug in (e.g. a DLL file) that can be called by any third party high level software. The executable file will allow reading the meter data, check security, interpret and provide data in a common agreed data format. Such an agreed data format should be flexible for future expansion and adaptable to various customer needs. Open formats using languages like XML (eXtensible Markup Language) is quite well suited for this kind of application.
Each of the three elements – meter, its driver software and the application software shall have distinct roles to play in the overall system. The meter and the driver software together shall be responsible for measuring and providing the data in the standard interoperability format. However, the application software shall be responsible for creating (making the telephone call and holding the line in a PSTN AMR for example) and scheduling the communication link. Data security can be managed by any open standard public domain technology so that it is verifiable and yet secure.
To provide Common framework (CFW) for software & to specify interfaces so that modules can be attached with it.
The meter reading function enables CFW to read meter of any make. User will select the data to be read from meter. CFW will generate configuration file which will specify connection details and data to be read from meter. CFW will invoke Manufacturer reading module (API 1) to read the meter and store the data in manufacturer specific format in manufacturer folder.
Multiple meter reading option is applicable only when more than one meter is connected on the same network (or on the same telephone line). When multiple meters reading option is chosen each meter is read sequentially. Next meter reading is started once first meter reading is completed.
Supports existing installed base of meters.
One utility in northern India has developed their meter reading software using Common Frame Work (CFW) specification. They are reading around 22000 HT & LT meters through AMR. These meters are of different manufacturer make & model. Meters are installed in remote places at different consumer premises along with the GSM modem. At the central station common software is installed with the GSM / PSTN modem through port multiplier.
API’s of all the requisite meter is made available to the utility for reading & converting data in to the common format. These API’s works on windows platform and will get invoke through the common software (CFW).
Meters are read using common software. The common software is independent of communication port/media. Utility is using combination of GSM/PSTN communication media to read meters for AMR.
Utility has prepared a schedule which runs at every midnight till morning six, in between all the scheduled meters irrespective of the manufacturer / model is being read through GSM / PSTN modem.
Read meter data is converted to common format i.e. XML, which is made available to the billing software of the utility to generate bills. Further, the same data also taken to other data analysis software.
By using the above system utility is able to produce MIS reports, billing & data analysis though the common format having a common interface between all the modules.
Since utility meter reading software is developed as per the CFW specification, hence in order to add new manufacturer make meters or existing manufacturers meter with different model / communication media, no changes will be required in the software developed by the them. The complete system is independent of meter hardware & communication protocol. This doesn’t require any specific communication port or protocol to communicate. Hence the complete system is future proof, support backward compatibility and provides support to installed based meter.
MIOS interoperable solution doesn’t talk about the software features. Utility has developed a complete web based system, through which meter could be read from any web client PC. They have developed the complete system on their intranet, hence they can provide authorize no. of users to login and prepare schedule, execute the schedule view reports, view data, convert data which is to be integrated to other software like billing, data analysis, etc.
This takes less time since all the meter data is read from common software through AMR and produce the same common format, hence there is no delay in relation with the earlier process in which data read through different manufacturer specific BCS and then converted into ASCII format (which was different from different BCS), then make all the format in an acceptable format of the target software, where by this solution provide faster way to do the same from common software with the common format with in the specified time.
As the above system is compatible with the existing installed base meters & future installation without making any changes in the field meters or increasing infrastructure and moreover this system can be developed & deployed by any third party on the published standard, hence many utilities have started understanding the concept and trying to implement the system in order to read multi-manufacturer make meters using one system. In this context, this system has been successfully implemented by one utility in north India for their AMR project.
Till date seven meter manufacturers in India have become the member of this forum and they are working on the same. Many more meter manufacturers are also interested and their membership is in pipeline.