ES2340469T3 - Procedimiento y sistema para un conjunto de dispositivos de red que pueden conectarse para mejorar la colaboracion , la escalabilidad y la fiabilidad. - Google Patents

Abstract

Un procedimiento para establecer una relación de revisión entre homólogos entre un primer (1) y un segundo (2) aparato de red, estando conectados el primer y el segundo aparato de red a una red interconectada (32), comprendiendo el procedimiento: determinar una dirección del segundo aparato de red (2) con el primer aparato de red (1), estando asociada la dirección del segundo aparato de red (2) con la red interconectada (32); enviar un mensaje de verificación de conexión al segundo aparato de red (2) desde el primer aparato de red (1) a través de la red interconectada (32); responder selectivamente al mensaje de verificación de conexión desde el primer aparato de red (1) con el segundo aparato de red (2); establecer una periodicidad entre el envío de mensajes periódicos posteriores de verificación de conexión en función de una periodicidad deseada proporcionada al primer aparato de red por el segundo aparato de red; y enviar selectivamente de manera periódica mensajes periódicos posteriores de verificación de conexión desde el primer aparato de red (1) al segundo aparato de red (2) a través de la red interconectada (32) y donde el intervalo de tiempo entre los mensajes periódicos posteriores de verificación de conexión está asociado con la periodicidad establecida.

Description

Procedimiento y sistema para un conjunto de dispositivos de red que pueden conectarse para mejorar la colaboración, la escalabilidad y la fiabilidad.

Campo técnico de la invención

Esta invención se refiere a un procedimiento y a un aparato de red para establecer una relación de revisión entre homólogos entre primeros y segundos aparatos.

Antecedentes de la invención

El tráfico de datos en redes, particularmente en Internet, ha aumentado considerablemente en los últimos años y esta tendencia continuará con el rápido crecimiento del comercio electrónico y otros servicios de Internet que requieren un mayor ancho de banda. Con este aumento del tráfico de datos en las redes, se ha producido un aumento correspondiente en el número de salas de equipos informáticos, conocidas como "salas de servidores", utilizadas para alojar el equipamiento necesario para soportar el encaminamiento del tráfico de datos. Además, la creciente dependencia de las empresas con respecto a su presencia en Internet ha creado la urgencia de mantener activas y en funcionamiento las salas de servidores en todo momento. Las estimaciones de la industria muestran que actualmente hay más de 400.000 salas de este tipo en los Estados Unidos.

El crecimiento del tráfico de Internet ha instado a muchas empresas a construir una sala de servidores para permitir que sus empleados tengan acceso a información de Internet o para habilitar el comercio electrónico y datos de almacenamiento. Inicialmente planteado como objetivo, se ha convertido en necesidad el hecho de que el servidor esté activo continuamente. Realizar un seguimiento de los numerosos ordenadores, junto con sus puentes asociados, encaminadores, fuentes de alimentación de reserva, etc., puede ser una ardua tarea. Una gran compañía con salas de servidores en más de una ciudad debe afrontar gastos de miles de euros en paquetes de software para mantener sus equipos en funcionamiento. Normalmente, el precio de un ordenador es de 738 euros aproximadamente (1.000 dólares). También se necesitan técnicos especializados para supervisar los equipos de red y emitir órdenes de trabajo para reparar las unidades defectuosas.

Para que sean fiables, los sistemas informáticos modernos no deben soportar calor, polvo o humedad excesivos. El calor puede provocar rápidamente el deterioro de los equipos. Un fallo en los ventiladores de refrigeración puede reducir la vida útil de los equipos a días u horas. Un fallo en una LAN (red de área local, local área network) de alta velocidad única puede provocar una lenta respuesta del sistema. Estos y otros fallos de este tipo en los equipos de una sala de servidores se producen de manera rutinaria y pueden generan grandes trastornos a una empresa.

Actualmente existen soluciones para supervisar equipos y redes informáticos para impedir tales fallos. Sin embargo, estas soluciones están dirigidas fundamentalmente a grandes sistemas de gama alta tales como los utilizados por grandes corporaciones o instituciones que cuentan con altos presupuestos para soportar la supervisión de los equipos. Por ejemplo, Hewlett-Packard proporciona un paquete de supervisión de gama alta con un precio inicial de aproximadamente 184.775 euros (250.000 dólares). A un nivel medio pueden encontrarse soluciones de supervisión más modestas por 14.782 euros aproximadamente (20.000 dólares). Algunos de estos sistemas sólo permiten la inspección de dispositivos de manera local. Otros permiten que un técnico inspeccione de manera geográfica varias instalaciones desde una consola central. Sin embargo, todas estas soluciones son caras de implementar y su mantenimiento es complejo y difícil así como la formación del personal que las utiliza.

Como resultado, las pequeñas y medianas empresas que poseen pequeñas y medianas redes necesitan un medio para supervisar y mantener sus equipos de red informáticos con el fin de evitar fallos de funcionamiento, pero no cuentan con los recursos para adquirir las caras soluciones disponibles actualmente. Muchas empresas no pueden adquirir una solución de gama alta o simplemente no disponen ni del tiempo ni de los recursos para formar a su personal informático para que aprenda y utilice sistemas complejos. En cambio, el procedimiento de supervisión habitual en muchas de estas compañías son las quejas que los usuarios transmiten al responsable del personal informático para indicar cuándo se ha producido un problema. La idea es que alguien de la organización notifique un fallo y solicite su reparación antes de que se produzcan problemas. Sin embargo, la realidad es que la mayoría de los responsables del personal informático han tenido que ocuparse de problemas en la sala de servidores debidos a un calor excesivo, a otro fenómeno físico o simplemente a un fallo.

Esto sucede especialmente en empresas que cuentan con múltiples salas de servidores y que tienen problemas relacionados con el acceso rutinario a cada una de estas salas. Por ejemplo, la mayoría de los responsables del personal informático necesitan algún tipo de acceso remoto para determinar el estado de una sala de servidores. Además, con las soluciones actuales existen problemas relacionados con la proporción de mano de obra de estas soluciones. La mayoría de las soluciones de supervisión de redes pueden necesitar un empleado a jornada completa o parcial. Por lo tanto, la justificación económica de estos sistemas es difícil ya que los equipos de red fallan normalmente de año en año o cuando se produce un error muy grave, y el coste de reparación es inferior al de mantener un empleado a jornada completa que supervise de manera rutinaria los equipos.

\newpage

Para la supervisión de componentes montados en un bastidor existen problemas similares relacionados con la posibilidad de que los componentes individuales colocados en un bastidor puedan supervisarse de manera remota. Además, las soluciones de supervisión actuales no proporcionan la generación de imágenes de vídeo de las ubicaciones de servidores remotos de una red. Los equipos informáticos están dispuestos normalmente en salas de servidores por dos motivos: seguridad y control ambiental. La generación remota de imágenes de vídeo de una sala de servidores de una red puede mantener la seguridad de los equipos a pesar de la ausencia de una presencia física en el
lugar.

Una sala de ordenadores típica puede alojar cientos de dispositivos que varían de caros ordenadores con funcionalidad de servidor a puentes, encaminadores, fuentes de alimentación continuas y equipos telefónicos. El entorno de una sala de servidores requiere supervisión ya que variables ambientales extremas pueden afectar finalmente a los equipos de la sala. Por ejemplo, altas temperaturas, humedad (debida, por ejemplo, a fugas de agua), o la ausencia de flujo de aire pueden perjudicar a los equipos. De manera similar, es importante determinar alarmas, tales como alarmas de humos y de incendios, o el estado de las aperturas de la sala. Aunque el coste de sustituir los componentes de una sala de servidores si estos fallan es muy elevado, las soluciones de supervisión actualmente disponibles no son rentables para su implementación en pequeñas empresas a pesar de los posibles costes de estas pérdidas.

Los sistemas de supervisión están implementados normalmente como dispositivos sencillos y autónomos con los que un usuario o una aplicación pueden interactuar y realizar tareas de configuración. La mayoría de aparatos permiten que uno o más usuarios o aplicaciones interactúen con los mismos, pero el usuario o aplicación debe interactuar normalmente con cada aparato por separado.

Estos sistemas de supervisión típicos utilizan una aplicación centralizada (o bien una extensión a un sistema de gestión de red, tal como HP OpenView, o bien un servidor propietario o aplicación de consola). Aunque estos mecanismos pueden ser bastante eficaces, añaden costes adicionales debido a software, hardware, configuración, administración y ancho de banda de red. Además, el servidor/aplicación central añade normalmente un único punto de fallo al
entorno.

Otro problema con los aparatos autónomos, en particular con dispositivos cuyo objetivo principal es supervisar condiciones ambientales y/o de red, es su vulnerabilidad a fallos no notificados. Específicamente, si el aparato de supervisión tiene un fallo, la detección del fallo requiere normalmente la interacción del usuario o interrogación mediante un servidor de gestión centralizado caro. La consecuencia de no detectar el aparato defectuoso es no poder detectar las condiciones que el dispositivo debía supervisar, no pudiendo obtener información durante ese lapso de tiempo.

En caso de fallo de un aparato, el aparato autónomo típico carece de mecanismos para el almacenamiento y la restauración externos de datos, específicamente de datos de configuración y de histórico. Esto puede añadir una sobrecarga significativa y la posibilidad de errores cuando se sustituye un dispositivo defectuoso ya que el nuevo dispositivo necesitará reconfigurarse de manera satisfactoria para adoptar la funcionalidad del dispositivo defectuoso. Pueden implementarse mecanismos para guardar y restaurar configuraciones de un dispositivo en servidores externos, pero nuevamente genera el problema de costes y puntos de fallo adicionales.

Más allá de la aplicación en salas de servidores e instalaciones de equipos de red en bastidores, otros diversos sistemas de supervisión sufren los mismos fallos y deficiencias asociados con el ancho de banda de red y fallos de sensor no detectados. Además, estos sistemas de supervisión pueden sufrir pérdidas de datos de histórico asociados el fallo de un sensor.

Por tanto, muchos sistemas de supervisión remotos típicos sufren deficiencias provocadas por fallos de sensor no detectados y un ancho de banda de comunicaciones limitado. Otros muchos problemas y desventajas de la técnica anterior resultarán evidentes a un experto en la materia después de comparar la técnica anterior con la presente invención descrita en este documento.

La patente US No. 5822302 describe un sistema que supervisa de manera automática una red de operaciones de centro de datos (DCO, Data Center Operations) (o cualquier red LAN/WAN) para detectar averías de circuito y envía una notificación si se detecta una avería. Una consola en un centro de operaciones remoto verifica periódicamente la conexión con una consola de cada centro de datos (la verificación de la conexión también puede realizarse bajo demanda). La consola remota recibe respuestas desde cada consola del centro de datos con la que se verificó la conexión. Se recibirá una respuesta para cada posible ruta entre el centro de datos y el centro de operaciones remoto. Estas respuestas indican la ruta que se ha tomado, y las rutas indicadas en las respuestas se comparan después con una tabla de rutas identificadas anteriormente como rutas relevantes o de interés.

La patente US No. 6138249 describe un procedimiento y un aparato para supervisar una pluralidad de sistemas de procesamiento de datos desde un sistema de supervisión. Los sistemas de procesamiento de datos pueden estar acoplados al sistema de supervisión a través de una nube de red. Cuando uno de la pluralidad de sistemas de procesamiento de datos experimenta un fallo, el fallo se detecta en el sistema de supervisión en base a las comunicaciones a través de la red. Los sistemas de procesamiento de datos pueden presentar cada uno un procesador de servicios acoplado directamente a la nube de red. El sistema de supervisión también puede utilizarse para supervisar el estado de los sistemas de procesamiento de datos, ya sea en un entorno de fabricación/pruebas o in situ.

