Estimacin de tiempos de vida para la verificacin de eventos en tiempo de ejecucin distribuida

Christos Kloukinas, George Spanoudakis, Khaled Mahbub Departamento de Informtica, Universidad de la Ciudad de Londres, EC1V 0HB, Reino Unido {C Kloukinas, G. Spanoudakis, K. Mahbub} @ soi.city.ac.uk

Abstracto Verificacin de tiempo de ejecucin del sistema se ha propuesto como una forma de verificacin dinmica de los sistemas de software que se puede aplicar en lugares donde la verificacin completa del sistema de pruebas estticas o exhaustivas no es prctica. Verificacin de tiempo de ejecucin comprueba las propiedades de eventos en tiempo de ejecucin en contra generados durante la operacin de un sistema. Los mtodos actuales para la verificacin de tiempo de ejecucin asumen que los eventos de tiempo de ejecucin con fecha y hora por un solo reloj y, por tanto, se pueden pedir por completo. Tambin se supone que los eventos son recibidos por el motor de razonamiento en el mismo orden en que se han producido. Estos supuestos son al parecer ciertos slo en sistemas con un solo reloj. En este trabajo se presenta la extensin de un marco para la verificacin de tiempo de ejecucin que puede controlar los sistemas distribuidos, en el que los eventos son producidos por diferentes componentes, cada uno con su propio reloj. INTRODUCCIN Tiempo de ejecucin (o dinmica) de verificacin del sistema se ha propuesto como un mtodo complementario a la verificacin del sistema y las pruebas estticas, que pueden aumentar la confianza en la exactitud de las operaciones del sistema de vigilancia y la identificacin de violaciones de las propiedades del sistema necesarios durante el funcionamiento normal del sistema [3] [6 ] [10]. Verificacin de tiempo de ejecucin es necesaria debido a la incapacidad de garantizar la integridad de los modelos de sistemas que se han utilizado para el anlisis esttico y la preservacin de estos modelos de implementacin de sistemas. Tambin es til ya que es difcil prever todas las circunstancias que puedan surgir durante la operacin de un sistema y por lo tanto, garantizar que los supuestos, en las que puede ser su correccin esttica demostrado, mantenga en tiempo de ejecucin. Por lo general, las plataformas para la verificacin de tiempo de ejecucin (por ejemplo, [6] [9] [11] [20]) proporciona soporte para especificar formalmente las propiedades de un sistema que debe ser verificada en tiempo de ejecucin, la identificacin de los eventos que deben estar disponibles con el fin de evaluar si propiedades de determinados requisitos, a la captura de estos eventos en tiempo de ejecucin, y la comprobacin de violacines de las propiedades requeridas.

La principal limitacin de las plataformas de verificacin de tiempo de ejecucin es que asumen que los sistemas que desee supervisar constan de componentes que se ejecutan en una sola mquina. En tales casos, los eventos del sistema que se est supervisando son: (i) una marca de tiempo de un reloj, (ii) totalmente ordenado, y (iii) recibida por el monitor en el mismo orden en que son generados por el sistema que se est supervisando. Mientras vlida en el caso de los sistemas centralizados, estos supuestos no es necesariamente vlida en los casos de sistemas distribuidos con componentes que se ejecutan en distintas plataformas. En tales sistemas, los eventos en tiempo de ejecucin puede provenir de componentes distribuidos que operan con relojes de tiempo diferentes. Adems, distribuye los componentes del sistema pueden tener diferentes tipos de conexiones con el monitor y, por tanto, generar eventos que llegan a la pantalla con retrasos de comunicacin diferentes y, posiblemente, en un orden que no es el mismo que el orden de su generacin. Por lo tanto, con el fin de comprobar las propiedades entre manifestaciones de componentes distribuidos, un monitor tendra que superar dos problemas: (i) para sincronizar los relojes de los orgenes de eventos diversos, por lo que las fechas de los diferentes eventos se pueden pedir y se compara con cada uno otros, y (ii) establecer hasta cuando un evento en particular necesita ser almacenada, de manera que pueda razonar sobre las propiedades del sistema de una manera correcta o, equivalentemente, para calcular la vida til de vigilancia requerida de cada evento. Consideremos, por ejemplo, el caso del monitoreo de la disponibilidad del canal de comunicacin entre dos C1 y C2 de un sistema de componentes, asegurando que el envo de una solicitud de R C1 (Evento-1) siempre ser seguido por la recepcin de R por C2 (Evento-2) dentro de un perodo de tiempo especfico. En este caso, evento-2 puede llegar a la pantalla anterior, debido a retrasos en la comunicacin diferentes en los canales correspondientes de eventos-1. Por lo tanto, cuando el monitor recibe dos eventos que tendrn que decidir durante cunto tiempo debe esperar para el evento-1 y esperar a que este evento antes de caer de eventos-2 o de lo contrario, el informe puede una violacin falsa de la disponibilidad del canal de comunicacin entre C1 y C2. Esto sucedera en los casos en que, despus de caer de eventos-2, el monitor recibe una correspondiente evento-1 a la misma. En este artculo presentamos una extensin de un marco de verificacin dinmica se describe en [20] que se ocupa de estos problemas. Los monitores marco original de los sistemas frente a las propiedades expresadas en el evento de Clculo (CE) [19] y fue desarrollado inicialmente para apoyar el monitoreo basado en eventos que se generan por una sola fuente. La ampliacin del marco que se presenta en este documento le permite controlar los sistemas en que los eventos son generados por fuentes distribuidas con diferentes relojes y canales de comunicacin con el monitor.

