An Open Standard Protocol for Networking of Energy ... - IEEE Xplore

IEEE TRANSACTIONS ON POWER DELIVERY, VOL. 23, NO. 4, OCTOBER 2008

1749

An Open Standard Protocol for Networking of Energy Meters Santosh S. Chavan, S. Jayaprakash, and V. Jagadeesh Kumar

Abstract—An open standard protocol for networking of energy meters under the simple network-management protocol (SNMP) environment is proposed. Since the SNMP is quite popular for network enabling of uninterruptible power supplies, the necessary support hardware and software already exist. Hence, migrating energy meter connectivity to the transfer control protocol/Internet protocol-based SNMP would be an easy task. A sample network is created under the LabVIEW virtual instrumentation environment and studied to validate the proposed open standard protocol for networking of energy meters. Index Terms—Automatic meter reading, management information base (MIB), network-management system (NMS), networking of energy meters, simple network-management protocol (SNMP).

I. INTRODUCTION NE OF THE major components of operational cost in an electrical utility system is the cost of acquiring data on consumption of the thousands of consumers, spread over a large geographical area, connected to the system. Typically, acquiring data on energy consumption is accomplished by making a meter reader visit the premises of each and every consumer and record data manually. Time and again loss of revenue to the utility occurs because of human errors in acquiring data on the consumption of individual consumers. Automating the entire process of acquiring data and billing will reduce the cost by eliminating human intervention in meter reading. The task of collecting data on electricity consumption without human intervention is popularly known as automatic meter reading (AMR) [1]. To facilitate automatic data collection, the metering systems should be networked. Networking of meters through dedicated wires, power line communication and wireless channels are being explored [1], [2]. A common protocol is needed to enable networking of different types of energy meters. While MODBUS protocol [3] for AMR is in existence for more than three decades, the device language message specification with its companion specification for energy metering (DLMS/COSEM) protocol is quite recent [4], [5]. The MODBUS protocol, administered by the MODBUS consortium [3], was originally developed for a dedicated network of energy meters. Both the original MODBUS and the recent version, namely, TCP/IP enabled MODBUS protocols are implemented as a

O

Manuscript received August 7, 2007; revised November 21, 2007. First published July 9, 2008; current version published September 24, 2008. Paper no. TPWRD-00484-2007. The authors are with the Department of Electrical Engineering, Indian Institute of Technology Madras, Chennai 600036, India (e-mail: [email protected]; [email protected]; [email protected]). Color versions of one or more of the figures in this paper are available online at http://ieeexplore.ieee.org. Digital Object Identifier 10.1109/TPWRD.2008.917900

Master-Slave configuration and have shortcomings such as limited data types, lack of support for large binary objects and inflexible description of a data object. Since MODBUS is a master-slave protocol, a field device cannot report on its own (report by exception). The master must routinely poll each field device and look for changes in the data, thus consuming bandwidth. MODBUS, in the direct addressing mode is restricted to addressing only 247 devices on one data link, thus the number of field devices that may be connected to a master station is limited. This protocol also lacks the most popular “plug and play” and “re-configurability” options. On the other hand, IEC 62056, the recent specification, also called DLMS/COSEM, developed by DLMS user association follows the client-server approach and addresses all the drawbacks of the MODBUS protocol. However, the cost of implementing and maintaining the DLMS protocol is very high. Since DLMS/COSEM is not an open standard, comments, enhancements and augmentation are not possible. Hence, there is an urgent need [6] for the introduction of an open standard protocol for networking of energy meters, which not only enables automatic data collection but is also capable of controlling and monitoring through appropriate management systems. Any open standard should be capable of handling different types of energy meters that may exist on a utility. We now propose an open standard for management of an energy meter network utilizing the popular simple network-management protocol (SNMP). The proposed open standard is implemented under the LabVIEW virtual instrumentation environment thus bringing in operating system (OS) and processor (platform) independence, plug and play, reusability, and reconfigurability. II. PROPOSED OPEN STANDARD FOR NETWORKING OF ENERGY METERS UNDER SNMP The SNMP, defined in the request for comments (RFC) 1157 [7] is designed to provide network-management solutions. Of the three versions, SNMPv1, SNMPv2, and SNMPv3 [8]–[10], versions 1 and 2 have number of features in common with SNMPv2 offering enhancements over SNMPv1. SNMPv3 provides security features such as authentication, privacy and access control. Irrespective of the version, the basic components of SNMP are: network-management system (NMS), agent, and management information base (MIB). Fig. 1 shows the block diagram of SNMP architecture. The open standard proposed here augments the existing NMS, Agent, and MIB of SNMP to enable management of networked energy meters. To implement the proposed open standard for networking of energy meters under the SNMP environment, the following are developed.