La patente US No. 6094676 desvela una disposición mediante la cual puede establecerse una comunicación entre homólogos entre dos unidades informáticas remotas a través de un canal de red, incluso aunque no se conozca una dirección de red permanente. Un ordenador emisor envía un mensaje a través de un canal supervisor, tal como una línea telefónica de conmutación de circuitos, hasta un ordenador receptor creando un evento de activación. Como respuesta al evento de activación, el ordenador emisor o el ordenador receptor determina una dirección de red asociada o bien con el ordenador emisor o bien con el ordenador receptor. Después, utilizando la dirección de red, la comunicación entre homólogos entre el ordenador emisor y el ordenador receptor se establece a través del canal de red.

Resumen de la invención

Según la presente invención se proporciona un procedimiento para establecer una relación de revisión entre homólogos entre un primer y un segundo aparato de red según la reivindicación 1, refiriéndose otros aspectos de la presente invención a un aparato de red según la reivindicación 7, a un aparato de red dispuesto con un segundo aparato de red como una agrupación de aparatos de red según la reivindicación 13, y a un programa de instrucciones ejecutables por una máquina para llevar a cabo las etapas de procedimiento del procedimiento mencionado anteriormente, según la reivindicación 19.

Aspectos de la invención se refieren a un aparato o dispositivo de red. El dispositivo puede presentar uno o más sensores. Estos sensores pueden medir, por ejemplo, variables ambientales, variables relacionadas con la energía, vídeo o imágenes fijas, sonidos, variables de red, etc. Además, el aparato de red puede enviar datos, alertas, alarmas y/u otras notificaciones asociadas con los sensores y los datos medidos.

Además, el aparato de red puede estar conectado a una red interconectada. A través de la red interconectada, el aparato de red puede comunicarse con otro aparato de red y/o con uno o más sistemas de supervisión remotos.

El aparato de red también puede enviar datos, alarmas u otras notificaciones a través de varios medios de comunicación. Estos medios pueden incluir redes telefónicas, módems, redes de radiolocalización, otros medios de comunicación inalámbricos, medios de auditoría, medios visuales, medios basados en web, etc.

Un aspecto adicional de la invención se refiere a un procedimiento de comunicación entre aparatos de red. Un aparato de red puede establecer una relación con un aparato de red homólogo. El aparato de red puede verificar después la conexión con el aparato homólogo. Si el aparato homólogo no recibe una o más verificaciones de conexión consecutivas, el aparato homólogo puede determinar el estado de operabilidad del aparato de red. En caso de un fallo, el aparato homólogo puede enviar una alerta a un sistema de supervisión remoto, a una parte responsable o a otro aparato homólogo.

La comunicación puede utilizar varios protocolos que incluyen, por ejemplo, HTTP, SNMP, TCP/IP, FTP, LDAP, SOAP, UDP, mensajes MQSeries de IBM, y mecanismos que incluyen, por ejemplo, procedimiento POST de HTTP, eventos CIM, alertas DMI, inserciones en bases de datos, adiciones en archivos de registro, etc. Sin embargo, pueden desarrollarse o concebirse otros protocolos.

Al utilizar un procedimiento de verificación de conexión junto con notificaciones cuando se mide un estado específico, el sistema puede supervisar una pluralidad de condiciones en una ubicación remota y detectar el fallo de dispositivos limitando al mismo tiempo el ancho de banda utilizado para comunicar las mediciones. De ese modo, puede establecerse un sistema de supervisión remoto entre una agrupación de aparatos de red remotos e instalaciones en una ubicación aparte.

Otro aspecto de la invención se refiere a una agrupación de aparatos de red. La agrupación de aparatos de red puede establecer varias relaciones entre homólogos. Además, la agrupación de aparatos puede establecer un directorio de aparatos y sus capacidades, características y/o funciones asociadas. Con este directorio, la agrupación de aparatos puede compartir recursos. De esta manera, la agrupación puede llevar a cabo funciones más complejas. Además, la agrupación puede realizar la función de un aparato defectuoso.

Un aspecto adicional de la invención se refiere a un sistema de supervisión remoto. El sistema de supervisión remoto puede incluir uno o más aparatos de red conectados a una red interconectada. Además, un sistema remoto puede supervisar el o los aparatos de red. Como alternativa, el sistema remoto puede comunicarse con un único aparato de red dominante. Este aparato de red dominante puede actuar como un intermediario entre el sistema remoto y otros aparatos de red de la agrupación. Además, el aparato de red dominante puede mantener un directorio de las capacidades de los otros aparatos de red de la agrupación.

Además, un aparato de reserva del aparato de red dominante puede actuar como un homólogo que observe al aparato de red dominante. En caso de que falle el aparato de red dominante, el aparato de reserva puede funcionar como el intermediario y/o mantener el directorio.

Otro aspecto de la invención se refiere a un medio legible por ordenador o por máquina con un conjunto de instrucciones para llevar a cabo el procedimiento de comunicación. El medio puede adoptar varias formas incluyendo un CD-ROM, un CD-R, un CD-RW, un DVD, un disco duro, un disco flexible, un medio extraíble, etc.

Por lo tanto, se describen un aparato y un procedimiento para supervisar ubicaciones remotas. Otros aspectos, ventajas y características novedosas de la presente invención resultarán evidentes a partir de la descripción detallada de la invención cuando se considera junto con los dibujos adjuntos.

Breve descripción de los dibujos

Para un entendimiento más completo de la presente invención y de las ventajas de la misma, a continuación se hace referencia a la siguiente descripción tomada junto con los dibujos adjuntos en los que los mismos números de referencia indican las mismas características, y en los que:

La fig. 1 es un diagrama de bloques esquemático de un sistema para una supervisión remota.

La fig. 2 es un diagrama de bloques esquemático de una realización a modo de ejemplo de un sistema para una supervisión remota según el sistema mostrado en la fig. 1.

La fig. 3 es un diagrama de bloques esquemático de una realización a modo de ejemplo del sistema mostrado en la fig. 1.

La fig. 4 es un diagrama de bloques esquemático de otra realización a modo de ejemplo del sistema mostrado en la fig. 1.

La fig. 5 es un diagrama de flujo de bloques de un procedimiento a modo de ejemplo para su utilización en el sistema mostrado en la fig. 1.

La fig. 6 es un diagrama de bloques esquemático de otra realización a modo de ejemplo del sistema mostrado en la fig. 1.

La fig. 7 es un diagrama de bloques esquemático de otra realización a modo de ejemplo del sistema mostrado en la fig. 1.

La fig. 8 es un diagrama de bloques de una realización a modo de ejemplo del aparato de red para su utilización en el sistema mostrado en la fig. 1.

La fig. 9 es un diagrama que ilustra una realización a modo de ejemplo de un directorio para su utilización en el sistema mostrado en la fig. 1.

La fig. 10A es un diagrama de bloques esquemático de una realización a modo de ejemplo del sistema mostrado en la fig. 1.

La fig. 10B es un diagrama de bloques esquemático de una realización a modo de ejemplo del sistema mostrado en la fig. 1.

La fig. 11A es un diagrama de flujo de bloques de un procedimiento a modo de ejemplo para su utilización en el sistema mostrado en la fig. 2.

La fig. 11B es un diagrama de flujo de bloques de un procedimiento a modo de ejemplo para su utilización en el sistema mostrado en la fig. 2.

La fig. 12 es un diagrama de bloques esquemático de otra realización a modo de ejemplo del sistema mostrado en la fig. 1.

La fig. 13 es un diagrama de flujo de bloques de un procedimiento a modo de ejemplo para su utilización en el sistema mostrado en la fig. 2.

La fig. 14 es un diagrama de flujo de bloques de un procedimiento a modo de ejemplo para su utilización en el sistema mostrado en la fig. 2.

La fig. 15 es un diagrama de flujo de bloques de un procedimiento a modo de ejemplo para su utilización en el sistema mostrado en la fig. 2.

Números de referencia correspondientes indican partes correspondientes a través de las diversas vistas de los dibujos.

Descripción detallada de la realización preferida

La fig. 1 es un diagrama de bloques esquemático del sistema según la invención. El sistema 10 puede presentar un sistema de supervisión remoto 12 y un sistema de supervisión 14. Además, el sistema puede presentar múltiples sistemas de supervisión remotos 12 conectados a un sistema de supervisión 14. Asimismo, un sistema de supervisión remoto 12 puede estar conectado a una pluralidad de sistemas de supervisión 14. De ese modo, un sistema de supervisión remoto 12 puede recopilar datos de múltiples sistemas de supervisión 14. Como alternativa, un sistema de supervisión 14 puede enviar datos a una pluralidad de sistemas de supervisión remotos 12. Además, una pluralidad de sistemas de supervisión remotos 12 puede estar conectada a una pluralidad de sistemas de supervisión 14 o en otras diversas combinaciones.

El sistema de supervisión remoto 12 puede adoptar diversas formas. Estas formas pueden incluir un ordenador o un conjunto de ordenadores situados de manera remota, un teléfono, un teléfono inteligente, un teléfono con correo electrónico, un radiolocalizador, un dispositivo portátil y/o un sistema de alarma, etc. Además, el sistema de supervisión remoto 12 puede acceder, supervisar y/o comunicarse con el sistema de supervisión 14 a través de diversos medios. Estos medios pueden incluir correo electrónico, interfaces web, interfaces de radiolocalizador, diversas normas de conexión en red, etc.

El sistema de supervisión 14 puede adoptar varias formas. Estas formas pueden incluir uno o más dispositivos de red asociados con uno o más sensores. Además, los dispositivos de red pueden comunicarse con otros aparatos de red. El o los sensores asociados con los dispositivos de red pueden adoptar varias formas. Estas formas pueden incluir sensores de temperatura, sensores de presión, sensores de flujo de aire, sensores de tensión, sensores de corriente, micrófonos, cámaras, videocámaras, sensores de red, sensores infrarrojos, sensores de movimiento, sensores de puerta, etc.

El sistema de supervisión remoto 12 y el sistema de supervisión 14 pueden comunicarse a través de diversos medios. Estos medios pueden incluir, cuando sea apropiado, redes globales, redes de área extensa, redes de área local, líneas telefónicas, redes inalámbricas, etc. Además, el sistema de supervisión remoto 12 y el sistema de supervisión 14 pueden comunicarse utilizando varios protocolos. Estos protocolos pueden incluir TCP/IP, protocolos de Ethernet, SNMP, HTTP, FTP, SOAP, UDP, mensajes MQSeries de IBM, etc.

El sistema mostrado en la fig. 1 puede tener varios usos. Por ejemplo, en una realización a modo de ejemplo, el sistema puede utilizarse para supervisar una ubicación en la que están almacenados los servidores y otros ordenadores. De ese modo, el usuario puede supervisar los recursos de red desde ubicaciones remotas. Sin embargo, se conciben otras muchas realizaciones. Pueden concebirse otras aplicaciones. Estas aplicaciones pueden incluir aplicaciones militares, de seguridad, etc.

La fig. 2 es un diagrama de bloques esquemático de una realización a modo de ejemplo del sistema mostrado en la fig. 1. El sistema 30 presenta varios aparatos de red conectados a una red interconectada. Esta red interconectada puede conectarse al sistema de supervisión remoto a través de varios medios. Los aparatos de red pueden comunicarse con aparatos de red homólogos a través de la red interconectada 32. Además, uno o más de los aparatos de red pueden comunicarse con el sistema de supervisión remoto 44. Esta comunicación puede llevarse a cabo a través de la red interconectada 32 o a través de otros medios.

