Method and system for a set of network appliances which can be connected to provide enhanced collaboration, scalability, and reliability

IS 2 340 469 T3

DESCRIPTION

Procedure and system for a set of network devices that can be connected to improve collaboration, scalability, and reliability.

Technical field of the invention

This invention relates to a method and network appliance for establishing a peer review relationship between first and second appliances.

Background of the invention

Data traffic on networks, particularly on the Internet, has increased considerably in recent years and this trend will continue with the rapid growth of e-commerce and other Internet services that require higher bandwidth. With this increase in data traffic on networks, there has been a corresponding increase in the number of computer equipment rooms, known as “server rooms”, used to house the equipment necessary to support the routing of data traffic. In addition, the increasing dependence of companies on their Internet presence has created an urgency to keep server rooms up and running at all times. Industry estimates show that there are currently more than 400,000 such rooms in the United States.

The growth of Internet traffic has prompted many companies to build a server room to allow their employees to access information from the Internet or to enable e-commerce and data storage. Initially set as a goal, the fact that the server is continuously active has become a necessity. Keeping track of the many computers, along with their associated bridges, routers, backup power supplies, etc., can be a daunting task. A large company with server rooms in more than one city must spend thousands of euros on software packages to keep its equipment running. Typically, the price of a computer is approximately 738 euros ($ 1,000). Specialized technicians are also needed to monitor network equipment and issue work orders to repair faulty units.

To be reliable, modern computer systems must not withstand excessive heat, dust, or humidity. Heat can quickly cause equipment to deteriorate. A failure in the cooling fans can reduce the useful life of the equipment to days or hours. A failure in a single high-speed LAN (local area network) can cause slow system response. These and other such failures in server room equipment occur routinely and can cause major disruption to a business.

Currently there are solutions to monitor computers and computer networks to prevent such failures. However, these solutions are primarily aimed at large high-end systems such as those used by large corporations or institutions that have high budgets to support equipment supervision. For example, Hewlett-Packard provides a high-end monitoring package with a starting price of approximately € 184,775 ($ 250,000). At a medium level, more modest monitoring solutions can be found for approximately € 14,782 ($ 20,000). Some of these systems only allow device inspection locally. Others allow a technician to geographically survey multiple facilities from a central console. However, all these solutions are expensive to implement and complex and difficult to maintain and train the personnel who use them.

As a result, small and medium-sized businesses that own small and medium-sized networks need a means to monitor and maintain their computer network equipment in order to avoid malfunctions, but they do not have the resources to purchase the expensive solutions available today. Many companies cannot afford a high-end solution or simply do not have the time or resources to train their IT staff to learn and use complex systems. In contrast, the usual monitoring procedure in many of these companies is complaints that users transmit to the person in charge of the IT staff to indicate when a problem has occurred. The idea is for someone in the organization to report a fault and request it to be repaired before problems occur. However, the reality is that most IT staff have had to deal with problems in the server room due to excessive heat, some other physical phenomenon, or simply a failure.

This is especially the case in companies that have multiple server rooms and have problems with routine access to each of these rooms. For example, most IT personnel require some form of remote access to determine the status of a server room. In addition, with current solutions there are problems related to the labor ratio of these solutions. Most network monitoring solutions may require a full or part-time employee. Therefore, the economic justification of these systems is difficult as network equipment usually fails from year to year or when a very serious error occurs, and the repair cost is less than keeping a full-time employee to supervise teams routinely.

IS 2 340 469 T3

For monitoring rack-mounted components, there are similar issues related to the possibility that individual components placed in a rack can be remotely monitored. Also, current monitoring solutions do not provide video imaging of remote server locations on a network. Computer equipment is normally arranged in server rooms for two reasons: security and environmental control. The remote generation of video images from a server room on a network can keep equipment safe despite the absence of a physical presence on site.

A typical computer room can house hundreds of devices ranging from expensive computers with server functionality to bridges, routers, DC power supplies, and telephone equipment. The server room environment requires monitoring as extreme environmental variables can ultimately affect the equipment in the room. For example, high temperatures, humidity (due, for example, to water leaks), or the absence of air flow can damage the equipment. Similarly, it is important to determine alarms, such as smoke and fire alarms, or the status of room openings. Although the cost of replacing components in a server room if they fail is very high, currently available monitoring solutions are not cost effective to deploy in small businesses despite the potential costs of these losses.

Monitoring systems are typically implemented as simple, self-contained devices with which a user or an application can interact and perform configuration tasks. Most devices allow one or more users or applications to interact with them, but the user or application must normally interact with each device separately.

These typical monitoring systems use a centralized application (either an extension to a network management system, such as HP OpenView, or a proprietary server or console application). Although these mechanisms can be quite effective, they add additional costs due to software, hardware, configuration, administration, and network bandwidth. Additionally, the central server / application typically adds a single point of failure to the environment.

Another problem with standalone appliances, particularly with devices whose primary purpose is to monitor environmental and / or network conditions, is their vulnerability to unreported failures. Specifically, if the monitoring apparatus has a failure, detection of the failure typically requires user interaction or interrogation by an expensive centralized management server. The consequence of not detecting the faulty device is not being able to detect the conditions that the device was supposed to monitor, not being able to obtain information during that period of time.

In the event of an appliance failure, the typical standalone appliance lacks mechanisms for external storage and restoration of data, specifically configuration and history data. This can add significant overhead and the possibility of errors when replacing a faulty device as the new device will need to be successfully reconfigured to adopt the functionality of the faulty device. Mechanisms can be implemented to save and restore device configurations on external servers, but again it creates the problem of additional costs and points of failure.

Beyond application in server rooms and rack network equipment installations, various other monitoring systems suffer from the same failures and deficiencies associated with network bandwidth and undetected sensor failures. In addition, these supervision systems can suffer loss of historical data associated with the failure of a sensor.

Therefore, many typical remote monitoring systems suffer from deficiencies caused by undetected sensor failures and limited communications bandwidth. Many other problems and disadvantages of the prior art will become apparent to one skilled in the art after comparing the prior art with the present invention described herein.

US Patent No. 5822302 describes a system that automatically monitors a Data Center Operations (DCO) network (or any LAN / WAN network) to detect circuit breakdowns and sends a notification if a fault is detected. fault. A console in a remote operations center periodically verifies the connection to a console in each data center (connection verification can also be done on demand). The remote console receives responses from each console in the data center to which the connection was verified. A response will be received for each possible route between the data center and the remote operations center. These responses indicate the route that has been taken, and the routes indicated in the responses are then compared to a table of routes previously identified as relevant or routes of interest.

US Patent No. 6138249 describes a method and apparatus for monitoring a plurality of data processing systems from a monitoring system. The data processing systems can be coupled to the supervision system through a network cloud. When one of the plurality of data processing systems experiences a failure, the failure is detected in the monitoring system based on communications over the network. The data processing systems may each have a service processor coupled directly to the network cloud. The monitoring system can also be used to monitor the status of data processing systems, either in a manufacturing / test environment or on site.

IS 2 340 469 T3