0885-8977/$25.00 © 2008 IEEE

1750

Fig. 1. Block diagram showing SNMP architecture.

1) Hardware enabling of energy meters to communicate using TCP/IP. 2) Management information base (MIB) specific to energy meters. 3) SNMP agent for the energy meters. 4) SNMP manager for the management system (server). 1) Hardware Enabling of Energy Meters: All the energy meters to be networked are first TCP/IP enabled so that each one becomes a managed device (node) under the control of the network manager (central server) in the SNMP environment. Once the meters are TCP/IP enabled, each energy meter is uniquely identified with a 32-bit IP address, which can grow up to (4 294 967 296) possible unique addresses. IP addresses are represented by four sets of numbers (called octets) each in the range 0-255 (one byte) separated by dots as 100.201.102.001. The first set of octets represents the network portion (netid) that determines the number of possible networks and the remaining octets determines the number of possible nodes (hosts) supported by each of the networks. Three classes of networks, namely, Class A, Class B, and Class C are permitted in TCP/IP environment for addressing hosts. In the class A network, the first octet alone is used for the network address netid and the remaining octets are utilized for host addresses. Hence, in class A addressing scheme, the address range is from 001.xxx.xxx.xxx to 126.xxx.xxx.xxx, where xxx can have values from 0 to 255 and determine the host ID. Class B networks implement the first two octets (address range 128.yyy.xxx.xxx to 191.yyy.xxx.xxx), where yyy can have values from 0 to 255. Class C networks implement the first three octets for netid (address range 192.yyy.yyy.xxx to 223.yyy.yyy.xxx). The remaining addresses that are not covered are meant for special applications. Class A and Class C addresses are commonly used for setting up private local area networks (LANs), such as the one envisaged for networking of energy meters. In the case of Class A address scheme, 126


possible networks can have 16 million hosts (energy meters) in total and in Class C address scheme, 2 097 151 possible networks can have 254 hosts on each network. Hence, the proposed open standard can support networking of a large number of energy meters. Standard firmware is now available to TCP/IP enable the energy meters [11]. To implement SNMP, the next task is to develop a management information base (MIB) that is comprehensive to handle different types of energy meters that may exist in a utility. 2) MIB Specific to Energy Meters: In order to manage the resources (termed as objects) in a network, the resources are to be listed and the list made available at that node (energy meter) and the server. Hence, the MIB of the server contains all the individual MIB of the energy meters in the network. In SNMP, the management information base (MIB) serves this purpose. MIB lists all the objects in a tree structure [12]. RFC 1155 defines the structure of management information (SMI) and provides the general framework, within which MIB is to be constructed. Here, each object has a unique object identifier (OID) consisting of integers. MIB objects are identified for all the parameters of different types of energy meters that can exist in a utility and made compliant with the SMI standard procedure for creating and maintaining the MIB on the SNMP manager. For the present task, the MIB required for networking of energy meters, developed using a subset of ASN.1 (abstract syntax notation dot one) [13], is shown in Fig. 2. Beginning with the root of the tree, there are three nodes at first level, iso, ccitt, and joint-iso-ccitt. The iso sub tree is meant for different standard organizations, one of which is dod (department of defense) under which Internet activity board is allocated the internet node. In the MIB tree internet node has a private node which is used to identify objects defined by private enterprises under the enterprises node. The present energy meter MIB is developed under a private enterprise node, with private enterprise number (PEN) 20 983 issued in the name of iitmadras. The MIB developed for the proposed energy meter networking is suitable for handling different types of energy meters (single phase or 3-phase meters) on a single network. The MIB on the sever is a super set of MIB of different types of energy meters connected or to be connected in the network. It should be noted here that the proposed MIB for the energy meter is scalable and hence facilitates future expansions and or modifications. 3) SNMP Agent for the Energy Meters: An agent is a software module that resides on the managed device, in our case the energy meter, having knowledge of local MIB (can be a subset of global management information available on the management system) [14]. Fig. 3 shows the algorithm employed to build the agent for the energy meters. The agent synchronously responds to any one of the SNMP requests, namely, GetRequest and GetNextRequest from a management system (server). Any interrupts (e.g., alarm conditions) are reported by the agent to the SNMP manager employing the trap message under SNMP. The agent is also capable of setting/configuring parameters of the energy meter on receiving SetRequest command from the SNMP manager. Thus the developed agent also supports management capability. To implement SNMP command GetRequest, the agent invokes a request listener to create a threaded object, and request

CHAVAN et al.: OPEN STANDARD PROTOCOL FOR NETWORKING OF ENERGY METERS

1751

Fig. 3. Algorithm to develop an agent for requisite energy meter MIB.