La red interconectada 32 puede adoptar varias formas. Estas formas pueden incluir una red global, una red de área extensa (WAN, wide area network), una red de área local (LAN, local area network), redes inalámbricas, etc. Además, pueden utilizarse varios protocolos para la comunicación entre los aparatos. Estos protocolos pueden incluir SNMP, HTTP, FTP, TCP/IP, SOAP, UDP, protocolos de Ethernet, protocolos Bluetooth, etc.

El sistema de supervisión remoto 44 puede comunicarse con uno o más de los aparatos de red a través de la red interconectada o a través de otros medios. Estos otros medios pueden incluir medios inalámbricos y otros medios de conexión en red. Por ejemplo, estos medios pueden incluir una red global, una conexión dedicada, un sistema telefónico, un sistema de radiolocalización, un módem, un sistema telefónico inalámbrico, etc. Por ejemplo, los aparatos de red pueden enviar datos a través de una red interconectada utilizando un procedimiento POST de HTTP o un procedimiento FTP. Como alternativa, los aparatos de red pueden enviar un mensaje de radiolocalización en texto a una parte responsable informándola acerca de una condición de alarma. En otro ejemplo, el sistema puede realizar llamadas telefónicas a partes responsables.

Un aparato de red puede adoptar varias formas. En una realización a modo de ejemplo, el aparato de red es un dispositivo que puede realizar un conjunto de funciones bien definido y que está conectado a una red. El dispositivo puede incluir software para supervisar, configurar, controlar y comunicar los resultados de sus funciones. Además, el dispositivo puede conectarse a una red interconectada. El dispositivo también puede configurarse, supervisarse y controlarse desde una ubicación remota.

Un grupo de aparatos de red puede funcionar como una agrupación. En este caso, una agrupación se refiere a una colección de aparatos de red interconectados que pueden actuar como una única entidad lógica. La agrupación puede estar asociada de manera lógica o estar agrupada para facilitar la interacción con el usuario, etc. Este agrupamiento o grupo como una única entidad lógica puede adoptar varias formas. Estas formas pueden incluir el agrupamiento de dispositivos asociados con una ubicación específica, una sala, un edificio, un usuario, una función, una finalidad, una región de red, un grupo de usuarios, una parte responsable, una ubicación de supervisión remota y/o un servidor, etc.

\newpage

En una realización a modo de ejemplo, los aparatos de red pueden utilizarse para supervisar una ubicación o sala de servidores. Cada aparato de red puede proporcionar una función específica, supervisar una variable específica o detectar una salida o un estado ambiental, etc.

Por ejemplo, un aparato de red puede establecerse para supervisar condiciones ambientales como flujos de aire y la temperatura. Otro aparato de red puede adoptar la forma de una cámara. Además, un aparato de red puede supervisar el estado y la calidad de la red. En un ejemplo adicional, un aparato de red puede utilizarse para supervisar la disponibilidad y la calidad de la energía eléctrica. En una realización, uno o más de estos diversos aparatos de red pueden estar situados por toda una sala. Por ejemplo, varios monitores de temperatura pueden estar situados en varios puntos de una sala para adquirir datos asociados con el perfil de temperatura de la sala. En otro ejemplo, varios aparatos de red pueden estar situados en un bastidor de servidores para supervisar flujos de aire, perfiles de temperatura y la calidad eléctrica dentro y entorno al bastidor. En este caso, los aparatos de red pueden comunicarse entre sí o comunicarse con un sistema de supervisión remoto. De esta manera, los datos asociados con la ubicación pueden transferirse al sistema de supervisión remoto.

Además, estos aparatos de red pueden configurarse para permitir ajustes de alarma. El aparato, una vez que se haya cumplido una condición de alarma, puede enviar una alerta o bien a otros aparatos de red o bien al sistema de supervisión remoto. De esta manera, puede establecerse un comportamiento complejo de manera que cuando un aparato de red cumpla una condición de alarma, otros aparatos de red enviarán su información al sistema de supervisión remoto o responderán consecuentemente. En una realización a modo de ejemplo, un aparato de red con sensor de puerta puede utilizarse para supervisar la entrada a la sala de servidores o la entrada al bastidor de servidores. Una vez que se cumpla la condición de alarma o una vez que la puerta esté abierta, el aparato de red con sensor de puerta puede enviar un mensaje o una alerta a los otros aparatos de red. Los otros aparatos de red pueden responder enviando información adicional al sistema de supervisión remoto o realizando alguna otra función. Por ejemplo, una vez que el aparato de red con sensor de puerta esté activado, o se cumpla una condición de alarma, el aparato de red con sensor de puerta puede enviar un mensaje a un aparato de red con cámara. El aparato de red con cámara puede capturar una imagen de la persona que entra por la puerta y el aparato de red puede enviar después esa imagen al sistema de supervisión remoto o, como alternativa, puede enviar la imagen a otro aparato de red. El otro aparato de red puede funcionar para enviar la información o la alerta a un usuario a través de otro sistema tal como un sistema telefónico, un radiolocalizador o a través de un módem.

El comportamiento complejo puede conseguirse a través de comunicaciones entre homólogos de aparatos de red. La fig. 3 es un diagrama de bloques esquemático que ilustra una realización a modo de ejemplo de una comunicación entre aparatos de red. Según la invención mostrada en la fig. 1. Por ejemplo, un conjunto de aparatos de red puede estar conectado a una red interconectada. Estos aparatos pueden establecer enlaces de comunicaciones entre los diversos aparatos de red.

En una realización a modo de ejemplo, un aparato de red verificará periódicamente la conexión con un aparato homólogo. Si el aparato homólogo no recibe una verificación de conexión esperada, puede establecer que el aparato que realiza la verificación de conexión no está operativo. De esta manera, puede detectarse rápidamente un fallo en un aparato.

Además, una vez que el aparato homólogo haya detectado un fallo, el aparato homólogo puede informar a la ubicación de supervisión remota o a otro aparato de red con relación al fallo del primer aparato de red. Con esta información, los otros aparatos de red pueden compensar el fallo y/o adoptar la funcionalidad del dispositivo defectuoso, etc. De manera similar, la ubicación de supervisión remota y/o una parte responsable pueden responder de manera apropiada.

En un algoritmo a modo de ejemplo, un aparato de red puede estar asignado para supervisar varios aparatos de red. Un aparato de red puede estar configurado para verificar la conexión con una pluralidad de otros aparatos de red y recibir verificaciones de conexión desde otro conjunto de aparatos de red. Un aparato de red puede verificar la conexión con aquellos aparatos que estén verificando la conexión con el mismo y con otros aparatos que no estén verificando la conexión con el mismo, o puede estar configurado para verificar la conexión solamente con aquellos aparatos que no estén verificando la conexión con el mismo. De ese modo, pueden establecerse varios algoritmos que faciliten la detección de fallos entre homólogos.

El sistema de comunicación entre homólogos también puede utilizarse para enviar mensajes de alerta a través de la red. El sistema de revisión también puede utilizarse para enviar datos, establecer varias configuraciones del sistema, crear comportamientos complejos, establecer una comunicación con una red remota, etc.

En una realización a modo de ejemplo, un aparato de red A puede supervisar aparatos de red B, C y D. De ese modo, los aparatos de red B, C y D pueden verificar la conexión con el aparato de red A. Como alternativa, el aparato de red A puede verificar la conexión con los aparatos de red B, C y D.

Si el aparato de red A falla, está apagado o se ha eliminado del sistema, los dispositivos B, C y D pueden percatarse del fallo o apagado del dispositivo. Por ejemplo, si el dispositivo B va a verificar la conexión con el dispositivo A y no recibe una respuesta, el dispositivo B puede establecer que el dispositivo A ya no está en servicio. Como alternativa, si el dispositivo A verifica periódicamente la conexión con el dispositivo C y la verificación de conexión periódica deja de realizarse, el dispositivo C puede establecer que el dispositivo A ya no está en servicio. En otro ejemplo, el dispositivo A puede realizar una verificación de conexión especial para informar con relación a un evento de apagado inminente o un evento de apagado esperado. De ese modo, el dispositivo B, C y D pueden establecer que el dispositivo A ya no está en servicio. Los dispositivos B, C o D pueden enviar una notificación al sistema de supervisión remoto con relación al fallo o apagado del dispositivo A. En un ejemplo adicional, el dispositivo B, C y D pueden llevar a cabo comunicaciones de tal manera que solamente un dispositivo envíe la notificación del fallo.

Además, los dispositivos B, C y D pueden establecer nuevos enlaces de comunicación y una nueva relación de revisión entre homólogos, tal y como se observa en la figura 4. Por ejemplo, el aparato B puede comunicarse con el aparato C en lugar de con aparato A. Puesto que el aparato D ya no requiere los recursos para supervisar al aparato A, puede establecer una nueva supervisión con el dispositivo C. De esta manera, la revisión entre homólogos puede reconfigurarse automáticamente.

En otra realización a modo de ejemplo, un nuevo aparato G puede añadirse al sistema y/o conectarse a la red. El dispositivo G puede establecer una revisión entre homólogos con el aparato B. Además, puede intentar establecer una revisión entre homólogos con el dispositivo D. En una realización a modo de ejemplo, el dispositivo D puede tener la opción de rechazar la revisión entre homólogos basándose en los recursos del dispositivo D, el número de homólogos que ya está supervisando el dispositivo D o por los que está siendo supervisado, y/u otros factores. De ese modo, el dispositivo G puede establecer después una relación de revisión entre homólogos con el aparato de red F. Además, los aparatos pueden decidir finalizar la revisión entre homólogos. Por ejemplo, el aparato de red D puede decidir finalizar su revisión del aparato F. Esta decisión puede basarse en las capacidades del aparato, el número de otras relaciones de revisión entre homólogos, los recursos de red y otros factores. Como alternativa, el aparato de red F puede decidir finalizar su relación de revisión entre homólogos con el dispositivo D. Esta decisión puede tomarse por motivos similares.

De ese modo, las relaciones entre homólogos pueden reconfigurarse automáticamente, pueden utilizarse para supervisar el estado de otros aparatos homólogos, pueden utilizarse para transferir datos entre aparatos, para establecer comportamientos complejos entre aparatos, etc.

El proceso de revisión entre homólogos puede utilizar varios protocolos para establecer comunicaciones. Estos protocolos pueden incluir FTP, SNMP, HTTP, SOAP, UDP, TCP/IP, entre otros.

La fig. 5 es un diagrama de flujo de bloques de un procedimiento a modo de ejemplo para establecer comunicaciones para el proceso de revisión entre homólogos. El procedimiento 50 puede llevarse a cabo mediante un aparato de red. El aparato de red puede llevar a cabo radiodifusión para encontrar otros aparatos de red en la red, tal y como se muestra en el bloque 52. Sin embargo, el aparato puede utilizar uno o más de una variedad de mecanismos para determinar la presencia de otros aparatos. Por ejemplo, los mecanismos pueden incluir configuración de usuario final, multidifusión, radiodifusión por subred, consultas a servicios de directorio, recorrido por direcciones de subred, entre otros.

