ES2646632A2 - Método y aparato para balancear recursos en una arquitectura de automatización y alarma - Google Patents

Método y aparato para balancear recursos en una arquitectura de automatización y alarma Download PDF

Info

Publication number
ES2646632A2
ES2646632A2 ES201790010A ES201790010A ES2646632A2 ES 2646632 A2 ES2646632 A2 ES 2646632A2 ES 201790010 A ES201790010 A ES 201790010A ES 201790010 A ES201790010 A ES 201790010A ES 2646632 A2 ES2646632 A2 ES 2646632A2
Authority
ES
Spain
Prior art keywords
sensor
data
gateway entity
processing
entity
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
ES201790010A
Other languages
English (en)
Other versions
ES2646632R1 (es
ES2646632B2 (es
Inventor
Andrei Bucsa
Gregory W. Hill
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Johnson Controls Tyco IP Holdings LLP
Original Assignee
Tyco Safety Products Canada Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tyco Safety Products Canada Ltd filed Critical Tyco Safety Products Canada Ltd
Publication of ES2646632A2 publication Critical patent/ES2646632A2/es
Publication of ES2646632R1 publication Critical patent/ES2646632R1/es
Application granted granted Critical
Publication of ES2646632B2 publication Critical patent/ES2646632B2/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/542Event management; Broadcasting; Multicasting; Notifications
    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803Home automation networks
    • H04L12/2823Reporting information sensed by appliance or service execution status of appliance services in a home automation network
    • H04L12/2827Reporting to a device within the home network; wherein the reception of the information reported automatically triggers the execution of a home appliance functionality
    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5016Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10Architectures or entities
    • H04L65/102Gateways
    • H04L65/1033Signalling gateways
    • H04L65/1036Signalling gateways at the edge
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/12Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/12Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H04L67/125Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/53Network services using third party service providers

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Automation & Control Theory (AREA)
  • Telephonic Communication Services (AREA)
  • Small-Scale Networks (AREA)
  • Alarm Systems (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Método y aparato para balancear recursos en una arquitectura de automatización y alarma donde se realizan tareas de procesamiento relativamente simples a nivel de sensor, con un procesamiento más complejo que se desplaza a la entidad de pasarela o a un dispositivo de procesamiento en red; donde la entidad de pasarela asigna dinámicamente recursos de procesamiento para sensores y si un sensor detecta que está ocurriendo un evento, o predice que está a punto de ocurrir un evento, el sensor presenta una solicitud de asignación de recursos y un balanceador de potencia que funciona en la entidad de pasarela procesa la solicitud; en respuesta a la solicitud de asignación de recursos, la entidad de pasarela asigna algunos recursos de procesamiento al sensor solicitante y los datos se procesan en tiempo real o casi en tiempo real por la entidad de pasarela.

Description

2 DESCRIPCIÓN Método y aparato para balancear recursos en una arquitectura de automatización y alarma Referencia cruzada a la solicitud relacionada Esta solicitud reivindica prioridad de la Solicitud de Patente Provisional de los Estados Unidos N ° 62/059.410 presentada el 3 de octubre de 2015, y titulada “Wireless Security and 5 Home Automation”. La totalidad de esta solicitud se incorpora en la presente memoria como referencia Campo de la descripción La descripción se refiere al campo de sistemas de automatización y alarma, y más particularmente a métodos y aparatos para balancear recursos en una arquitectura de 10 sistema para un sistema de automatización o alarma.Antecedentes de la descripción Los sistemas de automatización y alarma, tales como los sistemas domóticos, sistemas de alarma de incendio y sistemas de seguridad, incluyen típicamente una o más entidades de pasarela, por ejemplo, paneles de alarma, que reciben información desde diversos sensores 15 distribuidos a través de un área estructurada. En respuesta a tipos particulares de señales de entrada, los sensores o la entidad de pasarela algunas veces desencadenan una acción mediante un dispositivo de salida. Por ejemplo, un sistema de alarma de incendio típico incluye uno o más sensores, por ejemplo, detectores de humo o estaciones de extracción accionadas manualmente, etc., y dispositivos de salida, por ejemplo, luces estroboscópicas, 20 sirenas, sistemas de anuncios públicos, etc., conectados operativamente a una entidad de pasarela. En algunos sistemas de automatización y alarma tradicionales, un sensor incluye capacidad de procesamiento para procesar los datos del sensor. Por ejemplo, un sensor monitoriza señales eléctricas reunidas por el dispositivo de detección del sensor para variaciones que 25 representan la aparición de una condición de alarma. Con propósitos de registro de datos y realización de analítica de datos, el sensor reenvía información a la entidad de pasarela, y la entidad de pasarela a su vez reenvía los datos a un dispositivo de procesamiento en la nube. El dispositivo de procesamiento en la nube reúne datos de muchos sensores y/o entidades de pasarela, analiza los datos, y genera informes 30 El procesamiento de los datos en el sensor requiere que el sensor consuma energía, lo cual puede ser problemático, especialmente si el sensor está alimentado por baterías. Además, 3 los sensores individuales son relativamente complejos y caros, porque el sensor se debe dotar con suficientes recursos de procesamiento para que el sensor pueda procesar sus propios datos de forma aislada. Durante períodos de inactividad, estos recursos de procesamiento no se usan y, por lo tanto, se desperdician. Aún más, si se desarrolla una nueva actualización para el algoritmo que procesa los datos del sensor, cada sensor debe 5 recibir y procesar la actualización. Este proceso de actualización puede ser complicado y puede requerir mucho tiempo en un entorno con muchos sensores. Compendio Esta descripción aborda estos y otros problemas con los sistemas de alarma y automatización convencionales. Según las realizaciones ejemplares, se realizan tareas de 10 procesamiento relativamente simples a nivel de sensor, con un procesamiento más complejo que se desplaza a la entidad de pasarela. Otras tareas de procesamiento que requieren mayor potencia de procesamiento, por ejemplo, analítica de datos, se envían a un dispositivo de procesamiento en red, por ejemplo, un dispositivo de procesamiento en la nube) y/o a otro dispositivo de terceros. De esta manera, se proporciona una jerarquía de 15 capacidades de procesamiento, con los sensores formando un nivel inferior, la entidad de pasarela formando un nivel intermedio, y los dispositivos de procesamiento en la nube/de terceros formando un nivel superior. La entidad de pasarela asigna dinámicamente memoria o recursos de procesamiento a los sensores. Si un sensor detecta que está ocurriendo un evento, o predice que está a punto 20 de ocurrir un evento, el sensor presenta una solicitud de asignación de recursos y un balanceador de potencia que funciona en la entidad de pasarela procesa la solicitud. En respuesta a la solicitud de asignación de recursos, la entidad de pasarela asigna algunos recursos de procesamiento al sensor solicitante. Balanceando la potencia de procesamiento entre los sensores y la entidad de pasarela, los 25 sensores se pueden hacer más simples y menos caros, debido a la disminución de la potencia de procesamiento requerida. Además, se pueden proporcionar por el sistema capacidades mejoradas, tales como procesar datos de comandos de voz recibidos a través de los sensores, porque los sensores no necesitan soportar toda la carga o procesar datos complejos. Aún más, se pueden desplegar nuevas características, y se pueden actualizar 30 características antiguas, modificando solamente la lógica de procesamiento en la entidad de pasarela, en lugar de la lógica de procesamiento de cada uno de los múltiples sensores. Breve descripción de los dibujos 4 A modo de ejemplo, se describirán ahora realizaciones ejemplares específicas del sistema y método descritos, con referencia a los dibujos adjuntos, en los que: La FIG. 1 es un diagrama de bloques que ilustra una arquitectura de sistema ejemplar según la presente descripción. La FIG. 2 representa una jerarquía de dispositivos de procesamiento en la arquitectura del 5 sistema. La FIG. 3 es un diagrama de bloques que ilustra un dispositivo de detección o dispositivo de salida ejemplas según la presente descripción. La FIG. 4 es un diagrama de bloques que ilustra una entidad de pasarela ejemplar según la presente descripción. 10 La FIG. 5 es un diagrama de contexto del sistema que ilustra interacciones ejemplares entre los dispositivos de la arquitectura del sistema desde la perspectiva de la entidad de pasarela según la presente descripción. Las FIG. 6-10B representan estructuras de datos ejemplares adecuadas para su uso según la presente descripción. 15 La FIG. 11 es un diagrama de flujo de datos que ilustra flujos de datos ejemplares a través de la arquitectura del sistema según la presente descripción. La FIG. 12 es un diagrama de flujo que representa un método ejemplar realizado por un dispositivo sensor según la presente descripción. La FIG. 13 es un diagrama de flujo que representa un método ejemplar realizado por una 20 entidad de pasarela según la presente descripción. Las FIG. 14A-14B son gráficos de flujo de procesamiento ejemplares que representan los pasos de procesamiento realizados en un servicio interactivo de voz ejemplar según la presente descripción. Descripción detallada 25 Esta descripción se refiere a una arquitectura de sistema para sistemas de automatización y alarma, para los que se define una jerarquía de capacidades de procesamiento. A diferencia de los sistemas convencionales en los que la mayoría del procesamiento de datos de los sensores se maneja por los sensores respectivos, la arquitectura de sistema ejemplar mueve las tareas de procesamiento dentro de la jerarquía con el fin de conservar recursos, 30 5 realizar balanceo de carga, y asignar tareas de procesamiento a los dispositivos que son más adecuados para realizarlas. La FIG. 1 representa un ejemplo de tal arquitectura 10 de sistema. La arquitectura 10 de sistema de la FIG. 1 se pretende que sea solamente ilustrativa, y un experto en la técnica reconocerá que las realizaciones descritas a continuación se pueden emplear en una 5 arquitectura de sistema que tenga más, menos, y/o diferentes componentes que la arquitectura 10 de sistema de la FIG. 1. La arquitectura 10 de sistema incluye una zona 12 monitorizada. La zona 12 monitorizada representa una agrupación lógica de dispositivos monitorizados, y puede corresponder o no a una ubicación física definida por límites físicos, por ejemplo, una habitación o un edificio. 10 La zona 12 monitorizada representa, por ejemplo, una parte o la totalidad de una casa residencial, una empresa, una escuela, un aeropuerto, etc. La zona 12 monitorizada ejemplar incluye una serie de sensores, sensor 14 y sensor 16. Los sensores incluyen dispositivos que miden o detectan una propiedad física, como temperatura, presión, presencia de luz o humo, o la posición de un interruptor. Un sensor 15 traduce la propiedad física a una señal eléctrica, por ejemplo, usando un transductor. Ejemplos de sensores incluyen sensores ambientales, por ejemplo, sensores de temperatura, sensores de presión, sensores de humedad, sensores de nivel de luz, etc., sensores de estado, por ejemplo, interruptores de puertas y ventanas, detectores de humo, detectores de movimiento, detectores de estado de válvulas, indicadores de nivel, 20 indicadores de nivel de flujo, etc., sensores de salud, por ejemplo, sensores de ritmo cardiaco, sensores de flujo sanguíneo, sensores de nivel de azúcar, sensores de temperatura corporal, etc., sensores de localización, por ejemplo, transmisores del Sistema de Posicionamiento Global u otros sensores basados en localización colocados en personas, animales, propiedades, etc., así como sensores de propósito general o 25 multipropósito, por ejemplo, micrófonos, cámaras, interruptores de tracción manual, etc.. La zona 12 monitorizada ejemplar incluye también un dispositivo 18 de salida. Los dispositivos de salida incluyen dispositivos que proporcionan una señal de salida, tal como sonido, luz, vibración, o una instrucción para tomar una acción, en respuesta a una condición. La condición que hace al dispositivo de salida proporcionar la señal de salida 30 puede ser, por ejemplo, la detección de una salida particular de un sensor, por ejemplo, la señal del sensor que cae por debajo o que se eleva por encima de un valor umbral predefinido, o la detección de un patrón predefinido en los datos del sensor, o un mensaje desencadenador enviado al dispositivo de salida por otro dispositivo. 6 Ejemplos de dispositivos de salida incluyen dispositivos de notificación tales como altavoces, luces estroboscópicas, un motor que induce vibración en un dispositivo móvil, etc. Algunos tipos de dispositivos de notificación están configurados para proporcionar una salida perceptible por un humano, por ejemplo, un dispositivo de notificación que proporciona una salida visual, auditiva, háptica, u otra perceptible por un humano, mientras que otros tipos 5 están configurados para proporcionar una salida perceptible por una máquina, por ejemplo, una alarma silenciosa que transmite una notificación de un incidente de seguridad a un servidor en una empresa de seguridad, o una cabina telefónica de incendio que envía una alerta a un parque de bomberos. Otros ejemplos de dispositivos de salida incluyen dispositivos que controlan otros 10 dispositivos u objetos. Ejemplos de tales dispositivos de salida incluyen dispositivos que abren o cierran una puerta, encienden o apagan una luz, ajustan un dispositivo de calefacción, ventilación, o aire acondicionado (HVAC), etc. Una entidad 20 de pasarela monitoriza y controla los sensores 14, 16 y el dispositivo 18 de salida de la zona 12 monitorizada. Las entidades de pasarela incluyen dispositivos que 15 gestionan o supervisan los dispositivos de una zona 12 monitorizada, y que se comunican opcionalmente con dispositivos fuera de la zona 12 monitorizada. La entidad 20 de pasarela ejemplar procesa los datos de entrada recibidos de los sensores 14, 16 determina si los datos del sensor indican que se debería tomar una acción, tal como levantar una alarma, y dispara el dispositivo 18 de salida. Ejemplos de entidades 20 de pasarela incluyen paneles 20 de control dedicados y dispositivos informáticos locales tales como ordenadores personales o servidores locales. La entidad 20 de pasarela se puede desplegar en la zona 12 monitorizada, situada cerca de la zona 12 monitorizada, o situada remotamente, mientras que permanece comunicativamente conectada a, la zona 12 monitorizada. 25 La realización de la FIG. 1 incluye una única zona 12 monitorizada controlada por una única entidad 20 de pasarela. En otras realizaciones, se pueden controlar múltiples zonas supervisadas mediante distintas entidades de pasarela o las zonas monitorizadas se pueden monitorizar colectivamente mediante una única entidad de pasarela. Los sensores 14, 16 y el dispositivo 18 de salida están en comunicación con y conectados 30 operativamente a la entidad 20 de pasarela. La conexión puede ser una conexión inalámbrica, por ejemplo, a través de Wi-Fi o una tecnología de comunicación radio de corto alcance de baja potencia o una conexión cableada, por ejemplo, a través de cableado de 7 comunicaciones de cobre o de fibra óptica, o a través de una red de línea eléctrica. La entidad 20 de pasarela comunica con las entidades remotas a través de una red 22. Una red 22 es una colección de dos o más nodos y enlaces entre los nodos que permiten que la información comunicada sea pasada entre los nodos. Una red 22 puede estar cableada o ser inalámbrica. Ejemplos de una red 22 incluyen redes informáticas, tales como Internet, 5 una red de área local, o una red de área metropolitana, y redes telefónicas tales como centrales telefónicas terrestres y redes de telecomunicaciones inalámbricas. Existe un camino 24 crítico de temporización entre la entidad de pasarela en un lado, y los sensores 14, 16 y el dispositivo 18 de salida en el otro lado. El camino 24 crítico de temporización transporta datos sensibles al tiempo, por ejemplo, datos del sensor que 10 pueden ser indicativos de la aparición de un evento, tal como un incendio, allanamiento, o emergencia médica que se designan para procesamiento en tiempo real o casi en tiempo real a medida que están siendo generados los datos. Debido a que los datos del sensor 14 son sensibles al tiempo y están siendo procesados alejados del sensor 14 que generó los datos, el(los) camino(s) de comunicación para intercambiar información entre el sensor 14 y 15 el dispositivo de procesamiento, la entidad 20 de pasarela, en este ejemplo, debe ser robusto y relativamente rápido. En la realización representada, existe un camino 26 no crítico de temporización entre la entidad 20 de pasarela y la red 22. En esta realización, los dispositivos en el otro lado de la red 22 de la entidad de pasarela; es decir, el dispositivo 28 de procesamiento en la nube y el 20 servicio 30 de terceros, realizan tareas de procesamiento no sensibles al tiempo, relativamente complejas. Por ejemplo, el dispositivo 28 de procesamiento en la nube realiza tareas tales como agregación y registro de datos, generación de informes, y analítica de datos. Debido a que estos cálculos no son sensibles al tiempo y no necesitan ser realizados en tiempo real a medida que se generan los datos, el camino de comunicación entre la 25 entidad 20 de pasarela y la red 22 se considera un camino 26 no crítico de temporización. Sin embargo, en algunas realizaciones, las conexiones entre la entidad 20 de pasarela y otros dispositivos en la arquitectura 10 se pueden designar como caminos críticos de temporización, dependiendo de la aplicación. Los dispositivos de la arquitectura 10 de sistema, incluyendo la entidad 20 de pasarela, los 30 sensores 14 y 16, y el dispositivo 18 de salida incluyen alguna cantidad de potencia de procesamiento. Un dispositivo 28 de procesamiento en la nube aumenta las capacidades de procesamiento de los otros dispositivos en la arquitectura 10. Un dispositivo 28 de procesamiento en la nube es un dispositivo que es accesible a la entidad 20 de pasarela a 8 través de la red 22 y que proporciona capacidades de procesamiento adicionales que pueden ser invocadas por la entidad 20 de pasarela u otro dispositivo en la arquitectura 10 de sistema con el fin de realizar tareas de procesamiento. Un servicio 30 de terceros recibe información de la entidad 20 de pasarela y/o del dispositivo 28 de procesamiento en la nube. Un servicio 30 de terceros es una entidad que recibe 5 información acerca del estado de los sensores y/o zonas monitorizadas en la arquitectura 10 y es normalmente distinto de la entidad que posee o controla los dispositivos de la zona 12 monitorizada. El servicio 30 de terceros se puede, pero no necesariamente, operar por la misma entidad que opera el dispositivo 28 de procesamiento en la nube. El servicio 30 de terceros puede tomar una acción en respuesta a la información, tal como registrar la 10 información para uso futuro, agregar la información a otra información para generar un informe, reconocer emergencias, y despachar los primeros respondedores a la zona 12 monitorizada. Ejemplos de servicios 30 de terceros incluyen compañías de seguridad, parques de bomberos, consultorios médicos y hospitales, y centros de almacenamiento de datos. 15 Según las realizaciones ejemplares, los dispositivos de la arquitectura 10 de sistema están organizados en una jerarquía con propósitos de procesamiento de datos del sensor, actualización de un estado del sistema, y disparo de dispositivos de salida, entre otras posibilidades. La FIG. 2 ilustra un ejemplo de una jerarquía 32 de dispositivos en la arquitectura 10 del sistema. 20 En un nivel 34 inferior de la jerarquía 32, se agrupan juntos los sensores y los dispositivos de salida. Los sensores y los dispositivos de salida típicamente poseen capacidades de procesamiento limitadas y potencia limitada, y por lo tanto son poco adecuados para tareas de procesamiento complejas. Sin embargo, se puede confiar en tales dispositivos para realizar tareas de procesamiento relativamente simples. 25 Además, estos dispositivos se despliegan típicamente en un contexto específico y/o se invocan para monitorizar un tipo muy particular de entrada. Por ejemplo, un sensor de rotura de cristal es un tipo de sensor que emplea un micrófono para registrar sonido, por ejemplo, en las inmediaciones de una ventana, que se analiza entonces con el fin de detectar un patrón predeterminado o una señal indicativa del sonido de rotura de cristal. Incluso si el 30 sensor de rotura de cristal tiene solamente capacidades de procesamiento limitadas, esas capacidades se pueden emplear para detectar patrones de rotura de cristal relativamente simples, reduciendo de esta manera la necesidad de procesar todos los datos de sonido del sensor de rotura de cristal en la entidad 20 de pasarela. 9 Si un dispositivo en el nivel 34 inferior de la jerarquía 32 es incapaz de procesar algunos datos de entrada o no está configurado para hacerlo así, el dispositivo reenvía los datos a un dispositivo en el nivel 36 intermedio de la jerarquía 32. El nivel 36 intermedio incluye entidades de pasarela, tales como paneles de control, dispositivos informáticos locales, y en algunas situaciones dispositivos móviles tales como teléfonos celulares y tabletas. Tales 5 dispositivos típicamente tienen capacidades de procesamiento y potencia mejoradas en comparación con dispositivos en el nivel 34 inferior, lo que los hace muy adecuados para la mayoría de las tareas de procesamiento. Los dispositivos del nivel 36 intermedio pueden realizar análisis de propósito más general, a diferencia de los análisis de propósito especial realizados en el nivel 34 inferior, y/o realizar análisis más complejo en comparación con el 10 nivel 34 inferior. Los dispositivos en el nivel 36 intermedio ocasionalmente pueden llegar a sentirse abrumados en presencia de muchas solicitudes de procesamiento de datos, o pueden encontrar una tarea de procesamiento que está más allá de sus capacidades. En este caso, las tareas de procesamiento pueden hacer subir la jerarquía al nivel 38 superior. En el nivel 15 38 superior, los dispositivos de procesamiento en la nube y de terceros realizan tareas complejas en nombre del sistema. Los dispositivos en diferentes niveles de la jerarquía 32 y, diferentes dispositivos en el mismo nivel de la jerarquía 32, pueden incluir una lógica diferente para procesar los mismos datos. Por ejemplo, un detector de humo en el nivel 34 inferior y una entidad de pasarela en 20 el nivel 36 intermedio ambos pueden tener una lógica para analizar los datos del detector de humo para determinar si hay un incendio en la zona monitorizada. No obstante, la lógica de la entidad de pasarela puede ser más sofisticada que la lógica del detector de humo. De esta manera, el detector de humo y la entidad de pasarela podrían procesar los mismos datos y llegar a conclusiones diferentes. Esta capacidad se puede aprovechar 25 ventajosamente para proporcionar un análisis dirigido y sofisticado de los datos. Si un dispositivo en un nivel inferior de la jerarquía procesa datos y determina que casi, pero no del todo, indica la presencia de una condición de alarma, por ejemplo, los resultados del procesamiento no exceden un umbral de alarma, pero se aproximan al umbral dentro una tolerancia predefinida, entonces el dispositivo de nivel inferior puede reenviar los datos a 30 otro dispositivo en la arquitectura que tiene una capacidad de procesamiento más sofisticada o diferente. Además, diferentes dispositivos en el mismo nivel de la jerarquía 32 pueden tener una lógica diferente para procesar datos. Por consiguiente, se puede hacer que diferentes dispositivos 10 empleen una lógica de procesamiento dependiente de la ubicación o sensible al contexto. Por ejemplo, un detector de humo desplegado en una cocina se puede dotar con una lógica para eliminar falsas alarmas debido a la cocción, mientras que un detector de humo desplegado en un vestíbulo delantero puede omitir esta lógica. La lógica desplegada en un dispositivo puede ser dependiente de la configuración hardware 5 del dispositivo. Por ejemplo, un sensor que tiene hardware nuevo o mejorado puede desplegar una lógica de procesamiento más compleja o especializada en comparación con un sensor más antiguo o más simple. Además de proporcionar procesamiento sensible a la ubicación o al contexto, esta capacidad permite que un dispositivo en un nivel de la jerarquía 32 reenvíe datos a otro dispositivo más especializado, posiblemente a través de una entidad 10 de pasarela, cuando se presenta con datos que pueden ser manejados mejor por el dispositivo especializado. Además de un procesamiento mejorado, otra ventaja de la jerarquía 32 es que se pueden desarrollar ajustes de configuración mejorados en los niveles superiores de la jerarquía 32, por ejemplo, el nivel 36 intermedio y el nivel 38 superior, y empujar hacia abajo a niveles 15 inferiores de la jerarquía 32. Por ejemplo, si un sensor en el nivel 34 inferior determina que los datos de entrada casi, pero no del todo, se elevan al nivel de una condición de alarma, el sensor puede reenviar los datos de entrada a un dispositivo en el nivel 36 intermedio para procesamiento adicional. Si el dispositivo en el nivel 36 intermedio determina que los datos deberían haber desencadenado una condición de alarma, el dispositivo en el nivel 36 20 intermedio puede revisar la configuración del dispositivo en el nivel 34 inferior para determinar si se deberían cambiar uno o más ajustes de configuración de modo que el dispositivo de nivel inferior pueda analizar mejor los datos de entrada en el futuro. Por ejemplo, el dispositivo en el nivel intermedio podría disminuir el umbral de alarma del dispositivo de nivel inferior, o podría alterar el algoritmo empleado por el dispositivo de nivel 25 inferior en base al algoritmo usado por el dispositivo de nivel intermedio u otro dispositivo en la arquitectura 10. Las estructuras de dispositivos ejemplares en la jerarquía, en particular un sensor 14 ejemplar y una entidad 20 de pasarela ejemplar, se describen ahora con referencia a las FIG. 3 y 4. 30 El sensor 14 representado en la FIG. 3 incluye un detector 40. Los detectores incluyen dispositivos que miden o identifican un fenómeno y proporcionan una salida en respuesta a la presencia del fenómeno, a la ausencia del fenómeno, o a un cambio en el fenómeno. Ejemplos de detectores incluyen sensores de luz o imagen, micrófonos, 11 termómetros/termopares, barómetros, etc. La salida del detector 40 se procesa por un procesador 42. Los procesadores 42 incluyen dispositivos que ejecutan instrucciones y/o realizan operaciones matemáticas, lógicas, de control, o de entrada/salida. El procesador 42 del sensor 14 puede ser un procesador especializado que tiene capacidades de procesamiento limitadas y está diseñado para 5 funcionar en entornos de baja potencia. Por ejemplo, el procesador 42 del sensor 14 puede implementar la arquitectura de Computación de Conjunto de Instrucciones Reducido (RISC) o de Acorn RISC Machine (ARM). Ejemplos de procesadores 42 incluyen la familia de procesadores AtomTM de Intel Corporation de Santa Clara, California, la familia de procesadores A4 de Apple, Inc. de Cupertino, California, la familia de procesadores 10 SnapdragonTM de Qualcomm Technologies, Inc. de San Diego, California, y la familia de procesadores Cortex® de ARM Holdings, PLC de Cambridge, Inglaterra. El procesador 42 puede ser también un procesador personalizado. El sensor 14 incluye una interfaz 44 de potencia para suministrar energía eléctrica a los componentes del sensor 14. La interfaz 44 de potencia puede ser una conexión a una fuente 15 de energía externa, tal como una conexión cableada a la fuente de alimentación de una casa o empresa. Alternativa o adicionalmente, la interfaz 44 de potencia puede incluir una interfaz a una batería recargable o no recargable, o un condensador. El sensor 14 ejemplar se acopla en comunicación inalámbrica y cableada. Por consiguiente, el sensor 14 incluye una interfaz 46 de comunicación para gestionar la comunicación entre 20 el sensor 14 y otras entidades en la arquitectura 10. La interfaz 46 de comunicación acepta transmisiones entrantes de información desde las otras entidades de la arquitectura 10, gestiona la transmisión de información desde el sensor 14 a las otras entidades, y proporciona control de calidad para las transmisiones de datos, entre otras funcionalidades relacionadas con la comunicación. El sensor 14 puede conectarse a la red 22 a través de la 25 interfaz 46 de comunicación. La interfaz 46 de comunicación comunica de manera inalámbrica con las otras entidades de la arquitectura 10 usando un transmisor/receptor 48 de radio. El transmisor/receptor 48 de radio modula y demodula señales electromagnéticas transportadas inalámbricamente a través de un medio, tal como el aire o el agua, o a través de ningún medio tal como en el 30 espacio. En las realizaciones ejemplares, el transmisor/receptor 48 de radio del sensor 14 puede ser un transmisor/receptor de radio especializado que comunica sobre un alcance relativamente corto usando una potencia relativamente baja. Ejemplos de transmisores/receptores 48 de radio de potencia inferior incluyen dispositivos que se 12 comunican a través de ondas de radio de frecuencia ultra alta (UHF) de longitud de onda corta. Los transmisores receptores 48 de radio de baja potencia ejemplares pueden implementar un protocolo de comunicación tal como un protocolo ZigBee de ZigBee Alliance, el protocolo Bluetooth® de Baja Energía (BLE) del Grupo de Interés Especial de Bluetooth, el protocolo Z-Wave de la Z-Wave Alliance, el protocolo IPv6 sobre Redes de 5 Área Personal Inalámbricas de Baja Potencia (6LoWPAN) desarrollado por el Grupo de Trabajo de Ingeniería de Internet (IETF), o un protocolo de comunicaciones de campo cercano (NFC). Alternativa o adicionalmente, el sensor 14 podría acoplarse en comunicación inalámbrica usando otras tecnologías de transmisión/recepción, tales como inducción óptica, sónica o 10 electromagnética en espacio libre. La interfaz 46 de comunicación ejemplar también se conecta a una interfaz 50 de red para interconectar con una red de comunicaciones cableada. La interfaz 50 de red puede ser, por ejemplo, un controlador de interfaz de red (NIC) para establecer una conexión cableada a una red informática tal como Internet, una interfaz de fibra óptica para conectar a una red de 15 fibra óptica, una interfaz de cable para conectar a una red de televisión por cable, una clavija telefónica para conectar a una red telefónica, o una interfaz de línea eléctrica para conectar a una red de comunicaciones de línea eléctrica. Opcionalmente, el sensor 14 puede incluir un dispositivo 18 de salida. Por ejemplo, un detector de humo puede incluir un sensor para detectar la presencia de humo, y uno o más 20 dispositivos de salida, por ejemplo, una sirena y una luz estroboscópica, que se disparan en base a la salida del sensor. El sensor 14 incluye una memoria 52 para contener datos, instrucciones, y otra información para uso por los otros componentes del sensor. En las realizaciones ejemplares, la memoria 52 del sensor 14 puede ser una memoria especializada que incluye almacenamiento 25 relativamente limitado y/o usa una potencia relativamente baja. La memoria 52 puede ser un medio de almacenamiento de estado sólido tal como una memoria rápida y/o memoria de acceso aleatorio (RAM). Ejemplos de la memoria 52 incluyen una memoria Secure DigitalTM(SD) de la Asociación SD. La memoria 52 también puede ser una memoria personalizada. La memoria 52 incluye un almacenador temporal 54 de datos para almacenar 30 temporalmente datos del detector 40 hasta que los datos se puedan procesar por el procesador 42 o transmitir usando la interfaz 46 de comunicación. El almacenador temporal 54 de datos puede ser, por ejemplo, un almacenador temporal circular. Los datos en el 13 almacenador temporal 54 de datos se pueden procesar de una forma primero en entrar primero en salir (FIFO), de una forma último en entrar primero en salir (LIFO), en base a la importancia de las unidades de datos individuales en el almacenador temporal, o en base a una orden de procesamiento personalizada. El almacenador temporal 54 de datos se puede situar en una ubicación fija en la memoria 52. 5 Además del almacenador temporal 54 de datos, la memoria 52 incluye un almacenador temporal 56 de red para almacenar información transmitida o recibida a través de la interfaz 46 de comunicación. El procesador 42 ensambla los datos para su transmisión por la interfaz 46 de comunicación, y almacena las unidades de datos en el almacenador temporal 56 de red. La interfaz 46 de comunicación recupera regularmente datos pendientes del 10 almacenador temporal 56 de red y los transmite hacia su destino. Al recibir los datos desde otro dispositivo de la arquitectura 10, la interfaz 46 de comunicación coloca los datos en el almacenador temporal 56 de red. El procesador 42 recupera regularmente los datos pendientes del almacenador temporal de red y procesa los datos según las instrucciones almacenadas en la memoria 52, o codificadas en el procesador 42. Con el fin de distinguir 15 entre los datos recibidos y los datos a ser transmitidos, el almacenador temporal 56 de red se puede subdividir en un almacenador temporal “dentro” y en un almacenador temporal “fuera”. El almacenador temporal 56 de red se puede situar en una ubicación fija en la memoria 52. La memoria 52 almacena además una configuración 58 que incluye reglas 60, filtros 62, 20 lógica 64 de procesamiento, y parámetros de configuración 66. Una configuración 58 es una descripción de hardware y/o software presente en un dispositivo. Las reglas 60 describen una o más acciones que ocurren en respuesta a una o más condiciones. Los filtros 62 son lógica que se ejecuta en datos de entrada y/o procesa con el fin de determinar una siguiente acción a tomar con los datos, tal como procesar los datos localmente, guardar los datos en 25 un registro, o reenviar los datos a otro dispositivo para procesamiento. La lógica 64 de procesamiento proporciona instrucciones y/o parámetros que operan sobre datos de entrada, o, en algunos ejemplos, sin datos de entrada, para generar nuevos datos de salida, transformar los datos de entrada en nuevos datos, o tomar una acción con respecto a los datos de entrada o algunos otros datos. La lógica 64 de procesamiento se puede aplicar a 30 los datos generados por el detector 40 con el fin de tomar una acción, tal como levantar una alarma, cambiar un estado de seguridad o de monitorización de la arquitectura 10, operar un dispositivo de salida, etc. La entidad 20 de pasarela se puede desplegar con diferentes tipos de lógica 64 de procesamiento, estando los diferentes tipos especializados respectivamente en diferentes tipos de datos del sensor. Los parámetros 66 de configuración incluyen valores 35 14 para ajustes que describen cómo opera el hardware y/o software del dispositivo configurado. La configuración 58, las reglas 60, los filtros 62, la lógica 64 de procesamiento y los parámetros 66 de configuración se describen con más detalle en relación con las FIG. 7-10B, a continuación. Al menos un enlace de comunicación que usa el sensor 14 para comunicar, por ejemplo, el 5 enlace con la entidad 20 de pasarela, es un camino 24 crítico de temporización. Como se señaló anteriormente, el camino 24 crítico de temporización transporta datos sensibles al tiempo entre, por ejemplo, el sensor 14 y la entidad 20 de pasarela. Por consiguiente, el camino 24 crítico de temporización puede requerir una transmisión de datos en tiempo real o casi en tiempo real. El procesador 42, la interfaz 46 de comunicación, y la memoria 52 del 10 sensor se pueden configurar para priorizar los datos sensibles al tiempo de manera que los datos se procesen, transmitan, y actúen rápidamente. Por ejemplo, los datos sensibles al tiempo del detector 40 se pueden marcar con una cabecera especial por el procesador 42. Los datos sensibles al tiempo se pueden analizar, usando la lógica 64 de procesamiento, de una manera acelerada, por ejemplo, los datos sensibles al tiempo se pueden priorizar sobre 15 otros datos no sensibles al tiempo. Si los datos sensibles al tiempo van a ser procesados en otro dispositivo en la jerarquía 32, los datos sensibles al tiempo se pueden colocar en un área segregada de alta prioridad del almacenador temporal 56 de red o enviar directamente a la interfaz 46 de comunicación para su transmisión. La interfaz 46 de comunicación puede anexar una cabecera especial a los datos sensibles al tiempo, marcando los datos como de 20 alta prioridad. Al recibir datos con una cabecera de alta prioridad, la interfaz 46 de comunicación puede colocar los datos en el área de alta prioridad del almacenador temporal 56 de red y/o anunciar la llegada de los datos al procesador 42. La interfaz 46 de comunicación establece uno o más canales de comunicación de alta prioridad entre el sensor 14 y la entidad 20 de pasarela. Los canales de comunicación de 25 alta prioridad pueden ser canales de banda ancha para asegurar que existe suficiente ancho de banda para transmitir los datos en tiempo real o casi en tiempo real. Los canales de comunicación de alta prioridad pueden ser redundantes, de manera que los canales de respaldo estén disponibles si uno de los canales de comunicación cesa de funcionar. La redundancia se puede establecer usando múltiples tipos de medios de transmisión, por 30 ejemplo, medios cableados e inalámbricos, diferentes tipos de medios cableados, etc., usando diferentes rutas entre el sensor 14 y la entidad 20 de pasarela ,por ejemplo, una ruta de comunicación directa a la entidad 20 de pasarela y en una ruta indirecta desde el sensor 14 a través de otro dispositivo, tal como otro sensor 16, a la entidad 20 de pasarela, estableciendo dispositivos de procesamiento alternativos ,por ejemplo, estableciendo un 35 15 canal de comunicación al dispositivo 28 de procesamiento en la nube, en el caso de que la entidad de pasarela sea inalcanzable o incapaz de procesar datos del sensor, y otras posibilidades. Se pueden usar procedimientos similares para datos sensibles al tiempo en la entidad 20 de pasarela. 5 El sensor 14 representado en la FIG. 3 se comunica ante todo con la entidad 20 de pasarela, que puede ser similar al sensor 14 en términos de los tipos de componentes usados. No obstante, debido a que hay menos restricciones en la entidad 20 de pasarela en términos de tamaño, ubicación, y consumo de energía, la entidad 20 de pasarela puede tener más componentes y/o componentes más potentes que el sensor 14. Típicamente, la 10 entidad 20 de pasarela es un panel o un dispositivo informático situado en o cerca de la zona 12 monitorizada. La FIG. 4 es un diagrama de bloques que representa la estructura de una entidad 20 de pasarela ejemplar. La entidad 20 de pasarela incluye un procesador 42. El procesador 42 de la entidad 20 de pasarela puede ser similar al procesador 42 del sensor 14; alternativa o adicionalmente, el 15 procesador 42 de la entidad 20 de pasarela puede ser una Unidad Central de Proceso (CPU) que tiene uno o más núcleos de procesamiento, uno o más coprocesadores, y/o memoria caché en el chip. En algunas realizaciones, el procesador 42 de la entidad 20 de pasarela puede ser un procesador especializado que tiene capacidades de procesamiento mejoradas en 20 comparación con el procesador 42 del sensor 14 y, como resultado, puede presentar un aumento del consumo de energía y/o generación de calor en comparación con el procesador 42 del sensor 14. Por ejemplo, el procesador 42 de la entidad 20 de pasarela puede implementar la arquitectura de Computación de Conjunto de Instrucciones Complejo (CISC). Ejemplos de procesadores 42 incluyen las familias de procesadores Celeron®, Pentium®, y 25 CoreTM de Intel Corporation de Santa Clara, California, y los procesadores de Unidad de Procesamiento Acelerado (APU) y de Unidad Central de Proceso (CPU) de Advanced Micro Devices (AMD), Inc. de Sunnyvale, California. La entidad 20 de pasarela incluye además una interfaz 44 de potencia. La interfaz 44 de potencia puede conectarse directamente al sistema de distribución de energía o a la red 30 eléctrica en la ubicación en la que se despliegue la entidad 20 de pasarela. La interfaz 44 de potencia puede incluir una interfaz para aceptar corriente alterna (CA), corriente continua (DC), o ambas. La interfaz 44 de potencia puede incluir un convertidor para convertir AC en 16 DC, o viceversa. La interfaz 44 de potencia puede incluir una batería de respaldo para hacer funcionar la entidad 20 de pasarela durante cortes de energía. La entidad 20 de pasarela incluye una interfaz 46 de comunicación, una radio 48, y una interfaz 50 de red similares a los componentes respectivos del sensor 14. Se puede esperar que la entidad 20 de pasarela comunique con más dispositivos que el sensor 14 y, en 5 consecuencia, se puede dotar con más o más complejas interfaces 46 de comunicación, radios 48, e interfaces 50 de red que el sensor 14. La entidad 20 de pasarela se puede asignar a una zona 12 monitorizada particular y, en consecuencia, puede mantener comunicación con los dispositivos en la zona 12 monitorizada a través de la interfaz 46 de comunicación. La entidad 20 de pasarela también puede conectarse a la red 22 a través de 10 la interfaz 46 de comunicación. La entidad 20 de pasarela incluye una memoria 52. La memoria 52 de la entidad 20 de pasarela puede ser similar a la memoria 52 del sensor 14, pero presenta típicamente un mayor espacio de almacenamiento y/o un rendimiento mejorado ,tal como tiempos de lectura/escritura mejorados, tiempos de búsqueda mejorados, y/o redundancia de datos 15 mejorada o capacidades de copia de seguridad de información. Ejemplos de una memoria 52 adecuada para su uso en la entidad 20 de pasarela incluyen una memoria de acceso aleatorio (RAM), una unidad de disco duro (HDD), o una unidad de estado sólido (SSD), entre otras posibilidades, o una combinación de los mismos tipos o diferentes de dispositivos de almacenamiento de información. 20 La memoria 52 proporciona un almacenador temporal 56 de red similar al almacenador temporal 56 de red del sensor 14. La memoria 52 también incluye un área de almacenamiento para datos 70 del sensor, que incluyen datos del sensor procedentes de los sensores en la zona 12 monitorizada supervisada por la entidad 20 de pasarela ,por ejemplo, datos 72 del primer sensor, datos del segundo sensor, etc.. Los datos 70 del 25 sensor se pueden almacenar en una partición separada de la memoria 52 en comparación con otros elementos almacenados en la memoria 52. La memoria 52 de la entidad 20 de pasarela almacena también una configuración 58, reglas 60, filtros 62, lógica 64 de procesamiento, y parámetros 74 de configuración de entidad de pasarela. Estos elementos pueden ser similares en estructura a los elementos respectivos 30 del sensor 14, aunque pueden diferir en contenido ,por ejemplo, diferentes condiciones y acciones en las reglas 60, diferentes formas de filtrar los datos en los filtros 62, diferentes instrucciones en la lógica 64 de procesamiento, diferentes valores en los parámetros 74 de configuración, etc.. 17 La entidad 20 de pasarela incluye además un balanceador 68, que realiza un proceso de balanceo doble para asignar recursos, por ejemplo, recursos de procesamiento, recursos de memoria, etc., en la arquitectura 10. El balanceador 68 recibe notificaciones de eventos cuando un sensor determina que está teniendo lugar o está a punto de tener lugar un evento. En respuesta, el balanceador 68 asigna recursos a la pasarela. Por ejemplo, el 5 balanceador 68 puede asignar espacio en la memoria 52 para datos 72 del sensor 14 y/o puede generar nuevos hilos o asignar de otro modo recursos de procesamiento dentro del procesador 42. El proceso de balanceo doble se describe con más detalle en las Figuras 5 y 11-14B. Como se señaló anteriormente, la entidad 20 de pasarela reenvía algunos datos a un 10 dispositivo 28 de procesamiento en la nube para procesamiento adicional. El dispositivo 28 de procesamiento en la nube tiene una estructura similar a la de la entidad 20 de pasarela. Con el fin de evitar redundancia, la estructura del dispositivo 28 de procesamiento en la nube no se muestra por separado. El dispositivo 28 de procesamiento en la nube se puede desplegar de una manera que permita componentes mejorados cualitativa y 15 cuantitativamente, en comparación con la entidad 20 de pasarela. Por ejemplo, la memoria del dispositivo 28 de procesamiento en la nube puede incluir varias unidades de disco duro (HDD) o unidades de estado sólido (SDD), entre otras posibilidades de almacenamiento. La memoria del dispositivo 28 de procesamiento en la nube puede estar dispuesta en una formación redundante de configuración de discos independientes (RAID) para fiabilidad y 20 rendimiento mejorados. Además, el procesador el dispositivo 28 de procesamiento en la nube puede ser cualitativa o cuantitativamente más potente que el procesador 42 de la entidad 20 de pasarela. Por ejemplo, se pueden proporcionar múltiples procesadores 42 en el dispositivo 28 de procesamiento en la nube, que pueden incluir más núcleos de procesamiento que el 25 procesador 42 de la entidad 20 de pasarela. Además, el(los) procesador(es) 42 del dispositivo 28 de procesamiento en la nube puede(n) ser de un tipo diferente y más potente que el procesador 42 de la entidad 20 de pasarela. Por ejemplo, el dispositivo 28 de procesamiento en la nube puede emplear una unidad central de proceso (CPU) más potente que la entidad 20 de pasarela, o puede emplear más o mejores coprocesadores que la CPU 30 de la entidad 20 de pasarela, o puede emplear una unidad gráfica de procesamiento (GPU) que sea más potente que la CPU de la entidad 20 de pasarela. Como se muestra en la FIG. 5, el sensor 14, la entidad 20 de pasarela, el dispositivo 28 de procesamiento en la nube, y el servicio 30 de terceros pueden interactuar entre sí, y con 18 otros elementos de la arquitectura 10, con el fin de procesar datos del sensor. La FIG. 5 es un diagrama de contexto del sistema que muestra cómo, en una realización ejemplar, interactúan entre sí las entidades de la arquitectura 10 de sistema según un proceso 76 de balanceo doble. El proceso 76 de balanceo doble abarca los pasos o las acciones realizadas por la arquitectura 10 con el fin de balancear los datos del sensor de procesamiento y 5 gestionar las entidades de la arquitectura 10. El proceso 76 de balanceo doble incluye las acciones descritas con más detalle en los diagramas de flujo de las FIG. 11-14B. El sensor 14 genera datos de entrada para el proceso 76 de balanceo doble usando el detector 40. Los datos de entrada se almacenan en el almacenador temporal 54 de datos del sensor hasta que se puedan procesar por el procesador 42. El procesador 42 recupera 10 los datos del almacenador temporal 54 de datos y hace una determinación inicial, basada en un filtro 62, o bien para procesar los datos localmente o bien para reenviar los datos a otro dispositivo en la arquitectura 10 para su procesamiento. Si los datos se procesan localmente y el sensor determina que está ocurriendo o se prevé que ocurra un evento ,por ejemplo, se indica o se considera que es probable una condición 15 de alarma, el sensor 14 genera, como salida del proceso 76 de balanceo doble, una notificación de evento. Una notificación de evento señala la aparición o predicción del evento para la entidad 20 de pasarela, de modo que el balanceador 68 de la entidad 20 de pasarela puede comenzar a asignar recursos y responder al evento. Un mensaje de notificación de evento puede indicar que el evento está ocurriendo o es probable que ocurra, o la 20 notificación de evento puede indicar que ha finalizado un evento previamente marcado. En algunas realizaciones, la notificación de eventos incluye características del sensor 14, tales como datos iniciales del sensor 14, información acerca de la configuración del sensor 14 ,por ejemplo, detalles acerca de los microprogramas, software, hardware, etc., una identificación de modelo de sensor 14, el tipo de sensor 14, por ejemplo, detector de humo, 25 sensor de rotura de cristal, etc., o información de mantenimiento, por ejemplo, mediciones de la resistencia a través de diversos puntos en la circuitería del sensor 14, mediciones del nivel de batería o conectividad de red del sensor 14, consumo de energía del sensor 14, etc.. Si el procesador 42 determina que los datos no pueden o no deberían ser procesados 30 localmente, entonces el sensor 14 genera, como salida al proceso 76 de balanceo doble, un mensaje que incluye los datos no procesados para procesamiento por otro dispositivo en la arquitectura 10. Los datos no procesados incluyen datos, por ejemplo, datos generados por el sensor 14, que se designan por el proceso 76 de balanceo doble para procesar por un 19 dispositivo diferente del dispositivo en el que residen actualmente los datos no procesados. Los datos no procesados pueden incluir datos que se procesan parcialmente por el dispositivo en el que residen actualmente los datos no procesados. Por ejemplo, el sensor 14 puede realizar un procesamiento parcial de los datos, y reenviar algunos de o todos los datos en bruto, junto con los resultados del procesamiento, al proceso 76 de balanceo doble 5 como datos no procesados. En otras realizaciones, los datos no procesados se pueden procesar completamente por el sensor 14, pero sin embargo se pueden reenviar a otro dispositivo para más consideración. En algunas realizaciones, el sensor 14 registra datos con el detector 40 que se usa para el reconocimiento de sonido y de voz. Por ejemplo, el detector 40 puede recibir datos de habla 10 como entrada y o bien procesar localmente los datos de habla con el procesador 42, o bien reenviar los datos de habla al proceso 76 de balanceo doble como datos no procesados. Los datos de habla se pueden usar para reconocimiento y/o autenticación de habla en la arquitectura 10. Por ejemplo, los datos de habla se pueden usar para autenticar un usuario cuando el usuario entra en la zona 12 monitorizada. Si el usuario deja de autenticarse, el 15 sensor 14 puede enviar una notificación de evento para desencadenar una condición de alarma que indique la presencia de un usuario no autorizado en la zona 12 monitorizada. El sensor 14 recibe, como salida del proceso 76 de balanceo doble, desencadenadores y solicitudes de acceso remoto. Un desencadenador es una instrucción de otro dispositivo, tal como la entidad 20 de pasarela, para cambiar el estado del sensor o tomar una acción, por 20 ejemplo, hacer sonar una alarma, encender una luz estroboscópica, o reproducir una grabación de audio, en respuesta a la detección de un evento desde el otro dispositivo. Por ejemplo, un desencadenador puede informar al sensor 14 de que la arquitectura 10 está en una configuración de alarma, y las reglas internas del sensor 14 pueden proporcionar un tipo particular de notificación en respuesta, por ejemplo, disparar un dispositivo 18 de salida 25 integrado del sensor 14. Alternativa o adicionalmente, el mensaje desencadenador puede dar instrucciones al sensor 14 para realizar una tarea tal como hacer sonar una alarma o cambiar un ajuste de temperatura en la zona 12 monitorizada. Una solicitud de acceso remoto es una solicitud de un dispositivo de la arquitectura 10 que dirige al sensor 14 a dar el control sobre algunos de o todos los componentes del sensor 14 30 a una entidad externa. Por ejemplo, una solicitud de acceso remoto podría ordenar al sensor 14 proporcionar audio de datos visuales desde el almacenador temporal 54 de datos y/o el detector 40 del sensor. La solicitud de acceso remoto también podría ordenar al sensor 14 ceder el control de un dispositivo de salida, tal como un altavoz, de modo que una entidad 20 remota pueda comunicarse a través del dispositivo de salida y/o un detector tal como un micrófono. La solicitud de acceso remoto también podría solicitar que el sensor 14 se reposicione a sí mismo como en el caso de una videocámara operada remotamente que toma una vista panorámica, se inclina, o rota en respuesta a órdenes de la entidad externa, entre otras posibilidades. 5 El servicio 30 de terceros monitoriza el estado de los dispositivos y zonas de la arquitectura 10 para condiciones que requieren una acción adicional tales como despachar servicios de emergencia o contactar con un usuario. Por consiguiente, el servicio 30 de terceros se dota con, como una salida del proceso 76 de balanceo doble, actualizaciones de estado indicativas de cualquier cambio en el estado de seguridad o monitorización de la 10 arquitectura 10. Además, el servicio 30 de terceros puede recibir datos procesados o no procesados como una salida del proceso 76 de balanceo doble, que puede permitir al servicio 30 de terceros monitorizar el estado de los sensores en la zona 12 monitorizada. Por ejemplo, el servicio 30 de terceros puede recibir datos en bruto de un sensor tal como un detector de humo, y/o datos procesados que resumen los eventos que condujeron a una 15 condición de alarma, entre otras posibilidades. Sobre la base de las actualizaciones de estado y de los datos procesados o no procesados, el servicio 30 de terceros puede contactar, o puede facilitar el contacto con, los primeros respondedores tales como servicios médicos, parques de bomberos o comisarías de policía, una compañía de seguridad privada, etc. Por consiguiente, el servicio 30 de terceros puede 20 proporcionar, como entrada al proceso 76 de balanceo doble, información del primer respondedor. La información del primer respondedor puede incluir información tal como partes seleccionadas de los datos procesados o no procesados, que ayuda a los primeros respondedores a manejar un evento. Por ejemplo, la información del primer respondedor podría incluir coordenadas del Sistema de Posicionamiento Global (GPS) que indican la 25 ubicación de un sensor 14 que está presentando actualmente una condición de alarma. La información del primer respondedor puede originarse en el sensor 14, en la entidad 20 de pasarela, o en el dispositivo 28 de procesamiento en la nube, o se puede almacenar en el servicio 30 de terceros. El dispositivo 28 de procesamiento en la nube proporciona capacidades de procesamiento 30 adicionales para la arquitectura 10. Por ejemplo, el dispositivo de procesamiento en la nube puede realizar un procesamiento más avanzado usando algoritmos más complejos que la entidad 20 de pasarela, puede soportar la entidad 20 de pasarela calculando previamente información que simplifica los cálculos realizados por la entidad 20 de pasarela, por ejemplo, 21 generando un diccionario de interacción que proporciona un número limitado de opciones que la entidad 20 de pasarela puede seleccionar cuando se acopla en interacciones de voz automatizadas con un usuario, puede realizar analíticas de datos avanzadas sobre la base de los datos de uno o más sensores, y/o puede registrar datos para referencia futura o para cumplir con regulaciones aplicables. 5 Con el fin de usar estas capacidades de procesamiento adicionales, el proceso 76 de balanceo doble envía, como salida, datos no procesados, y/o datos procesados, a ser procesados en el dispositivo 28 de procesamiento en la nube. Los datos no procesados y/o procesados pueden originarse a partir de un único sensor 14, o se pueden considerar holísticamente datos de múltiples sensores. 10 El dispositivo 28 de procesamiento en la nube procesa los datos recibidos y hace una determinación, por ejemplo, cambiar el estado de seguridad o de monitorización de la arquitectura 10, en base a los datos. Por consiguiente, el dispositivo 28 de procesamiento en la nube puede transmitir, como entrada al proceso 76 de balanceo doble, una actualización de estado que describe cómo cambiar el estado de la arquitectura 10 y/o un disparo para un 15 sensor 14 o dispositivo 18 de salida. El dispositivo 28 de procesamiento en la nube también puede transmitir mensajes de actualización de estado “nulo”, indicando que el estado de seguridad o de monitorización de la arquitectura 10 no necesita ser cambiado en respuesta a los datos. Además, el dispositivo 28 de procesamiento en la nube inicia llamadas a las estaciones de 20 monitorización y a los primeros respondedores. Por ejemplo, el dispositivo 28 de procesamiento en la nube puede enviar una señal al servicio 30 de terceros indicando la presencia de un evento tal como un incendio o allanamiento, y puede dirigir el servicio de terceros para llamar al 911. Alternativamente, el dispositivo 28 de procesamiento en la nube puede iniciar una llamada al 911 y luego manejar la llamada sobre el servicio 30 de terceros. 25 Como se señaló anteriormente, una ventaja de la arquitectura 10 es que se pueden desplegar en la pasarela 20, actualizaciones de la lógica de procesamiento usada para analizar los datos del sensor, sin necesidad de empujar las nuevas actualizaciones todo el camino hasta los sensores. En algunas realizaciones, el dispositivo 28 de procesamiento en la nube determina cómo se debería actualizar la configuración de la entidad 20 de pasarela. 30 Por ejemplo, si la entidad 20 de pasarela procesa datos y decide no desencadenar una alarma, pero el dispositivo 28 de procesamiento de la nube determina que se debería haber desencadenado una alarma, el dispositivo 28 de procesamiento en la nube puede enviar automáticamente una actualización de configuración a la entidad 20 de pasarela para 22 disminuir los umbrales de detección de la entidad de pasarela. Alternativamente, si el dispositivo 28 de procesamiento en la nube determina que una alarma no se debería haber desencadenado por la entidad 20 de pasarela, pero se desencadenó, el dispositivo 28 de procesamiento en la nube puede enviar automáticamente una actualización de configuración a la entidad 20 de pasarela para elevar el umbral de la entidad de pasarela. En otro ejemplo, 5 el dispositivo 28 de procesamiento en la nube puede determinar que la configuración de una entidad de pasarela está desfasada y que existe una configuración más actualizada en otro dispositivo cercano. El dispositivo 28 de procesamiento en la nube puede enviar una actualización de configuración a la entidad de pasarela desactualizada en base a la configuración del dispositivo actualizado. 10 Por consiguiente, el dispositivo 28 de procesamiento en la nube transmite, como entrada al proceso 76 de balanceo doble, una actualización de configuración a ser aplicada en la entidad 20 de pasarela. Las actualizaciones de configuración incluyen mensajes que describen un cambio en la configuración 58 de la entidad 20 de pasarela. Por ejemplo, las actualizaciones de configuración pueden actualizar las reglas 60, los filtros 62, la lógica 64 15 de procesamiento, y/o los parámetros 74 de configuración de la entidad 20 de pasarela afectada. La entidad 20 de pasarela funciona como un concentrador o facilitador central entre los dispositivos sensores/de salida y los dispositivos externos accesibles a través de la red 22. Entre otras funciones, la entidad 20 de pasarela: asigna recursos a sensores o grupos de 20 sensores particulares en respuesta a notificaciones de eventos; procesa datos de los sensores en la arquitectura 10; reenvía datos no procesados a otros dispositivos que sean más adecuados para procesar los datos; transmite actualizaciones de estado al servicio 30 de terceros; dispara dispositivos de salida; envía solicitudes de acceso remoto a sensores; proporciona acceso a datos grabados de video/audio al servicio 30 de terceros; y aplica 25 actualizaciones de configuración a partir del proceso 76 de balanceo doble. En algunas realizaciones, la entidad 20 de pasarela también genera avisos vocales y realimentación de audio usando procesamiento de texto a habla y de lenguaje natural basado en el diccionario de interacción del dispositivo 28 de procesamiento en la nube. La entidad 20 de pasarela puede exponer una o más Interfaces de Programa de Aplicaciones (API) a los otros 30 dispositivos de la arquitectura 10 con estos propósitos. El proceso 76 de balanceo doble acepta las entradas de los diversos dispositivos como se muestra en la FIG. 5, y procesa las entradas para generar salidas. Como parte del proceso 76 de balanceo doble, se pueden emplear una serie de estructuras de datos diferentes. Se 23 describen a continuación estructuras de datos ejemplares adecuadas para su uso con las realizaciones con referencia a las FIG. 6-10B. La FIG. 6 muestra una actualización 78 de configuración ejemplar que se usa para actualizar la configuración 58 de una entidad 20 de pasarela. La actualización 78 de configuración incluye una cabecera 80 que identifica, entre otras 5 cosas, el destino de la actualización 78 de configuración. En algunas realizaciones, la cabecera 80 identifica dispositivos específicos en los que se debería desplegar la actualización 78 de configuración. Alternativa o adicionalmente, la cabecera 80 puede identificar un grupo o clase de dispositivos en los que se debería desplegar la actualización 78 de configuración, por ejemplo, entidades de pasarela que supervisan al menos un 10 detector de humo. En algunas realizaciones, la cabecera 80 también incluye otra información, tal como una marca de tiempo, una prioridad, y una suma de comprobación. La marca de tiempo identifica el momento en que se envió la actualización 78 de configuración, que se puede usar para ordenar actualizaciones de configuración que llegan en sucesión. En algunos casos, pueden 15 entrar en conflicto entre sí dos actualizaciones de configuración, requiriendo de esta manara que una actualización de configuración anule a la otra. La marca de tiempo se puede usar para determinar qué actualización de configuración se envió primero, bajo la suposición de que esta última actualización de configuración estaba destinada a anular la anterior. Si se transmitió una primera actualización de configuración antes de una segunda actualización 20 de configuración, entonces en algunas realizaciones se aplica esta última, segunda, actualización de configuración y se anula la primera actualización de configuración, con independencia del orden en que se reciban las actualizaciones de configuración en el dispositivo a ser configurado. En algunas realizaciones, se usa un valor de prioridad para determinar qué actualización de 25 configuración debe anular otras actualizaciones de configuración. Por ejemplo, si se recibe una primera actualización de configuración que tiene una prioridad alta y se aplica en un dispositivo configurado, el dispositivo configurado puede decidir no aplicar una actualización de configuración conflictiva posterior que tenga una prioridad inferior. Se usa una suma de comprobación en la cabecera 80 para verificar que la actualización 78 30 de configuración se recibió correctamente y no fue ilegible en la transmisión. La suma de comprobación se aplica en el dispositivo de transmisión calculando un valor de suma de comprobación sobre la carga útil de la actualización 78 de configuración, usando cualquiera 24 de una serie de algoritmos de suma de comprobación bien conocidos. La suma de comprobación calculada se añade la cabecera 80. A la recepción de la actualización 78 de configuración, se calcula un valor de suma de comprobación sobre la carga útil de la actualización 78 de configuración, y se compara con la suma de comprobación en la cabecera 80. Si las dos sumas de comprobación coinciden, entonces la actualización 78 de 5 configuración se determina que ha sido recibida con éxito. Si las dos sumas de comprobación no coinciden, entonces el dispositivo de recepción determina que ocurrió un error en la transmisión o recepción, y solicita que la actualización 78 de configuración sea retransmitida. Los diferentes elementos en la actualización 78 de configuración pueden estar separados 10 por un carácter designado tal como un carácter de Fin de Línea, o una coma, o cualquier otro carácter adecuado. Cuando se analiza sintácticamente la actualización 78 de configuración por el dispositivo de recepción, el dispositivo de recepción puede separar los diferentes elementos en base a los caracteres designados, y puede modificar los elementos correspondientes de la configuración 58 del dispositivo configurado. Alternativa o 15 adicionalmente, los diferentes elementos de la actualización 78 de configuración se pueden proporcionar en ubicaciones predefinidas en la actualización de configuración, o pueden tener un tamaño predefinido, o pueden tener un tamaño variable que se reporta en la cabecera 80. A la recepción de la actualización 78 de configuración, el dispositivo de recepción puede separar los elementos de la actualización de configuración en base a su 20 posición en el mensaje y/o tamaño. Aunque la actualización 78 de configuración se muestra con reglas 60, filtros 62, lógica 64 de procesamiento, y parámetros 74 de configuración actualizados, algunos de estos elementos se pueden omitir de la actualización 78 de configuración. Por ejemplo, si solamente las reglas 60, o una parte de una regla 60, se actualizan en una actualización 78 25 de configuración dada, entonces los elementos restantes se omiten de la actualización 78 de configuración. La cabecera 80 indica qué elementos se actualizan en una actualización 78 de configuración dada. Un ejemplo de una regla 60 adecuada para su uso en una configuración 74 o actualización 78 de configuración se muestra en la FIG. 7. La regla 60 intenta hacer coincidir un conjunto 30 de condiciones 82, por ejemplo, una primera condición 84, una segunda condición 86, etc., como se define en la regla 60, con las condiciones en la arquitectura 10. Cuando se cumple el conjunto de condiciones 82, entonces se desencadenan una o más acciones 88. Una condición es un conjunto predefinido de estados, estatus, o valores de parámetros que 25 un dispositivo intenta hacer coincidir contra estados, estatus, o parámetros en la arquitectura 10. Ejemplos de condiciones 82 incluyen la coincidencia de un estado de la arquitectura o un dispositivo con un valor predefinido o intervalo de valores, por ejemplo, el nivel de seguridad actual es 1, 2 o 3; el detector de humo está en un modo de “alarma”. Se pueden hacer coincidir múltiples estados en una única condición, por ejemplo, dos detectores de humo 5 separados entre sí más de una distancia predefinida están en un modo de “alarma”, se dispara un sensor de rotura de cristal y un detector de movimiento detecta movimiento en la habitación. Una o más de las condiciones 82 pueden estar basadas en el tiempo, por ejemplo, la hora actual es 10:30 AM; la hora actual está entre 10:00 PM y 6:00 AM. El conjunto de condiciones 82 puede ser un conjunto vacío; es decir, sin condiciones, en 10 cuyo caso la acción 88 se lleva a cabo inmediatamente tras la recepción de la regla 60, y se descarta posteriormente. Alternativamente, se puede aplicar una lógica personalizada para definir cómo llevar a cabo reglas que no tienen condiciones 82 asociadas. Algunas de o todas las condiciones 82 se pueden especificar usando operadores lógicos tales como AND, OR, XOR, NOT, etc. Por ejemplo, la regla 60 puede especificar que la 15 primera condición 84 y la segunda condición 86 se deben cumplir ambas para que la acción 88 sea desencadenada. Alternativamente, la regla 60 podría especificar que o bien la primera condición 84 o bien la segunda condición 86 se deben cumplir para desencadenar la acción 88. Cuando el conjunto de condiciones 82 se adapta a un estado actual de la arquitectura 10 o 20 el(los) dispositivo(s), se lleva a cabo la acción 88 especificada en la regla. Una acción 88 es un conjunto de una o más instrucciones o tareas a ser llevadas a cabo por el dispositivo en el que se desencadena la regla 60. Ejemplos de acciones 88 incluyen realizar una tarea localmente, por ejemplo, desencadenar un dispositivo de notificación integrado; procesar datos adicionales, y reenviar instrucciones a otros dispositivos, por ejemplo, enviar una 25 actualización de estado a la pasarela 20, escalar el nivel de seguridad de la arquitectura 10; disparar el lavavajillas para que empiece a funcionar. Una regla 60 puede especificar el número de veces que se va a ser llevada a cabo la regla. Esto se puede hacer, por ejemplo, especificando un número máximo de aplicaciones como una de las condiciones 84, y rastreando el número de veces que la regla 60 ha hecho que la 30 acción 88 sea desencadenada. Al alcanzar el número máximo de aplicaciones, se descarta la regla 60. Además de las reglas 60, la actualización 78 de configuración especifica los filtros 62. Dos 26 ejemplos de filtros 62 se muestran en las FIG. 8A y 8B. La FIG. 8A representa un filtro 90 de determinación de procesamiento ejemplar, que es un filtro de procesamiento previo aplicado a los datos presentes en un dispositivo local para determinar si los datos se deberían procesar inicialmente localmente, o reenviar a una ubicación diferente en la arquitectura 10 para su procesamiento. La FIG. 8B representa un filtro 102 de escalado ejemplar, que es un 5 filtro de procesado posterior aplicado después de que se procesan localmente los datos con el fin de determinar si los datos se deberían procesar además por otros dispositivos en la arquitectura 10. Como se muestra en la FIG. 8A, el filtro 90 de determinación de procesamiento incluye una lógica 92 de evaluación. La lógica 92 de evaluación acepta datos de entrada y/o información 10 contextual acerca de los datos, por ejemplo, el tipo de sensor(es) que generó(generaron) los datos, la ubicación en la que se desplegó(desplegaron) el(los) sensor(es), cualquier procesamiento inicial que se haya hecho sobre los datos, etc., y evalúa los datos para determinar si los datos se deberían procesar localmente. La lógica 92 de evaluación ejemplar evalúa los datos de entrada y/o la información 15 contextual contra uno o más umbrales 94 para determinar si los datos se deberían procesarse localmente. Un umbral 94 representa una magnitud o intensidad que se debe cumplir o exceder para que ocurra un resultado dado. En el ejemplo de la lógica de evaluación, los umbrales 94 representan líneas de división que hacen que ciertas acciones predefinidas sean realizadas dependiendo de si un parámetro medido cae de un lado o del 20 otro del umbral 94. En el filtro 90 de determinación de procesamiento ejemplar, los datos se comparan contra un umbral 96 de complejidad. Un umbral 96 de complejidad representa una complejidad máxima que el dispositivo local es capaz de tolerar en datos mientras que aún es capaz de procesar eficientemente los datos. En la realización ejemplar, la lógica 92 de evaluación 25 analiza los datos y la información contextual acerca de los datos, y asigna una puntuación de complejidad a los datos. La puntuación de la complejidad se puede calcular considerando el tipo de sensor desde el que se originaron los datos, la cantidad de los datos, si los valores de los datos son estables o variables, si los datos son claros o ruidosos, si los datos incluyen cualquier patrón reconocible inmediatamente, etc. 30 Si la puntuación de complejidad alcanza o excede el umbral 96 de complejidad, entonces la lógica 92 de evaluación determina que los datos son demasiado complejos para su procesamiento en el dispositivo local. Si la puntuación de complejidad está por debajo del umbral 96 de complejidad, entonces la lógica 92 de evaluación determina que el dispositivo 27 local es capaz de procesar los datos. La lógica 92 de evaluación también usa un umbral 98 de carga para realizar balanceo de carga. El balanceo de carga se refiere a la distribución de tareas, trabajos, u otro tipo de trabajo entre múltiples recursos informáticos. En la realización ejemplar, la lógica 92 de evaluación compara una carga en el procesador(es) local(es), por ejemplo, un porcentaje de 5 recursos de procesamiento local que se utilizan actualmente, un número y/o complejidad de trabajos que se procesan actualmente, etc., con el umbral 98 de carga. Si la carga actual satisface o excede el umbral 98 de carga, entonces la lógica 92 de evaluación puede determinar que la tarea de procesamiento en consideración se debería procesar en otra parte. Si la carga actual está por debajo del umbral 98 de carga, entonces la lógica 92 de 10 evaluación puede determinar que la tarea de procesamiento se debería realizar localmente. La lógica 92 de evaluación se puede programar con una lista de dispositivos accesibles que tienen recursos informáticos disponibles para su uso, por ejemplo, la entidad 20 de pasarela, y una indicación de los tipos de tareas de procesamiento en los que se especializan los dispositivos. Si la lógica 92 de evaluación determina que una tarea de procesamiento se 15 debería reenviar a otro dispositivo de la arquitectura, la lógica 92 de evaluación puede consultar la lista para seleccionar un dispositivo de destino adecuado. Los dispositivos de la lista se pueden asociar con una prioridad que indica el orden en el que se deberían enviar las tareas de procesamiento a los dispositivos enumerados. Por ejemplo, entre dispositivos especializados en un tipo de datos particular, por ejemplo, datos de 20 detector de humo, los dispositivos se pueden clasificar en orden de prioridad. La siguiente tarea de procesamiento recibida para ese tipo de datos particular se puede enviar al dispositivo de prioridad más alta en la lista. Se puede enviar una consulta al dispositivo de prioridad más alta para determinar si el dispositivo de prioridad más alta es capaz de realizar una nueva tarea de procesamiento. Si el dispositivo de prioridad más alta responde 25 reconociendo su disposición a realizar la tarea, los datos se pueden enviar al dispositivo de prioridad más alta para su procesamiento. Si el dispositivo de prioridad más alta responde rechazando la solicitud de procesamiento, el dispositivo local puede pasar al siguiente dispositivo de prioridad más alta en la lista. Este proceso se puede repetir hasta que se seleccione un dispositivo adecuado. 30 Los dispositivos en la lista pueden intercambiar mensajes, por ejemplo, a través de la entidad 20 de pasarela, para cambiar su clasificación de prioridad en otros dispositivos. Por ejemplo, si se asigna a un dispositivo dado un gran número de tareas de procesamiento y su carga de procesamiento se aproxima a una tolerancia predefinida del umbral 98 de carga del 28 dispositivo, el dispositivo sobrecargado puede enviar un mensaje a la entidad 20 de pasarela solicitando que la prioridad del dispositivo sobrecargado sea disminuida en la lógica 92 de evaluación de otros dispositivos de la arquitectura 10. Por consiguiente, es menos probable que otros dispositivos envíen tareas de procesamiento al dispositivo sobrecargado. Cuando la carga de procesamiento del dispositivo sobrecargado cae a un nivel predefinido, o 5 después de una cantidad de tiempo predeterminada, se puede elevar la prioridad del dispositivo. Un dispositivo local también puede cambiar la prioridad de un dispositivo remoto en la lógica 92 de evaluación del dispositivo local a medida que el dispositivo local asigna tareas al dispositivo remoto. Por ejemplo, si una entidad 20 de pasarela envía un trabajo de 10 procesamiento a un primer sensor 14, la entidad 20 de pasarela puede disminuir la prioridad del primer sensor de modo que la siguiente tarea se envíe a un segundo sensor 16. De esta manera, la entidad 20 de pasarela puede distribuir las tareas más uniformemente. La lista también puede incluir un dispositivo por defecto situado en el siguiente nivel más alto de la jerarquía 32, en comparación con el dispositivo local que se está preparando 15 actualmente para reasignar la tarea de procesamiento, al que se pueden reenviar tareas si no se identifica ningún otro dispositivo. Por ejemplo, el dispositivo por defecto en el nivel 36 intermedio de la jerarquía 32 puede ser la pasarela 20, y el dispositivo por defecto en el nivel 38 superior de la jerarquía 32 puede ser el dispositivo 30 de procesamiento en la nube o de terceros. 20 Además de determinar si los datos se deberían procesar local o remotamente, el filtro 90 de determinación de procesamiento también aplica un conjunto de reglas 100 de notificación a cualquier dato recibido para determinar si los datos se deberían registrar en una memoria local, reenviar a otros dispositivos especificados en la arquitectura 10, o procesar y descartar. El conjunto de reglas 100 de notificación coincide con las condiciones 82, tales 25 como un tipo de datos, un intervalo de tiempo en el que se deberían registrar los datos, patrones reconocidos en los datos, etc. frente a los datos de entrada, potencialmente después de que se procesen los datos por la lógica 92 de evaluación. Si las condiciones 82 coinciden con los datos, el conjunto de reglas 100 de notificación aplica una acción 88 tal como almacenar los datos en una memoria local, por ejemplo, la memoria 52 del sensor 14, 30 o la memoria 52 de la entidad 20 de pasarela, o reenviar los datos a un dispositivo especificado en la acción 88. Si el filtro 90 de determinación de procesamiento determina que los datos se deberían procesar localmente, los datos se procesan según la lógica 72 de procesamiento del 29 dispositivo local. Después del procesamiento por la lógica 72 de procesamiento, el dispositivo aplica un filtro 102 de escalado, como se muestra en la FIG. 10B, para determinar si los datos también se deberían escalar a otro dispositivo para procesamiento adicional. El filtro 102 de escalado se aplica si la lógica 72 de procesamiento decide tomar cualquier 5 acción, decide tomar una acción específica tal como levantar una alarma, decide no tomar ninguna acción, o cualquier combinación de posibilidades. El filtro 102 de escalado tiene una lógica 104 de evaluación que determina si los datos procesados se deberían escalar siendo procesados además en otro dispositivo. La lógica 104 de evaluación decide escalar los datos para procesamiento adicional si la lógica 72 de 10 procesamiento es incapaz de procesar los datos. Por ejemplo, si los datos son datos de voz que incluyen comandos, y la lógica 72 de procesamiento es incapaz de identificar los comandos en los datos de voz con un alto grado de confianza, la lógica 104 de evaluación puede escalar los datos para procesamiento adicional a un nivel superior de la jerarquía 32. La lógica 104 de evaluación consulta un umbral 106, tal como un umbral 108 de escalado, 15 con el fin de determinar si los datos se deberían escalar. En una realización ejemplar, el umbral 108 de escalado se aplica cuando la lógica 72 de procesamiento determina no tomar una acción, pero estuvo dentro de una tolerancia predefinida de tomar la acción, sugiriendo que la determinación puede ser un falso negativo. Alternativa o adicionalmente, el umbral 108 de escalado se aplica cuando la lógica 64 de procesamiento determina tomar una 20 acción, pero estuvo dentro de una tolerancia predefinida de no tomar la acción, sugiriendo que el resultado de la determinación puede ser un falso positivo. El umbral 108 de escalado es un valor o intervalo de valores que define estas tolerancias. Por ejemplo, la lógica 64 de procesamiento puede desencadenar una alarma en un dispositivo 18 de salida si el valor v de datos del sensor de un sensor se eleva por encima 25 de un umbral a de alarma predefinido. El umbral de escalado se puede fijar a un valor e. Si el valor v de datos del sensor se eleva por encima de a, la lógica 64 de procesamiento desencadenará la alarma. Si el valor v de datos del sensor está en o por debajo del valor a - e, entonces la lógica 72 de procesamiento determinará que no se debería desencadenar ninguna alarma, y el filtro 102 de escalado no escalará los datos para procesamiento 30 adicional por otro dispositivo. Si los datos del sensor están en un intervalo {a-e < v < a}, entonces la lógica 64 de procesamiento no desencadenará la alarma, pero el filtro 102 de escalado reenviará los datos a otro dispositivo para procesamiento adicional. 30 El umbral 108 de escalado se modifica por los modificadores 110 de nivel de seguridad. Los modificadores 110 de nivel de seguridad representan un valor o valores usados para elevar o disminuir el umbral 108 de escalado, dependiendo del nivel o estado de seguridad actual de la arquitectura 10, o una o más zonas 12 en la arquitectura 10. A medida que cambia el nivel o estado de seguridad, los modificadores 110 de nivel de seguridad modifican el 5 umbral 108 de escalado para hacer la lógica 104 de evaluación más o menos propensa a escalar los datos. Por ejemplo, si el nivel de seguridad se eleva, la lógica 104 de evaluación se puede hacer más probable que escale los datos para procesamiento adicional. Si el nivel de seguridad es relativamente bajo, la lógica 104 de evaluación se puede hacer menos probable que escale los datos. 10 En una realización adicional, la lógica 104 de evaluación aplica reconocimiento de patrón y escala los datos si se identifica un patrón particular en los datos, con independencia de si la lógica 64 de procesamiento decidió tomar una acción en respuesta a los datos. La lógica 104 de evaluación del filtro 102 de escalado selecciona un dispositivo al que se deberían reenviar los datos de una manera similar a la forma en que la lógica 92 de 15 evaluación del filtro 90 de determinación de procesamiento selecciona un dispositivo al que se deberían reenviar los datos. Los criterios para la lógica 104 de evaluación también pueden ser diferentes de los criterios para la lógica 92 de evaluación. El filtro 102 de escalado se aplica siguiendo al procesamiento de los datos por la lógica 64 de procesamiento. Un ejemplo de la lógica 64 de procesamiento se muestra en la FIG. 9. 20 La lógica 64 de procesamiento incluye una lógica 112 de evaluación. La lógica 112 de evaluación acepta datos de entrada, tales como datos de un detector 40 de un sensor 14, o datos agregados desde múltiples sensores, y procesa los datos para transformar los datos en nuevos datos de salida, modificar datos existentes, o realizar una acción. Los datos procesados se comparan con un umbral 116, tal como un umbral 118 de disparo. El umbral 25 118 de disparo define un valor que, si el valor de los datos de entrada se eleva por encima o cae por debajo, hace que una acción sea realizada. La lógica 112 de evaluación también aplica coincidencia de patrones a los datos para determinar si tomar la acción. Si la lógica 112 de evaluación indica que los datos exceden el umbral, o que los datos coinciden con un patrón predeterminado, la lógica 112 de evaluación puede determinar que 30 un evento está actualmente en curso o que un evento está a punto de ocurrir. En este caso, la lógica 112 de evaluación puede generar una notificación de evento para ser reenviada a la entidad de pasarela. 31 Los datos de entrada y/o los datos procesados también se comparan con un conjunto de reglas 114 de disparo. El conjunto de reglas 114 de disparo define las reglas 60 en las que las condiciones 82 se relacionan con los datos que se procesan. Por ejemplo, una regla del conjunto de reglas 114 de disparo puede indicar que, si los datos incluyen un patrón indicativo de que una persona regresa a su hogar, se debería encender un dispositivo 18 de 5 salida tal como una luz. Otra regla del conjunto de reglas 114 de disparo puede referirse al envío de una actualización de estado o notificación a otro dispositivo, tal como un dispositivo móvil de un usuario, el dispositivo 28 de procesamiento en la nube, o el servicio 30 de terceros. Las reglas del conjunto de reglas 114 de disparo pueden ser dependientes de la 10 localización, por ejemplo, incluyendo información de localización como una de las condiciones 82. Por ejemplo, si la regla es una regla que se desencadena por una alarma de incendio y desencadena una acción 88 de encender un sistema de rociadores, una de las condiciones de la regla puede ser que los rociadores no se deberían disparar hasta que sea absolutamente necesario si el dispositivo de salida (rociador) está en un laboratorio 15 informático o en una sala de servidores. Volviendo ahora a los parámetros 66, 74 de configuración, los parámetros ejemplares para la entidad 20 de pasarela y el sensor 14 se representan en las FIG. 10A y 10B, respectivamente. La FIG. 10A representa los parámetros 74 de configuración para despliegue en una entidad 20 20 de pasarela. Los parámetros 74 de configuración especifican una lista de dispositivos 120 conectados. La lista de dispositivos 120 conectados incluye un identificador para los dispositivos que están, o deberían estar, acoplados comunicativamente a la entidad 20 de pasarela, así como una indicación del tipo de dispositivo. El identificador puede ser una dirección del dispositivo, por ejemplo, una dirección IPv6. La lista de dispositivos 120 25 conectados incluye dispositivos que la entidad 20 de pasarela es responsable de supervisar, por ejemplo, los sensores 14, 16 y el dispositivo 18 de salida de la zona 12 monitorizada, así como otros dispositivos con los que la entidad 20 de pasarela es capaz de comunicarse, por ejemplo, el dispositivo 28 de procesamiento en la nube y el servicio 30 de terceros. Los parámetros 74 de configuración incluyen una lista de condiciones 122 de dispositivo que 30 representan el estado de los dispositivos en la lista de dispositivos 120 conectados. El estado de los dispositivos refleja cualquiera, o una combinación, de estado de comunicación, por ejemplo, conectado comunicativamente a la entidad 20 de pasarela y/o la red 22, estado de mantenimiento del dispositivo, por ejemplo, el nivel de batería del 32 dispositivo, si el dispositivo está programado para mantenimiento, si el dispositivo está reportando datos anormales, etc., un estado de configuración de los dispositivos, por ejemplo, una lista del(de los) ID(s) 138 de configuración para los dispositivos) y otros estados. La lista de condiciones 122 de dispositivo incluye la condición de la entidad 124 de pasarela 5 en sí misma, así como una condición 126 para los sensores y una condición 126 para los dispositivos de salida supervisados por la entidad 20 de pasarela. Las condiciones de estado se pueden reportar por los dispositivos en respuesta a una consulta de la entidad 20 de pasarela, a intervalos regulares, o se pueden actualizar por la entidad 20 de pasarela, por ejemplo, en respuesta a no recibir una respuesta o una actualización esperada desde el 10 dispositivo. Los parámetros 74 de configuración incluyen intervalos 130 de valores esperados para el dispositivo configurado. Los intervalos de valores esperados representan un intervalo de valores para uno o más parámetros operativos o características del dispositivo configurado que indican la operación normal del dispositivo. Si el dispositivo genera un parámetro 15 operativo o presenta una característica fuera de los intervalos 130 de valores esperados, esto puede indicar un mal funcionamiento del dispositivo configurado que requiere mantenimiento. Los parámetros de configuración pueden, por consiguiente, incluir un conjunto de reglas de mantenimiento con un conjunto de reglas 60 a ser aplicadas cuando uno o más parámetros operativos o características caigan fuera de los intervalos 130 de 20 valores esperados. El conjunto de reglas 132 de mantenimiento puede especificar acciones, tales como reportar un malfuncionamiento al servicio 30 de terceros o al usuario, o realizar operaciones de mantenimiento tales como reiniciar el dispositivo, usando hardware o software alternativo, si está disponible, o restaurar el dispositivo a una configuración última bien conocida. 25 Los parámetros 74 de configuración también incluyen un conjunto de reglas 134 de seguridad que incluye reglas 60 que especifican acciones 88 a ser tomadas en el caso de que se levante una condición de alarma o cambie el nivel 136 de seguridad de la arquitectura 10. El nivel 136 de seguridad representa un nivel de vigilancia o un estado de monitorización de 30 la arquitectura 10 o una parte de la arquitectura 10. El nivel 136 de seguridad se puede especificar como un valor cuantitativo, por ejemplo, nivel 1, nivel 2, etc., o se puede especificar como un conjunto de “modos”. Ejemplos de “modos” se muestran en la Tabla 1 a continuación: 33 Nombre del Modo Descripción del Modo Seguro La(s) zona(s) monitorizada(s) está(n) segura(s). Los sensores están habilitados y funcionan adecuadamente. No están presentes ocupantes en la(s) zona(s) monitorizada(s), excepto posiblemente mascotas. Vigilante La(s) zona(s) monitorizada(s) está(n) relativamente segura(s). Pueden estar presentes ocupantes. En Riesgo Estado de Transición que indica que la(s) zona(s) monitorizada(s) no está(n) segura(s). Puede estar intentándose autenticar un ocupante. Intrusos Algo va mal en la(s) zona(s) monitorizada(s). Podría indicar la presencia de intrusos o vandalismo. Emergencia Condición que amenaza la vida detectada, tal como un incendio o una fuga de gas. Problema Se ha detectado un problema significativo, tal como una inundación, fallo de energía, o aparato inoperable.Molestia Se ha detectado un problema menor. TABLA 1 El conjunto de reglas 134 de seguridad incluye acciones por defecto a ser tomadas siempre que el nivel 136 de seguridad esté en un estado particular. Por ejemplo, si el nivel 136 de seguridad se fija al modo de “emergencia”, el conjunto de reglas 134 de seguridad puede hacer que solicitudes de datos sean enviadas repetidamente a un sensor pertinente. 5 Los parámetros 74 de configuración desplegados en el dispositivo se pueden personalizar al dispositivo, a la ubicación en la que se despliega el dispositivo, y/o en base a otras consideraciones. Con el fin de identificar qué configuración está presente en qué dispositivo, que se puede usar, por ejemplo, para determinar si un dispositivo particular es muy adecuado para procesar ciertos tipos de datos, los parámetros 74 de configuración se 10 pueden asociar con uno o más ID(s) 138 de configuración. El(los) ID(s) 138 de configuración puede(n) ser, por ejemplo, una suma de comprobación, y una cadena de identificación, o una serie de marcas que identifican unívocamente una parte o la totalidad de un conjunto de parámetros 74 de configuración. 34 Los parámetros 74 de configuración también incluyen ajustes 140 de configuración por defecto. Los ajustes 140 de configuración por defecto son ajustes para algunos de o todos los parámetros 74 de configuración que se aplican en ciertas condiciones, tales como cuando se arranca o se reinicia el dispositivo, o cuando un parámetro 74 de configuración está dañado o de otro modo se vuelve inutilizable. A medida que se reciben actualizaciones 5 78 de configuración, los ajustes 140 de configuración por defecto se pueden actualizar opcionalmente con los nuevos ajustes de configuración contenidos en la actualización 78. Como se muestra en la FIG. 10B, los parámetros 66 de configuración para el despliegue en un sensor 14 son similares a los parámetros 74 de configuración de entidad de pasarela. Debido a que el sensor 14 no es responsable típicamente de supervisar otros dispositivos en 10 la arquitectura 10, algunos de los elementos de los parámetros 74 de configuración de entidades de pasarela se pueden eliminar en los parámetros 66 de configuración del sensor. Las reglas 60, los filtros 62, la lógica 64 de procesamiento, y los parámetros 66, 74 de configuración se aplican por dispositivos en la arquitectura para procesar datos de entrada de uno o más sensores 14. Los métodos realizados por los dispositivos en la arquitectura 10 15 se describirán a continuación con referencia a las FIG. 11-15. La FIG. 11 es un diagrama de flujo de datos que muestra un flujo de datos a través de la arquitectura 10. Por claridad de discusión, la FIG. 11 se centra ante todo en los aspectos de procesamiento de datos y de actualización de configuración descritos anteriormente del proceso 76 de balanceo doble. Algunos de los otros procesos descritos anteriormente se 20 omiten del diagrama de flujo de datos por claridad.Inicialmente, el sensor 14 primario genera datos del sensor y realiza un paso 142 de filtración para determinar si procesar los datos del sensor localmente, en el sensor 14 primario, o reenviar los datos del sensor a la entidad 20 de pasarela. En el proceso de filtrado, los datos de entrada del almacenador temporal 54 de datos del sensor se recuperan 25 por el procesador 42. Los datos se pueden agregar opcionalmente con otros datos. El procesador 42 aplica entonces el filtro 90 de determinación de procesamiento a los datos. En base a la lógica y los umbrales del filtro 90 de determinación de procesamiento, el procesador 42 determina si el(los) filtro(s) indica(n) que los datos se deberían registrar localmente. Si es así, los datos se almacenan en la memoria del dispositivo local. Los datos 30 se pueden almacenar durante una cantidad de tiempo predeterminada, o hasta que se borren los datos. Alternativa o adicionalmente, el(los) filtro(s) puede(n) indicar que los datos se deberían registrar, pero en un dispositivo remoto. Por consiguiente, los datos se pueden 35 reenviar al dispositivo remoto para su registro. Después de que o bien se registren los datos, o bien se tome una determinación de que los datos no necesitan ser registrados, el procesador 42 determina si el(los) filtro(s) indica(n) que los datos se deberían procesar localmente. Si no es así, entonces los datos se reenvían al siguiente destino indicado por la lógica 92 de evaluación (por ejemplo, la entidad 20 de 5 pasarela). Si, por otra parte, el procesador 42 determina que los datos se deberían procesar localmente, entonces el procesador carga la lógica 64 de procesamiento y procesa los datos en el paso 144 de procesamiento local. En paso 144 de procesamiento local, hay varios resultados posibles. Un resultado posible es que los datos procesados no desencadenan ninguna acción. Si los datos procesados no 10 desencadenan una acción y un filtro 102 de escalado no indica que los datos se deberían escalar para un procesamiento adicional, no se toma ninguna acción y el flujo de datos comienza de nuevo usando los nuevos datos generados por el sensor 14 primario. Si el filtro 102 de escalado indica que los datos se deberían escalar para procesamiento adicional, entonces los datos del sensor se reenvían a la entidad 20 de pasarela. 15 Otro posible resultado es que el procesamiento 144 local desencadene una acción de seguimiento, tal como una notificación de evento o una acción realizada por un dispositivo de salida. En estas situaciones, el paso 144 de procesamiento local genera una notificación de evento y la reenvía a la entidad 20 de pasarela, y/o genera un disparo y lo envía a un dispositivo 18 de salida primario. 20 Si el procesamiento 144 local realizado en el sensor 14 indica que está ocurriendo o está a punto de ocurrir un evento, el sensor 14 genera una notificación de evento y envía la notificación de evento a la entidad 20 de pasarela. La notificación de evento se puede enviar anterior a los datos no procesados o procesados desde el sensor 14. Al recibir la notificación de evento, el balanceador 68 de la entidad 20 de pasarela asigna recursos, por ejemplo, 25 recursos de procesamiento o recursos de memoria, al sensor 14 y se prepara para recibir datos del sensor 14, por ejemplo, creando o actualizando uno o más caminos 24 críticos de temporización al sensor 14. El sensor 14 reenvía entonces los datos del sensor directamente a la entidad 20 de pasarela para su evaluación. Por consiguiente, el sensor 14 se puede programar con una lógica 64 de procesamiento 30 relativamente simple que identifica cuando están ocurriendo o están a punto de ocurrir eventos, pero no tiene necesariamente la complejidad para procesar completamente los datos durante un evento. La lógica 64 de procesamiento más compleja se despliega en la 36 entidad 20 de pasarela, que procesa los datos cuando el sensor 14 hace la determinación inicial de que los datos sugieren la aparición de un evento. Si el paso 144 de procesamiento local hace que una actualización de estado sea enviada a la entidad 20 de pasarela, la entidad 20 de pasarela procesa el cambio de estado, por ejemplo, cambiando el nivel 136 de seguridad y aplicando las reglas aplicables a partir del 5 conjunto de reglas 134 de seguridad. Esto puede implicar el disparo de uno o más dispositivos 18 de salida. Si el paso 142 de filtración o el paso 144 de procesamiento local realizado por el sensor primario 14 hacen que los datos del sensor sean enviados a la entidad 20 de pasarela para procesamiento adicional, la entidad 20 de pasarela puede aplicar opcionalmente un paso 10 142 de filtración para determinar si la entidad 20 de pasarela debería procesar los datos del sensor localmente, o a través de un sensor secundario que sea alcanzable por la entidad 20 de pasarela. Si es así, la entidad de pasarela realiza un paso 144 de procesamiento local sobre los datos del sensor aplicando la lógica 64 de procesamiento de la entidad de pasarela a los datos. 15 En el paso 144 de procesamiento local realizado por la entidad 20 de pasarela, hay varios posibles resultados. Un posible resultado es que los datos procesados no desencadenan ninguna acción. Si los datos procesados no desencadenan una acción y un filtro 102 de escalado no indica que los datos se deberían escalar para procesamiento adicional, no se toma ninguna acción y el flujo de datos puede comenzar de nuevo usando los nuevos datos 20 generados por el sensor 14 primario. Si el filtro 102 de escalado indica que los datos se deberían escalar para procesamiento adicional, entonces los datos del sensor se reenvían al dispositivo 28 de procesamiento en la nube. Otro posible resultado es que el procesamiento 144 local desencadene una acción de seguimiento, tal como un cambio de estado o una acción realizada por un dispositivo de 25 salida. En estas situaciones, el paso 144 de procesamiento local genera una actualización de estado y la reenvía al servicio 30 de terceros, cambia el nivel 136 de seguridad en la entidad 20 de pasarela (si es necesario), y desencadena cualquier regla aplicable del conjunto de reglas 134 de seguridad. Por ejemplo, el paso de procesamiento local genera un desencadenador y lo reenvía a un dispositivo 18 de salida primario. 30 Aún otro posible resultado es que la entidad 20 de pasarela determina, o bien inicialmente o bien a medida que se procesan los datos, que los datos se deberían reenviar a un sensor 16 secundario que es muy adecuado para procesar los datos del sensor. Por ejemplo, el sensor 37 16 secundario se puede desplegar con una configuración 58 especializada que es particularmente bien adecuada para procesar el tipo de datos recibidos desde el sensor 14. Por consiguiente, el paso 144 de procesamiento local de la entidad 20 de pasarela puede reenviar los datos del sensor al sensor 16 secundario para su procesamiento, y puede recibir una actualización de estado en respuesta. 5 Alternativa o adicionalmente, el paso 144 de procesamiento local puede determinar que se necesitan datos suplementarios con el fin de procesar los datos del sensor. Si el sensor 16 secundario ya ha almacenado datos en el almacenador temporal 70 de datos del sensor de la entidad 20 de pasarela, la entidad de pasarela recupera los datos del sensor secundario desde su memoria 52. Alternativamente, el paso 144 de procesamiento local puede enviar 10 una solicitud al sensor 16 secundario, y recibir datos del sensor desde el sensor 16 secundario en respuesta. El paso 142 de filtración y/o el paso 144 de procesamiento local realizados por la entidad 20 de pasarela pueden hacer que los datos del sensor sean reenviados al procesador 28 en la nube para procesamiento adicional. El procesador 28 en la nube aplica un paso 142 de 15 filtración local (no mostrado) y un paso 144 de procesamiento a los datos. Similar al paso 144 de procesamiento local realizado por la entidad 20 de pasarela, el procesador 28 en la nube puede determinar que se necesitan datos adicionales a partir de un sensor 16 secundario. Si el paso 144 de procesamiento local realizado por el procesador 30 en la nube o de 20 terceros genera una actualización de estado y/o cualquier desencadenador para el dispositivo 18 de salida, la actualización de estado y el(los) desencadenador(es) se envían a la entidad 20 de pasarela y/o al servicio 30 de terceros para ser actuado en consecuencia. También se pueden enviar actualizaciones de configuración a la entidad 20 de pasarela como una salida del paso 144 de procesamiento local realizado por el dispositivo 28 de 25 procesamiento en la nube. Las actualizaciones de configuración pueden cambiar los ajustes de configuración de la entidad 20 de pasarela. Se señala que, aunque la FIG. 11 muestra el sensor 14 que reenvía datos a la entidad 20 de pasarela para su análisis, el sensor 14 también puede reenviar datos directamente al dispositivo 30 de procesamiento en la nube o de terceros. 30 La FIG. 12 representa un procedimiento 146 de operación ejemplar adecuado para su uso por el sensor 14, y cualquier otro sensor en la arquitectura 10. El procedimiento comienza en el paso 148, donde se inicializa el sensor. Esto puede implicar, por ejemplo, realizar 38 comprobaciones de inicio del sistema, cargar los ajustes 140 de configuración por defecto desde la memoria, fijar cualquier parámetro pertinente en la configuración 58 en base a los ajustes 140 de configuración por defecto, inicializar los almacenadores temporales 54, 56, establecer comunicación con la entidad 20 de pasarela a través de la interfaz 46 de comunicación, y aplicar reglas de mantenimiento pertinentes a partir del conjunto de reglas 5 132 de mantenimiento. El procesado entonces pasa al paso 150, donde el sensor 14 comprueba el almacenador temporal 56 de red para nuevos mensajes. Si el sensor 14 determina, en el paso 152, que el almacenador temporal 56 de red incluye un nuevo desencadenador o solicitud de acceso remoto, por ejemplo, de la entidad 20 de pasarela, entonces el procesamiento pasa al paso 10 154 y se procesa el mensaje de desencadenador o solicitud. En el caso de un desencadenador, el sensor 14 puede analizar sintácticamente el mensaje de desencadenador para recuperar una acción que el sensor 14 solicita tomar, tal como disparar un dispositivo 18 de salida accesible al sensor 14. En el caso de una solicitud de acceso remoto, el sensor 14 analiza sintácticamente la 15 solicitud para identificar una entidad que está solicitando acceso a las capacidades del sensor. El sensor 14 evalúa o autentica la entidad para determinar si la entidad está autorizada para acceder a las capacidades solicitadas. Si es así, el sensor abre o se conecta a un canal de comunicación con la entidad solicitante, y ejecuta comandos autorizados desde la entidad solicitante que permiten a la entidad solicitante controlar las 20 capacidades de sensor que fueron el objeto de la solicitud. Por ejemplo, el servicio 30 de terceros puede presentar una solicitud de acceso remoto a una cámara de vídeo, y puede presentar comandos para controlar las capacidades de posicionamiento de la cámara de vídeo, por ejemplo, hacer una panorámica, inclinarse, y rotar. Alternativamente, el servicio 30 de terceros podría solicitar acceso a datos de audio y/o vídeo de la cámara, y se podría 25 dotar con acceso al almacenador temporal 54 de datos de la cámara. El procesamiento vuelve entonces al paso 150, donde se comprueba el almacenador temporal 56 de red para desencadenadores o solicitudes de acceso remoto adicionales. Si la determinación en el paso 152 es “NO”; es decir, no están presentes nuevos desencadenadores o solicitudes de acceso remoto en el almacenador temporal 56 de red, el 30 procesamiento pasa al paso 156 y el siguiente lote de datos se recupera del almacenador temporal 54 de datos. El procesado entonces pasa al paso 158, donde el sensor 14 determina si un evento ya está 39 en curso. Por ejemplo, si el procesamiento previo realizado por el sensor hizo al sensor enviar una notificación de evento a la entidad 20 de pasarela, entonces el sensor 14 puede establecer una marca de “evento en curso” en una ubicación designada en la memoria 52 del sensor. Cuando el sensor 14 o la entidad 20 de pasarela determina que el evento ha terminado, el sensor 14 puede reiniciar la marca de “evento en curso”. En el paso 158, el 5 sensor 14 puede comprobar la marca de evento en curso para evaluar si un evento está en curso actualmente. Si el resultado en el paso 158 es “SÍ”; es decir, un evento está actualmente en curso, entonces el sensor 14 pasa directamente al paso 166 y reenvía los datos del sensor desde el almacenador temporal 54 de datos directamente a la entidad de pasarela para su 10 procesamiento. Si el resultado en el paso 158 es “NO”; es decir, un evento no está actualmente en curso, entonces el sensor 14 pasa al paso 160 y realiza la filtración y/o procesamiento, por ejemplo, que corresponde a los pasos 142 y 144 de FIG. 11, sobre los datos. En base a la filtración y/o procesamiento, el sensor evalúa, en el paso 162, si los datos recién procesados 15 indican que está ocurriendo actualmente o se prevé que ocurra un evento. Si no es así, entonces el procesamiento vuelve al paso 150 y se comprueba de nuevo el almacenador temporal para nuevos mensajes. Si la determinación en el paso 162 es “SÍ”; es decir, está ocurriendo o se prevé que ocurra un evento, entonces el procesamiento pasa al paso 164 y el sensor 14 transmite una 20 notificación de evento a la entidad 20 de pasarela para informar a la entidad 20 de pasarela que los datos del sensor estarán llegando a la entidad de pasarela en un futuro próximo. En respuesta, la entidad de pasarela asigna recursos en preparación para recibir los datos. El procesamiento pasa entonces al paso 166, en el que se transmite el siguiente lote de datos en bruto a la entidad 20 de pasarela. 25 Algunos de o todos los pasos del procedimiento 146 de operación se pueden realizar en paralelo, si el procesador 42 del sensor 14 soporta procesamiento paralelo. Por ejemplo, la FIG. 12 separa los pasos usados para procesar desencadenadores y solicitudes de acceso remoto de los pasos usados para procesar los datos del sensor. Los desencadenadores/las solicitudes de acceso remoto se realizan en un primer hilo 168, y los pasos de 30 procesamiento de datos del sensor se realizan en un segundo hilo 170. Si los pasos del procedimiento 146 de operación se van a realizar en paralelo, entonces el paso 148 de inicialización puede incluir la creación de nuevos hilos para conjuntos de procedimientos paralelos. 40 La FIG. 13 representa un procedimiento 172 de operación correspondiente adecuado para el realizar por una entidad 20 de pasarela. El procedimiento 172 comienza en el paso 174, cuando se inicializa la entidad 20 de pasarela. Esto puede implicar, por ejemplo, realizar comprobaciones de inicio del sistema, cargar los ajustes 140 de configuración por defecto desde la memoria, establecer cualquier parámetro pertinente en la configuración 58 en base 5 a los ajustes 140 de configuración por defecto, inicializar los almacenadores temporales 54, 56 de datos, establecer la comunicación con los dispositivos en la lista de dispositivos 120 conectados, y aplicar reglas de mantenimiento pertinentes a partir del conjunto de reglas 132 de mantenimiento. El procesamiento pasa entonces al paso 176, donde se comprueba el almacenador temporal 10 56 de red para determinar si hay cualquier mensaje pendiente de evaluación. Debido a que la entidad 20 de pasarela maneja muchos tipos diferentes de mensajes, los mensajes se clasifican en los pasos 178, 184, 188 y 190. Los diferentes tipos de mensajes se manejan en orden de prioridad, por ejemplo, mensajes que tienen notificaciones de eventos, que podrían incluir una condición de alarma, se pueden procesar antes que mensajes que tengan nuevos 15 datos del sensor para procesamiento. En el paso 178, la entidad 20 de pasarela determina si hay una notificación de evento pendiente. Si es así, el procesamiento pasa al paso 180 y se procesa la notificación de evento. En el paso 180, el balanceador 68 de la entidad de pasarela asigna recursos para el sensor 14 que presentó la notificación de evento. La cantidad de recursos asignados puede 20 depender del tipo de sensor que presentó la notificación de evento o el tipo de evento. Por ejemplo, el procesamiento de datos de un detector de humo puede implicar comprobaciones relativamente simples, tales como si el detector 40 lee un valor por encima de un umbral que indica la presencia de humo en la habitación y/o comprobación de un termómetro cercano. Por otra parte, el procesamiento de datos de un sensor de rotura de cristal puede implicar 25 pasos de procesamiento de audio complejos y, por lo tanto, el balanceador 68 puede asignar más recursos en respuesta a una notificación de evento de un sensor de rotura de cristal que de un detector de humo. El procesamiento entonces pasa al paso 182, y se evalúa/ejecuta el conjunto de reglas 134 de seguridad. Si el nivel 136 de seguridad se cambia por el conjunto de reglas de seguridad, 30 la entidad 20 de pasarela puede actualizar el nivel 136 de seguridad. Una vez que se dirige la notificación de evento, el procesamiento entonces vuelve al paso 176 y el almacenador temporal 56 de red se comprueba para mensajes adicionales. En el paso 184, la entidad 20 de pasarela determina si hay un nuevo mensaje de disparo 41 pendiente. Si es así, el procesamiento pasa al paso 186 y la entidad de pasarela reenvía el mensaje de disparo a los dispositivos 18 de salida afectados. El procesamiento entonces vuelve al paso 176 y se comprueba el almacenador temporal 56 de red para mensajes adicionales. En el paso 188, la entidad 20 de pasarela determina si hay nuevos datos del sensor a ser 5 procesados. Si es así, el procesamiento pasa a los pasos 142 y 144 y se realizan los métodos de filtración y procesamiento de la entidad de pasarela. Si están pendientes de ser procesados múltiples lotes de datos, la entidad 20 de pasarela puede priorizar los datos para los que se ha recibido una notificación de evento, y puede priorizar eventos de prioridad alta sobre eventos de prioridad baja. Después de que se procesan los datos del sensor, el 10 procesamiento vuelve al paso 176 y se comprueba el almacenador temporal 56 de red para mensajes adicionales. En el paso 190, la entidad 20 de pasarela determina si hay cualquier mensaje de configuración pendiente. Si es así, el procesamiento pasa al paso 192 y se recupera la siguiente actualización 78 de configuración del almacenador temporal 56 de red. En el paso 15 194, la actualización 78 de configuración recuperada se analiza sintácticamente para separar los elementos respectivos, por ejemplo, las reglas 60, los filtros 62, la lógica 64 de procesamiento, y los parámetros 66 de configuración, de la actualización 78 de configuración. Por ejemplo, si los elementos están separados por un carácter designado, la entidad de pasarela lee la actualización 78 de configuración hasta que se alcanza el carácter 20 designado, e identifica los datos leídos con el elemento adecuado de la actualización 78 de configuración. Alternativamente, la cabecera 80 puede especificar dónde encontrar los elementos respectivos de la actualización 78 de configuración. En el paso 196, se evalúan los elementos respectivos para determinar cómo actualizar la configuración 74 de la entidad de pasarela. Por ejemplo, la entidad 20 de pasarela 25 determina si el elemento de la actualización 78 de configuración es un nuevo elemento de configuración o es una nueva versión de un elemento de configuración existente ya desplegado en la entidad 20 de pasarela. Si no existe ningún elemento de configuración correspondiente, por ejemplo, el elemento de configuración es una nueva regla a ser añadida al conjunto de reglas 114 de disparo, entonces el elemento de configuración se 30 añade a la configuración 74. Si existe un elemento de configuración correspondiente, por ejemplo, el elemento de configuración es una nueva versión de una regla existente en el conjunto de reglas 114 de disparo, entonces el nuevo elemento de configuración sobrescribe el elemento de configuración antiguo. 42 El procesamiento vuelve entonces al paso 176 y se comprueba el almacenador temporal 56 de red para mensajes adicionales. Algunos de o todos los pasos del procedimiento 172 de operación se pueden realizar en paralelo. La FIG. 13 representa una realización ejemplar en la que las actualizaciones de estado se procesan en un primer hilo, los mensajes de disparo se procesan en un segundo 5 hilo, los datos del sensor se procesan en un tercer hilo, y las actualizaciones de estado se procesan en un cuarto hilo. Si las etapas del procedimiento 172 de operación van a ser realizadas en paralelo, entonces el paso 174 de inicialización puede incluir la creación de nuevos hilos para conjuntos de procedimientos paralelos. Los procedimientos ejemplares descritos en las FIG. 11-13 pueden formar parte del proceso 10 76 de balanceo doble. Estos procedimientos se pueden complementar con procedimientos adicionales según sea necesario o aplicable. Las FIG. 14A-14B representan un ejemplo del proceso 76 de balanceo doble funcionando. En el paso 198, la entidad 20 de pasarela envía un mensaje de supervisión a un primer sensor 14, solicitando que el sensor confirme que está operativo y conectado a la entidad 20 15 de pasarela. En el paso 200, el sensor responde reconociendo el mensaje de supervisión, y por lo tanto la entidad de pasarela no toma ninguna acción (paso 202) en respuesta al reconocimiento. Por el contrario, cuando la entidad 20 de pasarela envía un mensaje de supervisión, en el paso 204, a un segundo sensor 16, la entidad de pasarela no recibe ninguna respuesta 20 (paso 206). Por consiguiente, en el paso 208, la entidad de pasarela señala que el segundo sensor 16 ha fallado, y reporta el fallo al dispositivo 28 de procesamiento en la nube. El dispositivo 28 de procesamiento en la nube señala, en el paso 210, que el segundo sensor ha fallado, y reporta el fallo al servicio 30 de terceros. En el paso 212, el servicio 30 de terceros señala que ha fallado el segundo sensor 16. 25 En el paso 214, el primer sensor 14 detecta la aparición de un evento, y envía una notificación de evento a la entidad 20 de pasarela. En respuesta a la notificación de evento, en el paso 216 la entidad 20 de pasarela invoca que el balanceador 68 asigne recursos para el primer sensor 14. En el paso 218, el primer sensor 14 envía datos en bruto a la entidad 20 de pasarela, que la 30 entidad 20 de pasarela procesa en el paso 220. En este ejemplo, la entidad 20 de pasarela determina, en el paso 220, que los datos desencadenan una acción a partir del conjunto de reglas 114 de disparo. En este caso, la acción implica generar un aviso vocal de vuelta al 43 primer sensor 14 con el fin de solicitar información adicional. Por consiguiente, en el paso 224, la entidad 20 de pasarela genera un aviso vocal, por ejemplo, “Se ha detectado un evento por el primer sensor. ¿Necesita ayuda?”. El aviso vocal puede ser un aviso predeterminado almacenado en el conjunto de reglas 114 de disparo, o se puede generar dinámicamente por la entidad 20 de pasarela. Por ejemplo, la entidad 20 de pasarela puede 5 generar un archivo de texto que contiene información a ser transmitida al primer sensor 14, y puede usar algoritmos de texto a habla para convertir el archivo de texto a un flujo de audio. En el paso 226, la pasarela envía una solicitud de acceso remoto al primer sensor 14, solicitando que el primer sensor 14 dé el control del altavoz y del micrófono del sensor. En respuesta, el sensor 14 abre un canal con la entidad 20 de pasarela para permitir que tenga 10 lugar la comunicación de audio bidireccional, y reproduce el aviso generado en el paso 224 a través del altavoz del sensor. En el paso 228, la entidad 20 de pasarela recibe un reconocimiento de que el sensor 14 ha aceptado las solicitudes de acceso remoto, y comienza una interacción bidireccional con cualquier usuario en presencia del sensor 14, usando realimentación de audio y algoritmos 15 de habla a texto. La entidad 20 de pasarela reenvía los datos de audio recibidos desde el sensor 14 al dispositivo 28 de procesamiento en la nube en el paso 230, que a su vez realiza procesamiento avanzado de los datos, graba y registra el audio para referencia futura, y facilita el procesamiento de los requisitos en la entidad 20 de pasarela generando dinámicamente un diccionario de interacción en base al contenido del audio recibido. Por 20 ejemplo, el dispositivo 28 de procesamiento en la nube dota a la entidad 20 de pasarela con una lista de palabras o frases que son aplicables en el contexto del audio recibido, y la entidad de pasarela usa la lista de palabras y frases para continuar una conversación en tiempo real a través del primer sensor 14. Por ejemplo, en respuesta al mensaje inicial de la entidad de pasarela “¿necesita 25 asistencia?”. Un usuario puede haber respondido con “sí, hay un incendio en la casa”. En respuesta, el dispositivo 28 de procesamiento en la nube genera un diccionario de interacción que incluye frases tales como “¿cuántas personas hay en la casa?”, “¿Pueden salir todos con seguridad de la casa?”, y “¿dónde está situada actualmente la persona que necesita asistencia?” Si la entidad 20 de pasarela averigua que alguien no puede salir con 30 seguridad de la casa, la entidad 20 de pasarela puede entonces, usando el diccionario de interacción, generar un aviso preguntando dónde está situado el usuario que necesita asistencia. En el paso 232, el sensor 14 recibe una entrada de audio que reconoce el evento; por 44 ejemplo, “sí, hay un incendio en la casa”. El sensor 14 mantiene el canal de audio abierto en el paso 226 y continúa reenviando datos de audio a la entidad 20 de pasarela. En el paso 234, habiendo recibido un reconocimiento de que está teniendo lugar el suceso, la entidad 20 de pasarela determina que debería contactar con otros sensores en las inmediaciones del primer sensor 14. Por consiguiente, el balanceador 68 de la entidad 20 de 5 pasarela asigna recursos adicionales para los múltiples sensores. En el paso 236, la entidad 20 de pasarela difunde una alarma de audio, por ejemplo, “se ha detectado una emergencia; por favor, avance con calma a la salida más cercana”, a todos los sensores en las inmediaciones del primer sensor 14. Por ejemplo, la alarma de audio puede estar en forma de un mensaje de disparo que contiene una grabación de audio e 10 instrucciones para reproducir la grabación de audio a través de los altavoces del sensor. En los pasos 238-242, los sensores en las inmediaciones del primer sensor 14, excepto para el segundo sensor 16, que presentaba un fallo en los pasos 206-212, reciben la alarma de audio y reproducen la alarma de audio a través de su respectivo altavoz. Mientras tanto, en el paso 238, el dispositivo 28 de procesamiento en la nube inicia una 15 llamada a una estación de monitorización del servicio 30 de terceros. Además, en el paso 240, el dispositivo 28 de procesamiento en la nube inicia una llamada al 911 para convocar a los primeros respondedores. El dispositivo 28 de procesamiento en la nube transfiere la llamada del 911 al servicio 30 de terceros, que conecta la llamada en el paso 242 y transmite las coordenadas GPS, por ejemplo, desde la entidad 20 de pasarela y/o el primer 20 sensor 14) al servicio 911. Simultáneamente, en el paso 244, la entidad 20 de pasarela se conecta remotamente al servicio 30 de terceros y al servicio 911, y presenta una solicitud de acceso remoto a los sensores accesibles, pasos 246-250. La entidad 20 de pasarela accede a los datos del sensor y los proporciona al servicio 30 de terceros y al servicio 911. En el paso 252, el 25 servicio 30 de terceros recibe los datos del sensor y mantiene una conexión de audio y vídeo con la zona 12 monitorizada a través de los sensores accedidos remotamente. Una vez que se determina que el evento está concluido, la entidad 20 de pasarela, en el paso 254, invoca al balanceador 68 para liberar los recursos asignados al evento, y vuelve a un modo de supervisión. 30 Como se puede ver a partir de este ejemplo y las realizaciones descritas anteriormente, el proceso 76 de balanceo doble permite procesar trabajos en la arquitectura 10 para ser distribuidos entre los diferentes niveles de la jerarquía 32 según sea adecuado, ahorrando 45 recursos de procesamiento en los sensores 14, 16 y la entidad 20 de pasarela. Debido a que los sensores solamente necesitan procesar información básica para determinar si está ocurriendo un evento y luego pueden reenviar los datos a la entidad 20 de pasarela, los sensores pueden operar con menos recursos de procesamiento, haciéndolos de esta manera menos costosos y más capaces de operar en modos de baja potencia o inactivo. 5 Además, las tareas de procesamiento complejas se pueden realizar en los niveles más altos de la jerarquía 32, permitiendo que sean realizados un análisis de datos y procedimientos más complicados, tales como interacciones de audio en tiempo real. Como se usa en la presente memoria, un elemento o paso expuesto en singular y precedido con la palabra “un” o “una” se debería entender que no excluye elementos o pasos plurales, 10 a menos que tal exclusión se exponga explícitamente. Además, referencias a “una realización” no tienen que ser interpretadas como que excluyen la existencia de realizaciones adicionales que también incorporen las características expuestas. Aunque se han descrito en la presente memoria ciertas realizaciones de la descripción, no se pretende que la descripción se limite a las mismas, ya que se pretende que la descripción 15 sea tan amplia en su alcance como la técnica permita y que la especificación se lea del mismo modo. Por lo tanto, la descripción anterior no se debería interpretar como limitante, sino meramente como ejemplificaciones de realizaciones particulares. Los expertos en la técnica imaginarán otras modificaciones dentro del alcance y del espíritu de las reivindicaciones adjuntas a la presente memoria. 20

