Testing de Sistemas de Tiempo Real PDF

 

Testing de Sistemas de Tiempo Real Pablo Itaim Ananias Valpara´ıso, ıso, 16 de d e Noviembre Nov iembre del 2004 2 004 Resumen

Las aplicaciones de tiempo real son muy variadas y continuamente surgen nuevos campos de utilizaci on o´ n para las mismas siendo cada d´ d´ııaa mas a´ s complejas. La verificacion o´ n de estos sistemas tambi´ tambien e´ n es muy complicada ya que, adem´as as de los requerimientos temporales, se deben probar los de causalidad y predictibilidad, a lo que se suman todas las la s caracter´ıısticas sticas t´eecnicas cnicas del sistema como son el frecuente uso de paralelismo, distribuci´o on n y mecanismos de tolerancia a fallas. El presente trabajo explora en el estado del arte y de la pr actica a´ ctica del testing de sistemas de tiempo real, mostrando las t´ tecnicas e´ cnicas y herramientas existentes para la verificaci on o´ n de este tipo de sistemas. Finalmente, se muestra un ejemplo utilizando una de las herramientas descritas.

1.

Intr Introd oduc ucci ci´on: o´ n:

Contrariamentee a lo que se podr Contrariament podr´´ıa ıa pensar, las aplicaciones de tiempo real son muy variadas y continuamente continuamente surgen ´ s comunes los asociados a los sistemas de telecomunicanuevos campos de utilizaci´ utilizacion o´ n para las mismas, siendo los m´ m aas ciones, rob´ robotica, o´ tica, multimedia, control de procesos industriales y sistemas espaciales, entre otros. Pensando en nuestra vida cotidiana, son sistemas de tiempo real los que ayudan a volar a los aviones, los que controlan el motor o los frenos de nuestro autom´ovil, ovil, etc. El aspecto fundamental que diferencia a los sistemas de tiempo real del resto de los sistemas ”convencionales”, es el hecho de que adem´ ademaas ´ s de ser necesaria la satisfaccio on ´ n de todos los requerimientos computacionales normales, la correcci´ correccio on ´ n del sistema depende tambi tambi´een ´ n del tiempo en que son producidos esos resultados. En otras palabras, un resultado l´ lo ogicamente ´ gicamente correcto pierde todo significado si el tiempo de espera por el mismo sobrepasa ciertos ll´´ımites ımites preestablecidos. De maas ´ s est est´a´ decir que la presencia de requisitos temporales hace que la construcci o on ´ n de los sistemas de tiempo real sea mucho m´ mas a´ s dif ´ıcil ıcil y complicada, principalmente porque la mayor´ mayor ´ıa ıa de los m´ metodos e´ todos y herramientas utilizados para la construcci´ construccion o´ n de sistemas convencionales no contemplan tales restricciones, caracter´ caracter´ısticas ısticas en los sistemas de tiempo real. ´ ´ ´ Por otro se lado, la verificaci on de de estos sistemas tambien es muya complicada ya que, adem de los requerimientos ´ısticas temporales, deben probar los causalidad y predictibilidad, lo que se suman todas lasascaracter´ caracter ısticas t´ tecnicas e´ cnicas del sistema como son el frecuente uso de paralelismo, distribuci´o on n y mecanismos de tolerancia a fallas. Generalmente, m´aass del 50 % del presupuesto se gasta en las Tareas de Test Testing ing de este tipo de Sistemas. La mayor´ıa ıa de los m´etodos etodos cl´asicos asicos existentes se enfocan en probar la correctitud l´ogica ogica del sistema y no consideran el problema temporal, parte esencial en los sistemas de tiempo real. Por lo anterior, estos m eetodos ´ todos deben complementarse con otros que se concentran en determinar si el sistema bajo prueba viola las especificaciones temporales o no. Un error temporal normalmente ocurre cuando las salidas son producidas muy pronto o el c aalculo ´ lculo de las salidas toma demasiado tiempo. Por ello, los Casos de Prueba deben construirse de manera tal que produzcan tiempos de ejecuci o on ´ n maximos a´ ximos y m´ınimos ınimos con el objeto de producir errores del tipo temporal. Obviamente es casi imposible encontrar esas entradas analizando y probando el comportamiento temporal de sistemas complejos en forma manual. Sin embargo, veremos que existen m´ metodos e´ todos que lo logran en forma semiautom´ semiautomatica. a´ tica. El punto 2 del presente Trabajo muestra una descripci´ descripcion o´ n general de los sistemas de tiempo real, indicando su clasificaci´ ficaci on o´ n y caracter´ caracter ´ısticas ısticas principales. El punto 3, describe elactica. Testing de los de Tiempo Real, las metodolog´ metodolog ılas as, las t´eecnicas, cnicas, herramientas, etc, el estado del arte y de la pr´ actica. Adem´ aas, s,Sistemas se presenta un ejemplo utilizado una de´ıas, Herramientas m´aass difundidas en el ambito a´ mbito investigativ investigativo. o. Finalmente, en el punto 4 se presentan las principales conclusiones respecto al trabajo realizado.

 