US Patent No. 6094676 discloses an arrangement whereby peer-to-peer communication can be established between two remote computing units via a network channel, even though a permanent network address is not known. A sending computer sends a message through a supervisory channel, such as a circuit switched telephone line, to a receiving computer creating or triggering an event. In response to the trigger event, the sending computer or the receiving computer determines a network address associated with either the sending computer or the receiving computer. Then, using the network address, peer-to-peer communication between the sending computer and the receiving computer is established through the network channel.

Summary of the invention

According to the present invention there is provided a method for establishing a peer review relationship between a first and a second network appliance according to claim 1, other aspects of the present invention referring to a network appliance according to claim 7, an appliance network arranged with a second network appliance as a network appliance grouping according to claim 13, and to a program of instructions executable by a machine to carry out the procedural steps of the aforementioned method, according to claim 19.

Aspects of the invention relate to a network appliance or device. The device can have one or more sensors. These sensors can measure, for example, environmental variables, energy-related variables, video or still images, sounds, network variables, etc. In addition, the network apparatus can send data, alerts, alarms and / or other notifications associated with the sensors and the measured data.

Furthermore, the network apparatus may be connected to an interconnected network. Through the interconnected network, the network appliance can communicate with another network appliance and / or with one or more remote monitoring systems.

The network appliance can also send data, alarms, or other notifications through various means of communication. These media may include telephone networks, modems, paging networks, other wireless communication media, auditing media, visual media, web-based media, etc.

A further aspect of the invention relates to a communication method between network apparatuses. A network appliance can establish a relationship with a peer network appliance. The network appliance can then verify the connection with the peer appliance. If the peer appliance does not receive one or more consecutive connection checks, the peer appliance can determine the operability state of the network appliance. In the event of a fault, the peer apparatus can send an alert to a remote monitoring system, a responsible party or another peer apparatus.

Communication can use various protocols including, for example, HTTP, SNMP, TCP / IP, FTP, LDAP, SOAP, UDP, IBM MQSeries messages, and mechanisms including, for example, HTTP POST procedure, CIM events, alerts DMI, database inserts, log file additions, etc. However, other protocols may be developed or devised.

By using a connection verification procedure in conjunction with notifications when a specific status is measured, the system can monitor a plurality of conditions at a remote location and detect device failure while limiting the bandwidth used to communicate the measurements. Thus, a remote monitoring system can be established between a cluster of remote network appliances and facilities in a separate location.

Another aspect of the invention relates to a grouping of network appliances. The grouping of network appliances can establish various relationships between peers. In addition, the fixture grouping may establish a directory of fixtures and their associated capabilities, features, and / or functions. With this directory, the appliance pool can share resources. In this way, the grouping can carry out more complex functions. In addition, the grouping can perform the function of a defective apparatus.

A further aspect of the invention relates to a remote monitoring system. The remote monitoring system may include one or more network appliances connected to an interconnected network. In addition, a remote system can monitor the network device (s). Alternatively, the remote system can communicate with a single dominant network appliance. This dominant network appliance can act as an intermediary between the remote system and other network appliances in the cluster. In addition, the dominant network appliance may maintain a directory of the capabilities of the other network appliances in the cluster.

Furthermore, a standby appliance of the dominant network appliance can act as a peer observing the dominant network appliance. In the event that the dominant network appliance fails, the backup appliance can function as the intermediary and / or maintain the directory.

Another aspect of the invention relates to a computer or machine readable medium with a set of instructions for carrying out the communication procedure. The medium can take various forms including a CD-ROM, a CD-R, a CD-RW, a DVD, a hard disk, a floppy disk, a removable medium, and so on.

IS 2 340 469 T3

Therefore, an apparatus and method for monitoring remote locations are described. Other aspects, advantages, and novel features of the present invention will become apparent from the detailed description of the invention when considered in conjunction with the accompanying drawings.

Brief description of the drawings

For a more complete understanding of the present invention and its advantages, reference is now made to the following description taken in conjunction with the accompanying drawings in which the same reference numbers indicate the same characteristics, and in which:

Fig. 1 is a schematic block diagram of a system for remote monitoring.

Fig. 2 is a schematic block diagram of an exemplary embodiment of a system for remote monitoring in accordance with the system shown in FIG. 1.

Fig. 3 is a schematic block diagram of an exemplary embodiment of the system shown in FIG. 1.

Fig. 4 is a schematic block diagram of another exemplary embodiment of the system shown in FIG. 1.

Fig. 5 is a block flow diagram of an exemplary method for use in the system shown in FIG. 1.

Fig. 6 is a schematic block diagram of another exemplary embodiment of the system shown in FIG. 1.

Fig. 7 is a schematic block diagram of another exemplary embodiment of the system shown in FIG. 1.

Fig. 8 is a block diagram of an exemplary embodiment of the network apparatus for use in the system shown in FIG. 1.

Fig. 9 is a diagram illustrating an exemplary embodiment of a directory for use in the system shown in FIG. 1.

Fig. 10A is a schematic block diagram of an exemplary embodiment of the system shown in FIG. 1.

Fig. 10B is a schematic block diagram of an exemplary embodiment of the system shown in FIG. 1.

Fig. 11A is a block flow diagram of an exemplary method for use in the system shown in FIG. 2.

Fig. 11B is a block flow diagram of an exemplary method for use in the system shown in FIG. 2.

Fig. 12 is a schematic block diagram of another exemplary embodiment of the system shown in FIG. 1.

Fig. 13 is a block flow diagram of an exemplary method for use in the system shown in FIG. 2.

Fig. 14 is a block flow diagram of an exemplary method for use in the system shown in FIG. 2.

Fig. 15 is a block flow diagram of an exemplary method for use in the system shown in FIG. 2.

Corresponding reference numerals indicate corresponding parts throughout the various views of the drawings.

Detailed description of the preferred embodiment

Fig. 1 is a schematic block diagram of the system according to the invention. The system 10 can have a remote supervision system 12 and a supervision system 14. In addition, the system can have multiple remote supervision systems 12 connected to a supervision system 14. Also, a supervision system

ES 2 340 469 T3 remote 12 can be connected to a plurality of supervision systems 14. Thus, a remote supervision system 12 can collect data from multiple supervision systems 14. Alternatively, one supervision system 14 can send data to a plurality of remote monitoring systems 12. In addition, a plurality of remote monitoring systems 12 may be connected to a plurality of monitoring systems 14 or in various other combinations.

The remote monitoring system 12 can take various forms. These forms may include a remotely located computer or set of computers, a telephone, a smartphone, an email phone, a pager, a portable device and / or an alarm system, etc. In addition, remote monitoring system 12 can access, monitor, and / or communicate with monitoring system 14 through various means. These media can include email, web interfaces, pager interfaces, various networking standards, and so on.

The monitoring system 14 can take various forms. These forms can include one or more network devices associated with one or more sensors. In addition, network devices can communicate with other network devices. The sensor (s) associated with the network devices can take various forms. These forms can include temperature sensors, pressure sensors, air flow sensors, strain sensors, current sensors, microphones, cameras, camcorders, network sensors, infrared sensors, motion sensors, door sensors, etc.

The remote monitoring system 12 and the monitoring system 14 can communicate through various means. These media may include, where appropriate, global networks, wide area networks, local area networks, telephone lines, wireless networks, etc. In addition, the remote monitoring system 12 and the monitoring system 14 can communicate using various protocols. These protocols can include TCP / IP, Ethernet protocols, SNMP, HTTP, FTP, SOAP, UDP, IBM MQSeries messages, and so on.