El aparato de red puede verificar después la conexión con y/o interrogar uno de los otros aparatos de red encontrados en la red, tal y como se observa en el bloque 54. Esta verificación de conexión puede adoptar varias formas. Por ejemplo, la verificación de conexión puede utilizar el protocolo de un mensaje POST de HTTP. La verificación de conexión puede incluir información como, por ejemplo, el número de serie del aparato solicitante, el periodo de tiempo planificado antes de la siguiente conexión de verificación, la dirección IP y nombre de anfitrión del aparato solicitante, y una lista de direcciones objetivo de SNMP para capturas SNMP. Sin embargo, la verificación de conexión puede adoptar varias formas incluyendo, por ejemplo, HTTP, SOAP, SNMP, TCP, UDP, FTP, mensajes MQSeries de IBM, entre otros.

El dispositivo homólogo puede recibir la verificación de conexión, determinar si tiene los recursos para establecer un proceso de revisión entre homólogos y enviar una respuesta. El aparato de red puede recibir esa respuesta, tal y como se observa en el bloque 56. El mensaje de respuesta puede incluir varios datos. Estos datos pueden incluir datos similares a los datos anteriores y/o pueden estar asociados con la funcionalidad de la ubicación del dispositivo, la dirección del dispositivo, una periodicidad deseada de futuras verificaciones de conexión, la aceptación de la relación, etc. La respuesta puede utilizar varios protocolos incluyendo los enumerados anteriormente, entre otros.

Si el dispositivo homólogo acepta la relación entre homólogos, el aparato de red puede esperar durante un periodo dado establecido en una comunicación entre el aparato de red y su homólogo, tal y como se observa en el bloque 60. Después, un aparato de red puede verificar de nuevo la conexión con el homólogo, tal y como se observa en el bloque 54. El dispositivo homólogo puede decidir si es necesario devolver un mensaje como respuesta. De ese modo se establece la revisión entre homólogos.

En una realización a modo de ejemplo, un aparato de red puede llevar a cabo radiodifusión a través de una red interconectada para encontrar las direcciones de aparatos homólogos. Por ejemplo, el aparato de red puede realizar una radiodifusión por subred. Los aparatos homólogos pueden responder a esta radiodifusión. Después, el aparato de red puede verificar de manera selectiva la conexión con uno de los aparatos homólogos respondedores. El aparato de red puede utilizar, por ejemplo, un mensaje POST de HTTP o un mensaje FTP con información relacionada con la dirección del aparato homólogo y/o la periodicidad de futuras verificaciones de conexión. Además, el mensaje puede contener información acerca de la funcionalidad del aparato de red y/o información asociada con los algoritmos asociados con la funcionalidad del aparato de red. El aparato homólogo puede responder con un mensaje. El mensaje puede utilizar, por ejemplo, un mensaje SNMP, FTP y/o POST de HTTP, etc. El mensaje puede incluir información asociada con la aceptación de la relación entre homólogos, la periodicidad de futuras verificaciones de conexión y/o la funcionalidad del dispositivo homólogo, etc. Después, el aparato de red puede verificar periódicamente de manera selectiva la conexión con el aparato homólogo.

En una realización a modo de ejemplo, un aparato puede, opcionalmente, "verificar la conexión" solamente con aparatos a los que debe vigilar y que no estén actualmente "verificando la conexión" con el mismo. Puesto que un aparato homólogo verifica periódicamente la conexión con el aparato de red, la ausencia de verificaciones de conexión del aparato puede usarse para detectar su mal funcionamiento. Si un aparato se apaga intencionadamente, el aparato puede realizar una "verificación de conexión" especial con cada uno de los dispositivos que están "verificando la conexión" con el mismo y/o que están "siendo verificados" por el mismo para indicar su intención de apagarse. Esto puede usarse para impedir que estos dispositivos notifiquen un apagado o reinicio planificados como un fallo.

En cualquier caso, puede determinarse que un aparato ha fallado si a) una "verificación de conexión" desde el aparato debería haberse realizado hace mucho tiempo o si b) uno o más intentos de "verificar la conexión" con el aparato han fallado. Cuando se detecta un fallo, pueden notificarse direcciones de correo electrónico u otros mecanismos de contacto suministrados por el aparato. Además, capturas SNMP (con su dirección agente fijada a la dirección IP del aparato que falta) pueden enviarse a las direcciones SNMP objetivo suministradas por el aparato. Opcionalmente, las notificaciones también pueden enviarse al correo electrónico y a las direcciones SNMP asociadas con el aparato de detección de fallos (en particular si el aparato defectuoso no suministró estos datos).

Con este algoritmo, un aparato de red puede establecer una relación de revisión entre homólogos con otro aparato de red. Además, el aparato de red puede establecer de manera selectiva más de una relación de revisión entre homólogos. Además, un algoritmo puede dictaminar el establecimiento de una pluralidad de relaciones entre homólogos.

De esta manera, si un dispositivo homólogo está esperando una verificación de conexión periódica desde un aparato de red, puede establecer de manera periódica el estado operativo del aparato de red. Si no se recibe una verificación de conexión o si no se ha recibido una serie de verificaciones de conexión, el dispositivo homólogo puede establecer que el aparato de red no está operativo.

Una variación de la verificación de conexión entre homólogos puede utilizarse para una comunicación entre aparato y dispositivo central. Por ejemplo, cada aparato puede estar configurado para "verificar la conexión" con uno o más servidores web anfitrión. En este caso, el aparato no detecta o notifica averías de los servidores objetivo, sino que una aplicación de esos servidores utiliza la información notificada a través de la verificación de conexión para saber cuándo notificar la avería de un aparato y a quién notificar la avería.

Otras realizaciones de estos mecanismos pueden utilizar varios protocolos para la implementación de "verificaciones de conexión" incluyendo HTTPS, SOAP, capturas SNMP, implementaciones propietarias de UDP o TCP, mensajes MQSeries de IBM, etc., así como otros mecanismos de notificación de alarma que incluyen procedimientos POST de HTTP, eventos CIM, alertas DMI, INSERTS de bases de datos, adiciones en archivos de registro, etc.

Los aparatos de red pueden comunicarse con el sistema de supervisión remoto a través de varios procedimientos. Estos procedimientos pueden incluir una red de radiolocalización, una red telefónica, una red inalámbrica, una red global interconectada, una línea dedicada, etc.

En una realización a modo de ejemplo, un mensaje periódico puede utilizar un procedimiento POST de HTTP. De manera similar, otras comunicaciones entre aparatos y entre aparatos y la ubicación remota pueden utilizar un procedimiento POST de HTTP. El procedimiento puede tener una forma parecida a lo siguiente.

1

\vskip1.000000\baselineskip

Las variables pueden contener información asociada con el tipo de aparato de red, la versión del software, el ID de red, el nombre de anfitrión, dispositivos, sensores y otros datos.

\newpage

En otra realización a modo de ejemplo, los mensajes pueden enviarse utilizando un procedimiento FTP. De ese modo, un mensaje puede adoptar la forma de un archivo de texto ubicado en otro aparato o servidor y aparecer de la siguiente manera:

VARIABLE1 = 1

VARIABLE2 = 2

VARIABLE3 = valor

Estos procedimientos también pueden utilizarse para transferir imágenes, sonido y otros datos. Además pueden utilizarse otros procedimientos, mecanismos y protocolos para enviar, transferir y/o transmitir datos.

La fig. 6 es un diagrama de bloques esquemático de una realización a modo de ejemplo de un sistema de comunicación entre el sistema de supervisión remoto 72 y aparatos de red 74, 76 y 78. El sistema 70 puede establecer comunicación entre el sistema de supervisión remoto 72 y cada uno de los aparatos de red A, B y C, 74, 76, 78. El sistema de supervisión remoto 72 puede interrogar cada uno de los dispositivos. Como alternativa, cada uno de los dispositivos 74, 76, 78 pueden transmitir información al sistema de supervisión remoto 72.

La comunicación entre el sistema de supervisión remoto y los aparatos de red puede adoptar varias formas. Estas formas pueden incluir las enumeradas anteriormente, entre otras.

Además, el sistema de supervisión remoto 72 y los aparatos de red 74, 76, 78 pueden comunicarse a través de varios protocolos. Estos protocolos pueden incluir HTTP, FTP, SNMP, SOAP, UDP, TCP/IP, etc.

En una realización alternativa, el sistema de supervisión remoto puede estar configurado para comunicarse con uno, dos o con un número inferior a todos los aparatos de red. La fig. 7 es un diagrama de bloques esquemático de una realización a modo de ejemplo de un sistema para la comunicación entre el sistema de supervisión remoto 92 y una agrupación de aparatos de red. El sistema 90 puede incluir un conjunto de aparatos de red 94, 96, 100, 102, 104, conectados a una red interconectada 98. El sistema de supervisión remoto 92 puede estar conectado a uno o más de los aparatos de red 94, 96. Sin embargo, el sistema de supervisión remoto puede estar conectado o no a la red interconectada 98 que conecta cada uno de los aparatos 94, 96, 100, 102, 104.

El sistema de supervisión remoto 92 puede comunicarse con el o los aparatos de red 94, 96 a través de varios medios. Estos medios pueden incluir los enumerados anteriormente, entre otros. Por ejemplo, el sistema de supervisión remoto 92 puede comunicarse con el aparato de red D 94 a través de una red global, una WAN, una red inalámbrica, una red por satélite, una conexión dedicada, una línea telefónica, etc.

Este procedimiento de comunicación entre el sistema de supervisión remoto 92 y el o los aparatos de red 94, 96 junto con el procedimiento de comunicaciones de revisión entre homólogos pueden permitir redundancia en el enlace de comunicaciones entre los aparatos de red conectados a la red interconectada 98 y el sistema de supervisión remoto 92. Por ejemplo, el aparato de red D 94 puede establecer a través de la red interconectada 98 una comunicación de revisión entre homólogos con el aparato de red E 96. Además, el aparato de red D 94 y el aparato de red E 96 pueden presentar un medio de comunicación con el sistema de supervisión remoto 92. Si el aparato de red D 94 falla, el aparato de red E 96 puede establecer comunicaciones con el sistema de supervisión remoto 92. De ese modo, los aparatos de red A, B y C pueden comunicase a través de la red interconectada 98 con el aparato de red E 96 que a su vez puede comunicarse con el sistema de supervisión remoto 92. De esta manera, los aparatos de red A, B y C mantienen un enlace de comunicaciones con el sistema de supervisión remoto 92.

En una realización a modo de ejemplo puede utilizarse una dirección IP flotante. El aparato de red D 94 puede establecer y adquirir la dirección IP. Si el aparato de red D 94 falla, el aparato de red E 96 puede tomar la dirección IP y establecerse como el propietario. De esta manera, el sistema de supervisión remoto 92 mantendrá comunicaciones con los aparatos conectados a la red interconectada 98 sin reconfigurarse. En una realización alternativa, el aparato de red E 96 puede enviar un mensaje al sistema de supervisión remoto 92 indicando el cambio en el estado de funcionamiento del aparato de red D 94. Además, el aparato de red E 96 puede enviar un mensaje al sistema de supervisión remoto 92 estableciéndose como el propietario del enlace de comunicaciones con los aparatos de red A, B y C.

En otra realización a modo de ejemplo, el aparato de red D 94 y el aparato de red E 96 pueden utilizar diferentes medios de comunicación para contactar con el sistema de supervisión remoto 92. Por ejemplo, el aparato de red D 94 puede estar conectado a una red global. En caso de que falle el aparato de red D, el aparato de red E 96 puede presentar un módem que pueda llamar al sistema de supervisión remoto 92. Además, el aparato de red D 94 y el aparato de red E 96 pueden estar conectados al sistema de supervisión remoto 92 a través de los mismos medios pero utilizando diferentes protocolos en su comunicación con el sistema de supervisión remoto 92. Por ejemplo, el aparato de red D 94 puede utilizar un protocolo POST de HTTP para comunicarse con el sistema de supervisión remoto 92 y el aparato de red E 96 puede utilizar un protocolo FTP.