2.

Sistem Sistemas as de Ti Tiemp empo o Real: Real:

Podemos definir un Sistema de Tiempo real como: ” Un sistema informatico que interacciona repetidamente con ´  su entorno, sobre el que realiza acciones de control que se producen dentro de intervalos de tiempo bien definidos ”. El hecho de que las acciones del sistema se deban efectuar dentro de intervalos de tiempo determinados hace que el dise˜n no o y realizaci´on on de sistemas de tiempo real revista una dificultad especial. Es importante resaltar que no se trata simplemente de que el sistema sea r´apido, apido, aunque esto desde luego ayuda a cumplir los requisitos de tiempo, sino de que sea determinista, es decir, que su comportamiento temporal sea el adecuado en cualquier circunstancia, incluso cuando el sistema est´ esta´ sobrecargado. [BA03] Generalmente las propiedades temporales se expresan mediante dos tipos de requisitos que se aplican a cada una de las actividades del sistema: Un esquema de activaci´  cuaando ´ ndo se debe ejecutar cada actividad. La activaci´ activacion o´ n puede ser peri odica o´ dica on, que indica cu´ o aperi´ aperiodica. o´ dica. En el primer caso, la actividad se ejecuta regularmente, con un per´ per´ııodo odo bien definido. En el segundo caso, se ejecuta de forma irregular, en respuesta a un suceso del entorno o del propio sistema de tiempo real. La activacion o´ n aperi´ aperiodica o´ dica se caracteriza mediante la exigencia de una separaci on o´ n m´ m ´ınima ınima entre dos sucesos consecutivos, mediante un numero u´ mero m´ maximo a´ ximo de sucesos en un intervalo de tiempo determinado, o mediante una distribuci on o´ n estad´ estad´ıstica ıstica del suceso de activaci´ activacion. o´ n. En el primer caso se suele hablar de activacion o´ n espor´ esporadica. a´ dica. Un  plazo de ejecuci´  ejecucion o´ n, que marca el l´ l´ıımite mite de tiempo para el ´   de la actividad, relativo al instante de activaci on, teermino ´ rmino de la actividad cada vez que se ejecuta.

Figura 1: Ejemplo de un STR de control Estos requisitos se pueden interpretar de varias maneras. En algunos sistemas, llamados cr´ cr ´ıticos ıticos (hard real-time real-time systems), es inadmisible que determinadas acciones (no necesariamente todas) terminen fuera de plazo ni una sola vez. En otros sistemas, denominados denominado s no-cr´ıticos ıticos ( soft real-time systems), se puede admitir que se violen algunos plazos de vez en cuando sin m´aass consecuencia que un deterioro en la calidad del funcionamiento del sistema. Obviamente, los primeros son considerablemente m´aass dif´ıciles ıciles de dise d ise˜nar n˜ ar y realizar que los segundos. Los problemas que plantea la construcci´on on de sistemas de tie tiempo mpo real se ven acrecentados acrece ntados por otras ccaracter´ aracter´ıısticas sticas de los mismos que, aunque comunes a otros tipos de aplicaciones inform aticas, a´ ticas, revisten especial complejidad cuando se mezclan con las restricciones temporales. Entre estas caracter´ caracter´ıısticas sticas adicionales podemos citar las siguientes: Concurrencia:  las actividades del entorno f ´ıısico sico se ejecutan en paralelo, por lo que el sistema de tiempo real tiene que responder a los sucesos externos mediante actividades concurrentes. Fiabilidad y Seguridad:  muchos sistemas de tiempo real, como los que controlan el vuelo de los aviones o el freno ´ viles, tienen requisitos de seguridad muy estrictos. En otros casos, menos cr´ de los autom´ automo oviles, cr´ıticos ıticos en cuanto a la seguridad, son razones de tipo econ´o omico mico las que exigen un grado de fiabilidad elevado. Por ejemplo, en los sistemas empotrados en electrodom´eesticos, sticos, el costo de reemplazar una serie de productos por errores de software es normalmente prohibitivo. El uso de m´ m eetodos ´ todos y herramientas que aseguren una fiabilidad adecuada en el software y el hardware, complementados con t eecnicas ´ cnicas de detecci detecci´o on ´ n y recuperacio on ´ n de fallas, es obligatorio en la mayor´ mayor´ııaa de los casos.