Claims (20)

  1. 46 REIVINDICACIONES 1. Un aparato de balanceo de recursos en una arquitectura de automatización y alarma que comprende: una memoria operable para almacenar datos de un sensor; y un procesador operable para: 5 recibir una notificación de evento del sensor que indica que ha ocurrido o se prevé que ocurra un evento, asignar recursos de procesamiento o de memoria para el sensor en respuesta a la notificación de evento, recibir datos del sensor, 10 procesar los datos recibidos usando los recursos asignados, y liberar los recursos cuando se concluya el evento.
  2. 2. El aparato de la reivindicación 1, en el que la memoria almacena además una lógica de procesamiento específica para un tipo de datos generados por el sensor, y el procesador llama a la lógica de procesamiento para procesar los datos recibidos. 15
  3. 3. El aparato de la reivindicación 2, en el que el procesador es operable además para: recibir una actualización de configuración que cambia la lógica de procesamiento, y procesar la actualización de configuración para cambiar la lógica de procesamiento almacenada en la memoria.
  4. 4. El aparato de la reivindicación 1, en el que el procesador es operable además para 20 transmitir una solicitud de acceso remoto al sensor, la solicitud de acceso remoto que da instrucciones al sensor para dar el control sobre uno o más componentes del sensor al aparato.
  5. 5. El aparato de la reivindicación 1, en el que los datos recibidos incluyen datos de audio, y el procesador es operable además para: 25 generar una interacción de audio en tiempo real usando un diccionario de interacción proporcionado por un dispositivo de procesamiento en la nube.
  6. 6. El aparato de la reivindicación 1, en el que el procesador es operable además para 47 generar un desencadenador en respuesta a los datos recibidos, el desencadenador que da instrucciones a un dispositivo de salida para tomar una acción.
  7. 7. El aparato de la reivindicación 1, en el que la asignación de los recursos se realiza en base a un tipo del sensor o un tipo de los datos proporcionados por el sensor.
  8. 8. Un aparato que comprende: 5 un detector operable para generar datos del sensor;una memoria operable para almacenar los datos del sensor; y un procesador operable para: evaluar los datos del sensor para determinar si los datos del sensor indican que está ocurriendo o se prevé que ocurra un evento, 10 generar una notificación de evento cuando la evaluación determine que está ocurriendo o se prevé que ocurra un evento, enviar la notificación de evento a una entidad de pasarela, y posterior a reenviar la notificación de evento, reenviar los datos del sensor a la entidad de pasarela. 15
  9. 9. El aparato de la reivindicación 8, en el que el procesador es operable además para: recibir una solicitud de acceso remoto de una entidad, la solicitud de acceso remoto que da instrucciones al procesador para dar el control sobre un componente del aparato a la entidad; evaluar la entidad para determinar si la entidad está autorizada para acceder al 20 componente; y proporcionar el control sobre el componente a la entidad cuando la entidad está autorizada para acceder al componente.
  10. 10. El aparato de la reivindicación 8, que comprende además un dispositivo de salida, en el que el procesador es operable además para: 25 recibir un disparo que solicita que el aparato tome una acción con respecto al dispositivo de salida, y desencadenar el dispositivo de salida para tomar la acción. 48
  11. 11. El aparato de la reivindicación 8, en el que el procesador es operable además para establecer un camino crítico de temporización entre el aparato y la entidad de pasarela, el camino crítico de temporización estando configurado para proporcionar interacción en tiempo real o casi en tiempo real entre la entidad de pasarela y el aparato.
  12. 12. Un método para balancear recursos en una arquitectura de automatización y alarma que 5 comprende: recibir, en un procesador de una entidad de pasarela desde un sensor, una notificación de evento que indica que está ocurriendo o se prevé que ocurra un evento en el sensor; asignar, en respuesta a la notificación de evento, uno o más recursos a la entidad de pasarela; 10 establecer un camino crítico de temporización entre la entidad de pasarela y el sensor; recibir datos desde el sensor en la entidad de pasarela; procesar los datos recibidos en tiempo real o casi en tiempo real; y desencadenar una acción en respuesta a los datos recibidos.
  13. 13. El método de la reivindicación 12, en el que desencadenar la acción comprende reenviar 15 los datos recibidos a un dispositivo de procesamiento en la nube para procesamiento avanzado.
  14. 14. El método de la reivindicación 12, en el que desencadenar la acción comprende disparar un dispositivo de salida para activar una alarma.
  15. 15. El método de la reivindicación 12, en el que desencadenar la acción comprende 20 proporcionar datos desde el sensor a un servicio de primer respondedor.
  16. 16. El método de la reivindicación 12, en el que desencadenar la acción comprende el acoplamiento en una interacción de audio bidireccional con el sensor.
  17. 17. El método de la reivindicación 16, en el que la interacción de audio bidireccional se dirige en base a un diccionario de interacción proporcionado por un dispositivo de procesamiento 25 en la nube.
  18. 18. El método de la reivindicación 12, que comprende además: determinar que el evento está completado, y liberar los recursos asignados. 49
  19. 19. El método de la reivindicación 12, que comprende además: recibir una actualización de configuración que cambia una manera en la que la entidad de pasarela procesa los datos desde el sensor, y aplicar la actualización de configuración.
  20. 20. El método de la reivindicación 12, en el que la entidad de pasarela determina, en 5 respuesta a los datos del sensor, interactuar con sensores adicionales, y la entidad de pasarela asigna recursos adicionales para la interacción con múltiples sensores. 10