La fig. 8 es un diagrama de bloques de una realización a modo de ejemplo de un aparato de red según las figs. 1 y 2. Un aparato de red 110 puede presentar un procesador 112, un sistema de circuitos programable 114, una interfaz de red 116, sensores 118, un medio de almacenamiento 120, un reloj 134 y un módem 136. Sin embargo, el aparato de red 110 puede presentar todas, algunas o ninguna de estas características. Además, el aparato de red puede utilizar varios elementos en distintas combinaciones para permitir distintas funcionalidades.

El procesador 112 puede adoptar varias formas. Estas formas pueden incluir microprocesadores y otros sistemas de circuitos. El procesador 112 puede tomar varios datos y/o instrucciones de funcionamiento y utilizar esta información junto con el sistema de circuitos programable 114, la interfaz de red 116, los sensores 118, uno o más medios de almacenamiento 120, un reloj 134, un módem 136, etc., para permitir la funcionalidad del aparato de red y establecer además comunicaciones con aparatos homólogos y/o su sistema de supervisión remoto. Además, el procesador 112 puede estar dispuesto para funcionar con un sistema operativo basado en Java. Además, el procesador 112, junto con el sistema operativo, puede funcionar como un servidor y/o un servidor web.

El sistema de circuitos programable 114 puede adoptar varias formas. Estas formas pueden aceptar programación a partir de varios medios incluyendo teclados, dispositivos de interfaz gráfica de usuario, dispositivos portátiles, a través de la interfaz de red, etc. De esta manera, puede adaptarse la funcionalidad del aparato de red.

La interfaz de red 116 puede adoptar varias formas. Estas formas pueden incluir Ethernet, Ethernet inalámbrica, redes en anillo, medios de comunicación por Bluetooth, un módem y una línea telefónica, entre otras diversas interfaces de comunicación y de red. Además, el aparato de red 110 puede presentar más de una interfaz de red conectada a medios de comunicación similares o diferentes. Por ejemplo, un aparato puede presentar una conexión a una red Ethernet privada y una conexión de interfaz a una red de área extensa. Como alternativa, otro aparato puede presentar una conexión de interfaz de red a una red Ethernet privada y una interfaz Ethernet inalámbrica. De ese modo, varios aparatos pueden presentar una funcionalidad asociada con las interfaces de red 116. Por ejemplo, un aparato de red con una interfaz de red Ethernet privada y con una interfaz inalámbrica puede comunicarse con sensores inalámbricos y comunicar los datos de sensor a otros aparatos de la red privada. En otro ejemplo, un aparato puede presentar una interfaz de red Ethernet privada y una interfaz WAN. De ese modo, el aparato puede funcionar para comunicar información desde y a los aparatos de la red privada a y desde ubicaciones remotas. Sin embargo, pueden concebirse varias combinaciones y funcionalidades asociadas con una o más interfaces de red similares o diferentes.

Además, los sensores 118 pueden adoptar varias formas. Estas formas pueden incluir sensores de temperatura, sensores de presión, sensores de calidad eléctrica, sensores de flujo de aire, micrófonos, cámaras, videocámaras, cámaras infrarrojas, sensores de puerta, sensores de movimiento, sensores de red, etc. Uno o más sensores 118 puede(n) estar incluido(s) en el aparato de red. Como alternativa, el aparato de red puede no presentar ningún sensor 118. En otra realización, el aparato de red puede presentar un altavoz de audio o salida visual. Además, el sensor o sensores 118 puede(n) estar incluido(s) o no dentro del aparato de red 110. De ese modo, el sensor o sensores 118 puede(n) estar integrado(s) en el aparato de red 110 o fuera del aparato. Además, un sensor externo puede estar conectado de manera exclusiva al aparato 110 tal como, por ejemplo, un sensor de temperatura externo, un detector de movimiento, un sensor conectado a través un cable de contacto seco, etc. Como alternativa, el sensor o sensores 118 puede(n) ser externo(s) al aparato 110 pero estar conectado(s) a más de un aparato 110 tal(es) como, por ejemplo, una UPS con múltiples terminales de contacto seco, etc. Además, el sensor o sensores 118 puede(n) ser externo(s) al aparato con una conexión inalámbrica pudiendo supervisarse o no por uno o más aparatos de una agrupación de aparatos tal(es) como, por ejemplo, un sensor de temperatura inalámbrico, un dispositivo de red supervisado a través de SNMP, etc. Sensores individuales que pueden supervisarse por más de un aparato están sometidos al equilibrio de cargas entre aparatos, a la asignación dinámica entre aparatos y a la cobertura de conmutación por error de aparato.

El medio de almacenamiento 120 puede adoptar varias formas. Estas pueden incluir RAM, ROM, memoria flash, discos duros, discos flexibles, unidades extraíbles, DVD, CD y tarjetas de memoria, entre otras. El medio de almacenamiento puede almacenar varias instrucciones de funcionamiento, datos y otra información. Esta información puede incluir instrucciones de conexión en red y de comunicación 122, reglas de alarma y alertas 124, instrucciones de comunicación entre homólogos 126, instrucciones de comunicación entre aparato y dispositivo central 128, varios directorios 130, datos 132, etc.

Las instrucciones de comunicación y de red 126 puede incluir implementaciones de varios protocolos, instrucciones de funcionamiento para interfaces de red 116 y/o módems 136, y otras instrucciones para las comunicaciones. Además, el medio de almacenamiento 120 puede contener conjuntos de instrucciones para interpretar mensajes enviados en varios protocolos. Estos conjuntos de instrucciones pueden escribirse como un CGI, un servlet de Java, ASP, JSP, una secuencia de comandos PHP, etc. Además, estos conjuntos de instrucciones pueden permitir que el aparato de red funcione como un servidor web. Por ejemplo, los conjuntos de instrucciones pueden utilizarse para analizar sintácticamente mensajes POST de HTTP, recibir mensajes FTP y/o interpretar mensajes enviados utilizando otros protocolos, procedimientos y mecanismos.

El medio de almacenamiento 120 también puede contener reglas de alarma 124 y otros algoritmos, umbrales y valores prefijados. Pueden utilizarse para indicar valores de parámetros sobre los que una parte responsable desea obtener información.

Además, el medio de almacenamiento 120 puede contener instrucciones de comunicación entre homólogos 126 y entre aparato y dispositivo central 128. Estas instrucciones pueden controlar, por ejemplo, la comunicación y los procedimientos de comunicación para varios fines con aparatos homólogos y/o ubicaciones remotas.

Además, los directorios 130 y otros datos 132 pueden estar almacenados en el medio de almacenamiento. El directorio 130 puede contener información asociada con aparatos, direcciones, nombres de anfitrión, software, versiones de software, tipos de dispositivo, datos de dispositivo, etc. Además, el directorio puede estar compartido o puede ser una réplica de un directorio compartido. Los datos 132 pueden ser, o no, colectivos, compartidos y distribuidos. Los datos 132 pueden ser, por ejemplo, valores de sensores, listas tales como objetivos de capturas SNMP, listas de notificaciones por correo electrónico, números de radiolocalizador y de teléfono, etc.

Además, un aparato de red puede tener un reloj 134. Este reloj puede adoptar varias formas, pudiendo ser analógico, digital, etc. El reloj 134 puede utilizarse junto con los sensores para establecer el tiempo en el que se realizó una medición.

Además, el aparato de red 110 puede tener un módem 136 u otros medios de comunicación para la conexión a través de una línea telefónica u otros medios de comunicación cableados o inalámbricos. Esto puede ser similar o no a la interfaz de red 116.

En una realización a modo de ejemplo, el aparato de red puede funcionar para medir la temperatura en un punto de una sala de servidores. El aparato de red puede tener, por ejemplo, un procesador 112, un sistema de circuitos programable 114, una interfaz de red 116, un sensor de temperatura 118 y varios medios de almacenamiento 120. El aparato de red puede funcionar para realizar mediciones de temperatura periódicas. Además, el aparato de red puede revisar periódicamente la conexión con uno o más aparatos homólogos para establecer un comportamiento de grupo. Además, el aparato de red puede funcionar para suministrar datos de temperatura periódicamente o bajo solicitud al aparato homólogo o al sistema de supervisión remoto.

En una realización alternativa, el aparato de red puede tener un procesador 112, un sistema de circuitos programable 114, una interfaz de red 116 y un módem 136. El aparato de red puede utilizar la interfaz de conexión en red para establecer comunicaciones entre homólogos con otros aparatos del sistema. Además, tras una alerta de otro aparato del sistema, un aparato de red puede activar el módem y establecer un nuevo enlace de comunicaciones con un sistema de supervisión remoto. Como alternativa, el módem puede utilizarse para realizar radiolocalizaciones, llamadas telefónicas o para llevar a cabo otra funcionalidad de comunicación para avisar a una parte responsable con respecto al estado de un aparato homólogo.

Un procedimiento a modo de ejemplo para establecer un comportamiento interactivo complejo entre aparatos de red tal como la activación del módem en respuesta a una alerta de un aparato homólogo es la utilización de un directorio de dispositivo. La fig. 9 es un diagrama de bloques de una realización a modo de ejemplo de un directorio de dispositivo. Un directorio de dispositivo puede contener una identificación de dispositivo, información relacionada con las actividades soportadas de cada dispositivo asociado con la identificación de dispositivo, y otros datos asociados con el dispositivo y/o su funcionalidad.

El directorio de dispositivo puede establecerse a través de varios medios. Estos medios pueden incluir radiodifusión y/o verificación de conexión con otros dispositivos encontrados en la red interconectada. Los dispositivos homólogos pueden comunicar entre los mismos información asociada con esos dispositivos, las actividades soportadas por esos dispositivos y los datos asociados con el dispositivo y actividades soportadas.

Estas comunicaciones y el directorio pueden presentar varios datos. Estos datos pueden incluir direcciones de red de aparato, nombre de anfitrión, modelo de aparato, versión de software de aparato, sensores y dispositivos de aparato, funcionalidad y/o capacidades de aparatos, algoritmos, valores prefijados, tareas, etc. Además, los datos pueden incluir información acerca de los sensores y dispositivos de aparato incluyendo, por ejemplo, ID de dispositivo local, tipos de dispositivo, etiqueta de dispositivo, ubicación de dispositivo y varios atributos específicos del tipo de dispositivo. El aparato de red también puede programarse para notificar sus datos a directorios de otros dispositivos tras el reinicio, el apagado y otros eventos.

Además, los aparatos de red pueden programarse para soportar consultas para devolver atributos y atributos de dispositivos soportados. Los aparatos de red pueden programarse para realizar consultas de otros aparatos. Además, los aparatos pueden soportar validaciones de ID de dispositivo y aparato para permitir la detección de antiguas referencias a dispositivos eliminados.

La estructura de directorio puede permitir que los aparatos de red supervisen dispositivos y sensores de otros aparatos de red y/o aparatos homólogos. De ese modo, un aparato de red puede actuar en respuesta al valor de una variable de otro aparato. Por ejemplo, un aparato de red con cámara puede supervisar un sensor de puerta de otro aparato de red. Además, el aparato de red con cámara puede enviar, transmitir o transferir una imagen en respuesta a la apertura de la puerta.

Como alternativa, un aparato de red puede controlar el comportamiento de otro dispositivo. Por ejemplo, utilizando el directorio, un aparato puede determinar la dirección de otro aparato con capacidades de correo electrónico y controlar el envío de un mensaje a través de ese otro aparato.