El resto del documento est organizado de la siguiente manera. En la seccin 2, se proporciona un resumen de nuestro marco de supervisin y el lenguaje que se utiliza para especificar las propiedades de control. En la seccin 3, se propone una solucin para el clculo de la duracin de los eventos que el marco recibe de fuentes distribuidas y mostrar cmo estas vidas se utilizan durante el seguimiento. En la seccin 4, se dar una visin general de los trabajos relacionados y, por ltimo, en la seccin 5 se resumen los trabajos y las directrices para futuras investigaciones.

Marco de seguimiento (Informacin general) Como se muestra en la Figura 1, el marco de la verificacin dinmica que hemos extendido consiste en un administrador de supervisin, un monitor, un Network Time Protocol (NTP), y se comunica con los colectores de eventos diferentes unidos a los componentes del sistema que se est supervisando. El gerente de supervisin tiene la responsabilidad de iniciar, coordinar e informar los resultados del proceso de monitoreo. Una vez que se recibe una solicitud de seguimiento de un conjunto especfico de propiedades, el gerente se comprueba si es posible su seguimiento y, si es as, que enva las propiedades a ser evaluados para el monitor, y empieza a escuchar a los eventos que son generados por diferentes tipos de colectores de eventos externos. Estos eventos son recibidos a travs de sockets TCP / IP y se enva al monitor. Despus de recibir los eventos de la gerente, el monitor se comprueba si se viola alguna de las propiedades se le da. El monitor es un motor genrico para el control de violaciones de las frmulas de la CE en contra de un determinado conjunto de eventos en tiempo de ejecucin. Durante el monitoreo, que tambin tiene en cuenta la informacin sobre el estado de un sistema que se deriva de los acontecimientos en tiempo de ejecucin utilizando un tipo especial de frmulas CE llama supuestos (ver seccin 2.2). Cuando una violacin de una propiedad es, el monitor que registra en una base de datos de la desviacin que se sondea peridicamente por el responsable del seguimiento para recuperar desviaciones detectadas.