The system shown in fig. 1 can have several uses. For example, in an exemplary embodiment, the system can be used to monitor a location where servers and other computers are stored. Thus, the user can monitor network resources from remote locations. However, many other embodiments are envisioned. Other applications are conceivable. These applications can include military, security, etc. applications.

Fig. 2 is a schematic block diagram of an exemplary embodiment of the system shown in FIG. 1. System 30 features multiple network appliances connected to an interconnected network. This interconnected network can be connected to the remote monitoring system through various means. The network apparatuses can communicate with peer network apparatuses through the interconnected network 32. In addition, one or more of the network apparatuses may communicate with the remote monitoring system 44. This communication may take place through the interconnected network 32 or through other means.

The interconnected network 32 can take various forms. These forms may include a global network, a wide area network (WAN), a local area network (LAN), wireless networks, and so on. In addition, various protocols can be used for communication between the devices. These protocols can include SNMP, HTTP, FTP, TCP / IP, SOAP, UDP, Ethernet protocols, Bluetooth protocols, etc.

Remote monitoring system 44 may communicate with one or more of the network appliances through the interconnected network or through other means. These other means may include wireless means and other networking means. For example, these means may include a global network, a dedicated connection, a telephone system, a radiolocation system, a modem, a wireless telephone system, and so on. For example, network appliances can send data over an interconnected network using an HTTP POST procedure or an FTP procedure. Alternatively, network appliances can send a text paging message to a responsible party informing them of an alarm condition. In another example, the system can make phone calls to responsible parties.

A network appliance can take various forms. In an exemplary embodiment, the network appliance is a device that can perform a well-defined set of functions and that is connected to a network. The device may include software to monitor, configure, control, and communicate the results of its functions. In addition, the device can be connected to an interconnected network. The device can also be configured, monitored and controlled from a remote location.

A group of network appliances can function as a cluster. In this case, a cluster refers to a collection of interconnected network appliances that can act as a single logical entity. The grouping can be logically associated or grouped to facilitate user interaction, and so on. This grouping or group as a single logical entity can take various forms. These forms can include grouping of devices associated with a specific location, room, building, user, role, purpose, network region, user group, responsible party, remote monitoring location, and / or or a server, etc.

IS 2 340 469 T3

In an exemplary embodiment, network appliances can be used to monitor a server room or location. Each network appliance can provide a specific function, monitor a specific variable or detect an output or an environmental state, etc.

For example, a network appliance can be set up to monitor environmental conditions such as air flows and temperature. Another network appliance may take the form of a camera. In addition, a network appliance can monitor the status and quality of the network. In a further example, a network appliance can be used to monitor the availability and quality of electrical power. In one embodiment, one or more of these various network appliances may be located throughout a room. For example, multiple temperature monitors may be located at various points in a room to acquire data associated with the room's temperature profile. In another example, multiple network appliances may be located in a server rack to monitor airflows, temperature profiles, and power quality in and around the rack. In this case, the network devices can communicate with each other or communicate with a remote monitoring system. In this way, the data associated with the location can be transferred to the remote monitoring system.

In addition, these network devices can be configured to allow alarm settings. The device, once an alarm condition has been met, can send an alert either to other network devices or to the remote monitoring system. In this way, complex behavior can be established so that when one network appliance meets an alarm condition, other network appliances will send their information to the remote monitoring system or respond accordingly. In an exemplary embodiment, a door sensor network appliance can be used to monitor the entrance to the server room or the entrance to the server rack. Once the alarm condition is met or after the door is open, the door sensor network device can send a message or alert to the other network devices. The other network devices may respond by sending additional information to the remote monitoring system or by performing some other function. For example, once the door sensor network appliance is activated, or an alarm condition is met, the door sensor network appliance can send a message to a camera network appliance. The camera network appliance can capture an image of the person entering the door and the network appliance can then send that image to the remote monitoring system or, alternatively, it can send the image to another network appliance. The other network apparatus may function to send the information or alert to a user through another system such as a telephone system, a pager, or through a modem.

Complex behavior can be achieved through peer-to-peer communications of network appliances. Fig. 3 is a schematic block diagram illustrating an exemplary embodiment of a communication between network apparatuses. According to the invention shown in fig. 1. For example, a set of network appliances may be connected to an interconnected network. These apparatuses can establish communication links between the various network apparatuses.

In an exemplary embodiment, a network appliance will periodically verify the connection with a peer appliance. If the peer appliance does not receive an expected connection check, you can establish that the appliance performing the connection check is not operational. In this way, a failure in an apparatus can be quickly detected.

Furthermore, once the peer apparatus has detected a failure, the peer apparatus may inform the remote monitoring location or another network apparatus regarding the failure of the first network apparatus. With this information, the other network devices can compensate for the failure and / or adopt the functionality of the faulty device, etc. Similarly, the remote monitoring location and / or a responsible party may respond appropriately.

In an exemplary algorithm, one network appliance may be assigned to monitor multiple network appliances. A network appliance may be configured to verify connection with a plurality of other network appliances and receive connection verifications from another set of network appliances. A network device can verify the connection with those devices that are verifying the connection with it and with other devices that are not verifying the connection with it, or it can be configured to verify the connection only with those devices that are not verifying the connection. connection with it. Thus, various algorithms can be established to facilitate peer-to-peer failure detection.

The peer-to-peer communication system can also be used to send alert messages over the network. The review system can also be used to send data, configure various system configurations, create complex behaviors, establish communication with a remote network, and more.

In an exemplary embodiment, a network appliance A can monitor network appliances B, C, and D. Thus, network appliances B, C, and D can verify the connection to network appliance A. Alternatively , network appliance A can verify the connection with network appliances B, C and D.

If network appliance A fails, is powered off, or has been removed from the system, then devices B, C, and D can become aware of the device failure or shutdown. For example, if device B is to verify the connection with device A and does not receive a response, device B can establish that device A is no longer in service. Alternatively, if device A periodically verifies the connection with device C and the periodic connection verification fails, device C can establish that device A is no longer in service. In another example, the

ES 2 340 469 T3 device A can perform a special connection check to report in relation to an imminent shutdown event or an expected shutdown event. That way, device B, C, and D can establish that device A is no longer in service. Devices B, C, or D can notify the remote supervisory system regarding device A failure or shutdown. In a further example, device B, C, and D may carry out communications such that only one device sends notification of the failure.

In addition, devices B, C, and D can establish new communication links and a new peer review relationship, as shown in Figure 4. For example, device B can communicate with device C instead of with appliance A. Since appliance D no longer requires the resources to supervise appliance A, you can establish a new supervision with appliance C. In this way, peer review can be automatically reconfigured.

In another exemplary embodiment, a new appliance G may be added to the system and / or connected to the network. Device G can establish a peer review with device B. Additionally, you can try to establish a peer review with device D. In an exemplary embodiment, device D may have the option of rejecting the peer review based on device D's resources, the number of peers that device D is already monitoring or by which it is being monitored, and / or other factors. Thus, the device G can then establish a peer review relationship with the network appliance F. In addition, the appliances can decide to end the peer review. For example, network appliance D may decide to end its review of appliance F. This decision may be based on the capabilities of the appliance, the number of other peer review relationships, network resources, and other factors. Alternatively, network appliance F may decide to end its peer review relationship with device D. This decision may be made for similar reasons.