En otro ejemplo, un umbral de sensor de puerta puede estar definido en un aparato y ofrecer la opción de una lista de selección múltiple de sensores de puerta en diferentes aparatos registrados con el directorio, así como de una lista de selección múltiple de cámaras en varios aparatos. El umbral resultante calcula la apertura de puerta en cualquiera de los sensores de puerta para dar como resultado la generación, mediante el aparato, de correo electrónico con imágenes capturadas desde una o más cámaras diferentes.

En un ejemplo adicional, un panel de configuración de contenido de correo electrónico para alertas de sensor puede ofrecer un par de cuadros de lista de tipo añadir/eliminar para permitir el control de la adición de los valores actuales de varios sensores de varios aparatos en el correo electrónico.

En otro ejemplo, un umbral de sensor de temperatura puede estar definido en un aparato y ofrecer la opción de una lista de selección múltiple de sensores de temperatura en varios aparatos. Como resultado, se aplicará una única definición de umbral a estos múltiples sensores y solo se generará un único flujo de alertas SNMP y/o de correos electrónicos a diferencia de los múltiples mensajes de los aparatos con los sensores de temperatura. Los correos electrónicos de notificación pueden incluir los valores actuales de todos los sensores seleccionados, así como una indicación de si un sensor dado generó o no un error.

Para soportar estas actividades, cada aparato puede soportar una interfaz basada en el procedimiento POST de HTTP para consultar los valores actuales de múltiples atributos. La interfaz puede realizar consultas mediante el ID único de dispositivo. Para cámaras y otros sensores especiales, una interfaz basada en el procedimiento POST de HTTP puede utilizarse para devolver imágenes, datos de flujo continuo, flujos de sonido y otros tipos de datos.

Además, una interfaz de configuración basada en el procedimiento POST de HTTP puede permitir la definición de umbrales en el aparato que notificarán al aparato de configuración cuándo se ha producido una infracción. Los aparatos pueden soportar múltiples instancias de estos umbrales por atributo. Además, un mecanismo de notificación de infracciones de umbral basado en el protocolo POST de HTTP puede utilizarse para informar al propietario remoto del umbral con relación a la infracción.

Además, una interfaz basada en el procedimiento POST de HTTP puede permitir que los aparatos validen los umbrales configurados de manera remota en el aparato. Esto puede llevarse a cabo preguntando al aparato que fijó el umbral si el umbral es todavía válido. Los aparatos pueden utilizar esta interfaz cuando haya un intervalo de tiempo disponible, tal como interrupción de servicio de red o un reinicio del aparato.

Además, una interfaz basada en el procedimiento POST de HTTP también puede consultar el estado de umbrales configurados remotamente en el aparato para permitir la sincronización entre el aparato que configuró los umbrales y el aparato que los implementa. La consulta puede utilizarse, por ejemplo, después de un reinicio o de una interrupción de servicio de red.

Además, una interfaz basada en el procedimiento POST de HTTP puede utilizarse para fijar las variables de salida de dispositivos de salida. Estos dispositivos también pueden soportar una interfaz de consulta de valores actuales.

Aunque la interfaz basada en el procedimiento POST de HTTP se ha utilizado para fines a modo de ejemplo, pueden concebirse otras interfaces que lleven a cabo varias funcionalidades. Estas interfaces pueden utilizar otros protocolos incluyendo FTP, SNMP, CIM, SOAP, TCP o UDP propietario, LDAP, etc.

Al permitir la especificación de más de un servicio/aparato de directorio, se consigue una medida de tolerancia a fallos. Para ayudar en la recuperación de los fallos, los aparatos de directorio pueden ser comunes a todos los elementos de un conjunto de aplicaciones, y pueden estar configurados para que se reconozcan entre sí. Cuando un aparato de servicio de directorio está activo, puede intentar contactar con uno de sus homólogos y solicitar una lista de todos los aparatos conocidos por los homólogos. Esta lista puede utilizarse para actualizar la lista de aparatos conocidos por el aparato de directorio y, a su vez, utilizarse para solicitar a cada uno de estos aparatos que vuelvan a publicar sus datos en el aparato. Los aparatos que están conectados de manera satisfactoria pero que rechazan volver a publicar sus datos pueden descartarse.

Con el fin de proporcionar seguridad, cada aparato de directorio puede soportar la opción de configurar un ID de usuario y una contraseña de acceso que pueden estar configurados en cada aparato que intente unirse y utilizar el directorio. Para una mayor seguridad, pueden requerirse contraseñas únicas a cada aparato que intente utilizar el directorio. Otras realizaciones pueden soportar cualquiera de una variedad de servidores (LDAP, Kerberos, DCE, NIS) o de mecanismos (firmas digitales, cifrado de clave pública-privada) de seguridad.

En una realización alternativa, un único aparato de red puede establecer un directorio maestro. El aparato de red de directorio maestro puede interrogar otros aparatos presentes en la red y recibir información que puede almacenarse en el directorio.

Otros medios de tolerancia a fallos con los aparatos de directorio pueden ser implementar una conmutación por error basada en direcciones IP entre aparatos de directorio primarios y secundarios. De esta manera, todos los aparatos solo harán referencia e interactuarán con un único aparato de directorio. Esta implementación puede requerir que cada uno de los aparatos de directorio tenga una dirección IP distintiva, presentando además uno de los mismos (en un momento dado) la dirección IP asignada al aparato de directorio. El aparato de directorio primario puede presentar, por defecto, la dirección IP del aparato de directorio y su propia dirección IP distintiva. El aparato secundario puede poseer una dirección IP distintiva. Cualquier actualización del aparato primario puede comunicarse inmediatamente al aparato secundario para mantener la sincronización. Por otro lado, el aparato secundario puede interrogar de manera regular al aparato primario para comprobar si se produce un fallo. Si se produce un fallo, el aparato secundario puede, por ejemplo, activar en él mismo la dirección IP de servicio de directorio, enviar soluciones ARP gratuitas a la red para hacer que cualquier memoria caché ARP de la red reconozca la nueva ubicación de la dirección IP, y adoptar el papel del aparato de directorio primario. Una vez que se haya sustituido o reparado, el anterior aparato de directorio primario puede contactar con el nuevo aparato primario, sincronizar datos de directorio y adoptar el papel del aparato de directorio secundario.

La fig. 10A muestra un aparato de red A con un directorio. Los aparatos de red B, C, D y E se comunican con el aparato de red A para establecer el directorio. Estos aparatos pueden comunicarse con el aparato de red A a través de la red interconectada.

Además, el aparato de red puede interrogar al aparato de red con el directorio maestro para localizar recursos que pertenecen a otros aparatos de red. De esta manera, un aparato de red puede mejorar su propia funcionalidad utilizando características y funcionalidades de otros aparatos de red. Por ejemplo, el aparato de red B puede detectar una variable ambiental. Sin embargo, el aparato B puede no presentar la capacidad de enviar correo electrónico a través de una red global. El aparato de red C no puede detectar variables ambientales. Sin embargo, puede tener una conexión a una red global. De ese modo, el aparato de red B puede consultar el directorio del aparato de red A para obtener información de la conexión global del aparato de red C. El aparato de red B puede comunicarse después con el aparato de red C para establecer un enlace externo.

En una realización a modo de ejemplo incluso más compleja, el aparato de red B puede detectar una variable ambiental. El aparato de red B puede no presentar una funcionalidad de imágenes o conexión a una red externa. De ese modo, el aparato de red B, tras establecer una condición de alarma u otra condición puede consultar, por ejemplo, el aparato de red A y el directorio del aparato de red A. Después, el aparato de red B puede obtener información acerca de los recursos de los aparatos de red E, D y C. De ese modo, el aparato de red B puede comunicarse, por ejemplo, con un aparato de red con cámara E. El aparato de red E pueden enviar después una imagen a través del aparato de red C a través de la red externa. De esta manera, pueden establecerse comportamientos cada vez más complejos utilizando la agrupación manteniendo al mismo tiempo la autonomía de los diversos aparatos de red. Incluso además, el directorio puede almacenarse en varios aparatos de red.

Tal y como se observa en la fig. 10B, el directorio puede residir en el aparato de red E. Por ejemplo, el aparato de red E puede haber establecido una comunicación entre homólogos con el aparato de red A. Tras un fallo o el apagado del aparato de red A, el aparato de red E puede haber establecido la necesidad de un nuevo directorio. De ese modo, el aparato de red E puede haber adquirido el directorio del aparato de red A, o el aparato de red E puede volver a realizar interrogaciones y radiodifusiones para descubrir las actividades soportadas por el dispositivo y los diversos datos asociados con esos dispositivos y actividades soportadas a partir de los otros aparatos de red conectados a la red interconectada. Otro procedimiento para facilitar la transferencia del directorio y de cualquier otro dato requerido por la agrupación en su totalidad o por varios dispositivos de la agrupación puede necesitar establecer una lista maestra y una lista esclava.

La fig. 11A es un diagrama de flujo de bloques de un procedimiento a modo de ejemplo para crear un directorio. En el procedimiento 140, un aparato de red puede determinar la ubicación de un directorio, tal y como se observa en el bloque 142. El directorio puede estar almacenado en otro aparato de red. Como alternativa, el directorio puede estar almacenado en un servidor.

En el siguiente bloque 144, el aparato de red puede informar al dispositivo de directorio y controlar el almacenamiento de información asociada con el aparato de red. Esta información puede incluir direcciones, recursos, sensores, responsabilidades, identificadores únicos, datos, datos de relación entre homólogos, partes responsables, etc. Además, la información puede incluir parámetros de configuración.

En un procedimiento alternativo, el dispositivo de directorio puede iniciar un contacto con el aparato de red y solicitar información para su almacenamiento en una base de datos. La fig. 11B es un diagrama de flujo de bloques de un procedimiento a modo de ejemplo para crear un directorio. El dispositivo de directorio puede localizar el aparato de red, tal y como se observa en el bloque 146. El dispositivo de directorio puede utilizar varios medios tales como un recorrido por direcciones, una captura SNMP, consultar aparatos en direcciones conocidas, adquirir direcciones de homólogo a partir de aparatos conocidos, etc.

Tal y como se observa en el siguiente bloque 147, el dispositivo de directorio puede solicitar datos del aparato de red. Los datos pueden incluir direcciones, recursos, sensores, responsabilidades, identificadores únicos, datos, datos de relaciones entre homólogos, partes responsables, etc. Además, la información puede incluir parámetros de configuración. Después, el dispositivo de directorio puede ajustar el directorio consecuentemente, tal y como se observa en el bloque 148.

El dispositivo de directorio puede adoptar la forma de un aparato de red. Como alternativa, el dispositivo de directorio puede adoptar la forma de un servidor. Además, el dispositivo de directorio puede adoptar la forma de un aparato de red con acceso a una base de datos que resida en un servidor. De ese modo, el directorio puede almacenarse en el aparato de red, en un servidor, en una unidad de red, etc.

En una realización general a modo de ejemplo, tal y como se observa en la fig. 12, un aparato de red A puede tener datos maestros A. El aparato de red B puede tener una comunicación entre homólogos con el aparato de red A y puede establecer un conjunto de datos esclavos asociado con el conjunto de datos maestros A. Éste puede ser, por ejemplo, un directorio maestro y esclavo o puede adoptar la forma de otros datos recíprocamente útiles para A o B o para otros aparatos en la red. Además, el aparato de red B puede contener la lista maestra (datos maestros B) que almacena otra información diversa. Además, el aparato de red C puede almacenar datos esclavos para B y, de manera más redundante, puede almacenar datos esclavos para A. Sin embargo, el aparato de red no necesita almacenar ningún dato esclavo ni ninguna lista maestra tal y como se observa en el aparato de red D.