El marco supone que los componentes de los sistemas a ser monitoreados han asociado coleccionistas caso de que se puede capturar eventos durante su funcionamiento y los envan al monitor. Cuando un colector capta un evento de tiempo de ejecucin, que se envuelve en un sobre con informacin adicional, incluyendo el origen del evento (es decir, el componente donde fue capturado) y una marca de tiempo que indica cuando el evento fue capturado en el componente. Para habilitar la sincronizacin de las marcas de tiempo de eventos, el marco incorpora componentes que dan cuenta del Protocolo de Tiempo de Red [17] (es decir, un protocolo basado en el esquema de sincronizacin de los relojes se describe en [12]). La implementacin de este protocolo permite a los coleccionistas de eventos para calcular la diferencia de sus relojes con el reloj de la pantalla a intervalos regulares. Esta diferencia se utiliza para transformar las marcas de tiempo tomado de acuerdo con el reloj de cada colector en marcas de tiempo que expresa el tiempo en trminos de reloj del monitor. Esto se logra mediante la implementacin de un cliente de NTP en cada colector de eventos y un servidor NTP en la mquina que aloja el monitor, como se muestra en la Figura 1. Los clientes NTP llamar al servidor NTP a intervalos regulares para sincronizar sus relojes con el reloj del servidor. El uso de NTP puede sincronizar relojes distribuidos en un nivel muy alto de precisin ya que las ltimas versiones de NTP (versin 4) usar una resolucin de menos de un nanosegundo. 2.2 Especificacin de las Propiedades Como se indica en la seccin 1, en nuestro marco de supervisin de tiempo de ejecucin de las propiedades objeto del control se expresa en un lenguaje basado en eventos de Clculo (CE) [19]. CE es un lenguaje de lgica de primer orden temporal que puede ser usado para representar y razonar acerca de los acontecimientos y sus efectos en el tiempo. Un evento de la CE es un acontecimiento que tiene lugar en una instancia especfica de tiempo (por ejemplo, la invocacin de una operacin del sistema, la recepcin o envo de un mensaje) y puede tener un efecto. Los efectos de los acontecimientos son representados por fluentes. Fluentes son las condiciones que pueden cambiar con el tiempo (por ejemplo, una condicin que indica que un sistema ha recibido un mensaje) y se inician y / o terminadas por los acontecimientos. La ocurrencia de un evento de la CE est representada por el predicado sucede (e, t, (lb, ub)). Este predicado indica que un evento e instantnea se produce en algn tiempo t en el intervalo de tiempo (lb, ub) (es decir, lb t ub). La libra fronteras y la UB que definen los rangos de tiempo se especifican como expresiones lineales en las variables de tiempo pasa predicados en una frmula de la CE de la siguiente forma:

Dado nuestro foco en la supervisin del sistema en tiempo de ejecucin, los acontecimientos que consideramos representan las invocaciones de las operaciones del sistema, las respuestas de este tipo de operaciones, o el intercambio de mensajes entre los diferentes componentes del sistema. Por lo tanto, los eventos tienen la siguiente estructura que captura la informacin necesaria para el seguimiento de tales interacciones del sistema sin afectar a la expresin general de la estructura con respecto a la norma de la CE: Event (_id, _sender, _receiver, _status, _sig, _source) En esta estructura: _id es un identificador nico del evento. _sender es el identificador del componente del sistema que enva el mensaje que representa el evento. _receiver es el identificador del componente del sistema que recibe el mensaje que representa el evento _status es el estado de tramitacin de un evento (es decir, si no, ni su tratamiento se ha iniciado cuando el monitor que recibe) _sig es la firma del mensaje enviado o la operacin de invocacin / respuesta que representa el evento, que incluye el nombre de operacin y sus argumentos / resultado. _source es el identificador del componente, donde fue capturado el evento.

Fluentes se definen como las relaciones entre los objetos de la forma rel (O1,..., A) donde rel es el nombre de una relacin que asocia el n objetos O1,..., y encendido. La iniciacin o terminacin de un f fluido debido a la ocurrencia de un evento e en el tiempo t se denota en la CE por los Iniciados predicados (e, f, t) y termina (e, f, t), respectivamente. Una frmula CE tambin pueden utilizar los predicados Inicialmente (f) y se mantiene a (f, t) para indicar que una f fluido se mantiene en el inicio de la ejecucin de un sistema y en el tiempo t, respectivamente. Las reglas de un control en tiempo de ejecucin se especifican en trminos de los predicados por encima y por tener el cuerpo general de forma de la cabeza . El significado de una regla es que si su cuerpo se evala como verdadera, la cabeza tambin se debe evaluar como verdadera. Los predicados sucede en una regla que no tienen restricciones para sus lmites de tiempo inferior y superior son lo que llamamos "sin restricciones" predicados. Durante el

proceso de supervisin, las reglas son activadas por eventos que pueden ser unificada con las restricciones predicados sucede en ellos. Cuando esta unificacin es posible, el monitor genera una instancia de gobierno para representar a la norma parcialmente unificado y mantiene esta instancia activa hasta que todos los otros predicados en ella se han unificado con xito eventos y fluentes de tipos apropiados o que se deduce que no son ms unificaciones posible. En este ltimo caso, la instancia de gobierno se elimina. Cuando una instancia de gobierno es totalmente unificado, los controles de monitor, si la instancia particular que se expresa est satisfecho. Un ejemplo de una regla que se puede expresar en el lenguaje de la CE de nuestro marco est dado por la siguiente frmula:

Esta regla establece que cuando un correo evento (_eID1, _C3, _C1, REQ, autorizar (), _C3), t1, (t1, t1)) que representa una llamada de autorizar la operacin () en un _C1 componente por componente _C3 se enva, debe ser seguido por un evento E (_eID2, _C3, _C1, RES, autorizar (), _C1) represening la recepcin de la llamada _C1 en no ms de 10 unidades de tiempo despus de que el envo de llamada. As, el artculo 1 expresa una propiedad limitada disponibilidad para el canal de comunicacin entre los componentes _C3 y otros componentes del sistema (_C1), ya que requiere que las solicitudes generadas por _C3 se transmiten dentro de un perodo de tiempo limitado. El predicado sin restricciones en esta regla es el predicado pasa (e1C3, t1, (t1, t1)) 1, ya que los lmites inferior y superior de la variable tiempo se definen sin ninguna referencia a las variables de otro momento de la regla. Por lo tanto, en tiempo de ejecucin, las nuevas instancias de la Regla 1 se generar tan pronto como un evento que puede ser unificada con este predicado se recibe. Cada uno de estos casos, la regla que sigue viva hasta que est totalmente unificado o hasta que una mayor unificacin de un evento en representacin de la recepcin de una respuesta de la convocatoria enviada por _C3 en la instancia de gobierno es posible. Tenga en cuenta que, como en el ejemplo anterior, nuestro marco de trabajo requiere que todos los predicados restringidos en una regla para que las variables de tiempo limitado con lmites superiores. Esto es para asegurar que las reglas pueden ser verificados. Por ejemplo, si sucede lo predicado por e2C1 en la cabeza de la Regla 1 no tiene un lmite superior, entonces su ausencia no sera hacer que el monitor de la bandera de la regla como violado, ya que el

monitor siempre esperar a que algn e2C1 evento en algn momento en el futuro.

3. INFORMTICA DE POR VIDA DE EVENTOS Como ya comentamos en la seccin 1, el problema que surge con el uso de los eventos que son generados por fuentes distribuidas es doble: en primer lugar es necesario sincronizar los relojes de los orgenes de eventos tan diferentes que las fechas de los eventos que puede generar ser comparables entre s y en segundo lugar tenemos que saber hasta cuando tenemos que guardar un evento en particular con el fin de ser capaces de razonar sobre el estado del sistema y comprobar las reglas. La sincronizacin de los relojes que se realiza a travs de la utilizacin del Protocolo de Tiempo de Red (NTP) de nuestro marco resuelve el primer problema, pero no el segundo. Para apreciar el segundo problema, considere la Regla 1, suponiendo sin prdida de generalidad que _C3 y _C1 referirse tanto a la fuente del evento y el reloj de la componente del sistema de origen donde fue capturado el evento. Como la ocurrencia de eventos de tipo e1C3 en el artculo 1 no tiene restricciones, los eventos de este tipo pueden crear una instancia del Estado durante el seguimiento. A diferencia de ellos, los acontecimientos de e2C1 tipo son temporalmente limitados por e1C3 eventos en la regla y no puede, por tanto, crear nuevas instancias de la regla, sino que slo puede ser unificada con las instancias de gobierno existentes. 1 e1C3 es una referencia abreviada a la direccin de eventos (_eID1, _C3, _C1, REQ, autorizar (), _C3), en la que el subndice denota la identificacin del suceso y el exponente de la fuente del evento. Tales referencias abreviadas se usan en el resto del trabajo en todos los casos en que otras variables de eventos no son importantes. Por lo tanto, si el monitor recibe un evento de tipo e2C1, adems de la unificacin con todas las instancias actuales de la Regla 1, se debe mantener hasta que no haya posibilidad de recibir un evento e1C3 que pudieran estar relacionados con e2C1 a travs de la Regla 1. Esto es necesario ya que si e2C1 se ha cado y ms tarde, el monitor recibe un evento e1C3 con una marca de tiempo antes de e2C1, sera denunciar una violacin falsa de la Regla 1. La posibilidad de e1C3 y e2C1 eventos que llegan a la pantalla en el orden inverso de su aparicin se produce debido a diferentes (y que cambia dinmicamente) retrasos en la comunicacin en los canales que conectan C1 y C3 con el monitor o incluso ataques de estos canales que pueden causar la la prdida de los acontecimientos. Manteniendo al mismo tiempo los eventos de e2C1 tipo, en este caso es necesario para la solidez de los resultados del monitoreo, el monitor tambin debe asegurarse de que mantiene a estos eventos slo para el tiempo mximo que es necesario para la solidez de los resultados. Esto es porque si el monitor los conserva durante ms tiempo el tamao de su almacn de eventos aumenta montonamente con un efecto de deterioro tanto