Thus, peer relationships can be automatically reconfigured, can be used to monitor the status of other peer devices, can be used to transfer data between devices, to establish complex behaviors between devices, and so on.

The peer review process can use multiple protocols to establish communications. These protocols can include FTP, SNMP, HTTP, SOAP, UDP, TCP / IP, among others.

Fig. 5 is a block flow diagram of an exemplary procedure for establishing communications for the peer review process. The method 50 can be carried out by a network appliance. The network appliance can broadcast to find other network appliances on the network, as shown in block 52. However, the appliance can use one or more of a variety of mechanisms to determine the presence of other network appliances. appliances. For example, the mechanisms may include end user configuration, multicast, subnet broadcast, directory service queries, subnet address traversal, and more.

The network appliance can then verify the connection with and / or interrogate one of the other network appliances found in the network, as seen in block 54. This connection verification can take various forms. For example, connection verification can use the protocol of an HTTP POST message. The connection verification may include information such as the serial number of the requesting device, the planned period of time before the next verification connection, the IP address and host name of the requesting device, and a list of target addresses. SNMP for SNMP traps. However, connection verification can take various forms including, for example, HTTP, SOAP, SNMP, TCP, UDP, FTP, IBM MQSeries messages, and more.

The peer device can receive the connection verification, determine if it has the resources to establish a peer review process, and send a response. The network appliance can receive that response, as seen in block 56. The response message can include various pieces of information. This data may include data similar to the above data and / or may be associated with the functionality of the device location, the device address, a desired periodicity of future connection checks, the acceptance of the relationship, etc. The response may use various protocols including those listed above, among others.

If the peer device accepts the peer relationship, the network appliance can wait for a given period established in a communication between the network appliance and its peer, as observed in block 60. Then, a network appliance can verify the connection with the peer again, as seen in block 54. The peer device can decide if it is necessary to return a message in response. This establishes peer review.

In an exemplary embodiment, a network appliance may broadcast over an interconnected network to find the addresses of peer appliances. For example, the network apparatus may perform subnet broadcasting. Homologous devices can respond to this broadcast. The network appliance can then selectively verify the connection to one of the responding peer appliances. The network appliance can use, for example, an HTTP POST message or an FTP message with information related to the address of the peer appliance and / or the periodicity of future connection checks. In addition, the message may contain information about the functionality of the network device and / or information associated with the algorithms.

ES 2 340 469 T3 associated with the functionality of the network appliance. The counterpart device can reply with a message. The message can use, for example, an HTTP SNMP, FTP and / or POST message, etc. The message may include information associated with the acceptance of the peer relationship, the periodicity of future connection checks and / or the functionality of the peer device, etc. The network appliance can then selectively verify the connection to the peer appliance periodically.

In an exemplary embodiment, an appliance may optionally "verify connection" only with appliances that it must monitor and that are not currently "verifying connection" with it. Since a peer appliance periodically checks the connection to the network appliance, the absence of appliance connection checks can be used to detect its malfunction. If a device is intentionally turned off, the device can perform a special "connection check" with each of the devices that are "verifying the connection" with it and / or that are "being verified" by it to indicate their intention. of shutting down. This can be used to prevent these devices from reporting a planned shutdown or reboot as a failure.

In either case, an apparatus may be determined to have failed if a) a "connection check" from the apparatus should have been performed a long time ago or if b) one or more attempts to "verify connection" with the apparatus have failed. When a failure is detected, email addresses or other device-supplied contact mechanisms can be reported. Additionally, SNMP traps (with your agent address set to the missing appliance IP address) can be sent to the target SNMP addresses supplied by the appliance. Optionally, notifications can also be sent to email and to the SNMP addresses associated with the fault detection apparatus (in particular if the faulty apparatus did not supply this data).

With this algorithm, a network appliance can establish a peer review relationship with another network appliance. Furthermore, the network apparatus may selectively establish more than one peer review relationship. Furthermore, an algorithm can dictate the establishment of a plurality of peer relationships.

In this way, if a peer device is waiting for a periodic connection check from a network appliance, it can periodically set the operational state of the network appliance. If a connection check is not received or if a series of connection checks has not been received, the peer device can establish that the network appliance is not operational.

A variation of the peer-to-peer check can be used for host-to-host communication. For example, each appliance can be configured to "verify connection" with one or more host web servers. In this case, the device does not detect or report failures of the target servers, but rather an application on those servers uses the information reported through the connection verification to know when to report the failure of a device and to whom to report the failure.

Other implementations of these mechanisms may use various protocols for the implementation of "connection checks" including HTTPS, SOAP, SNMP traps, proprietary implementations of UDP or TCP, IBM MQSeries messages, etc., as well as other alarm notification mechanisms that they include HTTP POST procedures, CIM events, DMI alerts, database INSERTS, additions to log files, and so on.

Network appliances can communicate with the remote monitoring system through various procedures. These procedures can include a paging network, a telephone network, a wireless network, an interconnected global network, a dedicated line, and so on.

In an exemplary embodiment, a periodic message may use an HTTP POST procedure. Similarly, other device-to-device and device-to-device communications and the remote location can use an HTTP POST procedure. The procedure can take a form similar to the following.

POST / HTTP / 1.1 message type

Host: 000.000.0.000:00

User-Agent: Software / version

Accept: 7 *

Accept-Encoding: gzip

Accept-Language: en

VARIABLE1 = 1% VARIABLE2 = 2% VARIABLE3 = value

Variables can contain information associated with the type of network device, software version, network ID, host name, devices, sensors, and other data.

IS 2 340 469 T3

In another exemplary embodiment, the messages may be sent using an FTP procedure. Thus, a message can take the form of a text file located on another device or server and appear as follows:

VARIABLE1 = 1

VARIABLE2 = 2

VARIABLE3 = value

These procedures can also be used to transfer images, sound, and other data. In addition, other procedures, mechanisms and protocols can be used to send, transfer and / or transmit data.

Fig. 6 is a schematic block diagram of an exemplary embodiment of a communication system between remote monitoring system 72 and network appliances 74, 76, and 78. System 70 may establish communication between remote monitoring system 72 and each of the network apparatuses A, B and C, 74, 76, 78. The remote monitoring system 72 can interrogate each of the devices. Alternatively, each of the devices 74, 76, 78 can transmit information to the remote monitoring system 72.

Communication between the remote monitoring system and network appliances can take various forms. These forms may include those listed above, among others.

In addition, the remote monitoring system 72 and network apparatuses 74, 76, 78 can communicate through various protocols. These protocols can include HTTP, FTP, SNMP, SOAP, UDP, TCP / IP, etc.

In an alternative embodiment, the remote monitoring system may be configured to communicate with one, two, or fewer than all network appliances. Fig. 7 is a schematic block diagram of an exemplary embodiment of a system for communication between remote monitoring system 92 and a cluster of network appliances. System 90 may include a set of network appliances 94, 96, 100, 102, 104, connected to an interconnected network 98. The remote supervision system 92 may be connected to one or more of the network appliances 94, 96. However, the remote supervision system may or may not be connected to the interconnected network 98 that connects each of the appliances 94, 96 , 100, 102, 104.