Fig. 4. Algorithm employed to develop the SNMP manger. Fig. 2. MIB tree developed for the proposed open standard for networking of energy meters under SNMP.

handler, to carry out a request. The request handler then performs a specified action on the managed device through a device handler and then sends a response to the server. After finishing the request, the request handler deletes the threaded object to release resources. On the other hand for servicing traps (interrupts), the developed agent invokes a condition checker to iteratively check the managed device (energy meter) for alarm conditions. As soon as conditions become faulty or undesirable the agent will invoke a trap request to create a trap handler. The trap handler sends a trap to SNMP manager asynchronously and then deletes itself to release the resources for further use. Thus a connection between the agent of an energy meter and the manager of the management system is established whenever a requirement arises and closed as soon as the task at hand is completed. This aspect of SNMP reduces traffic on the network and hence avoids traffic congestion and bandwidth requirement. 4) SNMP Manager for the Server: SNMP manager is a service which employs a variety of tools, applications, and devices to assist human network managers in monitoring and maintaining networks. SNMP manager has a distributed

database, and performs auto polling of network devices. It manages high-end workstations generating real-time graphical views of network topology changes and traffic [15]. Typically SNMP manager is responsible for performance, configuration, security, fault, and accounting management of the SNMP-based network. The network-management system enables the communication between SNMP manager on the management system (server) and SNMP agent running on energy meters (client). The resources in the MIB such as energy meter parameters and energy meter tests are managed and controlled by SNMP manager. Manager in an energy meter network can use the acquired data for energy usage profiling, billing, demand forecasting, leak detection, remote shutoff, etc. The SNMP manager required for the present task is developed on the LabVIEW platform. The developed SNMP manger is an interactive graphical interface which is able to monitor the behavior of the developed network and poll energy meters. The major components of an SNMP manager are: SNMP requests, SNMP request-response, and trap messages. These components are developed using virtual instrumentation primitives available in the SNMP LabVIEW toolkit [16]. The primitives are combined to implement the required SNMP manager module. Fig. 4 shows the algorithm employed to develop the SNMP manger

1752


Fig. 5. Front panel of SNMP manager and expanded view of a 3-phase meter’s resources.

utilizing the SNMP primitives. The virtual instrument compiler (VI) in the LabVIEW incorporates the UC Davis MIB compiler. The MIB compiler converts the MIB names to appropriate object identifiers (OIDs) that correspond to authorized list of OIDs. The compiler also enables conversion of OIDs to MIB names in the reverse direction (when messages are received from energy meters). The formal definition of OIDs comes from the International Telecommunication Union Standards Committee

(ITU-T) recommendation X.208 (ASN.1). For the present task the private enterprise number (PEN) of 20983 was allotted by the Internet Assigned Numbers Authority (IANA). All of the OIDs are then implemented under the given PEN. The energy meter MIB is embedded in the developed SNMP manager through the aforesaid compilation process. Only after the compilation of the MIB is complete without errors, the SNMP manager can issue Get, GetNext, or Set requests to

CHAVAN et al.: OPEN STANDARD PROTOCOL FOR NETWORKING OF ENERGY METERS

an agent and decode GetResponse from agents and suitably operate the data base. III. EXPERIMENTAL VALIDATION OF THE PROPOSED STANDARD AND CONCLUSION In order to validate the proposed open standard under SNMP for networking of energy meters, a small network was designed. The requisite MIB for different types of energy meters is developed using the MG-Soft MIB Builder [17], which is shown as a tree structure in Fig. 2. The SNMP manager for the energy meter network is developed on LabVIEW 7.1 platform with the help of SNMP toolkit for LabVIEW-7.1 [18]. The SNMP agent development is carried out using AdventNet Agent C toolkit library [19]. The front panels of SNMP manager Virtual Instrument (VI) is shown in Fig. 5. The energy meter chosen is a three-phase meter, model QUASAR manufactured by Larsen and Toubro, India. The VI developed for this meter is also indicated in Fig. 5. The entire system works seamlessly and the data from the energy meters on the network acquired and stored on the server at regular intervals. To check the ability of the proposed open standard in handling interrupts, fault conditions were intentionally introduced in one of the meters. Since the communication between the SNMP manager and the agent in the managed device is direct, it is seen from the prototype network that the response to errors is quite fast. The open standard for networking of energy meters based on SNMP proposed here provides the flexibility to include any type of meter simply by extending only the MIB. Moreover a connection between the management station and a particular energy meter in the network is established as and when required and the connection closed as soon as the required task is completed. Thus the exchange of data on the network only takes place when a need arises, optimizing data traffic and thus conserving bandwidth. The developed network can operate with meters from different vendors as long as the meters are equipped with TCP/IP, SNMP agent, and MIB. Implementation of the proposed open standard protocol for networking of energy meters based on SNMP ensures total network-management solution including the implementation of automatic meter reading, network management and control. REFERENCES [1] Brothman, R. D. Reiser, and N. L. Khan, “Automatic remote reading of residential meters,” IEEE Trans. Commun., vol. C-13, no. 2, pp. 219–232, Jun. 1965. [2] B. S. Park, D. H. Hyun, and S. K. Cho, “Implementation of AMR system using power line communication,” in Proc. Asia Pacific Conf. Exhibition IEEE-Power Eng. Soc. Transmission Distribution, Yokohama, Japan, Oct. 2002, vol. 1, pp. 18–21. [3] Web page, [Online]. Available: http://www.modbus.org. [4] DLMS Std., CEN/TC/294/WG2 N.62E, Nov. 1996. [5] P. Fuchs and T. Schaub, “DLMS user association-coordination between applications and channels,” in Proc. 9th Int. Conf. Metering Tariffs for Energy Supply, May 1999, pp. 124–128. [6] J. Newbury and W. Miller, “Multiprotocol routing for automatic remote meter reading using power line carrier systems,” IEEE Trans. Power Del., vol. 16, no. 1, pp. 1–5, Jan. 2001.