´n Tama ˜  Tama ˜  no y complejidad:   El abaratamiento del hardware fom fomenta, enta, como en otros campos de aplicaci aplicaci´on, o´ n, la realizacio on de sistemas con m´ mas a´ s funcionalidad y mejores interfaces. Ello se traduce en un mayor tama no n˜ o y complejidad 2

 

incluso en sistemas que se sol´ sol ´ıan ıan realizar con escasos medios. Hoy en d´ d´ıa ıa es frecuente encontrar sistemas empotrados en televisores o tel´eefonos fonos m´oviles oviles con varios cientos de miles de l´ııneas neas de c´o odigo. digo. Otros sistemas m´aass sofisticados, como los que se encuentran en aviones o centrales telef´o onicas, nicas, alcanzan con frecuencia varios millones de l´ l´ııneas neas de cc´o odigo. ´ digo. La mayor´ mayor´ıa ıa de los m´ m etodos e´ todos y lenguajes utilizados para otros tipos de aplicaciones no tienen en cuenta los requisitos temporales. Por ello su utilizacion o´ n en sistemas de tiempo real resulta inadecuada en la mayor´ mayor´ıa ıa de los casos, ya que no permiten asegurar que se satisfacen las propiedades temporales del sistema. Por ello ha sido necesario desarrollar m´eetodos todos y herramientas nuevos, y adaptar algunos de los existentes. Por otr otro o lad lado, o, la planifi planificac caci´ i´o on n de lo loss re recu curs rsos os de dell si sist stem emaa es un uno o de los los pr prob oble lema mass cent centra rale less en la cons constr truc ucci´ ci´on o n delos sistemas de tiempo real. Es tal su importancia en los sistemas actuales, que la selecci selecci´o on ´ n de una pol pol´´ııtica tica de planificacio on ´n determina en gran medida la arquitectura de software y la realizaci on o´ n del sistema. La planificaci o on ´ n sincr sincr´o onica ´ nica ha sido la mas a´ s empleada tradicionalmente. Se caracteriza porque la ejecuci on o´ n de las tareas se activa de forma sincronizada con un reloj. El ejecutivo c´ c´ıclico ıclico es el m´ metodo e´ todo m´ maas ´ s empleado, y consiste en un procedimiento que activa cc´´ııclicamente clicamente un conjunto de tareas segun u´ n un orden prefijado en un plan de ejecuci on. o´ n. El car´ caracter a´ cter determinista de este m´ metodo e´ todo es su mayor ventaja. La dificultad de realizar y mantener el plan de ejecucion o´ n es su mayor inconveniente. La planificaci´ planificacion o´ n basada en prioridades constituye una alternativa que en los ´ los  ´ultimos ultimos a˜ anos n˜ os ha alcanzado la madurez necesaria para su utilizaci´ utilizacion o´ n en aplicaciones industriales. Este m´ m etodo e´ todo se basa en asignar est´ est aticamente a´ ticamente prioridades a ´ n, que se encarga de ejecutar en todo momento la tarea m´ las tareas, y en un planificador con expulsio on, m as a´ s prioritaria. Existen m´eetodos todos que, dadas las caracter caracter´´ısticas ısticas del sistema, determinan los tiempos m´aass desfavorables de ejecuci´o on n de las tareas y, por tanto, permiten garantizar el cumplimiento de los plazos de respuesta de las tareas. La mayor flexibilidad de este m´ meetodo ´ todo y la inclusio on ´ n en normas internacionales de mecanismos orientados a su construcci o on, ´ n, facilitan su implantaci´ implantacio on ´ n industrial.

3.

Testin esting gd dee Sistem Sistemas as d dee T Tiempo iempo Real Real::