The remote monitoring system 92 may communicate with the network apparatus (s) 94, 96 through various means. These media may include those listed above, among others. For example, the remote monitoring system 92 may communicate with the D network apparatus 94 via a global network, a WAN, a wireless network, a satellite network, a dedicated connection, a telephone line, and so on.

This communication procedure between the remote monitoring system 92 and the network device (s) 94, 96 together with the peer review communications procedure can allow redundancy in the communication link between the network devices connected to the interconnected network 98 and the remote monitoring system 92. For example, the network device D 94 can establish a peer review communication with the network device E 96 via the interconnected network 98. In addition, the network device D 94 and the network device E 96 can have a means of communication with remote supervision system 92. If network appliance D 94 fails, network appliance E 96 can establish communications with remote supervision system 92. In this way, the network appliances A, B, and C can communicate via the interconnected network 98 with the network appliance E 96 which in turn can communicate with the remote monitoring system 92. In this way, the monitoring appliances Network A, B, and C maintain a communications link with remote monitoring system 92.

In an exemplary embodiment, a floating IP address may be used. The network appliance D 94 can set and acquire the IP address. If the network appliance D 94 fails, the network appliance E 96 can take the IP address and establish itself as the owner. In this way, the remote supervision system 92 will maintain communications with the appliances connected to the interconnected network 98 without reconfiguring itself. In an alternative embodiment, the network appliance E 96 may send a message to the remote monitoring system 92 indicating the change in the operating state of the network appliance D 94. In addition, the network appliance E 96 may send a message to the system of remote supervision 92 establishing itself as the owner of the communication link with network devices A, B and C.

In another exemplary embodiment, Network Appliance D 94 and Network Appliance E 96 may use different communication means to contact remote monitoring system 92. For example, Network Appliance D 94 may be connected to a global network. In the event that network appliance D fails, network appliance E 96 may present a modem that can call remote monitoring system 92. Furthermore, network appliance D 94 and network appliance E 96 may be connected to remote supervision system 92 through the same means but using different protocols in their communication with remote supervision system 92. For example, appliance Network Device 94 can use an HTTP POST protocol to communicate with remote monitoring system 92 and Network Device E 96 can use an FTP protocol.

Fig. 8 is a block diagram of an exemplary embodiment of a network apparatus according to FIGS. 1 and 2. A network appliance 110 may have a processor 112, a programmable circuitry 114, an interface

ES 2 340 469 T3 network 116, sensors 118, a storage medium 120, a clock 134 and a modem 136. However, the network appliance 110 may have all, some, or none of these characteristics. In addition, the network appliance can use several elements in different combinations to allow different functionalities.

Processor 112 can take various forms. These forms can include microprocessors and other circuitry. Processor 112 may take various data and / or operating instructions and use this information in conjunction with programmable circuitry 114, network interface 116, sensors 118, one or more storage media 120, a clock 134, a modem 136, etc., to allow the functionality of the network device and also establish communications with peer devices and / or their remote supervision system. Additionally, processor 112 may be arranged to operate with a Java-based operating system. Additionally, processor 112, in conjunction with the operating system, can function as a server and / or a web server.

Programmable circuitry 114 can take various forms. These forms can accept programming from various media including keyboards, graphical user interface devices, handheld devices, through the network interface, etc. In this way, the functionality of the network appliance can be adapted.

The network interface 116 can take various forms. These forms can include Ethernet, wireless Ethernet, ring networks, Bluetooth media, a modem, and a telephone line, among various other communication and network interfaces. Furthermore, the network apparatus 110 may have more than one network interface connected to similar or different communication media. For example, an appliance may have a connection to a private Ethernet network and an interface connection to a wide area network. Alternatively, another apparatus may have a network interface connection to a private Ethernet network and a wireless Ethernet interface. Thus, various apparatuses may have functionality associated with network interfaces 116. For example, a network appliance with a private Ethernet network interface and with a wireless interface can communicate with wireless sensors and communicate the sensor data to other appliances on the private network. In another example, an appliance may have a private Ethernet network interface and a WAN interface. Thus, the appliance can function to communicate information to and from appliances on the private network to and from remote locations. However, various combinations and functionalities associated with one or more similar or different network interfaces can be conceived.

In addition, the sensors 118 can take various forms. These forms can include temperature sensors, pressure sensors, power quality sensors, air flow sensors, microphones, cameras, camcorders, infrared cameras, door sensors, motion sensors, network sensors, etc. One or more sensors 118 may be included in the network appliance. Alternatively, the network appliance may have no sensor 118. In another embodiment, the network apparatus may have an audio or visual output speaker. Furthermore, the sensor (s) 118 may or may not be included within the network appliance 110. Thus, the sensor (s) 118 may be integrated into the network appliance 110 or outside the appliance. In addition, an external sensor may be uniquely connected to apparatus 110 such as, for example, an external temperature sensor, a motion detector, a sensor connected through a dry contact wire, and so on. Alternatively, the sensor (s) 118 may be external to the appliance 110 but be connected to more than one appliance 110 such as, for example, a UPS with multiple dry contact terminals, etc. In addition, the sensor (s) 118 may be external (s) to the appliance with a wireless connection, and may or may not be monitored by one or more appliances of a grouping of appliances such as, for example, a wireless temperature sensor. , a network device monitored via SNMP, etc. Individual sensors that can be monitored by more than one device are subject to inter-device load balancing, dynamic inter-device allocation, and device failover coverage.

Storage medium 120 can take various forms. These can include RAM, ROM, flash memory, hard drives, floppy drives, removable drives, DVDs, CDs, and memory cards, among others. The storage medium can store various operating instructions, data, and other information. This information may include networking and communication instructions 122, alarm and alert rules 124, peer-to-peer communication instructions 126, device-to-host communication instructions 128, various directories 130, data 132, and so on.

Communication and network instructions 126 may include implementations of various protocols, operating instructions for network interfaces 116 and / or modems 136, and other instructions for communications. In addition, storage medium 120 may contain sets of instructions for interpreting messages sent in various protocols. These instruction sets can be written as a CGI, a Java servlet, ASP, JSP, a PHP script, etc. Furthermore, these instruction sets can allow the network appliance to function as a web server. For example, instruction sets can be used to parse HTTP POST messages, receive FTP messages, and / or interpret messages sent using other protocols, procedures, and mechanisms.

Storage medium 120 may also contain alarm rules 124 and other algorithms, thresholds, and preset values. They can be used to indicate parameter values ​​about which a responsible party wishes to obtain information.

In addition, storage medium 120 may contain peer-to-peer 126 and apparatus-to-host 128 communication instructions. These instructions may control, for example, communication and communication procedures for various purposes with peer apparatuses and / or remote locations.

IS 2 340 469 T3

Additionally, directories 130 and other data 132 may be stored on the storage medium. Directory 130 may contain information associated with devices, addresses, host names, software, software versions, device types, device data, and so on. Also, the directory can be shared or it can be a replica of a shared directory. Data 132 may or may not be collective, shared, and distributed. The data 132 can be, for example, sensor values, lists such as SNMP trap targets, email notification lists, pager and telephone numbers, and so on.