ES201790010A 2014-10-03 2015-10-02 Método y aparato para balancear recursos en una arquitectura de automatización y alarma Active ES2646632B2 (es)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201462059410P 2014-10-03 2014-10-03
US62/059,410 2014-10-03
US14/857,900 2015-09-18
US14/857,900 US10592306B2 (en) 2014-10-03 2015-09-18 Method and apparatus for resource balancing in an automation and alarm architecture
PCT/CA2015/051000 WO2016049778A1 (en) 2014-10-03 2015-10-02 Method and apparatus for resource balancing in an automation and alarm architecture

Publications (3)

Publication Number Publication Date
ES2646632A2 true ES2646632A2 (es) 2017-12-14
ES2646632R1 ES2646632R1 (es) 2018-03-13
ES2646632B2 ES2646632B2 (es) 2019-05-03

Family

ID=55629218

Family Applications (1)

Application Number Title Priority Date Filing Date
ES201790010A Active ES2646632B2 (es) 2014-10-03 2015-10-02 Método y aparato para balancear recursos en una arquitectura de automatización y alarma

Country Status (5)

Country Link
US (1) US10592306B2 (es)
ES (1) ES2646632B2 (es)
GB (1) GB2550476B (es)
MX (1) MX381752B (es)
WO (1) WO2016049778A1 (es)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210203567A1 (en) * 2019-12-27 2021-07-01 Digital Guardian, LLC Systems and methods for investigating potential incidents across entities in networked environments
US11314563B1 (en) * 2021-03-18 2022-04-26 Citrix Systems, Inc. Context-based generation of activity feed notifications

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9812126B2 (en) * 2014-11-28 2017-11-07 Microsoft Technology Licensing, Llc Device arbitration for listening devices
US10958531B2 (en) * 2015-12-16 2021-03-23 International Business Machines Corporation On-demand remote predictive monitoring for industrial equipment analysis and cost forecast
CN106899497A (zh) * 2015-12-18 2017-06-27 阿基米德自动控制公司 智能多通道无线数据获取网关
CN106559579B (zh) * 2016-11-30 2020-08-21 契科基纳(南京)科技有限公司 移动终端和cpu/gpu调度参数更新方法
US10923104B2 (en) 2017-06-30 2021-02-16 Ademco Inc. Systems and methods for customizing and providing automated voice prompts for text displayed on a security system keypad
US10673715B2 (en) 2017-07-20 2020-06-02 Servicenow, Inc. Splitting network discovery payloads based on degree of relationships between nodes
JP6451909B1 (ja) * 2017-08-03 2019-01-16 オムロン株式会社 センサ管理ユニット、センサ装置、センサ管理方法、及びセンサ管理プログラム
US11134320B2 (en) * 2017-08-03 2021-09-28 Omron Corporation Sensor management unit, sensor device, sensor management method, and sensor management program
US10833923B2 (en) * 2017-10-26 2020-11-10 Skylo Technologies Inc. Dynamic multiple access for distributed device communication networks with scheduled and unscheduled transmissions
US10306442B1 (en) 2018-01-16 2019-05-28 Skylo Technologies Inc. Devices and methods for specialized machine-to-machine communication transmission network modes via edge node capabilities
US11163434B2 (en) 2019-01-24 2021-11-02 Ademco Inc. Systems and methods for using augmenting reality to control a connected home system
US11520946B2 (en) 2019-04-09 2022-12-06 Johnson Controls Tyco IP Holdings LLP Cloud-based fire protection system and method
CN117063140A (zh) * 2021-03-25 2023-11-14 瑞典爱立信有限公司 用于感官环境中感官事件的标记以及优先化的系统以及方法