Las Tareas de Testing son una de las actividades m as a´ s complejas y consumidoras de tiempo de todo el proceso de desarrollo de un sistema de tiempo real [Hea91]. [Hea91]. Normalmente consumen el 50 % del esfuerzo de desarrollo y del presup pre supues uesto to ya que, que, como como vim vimos os en el punto punto ant anteri erior or,, estos estos sistem sistemas as son mucho mucho mas a´ s dif  dif ´ıciles ı ciles de pro probar bar que los sistem sistemas as ”convencionales” ”conv encionales” ya que, adem adem´as a´ s de la satisfacci´ satisfaccion o´ n de los requerimientos requerimientos normales, la correccio on ´ n del Sistema depende del tiempo en que son producidos esos resultados. As´ As ´ı, ı, durante el Testing, hay que evaluar posibles Deadlocks, debe considerarse la manipulacion o´ n de eventos (p.e. procesamiento de interrupciones), el timing de los datos, el paralelismo de las tareas que manejan los datos y, en general, poner  ´enfasis enfasis en las condiciones especiales de tiempo. Adem´ Ademas, a´ s, debe considerarse la relacion o´ n que existe entre el Software de Tiempo Real y el Hardware, lo que tambi´ tambien e´ n produce problemas al momento del testing.

Figura 2: Requerimientos Requerimientos temporales Para los efectos del Testing se entiende   Error temporal  como el hecho que las salidas sean producidas muy temprano (antes de lo previsto) o que la computaci on o´ n de  de  estas e´ stas demore m´ mas a´ s de lo que debe. Asimismo, un  Casos de Prueba, para el an´ analisis a´ lisis temporal, debe llevar el Sistema a tiempos m´ m aximos a´ ximos y m´ m´ınimos ınimos con el objeto de verificar si producen alg´ algun u´ n error de tipo temporal. 3

 

3.1. 3.1.

Es Estad tado o de dell Arte Arte

Para efectuar el Testing a este tipo de Sistemas se ha propuesto una estrategia de 4 pasos: Pruebas de las tareas : Dise˜n no o y ejecuci´on on de pruebas para cada tarea. Descubre defectos en la L´o ogica gica y en la funcionalidad de las Tareas, pero no en timing o comportamiento. Prueba de comportamient comportamiento o: simular el comportamiento comportamiento del sistema y probar los acontecimientos individual individuales. es. Prueba Inter-ta Inter-tareas reas: detectar los errores en la integraci´on on de tareas asincr´o onicas. nicas. Prueba del sistema: detectar los errores de la interfaz de software/hardware.

Obviamente, cada sistema va a tener sus caracter´ caracter´ıısticas sticas propias: las pruebas a un sistema distribuido de tiempo real [HT01] no van a ser las mismas que las de un sistema no distribuido. Asimismo, la ejecuci on o´ n de las pruebas ´  ´ ´ ´ ser ser´a diferente si ´ si estas estas se hacen en l´ lınea ınea [KGL04] o fuera de l´ lınea ınea del sistema. Dado lo anterior, mucho se ha publicado respecto a la forma de llevar a cabo los distintos tipos de Pruebas [Kon01, KT04a, AH02b, JW96, JW00](entre otros). En general, todos los Autores coinciden que la mejor forma de probar un sistema de tiempo real es separando la prueba funcional o l ogica o´ gica de la temporal. As´ As´ı, ı, se utilizar´ utilizara´ un m´ metodo e´ todo para probar la correctitud de la parte l´o ogica gica y otro m´etodo etodo para probar la correctitud de la parte temporal. De esta forma podemos identificar las dos t´eecnicas cnicas m´as as utilizadas para efectuar el Testing de Sistemas de Tiempo Real que son: Para la verificaci´ verificacion o´ n de la parte funcional o l ogica: o´ gica: m eetodo ´ todo ”convencional” (White Box, Black Box). •  Uso de un m´ •  Uso de Aut´omatas omatas Temporizados. Para comprobar el aspecto temporal:

•  Uso de T´ Tecnicas e´ cnicas de Tes Testing ting Evolutivo. •  Uso de L´ Logica o´ gica TCTL. Generalmente se utilizan de acuerdo a la siguiente relaci´on: on: M´eetodo todo convencionalconvencional-Tes Testing ting Evolutivo y Aut´o omatas matas temporizados-L´ogica ogica TCTL.

3.2.. 3.2

Verificac erificaciion o´ n del aspecto funcional o logico o´ gico