Furthermore, a network appliance may have a clock 134. This clock may take various forms, and may be analog, digital, and so on. Clock 134 can be used in conjunction with sensors to establish the time at which a measurement was made.

In addition, the network apparatus 110 may have a modem 136 or other communication means for connection via a telephone line or other wired or wireless communication means. This may or may not be similar to network interface 116.

In an exemplary embodiment, the network appliance may function to measure the temperature at a point in a server room. The network appliance may have, for example, a processor 112, a programmable circuitry 114, a network interface 116, a temperature sensor 118, and various storage media 120. The network appliance may function to perform temperature measurements periodic. Furthermore, the network appliance may periodically review the connection with one or more peer appliances to establish group behavior. Furthermore, the network appliance can function to supply temperature data periodically or on request to the peer appliance or the remote monitoring system.

In an alternative embodiment, the network appliance may have a processor 112, programmable circuitry 114, a network interface 116, and a modem 136. The network appliance may use the networking interface to establish peer-to-peer communications with other devices in the system. In addition, following an alert from another device in the system, a network device can activate the modem and establish a new communication link with a remote monitoring system. Alternatively, the modem can be used to make paging, phone calls, or to carry out other communication functionality to alert a responsible party regarding the status of a peer apparatus.

An exemplary method of establishing complex interactive behavior between network devices such as modem activation in response to an alert from a peer device is the use of a device directory. Fig. 9 is a block diagram of an exemplary embodiment of a device directory. A device directory may contain a device identification, information related to the supported activities of each device associated with the device identification, and other data associated with the device and / or its functionality.

The device directory can be established through various means. These means may include broadcasting and / or connection verification with other devices found in the interconnected network. Peer devices can communicate information associated with those devices, the activities supported by those devices, and the data associated with the device and supported activities among themselves.

These communications and the directory can present various pieces of information. This data may include appliance network addresses, host name, appliance model, appliance software version, appliance sensors and appliances, appliance functionality and / or capabilities, algorithms, presets, tasks, etc. In addition, the data may include information about the sensors and appliance devices including, for example, local device IDs, device types, device tag, device location, and various attributes specific to the device type. The network appliance can also be programmed to report its data to directories on other devices after reboot, shutdown, and other events.

In addition, network appliances can be programmed to support queries to return supported device attributes and attributes. Network devices can be programmed to query other devices. Additionally, gadgets can support device and gadget ID validations to allow detection of old references to deleted devices.

The directory structure may allow network appliances to monitor devices and sensors of other network appliances and / or peer appliances. Thus, a network appliance can act in response to the value of a variable in another appliance. For example, a network appliance with a camera may monitor a door sensor of another network appliance. Furthermore, the camera network apparatus can send, transmit or transfer an image in response to the opening of the door.

Alternatively, a network appliance can control the behavior of another device. For example, using the directory, a device can determine the address of another device with email capabilities and control the delivery of a message through that other device.

In another example, a door sensor threshold may be defined in one appliance and offer the option of a multiple selection list of door sensors in different appliances registered with the directory, as well as a list

ES 2 340 469 T3 for multiple selection of cameras on various devices. The resulting threshold calculates the door opening on any of the door sensors to result in the generation, by the apparatus, of email with images captured from one or more different cameras.

In a further example, an email content settings panel for sensor alerts may offer a couple of add / remove list boxes to allow control of adding current values ​​from multiple sensors from multiple fixtures to the email.

In another example, a temperature sensor threshold may be defined on one appliance and offer the option of a multi-select list of temperature sensors on multiple appliances. As a result, a single threshold definition will be applied to these multiple sensors and only a single stream of SNMP alerts and / or emails will be generated as opposed to multiple messages from appliances with temperature sensors. Notification emails can include current values ​​for all selected sensors, as well as an indication of whether or not a given sensor generated an error.

To support these activities, each appliance can support an interface based on the HTTP POST procedure to query the current values ​​of multiple attributes. The interface can query using the unique device ID. For cameras and other specialty sensors, an interface based on the HTTP POST procedure can be used to return images, streaming data, sound streams, and other types of data.

Additionally, a configuration interface based on the HTTP POST procedure can allow the definition of thresholds on the appliance that will notify the configuration appliance when a violation has occurred. Widgets can support multiple instances of these thresholds per attribute. Additionally, a threshold violation notification mechanism based on the HTTP POST protocol can be used to inform the remote owner of the threshold regarding the violation.

Additionally, an interface based on the HTTP POST procedure can allow appliances to validate thresholds configured remotely on the appliance. This can be done by asking the apparatus that set the threshold if the threshold is still valid. Appliances can use this interface when there is a time slot available, such as network service interruption or appliance reboot.

In addition, an interface based on the HTTP POST procedure can also query the status of remotely configured thresholds on the appliance to allow synchronization between the appliance that configured the thresholds and the appliance that implements them. The query can be used, for example, after a reboot or a network service outage.

Additionally, an interface based on the HTTP POST procedure can be used to set the output variables of output devices. These devices can also support a current values ​​query interface.

Although the HTTP POST-based interface has been used for exemplary purposes, other interfaces are conceivable that perform various functionalities. These interfaces can use other protocols including FTP, SNMP, CiM, SOAP, TCP or proprietary UDP, LDAP, etc.

By allowing the specification of more than one directory service / appliance, a measure of fault tolerance is achieved. To aid in recovery from failures, directory appliances can be common to all elements of an application set, and they can be configured to recognize each other. When a directory service appliance is active, you can try to contact one of its peers and request a list of all appliances known to the peers. This list can be used to update the list of appliances known to the directory appliance and in turn used to request each of these appliances to republish their data to the appliance. Devices that are successfully connected but refuse to republish their data can be discarded.

In order to provide security, each directory appliance may support the option of setting a user ID and access password that can be configured on each appliance that attempts to join and use the directory. For added security, unique passwords may be required for each device attempting to use the directory. Other embodiments may support any of a variety of security servers (LDAP, Kerberos, DCE, NIS) or mechanisms (digital signatures, public-private key encryption).

In an alternative embodiment, a single network appliance can establish a master directory. The master directory network appliance can interrogate other appliances present on the network and receive information that can be stored in the directory.

Other means of fault tolerance with directory appliances may be to implement IP address-based failover between primary and secondary directory appliances. In this way, all fixtures will only reference and interact with a single directory fixture. This implementation may require each of the directory appliances to have a distinctive IP address, one of them further presenting (at a given time) the IP address assigned to the directory appliance. The primary directory appliance may have, by default, the IP address of the directory appliance and its own distinctive IP address. The secondary appliance can

ES 2 340 469 T3 have a distinctive IP address. Any updates from the primary device can be immediately communicated to the secondary device to maintain synchronization. On the other hand, the secondary apparatus can regularly interrogate the primary apparatus to check whether a fault occurs. If a failure occurs, the secondary appliance can, for example, activate the directory service IP address on itself, send free ARP solutions to the network to make any ARP cache on the network recognize the new address location IP, and adopt the role of the primary directory apparatus. After it has been replaced or repaired, the old primary directory apparatus can contact the new primary apparatus, synchronize directory data, and take on the role of the secondary directory apparatus.