Family Cites Families (47)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5309146A (en) 1988-05-03 1994-05-03 Electronic Environmental Controls Inc. Room occupancy indicator means and method
US5568535A (en) 1992-06-01 1996-10-22 Trackmobile, Inc. Alarm system for enclosed area
US5864286A (en) 1995-05-16 1999-01-26 General Signal Corporation Distributed intelligence alarm system having a two- tier monitoring process for detecting alarm conditions
US7015806B2 (en) 1999-07-20 2006-03-21 @Security Broadband Corporation Distributed monitoring for a video security system
US6317042B1 (en) 2000-05-01 2001-11-13 Lucent Technologies Inc. Automated emergency announcement system
US7047196B2 (en) * 2000-06-08 2006-05-16 Agiletv Corporation System and method of voice recognition near a wireline node of a network supporting cable television and/or video delivery
US6658091B1 (en) 2002-02-01 2003-12-02 @Security Broadband Corp. LIfestyle multimedia security system
US20090120653A1 (en) 2003-07-31 2009-05-14 Michael Steven Thomas Fire suppression delivery system
US7380039B2 (en) * 2003-12-30 2008-05-27 3Tera, Inc. Apparatus, method and system for aggregrating computing resources
US7193508B2 (en) * 2004-02-12 2007-03-20 Hill Philip A Portable security system
US7629880B2 (en) 2004-03-09 2009-12-08 Ingrid, Inc. System, method and device for detecting a siren
US8248226B2 (en) 2004-11-16 2012-08-21 Black & Decker Inc. System and method for monitoring security at a premises
US8041772B2 (en) * 2005-09-07 2011-10-18 International Business Machines Corporation Autonomic sensor network ecosystem
US20070249319A1 (en) * 2006-04-24 2007-10-25 Faulkner Mark A Power distribution communication system employing gateway including wired and wireless communication interfaces
US8065411B2 (en) * 2006-05-31 2011-11-22 Sap Ag System monitor for networks of nodes
US7971143B2 (en) 2006-10-31 2011-06-28 Microsoft Corporation Senseweb
US20080177683A1 (en) 2007-01-23 2008-07-24 No Brian Y Method and apparatus for mobile intelligence
US20090195382A1 (en) * 2008-01-31 2009-08-06 Sensormatic Electronics Corporation Video sensor and alarm system and method with object and event classification
WO2009111801A2 (en) * 2008-03-07 2009-09-11 Tendril Networks, Inc. Apparatus and method for dynamic licensing access to wireless network information
US20090273462A1 (en) * 2008-05-01 2009-11-05 Honeywell International Inc. Using fixed mobile convergence femtocells for alarm reporting
US9210220B2 (en) * 2008-09-29 2015-12-08 Andrew Steckley System and method for intelligent automated remote management of electromechanical devices
US9679449B2 (en) 2008-12-30 2017-06-13 Oneevent Technologies, Inc. Evacuation system
DE102009016154A1 (de) 2009-04-03 2010-10-14 Hekatron Vertriebs Gmbh Thermogeneratoranordnung, thermischer Schalter und Verfahren zum Betreiben einer elektrischen Vorrichtung
US8886206B2 (en) 2009-05-01 2014-11-11 Digimarc Corporation Methods and systems for content processing
US20110317007A1 (en) 2010-06-24 2011-12-29 Kim Ki-Il Smoke and carbon monoxide alarm device having a video camera
GB2483057B (en) * 2010-08-20 2012-11-28 Wireless Tech Solutions Llc Apparatus, method and system for managing data transmission
CN102487525A (zh) * 2010-12-02 2012-06-06 中国移动通信集团上海有限公司 告警信息传输方法、无线传感器节点设备、网关节点设备
US11750414B2 (en) 2010-12-16 2023-09-05 Icontrol Networks, Inc. Bidirectional security sensor communication for a premises security system
US8907799B2 (en) 2011-03-07 2014-12-09 Flamesniffer Pty Ltd Fire detection
US20130150686A1 (en) 2011-12-07 2013-06-13 PnP INNOVATIONS, INC Human Care Sentry System
US9477936B2 (en) 2012-02-09 2016-10-25 Rockwell Automation Technologies, Inc. Cloud-based operator interface for industrial automation
US9372213B2 (en) 2012-02-15 2016-06-21 Alpha and Omega, Inc. Sensors for electrical connectors
US8710983B2 (en) 2012-05-07 2014-04-29 Integrated Security Corporation Intelligent sensor network
US9046414B2 (en) 2012-09-21 2015-06-02 Google Inc. Selectable lens button for a hazard detector and method therefor
CN103685195A (zh) 2012-09-21 2014-03-26 华为技术有限公司 用户验证处理方法、用户设备和服务器
US8498864B1 (en) * 2012-09-27 2013-07-30 Google Inc. Methods and systems for predicting a text
US9064389B1 (en) * 2012-11-13 2015-06-23 e-Control Systems, Inc. Intelligent sensor for an automated inspection system
US10529215B2 (en) 2012-11-16 2020-01-07 Vapor Products Group, Llc Remote environmental condition monitoring and reporting
WO2014078960A1 (en) 2012-11-23 2014-05-30 Robin Johnston System and method for monitoring farm related equipment
US9262906B2 (en) 2013-03-14 2016-02-16 Comcast Cable Communications, Llc Processing sensor data
US9710251B2 (en) 2013-03-15 2017-07-18 Vivint, Inc. Software updates from a security control unit
US9123221B2 (en) 2013-05-20 2015-09-01 Apple Inc. Wireless device networks with smoke detection capabilities
WO2015009958A1 (en) 2013-07-18 2015-01-22 Google Inc. Systems and methods for detecting gesture events in a hazard detection system
US9685067B2 (en) 2013-10-31 2017-06-20 At&T Intellectual Property I, L.P. Machine-to-machine (M2M) emergency communications
JP6217757B2 (ja) 2013-11-15 2017-10-25 富士通株式会社 システム、通信ノード、および判断方法
US20150350303A1 (en) 2014-05-29 2015-12-03 Chia-I Lin Manufacturing optimization platform and method
US9741344B2 (en) 2014-10-20 2017-08-22 Vocalzoom Systems Ltd. System and method for operating devices using voice commands

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210203567A1 (en) * 2019-12-27 2021-07-01 Digital Guardian, LLC Systems and methods for investigating potential incidents across entities in networked environments
US11799736B2 (en) * 2019-12-27 2023-10-24 Digital Guardian Llc Systems and methods for investigating potential incidents across entities in networked environments
US11314563B1 (en) * 2021-03-18 2022-04-26 Citrix Systems, Inc. Context-based generation of activity feed notifications