Además, uno o más servidores pueden estar conectados o no a la red. Los datos pueden estar almacenados en estos servidores. Los datos pueden adoptar la forma de un directorio, datos maestros, datos esclavos, etc. De ese modo, el servidor y los datos pueden adoptar varias formas. Estas formas pueden incluir, por ejemplo, archivos en un servidor de archivos, una base de datos en un servidor de bases de datos, un servidor LDAP, etc. Uno o más de los aparatos de red acoplados a la red interconectada pueden ser clientes del o de los servidores.

De esta manera, el comportamiento complejo puede beneficiarse además de los datos colectivos. Por ejemplo, una parte responsable puede desear un correo electrónico tras una condición de temperatura dada. Si en la sala hay uno o más sensores de temperatura, una regla de alerta y el número de radiolocalizador asociado o la dirección de correo electrónico y otros datos pueden almacenarse en una lista de datos maestros accesible de manera comunitaria. La información puede almacenarse además en cada dispositivo de sensor de temperatura como un conjunto de datos esclavos. De ese modo, cuando se cumple una condición de temperatura, la notificación puede enviarse a la parte responsable. El dispositivo de detección de temperatura en el que se cumple la condición puede elegir consultar la lista de datos maestros para determinar cómo, cuándo o qué hacer con la información. Como alternativa, el aparato de red puede utilizar la lista de datos esclavos o el conjunto de datos para determinar su comportamiento.

De esta manera, se permite redundancia de la información accesible de manera comunitaria. Además, un usuario puede cambiar la información deseada en una ubicación y hacer que esa información sea universal.

Además puede implementarse una conmutación por error de supervisión remota y un equilibrio de carga. Una pluralidad de las características implementadas por aparatos de supervisión pueden basarse en la observación a través de la red de otro dispositivo, especialmente a través de protocolos tales como SNMP, CIM y HTTP. En presencia de múltiples aparatos, la elección de qué aparatos supervisan qué dispositivos de red puede estar asociada con las funcionalidades y capacidades de los aparatos individuales. Esto puede utilizarse como la base para la asignación dinámica de tareas de supervisión de dispositivos y de un mecanismo para la conmutación por error de responsabilidades de supervisión si un aparato falla. Además, el equilibrio de cargas, la supervisión de conmutación por error y la asignación dinámica pueden aplicarse a la supervisión de sensores compartidos.

En el procedimiento a modo de ejemplo 150 mostrado en la fig. 13 pueden reasignarse responsabilidades y/o recursos. Por ejemplo, en caso de que un dispositivo homólogo falle, como se observa en el bloque 152, un aparato de red puede acceder al directorio para determinar qué recursos, responsabilidades y contactos están asignados al dispositivo defectuoso.

Los recursos pueden ser, por ejemplo, gestión de datos, capacidades, funciones, sensores, etc. El fallo de un dispositivo puede disminuir las capacidades de una agrupación. Como alternativa, los dispositivos que dependen de las capacidades y de la funcionalidad del aparato defectuoso pueden ser informados del fallo. De esta manera, los aparatos que dependen del aparato defectuoso pueden determinar, accediendo al directorio o a otros medios, si pueden y cómo pueden acceder a un dispositivo alternativo, notificar a una parte responsable con relación a la pérdida de capacidad y/o establecer relaciones entre homólogos, etc. Por ejemplo, un dispositivo con un módem puede actuar como un medio para radiolocalizar partes responsables. Si este dispositivo falla, la agrupación puede perder capacidades de radiolocalización. Además, los dispositivos homólogos perderían una relación entre homólogos. De ese modo, la agrupación necesitaría encontrar un dispositivo alternativo con capacidad de radiolocalización o un medio alternativo de comunicación, por ejemplo alarmas. Además, pueden establecerse nuevas relaciones entre homólogos. Sin embargo, pueden concebirse varios ejemplos de recursos.

Las responsabilidades pueden incluir supervisar sensores compartidos, el directorio o un servicio de directorio de reserva, un servicio de almacenamiento de datos, relaciones entre homólogos, supervisión de alarmas, etc. El aparato de red que supervisa al aparato defectuoso puede reasignar las responsabilidades. Por ejemplo, el aparato puede interrogar otros aparatos para solicitar la aceptación de responsabilidad. Los otros aparatos pueden encontrarse, por ejemplo, en el directorio. Por ejemplo, el aparato puede acceder al directorio para determinar qué otros aparatos pueden comunicarse con un sensor inalámbrico compartido. Después, el aparato puede asignar o solicitar la aceptación de responsabilidad desde otro aparato, tal y como se observa en el bloque 156.

Además, el aparato puede notificar a las partes responsables con relación al fallo del homólogo, tal y como se observa en el bloque 158. El aparato puede acceder, por ejemplo, al directorio para determinar quiénes son las partes responsables y cómo contactar con las mismas.

Además, el aparato de red puede ajustar el directorio, tal y como se observa en el bloque 160. El ajuste puede reflejar el fallo del aparato, la eliminación del aparato, la reasignación de responsabilidades, acciones realizadas en respuesta al fallo, etc.

Estas etapas pueden llevarse a cabo en varias combinaciones o no realizarse. Además, pueden concebirse otros diversos procedimientos para la reasignación de recursos, la asignación dinámica de responsabilidades y la notificación a las partes responsables. Además, el procedimiento 150 puede llevarse a cabo por un dispositivo antes de un apagado o desactivación planificado.

En un ejemplo, cada aparato de un conjunto de aparatos registrados con un conjunto dado de aparatos de directorio (un "dominio de aparatos") puede publicar un conjunto de registros en el directorio describiendo sus capacidades de supervisión remota. Específicamente, puede definirse un registro para cada tipo de supervisión remota que contiene la cantidad de dispositivos que pueden soportarse, el número de dispositivos que están supervisándose actualmente, la versión de implementación de la supervisión remota y otros atributos específicos del tipo de supervisión. Cada registro puede codificarse, por ejemplo, mediante la combinación del número de serie del aparato y el tipo de supervisión remota.

Los contenidos de este directorio de capacidades se utilizarán por herramientas de configuración (para determinar qué capacidad de supervisión remota está disponible y si alguna capacidad adicional está disponible) y para responder a fallos (ya que el directorio ayudará a determinar qué otros dispositivos pueden tener asignadas tareas de aparatos defectuosos).

Los aparatos registrados en un dominio de aparatos dado pueden definir la configuración de cualquier supervisión remota como un conjunto de registros de directorio. Cada registro de este tipo puede incluir el tipo de supervisión remota, la dirección e identidad del dispositivo que va a supervisarse, el número de serie de aparato del aparato que está supervisando actualmente al dispositivo, y cualquier ajuste específico del tipo de supervisión.

En un ejemplo, cuando un nuevo dispositivo está configurado para la supervisión, un nuevo registro puede añadirse al directorio de configuración sin ningún aparato inicial asignado. La herramienta de configuración puede consultar después el directorio de capacidades para encontrar algún aparato con la capacidad de supervisión requerida y la capacidad de supervisar dispositivos adicionales. Después, la lista resultante de aparatos puede ordenarse en función de prioridades tales como la ubicación de subred con respecto al dispositivo, la capacidad disponible y el nivel de función de supervisión. Después, la herramienta de configuración puede recorrer la lista ordenada, enviando solicitudes a cada aparato para aceptar la responsabilidad de supervisar el dispositivo hasta que un aparato acepte dicha responsabilidad. El aparato que acepte puede establecerse como el aparato de supervisión del dispositivo.

Cuando un aparato falle, el aparato homólogo que detecta la avería puede consultar el directorio de configuración para buscar registros pertenecientes al dispositivo defectuoso. Si encuentra alguno, puede solicitar que el registro se fije como que no pertenece a ningún dispositivo (número de serie = 0) y puede repetir el mismo algoritmo de asignación utilizado para la configuración inicial hasta que se encuentre un nuevo dueño. Si un aparato está apagándose o está eliminándose del domino de aparatos, puede repetir este mismo procedimiento en su propio nombre asignando sus responsabilidades a otros dispositivos. Además, estos procedimientos de reasignación pueden aplicarse a la responsabilidad de supervisión de sensores compartidos.

Una pluralidad de otros elementos de configuración puede proporcionar un beneficio considerable si está definida de manera compartida en el directorio del dominio de aparatos. Específicamente, los objetos compartidos para elementos tales como privilegios y cuentas de usuario, plantillas de notificación de correo electrónico, perfiles de respuesta de acción, listas de notificación de correo electrónico y listas de objetivos de capturas SNMP son beneficiosos.

Para proporcionar un mecanismo eficaz para estos objetos, la implementación de servidores y de clientes de directorio puede mejorarse para proporcionar y soportar un mecanismo de suscripción de configuración con almacenamiento local y permanente de diferentes registros en memoria caché. Específicamente, cada aparato que está interesado en un objeto compartido dado puede abonarse a ese objeto del servidor de directorio. Esto puede dar como resultado que el aparato reciba una copia inicial del registro, así como la recepción automática de actualizaciones de ese registro cuando el "maestro" está actualizado. De ese modo, el aparato puede utilizar después los datos sin solicitar constantemente la información del servidor de directorio y también puede funcionar con la copia de los datos almacenada en memoria caché si se produce una avería en la red o en servidor de directorio. La lista de abonado para cada registro de directorio puede almacenarse permanentemente con el registro en el servidor de directorio, de manera que un aparato que haya estado desconectado puede actualizarse automáticamente cuando establece contacto con el servidor de directorio.

Los objetos de configuración compartidos pueden publicarse como registros con nombre en el servidor de directorio y pueden consistir en un ID único de dominio, una etiqueta, un tipo y una lista de pares atributito/valor específicos del tipo de objeto.

Los objetos compartidos pueden incluir cuentas de usuario, listas de notificación de correo electrónico, listas de notificación de capturas SNMP, plantillas de notificación de correo electrónico, perfiles de respuesta de acción, etc. Las cuentas de usuario pueden simplificar la gestión de control de acceso para un grupo de aparatos, permitiendo un ID de usuario/contraseña únicos para todos los aparatos y una manera de aplicar control de acceso a nuevos aparatos añadidos al grupo. Las cuentas pueden soportar listas de control de acceso para acceder a aparatos específicos, dispositivos acoplados a estos aparatos y otros objetos compartidos.

Las listas de notificación de correo electrónico pueden permitir la administración de listas de notificación compartidas, de manera que las diversas acciones de notificación configuradas en diferentes aparatos pueden configurarse según la necesidad de interactuar con cada aparato directamente. Los atributos de configuración que se refieren a direcciones de correo electrónico pueden soportar tanto direcciones de correo electrónico explícitas como referencias simbólicas a listas compartidas de notificación de correo electrónico.

Las listas de notificación de capturas SNMP, así como de correo electrónico, donde están especificados los objetivos de las capturas SNMP pueden soportar listas de objetivos explícitas y referencias simbólicas a listas compartidas de notificación SNMP.

Las plantillas de notificación de correo electrónico pueden ser "cartas modelo" definidas por el usuario para notificaciones de alarma mediante correo electrónico, permitiendo al usuario indicar qué texto enviar y soportando macros para la inserción de varios atributos del aparato y de sus dispositivos y sensores. Permitiendo que múltiples aparatos compartan estas definiciones puede proporcionarse una personalización sencilla y coherente de estas notificaciones en muchos aparatos.