en el espacio y el tiempo necesarios para la vigilancia. El punto mximo de tiempo hasta que los acontecimientos e2C1 tendra que ser conservada por el monitor, en este ejemplo, se puede establecer por encontrar el valor mximo de la variable tiempo de t1 e1C3 eventos que satisface las restricciones: (1) t1 t2 -1 y (2) t2 t1 10.

En general, para una regla con n +1 pasa predicados, habr 2n +1 tales desigualdades para resolver. Esto se debe a uno de los predicados de regla no tiene restricciones (el despido de la regla), el resto pasa predicados contribuir cada dos desigualdades, y necesitamos una igualdad adicional para establecer el valor exacto de la variable tiempo del evento en cuestin (en t2 nuestro ejemplo anterior con el e2C1 eventos). La figura 2 muestra el algoritmo para calcular la vida til de un evento. De acuerdo con este algoritmo, cuando un correo evento, el conjunto R (e) de reglas que tienen predicados que pueden ser unificada con el correo acontecimiento est determinado (este grupo incluye normas que tienen los tipos de eventos que son los mismos que el tipo de e o supertipos de la misma). El conjunto R (e) se incluyen las normas que pueden especificar lmites de tiempo para el evento que no puede ser completamente evaluado. Posteriormente, las limitaciones de cada regla en R (e) se identifican y se expandi con una igualdad que expresa que la variable tiempo del predicado de la regla que se ha unificado con el correo es igual a la fecha y hora del correo (paso 2.a). Teniendo en cuenta el conjunto de restricciones de tiempo que resulta de este proceso, el algoritmo calcula el valor mximo posible para cada una de las variables de tiempo de la norma mediante el mtodo Simplex [8] (paso 2.bi). Posteriormente, los grupos de las variables de tiempo diferentes segn el reloj del origen de eventos que estn relacionados con (paso 3), y genera un conjunto de todas las condiciones (de por vida (e)) para calcular el lmite superior de la vida til de correo ( paso 4). Una condicin en la vida (e) establece que el correo no ser necesaria despus de la ltima que se ve desde un canal que es relevante para e tiene una marca (last_observed (CJ)) que es mayor que el valor mximo posible del tiempo variables agrupadas en el grupo de este canal (ver condiciones last_observed (CJ)> maxti GJ (max (ti))). La razn para usar la marca de tiempo del ltimo evento que se ha observado a partir de un reloj en la evaluacin de la vida (e) las condiciones es porque los eventos son comunicados a la pantalla a travs de sockets TCP / IP que garantizan una transmisin FIFO dentro del mismo componente (reloj), supervisar el canal. Las condiciones de vida (e) determinar la vida til del correo ya que cuando su conjuncin se hace realidad, la vida til de e expirar.