1753

[7] Open Standard-RFC 1157, [Online]. Available: http://www.ietf.org/ rfc/rfc1157.txt. [8] W. Stallings, “SNMP and snmpv2: The infrastructure for network management,” IEEE Commun. Mag., vol. 36, no. 3, pp. 37–43, Mar. 1998. [9] W. Stallings, SNMPv1 SNMPv2 and SNMPv3, 3rd ed. Reading, MA: Addison-Wesley, Dec. 1998. [10] B. Artiz, A. Chandana, and U. Warrier, “Network management of TCP/IP networks: Present and future,” IEEE Network Mag., vol. 4, no. 4, pp. 35–43, Jul. 1990. [11] , [Online]. Available: http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1824&appnote=en012108. [12] D. Perkins and E. McGinnis, Understanding SNMP MIB’s, 1st ed. Englewood Cliffs, NJ: Prentice-Hall, Dec. 1996. [13] N. Miyauchi, T. Nakakawaji, K. Katsuyama, and T. Mizuno, “An implementation of management information base,” in Proc. 1st Int. Workshop Interoperability Multidatabase Syst., Kyoto, Japan, Apr. 1991, pp. 318–321. [14] J. Lee and P.-L. Hsu, “Design and implementation of the SNMP agents for remote monitoring and control via UML and Petri nets,” IEEE Trans. Contr. Syst. Technol., vol. 12, no. 2, pp. 294–302, Mar. 2004. [15] M. Subramanian, Network Management: Principles and Practice, 1st ed. Reading, MA: Addison-Wesley, Jan. 2000. [16] Web page, [Online]. Available: http://www.viodia.com. [17] Web page, [Online]. Available: http://www.mg-soft.com. [18] Web page, [Online]. Available: http://www.ni.com. [19] Web page, [Online]. Available: http://www.adventnet.com. Santosh S. Chavan was born in Pune, Maharashtra, India, on October 16, 1981. He received the B.E. degree in instrumentation engineering from SRTM University, Nanded Maharashtra, India, in 2002 and is currently pursuing the M.S. degree in electrical engineering from the Indian Institute of Technology Madras, Chennai, India. His research interests are in the areas of computer networks and digital design.

S. Jayaprakash was born in Jambuvanodai, India, on October 2, 1952. He received the M.Sc. degree in mathematics from the University of Madras, India, and the M.S. and Ph.D. degrees in computer science from the Indian Institute of Technology (IIT), Madras. Currently, he is with the Computer Centre, IIT Madras, and heading Campus Network Group. He was a UNDP Fellow with the University of Maryland, College Park. His areas of interest include computer networks and software engineering.

V. Jagadeesh Kumar (M’96) was born in Madras, India, on July 21, 1956. He received the B.E. degree in electronics and telecommunication engineering from the University of Madras, India, in 1978, and the M.Tech. and Ph.D. degrees in electrical engineering from the Indian Institute of Technology, (IIT) Madras, in 1980 and 1986, respectively. He is currently a Professor on the Faculty of the Department of Electrical Engineering, IIT Madras. He was a BOYSCAST Fellow at the King’s College London during 1987. He was a DAAD Fellow at the Technical University of Braunschweig, Braunschweig, Germany, during 1997. He was a Visiting Scientist with the Technical University of Aachen, Aachen, Germany, during 1999. He taught for one term at the Asian Institute of Technology (AIT), Bangkok, in 1999. His teaching and research interests are in the areas of measurements, instrumentation, and signal processing.