SNMP for home automation

INTERNATIONAL JOURNAL OF NETWORK MANAGEMENT Int. J. Network Mgmt 2004; 14: 231–239 (DOI: 10.1002/nem.519) SNMP for home automation By Ran Giladi*† Home and building automation applications impose the need for convergence, or at least interoperability, of data networks with intelligent building networks. This situation entails the use of a unified management system. In this paper we extend the traditional SNMP-based network management system paradigm by creating an integrated site network management system that contains data elements, telecommunication equipment and intelligent building devices. A possible architecture based on a proxy gateway is presented and analyzed. We suggest an implementation and potential applications. Copyright © 2004 John Wiley & Sons, Ltd. Introduction R ecent home and building automation applications are information driven and impose the need for convergence, or at least interoperability, of intelligent building networks with data and telecommunication networks. This entails the use of a unified management system. In this paper we describe an extension of the traditional SNMP-based data network management system paradigm that will enable this interoperability and convergence. The following scenario, inspired from SUN’s introduction to JiniTM home automation project,3 can illustrate what intelligent building and data networks convergence is all about: Your alarm clock set itself automatically, based on your work schedule. Obviously, it will let you sleep, if you marked your PC calendar for a day off. While drinking your morning coffee (it was hot and ready, right on time) the TV broadcasts your most important messages (e-mails, SMS, etc.) and other filtered, interesting, last night’s newscasts, pausing when you walk away from the TV. When entering your office, you are automatically authorized to enter the floor, and your office and PC wake up. If anyone else enters your room or touches your PC without your explicit permission, the PC and the door lock themselves and notify security. While working, you’ll get an SMS message, asking you to approve a grocery purchase that your home generated; the detailed generated grocery list is in your e-mail. All of this could be a description of the first two hours of a regular day, and is not a scene from a science fiction movie. It results from computer networks and intelligent building networks convergence. And as these networks start to converge, there is a need for service provisioning and main- Ran Giladi is with Ben-Gurion University, and serves as an active chairman of DiskSites, Inc. and of InfoCyclone Inc., a company he co-founded in 2000 and served as its President and CEO. He is also a director of LanOptics Ltd. (NASDAQ:LNOP). Giladi was previously the founder and Head of the Department of Communication Systems Engineering at Ben-Gurion University (1992–2000). Prior to Ben-Gurion University he taught at the Business School and at the Electrical Engineering Department of Tel-Aviv University. Giladi co-founded Ramir Ltd., later acquired by Harris-Adacom, and served as Vice President of Research & Development for both companies. Giladi also founded the Israeli Consortia for research on network management systems (NMS), and served as the Chairman of the Consortia Board of Directors. His research interests include computer and communications systems performance, data networks and communications, and network management systems. Giladi received a B.A. in Physics and an M.Sc. in Biomedical Engineering from the Technion—Israel Institute of Technology, and a Ph.D. in Computers and Information Systems from Tel-Aviv University. *Correspondence to: Ran Giladi, Department of Communication Systems Engineering, Ben-Gurion University of the Negev, Beer Sheva 84105, Israel. † E-mail: ran@bgumail.bgu.ac.il Copyright © 2004 John Wiley & Sons, Ltd. Published online 4 May 2004 232 tenance that can be carried out only by a unified site management system. W e are witnessing a revolution in building intelligence that has transformed homes, offices, and buildings into proactive computing nodes We are witnessing a revolution in building intelligence that has transformed homes, offices, and buildings into proactive computing nodes, which in some cases, directly interfaces, with data and telecommunications networks, equipment and applications. Integration of data networks with environmental infrastructure devices is expressed in various scenarios such as physical security of data network elements, wireless mobile sensors, appliances that interact with the Internet, multimedia and entertainment applications, and various autonomous systems. Universal plug and play (UPnP),6 for example, enables management and information exchange between computers and peripherals (like routers or printers), as well as intelligent building applications (e.g., security, multimedia, air-conditioning, and lighting).7 The JiniTM Home Automation project mentioned earlier is another example of how data networks integrate with intelligent building networks. JiniTM is a general infrastructure for distributed computing between network devices that provides mechanisms to enable these devices to plug and work together automatically. The SNMP network management system, as well as most other traditional network management systems, relates to the management of network elements that are part of data or telecommunication networks. These elements are composed of computing nodes (e.g., PCs, mobile PDAs, etc.), computing peripheral nodes (e.g., printers, scanners, etc.), and network equipment nodes (e.g., routers, switches, access points, etc.). The network management framework covers configuration, security, accounting, performance, and fault-management applications. A generalization of network management is system management, which relates to computing, resources and application management. A further generalization, which is the objective of our research, is to extend Copyright © 2004 John Wiley & Sons, Ltd. R. GILADI the network management paradigm to include the surrounding data-network elements. Aside from enabling intelligent building network and data network convergence, there are other practical reasons for using SNMP for home automation. For example, there is a lack of a management framework for intelligent building networks that are composed of many heterogeneous devices. A unified management model to control these devices is a necessity, and SNMP can be used for this purpose, similarly to what was done in the case of data networks, when data networks were composed of heterogeneous elements. Another reason for using SNMP is that SNMP can expand network management to site management since current intelligent network devices are assigned by IP addresses. This paper presents an analysis and implementation of an integrated intelligent building network and SNMP-based network management system, in which all intelligent building objects on the intelligent building network are perceived by the network management system as managed objects. In the next section we present an intelligent building management scheme, which is followed by the proposed system architecture. The third section describes how we implemented the system, and the final section concludes the paper with possible applications. Intelligent Building Management by SNMP There are many approaches to intelligent building management, and numerous kinds of networks and protocols to carry out the building control tasks.3,4,5 Most of the approaches and networks emerged from industrial automation applications used in process automation, motorized vehicles, space industry, etc. Networks for industrial automation applications are known as field buses, or field area networks (FANs). Approaches to intelligent building management and FANs can be classified into two main groups: centralized management and distributed management. In order to manage a centralized intelligent building network by SNMP, an agent (a managed object) and a proper information description (MIB) is installed on the main control point of the system. By referring to this main control point, network Int. J. Network Mgmt 2004; 14: 231–239 SNMP FOR HOME AUTOMATION 233 management tasks can be executed. Implementation can be based on RMON, proxy agent, entity MIB, AgentX, or any other similar scheme. In distributed intelligent building systems, network management by SNMP becomes more complicated and requires a different approach. In this paper we focus on the European installation bus (EIB) standard, which is a distributed controlled network. We propose a management system for EIB that incorporates SNMP into EIB and vice versa. —The EIB Network— The EIB standard1 is based on the seven communication layers model. The first layer, the physical one, is based on power line, CSMA/CA twisted pair or wireless network, to which all the EIB devices (sensors, actuators, and interfaces) are connected. Upper layer protocols define message formats and addressing schemes, enable routing in the EIB network, and provide transport utilities and application services and interfaces. There are basically two types of devices in the EIB network: sensors that produce messages and commands upon events, and actuators that respond to these messages by changing the status of the physical devices (switching on or off, dimming, opening or closing, rotating, etc.). Every device in the EIB network has a physical address, which is used mainly to upload applications (e.g., what the device will do), and working parameters (e.g., time variables, thresholds, etc.). Every EIB device uses objects that are determined by the application. These objects are used to generate or receive messages, according to the object’s function. The messages are broadcasted on the EIB network, identified by the designated group address of the respective event that was the cause for these messages. All objects that are programmed to respond to these broadcasted events will be activated and perform the way their application dictates. In order to manage EIB devices by SNMP a proxy gateway must be used such that it will emulate all EIB devices as managed IP entities on the management network on one side, and listen to and submit EIB messages on the EIB network to the EIB entities on the other side (see Figure 1). The proxy gateway accepts SNMP messages, translates them and returns a formatted reply to the remote management system at the other end. It monitors and controls EIB devices continuously so that the correct status of the EIB system will be sent immediately to the management system once required. A manager on a remote host will be able to receive the status of the EIB devices in real time, setting and changing the state of a device and its objects when necessary. —MIB Design— The proxy gateway has to maintain an MIB that contains all the relevant information on every device in the EIB network. Because the MIB is predefined, and its dynamic structure is very limited, EIB information has to be generalized in a way that will enable representation of all devices and all common data, while maintaining specific information on each EIB device. The pooled information that is fetched from each of the devices is the building block of the information base. This information includes the value of each of the objects in every EIB device, all the group addresses associated with the device’s objects, and more general information such as the manufacturer and the type of the device. SNMP doesn’t allow simple creation of several instances of a single object. An agent that runs on a single host (with a single IP address) represents a single object and all its properties. Thus, a proxy E IB N etw o rk C o m m unica tio n N etw o rk M anag e m e nt S ystem P ro xy G a tew a y Figure 1. General design of system architecture Copyright © 2004 John Wiley & Sons, Ltd. Int. J. Network Mgmt 2004; 14: 231–239 234 R. GILADI index address type manufacturer values(table) groups(table) association(table) Figure 2. EIB data agent that represents all the EIB network devices is difficult to implement. Two methods were examined to overcome this problem. The first method is to build a huge table that contains all the EIB devices. The table is defined in the private branch of the MIB tree that will be reserved for the EIB network. Each row in the table contains the data of every EIB device (Figure 2). This table can dynamically respond to the EIB network structure and activity and match the instantaneous structure and up-to-date activities. However, this method is not convenient, nor applicable, because it represents the whole EIB network as a single entity and there is no need to use tables within tables. T he method is object-oriented, and is based on building an MIB that describes one single EIB device and its data. The second method is object-oriented, and is based on building an MIB that describes one single EIB device and its data. This allows the manager to select a single device, and reference only this device and its data. As such, every EIB device is represented as a different entity in the network, having in effect a unique ‘shadow’ IP address. This method is superior to the first method, since it saves a huge table I/O for each query or event to be handled. It also enables a more accurate representation of the EIB devices and their dynamic behavior. The organization of the designed MIB tree, along with its Object IDs (OIDs) is represented in Figure 3. There are three tables in the designed MIB tree that are read from the device’s memory. The object table (EIBComponent.2) represents the communication object table of an EIB device, including the value of each communication object. The group table (EIBComponent.3) represents all the groups that the communication objects in this device are attached to. The association table Copyright © 2004 John Wiley & Sons, Ltd. (EIBComponent.4) is the same as in the device memory, and represents the connection between a communication object and a group address. —System Architecture— The proxy gateway we designed is made of three modules: a driver for the EIB network, a network interface, and a proxy agent for the SNMP (Figure 4). The first two modules are in the lower level of the system, and do not interact directly with each other. The agent is the main application that uses the EIB driver to interact with the intelligent building devices, and the network interface to interact with the management system by SNMP. Figure 4 illustrates the relationship of the three modules. The EIB driver is responsible for all the communication tasks between the proxy gateway and the EIB network. The tasks that have to be performed include mapping of the EIB devices, reading a value from a device’s memory as well as setting it, sending group messages, and intercepting group messages (monitoring the EIB network). The network interface is more complicated to implement than the EIB driver. When using the object-oriented solution, multiple IP addresses are assigned to the same host, i.e., the proxy gateway. Each IP address reflects a single EIB device. A full EIB network consists of more than 64 000 devices, and is mapped to a class B IP network. Then the proxy gateway becomes a gateway to this EIB network. There are two ways to implement an EIB-IP mapping: translating an EIB-IP address by some calculation or mapping by a lookup table. Since an IP B-class address has its first two bytes reserved for the IP subnet and its last two bytes reserved for the host address in the IP subnet, and since an EIB address is less than two bytes long, a possible translation is to map the device address in the EIB network into the lower two bytes of the IP address Int. J. Network Mgmt 2004; 14: 231–239 SNMP FOR HOME AUTOMATION 235 1.3.6.1.4.1 bgucse EIB Component (1) manufacturer (7) address (1) details (6) group - table (3) object - table (2) objectEntry (1) association - table (4) groupsEntry (2) type (5) associationsEntry (3) associationIndex (1) objectIndex (1) value (3) groupsIndex (1) dataType (2) groupsAddress (2) objectNumber (3) connectionNumber (2) Figure 3. MIB design Proxy-Agent EIB driver Network Interface Figure 4. System architecture that represents this device in the IP network. The two most significant bytes in the IP address remain with the subnet ID assigned to the EIB network. The other alternative for mapping addresses is by Copyright © 2004 John Wiley & Sons, Ltd. using a lookup table that maps a specific IP address to a specific EIB address. This solution can be used for a very sparse EIB network, i.e., when there are only a few EIB devices that need to be Int. J. Network Mgmt 2004; 14: 231–239 236 R. GILADI EIB Network EIB PDU Dest Addr - 1.1.2 Address = 1.1.2 SNMP PDU Dest IP - 192.168.17.2 Address = 1.1.3 Manager SNMP Response PDU Proxy Gateway Translate IP address to EIB address. Activate proper API function. Construct response Address = 1.1.230 Figure 5. Data flow managed in an IP network, or when there is no way to use any dedicated IP subnet in the IP network. This method, however, requires assigning and managing specific IP addresses in the IP network, which could be troublesome. The network module sniffs all the packets in the IP network that the proxy gateway resides on, and picks up all the packets that were targeted to IP addresses that are assigned to EIB devices and have the correct destination port (port 161 for SNMP). When a message is being sent from the proxy gateway to the manager, an IP address is assigned (as described above) to represent the EIB device. The agent application runs on the proxy gateway, represents each of the devices in the EIB network, and behaves as a proxy-agent for the multiple devices. It receives queries from remote management systems, which consist of a request type (like GetRequest and SetRequest), a device identifier (IP), an object ID (OID) of the specific data in the MIB module that the operation should be applied to, and optional data (such as a value to send to the EIB device). The agent determines the address of the correct EIB device that the manager handles by mapping the IP address of the message to the EIB address. After determining the address and decoding the message, a new response message is built. The response message Copyright © 2004 John Wiley & Sons, Ltd. contains all the OIDs in the request message, and the values associated with each OID. When the request is a GetRequest (or GetNextRequest) the values are obtained by using the EIB driver interface in order to query the EIB system for the correct value. However, when the request is a SetRequest, the value of the communication object is set. If the communication object is a ‘sending’ object, i.e., one that produces events and commands, the value is sent to all the groups associated with that object. The defined MIB (Figure 3) contains three different tables: the communication objects table, the group table, and the association table. When a request arrives to one of the OIDs inside one of these tables, the length of the table is checked in order to ensure that the response is correct. Implementation The proxy gateway was built for several operating systems2 according to our design outlined in the previous section. The same internal infrastructure was kept and the code of the agent part was the same for each of the operating systems since the agent’s code is not hardware-dependent. We examined the proxy gateway with a very simple EIB network that contains a single device Int. J. Network Mgmt 2004; 14: 231–239 SNMP FOR HOME AUTOMATION 237 Figure 6. Manager view of the device’s objects with two communication objects. The EIB address of the tested device was 1.1.2 (0x11 0x02). The EIB network was connected to the proxy gateway. A private network address was used (192.168.0.0, which is defined as a private, non-routable address). The EIB device was mapped to the IP address 192.168.17.2. Since this address was defined as a non-routable address, a route entry on the manager host for the subnet 192.168.0.0 to point to the real proxy gateway IP address had to be added. In order to allow remote or routable EIB network management, a real IP subnet address had to be used on the proxy gateway. After setting up the system, the manager could load the defined MIB and query the proxy. A simple management tool was used (CA’s MIB Browser). Figure 6 shows the data that the manager received when querying the address 192.168.17.2 with the OID of the address, the type, the details and the manufacturer of the device. The proxy gateway responded to the 192.168.17.2 destination IP address, mapped the EIB device, queried it, and responded with all the data. The type and the manufacturer were read from the memory of the EIB. Figure 7 shows the table of communication objects for this device, Copyright © 2004 John Wiley & Sons, Ltd. which contains the index of the object, its data type and the value that this object contains. It was possible to set values of the EIB device by using the same SNMP interface (CA’s MIB Browser), or any other remote SNMP management platform. Applications Like many data network management systems, the proposed proxy gateway can be used as a management platform for various purposes, starting from the basic functional management areas (configuration, accounting, performance, fault management and security) and progressing to upper-layer management applications. T he proxy gateway can be used as a management platform for various purposes, starting from basic functional management areas and progressing to upperlayer management applications. Int. J. Network Mgmt 2004; 14: 231–239 238 R. GILADI Figure 7. Manager view of a device’s table An example of a functional area management would be a simple fault management, with event correlations and alarm notifications, based on TRAP messages and dynamically-defined thresholds for various sensors and actuators. This allows intelligent supervision of data-center presence, as well as the ability to recognize and handle faults that were created by environmental factors (power break, temperature, etc.). In addition, the proxy gateway can be used by a WEB-based network management system so that any qualified user can get intelligent building parameters by handling the MIB variables in an SNMP-based session, from anywhere in the Internet or Inranet. Thus, a user can ‘click’ on an icon representing an intelligent building device (shutter, door, light, air-conditioner, etc.) and operate it, change its operating parameters (temperature, sensitivity to light), or examine its status. Furthermore, applications can dictate working patterns to intelligent building devices according to data events or calculations (e.g., a personal calendar that produces SNMP messages for setting a beeper, or an air-conditioning system). Any sensor in the building can be used as an alarm trigger, air- Copyright © 2004 John Wiley & Sons, Ltd. condition control, or lighting control, depending on the SNMP message that arrived from the personal calendar. The proposed system can also deal with security issues in intelligent building management. Current intelligent building control and management systems lack security measures. Even UPnP or JiniTM does not secure intelligent building management (UPnP at this point is totally unprotected, although JiniTM is somewhat more protected because of its access control lists). Essentially, any tapped device capable of analyzing the intelligent building network traffic, which is not complex, can control intelligent building elements, including alarm systems, doors, shutters, etc. The proposed system can monitor security leaks in the intelligent building network management, since SNMPv3 itself contains security protection. Acknowledgement Thanks go to my two students, Yehuda SadehWein and Shachar Gang, who implemented this project, and with whom I very much enjoyed working. Int. J. Network Mgmt 2004; 14: 231–239 SNMP FOR HOME AUTOMATION References 1. EIBA Handbook for Developers, Series 3, Version 1, March 1999. 2. Gang S, Weinraub Y, Giladi R. SNMP interface for building automation components, Proceedings of EIB Scientific Conference 2000, Munich, Germany. 3. Home—The JiniTM Home Automation Project, http://home.jini.org. 4. Prayati AS, Kalogeras AP, Lorenz K, Koubias S. Engineering tools to support interoperability in the development and maintenance of heterogeneous distributed real-time control systems, Proceedings of International Workshop on Assurance in Distributed Copyright © 2004 John Wiley & Sons, Ltd. 239 Systems and Networks—ADSN 2003, Providence, Rhode Island, USA. 5. Sauter T, Dietrich D, Kastner W. (eds.), EIB, 2001, Publicis, Munich, Germany. 6. UPnP: WWW.UPNP.ORG 7. Wischy MA, Gitsels M. EIB—Universal plug & play gateway, Proceedings of EIB Scientific Conference 2000, Munich, Germany. 䊏 If you wish to order reprints for this or any other articles in the International Journal of Network Management, please see the Special Reprint instructions inside the front cover. Int. J. Network Mgmt 2004; 14: 231–239