En nuestro ejemplo anterior, si la regla 1 es la nica regla que est siendo vigilado y de un caso de e2C1 tipo se observa en t2 = 10, paso 1 se produce el conjunto R (e2C1) = {1} Regla-, el paso 2.a producir CNR = {t1 t2 -1, t2 t1 + 10, T2 = 10}, 2.bi paso producir el mximo de soluciones (t1) = 9 y un mximo (t2) = 10, encontrando el mximo valor de t1 para que las restricciones en el CNR est satisfecho, y el paso 3 se produce dos grupos de variables de tiempo {} y {t1 t2}, para los dos relojes C1 y C3, respectivamente. Finalmente, en el paso 4, la restriccin de vida establecida para e2C1 se establecer como: Toda la vida (e2C1) = {(last_observed (C1)> 10), (last_observed (C3)> 9)}. Cabe sealar que nuestro algoritmo utiliza el mtodo Simplex, que tiene complejidad exponencial O (2n) (por un problema con n variables [8]), para encontrar el tiempo mximo de una variable de tiempo en 2.bi paso, aunque hay algoritmos con compexity polinomio (el peor de los casos la complejidad del algoritmo de Karmarkar [1], por ejemplo, es O (n3.5)). Esto se debe a un pequeo nmero de variables, como las que normalmente aparecen en las reglas de control (n 10), Simple tiene un mejor rendimiento. Adems, el algoritmo de la Figura 2 se calcula el valor mximo de una variable de tiempo para cada regla por separado, en lugar de agruparlos en un solo problema ms grande. Esto se debe a los problemas de regla individual se pueden resolver de manera independiente y un conjunto ms amplio de las reglas se necesitara ms tiempo para resolver, debido a las variables de tiempo adicional (en general, 2n + 2m <2n + m por n, m 2). Debido a este enfoque, una vez que los

sistemas de reglas individuales se han resuelto, las variables de tiempo diferentes que estn asociados con eventos provenientes de la misma velocidad de reloj deben ser agrupados, como se hizo en el paso 3 del algoritmo. Tenga en cuenta que a este paso, el algoritmo de la figura 2 se supone que los relojes / fuentes de los eventos en que las reglas son completamente especificado cuando una norma se corresponde con un evento de entrada. En el ejemplo de la Regla 1, este es el caso, ya que el remitente de un evento e2C1 (es decir, C3) es tambin la fuente de los acontecimientos e1C3. As, cuando la regla 1 se corresponde con un evento e2C1, la

identidad de C3 es conocida. Sin embargo, puede haber casos en los que la fuente exacta de los acontecimientos que podran ser emparejado con una regla no se conoce despus de la regla coincida con los acontecimientos lleg. Consideremos, por ejemplo, la siguiente regla:

Esta regla establece que si un usuario _U se conecta a un sistema de un _C2 _C1 terminal y luego l / ella se conecta de nuevo desde un terminal diferente _C3, l / ella debe tener la sesin de la terminal del antiguo antes de que el segundo inicio de sesin. La regla de control efectivo de los casos en que los usuarios conectados desde diferentes terminales al mismo tiempo. Cuando un correo evento (_eID2, _C3, _C2, REQ, inicio de sesin (_U, _C3), _C3) (o e2C3 en nuestra forma abreviada) llega a la pantalla, su vida tendr que ser estimada en referencia a los valores mximos posibles de variables de tiempo T1 y T3. En este caso, sin embargo, el algoritmo de la Figura 2 no funciona, ya que en el paso 3 no se sabe que otros terminales del usuario de e2C3 puede utilizar o, equivalentemente, que los relojes de origen debe estar asociada con las variables de tiempo T1 y T3.

Para hacer frente a estos casos, se utiliza una extensin del algoritmo, que se muestra en la Figura 3. El algoritmo extendido inicialmente grupos de variables de tiempo en los grupos correspondientes a los tipos de los orgenes de eventos que se asocian con ellos en las normas. Luego, para cada uno de los grupos de tipo de fuente, que encuentra todas las fuentes del tipo que se sabe que el sistema, crea grupos diferentes para ellos y asigna las copias de las variables de tiempo de cada tipo de fuente para cada uno de los grupos de origen que se generados por el tipo. Por lo tanto, si se sabe que el sistema que se est supervisando con el artculo 2 tiene 3 terminales, el algoritmo de la Figura 3 se crean diferentes grupos de variables para cada uno de estos terminales y asignar copias de las variables de tiempo T1 y T2 a cada uno de estos grupos . Despus de haber calculado la vida (e) conjunto de restricciones, a la llegada de un mensaje de evento en tiempo de ejecucin que se utilizan para calcular un vector con los valores de tiempo mximo para el correo con respecto a los

relojes de diferentes relacionados con ella. Para el ejemplo actual de la Regla 1, el vector de e2C1 sera <10, 9>. El evento y su vector se almacenan en la base de datos del monitor. Adems, cuando un nuevo evento llega a l, el monitor comprueba si la vida de algunos otros eventos que dependen de el reloj de la nueva cita ha expirado. El proceso anterior se muestra en la Figura 4.