Los perfiles de respuesta de acción pueden definir un conjunto de respuestas, incluyendo acciones repetidas y escalado, a condiciones de alerta detectadas a través de umbrales u otros medios. Muchos consumidores con múltiples aparatos pueden permitir que estas respuestas sean coherentes y de fácil actualización en sus aparatos.

Los recursos de directorio y los objetos compartidos, entre otros elementos, pueden utilizarse para permitir la configuración masiva de dispositivos. En el procedimiento 170 mostrado en la fig. 14, un usuario puede definir una configuración que vaya a aplicarse a múltiples dispositivos, tal y como se observa en el bloque 172. La configuración puede incluir perfiles de respuesta de acción, plantillas de notificación de correo electrónico, listas de notificación de capturas de SNMP, listas de notificación de correo electrónico, objetos de configuración compartidos, etc.

Después, el usuario puede acceder al directorio o a otro dispositivo de almacenamiento y almacenar la configuración, tal y como se observa en el bloque 174. Por ejemplo, el usuario puede acceder al dispositivo de directorio, al dispositivo proxy, al aparato primario, etc.

Después, la configuración puede distribuirse tal y como se observa en el bloque 176. La distribución puede llevarse a cabo interrogando aparatos que tienen asignada la configuración, transfiriendo los datos al aparato tras la solicitud del aparato y mediante otros procedimientos.

Además, los recursos de directorio y los objetos compartidos, entre otros elementos, pueden utilizarse para generar un comportamiento de aparato complejo. Por ejemplo, tal y como se observa en la fig. 15, puede establecerse un procedimiento para utilizar recursos compartidos. Tal y como se observa en el procedimiento 190, un aparato puede entrar en un estado de alarma, tal y como se observa en el bloque 192. Sin embargo, esta etapa puede estar incluida o no en el procedimiento 190.

El aparato puede evaluar un procedimiento establecido, tal y como se observa en el bloque 194. El procedimiento establecido puede ser instrucciones para informar a una parte responsable, controlar el comportamiento de otro dispositivo, informar a otro aparato, etc. Sin embargo, esta etapa puede estar incluida o no en el procedimiento 190.

El aparato puede acceder al directorio, tal y como se observa en el bloque 196. De ese modo, el aparato puede determinar la dirección de otros aparatos con recursos deseados. Por ejemplo, un aparato con alarma de puerta puede acceder al directorio para determinar la dirección de un aparato con cámara. Como alternativa, un aparato con sensor de temperatura puede acceder al directorio para determinar la dirección de un aparato de radiolocalización. Además, el aparato puede acceder al directorio para buscar listas de notificación, procedimientos y otros objetos compartidos.

El aparato puede acceder a recursos de otros aparatos, tal y como se observa en el bloque 198. Por ejemplo, el aparato con alarma de puerta puede acceder a las imágenes del aparato con cámara. Como alternativa, el aparato con alarma de puerta puede controlar al aparato con cámara para enviar una imagen a una parte responsable. En otro ejemplo, un aparato con sensor de temperatura puede controlar un aparato con radiolocalizador para llevar a cabo radiolocalización con una parte responsable. Sin embargo, pueden concebirse varios ejemplos de comportamiento complejo.

Además, para soportar una única interfaz tolerante a fallos para GUI de configuración y aplicación para interactuar con el dominio de aparatos como una única unidad, puede implementarse soporte para una o más direcciones IP "flotantes" (similar al mecanismo de conmutación por fallo descrito para el servidor de directorio). Esto puede permitir que uno de los aparatos del dominio de aparatos posea una dirección IP adicional dada destinada para el acceso mediante partes externas (es decir, navegadores web, aplicaciones Java, etc.). Al igual que el servidor de directorio, pueden configurarse uno o más aparatos de reserva en la misma subred, de manera que un fallo en el aparato primario puede dar como resultado que uno de los aparatos de reserva "reivindique" la dirección IP pública, permitiendo un servicio ininterrumpido.

Además de soportar conmutación por error de dirección IP pública, los aparatos pueden soportar un proxy de solicitudes a otros aparatos del dominio. Por ejemplo, solicitudes para acceder a datos de configuración o a datos de sensor de un aparato dado pueden llevarse a cabo o bien interactuando directamente con el aparato o bien transmitiendo una solicitud a través del aparato que posee la dirección IP pública. El acceso por proxy puede realizarse mediante el número de serie de aparato, de manera que puede soportarse DHCP u otra reasignación de dirección IP no anunciada. Permitiendo el acceso por proxy también se permite soportar de mejor manera el acceso a través de cortafuegos (ya que solamente la dirección IP pública necesita estar "abierta"). Para soportar solicitudes por proxy pueden utilizarse, por lo general, cuentas de usuario compartidas, ya que el contexto de seguridad de la aplicación solicitante necesita ser igualmente coherente para todos los aparatos del dominio.

Así pues se ha descrito un sistema de supervisión. En vista de la descripción detallada anterior de la presente invención y de los dibujos asociados, otras modificaciones y variaciones resultarán ahora evidentes a los expertos en la materia. También resulta evidente que estas otras modificaciones y variaciones pueden llevarse a cabo sin apartarse del alcance de la presente invención descrita en las siguientes reivindicaciones.

Claims (19)

1. \global\parskip0.950000\baselineskip

   1. Un procedimiento para establecer una relación de revisión entre homólogos entre un primer (1) y un segundo (2) aparato de red, estando conectados el primer y el segundo aparato de red a una red interconectada (32), comprendiendo el procedimiento:

   determinar una dirección del segundo aparato de red (2) con el primer aparato de red (1), estando asociada la dirección del segundo aparato de red (2) con la red interconectada (32);

   enviar un mensaje de verificación de conexión al segundo aparato de red (2) desde el primer aparato de red (1) a través de la red interconectada (32);

   responder selectivamente al mensaje de verificación de conexión desde el primer aparato de red (1) con el segundo aparato de red (2);

   establecer una periodicidad entre el envío de mensajes periódicos posteriores de verificación de conexión en función de una periodicidad deseada proporcionada al primer aparato de red por el segundo aparato de red; y

   enviar selectivamente de manera periódica mensajes periódicos posteriores de verificación de conexión desde el primer aparato de red (1) al segundo aparato de red (2) a través de la red interconectada (32) y donde el intervalo de tiempo entre los mensajes periódicos posteriores de verificación de conexión está asociado con la periodicidad establecida.

   \vskip1.000000\baselineskip

2. 2. El procedimiento según la reivindicación 1, en el que el mensaje de verificación de conexión utiliza un procedimiento POST de HTTP.
3. 3. El procedimiento según la reivindicación 1, en el que el mensaje de verificación de conexión utiliza un procedimiento FTP.
4. 4. El procedimiento según la reivindicación 1, donde el procedimiento comprende además:

   enviar selectivamente un mensaje de notificación en caso de que no se reciba una verificación de conexión periódica esperada.

   \vskip1.000000\baselineskip

5. 5. El procedimiento según la reivindicación 4, en el que el mensaje de notificación se envía a una ubicación remota (49).
6. 6. El procedimiento según la reivindicación 4, en el que el mensaje de notificación se envía a otro aparato de red (2 a 5) conectado a la red interconectada (32).
7. 7. Un aparato de red (1, 110) que puede hacerse funcionar para establecer una relación de revisión entre homólogos con un segundo aparato de red (2) conectado a una red interconectada (32), comprendiendo el aparato de red (1, 110):

   un procesador (112);

   una interfaz de red (116) acoplada de manera comunicativa al procesador (112), pudiendo conectarse la interfaz de red (116) a la red interconectada (32);

   un medio de almacenamiento (120) acoplado de manera comunicativa al procesador (112), pudiendo hacerse funcionar el medio de almacenamiento (120) para almacenar conjuntos de instrucciones; y

   un conjunto de instrucciones (126) para establecer una relación de revisión entre homólogos con dicho segundo aparato de red (2), estando configurado dicho conjunto de instrucciones (126) para hacer que dicho procesador (112):

   determine una dirección del segundo aparato de red (2), estando asociada la dirección de dicho segundo aparato de red con la red interconectada (32);

   envíe un mensaje de verificación de conexión al segundo aparato de red (2) a través de la red interconectada (32);

   establezca una periodicidad entre el envío de mensajes periódicos posteriores de verificación de conexión en función de una periodicidad deseada proporcionada por el segundo aparato de red (2); y

   envíe mensajes periódicos posteriores de verificación de conexión al segundo aparato de red (2) a través de la red interconectada (32) a intervalos de tiempo en función de la periodicidad establecida.

   \global\parskip1.000000\baselineskip

8. 8. El aparato de red según la reivindicación 7, en el que el procesador (112) es un procesador basado en Java.
9. 9. El aparato de red según la reivindicación 8, que comprende además un medio para la comunicación con un sistema remoto (49).
10. 10. El aparato de red según la reivindicación 7, que comprende además al menos un sensor (118) acoplado de manera comunicativa al procesador (112).
11. 11. El aparato de red según la reivindicación 10, que comprende además al menos un umbral, estando asociado el al menos un umbral con valores medidos por el al menos un sensor (118).
12. 12. El aparato de red según la reivindicación 11, que comprende además un conjunto de instrucciones (124) para enviar una notificación en respuesta al al menos un umbral alcanzado por los valores medidos por el al menos un sensor (118).
13. 13. Una agrupación que comprende el aparato de red según cualquiera de las reivindicaciones 7 a 12 dispuesto con un segundo aparato de red (2) como una agrupación de aparatos de red, en el que:

    la agrupación comprende una red interconectada (32) que conecta los dos aparatos de red (1, 2),

    uno de los aparatos de red de la agrupación puede hacerse funcionar para comunicarse con un sistema remoto (49); y

    los aparatos de red (1, 2) pueden hacerse funcionar para establecer entre sí una relación de revisión entre homólogos.

    \vskip1.000000\baselineskip

14. 14. La agrupación según la reivindicación 13, en la que el aparato de red de la agrupación, que puede hacerse funcionar para comunicarse con el sistema remoto (49), está configurado para comunicarse con el sistema remoto (49) utilizando un procedimiento POST de HTTP.
15. 15. La agrupación según la reivindicación 13, en la que el aparato de red de la agrupación, que puede hacerse funcionar para comunicarse con el sistema remoto (49), está configurado para comunicarse con el sistema remoto (49) utilizando un procedimiento FTP.
16. 16. La agrupación según la reivindicación 13, en la que el aparato de red de la agrupación, que puede hacerse funcionar para comunicarse con el sistema remoto, está configurado para actuar como un intermediario entre el sistema remoto y el otro aparato de red de la agrupación.
17. 17. La agrupación según la reivindicación 16, en la que el otro aparato de red de la agrupación, que puede hacerse funcionar para comunicarse con el sistema remoto, está configurado para establecer una relación de revisión entre homólogos con el aparato de red de la agrupación que está configurado para comunicarse con el sistema remoto y para actuar como el intermediario.
18. 18. La agrupación según la reivindicación 17, en la que el otro aparato de red de la agrupación está configurado para asumir de manera selectiva una dirección de red del aparato de red de la agrupación que está configurado para actuar como un intermediario en caso de que falle el aparato de red de la agrupación que está configurado para actuar como el intermediario.
19. 19. Un programa de instrucciones que puede ser ejecutado por una máquina para llevar a cabo todas las etapas de procedimiento de un procedimiento según cualquiera de las reivindicaciones 1 a 6 cuando se ejecuta en dicha máquina.