Fig. 10A shows a network appliance A with a directory. Network appliances B, C, D, and E communicate with network appliance A to establish the directory. These apparatuses can communicate with network apparatus A through the interconnected network.

Furthermore, the network appliance can interrogate the network appliance with the master directory to locate resources belonging to other network appliances. In this way, a network appliance can enhance its own functionality by using features and functionality of other network appliances. For example, the network appliance B can detect an environmental variable. However, apparatus B may not have the ability to send e-mail over a global network. Network appliance C cannot detect environmental variables. However, you can have a connection to a global network. Thus, the network appliance B can consult the directory of the network appliance A to obtain information on the global connection of the network appliance C. The network appliance B can then communicate with the network appliance C to establish an external link. .

In an even more complex exemplary embodiment, network apparatus B may detect an environmental variable. Network appliance B may not have imaging functionality or connection to an external network. Thus, the network appliance B, after setting an alarm condition or other condition, can consult, for example, the network appliance A and the directory of the network appliance A. Then, the network appliance B can obtain information about the resources of the network appliances E, D and C. In this way, the network appliance B can communicate, for example, with a network appliance with a camera E. Network appliance E can then send an image via network appliance C via the external network. In this way, increasingly complex behaviors can be established using clustering while maintaining the autonomy of the various network appliances. Furthermore, the directory can be stored on various network devices.

As can be seen in fig. 10B, the directory may reside on network appliance E. For example, network appliance E may have established peer-to-peer communication with network appliance A. Following a failure or shutdown of network appliance A, network appliance Network E may have established the need for a new directory. Thus, the network appliance E may have acquired the directory from the network appliance A, or the network appliance E may re-poll and broadcast to discover the activities supported by the device and the various data associated with those devices and activities supported from the other network devices connected to the interconnected network. Another procedure to facilitate the transfer of the directory and any other data required by the cluster as a whole or by several devices in the cluster may need to establish a master list and a slave list.

Fig. 11A is a block flow diagram of an exemplary procedure for creating a directory. In procedure 140, a network appliance may determine the location of a directory, as seen in block 142. The directory may be stored on another network appliance. Alternatively, the directory can be stored on a server.

In the next block 144, the network appliance may inform the directory appliance and control the storage of information associated with the network appliance. This information may include addresses, resources, sensors, responsibilities, unique identifiers, data, peer relationship data, responsible parties, etc. In addition, the information may include configuration parameters.

In an alternative method, the directory device may initiate contact with the network appliance and request information for storage in a database. Fig. 11B is a block flow diagram of an exemplary procedure for creating a directory. The directory device can locate the network appliance, as seen in block 146. The directory device can use various means such as address traversal, SNMP trap, querying devices at known addresses, acquiring peer addresses from known devices, and so on.

As seen in the next block 147, the directory device can request data from the network device. Data can include addresses, resources, sensors, responsibilities, unique identifiers, data, peer relationship data, responsible parties, etc. In addition, the information may include configuration parameters. The directory device can then adjust the directory accordingly, as seen in block 148.

The directory device may take the form of a network appliance. Alternatively, the directory device can take the form of a server. Furthermore, the directory device may take the form of a

ES 2 340 469 T3 network appliance with access to a database residing on a server. Thus, the directory can be stored on the network appliance, on a server, on a network drive, and so on.

In a general embodiment by way of example, as seen in FIG. 12, network appliance A may have master data A. Network appliance B may have peer-to-peer communication with network appliance A and may establish a slave data set associated with master data set A. This may be For example, a master and slave directory or it can take the form of other data that is reciprocally useful for A or B or for other devices on the network. Furthermore, the network appliance B may contain the master list (master data B) which stores various other information. Furthermore, the network appliance C can store slave data for B and, more redundantly, it can store slave data for A. However, the network appliance does not need to store any slave data or any master list as noted in the network appliance D.

Also, one or more servers may or may not be connected to the network. The data may be stored on these servers. The data can take the form of a directory, master data, slave data, and so on. Thus, the server and the data can take various forms. These forms can include, for example, files on a file server, a database on a database server, an LDAP server, and so on. One or more of the network apparatuses coupled to the interconnected network may be clients of the server (s).

In this way, complex behavior can benefit in addition to collective data. For example, a responsible party may want an email after a given temperature condition. If there are one or more temperature sensors in the room, an alert rule and the associated pager number or email address and other data can be stored in a community accessible master data list. The information can further be stored in each temperature sensor device as a slave data set. That way, when a temperature condition is met, the notification can be sent to the responsible party. The temperature sensing device where the condition is met may choose to query the master data list to determine how, when, or what to do with the information. Alternatively, the network appliance can use the slave data list or data set to determine its behavior.

In this way, redundancy of the information accessible in a community way is allowed. Also, a user can change the desired information in one location and make that information universal.

Additionally, remote monitoring failover and load balancing can be implemented. A plurality of the features implemented by monitoring apparatuses can be based on observing through the network of another device, especially through protocols such as SNMP, CIM and HTTP. In the presence of multiple appliances, the choice of which appliances monitor which network devices may be associated with the functionalities and capabilities of the individual appliances. This can be used as the basis for the dynamic assignment of device monitoring tasks and a mechanism for failover of monitoring responsibilities if an appliance fails. Additionally, load balancing, failover monitoring, and dynamic mapping can be applied to shared sensor monitoring.

In the exemplary procedure 150 shown in FIG. 13 responsibilities and / or resources can be reallocated. For example, in the event that a peer device fails, as noted at block 152, a network appliance can access the directory to determine what resources, responsibilities, and contacts are assigned to the faulty device.

Resources can be, for example, data management, capabilities, functions, sensors, etc. Device failure can decrease the capabilities of a pool. Alternatively, devices that depend on the capabilities and functionality of the faulty apparatus can be reported of the fault. In this way, the devices that depend on the defective device can determine, by accessing the directory or other means, if they can and how they can access an alternative device, notify a responsible party regarding the loss of capacity and / or establish relationships between homologues, etc. For example, a device with a modem can act as a means of paging responsible parties. If this device fails, the cluster may lose paging capabilities. Furthermore, peer devices would lose a peer relationship. Thus, the cluster would need to find an alternative device with radiolocation capability or an alternative means of communication, eg alarms. In addition, new peer relationships can be established. However, several resource examples can be devised.

Responsibilities may include monitoring shared sensors, the directory or a backup directory service, a data warehouse service, peer relations, alarm monitoring, and so on. The network appliance that supervises the faulty appliance can reassign responsibilities. For example, the device may interrogate other devices to request acceptance of responsibility. The other devices can be found, for example, in the directory. For example, the device can access the directory to determine which other devices can communicate with a shared wireless sensor. Later, the device can assign or request the acceptance of responsibility from another device, as observed in block 156.

In addition, the device can notify the responsible parties regarding the failure of the peer, as observed in block 158. The device can access, for example, the directory to determine who the responsible parties are and how to contact them. .

IS 2 340 469 T3

In addition, the network appliance may adjust the directory, as noted at block 160. The adjustment may reflect appliance failure, appliance removal, reassignment of responsibilities, actions taken in response to the failure, and so on.