4. TRABAJOS RELACIONADOS Las formas de verificacin dinmica se han desarrollado e investigado en el contexto de la verificacin del programa, crticos para la seguridad, y sistemas de servicio cntrica. En la verificacin del programa, la investigacin se ha centrado en el desarrollo de plataformas de programacin con funciones de supervisin genrica, incluido el apoyo para la generacin de los eventos del programa en tiempo de ejecucin (por ejemplo, jMonitor [11]), la incorporacin de las especificaciones de los bienes susceptibles de seguimiento en los programas y la produccin de cdigo que se puede verificar estas propiedades durante la ejecucin del programa (por ejemplo, la programacin orientada a control [4] y [6]). Tambin existe un trabajo centrado en la verificacin de tiempo de ejecucin de las especificaciones de requisitos [7]. Sin embargo, el tiempo de medicin no se considera en [4], [6], [7] o [11]. Mtodos de control de tiempo de ejecucin tambin se han aplicado a los sistemas crticos de seguridad autnomas [16], como las pruebas de estos sistemas es difcil y consume recursos. En los sistemas centrados en servicio, verificacin dinmica se ha centrado en los acuerdos de control de nivel de servicio (SLAs) [2] [20]. En los sistemas crticos de seguridad, los primeros mtodos de vigilancia se centr en la deteccin de fallos de sincronizacin y la garanta de respuesta del sistema [9] [15]. Aunque [15] apoya las limitaciones de tiempo, que no admite la supervisin distribuida. El control distribuido de [9] Por otra parte no es compatible con fluentes o expresiones generales para el tiempo y no aclara cmo el lmite del tamao de las historias de caso que se decida. La correlacin de eventos tambin se ha considerado en [18] donde los observadores de eventos se producen como autmatas transductor de reconocer y volver a escribir los eventos de entrada. En comparacin con nuestro marco, el enfoque en [18] no es compatible con

fluentes o el tiempo de medicin. La ampliacin del marco en [20] con las capacidades descritas en este documento permite comprobar propiedades complejas, basadas en los eventos capturados desde fuentes distribuidas, por lo tanto, superior a las capacidades de los otros enfoques.

5. CONCLUSIONES En este trabajo hemos presentado las extensiones de la estructura de supervisin se describe en [20] que hacerlo aplicable a mltiples reloj de los sistemas distribuidos. Nuestras extensiones de direccin de dos de los problemas de control de sistemas distribuidos: (1) la necesidad de sincronizar los relojes de las fuentes de eventos diferentes para que los eventos que emiten pueden ser correlacionados, y (2) la estimacin de la duracin de los eventos dentro de la pantalla en Para garantizar que los retrasos de transmisin desconocida de otros eventos que pueden necesitar que se correlaciona con ellos, no afectar el proceso de supervisin. Para abordar el primero de estos problemas, hemos incorporado una implementacin del protocolo NTP en nuestro marco. Para abordar el segundo problema, se calcula el tiempo de vida mximo de un evento mediante la identificacin, las restricciones entre las variables de tiempo de las variables de evento y tiempo de otras actividades que coexisten con l en las normas y la solucin de estas dificultades para encontrar el tiempo de vida posible para el evento mediante el mtodo Simplex (ver [12] para ms detalles). Una optimizacin posible de nuestra solucin es resolver estticamente todos los sistemas de restriccin lineal en la inicializacin, as como para necesitar slo para crear instancias de los valores especficos de las marcas de tiempo diferentes, asociadas a una nueva y sus normas conexas, cuando el caso llega, en lugar de resolver el correspondiente sistema lineal en cada ocasin. Esto requerira una solucin simblica del sistema de restricciones lineales en lugar de la solucin numrica ms sencillo que actualmente emplea. Por esta razn hemos decidido en contra de la solucin simblica en la implementacin actual, y la intencin de examinar esta opcin una vez que hemos adquirido ms experiencia con el comportamiento de la aplicacin actual en un entorno distribuido. 6. AGRADECIMIENTOS Este trabajo ha sido financiado por la serenidad de proyectos integrados de investigacin (FP6-IST-2.006-27.587).