Suggested Meter Standards

Introduction

Several metering systems are now available (or soon will be available) for service under real time pricing, including remote meter reading as often as needed. Two principles lead to requirements for standard specifications for such meters (but not to designating a single metering system): (1) provision of service on a variety of rate options including real time pricing, and (2) a need (due to consumer protection needs) for a meter to maximize the opportunities for use by alternative metering agents if a customer does not continue to be served by the agent that originally had the customer's meter installed. (We wish to avoid the possibility that an aggregator will have its customers invest in a meter that cannot be used by other aggregators.)

Beyond these requirements, there is little need for regulators to establish a specific meter system as a standard -- only a need to specify minimum specifications that can allow meters to be certified as meeting these regulatory goals. If it is taken as a premise that regulation should not be imposed if competitive markets are capable of functioning, and that competitive markets should be allowed to exist if they are feasible, then regulators should not choose a "winning" metering system; instead, regulators should allow markets to select the system that best suits their needs. Among the benefits of allowing on-going competition among meter vendors would be promoting innovation. By the same premise, if new choices among alternative generation suppliers require new investments in meters to be made, and new capabilities to be added to billing systems due to the market offerings the alternative suppliers wish to put forth, those alternative generation suppliers should be allowed to make the new investments in metering and billing, instead of the UDC, and receive a credit (or avoid paying a rate) for costs that the UDC does not incur.

Conceptual Metering Requirements

If a meter is capable of real time pricing, it is also capable of billing simpler rate structures (thus satisfying the first of the two principles stated above). Needed capabilities for new meters are therefore the following (as a preliminary concept): (1) ability to reliably store 24 hourly consumption data points per day for a period of time until the meter is read (minimum capacity of 3 TOU periods of energy and demand per day for 30 days, plus power factor data for larger customers; storage may be at meter or upstream database), (2) a specific core communications functionality that can be provided by all metering systems, (3) ability to detect meter tampering, (4) ability to verify accuracy of individual meters both before and after installation, and (5) meeting of safety standards. Metering systems should be free to extend these capabilities to address market needs. Note that these specifications address the characteristics of new meters and meter retrofits, and do not replace the need for protocols for billing competitive supplies using existing meters (i.e., use of load profiles).

The frequency of usage measurements and mechanism for storing recorded data should be relatively simple to ascertain. A core communications functionaity is the subject of the remainder of this paper. Detecting meter tampering and verifying accuracy would be subjects for separate papers.

A Common Communications Functionality

Communications functionality can be considered by analogy to communication between computers over local and wide-area networks. A network operating system processes the transmission of data between the portions of operating systems that control other tasks. In the early 1970's, the International Standards Organization (ISO) developed the Open Systems Interconnection (OSI) model to define specific functions for each of several layers of functionality that are involved in network communications, with the goal of international standardization of computer network protocols; the following table summarizes its layered structure. (For convenience, this table also presents this paper's conclusions about needs for standardization.) The protocol examined in cursory detail here, TCP/IP, follows a similar model, although it doesn't directly follow the OSI model, having been developed through a more expeditious process in the Internet Engineering Task Force (IETF) of circulation and revision of Requests for Comments (RFC). The TCP/IP layered model consists of the Application, Transport, Internet, and Physical layers (labelled "A", "T", "I", and "P" in the following table).

(Note: If your Web browser doesn't handle tables, click here.)

The available metering systems vary in their physical methods of communication for remote reading, and may vary in their methods of measuring electricity use; these functions correspond to the highest and lowest levels of the OSI model. (In contrast, communications over backbone lines between metering agents and the ISO will need to follow the ISO's requirements at all levels.) Therefore, in the preliminary assessment of needs for standardization listed above, these levels are not identified as needing standardization, while the intermediate levels do require standardization due to the need to preserve as much meter functionality as possible if a customer chooses service from a different vendor. Notably, the levels where standardization is needed are the same as those where the TCP/IP communications protocol provides a standard: TCP/IP supports a wide variety of application needs, and makes no effort to define the underlying network physical connectivity. Indeed, TCP/IP is used over a variety of physical media that is similar to what meter manufacturers are proposing for remote metering: radio, coax cable, twisted-pair wires carrying voice-grade (or lower) analog signals, and fiber optic (as well as ISDN, Frame Relay, etc.). (However, the need for standardization incudes a common high-level communications format at the OSI Presentation level, just like Telnet, FTP, and HTTP are common high-level formats that allow Internet communications to occur.) TCP/IP can accomodate extensions of the services that can be provided to customers over the same communication circuits (particularly Internet-based services); TCP/IP is used on all leading computer systems (MS-DOS/Windows, Unix, Macintosh, etc.). Other communications protocols lack the flexibility of TCP/IP: for example, IPX/SPX is not used in as diverse circumstances, NetBeui is not routable, and analog signals would be more difficult to multiplex for the large numbers of devices that metering involves.

Lest this discussion remain too technical, a couple of examples can help in clarifying the major points. First, I have a pager in case my family needs to reach me. The service company that sold us the physical device had alternative models with different characteristics, but the company could communicate with all of them. We are changing to a different service company, but the new company could also communicate with our existing pager, because they use a common communications protocol. Second, I subscribe to a mailing list through Internet e-mail that concerns amateur radio communications. Some members use conventional Internet connections while others use packet radio, but we can all communicate because we use a common communications protocol; in the "application" layer, subscribers use a variety of computer systems and mailer programs, which are all compatible because they follow the standards. Similarly, establishing a common protocol for communications between meters and higher levels of the utility system can allow for communications between different physical metering devices and over different communications media. The agent requesting metering data doesn't need to know whether the meter is read from a pole-top, a substation, or via the cable TV company, but just where to route its request to a device that can find the metering data. We then don't need to establish an exclusive metering system, but instead can allow alternative generation suppliers to offer the services that they feel will be competitive, and can allow meter vendors to continue innovating to serve their markets.

Conclusion

Therefore, DRA proposes that standardization should be adopted to require a core capability for TCP/IP communications, primarily in the Transport and Internet layers as these terms are defined in TCP/IP specifications, while allowing metering systems to differentiate among themselves in the Application and Physical layers and in additional communication features beyond the core capability. As noted above, other minimum specifications would involve measurement and storage capacity, tamper resistance, and verification of accuracy.