Because no standards exist to define communications with metering products, each meter manufacturer has developed individual protocols and data formats.
The Reason for Protocols
When utilities moved from electromechanical meters with pulse initiators that fed magnetic tape recorders to electronic recorders and meters, the need arose to extract the data captured by these new devices.
Register and profile data needed to be transferred locally to portable reading devices and remotely to central stations. So manufacturers had to design a method to physically connect the data collectors to metering devices.
In addition to the physical connection, each manufacturer had to develop a method for the data collectors to talk to metering devices. The sequence of commands that allows the equipment to communicate is commonly referred to as the device handshake, or protocol.
Implementing a Data Collector
Three major issues are involved when developing a data collector for a particular metering device:
1.How will the device physically connect to the meter? This connection is called the port into the device.
2.What are the procedures, or handshake sequences, required to communicate with the meter and extract data?
3.What is the format of the data? Users must know how the data is stored in the meter so that after collection it can be decoded and formatted for billing and other uses.
Definition of Protocol Can Vary
Now we come to the area of greatest confusion and disagreement. Some people narrowly define protocol to mean only the handshake, or sequence of rules, that allows communication. These rules apply to specifications including the number of bytes or characters per message; types of error detection codes used; speed, or baud rate, at which the data is transmitted; and communication time-out values.
When discussing protocols with others, especially if the subject is about standards, it is critical to understand their definition. Otherwise, users might conclude that a certain metering device is compatible with certain data-collection equipment when, in fact, it is not.
For example, two metering devices may communicate using the same handshake sequence but their data formats may be different. In this case the data-collection equipment may be able to retrieve data but would not be able to interpret the information correctly. So users who believe they are purchasing compatible equipment because it uses a particular protocol standard in reality may not be.
Extent of the Compatibility Problem
The easiest way to analyze the extent of compatibility problems involved with communications is to break them down into the three major issues: ports, protocols and data formats.
The communications ports into the metering devices fall into one of three categories: optical, RS-232 and telephone. The terms probing, direct connect and remote interrogation refer to each of these ports respectively.
As far as protocols are concerned, they tend to be manufacturer specific. Though some manufacturers have more than one protocol, their protocols usually have the same flavor, or are similar enough to be compatible.
Data formats, on the other hand, vary not only by manufacturer but also by metering-device type (see Figure 1). The problem is further complicated because the different device-data formats do not tend to have the same flavor, as with the protocol issue described previously.
The Good News and Bad News
There is some good news in all of this. First, letÕs take a look at the communication ports. Specific standards already exist in this area. Optical ports consist of the GE OPTOCOM port used in North America and the FLAG port used in Europe. For the RS-232 and telephone interfaces, there are national and international standards established outside the electric and gas utility industries.
The news about protocols and data formats, however, is not so good. There are fewer protocols than data formats, and these protocols are rather simple compared with some of the sophisticated protocols used today to link various computer systems.
The situation is just the opposite with data formats. The formats can be quite complicated. This situation originally was driven by attempts to squeeze as much data as possible into the limited memory of metering devices. Though technology has increased memory capacities, data formats continue to increase in complexity because of the number and types of metering quantities that are measured and stored.
What makes the complication and proliferation of data formats such a severe problem is the extensive amount of time required to convert data to a useable form. Of the time spent adding support for a new metering device, only 20 percent Ñ four to five days Ñ is required to implement the protocol. The remaining 80 percent Ñ four to five weeks Ñ is spent decoding and converting the data to a common and useable format.
Therefore, users can achieve benefits through protocol standards, but they will not receive maximum benefits until they also standardize data formats (see Figure 2).
Efforts to Create Standards
Groups that receive support from industry organizations such as AMRA, Edison Electric Institute and Industry Canada have been working to define standards for meter communications and data formats.
The proposed solution is to use a single protocol that supports all products with table-defined data. However, the only viable solutions available at this time are multivendor data-collection systems and handheld readers that support multiple protocols.
The objectives of these standards committees include:
1. Providing utilities with a choice of metering products from multiple vendors without limiting the communication protocol.
2. Providing utilities with the ability to retrieve data from a variety of metering products using a single handheld reader or central data-collection system.
3. Providing utilities with the ability to program, or initialize, a variety of metering products using a single handheld reader or central station.
Industry participants can use several methods to accomplish these tasks. One solution could be to use a single protocol with one definition of tables for storing data in metering devices. An alternative involves developing and supporting an integrated system that solves the operational problems of no single protocol or definition of data.
The integrated-system approach has worked because it addresses the problem of support for existing metering hardware. It also allows an environment for a standard protocol and transition to table-defined products for storing data.
Utility Translation Systems Inc. (UTS), based in Raleigh, N.C., has developed software to support more than 100 metering devices with different communication protocols and data formats. The following comments are based on this experience.
1. Two major categories require guidelines to add support for new devices: the protocol used for communications and the formats used for decoding meter data. About 20 percent of the development effort involves implementing the protocol; the remaining 80 percent involves decoding data.
2. The software required to read any device can be implemented within a relatively short time period, but it takes a significantly greater amount of time to implement software for programming the device. This is particularly true for electronic registers with time-of-use schedules and electronic multifunction meters.
3. Metering products come in many shapes and sizes. They range from revenue class watt-hour meters and electric volume correctors to pulse-based recorders and protective relays. All of these devices measure or store energy consumption data in many formats and forms.
These observations tend to support the concept of arranging data in a standard format, such as tables within a metering device. However, this approach can apply only to future products. Industry participants still have to address the problem of communicating with existing products that use a variety of protocols.
Overview of Multivendor Data Collection
UTS developed MV-90 as a multivendor data-collection system for electric and gas meters with software to implement the protocols of each manufacturer. Launched in 1988, the system evolved to support very large-scale systems and is in use at more than 450 utilities around the world.
Data collectors in the competitive British electric market use MV-90 to gather information from more than 70,000 meters each night. The California independent system operator uses MV-90 to read 3,000 meters on an hourly basis within a two-minute time period.
Though MV-90 was developed to provide a solution for multivendor data collection, the majority of software development has focused on data management, validation and editing, and analysis of data. The systemÕs layered software products enable services including real-time pricing; load curtailment; validation, editing and estimation; load research; gas nomination and balancing; and billing for large customers.
As the energy industry moves toward deregulation, the benefits of having data collection, validation and data estimation, load research and load profiling, aggregation of multiple meters, and large power billing integrated into a single system is becoming apparent. This capability allows all functions to be fully automated with a single database to collect and deliver usage data and billing information within critical time constraints.
Ed White is an executive vice president of Itron Inc., and chairman of Raleigh, N.C.-based Utility Translations Systems Inc., a wholly owned subsidiary of Itron. This article originally appeared in the AMRA Newsletter, Volume 11, Number 6. AMRA is an international organization dedicated to the application and advancement of enhanced customer service and resource-management technologies. ET