These steps may or may not be carried out in various combinations. In addition, various other procedures can be devised for the reallocation of resources, the dynamic allocation of responsibilities and the notification of responsible parties. Additionally, procedure 150 may be performed by a device prior to a planned shutdown or deactivation.

In one example, each widget in a widget set registered with a given set of directory widget (a "widget domain") may publish a set of records in the directory describing its remote monitoring capabilities. Specifically, a register can be defined for each type of remote monitoring that contains the number of devices that can be supported, the number of devices that are currently being monitored, the version of remote monitoring implementation, and other attributes specific to the monitoring type. Each record can be coded, for example, by combining the serial number of the device and the type of remote monitoring.

The contents of this capabilities directory will be used by configuration tools (to determine what remote monitoring capability is available and if any additional capabilities are available) and to respond to faults (as the directory will help determine what other devices may have assigned faulty appliance tasks).

Appliances registered in a given appliance domain can define the settings for any remote monitoring as a set of directory records. Each such record may include the remote monitoring type, the address and identity of the device to be monitored, the appliance serial number of the appliance that is currently monitoring the device, and any specific monitoring type settings.

In one example, when a new device is configured for monitoring, a new record can be added to the configuration directory without any initial apparatus assigned. The configuration tool can then query the capabilities directory to find a device with the required monitoring capability and the ability to monitor additional devices. The resulting list of appliances can then be sorted based on priorities such as subnet location relative to appliance, available capacity, and level of monitoring function. The configuration tool can then go through the ordered list, sending requests to each appliance to accept responsibility for monitoring the device until a appliance accepts that responsibility. The apparatus you accept can be set as the device's monitoring apparatus.

When a device fails, the peer device that detects the failure can query the configuration directory to find records pertaining to the faulty device. If you find any, you can request that the record be set as not belonging to any device (serial number = 0) and you can repeat the same allocation algorithm used for the initial setup until a new owner is found. If a device is shutting down or being removed from the device domain, you can repeat this same procedure on your own behalf by assigning your responsibilities to other devices. Additionally, these reassignment procedures may apply to shared sensor monitoring responsibility.

A plurality of other configuration items can provide considerable benefit if they are defined shared in the appliance domain directory. Specifically, shared objects for items such as user accounts and privileges, email notification templates, action response profiles, email notification lists, and SNMP trap target lists are beneficial.

To provide an efficient mechanism for these objects, the implementation of directory servers and clients can be enhanced to provide and support a configuration subscription mechanism with local and permanent caching of different records. Specifically, each appliance that is interested in a given shared object can subscribe to that object on the directory server. This can result in the apparatus receiving an initial copy of the record, as well as automatically receiving updates to that record when the "master" is up to date. Thus, the apparatus can then use the data without constantly requesting the information from the directory server and can also operate on the cached copy of the data if a network or directory server failure occurs. The subscriber list for each directory record can be permanently stored with the record on the directory server, so that a device that has been offline can be automatically updated when contacting the directory server.

Shared configuration objects can be published as named records to the directory server and can consist of a unique domain ID, tag, type, and list of object type-specific attribute / value pairs.

Shared objects can include user accounts, email notification lists, SNMP trap notification lists, email notification templates, action response profiles, and so on. User accounts can simplify access control management for a group of fixtures, allowing a unique user ID / password for all fixtures and a way to apply access control to newly added fixtures.

ES 2 340 469 T3 to the group. Accounts can support access control lists to access specific devices, devices attached to these devices, and other shared objects.

Email notification lists can allow the management of shared notification lists, so that the various notification actions configured on different appliances can be configured according to the need to interact with each appliance directly. Configuration attributes that refer to email addresses can support both explicit email addresses and symbolic references to shared email notification lists.

The SNMP trap notification lists, as well as email, where the SNMP trap targets are specified, can support explicit target lists and symbolic references to shared SNMP notification lists.

Email notification templates can be user-defined "form letters" for email alarm notifications, allowing the user to indicate what text to send and supporting macros for inserting various attributes of the apparatus and its devices and sensors. Allowing multiple widgets to share these definitions can provide easy and consistent customization of these notifications across many widgets.

Action response profiles can define a set of responses, including repeated actions and escalation, to detected alert conditions through thresholds or other means. Many consumers with multiple devices can allow these responses to be consistent and easily updated on their devices.

Directory resources and shared objects, among other elements, can be used to allow mass configuration of devices. In procedure 170 shown in FIG. 14, a user can define a configuration that is to be applied to multiple devices, as seen in block 172. The configuration can include action response profiles, email notification templates, SNMP trap notification lists, email notification lists, shared configuration objects, and so on.

The user can then access the directory or other storage device and store the configuration, as seen in block 174. For example, the user can access the directory device, the proxy device, the primary device, and so on.

The configuration can then be distributed as seen at block 176. The distribution can be carried out by interrogating devices assigned to the configuration, transferring the data to the device upon request of the device, and through other procedures.

Additionally, directory resources and shared objects, among other things, can be used to generate complex appliance behavior. For example, as seen in fig. 15, a procedure can be established to use shared resources. As observed in procedure 190, an apparatus can enter an alarm state, as observed in block 192. However, this step may or may not be included in procedure 190.

The apparatus may evaluate an established procedure, as noted at block 194. The established procedure may be instructions to inform a responsible party, control the behavior of another device, inform another apparatus, and so on. However, this step may or may not be included in procedure 190.

The appliance can access the directory, as seen in block 196. In this way, the appliance can determine the address of other appliances with desired resources. For example, a door alarm device can access the directory to determine the address of a camera device. Alternatively, a temperature sensing device can access the directory to determine the address of a radiolocation device. In addition, the appliance can access the directory to find notification lists, procedures, and other shared objects.

The appliance can access resources from other appliances, as noted at block 198. For example, the door alarm appliance can access images from the camera appliance. Alternatively, the door alarm apparatus may control the camera apparatus to send an image to a responsible party. In another example, a temperature sensing apparatus may control a pager apparatus to perform paging with a responsible party. However, several examples of complex behavior can be conceived.

In addition, to support a single fault-tolerant interface for configuration and application GUIs to interact with the appliance domain as a single unit, support for one or more "floating" IP addresses can be implemented (similar to the failover mechanism described for directory server). This may allow one of the appliances in the appliance domain to own a given additional IP address intended for access by external parties (ie web browsers, Java applications, etc.). Like the directory server, one or more backup appliances can be configured on the same subnet, so that a failure in the primary appliance can result in one of the backup appliances "claiming" the public IP address, allowing uninterrupted service.

IS 2 340 469 T3

In addition to supporting public IP address failover, appliances can support proxy requests to other appliances in the domain. For example, requests to access configuration data or sensor data for a given appliance can be made either by interacting directly with the appliance or by transmitting a request through the appliance possessing the public IP address. Proxy access can be done via the device serial number, so DHCP or other unannounced IP address reassignment can be supported. Allowing proxy access also allows access through firewalls to be better supported (since only the public IP address needs to be “open”). Shared user accounts can generally be used to support proxy requests, as the security context of the requesting application needs to be equally consistent for all appliances in the domain.

Thus a monitoring system has been described. In view of the above detailed description of the present invention and associated drawings, other modifications and variations will now be apparent to those skilled in the art. It is also apparent that these other modifications and variations can be made without departing from the scope of the present invention described in the following claims.