Los M´ Metodos e´ todos que se presentan tienen como objetivo el modelar un sistema determinado con el objeto de verificar su correcto funcionamiento l´ logico o´ gico y funcional a trav´ traves e´ s de herramientas de Testing. 3. 3.2. 2.1. 1.

Uso Uso de metodos e´ todos convencionales convencionales

Esto se refiere a la utilizacion o´ n de t´ tecnicas e´ cnicas est´ estandar a´ ndar para la verificaci´ verificacion o´ n de la correctitud funcional o l ogica o´ gica del sistema o aplicaci´ aplicacion. o´ n. Para ello se utilizan t ecnicas e´ cnicas de Caja Blanca (prueba de caminos b asicos, a´ sicos, data flow, loop, etc.) y ´ lisis de valores frontera, diagrama causa-efecto, etc.). de Caja Negra(Particionamient Negra(Particionamiento o de equiv equivalencias, alencias, an´ anaalisis 3.2.2. 3.2.2.

Uso de Aut ut´omatas o´ matas Temporizados

Este m´ metodo e´ todo utiliza Automatas o´ matas temporizados para describir la logica o´ gica y restricciones temporales del sistema bajo prueba. ´ mata que posee un conjunto finito de variables reales, llamadas Un Aut´ Automata o´ mata temporizado [AD94] es un Aut o omata relojes, cuyos valores se incrementan uniformemente con el paso del tiempo. Dichos relojes son utilizados para medir, por ejemplo, temporales el tiempo transcurrido dos eventos, el tiempo espera o la demoracondiciones de una comunicaci´ o on. n.o restricciones inherentes aentre las acciones del sistema sonde expresadas uniendo de activaci on ´Las na cada una de las transiciones del aut´ auto omata. ´ mata. Una transici transici´on o´ n est´ esta´ habilitada, es decir puede ser atravesada, cuando su condici´on condici o´ n asociada es satisfecha por los valores de los relojes. Un reloj puede ser puesto a cero en cualquier transicio on. ´ n.

4

 

´ A todo instante, el valor de un reloj es igual al tiempo transcurrido desde la  ultima vez en que fue puesto a cero. Una transici´on on est´a habilitada, es decir puede ser atravesada, cuando su condici´o on n asociada es satisfecha por los valores de los relojes. relojes. Un reloj puede ser puesto puesto a cero en cualquie cualquierr transici´ transici´on. on. A todo instante, el valor de un reloj es igual al tiempo transcurrido desde la  ultima u´ ltima vez en que fue puesto a cero. La Figura 3 es un ejemplo b´ basico a´ sico de un Automata o´ mata Temporizado, donde se muestran las transiciones entre dos estados   p  y  q . El Aut´ Auto omata ´ mata posee 2 relojes  x  e  y  m aas ´ s el reloj real  t . Se pueden apreciar las condiciones temporales y sus efectos en la tabla adjunta. As´ As´ı, ı, el aut´ automata o´ mata pasar´ pasara´ del estado   p al  q  si se cumple que el valor del reloj  y < 4 y que la entrada sea una  a. Al cambiar de estado, el reloj  x  vuelve a 0.

Figura 3: Ejemplo de un Aut´o omata mata Temporizado Durante la ultima d´ deecada, ´ cada, las tt´ecnicas e´ cnicas de chequeo de modelos para la la verificaci on o´ n de sistemas con restricciones temporales han sido desarrolladas bas´ basandose a´ ndose en la teor teor´´ıa ıa de aut´ automatas o´ matas temporizados. La limitacion o´ n pr´ practica a´ ctica de aplicar estas t´ teecnicas ´ cnicas a sistemas industriales es el gran taman no ˜ o de memoria y tiempo necesarios para explorar y guardar el espacio de estados del modelo del sistema. Sin embargo, [Pet99] mejoro´ el estado de dichas t´ tecnicas e´ cnicas al desarrollar otras tt´eecnicas ´ cnicas de verificaci verificaci´on o´ n simb´ simbolica, o´ lica, ´ n del sistema y aplicada sobre la marcha. Una caracter enfocada a la composici´ composicio on caracter´´ıstica ıstica com´ comun u´ n que tienen las t´ tecnie´ cnicas presentadas en el trabajo son que ellas utilizan eficientes t ecnicas e´ cnicas de resoluci´ resolucion o´ n de limitaciones para representar simbolicamente o´ licamente y manipular el espacio de estados. Las t ecnicas e´ cnicas desarrolladas fueron implementadas en la herramienta de verificaci´ verificacio on ´ n Uppaal [UU04], demostrando la posibilidad de la aplicaci aplicaci´o on ´ n a casos industriales. Otro trabajo interesante es [KT04b], que utiliza los Aut´ Automatas o´ matas temporizados con criterios de cobertura.

3.3.. 3.3

Verificac erificaciion o´ n del aspecto temporal temporal

Los M´ Metodos e´ todos que se presentan tienen como objetivo el modelar las restricciones temporales de un sistema determinado con el objeto de verificar su correcto funcionamiento temporal. 3. 3.3. 3.1. 1.

Uso Uso de Tecnicas e´ cnicas de Testing Evolutivo.

Como dijimos anteriormente, el objetivo de la persona que efect ua u´ a el testing es encontrar el valor de las entradas para las cuales el sistema tiene los m aximos a´ ximos y m´ m´ınimos ınimos tiempos de ejecuci on, o´ n, con el fin de forzar al sistema y verificar la existencia de errores temporales. Es virtualmente imposible encontrar esas entradas analizando y probando un sistema complejo de forma manual. Sin embargo, si la b usqueda u´ squeda de dichas entradas es interpretado como un problema de optimizaci´ optimizacion, o´ n, se puede utilizar la Computaci on o´ n evolucionista para encontrar las entradas que produzcan los efectos deseados. Esta b´usqueda usqueda para datos de prueba exactos por medio de la computaci´o on n evolutivo se llama Testing evolutivo. Este m´eetodo todo ha probado ser una manera prometedora para probar la conducta temporal de sistemas de

5

 

tiempo real. As´ As´ı lo avalan los estudios efectuados por [HP99, HP00, MO98, JW98, HG99, Gro99], as´ as ´ı como tambi´ tambien e´ n [LB02, AB04]. El Testing Evolutivo o  Evolutionary Testing  es un m´etodo etodo de Caja Negra que permite la generaci´o on n autom´aatica tica de casos de prueba y se utiliza como m´etodo etodo especializado e independiente en las pruebas de caracter´ıısticas sticas no funcionales. Este m´ metodo e´ todo permite una busqueda u´ squeda autom´ automaatica ´ tica de los tiempos extremos de ejecuci on. o´ n. La bu usqueda ´ squeda de estos tiempos, m´ maaximos ´ ximos y m m´´ınimos, ınimos, es tratada como un problema de optimizaci on o´ n donde se aplican algoritmos evolucionistas para su resoluci´ resolucio on. ´ n. A su vez, el testing evolutivo se beneficia del hecho que la evaluaci on o´ n de requerimientos temporales es m´ mas a´ s sencilla que la del comportamiento l ogico, o´ gico, as´ as´ı las mismas condiciones temporales se aplican a diferentes situaciones de entradas. Es un procedimiento iterativo que combina los buenos datos de prueba para lograr mejores datos de prueba y cuya mayor fortaleza es el tomar en consideracion o´ n el verdadero ambiente de funcionamiento del sistema bajo prueba (computador,, compilador, etc). Este metodo putador e´ todo efect´ efectua u´ a una prueba del comportamiento comportamiento din din´amico a´ mico del sistema (comportamient (comportamiento o a trav´ traves e´ s del tiempo de ejecuci´ ejecucion, o´ n, requisitos de espacio de memoria). ´n Al utilizar el testing evolutivo para determinar los tiempos extremos de ejecuci´ ejecucion, o´ n, cada individuo de la poblacio on representa un dato de prueba o test datum, con el cual el sistema bajo prueba es ejecutado. Generalmente, la poblaci´o on n inicial es generada de forma aleatoria, sin embargo, si se tiene alg´u un n conocimiento respecto del sistema bajo prueba, eesta ´ sta se puede seleccionar de mejor forma. Para cada dato de prueba se mide el tiempo de ejecuci´on. on. Despu´es, es, la poblaci´o on n es clasificada seg´u un n el tiempo de ejecuci´on ejecuci o´ n determinado. La ubicaci´ ubicacion o´ n asignada a cada individuo depende solo de su posicio on ´ n en el el ranking individual y no del tiempo de ejecuci´ ejecucion o´ n asociado. As´ As´ı, ı, el tiempo de ejecuci´ ejecucion o´ n asociado a cada dato de prueba determina el valor de su ubicacion. o´ n. Si uno busca el caso con el peor tiempo de ejecuci´ ejecucio on, ´ n, los datos de prueba con los tiempos de ejecucio on ´n ´ n. Al contrario, si lo que se busca son los casos con el mejor tiempo de mas a´ s largos obtienen altos valores de ubicaci o on. ejecuci´on, ejecuci o´ n, los individuos con los tiempos de ejecuci´ ejecucion o´ n m as a´ s cortos van a obtener los valores de ubicaci´ ubicacion o´ n altos. ´n Los miembros de la poblaci´ poblacion o´ n son seleccionados con respecto a su ubicaci´ ubicacion o´ n y sujetos a recombinaci´ recombinacion o´ n y mutacio on ´ n, se decide cuales datos de prueba son elegidos para ser para generar nuevos datos de prueba. Por medio de la selecci o on, reproducidos. Con el objeto de mantener la diversidad de la poblaci on o´ n y para evitar una r´ r apida a´ pida convergencia hacia un valor local o optimo, ´ ptimo, se aplica un modo selectivo moderado. Posterior Poste rior a la mutaci´on, on, se verifica verifica que los datos generad generados os est´en en en el dominio de las entradas de los objetos de pruebas, reajustando los datos inv´aalidos. lidos. Los individuos producidos son evaluados ejecutando los objetos de test con con ellos y midiendo los tiempos de ejecuci´on. on. Los nuevos individuos son unidos con la generaci´on on previa para formar una nueva poblaci´on on y proceder a la reinsercion. reinserci´ o´ n. El proceso evolucionario se repite, comenzando por la selecci´ seleccion, o´ n, hasta que se cumpla alguna condici o on ´ n de tt´ermino e´ rmino como por ejemplo, que se alcance un nu umero ´ mero determinado de generaciones o que se registre un tiempo de ejecuci o on ´n fuera de los l´ l´ıımites mites especificados. En este caso, se detecta un error temporal y la prueba es exitosa. Si todos los tiempos de ejecuci´ ejecucion o ´ n la encontrados est´ estaan ´ n dentro de los ll´´ımites ımites establecidos el sistemadel bajo prueba, se puede justificar una confianza en exactitud temporal del sistema. La Figura 4 muestrapara la estructura Testing Evolutivo. 3. 3.3. 3.2. 2.

Uso Uso de Logica o´ gica TCTL.

Muchas propiedades importantes de los sistemas encuentran una expresi´on on natural en l´o ogica gica temporal [Pnu81]. La logica o´ gica temporal de tiempo real TCTL o  Timed Computation Tree Logic   [RAD90, Alu91, THY92], extiende los operadores temporales   ∃ µ  (existe una ejecucion) o´ n) y   ∀ µ”(para todas las ejecuciones) de CTL (”Computation Tree Logic”)[AC82] con restricciones temporales que permiten un razonamiento ”cuantitativo” del tiempo. Si bien CTL es una l´o ogica gica temporal adecuada para sistemas reactivos, eesta ´ sta permite razonamiento ”cualitativo” del tiempo basado en la noci´on on de secuencialidad en las ejecuciones, pero no es posible expresar en ella restricciones temporales cuantitativas. En CTL pueden expresarse propiedades tales como ”inevitableme inevitablemente nte suceder a´´   el evento e” o´ ” la propiedad p se satisface continuamente en todas las ejecuciones del sistema ”. Las f ormulas o´ rmulas de TCTL permiten expresar, adem´ ademaas, ´ s, propiedades tales como ”inevitablemente antes de un tiempo t  suceder´  a el evento e”  o´ ”la propiedad p se satisface continuamente entre los tiempos t    y t   para toda ejecuci´  on del i  f  ormulas ´ rmulas de TCTL son interpretadas sobre los estados de un sistema de tiempo real y se definen a partir sistema”. Las f o de un conjunto de predicados b´aasicos sicos (proposiciones at´omicas) omicas) sobre los estados. El conjunto P de predicados sobre

6

 

Figura 4: Ciclo del Te Testing sting Evolutivo los estados de un grafo temporizado se define en [Oli94] como sigue:  p := @ = l | xi  ≺ c| xi − x j  ≺ d    , =, ≥, >}. Adicionalmente suelen considerarse los siguientes  x j   ∈  X , c  ∈(e),yd  after   L , xi , init  Donde   lb´  ∈   ∈ ∈  9 (e) {