Also Published As

Publication number Publication date
ES2646632R1 (es) 2018-03-13
US10592306B2 (en) 2020-03-17
MX2017004286A (es) 2017-06-26
GB2550476A (en) 2017-11-22
GB201704954D0 (en) 2017-05-10
ES2646632B2 (es) 2019-05-03
US20160098305A1 (en) 2016-04-07
WO2016049778A1 (en) 2016-04-07
GB2550476B (en) 2021-07-14
MX381752B (es) 2025-03-13

Similar Documents

Publication Publication Date Title
ES2646632B2 (es) Método y aparato para balancear recursos en una arquitectura de automatización y alarma
US10803720B2 (en) Intelligent smoke sensor with audio-video verification
US10397042B2 (en) Method and apparatus for automation and alarm architecture
US10242541B2 (en) Security and first-responder emergency lighting system
US11893880B2 (en) Enhanced emergency detection system
US9639098B2 (en) Thermostat and messaging device and methods thereof
JP6067836B2 (ja) 監視システム
US9721457B2 (en) Global positioning system equipped with hazard detector and a system for providing hazard alerts thereby
WO2017117674A1 (en) Intelligent smoke sensor with audio-video verification
JP2017506788A (ja) スマート非常出口表示
EP4154522A1 (en) Operating wireless devices and image data systems
AU2016228537A1 (en) Providing internet access through a property monitoring system
US20130325407A1 (en) Apparatus and method for sharing sensing information of portable device
JP2006279926A (ja) 無線通信装置、無線通信システム、無線通信方法、プログラム、およびそのプログラムを記録した記録媒体
US11176799B2 (en) Global positioning system equipped with hazard detector and a system for providing hazard alerts thereby
JP6934585B1 (ja) デバイスの向きに依存したセンサ信号の送信
US11361652B1 (en) Voice annunciated reminders and alerts
JP2018106356A (ja) 施設制御システム及び施設制御方法

Legal Events

Date Code Title Description
FG2A Definitive protection

Ref document number: 2646632

Country of ref document: ES

Kind code of ref document: B2

Effective date: 20190503

PC2A Transfer of patent

Owner name: JOHNSON CONTROLS TYCO IP HOLDINGS LLP

Effective date: 20260327