MX2013009644A - Motor de politicas personalizable. - Google Patents
Motor de politicas personalizable.Info
- Publication number
- MX2013009644A MX2013009644A MX2013009644A MX2013009644A MX2013009644A MX 2013009644 A MX2013009644 A MX 2013009644A MX 2013009644 A MX2013009644 A MX 2013009644A MX 2013009644 A MX2013009644 A MX 2013009644A MX 2013009644 A MX2013009644 A MX 2013009644A
- Authority
- MX
- Mexico
- Prior art keywords
- rule
- event
- policy
- subsystem
- action
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G08—SIGNALLING
- G08B—SIGNALLING OR CALLING SYSTEMS; ORDER TELEGRAPHS; ALARM SYSTEMS
- G08B21/00—Alarms responsive to a single specified undesired or abnormal condition and not otherwise provided for
- G08B21/02—Alarms for ensuring the safety of persons
- G08B21/10—Alarms for ensuring the safety of persons responsive to calamitous events, e.g. tornados or earthquakes
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/08—Insurance
-
- G—PHYSICS
- G08—SIGNALLING
- G08B—SIGNALLING OR CALLING SYSTEMS; ORDER TELEGRAPHS; ALARM SYSTEMS
- G08B27/00—Alarm systems in which the alarm condition is signalled from a central station to a plurality of substations
- G08B27/001—Signalling to an emergency team, e.g. firemen
-
- G—PHYSICS
- G08—SIGNALLING
- G08B—SIGNALLING OR CALLING SYSTEMS; ORDER TELEGRAPHS; ALARM SYSTEMS
- G08B27/00—Alarm systems in which the alarm condition is signalled from a central station to a plurality of substations
- G08B27/005—Alarm systems in which the alarm condition is signalled from a central station to a plurality of substations with transmission via computer network
Landscapes
- Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Emergency Management (AREA)
- Engineering & Computer Science (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Geology (AREA)
- General Life Sciences & Earth Sciences (AREA)
- Environmental & Geological Engineering (AREA)
- Life Sciences & Earth Sciences (AREA)
- Marketing (AREA)
- Economics (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- General Business, Economics & Management (AREA)
- Technology Law (AREA)
- Strategic Management (AREA)
- Theoretical Computer Science (AREA)
- Development Economics (AREA)
- Alarm Systems (AREA)
- Testing And Monitoring For Control Systems (AREA)
- Debugging And Monitoring (AREA)
- Combined Controls Of Internal Combustion Engines (AREA)
- Geophysics And Detection Of Objects (AREA)
- Emergency Alarm Devices (AREA)
- Computer And Data Communications (AREA)
Abstract
Las modalidades describen un sistema y método que distribuye alertas con una descripción de probabilidad de la severidad de condiciones de riesgo que producen la alerta y que incorporan un motor de políticas para expresar reglas para responder a la alerta.
Description
MOTOR DE POLITICAS PERSONALI ABLE
Campo de la Invención
Esta solicitud se refiere en general a sistemas y métodos para procesar datos de riesgo y datos de probabilidad para generar advertencias que pueden ser usadas para iniciar una respuesta de riesgo.
Antecedentes de la invención
Los Sistemas de Alerta Sísmica (SAS) dependen de la detección rápida y la caracterización de los movimientos de tierra sísmicos para proporcionar alertas anticipadas de temblores de riesgo. Debido a que el tiempo de alerta ofrecido por SAS es corto (de unos segundos) se pueden tomar muy pocas acciones que no hayan sido premeditadas anticipadamente del evento. Estas acciones por lo general fallan en dos categorías: automatizada, que significa que se accionan electrónica o electromecánicamente en respuesta a una señal electrónica; o mediadas por un humano, i.e., accionadas por la reacción de un humano que recibe una señal auditiva o visual. En general la señal auditiva/visual en la última categoría es por sí misma una acción automatizada iniciada en respuesta a una alerta electrónica.
Los SAS existentes por lo general emiten una alerta binaria ("riesgo" o "no riesgo"). Sin embargo, debido a que el costo de tomar cualquier acción no es cero, es importante
Ref. 243203
considerar, . para cada ventaja individual y cada acción separada, el beneficio potencial para tomar acción para un nivel dado de movimiento de tierra anticipado (intensidad) y una incertidumbre estimada dada en ese nivel. Este análisis puede realizarse en cualquier nivel deseado de sofisticación, pero requiere de que la alerta electrónica emitida por los SAS codifique tanto el nivel de movimiento de tierra anticipado como la incertidumbre estimada en ese nivel. Debido a que el tiempo es la esencia, esta información debe ser comunicada por los SAS como una forma tan compacta como sea posible.
La respuesta a una alerta de SAS puede abarcar tanto acciones mediadas por un humano como automatizadas. Las acciones automatizadas deben basarse en una política predeterminada que codifica lo que hay que hacer, y bajo qué condiciones de alerta. En la política más simple, la única condición es si la alerta binaria existe, y la acción que se va a tomar no varía de alerta a alerta. Una política más sofisticada puede codificar muchas acciones diferentes, que se van a tomar bajo varias condiciones de movimiento de tierra estimado y niveles de confidencia. En tal sistema sofisticado, incluso las respuestas mediadas por un humano son automatizadas al final porque se debe tomar una decisión anticipadamente sobre qué condiciones de alerta desencadenan la notificación de las personas que están mediando.
Por lo general hay un costo al tomar una acción en respuesta a una alerta sísmica. Este costo puede ser el impacto de productividad del personal que responde a una alerta o la disponibilidad de pérdida de equipo que se debe apagar. Puede haber costos de reinicio significativos para el equipo o los procesos que., han sido apagados. También hay un costo asociado con no tomar acciones para proteger a la gente y a los bienes. En muchos casos, la decisión de iniciar una respuesta a la alerta sísmica es un balance entre el costo esperado por daño y el costo por la acción de apagado.
Debido a que diferentes usuarios tendrán diferentes requerimientos de acciones que se deben tomar, y las condiciones bajo las cuales se deben iniciar esas acciones, és necesario un motor de políticas sofisticado para codificar las políticas deseadas del usuario y para implementarlas en caso de una alerta de los SAS .
Sumario de la Invención
Las modalidades de la presente invención se refieren a sistemas, métodos y dispositivos que contienen un motor de políticas personalizable que permite al cliente de la alerta sísmica establecer niveles de incertidumbre umbral y de movimiento de tierra de manera independiente de cada acción que el cliente desea considerar en el caso de un sismo. El motor de políticas permite que el consumidor éstablezca, de acuerdo con cualquier análisis que el cliente
elija realizar, tanto un nivel de intensidad como un nivel de confidencia por arriba del cual una acción debe tomarse. Las acciones diferentes puede asignárseles diferentes niveles de intensidad y de confidencia, y los múltiples niveles de confidencia e intensidad pueden ser asignados a la misma acción (por ejemplo, una menor intensidad pero mayor confianza puede desencadenar la misma acción que una mayor intensidad con menor confianza) .
Bajo este motor de políticas cualquiera, todas, o ninguna acción puede ser iniciada durante un evento que depende del nivel de movimiento de tierra anticipado y la incertidumbre en ese nivel. Si el valor de cualquiera de estas cantidades varía sobre la duración del evento, acciones diferentes pueden iniciarse en diferentes momentos, ya que sus umbrales predeterminados para la iniciación están cruzados. Si la información emergente acerca del evento lleva a la reducción en el nivel de confianza en el movimiento de tierra, las acciones ya iniciadas pueden terminarse o continuarse de acuerdo con las políticas condicionales predeterminadas.
El motor de políticas puede también incorporar información acerca del tiempo estimado de empiezo del movimiento de tierra de riesgo mediante los SAS, al decidir si iniciar las acciones o qué acción iniciar en un movimiento de tierra umbral dado.
El motor también acepta datos de entrada adicionales como es deseado para incorporarse a las decisiones de políticas. Por ejemplo el motor puede permitir iniciar acciones con base en movimientos de tierra de riesgo observados en el lugar en lugar de predecir los movimientos de tierra, para incorporar la información de conectividad de red en las decisiones de políticas, 'o para hacer un i
metaanálisis de los datos de alerta codificados, p.ej.,
I
velocidad de cambio de parámetros codificados como un criterio de políticas. El motor de políticas también puede i
aceptar umbrales condicionales con base en el estado de las ventajas de salud asumidas o conocidas después de un evento mayor, p.ej., reducir los movimientos de tierra umbral para las réplicas después de un sismo devastador.
í Además, todas las entradas registradas en el motor de políticas y las acciones iniciadas por el motor de políticas se registran en la memoria durante un evento y se escriben en medios estables o prácticos después de un evento, para propósitos de auditoría.
I
En algunas modalidades, se proporciona un sistema piara distribuir las alertas con respecto a un - evento. El s:istema incluye un subsistema de especificación de políticas para generar una o más políticas legibles por computadora, cjada política comprende al menos una regla y al menos una acción asociada con al menos una regla, en donde cada regla
incluye una pluralidad de parámetros de evento y una pluralidad asociada de probabilidades de parámetro de evento predeterminadas; un subsistema de detección de cambios para recibir y monitorear los datos desde un sistema de sensor, los datos incluyen valores de parámetro de evento esperados y mediciones de desviación asociadas; un subsistema de ejecución de políticas para ejecutar al menos una regla y desencadenar una acción con base en una comparación de los valores de parámetro de evento esperados y mediciones de desviación asociadas con las probabilidades de parámetro de evento predeterminadas al menos de una regla, en donde el subsistema de ejecución de políticas inicia el procesamiento al menos de una regla después de recibir instrucciones del subsistema de detección de cambios, en donde el subsistema de detección de cambios envía instrucciones al subsistema de e'jecución de políticas después de la detección de un cambio predeterminado en al menos uno de los valores de parámetro de evento esperado; y un ' subsistema de procesamiento de acciones í
para generar una salida para realizar al menos una acción desencadenada por el subsistema de ejecución de políticas.
En algunas modalidades, el sistema incluye además un subsistema de rastreo de origen que registra las operaciones de cada subsistema en los medios fijos para evaluación después de un evento.
En algunas modalidades, el subsistema ;de
I
especificación de políticas puede aceptar la entrada de un Usuario final o tercero o una combinación de usuario final y tercero para generar la política legible por computadora.
En algunas modalidades, al menos una regla comprende un predicado Boolean.
En algunas modalidades, al menos una regla comprende una regla vaga y al menos una acción comprende una función de acción continua.
En algunas modalidades, al menos una regla se expresa como una probabilidad de exceder un valor predeterminado de uno de la pluralidad de parámetros de evento .
En algunas modalidades, la probabilidad de exceder un valor predeterminado se calcula con base en una distribución Gaussian con un valor esperado predeterminado y una desviación.
En algunas modalidades, el subsistema de ejecución de políticas ejecuta al menos una regla en serie y resuelve los conflictos y las acciones de desencadenamiento con base en las reglas resueltas.
En algunas modalidades, el subsistema de procesamiento de acciones monitorea el desempeño de las acciones desencadenadas para verificar que las acciones hayan sido ejecutadas hasta su finalización.
En algunas modalidades, la alerta contiene un
resumen parametrizado del evento.
En algunas modalidades, el resumen parametrizado incluye una distribución de probabilidad para el cálculo de una distribución de probabilidad.
En algunas modalidades, la salida es producida de manera periódica con base en la detección de un cambio predeterminado en al menos uno de los valores de parámetro de evento esperados.
En algunas modalidades, la política comprende un predicado y una acción o una función continua de los parámetros de entrada y una salida de control que varía continuamente .
En algunas modalidades, el subsistema de especificación de políticas recibe información con respecto al estado de un dispositivo que recibe la salida del subsistema de procesamiento de acciones y modifica las políticas con base en el estado del dispositivo.
En algunas modalidades, el subsistema de políticas ajusta las reglas con base en los datos pasados.
En algunas modalidades, las reglas se actualizan en tiempo real.
En algunas modalidades, el subsistema de especificación de políticas comprende una pluralidad de interfaces de usuario personalizadas a un nivel experto de usuario que permite que el usuario personalice las reglas.
En algunas modalidades, la distribución de probabilidad representa la severidad del evento.
En algunas modalidades, la salida se envía a un altavoz o a una pantalla para generar un mensaje de alerta.
En algunas modalidades, la salida energiza un relé o controla la operación de una máquina, motor o turbina.
En algunas modalidades, el evento es un sismo y los parámetros de evento incluyen uno más de sacudidas de tierra máximas, aceleración de tierra máxima, velocidad de tierra máxima, desplazamiento de tierra máxima, intensidad Mercalli modificada, tiempo estimado de llegada de temblor de riesgo, y tiempo real de la llegada de ondas S. Estos parámetros describen el temblor anticipado en un lugar específico y puede incluir efectos locales (como condiciones de suelo) o no. Los parámetros también pueden describir mediciones reales de temblores de tierra en algún lugar remoto o en el lugar local. La diferencia en un pronóstico de intensidad de temblor y la medición de la intensidad de temblor se representan en la confianza del estimado de intensidad (un estimado basado en una medición tendrá más confianza alta tanto en valor esperado como en derivación estándar) ero aún involucra estimar la intensidad local con base en las mediciones remotas. Si las mediciones locales estuvieran disponibles, estas pueden tener mayor significado en las definiciones de políticas.
En algunas modalidades, a cada política se le asigna una prioridad.
En algunas modalidades, la prioridad se especifica a través del orden de definición, manualmente asignado por un Usuario, o cambiado por las acciones de una política.
¡ En algunas modalidades, las reglas pueden hacer referencia a estados de acción y a variables de sistema i
éxternas .
En algunas modalidades, se proporciona un método implementado por computadora para distribuir alertas con respecto a un evento. El método incluye generar una o más políticas legibles por computadora, cada política comprende ál menos una regla y al menos una acción asociada con al menos una regla, en donde cada regla incluye una pluralidad de parámetros de evento y una pluralidad asociada de probabilidades de parámetro de evento; recibir y monitorear datos de un sistema de sensor, los datos incluyen valores de p.arámetro de evento esperados y mediciones de desviación asociadas; iniciar el procesamiento al menos de una regla después de la detección de un cambio predeterminado en al mjenos uno de los valores de parámetro de evento esperado; ejecutar al menos una regla y desencadenar al menos una acción con base en una comparación de los valores de parámetro de evento esperados y mediciones de desviación asociadas con los parámetros de evento y las probabilidades
de parámetro de evento predeterminadas asociadas al menos de una regla; y generar una salida para realizar al menos una acción desencadenada por el subsistema de ejecución de políticas .
En, algunas modalidades, el método incluye además registrar las operaciones de cada subsistema a medios fijos para evaluación después de un evento.
En algunas modalidades, el método incluye además aceptar la entrada de un usuario final o tercero o una combinación de usuario final y tercero para generar la política legible por computadora.
En algunas modalidades, al menos una regla comprende un predicado Boolean.
En algunas modalidades, al menos una regla comprende una regla vaga y al menos una acción comprende una función de acción continua.
En algunas modalidades, al menos una regla se expresa como una probabilidad de exceder un valor predeterminado de uno de la pluralidad de parámetros de evento .
En algunas modalidades, la probabilidad de exceder un valor predeterminado se calcula con base en una distribución Gaussian con un valor y desviación esperados predeterminados .
En algunas modalidades, el método incluye además
ejecutar al menos una regla en serie y resolver conflictos y acciones de desencadenamiento con base en las reglas resueltas .
En algunas modalidades, el método incluye además monitorear el desempeño de las acciones desencadenadas para verificar que las acciones se hayan ejecutado hasta su finalización .
En algunas modalidades, las alertas contienen un resumen parametrizado del evento.
En algunas modalidades, el resumen parametrizado incluye una distribución de probabilidad o información para el cálculo de una distribución de probabilidad.
En algunas modalidades, la salida es producida de manera periódica con base en la detección de un cambio predeterminado en al menos uno de los valores de parámetro de evento esperado.
En algunas modalidades, la política comprende un predicado y una acción o una función continua de los parámetros de entrada y una salida de control que varía continuamente.
En algunas modalidades, el método incluye además recibir información con respecto al estado de un dispositivo que recibe la salida del subsistema de procesamiento de acciones y modifica la política con base en el estado del dispositivo.
En algunas modalidades, el método incluye además ajustar las reglas con base en los datos pasados.
En algunas modalidades, el método incluye además actualizar las reglas en tiempo real.
En algunas modalidades, el método incluye además personalizar las reglas usando una pluralidad de interfaces de usuario personalizadas para un nivel experto de usuario.
En algunas modalidades, la distribución de probabilidad representa la severidad del evento.
En algunas modalidades, el método incluye además enviar la salida a un altavoz o a una pantalla para generar un mensaje de alerta.
En algunas modalidades, el método incluye además enviar la salida para energizar un relé o controlar la operación de una máquina, motor o turbina.
En algunas modalidades, el evento es un sismo y los parámetros de evento incluyen uno o más de sacudidas de tierra máximas, aceleración de tierra máxima, velocidad de tierra máxima, desplazamiento de tierra máxima, intensidad Mercalli modificada, tiempo estimado de llegada de temblor de riesgo, y tiempo real de la llegada de ondas S.
En algunas modalidades, el método incluye además asignar una prioridad a cada política.
En algunas modalidades, la prioridad es especificada a través del orden de definición, manualmente
asignado por un usuario, o cambiado por las acciones de una política .
En algunas modalidades, las reglas pueden hacer referencia a los estados de acciones y las variables de sistema externas.
En algunas modalidades, se proporciona un dispositivo para distribuir alertas con respecto a un evento. El dispositivo incluye un procesador y memoria para almacenar instrucciones que cuando se ejecutan por el procesador provocan que el procesador: genere una o más políticas legibles por computadora, cada política comprende al menos una regla y al menos una acción asociada con al menos una regla, en donde cada regla incluye una pluralidad de parámetros de evento y una pluralidad asociada de probabilidad de parámetro de evento predeterminada; reciba y monitoreé datos de un sistema de sensor, los datos incluyen valores de parámetro de evento esperados y mediciones de desviación asociadas; inicie el procesamiento al menos de una regla después de la detección de un cambio predeterminado en al menos uno de los valores de parámetro de evento esperado; ejecute al menos una regla y desencadenar al menos una acción con base en una comparación de los valores de parámetro esperados y mediciones de desviación asociadas con los parámetros de evento y las probabilidades de parámetro de evento predeterminadas asociadas al menos de una regla; y
genere una salida para realizar al menos una acción desencadenada por el subsistema de ejecución de políticas. En álgunas modalidades, el dispositivo puede ser uno o más de computadoras o servidores.
En otras modalidades, algunas o todas las instrucciones descritas anteriormente y en la presente pueden implementarse en hardware como un circuito integrado de aplicación específica.
Breve Descripción de las Figuras
Las características novedosas de la invención se establecen en lo siguiente con particularidad en las reivindicaciones que siguen. Un mejor entendimiento de las características y ventajas de la presente invención será obtenido con referencia a la siguiente descripción detallada que establece las modalidades ilustrativas, en las que los principios de la invención se utilizan, y las figuras i
acompañantes en las cuales:
; La figura 1 es un diagrama de flujos de datos que ilustra el procesamiento de entradas y la generación de salidas de alerta.
: La figura 2 es una representación gráfica de una política hipotética.
La figura 3 es una representación de la djistribución de probabilidad de los movimientos de tierra estimados en un evento de ejemplo, que muestra la desviación
media y estándar del estimado.
La figura 4 es una representación de la probabilidad de exceder cualquier movimiento de tierra, superimpuesto en la política hipotética de la figura 2, que muestra acciones que se inician y acciones que no, con base en la curva de probabilidad de ejemplo.
La figura 5 es una ilustración de un ejemplo del flujo de datos a través del Motor de Políticas que muestra varias entradas, y las acciones de control que pueden definirse para una aplicación particular.
La figura 6 es una gráfica que ilustra la velocidad del ventilador como una función de la intensidad esperada de un sismo.
Descripción Detallada de la Invención
En algunas modalidades, un Motor de Políticas comprende cinco subsistemas funcionales: un subsistema de especificación de políticas 1, un subsistema de ejecución de políticas 4, un subsistema de detección de cambios 3, un subsistema de procesamiento de acciones 5, y un subsistema de rastreo de origen 6. Con referencia al diagrama de bloques en la figura 1. El subsistema de detección de cambios puede recibir datos de evento de tiempo real de un sistema de alerta sísmica 30, que recibe y procesa datos de un sensor sísmico 29, como se describe por ejemplo en la Solicitud de Patente Internacional No. PCT/US2011/065733, presentada el 19
de diciembre de 2011 y titulada "Sistema de Alerta Sísmica", que se incorpora en la presente por referencia. El subsistema de detección de cambios puede también recibir el estado local y los datos de entrada 31. Otros sensores sísmicos y otros sensores de riesgo también pueden ser adecuados. El subsistema de procesamiento de acciones genera salidas 32 que pueden enviarse a una variedad de dispositivos y sistemas como se describirá más adelante.
En algunas modalidades, el subsistema de especificación de políticas 1 puede implementarse en un Dispositivo de Alerta o en un servidor. En algunas modalidades, una aplicación con interfaz de usuario e importación de archivos (para especificación de políticas a base de texto) opera en un servidor de internet u otro entorno de aplicación (p. ej . , móvil), o en una computadora (de escritorio) y se comunica con el Dispositivo de Alerta ya sea directamente (USB) o a través de una conexión de internet. La compilación de políticas en la forma interna necesaria para el Dispositivo de Alerta o servidores se hace en la aplicación (para proporcionar retroalimentación inmediata al usuario) . El almacenamiento de las políticas (y sus representaciones internas) puede estar en una base de datos, archivo, o cualquier otra estructura de almacenamiento de datos adecuada, en el Dispositivo de Alerta o en un servidor.
1
En algunas modalidades, el subsistema de ejecución de políticas 4 también puede residir en el Dispositivo de Alerta o en un servidor. En algunas modalidades, el Dispositivo de Alerta es un dispositivo hardware autónomo que incluye salidas de control y características de confianza de información para comunicación. El dispositivo de alerta también puede ser otro dispositivo hardware aplicado, como un controlador industrial o computadora, que opera el software de Motor de Políticas. Salvo en casos en donde la salida de control, es un protocolo de software (como un mensaje de trampa SNMP) , el Dispositivo de Alerta tiene salidas físicas, como audio y/o contactos relé por ejemplo, usadas para comunicar la alerta a otros dispositivos para iniciar sus respuestas protectoras, como se describe más adelante.
! En algunas modalidades, el subsistema de detección de cambios 3 también puede residir en el Dispositivo de Alerta para iniciar la recomputación de las políticas que llevan a un control actualizado y salidas de alerta. Este subsistema recibe mensajes del Sistema de Alerta Sísmica (por medio de internet u otro sistema de comunicación de datos por ejjemplo) o mensajes de otras fuentes de información a cuyas salidas o estados se hace referencia en las políticas. Este subsistema también puede tener entradas físicas (digital, vbltaje, o corriente, etc.) que se usan para monitorear los estados o valores referenciados en las políticas (esto puede
incluir, por ejemplo, el estado operante de una máquina que se va a controlar, como la velocidad de ventilador mencionada en lo siguiente) .
En algunas modalidades, el subsistema de procesamiento de acciones 5 puede ser software que opera en el Dispositivo de Alerta que ejecuta acciones de políticas y maneja directamente salidas de control y alerta come se describe más adelante. Este software es responsable de manipular las salidas para producir la respuesta de control deseada en el equipo o sistema con interfaz en el Dispositivo de Alerta.
En algunas modalidades, el subsistema de rastreo de origen 6 puede ser software que opera en el Dispositivo de Alerta para monitorear la operación de otros subsistemas. También puede tener acceso a todas o algunas entradas (mensajes o sondeos) para que un registro completo de los estímulos y respuestas durante el periodo de alerta sísmica pueda ser registrado. Los datos de rastreo se escriben en almacenamiento no volátil (como FLASH) en el Dispositivo de Alerta y puede ser enviado a sistemas remotos (como un servidor) para archivos fuera de lugar. Un archivo de registro o de base de datos es un ejemplo de una manera en que los datos de rastreo pueden almacenarse, en donde la base de datos puede estar en un servidor y el archivo de registro puede escribirse en FLASH.
Políticas
Una política define una acción que se va a tomar bajo condiciones específicas. Cada política puede comprender üna regla y una acción asociada. Una regla puede describirse como un predicado Boolean o una función continua (referida como una regla vaga) . La acción puede tomar una o varias formas: asigna una variable de estado interno, inicia un proceso externo (como energizar un relé, empezar la transferencia continua de una alerta de audio, o enviar un mensaje) , inicia un proceso interno (como cambiar parámetros de operación del dispositivo) , o modifica el motor de políticas por sí misma (como hacer la transición a un estado mayor de alerta en el que las políticas pueden ser diferentes), o cualquier combinación de estas.
1 Un predicado es una regla Boolean que, cuando cambia su valor, provoca algunas acciones específicas o acciones que se van a realizar. El predicado es una expresión ajrbitraria de variables de entrada y estado. Una regla vaga se usa para expresar un intervalo de respuestas posibles. Por i
ejemplo, la velocidad de una máquina rotatoria puede ser rjeducida durante eventos pequeños y eventualmente detenida durante eventos largos. Un área de nombre define entradas i
disponibles para reglas y salidas para acciones.
Especificación de políticas
El subsistema de especificación de políticas 1
acepta las definiciones de políticas en formas legibles para los humanos y las convierte en una forma interna usada por el subsistema de ejecución de políticas 4. Las políticas pueden ser capturadas en diferentes representaciones incluyendo afirmaciones en un lenguaje formal, documentos XML, diagramas gráficos, u otras formas.
Algunos ejemplos típicos incluyen:
Si (predicate_specification) entonces action_specification continuous_funetion ( fuzzy_specification)
<policy>
<predicate>predicate_specification</predicate> <action>action_specification</action>
</policy>
<policy>
<fuzzy>fuzzy_specification</fuzzy>
<action>action_specificátion</action>
</policy>
En el ejemplo proporcionado arriba,
"predicate_specification" es una expresión Boolean. La modalidad preferida usa la siguiente gramática de expresiones generales :
expression : := simpleExpression ( relationalOp simpleExpression )? relationalOp ::= '<· | '<=' | 1 !=' | '>'
simpleExpression : := term ( addOperator simpleExpression )?
addOperator ::= '+' | ' - ' | ' or' | ' | | '
term : : = factor ( factor mulCperator term ) ?
mulCperator : := '*' | '/' I 'div' I 'mod' | 'and' | '&&'
factor := literalConstant | variable | function |
unaryOperator factor | 1 ( 1 expression' ) '
UnaryOperator ::= '+' | '-' | ' not '
literalConstant ::= integerLiteral | realLiteral | stringLiteral integerLiteral : := [0-9]+
eralLiteral : : = integerLiteral |
integerLiteral ( ' .1 integerLiteral ) ? ' E 1 scaleFactor scaleFactor : := [+-]? integerLiteral
stringLiteral : = ' ' ' ' any_printing_character_or_escaped_quote+ ' ' 1 ' variable : : = simpleVariable | compoundVariable
simpleVariable : := identifier
identifier : := [a-zA-Z] [a-zA-ZO-9* ]
compoundVariable : := simpleVariable ( '.' propertyOrFunction )+ propertyOrFunction : := identifier ( ' ( ' expression ) ? ' ) 1 ) ?
Área de Nombre de regla
El área de nombre de regla contiene un objeto, evento, que contienen todos los parámetros de evento como son reportados por los SAS u obtenidos a través de mediciones locales. El objeto de evento tiene los siguientes objetos subordinados :
event.jerk - sacudimiento de tierra máximo (banda ancha o en una banda de frecuencia designada)
event . acceleration - aceleración de tierra máxima
(banda ancha o en una banda de frecuencia designada)
event . velocity - velocidad de tierra máxima (banda ancha o en una banda de frecuencia designada)
event . displacement - desplazamiento de tierra máximo (banda ancha o en una banda de frecuencia designada) event. mmi - Intensidad Mercalli Modificada o
Intensidad Instrumental, definida internamente como una función de event-jerk, event . acceleration, event . elocity y event . displacement
: event. eta - tiempo estimado en segundos hasta la llegada de temblor de riesgo
\ event. toa - tiempo real (detectado) de la llegada de ondas S.
' Cada uno de los objetos físicos (mmi, sacudimiento, aceleración, velocidad, y desplazamiento) tiene los skguientes métodos:
; poe (nivel, [banda] ) - regresa la probabilidad de eixceder el nivel específico en banda específica o banda ancha roe ( [banda] ) - regresa la velocidad de cambio de u'na propiedad en una banda específica o banda ancha
El objeto eta también tiene un método roe ( ) .
Cada uno de los objetos subordinados event tiene lps siguientes objetos de serie de datos que son vectores ensamblados por el Motor de Políticas de los datos enviados pbr los SAS en mensajes de actualización de alerta:
ev - una serie de tiempos de valores esperados como fueron reportados por los SAS en una serie de actualizaciones .
dev - una serie de tiempos de desviaciones estándar como fueron reportadas por los SAS en una serie de actualizaciones .
obs - una serie de tiempos de tiempos de observación de ev y dev.
Estos objetos de serie de datos tienen las siguientes propiedades y métodos:
num - número de elementos en la serie de tiempos. latest - el último valor recibido en una actualización de SAS.
mean - la media de los valores recibidos. roe ( ) - velocidad de cambio de los datos.
En algunas modalidades, los datos num, latest, mean, y roe ( ) pueden ser proporcionados por un servidor remoto en lugar de uno derivado de un historial local (i.e., descargado al servidor) .
Algunos ejemplos del uso de estos objetos en una expresión de predicado:
/* probabilidad de que PGV exceda 70cm/s es mayor que 50%*/ event . velocity . poe (70) > 0.5
/* probabilidad de que PGA en 3.0Hz de banda exceda 0.7cm/s es mayor que o igual que 65%*/
évent . acceleration . poe (0.7, 3.0) >= 0.65
* probabilidad de que PGA exceda 120 cm/s/s o velocidad que exceda 450 cm/s > 50%*/
event . acceleration . poe (120) > 0.5 o event . velocity . poe (450) ^ 0.5
Otras maneras equivalentes de expresar estas expresiones también puede proporcionarse como requeridas para ayudar a los usuarios a expresar sus intenciones.
! La figura 2 muestra la representación gráfica de una política hipotética. La política está compuesta por tres reglas :
1. si event . acceleration . poe (3.16)>=0.8 entonces áction_A ver (7)
2. si event . acceleration . poe (31.6)>=0.6 entonces action_B ver (8)
3. si event . acceleration . poe (100)>=0.1 entonces ajction_C ver (9)
I En cualquier evento, cualquier número de estas acciones puede iniciarse dependiendo de la combinación de la intensidad estimada de temblor y la incertidumbre en el estimado.
La velocidad de cambio puede ser aplicada a cualquier variable o entrada. Los operadores trabajan en toda ciase de entradas.
i La prioridad de políticas se especifica a través
del orden de definición. La prioridad manual también puede ser asignada. Las prioridades pueden ser cambiadas por las acciones de una política (elevar algunas políticas con base en políticas previas que se desencadenan) .
Las reglas pueden hacer referencia a la historia pasada (útil, por ejemplo, para reducir el umbral para acción una vez que un evento largo ha ocurrido bajo la suposición de que el daño ha incrementado las vulnerabilidades) . La historia pasada que incluye datos pasados y datos históricos puede almacenarse en una base de datos a la cual se puede tener acceso por el subsistema de especificación de políticas d cualquier otro subsistema. Además, los datos de tiempo real pueden ser añadidos a la base de datos para que la base de datos se actualice.
Las reglas pueden hacer referencia a variables de sistema en el sistema que implementa el Motor de Políticas. Esta área de nombre puede extenderse al añadir nombres de otras áreas de nombre junto con funciones de acceso y monitoreo .
Las reglas pueden hacer referencia a los estados de acción (lo que ya ha sido iniciado) y a las variables de sistema externas (como interruptores y datos importados) .
Una política también puede describir una función continua utilizando una regla vaga. Esta regla define una relación entre una variable de control de salida (como una
velocidad de ventilador) y la intensidad de temblor esperada. Tal regla se muestra en la figura 6. En este ejemplo, la velocidad de ventilador se reduce gradualmente a cero a medida que la intensidad esperada va hacia MMI IX. Este enfoque balancea el riesgo de daño con beneficios de la operación continuada. La definición de política para esto podría ser:
si ( expected_mmi<6 entonces fan_speed=normal ;
si (expected_mmi>9 entonces fan_speed=apagada;
si (expected_mmi>=6 entonces fan_speed=normal* ( 9-expected_value) /3
Esto se vuelve vago porque la verdad de la expresión "expected_mmi<6" no es binaria, pero se proporciona como una probabilidad de excedencia.
Subsistema de detección de cambios
El subsistema de detección de cambios 3 monitores " todas las variables para los cambios como mensajes que se reciben desde el sistema de análisis de sensor local o desde sistemas remotos. Cuando llegan nuevos datos, si cualquiera de los valores cambia, el subsistema de ejecución de reglas es notificado para procesar sus reglas. Esto permite que las reglas se actualicen tan pronto como las condiciones cambian para que las acciones puedan ser iniciadas rápidamente. El subsistema de detección de cambios monitorea todas las variables que son referenciadas por las reglas existentes,
informando al subsistema de ejecución de reglas que un cambio ha ocurrido solamente para esas variables. Los cambios en las yariables que no afectan a las reglas existentes no provocan que el subsistema de ejecución de reglas sea invocado. En algunas modalidades, el sistema de detección de cambios puede ser agnóstico en cuando a la magnitud de cambio, pero cada regla puede ser escrita para solamente considerar un cierto nivel de cambio significativo suficiente para actuar en la misma .
, Por ejemplo, . en algunas modalidades, los datos nuevos llegan en el subsistema de detección de cambios a través de mensajes o monitoreo de entrada. En el caso de un mensaje o evento de algún tipo, como un mensaje de actualización, el cambio puede ser cuantificado- en tiempo debido a la naturaleza del mensaje, que proporciona una muestra de la entrada en algún tiempo distinto. Cuando un mensaje nuevo llega, si el valor de la entrada es diferente ají valor recibido previamente, entonces las políticas que asan ese valor se actualizan y/o recomputan.
En el. caso de una entrada monitoreada o sondeada, l|a entrada puede ser ruidosa. En algunas modalidades, un intervalo de sondeo puede usarse para cuantificar (en tiempo) el impacto de los cambios en la misma manera que los mensajes de entrada mencionados arriba. En algunas modalidades, el sondeo que usa un enfoque de limitación de velocidad se logra
i
al muestrear los datos en un intervalo de tiempo predeterminado o en puntos predeterminados de tiempo. El muestreo de entrada es por lo general periódico, como una vez por segundo o más o menos gue una vez por segundo, y esta periodicidad limita qué tan frecuente la entrada puede tener un efecto sin importar qué tan ruidosos son los datos. Además o de manera alterna, el filtrado de entrada (como un filtro de paso bajo) , y los umbrales mínimos para iniciar un cambio también pueden usarse. En algunas modalidades, el filtrado de paso bajo o paso de banda puede usarse para reducir el ruido en una entrada. Por ejemplo, si se espera que una entrada cambie no tan frecuentemente como una vez un segundo, un filtro de paso bajo de 1Hz reducirá o filtrará los cambios que ocurran con más frecuencia. En algunas modalidades, una histéresis también puede ser especificada para reducir el efecto de una entrada ruidosa y evitar las detecciones de cambio falsas, en este contexto, la histéresis se refiere a un umbral que es mayor cuando la entrada se incrementa y menor cuando se reduce, lo que crea una banda muerta entre los dos umbrales que evita que los cambios pequeños provoquen cambios de salida. En algunas modalidades, tanto la limitación de velocidad como la histéresis pueden ser usados. En otras modalidades, las combinaciones diferentes de las técnica anteriores de procesamiento de datos ruidosos pueden Usarse.
La figura 3 muestra una distribución de probabilidad de la intensidad estimada para un evento de ejemplo. Esto representa un panorama en tiempo; el estimado cambiará y se actualizará con el tiempo. El subsistema de detección de cambios identificará estos cambios. En la figura 3, la curva representa la probabilidad de un nivel dado de aceleración de tierra máxima y sigue la forma de una distribución Gaussian (normal) . Ésta es la modalidad preferida de la distribución de probabilidad, pero hay otras que pueden ser posibles. El valor esperado del movimiento de tierra se representa por la media 10 de la distribución de probabilidad en la modalidad preferida. En la modalidad preferida la incertidumbre en el movimiento de tierra estimado se representa por la desviación estándar 11 de la distribución de probabilidad. Hay otras mediciones que son posibles, como el ancho completo en la mitad máxima 12 o 95% de intervalo de confianza 13. Los SAS comunican la medición de valor esperada y la medición de desviación al motor de políticas en tiempo real, y el valor de estas mediciones es monitoreado por el subsistema de detección de cambios. Cuando el valor esperado o la desviación cambia, el un sjistema de ejecución de reglas es notificado para procesar sus reglas.
Slubsistema de ejecución de políticas
El subsistema de ejecución de políticas 4 procesa
las políticas y desencadena acciones como se indica. Las políticas pueden desencadenar acciones que son contradictorias. Para detectar esto, todas las acciones se agregan y los conflictos se resuelven antes de pasar los eventos de acción al sistema de procesamiento de acciones 5.
El procesamiento de políticas ocurre cada vez que hay un cambio en cualquier entrada referenciada por cualquier política. Esto solamente es afectado por la especificación de delimitación de velocidad. Las actualizaciones de control vago pueden ser restringidas adicionalmente para cambiar solamente cuando el cambio exceda algún umbral. En algunas modalidades, esto puede ser manejado en el subsistema de cambio al cuantificar las entradas ya sea en tiempo (limitación de velocidad) o valor (a través de umbrales de cambio o filtrado) . La histéresis, como se describe de manera similar arriba, también puede ser especificada en el subsistema de ejecución de políticas para que cualquier salida de control evite cambios pequeños en las entradas de políticas que provoquen que el control cambie de estado.
Especificaciones de regla
Cada regla es procesada al evaluar los métodos de definidos establecidos en la Especificación de Políticas y se comparan con el valor umbral en la expresión de predicado. Las formas funcionales de los métodos incorporados en la modalidad preferida son:
real prob = poe(real level, optional real band) {
(real ev, real dev, real time) = get_metrics (1, band) ;
prob = probability_function(ev, dev, level);
}
real rate = roc(int W, optional real band) {
/* W = desired window length for rate calculations */ (real* ev, real* dev, real* time) = get_metrics (W, band); rate = rate_function(ev, dev, time);
}
(real* ev, real* dev, real* time) = getjmetrics (int window, real band) {
for int J=l:window {
int sample = [most recent sample] — J + 1;
If (band = 0) {
(ev(J), real maxband) = max ( [expected valué] (sample));
dev(J) = [deviation] (sample) (maxband);
} else {
ev(J) = [expected valué] (sample) (band) ;
dev(J) = [deviation] (sample) (band) ;
}
time(J) = [observation time] (sample) ;
}
}
La función probability_function toma tres argumentos:
valor esperado: el valor más probable del objeto como es determinado por los SAS . En la modalidad preferida, expresado como una media aritmética. Otras expresiones son posibles .
: desviación: una expresión de la incertidumbre en la medición, como es determinado por los SAS. En la modalidad preferida, expresada como una desviación estándar. También puede ser expresada como varianza, ancho completo en mitad máxima, o 95% de intervalo de confianza. Otras expresiones son posibles.
nivel: el valor umbral deseado para el objeto, en e'l cual la probabilidad de excedencia se calcula.
; La función regresa la probabilidad de excedencia, utilizando una de las siguientes técnicas:
; función: cualguier función continua como una función de distribución acumulativa que es definida por sobre todos los valores posibles de nivel. En la modalidad pireferida, la función de distribución acumulativa de una distribución normal:
P{ntvei)s— 1+erff nível^v
, en donde el nivel es expresado en forma lineal o logarítmica. Otras funciones son posibles. Una distribución Cauchy sigue la forma
mientras que una distribución Laplace sigue forma
P(n¡vel)= 1 1+S0n{nlveí-ev)il-e
tabla: una tabla de búsqueda de probabilidades y niveles definida por sobre todos los valores posibles de nivel .
Ejemplo:
Este ejemplo es equivalente a un caso degenerado e,l que el valor esperado es considerado como exacto (i. dev (desviación) = 0) . Un ejemplo más genérico podría ser:
que es una aproximación de una distribución con media de 3.5 y desviación estándar de 1.
tabla interpolada: similar a la técnica de tabla, los valores esperados del nivel entre los valores en la tabla son interpolados. Ejemplo:
Otras técnicas son posibles.
La función rate_function toma tres argumentos de grupo:
grupo de valor esperado: un grupo al menos de mediciones de valor esperado W de los SAS.
grupo de desviación: un grupo al menos de mediciones de desviación W de los SAS.
grupo de tiempo: un grupo de tiempos en el que los
SAS generaron las mediciones anteriores.
La función regresa la velocidad de cambio del objeto con base en los valores de los argumentos.
La figura 4 muestra la probabilidad de la función de excedencia para el evento de ejemplo mostrado en la figura 3. La curva es la función de distribución acumulativa Gaussian en la figura 3, la política hipotética de la figura 2 es superimpuesta en esta curva. La curva representa el valor de regreso en el eje y de event . acceleration . poe para los valores de entrada a lo largo del eje x. En esta representación, cualquier regla que caiga a la izquierda de la curva se ejecuta y se traza como círculos, mientras que las reglas que caen a la derecha no se ejecutan y se trazan como diamantes. Si se usa el ejemplo de la política hipotética de la figura 2:
1. event . acceleration . poe (3.16)= 0.97, por lo tanto action_A se inicia (ver 14)
2. event . acceleration . poe (31.6)= 0.5, por lo tanto action_B no se inicia (ver 15)
3. event . acceleration . poe (100)= 0.15, por lo tanto action_C se inicia (ver 16)
Como el valor esperado y las mediciones de desviación se actualizan, estas reglas se vuelven a evaluar.
Las acciones que no se inicia en la figura 4 pueden iniciarse de manera subsecuente cuando hay información nueva
disponible. De igual manera, las acciones que se inician en la figura 4 pueden realizarse de manera subsecuente, o puede que se les permita proceder dependiendo de la definición de acción (ver lo siguiente) .
Subsistema de procesamiento de acciones
El subsistema de procesamiento de acciones 5 es responsable de realizar las acciones desencadenadas por el subsistema de ejecución de políticas 4. Muchas de estas acciones requieren de monitoreo sostenido, como el paso continuo de un mensaje de alerta audio o el equipo de control que requiere de una interfaz multietapa. El subsistema de procesamiento de acciones es responsable de asegurar que todas las acciones iniciadas se completen. El subsistema de ejecución de reglas puede iniciar acciones subsecuentes que cancelan acciones previas. Un ejemplo es un mensaje de alerta de audio de paso continuo que puede reemplazarse por un mensaje más urgente si el temblor estimado incrementa en mayor medida. El subsistema de procesamiento de acciones es responsable de finalizar el paso continuo del mensaje previo y de empezar uno nuevo.
Una acción puede ser una función continua de parámetros de entrada.
Un ejemplo de acción continua: mantener una velocidad de la máquina para las intensidades estimadas siguientes MMI VI. En MMI VI se empieza a disminuir la
velocidad de la máquina hasta que la máquina opera a media velocidad en MMI VIII. Si la intensidad es mayor a MMI VII, se apaga la máquina. La máquina puede ser un ventilador de ventilación que debe mantenerse operando tan seguido como sea posible, pero puede dañarse si se opera durante el temblor de alta intensidad.
Las acciones pueden limitarse en velocidad para evitar iniciarlas muy rápido si las entradas se cambian rápidamente.
La histéresis puede ser especificada.
Las acciones pueden ser biestables; una vez que se desencadenan no pueden volverse a desencadenar sin una restauración explícita.
I
Las acciones pueden empezar, detenerse, volverse a desencadenar, y detener operaciones.
Las acciones pueden operar secuencias de comandos locales .
¡ Las acciones pueden establecer variables locales que se van a utilizar mediante otras políticas.
Las acciones pueden enviar datos a los dispositivos r¡emotos .
Cada acción describe lo que se debe hacer y completar la tarea. Algunos ejemplos:
/i* encender un relé durante 1 segundo, luego apagarlo */ set relay on for 1 second then off
/* pasar una alerta de audio que comprende un sonido de claxon y un mensaje de voz, repetir hasta detener */
loop (play (Klaxon_sound) ; play (voice_message ) ) until reset
Cada definición de acción también incluye lo que se debe hacer para desencadenarla o finalizarla. Un ejemplo de acción que va a abrir una puerta puede ser definida de la siguiente manera:
open_door {
start: set relay_l on for 1 second then off;
retrigger: set relay_l on for 1 second then off; stop: set relay_l off;
}
En algunas modalidades, esta es otra manera de manejar las consecuencias de los cambios de entrada que podrían provocar que un control se encienda/apague/encienda. Una acción puede definirse de manera que, una vez iniciada, la única manera de apagarse es una condición de restauración separada (como una entrada manual o un temporizador ) . Esto también reduce las consecuencias de las entradas ruidosas. Por ejemplo, una vez que está sobre el umbral, la acción puede empezarse y las entradas pueden ignorarse hasta que se satisface la condición de restauración, como esperar durante un periodo predeterminado de tiempo.
Una acción para pasar un mensaje de alerta de audio podría ser definido como sigue:
audio_alert {
start : loop ( play ( klaxon_sound ) ; play ( voice_message ) ) until stop;
retrigger : ;
5 j stop:;
}
Estas definiciones pueden sustituirse con un lenguaje formal, formato XML, u otras representaciones. La modalidad preferida usa la siguiente sintaxis (EBNF) :
]_0 action_definitions ::= action ñame ('(' ( parameter )+ ')' )?'{'(
áction_spec ) + 1 } '
action_ ñame : : = identifier
parameter : := identifier
action_spec : := start_spec | retrigger_spec | stop_spec'
^ ^ start_spec : : = ' start ' 1 : 1 compound_statement ' ; '
retrigger_spec : = ' retrigger" : ' compound_statement ' ; '
stop_spec : : = ' stop" : ' compound_statement 1 ; 1
compound_statement : : = statement | statementjolock
statement_block ::= '{' ( statement ) + ' } '
2Q Statement : := set_statement | loop_statement | function _statement
set_statement : = ' set ' variable ' = ' valué ( ' for 1 duration ( ' then ' v^lue )? )?
valué : : = boolean | integer | real | string
boolean : : = On 1 | ' off | ' true ' | ' false '
c duration ::= float
loop_statement : := 'loop' statement_block 'until' condition
condition : : = expression
function_statement : : = function_name ' ( ' ( parameter ) * ' ) '
function_name : := identifier
Las funciones pueden ser definidas dentro del Motor de Políticas o puede hacerse referencia a los procedimientos externos ya sea al ejecutar programas en el entorno local, utilizando llamadas de procedimiento remotas, o algunos métodos similares. Por" ejemplo:
script ( bash, "snmptrap server -p alert 0 0 6")
i ejecuta el comando "snmtrap server -p 0 0 6" utilizando los guiones de intérprete Bash.
Subsistema de rastreo de origen
Todas las operaciones del Motor de Políticas se registran usando el subsistema de rastreo de origen 6 para que el comportamiento del sistema pueda ser examinado por último para evaluara su desempeño y proporcionar un rastro de auditoría para controlar la toma de acciones. Esta información es útil para actualizar las reglas y para validar la operación del sistema.
En algunas modalidades, todos o algunos de los subsistemas mencionados arriba están integrados a una sola aplicación. En otras modalidades, algunos o todos los s,ubsistemas operan como procesos independientes o cómo
I
amenazas. Todas las particiones de sistema están incluidas en
esta descripción.
Entradas de políticas
Las políticas pueden operar en información paramétrica proporcionada por los SAS, como se representa en el objeto de evento (ver arriba) . Las políticas también pueden generar el estado local que se puede usar mediante otras políticas. Las políticas también pueden monitorear variables externas, como estado de equipo de tiempo real. Éstas se ilustran en la figura 5.
Múltiples políticas
La figura 5 muestra un ejemplo del flujo de datos a través del Motor de Políticas. Las entradas (17-19) alimentan las políticas (20-25) que inician varias acciones de control (26-28) para varias condiciones. Debe observarse que varias políticas pueden iniciar la misma respuesta de acción. Por ej emplo :
si event . mmi . poe (9)>= 0.8 entonces initiate_action_l --política 1
si event . mmi . poe (9)>= 0.5 y unsafe_condition == verdad entonces initiate_action_l
--política 2
si event . mmi . poe (7)>= 0.8 y vulnerable_condition =;= verdad entonces initiate_action_l
--política 3
En operaciones normales el equipo podrá aguantar
temblores muy fuertes sin daño, por lo tanto no se inicia el apagado a menos que el temblor violento se espere con alta confianza (política 1). Sin embargo, si el equipo está en un estado muy poco seguro (como interactuando con un operador) se inicia el apagado en niveles de confianza más bajos (política 2), debido a que la falla es probable que provoque lesiones al personal expuesto y el costo asociado es mayor. Si el equipo está en una condición de muy alta vulnerabilidad (¡como en algún modo de operación, como en autocalibración) , se inicia el apagado en un nivel más bajo de temblor esperado (¡política 3) .
Resolución de conflicto de políticas
Cuando las múltiples políticas controlan las mismas acciones, los conflictos de control pueden surgir. En el ejemplo anterior, las políticas definen diferentes umbrales p!ara iniciar una acción. Un OR simple de reglas de salida es suficiente. En escenarios más complejos, un enfoque más siofisticado es necesario, se tomará el ejemplo de un tren de conmutador. La desaceleración normal puede ralentizar el tren aj 3.5 km/hr/s y la desaceleración de emergencia puede ralentizarlo a 5 km/hr/s. El objetivo es reducir la velocidad d!el tren lo suficiente como para evitar descarrilamientos. La desaceleración de emergencia del tren eleva la probabilidad dje lesiones de los pasajeros, por lo que la desaceleración normal es la elección por defecto. Sin embargo, si el tiempo
necesario para ralentizar el tren es mayor que el tiempo hasta la llegada de las ondas de choque, se busca la desaceleración de emergencia. Las políticas podrían ser las siguientes :
si event .mmi . poe (7)>= 0.5 entonces desacelerar (normal )
--política 1
si event . mmi . eta ()<( current_velocity - safe velocity )/3.5 entonces desacelerar (emergencia)
—política 2
Las variables usadas en las reglas son ya sea parámetros en 'tiempo real del sistema que se va a controlar (current_velocity) o constantes predefinidas ( safe_velocity) . Estas dos políticas están en conflicto ya que le piden al tren que desacelere en diferentes velocidades. Una política de precedencia puede definirse para que dirija la respuesta adecuada :
precedencia : desacelerar ( emergencia>normal )
O puede inferirse la precedencia del orden en que las políticas se especificaron. 0 cada política puede marcarse con una precedencia explícita.
Captura de política de usuario- i El lenguaje detallado y la especificación discutida arriba permite a un experto expresar reglas flexibles y sofisticadas para políticas de alerta. Este nivel de detalle njo es necesario para todos los usuarios. Cualquier número de i
métodos más simples de políticas de captura pueden implementarse y representan al usuario final con. un conjunto más simple de elecciones. Estos se mapean en las' especificaciones de reglas subyacentes automáticamente. Entre los métodos se encuentran:
; Seleccionar de plantillas predefinidas personalizadas para aplicaciones particulares.
Proporcionar un método gráfico para políticas de especificación.
Mostrar una simulación de respuesta de Motor de
Políticas para permitir los refinamientos de políticas.
Las variaciones y modificaciones de los dispositivos y métodos descritos en la presente serán aparentes para las personas expertas en la técnica. Como tal, debe entenderse que la descripción detallada anterior y las j
ilustraciones acompañantes, están hechas con propósitos de claridad y entendimiento, no se pretende que limiten el alcance de la invención, que es definida por las reivindicaciones anexas en la presente. Cualquier característica descrita en cualquier modalidad descrita en la presente puede combinarse con cualquier otra característica i
de cualquier otra modalidad ya sea que se prefiera o no.
Se entiende que los ejemplos y las modalidades descritas en la presente son para propósitos ilustrativos solamente y que varias modificaciones o cambios en luz de las
mismas serán sugeridas a las personas expertas en la técnica que se deben incluir dentro del espíritu y alcance de esta solicitud y alcance de las reivindicaciones anexas. Todas las publicaciones, patentes y solicitudes de patente citadas en la presente se incorporan en la presente por referencia para todos los propósitos.
Se hace constar que con relación a esta fecha, el mejor método conocido por la solicitante para llevar a la práctica la citada invención, es el que resulta claro de la presente descripción de la invención.
Claims (49)
1. Un sistema para distribuir alertas con respecto a un evento, caracterizado porque comprende: un subsistema de especificación de políticas para generar una o más políticas legibles por computadora, cada política comprende al menos una regla y al menos una acción asociada con al menos una regla, en donde cada regla incluye una pluralidad de parámetros de evento y una pluralidad asociada de probabilidades de parámetro de evento predeterminadas ; un subsistema de detección de cambios para recibir y monitorear los datos desde un sistema de sensor, los datos incluyen valores de parámetro de evento esperados y mediciones de desviación asociadas; un subsistema de ejecución de políticas para ejecutar al menos una regla y desencadenar una acción con base en una comparación de los valores de parámetro de evento esperados y mediciones de desviación asociadas con las probabilidades de parámetro de evento predeterminadas al menos de una regla, en donde el subsistema de ejecución de políticas inicia "el procesamiento al menos de una regla después de recibir instrucciones del subsistema de detección de cambios, en donde el subsistema de detección de cambios envía instrucciones al subsistema de ejecución de políticas después de la detección de un cambio predeterminado en al menos uno de los valores de parámetro de evento esperado; y un subsistema de procesamiento de acciones para generar una salida para realizar al menos una acción desencadenada por el subsistema de ejecución de políticas.
2. El sistema de conformidad con la reivindicación lf caracterizado porque comprende además un subsistema de rastreo de origen que registra las operaciones de cada subsistema en los medios fijos para evaluación después de un evento .
3. El sistema de conformidad con la reivindicación 1 ó 2, caracterizado porque el subsistema de especificación de políticas puede aceptar la entrada de un usuario final o tercero o una combinación de usuario final y tercero para generar la política legible por computadora.
4. El sistema de conformidad con cualquiera de las reivindicaciones precedentes, caracterizado porque al menos una regla comprende un predicado Boolean.
5. El sistema de conformidad con las reivindicaciones 1-3, caracterizado porque al menos una regla comprende una regla vaga y al menos una acción comprende una función de acción continua. i
¡ 6. El sistema de conformidad con la reivindicación 4 ó 5, caracterizado porque al menos una regla se expresa como una probabilidad de exceder un valor predeterminado de u'no de la pluralidad de parámetros de evento. ¡
7. El sistema de conformidad con la reivindicación 6, caracterizado porque la probabilidad de exceder un valor predeterminado se calcula con base en una distribución aussian con un valor esperado predeterminado y una desviación . j 8. El sistema de conformidad con cualquiera de las
I reivindicaciones precedentes, caracterizado porque el subsistema de ejecución de políticas ejecuta al menos una í regla en serie y resuelve los conflictos y las acciones de ckesencadenamiento con base en las reglas resueltas. í
9. El sistema de conformidad con cualquiera de las reivindicaciones precedentes, caracterizado porque el de procesamiento de acciones monitorea : el de las acciones desencadenadas para verificar que : es hayan sido ejecutadas hasta su finalización.
! 10. El sistema de conformidad con cualquiera de las i reivindicaciones precedentes, caracterizado porque la alerta contiene un resumen parametrizado del evento.
I j 11. El sistema de conformidad con la reivindicación 10, caracterizado porque el resumen parametrizado incluye una ¡distribución de probabilidad para el cálculo de una ¿listribución de probabilidad.
12. El sistema de conformidad con cualquiera de las reivindicaciones precedentes, caracterizado porque la salida és producida de manera periódica con base en la detección de n cambio predeterminado en al menos uno de los valores de parámetro de evento esperados .
13. El sistema de conformidad con cualquiera de las reivindicaciones precedentes, caracterizado porque la política comprende un predicado y una acción o una función continua de los parámetros de entrada y una salida de control que varía continuamente. i
14. El sistema de conformidad con cualquiera de las reivindicaciones precedentes, caracterizado porque el subsistema de especificación de políticas recibe información con respecto al estado de un dispositivo que recibe la salida del subsistema de procesamiento de acciones y modifica las políticas con base en el estado del dispositivo.
15. El sistema de conformidad con cualquiera de las reivindicaciones precedentes, caracterizado porque el subsistema de políticas ajusta las reglas con base en los datos pasados.
16. El sistema de conformidad con cualquiera de las reivindicaciones precedentes, caracterizado porque las reglas i se actualizan en tiempo real.
17. El sistema de conformidad con cualquiera de las i j reivindicaciones precedentes, caracterizado porque el subsistema de especificación de políticas comprende una pluralidad de interfaces de usuario personalizadas a un nivel experto de usuario que permite que el usuario personalice las reglas .
18. El sistema de conformidad con la reivindicación ll, caracterizado porque la distribución de probabilidad representa la severidad del evento.
19. El sistema de conformidad con cualquiera de las reivindicaciones precedentes, caracterizado porque la salida se envía a un altavoz o a una pantalla para generar un mensaje de alerta.
20. El sistema de conformidad con cualquiera de las reivindicaciones 1-18, caracterizado porque la salida energiza un relé o controla la operación de una máquina, motor o turbina.
21. El sistema de conformidad con cualquiera de las reivindicaciones precedentes, caracterizado porque el evento es un sismo y los parámetros de evento incluyen uno o más de sacudidas de tierra máximas, aceleración de tierra máxima, velocidad de tierra máxima, desplazamiento de tierra máxima, intensidad Mercalli modificada, tiempo estimado de llegada de temblor de riesgo, y tiempo real de la llegada de ondas S.
22. El sistema de conformidad con cualquiera de las reivindicaciones precedentes, caracterizado porque a cada política se le asigna una prioridad.
23. El sistema de conformidad con la reivindicación 22, caracterizado porque la prioridad se especifica a través del orden de definición, manualmente asignado por un usuario, o cambiado por las acciones de una política.
2 . El sistema de conformidad con cualquiera de las reivindicaciones precedentes, caracterizado porque las reglas pueden hacer referencia a estados de acción y a variables de sistema externas. i i
! 25. Un método implementado por computadora para distribuir alertas con respecto a un evento, caracterizado porque comprende generar una o más políticas legibles por computadora, cada política comprende al menos una regla y al menos una acción asociada con al menos una regla, en donde cada regla incluye una pluralidad de parámetros de eventp y una pluralidad asociada de probabilidades de parámetro de evento; recibir y monitorear datos de un sistema de sensor, los datos incluyen valores de parámetro de- evento esperados y mediciones de desviación asociadas; j iniciar el procesamiento al menos de una regla ¡después de la detección de un cambio predeterminado en al menos uno de los valores de parámetro de evento esperados; ejecutar al menos una regla y desencadenar al menos una acción con base en una comparación de los valores de parámetro de evento esperados y mediciones de desviación asociadas con los parámetros de evento y las probabilidades de parámetro de evento predeterminadas asociadas al menos de una regla; y generar una salida para realizar al menos una acción desencadenada por el subsistema de ejecución de políticas .
26. El método de conformidad con la reivindicación 25, caracterizado porque comprende además registrar las operaciones de cada subsistema en medios fijos para ¡evaluación después de un evento.
27. El método de conformidad con la reivindicación 25 o 26, caracterizado porque comprende además aceptar la ¡entrada de un usuario final o tercero o una combinación de usuario final y tercero para generar la política legible por computadora . i
28. El método de conformidad con cualquiera de las reivindicaciones 25-27, caracterizado porque al menos una regla comprende un predicado Boolean.
¡ 29. El método de conformidad con cualquiera de las reivindicaciones 25-27, caracterizado porque al menos una regla comprende una regla vaga y al menos una acción ¡comprende una función de acción continua.
30. El método de conformidad con la reivindicación 28 o 29, caracterizado porque al menos una regla se expresa como una probabilidad de exceder un valor predeterminado de uno de la pluralidad de parámetros de evento.
31. El método de conformidad con la reivindicación 30, caracterizado porque la probabilidad de exceder un valor predeterminado se calcula con base en una distribución Gaussian con un valor y desviación esperados predeterminados.
32. El método de conformidad con cualquiera de las reivindicaciones 25-31, caracterizado porque comprende además ejecutar al menos una regla en serie y resolver conflictos y acciones de desencadenamiento con base en las reglas resueltas .
33. El método de conformidad con cualquiera de las reivindicaciones 25-32, caracterizado porque comprende además monitorear el desempeño de las acciones desencadenadas para verificar que las acciones se hayan ejecutado hasta · su finalización.
34. El método de conformidad con cualquiera de las reivindicaciones 25-33, caracterizado porque las alertas contienen un resumen parametrizado del evento.
35. El método de conformidad con la reivindicación 34, caracterizado porque el resumen parametrizado incluye una distribución de probabilidad o información para el cálculo de una distribución de probabilidad.
36. El método de conformidad con cualquiera de las reivindicaciones 25-35, caracterizado porque la salida es producida de manera periódica con base en la detección de un cambio predeterminado en al menos uno de los valores de parámetro de evento esperado.
37. El método de conformidad con cualquiera de las reivindicaciones 25-36, caracterizado porque la política comprende un predicado y una acción o una función continua de los parámetros de entrada y una salida de control que varía continuamente .
38. El método de conformidad con cualquiera de las reivindicaciones 25-37,' caracterizado porque comprende además recibir información con respecto al estado de un dispositivo que recibe la salida del subsistema de procesamiento de acciones y modifica la política con base en el estado del dispositivo.
39. El método de conformidad con cualquiera de las reivindicaciones 25-38, caracterizado porque comprende además ajusfar las reglas con base en los datos pasados.
40. El método de conformidad con cualquiera de las reivindicaciones 25-39, caracterizado porque comprende además actualizar las reglas en tiempo real.
41. El método de conformidad con cualquiera de las reivindicaciones 25-40, caracterizado porque comprende además personalizar las reglas usando una pluralidad de interfaces de usuario personalizadas para un nivel experto de usuario.
42. El método de conformidad con las reivindicaciones 25-41, caracterizado porque la distribución de probabilidad representa la severidad del evento.
43. El método de conformidad con cualquiera de las reivindicaciones 25-42, caracterizado porque comprende además enviar la salida a un altavoz o a una pantalla para generar un mensaje de alerta.
44. El método de conformidad con cualquiera de las reivindicaciones 25-42, caracterizado porque comprende además enviar la salida para energizar un relé o controlar la operación de una máquina, motor o turbina.
45. El método de conformidad con cualquiera de las reivindicaciones 25-44, caracterizado porque el evento es un sismo y los parámetros de evento incluyen uno o más de sacudidas de tierra máximas, aceleración de tierra máxima, velocidad de tierra máxima, desplazamiento de tierra máxima, intensidad Mercalli modificada, tiempo estimado de llegada de temblor de riesgo, y tiempo real de la llegada de ondas S.
46. El método de conformidad con cualquiera de las reivindicaciones 25-45, caracterizado porque comprende además asignar una prioridad a cada política.
47. El método de conformidad con la reivindicación 46, caracterizado porque la prioridad es especificada a través del orden de definición, manualmente asignado por un usuario, o cambiado por las acciones de una política.
48. El método de conformidad con cualquiera de las reivindicaciones 25-47, caracterizado porque las reglas pueden hacer referencia a los estados de acciones y las variables de sistema externas.
49. Un dispositivo para distribuir alertas con respecto a un evento, caracterizado porque comprende: un procesador y memoria para almacenar instrucciones que cuando se ejecutan por el procesador provocan que el procesador: genere una o más políticas legibles por computadora, cada política comprende al menos una regla y al íaenos una acción asociada con al menos una regla, en donde cada regla incluye una pluralidad de parámetros de evento y una pluralidad asociada de probabilidad de parámetro de evento predeterminada; reciba y monitoreé datos de un sistema de sensor, los datos incluyen valores de parámetro de evento esperados y mediciones de desviación asociadas; inicie el procesamiento al menos de una regla después de la detección de un cambio predeterminado en al menos uno de los valores de parámetro de evento esperados; ejecute al menos una regla y desencadene al menos una acción con base en una comparación de los valores de parámetro esperados y mediciones de desviación asociadas con los parámetros de evento y las probabilidades de parámetro de i evento predeterminadas asociadas al menos de una regla; y genere una salida para realizar al menos una acción desencadenada por el subsistema de ejecución de políticas. En algunas modalidades, el dispositivo puede ser uno o más de computadoras o servidores.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US201161447025P | 2011-02-26 | 2011-02-26 | |
| PCT/US2012/026783 WO2012116367A2 (en) | 2011-02-26 | 2012-02-27 | Customizable policy engine |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| MX2013009644A true MX2013009644A (es) | 2013-09-26 |
Family
ID=46721501
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| MX2013009644A MX2013009644A (es) | 2011-02-26 | 2012-02-27 | Motor de politicas personalizable. |
Country Status (11)
| Country | Link |
|---|---|
| US (1) | US9082286B2 (es) |
| EP (1) | EP2678843A4 (es) |
| JP (1) | JP5819446B2 (es) |
| CN (1) | CN103503042B (es) |
| AU (1) | AU2012222079B2 (es) |
| CA (1) | CA2827649A1 (es) |
| CL (1) | CL2013002421A1 (es) |
| HK (1) | HK1193230A1 (es) |
| MX (1) | MX2013009644A (es) |
| PE (1) | PE20141715A1 (es) |
| WO (1) | WO2012116367A2 (es) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105446200B (zh) * | 2015-12-31 | 2018-08-07 | 浙江中控软件技术有限公司 | 一种自动控制方法及装置 |
| CN109656774A (zh) * | 2018-09-27 | 2019-04-19 | 深圳壹账通智能科技有限公司 | 开放式规则流引擎分析方法、装置、终端设备及存储介质 |
| CN109375253B (zh) * | 2018-12-13 | 2020-01-21 | 中国地震局地球物理研究所 | 基于全部发震构造最大可信地震的地震动参数评价方法 |
| CN109375252B (zh) * | 2018-12-13 | 2020-05-05 | 中国地震局地球物理研究所 | 考虑不同发震构造最大可信地震的地震动参数评价方法 |
| CN111489517B (zh) * | 2019-01-25 | 2023-08-01 | 富士康精密电子（太原）有限公司 | 螺丝锁附异常警报方法、装置、计算机装置及存储介质 |
Family Cites Families (24)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5910763A (en) * | 1997-02-18 | 1999-06-08 | Flanagan; John | Area warning system for earthquakes and other natural disasters |
| US6169476B1 (en) * | 1997-02-18 | 2001-01-02 | John Patrick Flanagan | Early warning system for natural and manmade disasters |
| US6208247B1 (en) * | 1998-08-18 | 2001-03-27 | Rockwell Science Center, Llc | Wireless integrated sensor network using multiple relayed communications |
| JP2000121743A (ja) | 1998-10-14 | 2000-04-28 | Osaka Gas Co Ltd | 地震動分布の評価方法 |
| US6816878B1 (en) * | 2000-02-11 | 2004-11-09 | Steven L. Zimmers | Alert notification system |
| US6654689B1 (en) * | 2000-11-06 | 2003-11-25 | Weather Central, Inc. | System and method for providing personalized storm warnings |
| JP4253435B2 (ja) | 2000-11-30 | 2009-04-15 | 東京電力株式会社 | 地震動の強さ推定方法及びその装置 |
| US6731220B2 (en) | 2002-04-02 | 2004-05-04 | Industrial Technology Research Institute | Strong shaking judgment device and method |
| ES2533541T3 (es) * | 2002-08-30 | 2015-04-10 | Seismic Warning Systems, Inc. | Aparato sensor y método para detectar las ondas p generadas por un terremoto y generar una señal de control sensible |
| KR200324722Y1 (ko) * | 2003-04-16 | 2003-08-27 | 장병화 | 자동기상관측을 통한 재난 경보 및 생활정보 제공 시스템 |
| US20050027571A1 (en) | 2003-07-30 | 2005-02-03 | International Business Machines Corporation | Method and apparatus for risk assessment for a disaster recovery process |
| WO2005022198A1 (ja) | 2003-08-27 | 2005-03-10 | Nec Mobiling, Ltd. | 地震予知方法およびそのシステム |
| JP4160033B2 (ja) | 2004-09-09 | 2008-10-01 | 財団法人鉄道総合技術研究所 | 早期計測震度予測方法及びそのための装置 |
| DE202004018276U1 (de) * | 2004-11-25 | 2005-03-24 | Lachenit Heinrich | Erdbebenvorwarnsystem |
| US7353114B1 (en) | 2005-06-27 | 2008-04-01 | Google Inc. | Markup language for an interactive geographic information system |
| EP1970855B1 (de) * | 2007-03-13 | 2019-03-13 | Swiss Reinsurance Company Ltd. | Elektronische Steuerungsvorrichtung sowie Verfahren zur Steuerungs von cellulär aufgebauten Alarmsystemen |
| WO2009111394A1 (en) * | 2008-03-02 | 2009-09-11 | Thomas Gorman | Severe weather, environmental and mass notification warning system and method |
| CN101354757B (zh) | 2008-09-08 | 2010-08-18 | 中国科学院地理科学与资源研究所 | 一种精细尺度下的动态风险及易损性预测方法 |
| US20100169021A1 (en) * | 2008-12-31 | 2010-07-01 | Nokia Corporation | Earthquake detection apparatus, system, and method |
| CN101567124B (zh) | 2009-06-04 | 2012-05-02 | 山东省科学院海洋仪器仪表研究所 | 一种海洋灾害预警方法 |
| CN101630011A (zh) * | 2009-08-10 | 2010-01-20 | 南阳师范学院 | 基于虚拟仪器的地震监测与报警器 |
| CN101996470A (zh) | 2009-08-11 | 2011-03-30 | 融智信科技发展(北京)有限公司 | 基于mems加速度计的无线地震警报 |
| US8519860B2 (en) * | 2010-04-09 | 2013-08-27 | Weather Decision Technologies | Multimedia alerting |
| PE20140367A1 (es) | 2010-12-17 | 2014-03-22 | Seismic Warning Systems Inc | Sistema de advertencia de sismos |
-
2012
- 2012-02-27 CA CA 2827649 patent/CA2827649A1/en not_active Abandoned
- 2012-02-27 AU AU2012222079A patent/AU2012222079B2/en not_active Ceased
- 2012-02-27 CN CN201280020518.0A patent/CN103503042B/zh not_active Expired - Fee Related
- 2012-02-27 WO PCT/US2012/026783 patent/WO2012116367A2/en active Application Filing
- 2012-02-27 US US13/985,136 patent/US9082286B2/en not_active Expired - Fee Related
- 2012-02-27 MX MX2013009644A patent/MX2013009644A/es active IP Right Grant
- 2012-02-27 PE PE2013001974A patent/PE20141715A1/es not_active Application Discontinuation
- 2012-02-27 EP EP12750285.4A patent/EP2678843A4/en not_active Withdrawn
- 2012-02-27 JP JP2013555634A patent/JP5819446B2/ja not_active Expired - Fee Related
-
2013
- 2013-08-22 CL CL2013002421A patent/CL2013002421A1/es unknown
-
2014
- 2014-06-30 HK HK14106613.8A patent/HK1193230A1/zh not_active IP Right Cessation
Also Published As
| Publication number | Publication date |
|---|---|
| AU2012222079B2 (en) | 2015-10-01 |
| CL2013002421A1 (es) | 2014-01-31 |
| JP2014512588A (ja) | 2014-05-22 |
| CA2827649A1 (en) | 2012-08-30 |
| EP2678843A4 (en) | 2018-01-17 |
| HK1193230A1 (zh) | 2014-09-12 |
| NZ614604A (en) | 2015-10-30 |
| AU2012222079A1 (en) | 2013-09-05 |
| PE20141715A1 (es) | 2014-11-13 |
| WO2012116367A3 (en) | 2012-12-27 |
| CN103503042B (zh) | 2016-03-30 |
| US9082286B2 (en) | 2015-07-14 |
| CN103503042A (zh) | 2014-01-08 |
| WO2012116367A2 (en) | 2012-08-30 |
| US20140022075A1 (en) | 2014-01-23 |
| JP5819446B2 (ja) | 2015-11-24 |
| EP2678843A2 (en) | 2014-01-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10603579B2 (en) | Location-based augmented reality game control | |
| US20190392328A1 (en) | Cognitive computing systems and services utilizing internet of things environment | |
| US20190258747A1 (en) | Interactive digital twin | |
| US8150717B2 (en) | Automated risk assessments using a contextual data model that correlates physical and logical assets | |
| MX2013009644A (es) | Motor de politicas personalizable. | |
| US20160203123A1 (en) | Cognitive contextualization of emergency management system communications | |
| WO2021119087A1 (en) | Machine learning monitoring systems and methods | |
| US20200326669A1 (en) | Auto-adjustable machine functionality using analytics of sensor data | |
| WO2018111355A1 (en) | Content-level anomaly detection for heterogeneous logs | |
| KR20170122107A (ko) | 스마트 경보들을 제공하기 위한 지능적인 보안 허브 | |
| WO2022115419A1 (en) | Method of detecting an anomaly in a system | |
| US20230106381A1 (en) | Method and system for synthetic application monitoring | |
| US20180060987A1 (en) | Identification of abnormal behavior in human activity based on internet of things collected data | |
| CN113678148A (zh) | 针对个人防护设备的动态消息管理 | |
| US20200194123A1 (en) | Cognitive evaluation determined from social interactions | |
| Blaauwgeers et al. | Real-time risk estimation for better situational awareness | |
| US20220292427A1 (en) | Alert Actioning and Machine Learning Feedback | |
| CN108289077B (zh) | 一种对web服务器安全性进行模糊检测分析的方法及装置 | |
| NZ614604B2 (en) | Customizable policy engine | |
| EP3678071A1 (en) | System and method for improving safety in workspace | |
| CN113553147A (zh) | 基于ai和rpa的任务处理方法及其装置 | |
| US20200134528A1 (en) | Systems and methods for coordinating escalation policy activation | |
| Rogova | Context-awareness in crisis management | |
| da Silva et al. | Deploying privacy as a service within a cloud-based framework | |
| US11244065B2 (en) | Application monitoring and device restriction system and method |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FG | Grant or registration |