cd universidad de oviedodi002.edv.uniovi.es/~claudio/tesis.pdf · resumen los sistemas reactivos...

Departamento de Informática

OBTENCIÓN AUTOMÁTICA DEL ENTORNO EN LAVERIFICACIÓN MODULAR DE SISTEMAS

REACTIVOS

Tesis DoctoralClaudio de la Riva Álvarez

Dirigida por:

Dr. D. Pablo Javier Tuya González

Gijón, Noviembre de 2003

ResumenLos sistemas reactivos mantienen una continua interacción con el entornorespondiendo ante estímulos externos en función de su estado interno. Esto causaque su comportamiento sea complejo de analizar, y por tanto, suelen estar sujetosa múltiples errores.

Los comprobadores de modelos (model checkers) se han establecido como uno delos métodos de verificación formal más eficaces para asegurar la ausencia deciertos tipos de errores en tales sistemas, principalmente debido a su carácterautomático. Sin embargo, están limitados por el problema conocido comoexplosión de estados (los estados a explorar se incrementan exponencialmente conel tamaño del sistema). La verificación modular permite aliviar el problemaanterior, analizando partes del sistema (componentes) en vez del sistemacompleto. Para ello, es necesario incorporar previamente al componente unconjunto de suposiciones sobre el comportamiento del entorno y queposteriormente deben ser verificadas sobre dicho entorno. En general, estassuposiciones son especificadas por el analista en base al conocimiento que tienesobre el sistema.

En esta tesis se aborda la automatización del proceso de verificación modular,mediante el desarrollo de nuevas técnicas que permiten la generación automáticade los entornos (o suposiciones) de los componentes a verificar. De este modo, nose requiere la intervención del analista en la especificación de las suposiciones,sino que son obtenidas automáticamente mediante la exploración del entorno. Porotra parte, tampoco es necesario la verificación posterior de las suposiciones, yaque están aseguradas por el propio proceso utilizado en su generación.

En primer lugar, se detalla una técnica aplicable sobre componentes individuales.La generación de suposiciones (o restricciones) se basa en la exploración delentorno del componente para la extracción de relaciones entre los eventos queconstituyen su interfaz de entrada. Dichas relaciones muestran restricciones en laaparición de eventos, y se utilizarán como suposiciones en la verificación delcomponente.

La técnica anterior se amplía para la generación de restricciones en varioscomponentes del sistema simultáneamente, de forma que las obtenidas en uncomponente estén influenciadas por las generadas en otro componente. Estopermite obtener suposiciones más ajustadas al comportamiento real de entorno.

Los procesos de generación de suposiciones y verificación están basados en unasemántica de ejecución síncrona similar a la utilizada en otras notaciones (RSML)y herramientas (STATEMATE).

Finalmente, todo lo anterior se ilustra mediante la aplicación de las técnicas adiferentes componentes de un caso de un estudio de tamaño y complejidad notrivial.

Agradecimientos

En algún lugar he leído que la elaboración de una tesis es muy parecida alentrenamiento y realización de un maratón. Durante sus etapas se pasan pormomentos de euforia, cansancio, desganas y desánimos de manera constante. Yo,que he entrenado y corrido algunos maratones, puedo asegurar que las sensacionesanteriores son ciertas. Sobre todo, la final: euforia. Sin embargo, sin un apoyohumano no sería posible.

Por ello, quiero agradecer con unas pocas palabras a todas las personas, que deuna forma u otra han conseguido que finalmente esté redactando estas líneas.

En primer lugar, gracias infinitas a mis padres que siempre me han ayudado yapoyado en todo, y me han inculcado el valor del esfuerzo y del trabajo. A ellosles debo todo.

A mi mujer, Irene, y mi hijo, Álvaro. Ellos fueron quien más de cerca soportaronmis enfados, desplantes y demás. Irene, jamás agradeceré lo bastante tu paciencia,comprensión y generosidad durante todo este tiempo.

A mis hermanos, políticos o no, por el cariño. A mis padres políticos, por ser eso,unos padres.

A Javier Tuya, mi director de tesis, todo un ejemplo de trabajador incansable, ysin cuyos consejos esta tesis no vería la luz.

A Fanjul y de Diego por las conversaciones y cafés. Al resto de compañeros delLaboratorio de Comunicaciones e Ingeniería del Software por el estupendoambiente de trabajo.

A Santi, quien lo da todo por nada. Gracias por tu honradez y tu forma de ser.

A Pepe, por sus consejos, ánimos y ayuda en todo lo que le pedí.

A los compañeros del proyecto ARGO, por las reuniones.

Al resto de compañeros del Área de Lenguajes y Sistemas Informáticos y delDepartamento de Informática, quien han propiciado con medios materiales yhumanos la finalización de esta tesis.

Agradecimientos Institucionales

Esta tesis ha sido realizada con el apoyo de los siguientes proyectos deinvestigación:

� Proyecto AUTOVER, FICYT PB-TIC95-01� Proyecto EDIC, CICYT TIC96-0652

� Proyecto ARGO, CICYT TIC2001-1143-C03:

Subproyecto JASON, CICYT TIC2001-1143-C03-01 (Universidad del PaísVasco)

Subproyecto HERACLES, CICYT TIC2001-1143-C03-02 (Universidad deSevilla)

Subproyecto IDAS, CICYT TIC2001-1143-C03-03 (Universidad de Oviedo)

i

Índice General

1 INTRODUCCIÓN ....................................................................................1

1.1 Generalidades........................................................................................31.2 Motivación ..............................................................................................51.3 Objetivos de la Tesis ..............................................................................61.4 Estructura de la Tesis...........................................................................10

2 SISTEMAS REACTIVOS: ESPECIFICACIÓN Y VERIFICACIÓN.......11

2.1 Introducción..........................................................................................132.2 Métodos de Especificación para Sistemas Reactivos...........................14

2.2.1 Métodos Gráficos..........................................................................................142.2.1.1 SA/RT.......................................................................................................152.2.1.2 Lenguajes Síncronos, Statecharts y RSML .............................................172.2.1.3 Semánticas de Ejecución.........................................................................18

2.2.2 Lógica Temporal ...........................................................................................202.3 Verificación de Sistemas Reactivos......................................................212.4 Comprobación de Modelos..................................................................23

2.4.1 Basada en Lógica Temporal .........................................................................232.4.1.1 Lógica Lineal (LTL)...................................................................................242.4.1.2 Lógica Ramificada (CTL) .........................................................................25

2.4.2 Basada en Teoría de Autómatas ..................................................................252.5 Técnicas para Aliviar la Explosión de Estados .....................................27

2.5.1 Representación Simbólica ............................................................................272.5.2 Verificación “on-the-fly” .................................................................................282.5.3 Técnicas de Reducción.................................................................................29

2.5.3.1 Reducción de Orden Parcial ....................................................................302.5.3.2 Abstracción...............................................................................................30

2.6 Verificación Modular y Composicional ..................................................312.6.1 Minimización Composicional.........................................................................332.6.2 Razonamiento Suposición-Compromiso ......................................................352.6.3 Derivación Automática de Suposiciones ......................................................38

3 COMPUTACIÓN DE ESPACIOS DE ESTADOS.................................41

3.1 Introducción..........................................................................................433.2 Modelo Computacional.........................................................................43

3.2.1 Diagramas de Transición de Estados...........................................................433.2.2 Sistema Reactivo Síncrono...........................................................................44

3.2.2.1 Sintaxis.....................................................................................................453.2.2.2 Semántica ................................................................................................46

3.3 Generación de Configuraciones ...........................................................473.3.1 Esquema Básico de un Algoritmo de Alcanzabilidad ...................................473.3.2 Computación del Conjunto de Configuraciones ...........................................48

3.3.2.1 Representación de Configuraciones ........................................................493.3.2.2 Contador de Micropasos ..........................................................................50

3.3.3 Algoritmo Básico ...........................................................................................51

ii

3.3.4 Computación de Micropasos.........................................................................523.3.5 Ejemplo .........................................................................................................533.3.6 Discusión.......................................................................................................55

3.4 Generación Bajo Condiciones de No Determinismo .............................553.4.1 Computación de Micropasos No Determinista..............................................573.4.2 Ejemplo .........................................................................................................59

3.5 Interfaz con Otros Componentes..........................................................603.5.1 Componentes Cerrados y Abiertos ...............................................................613.5.2 Computación de Micropasos.........................................................................623.5.3 Ejemplo .........................................................................................................633.5.4 Micropasos de Estabilización........................................................................653.5.5 Problemas de No Terminación......................................................................66

3.6 Optimización.........................................................................................663.6.1 Explosión de Configuraciones.......................................................................673.6.2 Cortocircuito de Micropasos..........................................................................68

3.7 Comentarios y Discusión......................................................................70

4 GENERACIÓN AUTOM ÁTICA DE RESTRICCIONES........................71

4.1 Introducción..........................................................................................734.1.1 Ejemplo Introductorio ....................................................................................744.1.2 Descomposición del Problema......................................................................76

4.2 Introducción a las Reglas de Asociación ..............................................774.2.1 Formulación Básica.......................................................................................784.2.2 Otras Técnicas ..............................................................................................784.2.3 Comentarios ..................................................................................................79

4.3 Algoritmos de Cálculo de Reglas de Asociación...................................804.3.1 Definición.......................................................................................................804.3.2 Determinación de Itemsets. Algoritmo Apriori...............................................814.3.3 Generación de Reglas ..................................................................................82

4.4 Utilización de Reglas de Asociación como Restricciones del Entorno ..834.4.1 Restricciones del Entorno .............................................................................834.4.2 Representación de Restricciones del Entorno..............................................844.4.3 Proceso de Determinación de Restricciones del Entorno.............................85

4.5 Modificaciones al Proceso General ......................................................864.5.1 Eliminación de minsupport y minconf............................................................864.5.2 Obtención de large eventsets .......................................................................874.5.3 Generación de Restricciones ........................................................................894.5.4 Normalización de Macropasos......................................................................90

4.6 Comentarios y Discusión......................................................................91

5 GENERACIÓN SIMULT ÁNEA DE ENTORNOS..................................93

5.1 Introducción..........................................................................................955.1.1 Ejemplo Introductorio ....................................................................................97

5.2 Determinación de Entornos para Dos Componentes ............................995.2.1 Algoritmo General .........................................................................................995.2.2 Computación de Configuraciones ...............................................................102

5.2.2.1 Configuraciones para el Primer Micropaso ............................................1035.2.2.2 Configuraciones para el Resto de Micropasos ......................................105

5.2.3 Generación de Restricciones ......................................................................1085.2.3.1 Formato de las Restricciones.................................................................108

iii

5.2.3.2 Extracción de Restricciones en un Micropaso .......................................1095.2.3.3 Restricciones para Todos los Micropasos .............................................109

5.2.4 Condición de Estabilidad ............................................................................1115.2.4.1 Estabilidad en un Componente ..............................................................1115.2.4.2 Estabilidad del Sistema..........................................................................1135.2.4.3 Longitud Máxima de Macropaso ............................................................113

5.2.5 Ejemplo Completo.......................................................................................1135.3 Determinación de Entornos para Varios Componentes ......................116

5.3.1 Algoritmo General .......................................................................................1165.3.2 Ejemplo Completo.......................................................................................118

5.4 Comentarios y Discusión....................................................................121

6 IMPLEMENTACIÓN Y EVALUACIÓN...............................................123

6.1 Descripción de las Herramientas de Experimentación........................1256.1.1 Proyecto AUTOVER ...................................................................................1256.1.2 Proyecto EDIC ............................................................................................1266.1.3 Herramientas de Generación de Restricciones ..........................................1276.1.4 El Comprobador de Modelos SPIN.............................................................1286.1.5 Conjunto de Herramientas de Soporte a la Verificación Modular...............129

6.2 Caso de Estudio: La Caldera de Vapor ..............................................1306.2.1 Descripción del Sistema .............................................................................131

6.2.1.1 Modos de Operación..............................................................................1326.2.1.2 Mensajes Enviados y Recibidos por el Programa de Control................1336.2.1.3 Comportamiento Físico de la Caldera....................................................135

6.2.2 Modelo Operacional....................................................................................1356.2.2.1 Control....................................................................................................1376.2.2.2 All Pumps ...............................................................................................1396.2.2.3 Water......................................................................................................1436.2.2.4 Steam .....................................................................................................145

6.2.3 Requisitos del Programa de Control: Propiedades.....................................1476.2.3.1 Modo Normal..........................................................................................1486.2.3.2 Modo Degradado....................................................................................1496.2.3.3 Modo de Rescate ...................................................................................1506.2.3.4 Modo Parada de Emergencia ................................................................1516.2.3.5 Detección de Fallos en Unidades Físicas..............................................1526.2.3.6 Otras.......................................................................................................153

6.3 Verificación del Sistema Completo .....................................................1566.3.1 Tamaño del Sistema...................................................................................1566.3.2 Resultados Obtenidos.................................................................................157

6.4 Verificación Modular ...........................................................................1586.4.1 Modularización de Propiedades..................................................................1596.4.2 Formación de Componentes para Verificación...........................................160

6.5 Verificación de Componentes.............................................................1636.5.1 Componente CONTROL.............................................................................164

6.5.1.1 Verificación sin Suposiciones.................................................................1656.5.1.2 Verificación con Suposiciones Manuales...............................................1656.5.1.3 Verificación con Suposiciones Automáticas ..........................................1686.5.1.4 Análisis de Resultados...........................................................................173

6.5.2 Componente ALL PUMPS ..........................................................................1786.5.2.1 Verificación de una Bomba sin Suposiciones ........................................1796.5.2.2 Verificación de una Bomba con Suposiciones Manuales ......................1806.5.2.3 Verificación de una Bomba con Suposiciones Automáticas..................1806.5.2.4 Análisis de Resultados...........................................................................184

iv

6.5.2.5 Verificación de dos Bombas...................................................................1876.5.2.6 Análisis de Resultados ...........................................................................1886.5.2.7 Verificación del resto de bombas ...........................................................191

6.5.3 Componentes WATER y STEAM................................................................1926.5.4 Verificación de Ciclos de No Progreso........................................................1946.5.5 Otras Particiones en Componentes ............................................................196

6.6 Resumen y Discusión.........................................................................197

7 CONCLUSIONES................................................................................201

7.1 Resumen y Conclusiones...................................................................2037.2 Contribuciones ...................................................................................2057.3 Trabajo Futuro....................................................................................206

8 REFERENCIAS...................................................................................209

v

Índice de FigurasFigura 1: Proceso general de verificación modular............................................................6

Figura 2: Verificación con suposiciones automáticas (I) ....................................................9

Figura 3:Verificación con suposiciones automáticas (II) ....................................................9

Figura 4: Modelo del entorno ...........................................................................................15

Figura 5: Modelo de comportamiento...............................................................................16

Figura 6: Diagrama de transición de estados...................................................................17

Figura 7: Macropasos y micropasos ................................................................................20

Figura 8: Verficación composicional y modular................................................................32

Figura 9: Minimización composicional..............................................................................33

Figura 10: Algoritmo de alcanzabilidad ............................................................................48

Figura 11: Algoritmo para la generación de configuraciones...........................................51

Figura 12: Computación de micropasos...........................................................................52

Figura 13: Secuencia de generación de configuraciones ................................................53

Figura 14: Especificación de un componente ..................................................................54

Figura 15: Ejemplo de generación de configuraciones ....................................................54

Figura 16: Transiciones no deterministas ........................................................................56

Figura 17: Configuraciones no deterministas...................................................................57

Figura 18: Computación de micropasos (no determinista) ..............................................58

Figura 19: Ejemplo de transiciones no deterministas ......................................................59

Figura 20: Componente cerrado ......................................................................................61

Figura 21: Componente abierto........................................................................................61

Figura 22: Computación de micropasos con interfaz de otro componente......................63

Figura 23: Ejemplo: Configuraciones con interfaz de otro componente ..........................64

Figura 24: Micropaso de estabilización ............................................................................65

Figura 25: Componente que no finaliza ...........................................................................66

Figura 26: Explosión de estados en la generación de configuraciones...........................68

Figura 27: Ejemplo: Cortocircuito de micropasos ............................................................68

Figura 28: Cortocircuito en los micropasos......................................................................69

Figura 29: Generación automática y codificación de suposiciones .................................73

Figura 30: Ejemplo: Sistema a verificar modularmente ...................................................74

Figura 31: Ejemplo: Especificación del componente C1...................................................75

Figura 32: Algoritmo para generación de restricciones....................................................77

Figura 33: Algoritmo Apriori..............................................................................................81

Figura 34: Algoritmo para generación de candidatos ......................................................82

Figura 35: Algoritmo para generación de reglas de asociación.......................................83

vi

Figura 36: Utilización de reglas de asociación como restricciones del entorno...............86

Figura 37: Algoritmo para la computación de eventsets ..................................................88

Figura 38: Algoritmo para la generación de restricciones del entorno.............................89

Figura 39: Generación simultánea de entornos ...............................................................96

Figura 40: Ejemplo: Sistema a verificar modularmente (II) ..............................................97

Figura 41: Ejemplo: Componente C1 ................................................................................97

Figura 42: Ejemplo: Componente C2 ................................................................................98

Figura 43: Algoritmo de generación simultánea de restricciones (I) ..............................101

Figura 44: Estrategias de generación de configuraciones .............................................103

Figura 45: Esquema de generación de configuraciones para el primer micropaso.......104

Figura 46: Algoritmo de generación de configuraciones para el primer micropaso.......105

Figura 47: Configuraciones para el resto de micropasos (con restricciones) ................106

Figura 48: Configuraciones para el resto de micropasos (sin restricciones) .................106

Figura 49: Algoritmo de generación de configuraciones para el micropaso n ...............107

Figura 50: Algoritmo de generación de restricciones para un micropaso ......................109

Figura 51: Pasos en la obtención de restricciones para dos componentes...................111

Figura 52: Ejemplo: Avance de un componente en condiciones de estabilidad ............112

Figura 53: Espacio de configuraciones para los componentes de la Figura 52............114

Figura 54: Ejemplo: Restricciones en varios componentes (I) .......................................117

Figura 55: Algoritmo de generación simultánea de restricciones (II) .............................118

Figura 56: Ejemplo: Restricciones en varios componentes (II) ......................................119

Figura 57: Animación de contraejemplos en AUTOVER................................................126

Figura 58: Herramientas de soporte para la ejecución de los experimentos .................129

Figura 59: Estructura física de la caldera de vapor ........................................................132

Figura 60: Diagrama de subsistemas de la caldera de vapor ........................................136

Figura 61: Transformación de datos...............................................................................137

Figura 62: CONTROL: Diagrama de subsistema...........................................................138

Figura 63: CONTROL: Diagramas de transición de estados .........................................139

Figura 64: ALLPUMPS: Diagrama de subsistema .........................................................140

Figura 65: ALLPUMPS: Diagramas de transición de estados........................................140

Figura 66: PUMP: Diagrama de subsistema ..................................................................141

Figura 67: PUMP: Diagramas de transición de estados ................................................142

Figura 68: PUMP: Procesos de datos ............................................................................143

Figura 69: WATER: Diagrama de subsistema................................................................143

Figura 70: WATER: Diagrama de transición de estados................................................144

Figura 71: WATER: Procesos de datos discretos ..........................................................144

Figura 72: WATER: Procesos de datos continuos .........................................................145

Figura 73: STEAM: Diagrama de subsistema ................................................................145

vii

Figura 74: STEAM: Diagrama de transición de estados ................................................146

Figura 75: STEAM: Procesos discretos de datos ..........................................................147

Figura 76: STEAM: Procesos de datos continuos .........................................................147

Figura 77: Componentes de la caldera de vapor ...........................................................158

Figura 78: CONTROL: Comparativa de rendimiento con GenInd..................................175

Figura 79: CONTROL: Comparativa de rendimiento con GenPar .................................176

Figura 80: ALLPUMPS (1 bomba): Comparativa de rendimiento ..................................186

Figura 81: ALLPUMPS (2 bombas): Diagrama de subsistema......................................187

Figura 82: ALLPUMPS (2 bombas): Comparativa de rendimiento ................................190

Figura 83: Partición de componentes alternativa...........................................................196

ix

Índice de TablasTabla 1: Exploración de transiciones no deterministas.....................................................60

Tabla 2: Diferentes grados de automatización en la generación de restricciones............96

Tabla 3: Encadenamiento de acciones en la generación de restricciones en paralelo ..100

Tabla 4: Restricciones para el sistema de la Figura 52 .................................................115

Tabla 5: Configuraciones calculadas/almacenadas para el ejemplo de la Figura 52....116

Tabla 6: Configuraciones y restricciones para el ejemplo de la Figura 54 ....................117


Tabla 8: Configuraciones calculadas/almacenada para el Ejemplo de la Figura 56 .....120


Tabla 10: Tamaño del modelo de la caldera de vapor....................................................156

Tabla 11: CONTROL: Rendimiento de GenInd sobre diferentes entornos.....................169

Tabla 12: CONTROL: Restricciones obtenidas con GenInd sobre diferentes entornos.170

Tabla 13: CONTROL: Rendimiento de GenPar sobre diferentes entornos ....................172

Tabla 14: CONTROL: Nuevas suposiciones obtenidas con GenPar..............................172

Tabla 15: CONTROL: Resultados de SPIN en la verificación ........................................174

Tabla 16: CONTROL: Resumen de resultados...............................................................177

Tabla 17 : ALLPUMPS: Suposiciones Manuales ............................................................180

Tabla 18: ALLPUMPS: Rendimiento de GendInd sobre el componente CONTROL .....181

Tabla 19: ALLPUMPS: Restricciones obtenidas con GenInd sobre CONTROL ............182

Tabla 20: ALLPUMPS: Rendimiento de GenPar sobre ALLPUMPS y CONTROL........183

Tabla 21: ALLPUMPS: Resultados de SPIN en la verificación.......................................185

Tabla 22: ALLPUMPS (1 bomba): Resumen de resultados............................................187

Tabla 23: ALLPUMPS (2 bombas): Resultados de SPIN en la verificación ...................189

Tabla 24: ALLPUMPS (2 bombas): Resumen de resultados..........................................191

Tabla 25: WATER: Resultados de SPIN en la verificación .............................................193

Tabla 26: Coste en tiempo para varias verificaciones de un componente .....................198

Capítulo 1Introducción

Introducción

3

1.1 GeneralidadesLos sistemas software y hardware están incrementando contínuamente supresencia en muchos aspectos de la vida cotidiana. Consecuentemente, estossistemas han ido creciendo en complejidad, con la consiguiente posibilidad de unaumento de errores durante su utilización. Estos errores pueden tenerconsecuencias catastróficas en términos económicos, de tiempo o incluso de vidashumanas, por lo que su detección en las fases tempranas de desarrollo es unaspecto que se debe considerar como muy importante. Por ello, existe unademanda creciente por parte de la industria de nuevos métodos y técnicas queincrementen la fiabilidad en el diseño y construcción de productos hardware ysoftware. Por otra parte, desde un punto de vista puramente teórico, es necesarioproporcionar bases matemáticas sólidas, que permitan al ingeniero combinar suexperiencia con una base metodológica asentada formalmente.

La búsqueda de nuevas técnicas, métodos y heurísticas para asegurar elfuncionamiento correcto de los sistemas basados en computador se hace máscompleja cuando han de aplicarse a sistemas reactivos. Según Manna y Pnueli[Mann91], se define un programa reactivo como:

“Un programa reactivo es un programa cuyo papel es mantener una continuainteracción con su entorno en vez de calcular un valor tras su finalización”De acuerdo con esta definición, los sistemas reactivos se contraponen a lossistemas transformacionales (que producen una salida en función de sus entradas),ya que mantienen una continua interacción con su entorno, respondiendo ante losestímulos o eventos externos. La respuesta obtenida (salida), no está solamente enfunción de sus entradas, sino también en función del propio estado interno delsistema. Estos tipos de sistemas son típicamente concurrentes, lo que implica queestán formado por varios procesos que se ejecutan de forma simultánea y paralelaentre sí. Por tanto, el análisis de un sistema reactivo es complejo debido a la grancantidad de situaciones posibles que es necesario tener en cuenta.

Según el estándar Std 610.12 -1990 de IEEE [IEEE90], el término verificacióntiene dos acepciones diferentes:

“(1) El proceso de evaluar un sistema o componente para determinar que losproductos obtenidos de una determinada fase de desarrollo satisfacen lascondiciones impuestas al comienzo de dicha fase. (2) Prueba formal de lacorrección de un programa”

La primera de las definiciones es más general, y el proceso de verificación puedeser realizado utilizando técnicas informales, tales como, por ejemplo, lasrevisiones formales, recorridos (walkthroughts), inspecciones o pruebas. Lasegunda explícitamente introduce el concepto de formalidad (verificación formal).Incluye el uso de técnicas cuyo objetivo es la creación de un modelo matemáticodel sistema, utilizando un lenguaje para especificar las propiedades deseadas quedebe cumplir. Mediante un método de prueba se verifica que las propiedades sesatisfacen en el modelo.

Introducción

4

Si la verificación es realizada en su mayor parte sobre un computador, se habla engeneral de verificación automática. Cuando el sistema se puede especificar ymodelar mediante un sistema de estados finito, el proceso de verificación sedenomina verificación de sistemas de estados finitos. A diferencia de las técnicasmás habituales empleadas para el aseguramiento de calidad, como por ejemplo laprueba del software, donde se ejecuta el programa con determinadas entradas paradescubrir posibles errores, las técnicas automáticas de verificación formalconsideran todas las posibles ejecuciones de un sistema (en el caso de un sistemade estados finito). Un inconveniente de estas técnicas está en el desconocimientogeneral que un usuario medio posee de los formalismos matemáticos subyacentesa la verificación formal.

Los comprobadores de modelos (model checkers) [Clar99] son herramientascompletamente automáticas aplicadas a la verificación de sistemas de estadosfinitos. Normalmente el sistema se modela utilizando una máquina de estadosfinitos y las propiedades a verificar se expresan en algún tipo de lógica temporal.El proceso de verificación consiste en realizar una exploración exhaustiva delespacio de estados del sistema, para comprobar que el sistema es un modelo de laespecificación (propiedades a verificar). En caso de que la propiedad no se cumplaen el sistema, el comprobador de modelos genera un contraejemplo, o traza deejecución que falsea la propiedad.

Los comprobadores de modelos sufren el problema conocido como explosión deestados, causado por la relación exponencial entre el número de estados en elmodelo del sistema respecto al número de procesos a partir del cual se construye.Como consecuencia, los sistemas, a partir de un cierto tamaño, no pueden serverificados utilizando un comprobador de modelos.Por ello, uno de los principales objetivos en el campo de la verificación formal y,particularmente en la comprobación de modelos, está en el desarrollo dealgoritmos y estructuras de datos que permitan manejar espacios de estadosgrandes. Técnicas tales como, por ejemplo, la verificación simbólica [McMi93](donde se utilizan estructuras de datos para representar eficientemente el espaciode estados) y la reducción de orden parcial [Gode90] (que evita la generación delespacio de estados completo), permiten abordar parcialmente el problema de laexplosión de estados sobre ciertos tipos de sistemas reactivos.

Un enfoque prometedor para solucionar el problema de la explosión de estadosconsiste en utilizar técnicas modulares para la verificación (verificación modularo composicional [Pnue85]), de modo que la veracidad o falsedad de una propiedadsobre un sistema, se pueda deducir a partir de la veracidad o falsedad de loscomponentes o subsistemas que lo forman. De este modo, se traslada el problemade construcción del espacio de estados del sistema completo, a la construcción deespacios de estados para su componentes, con menor tamaño y manejables por elcomprobador de modelos. Entre estas técnicas, una de las más estudiadas desde elpunto de vista teórico, aunque no empleadas en la misma proporción en lapráctica, se encuentran las denominadas suposición-compromiso [Abad95]. Dadoque los componentes o subsistemas se consideran independientemente, esnecesario realizar alguna suposición sobre el comportamiento del resto decomponentes, y luego garantizar sobre ellos que la suposición es correcta

Introducción

5

(compromiso). Este enfoque es similar a los conductores (drivers) y resguardos(stubs) utilizados en la prueba incremental del software. En cierta forma, lassuposiciones actúan como limitadores del comportamiento del entorno,restringiendo el orden y valores de los eventos que el entorno puede suministrar alcomponente. Por ello, a lo largo de esta tesis se utilizará el término de restriccióndel entorno con el mismo significado que el de suposición.

Aunque los métodos automáticos de verificación, como la comprobación demodelos, fundamentalmente se han aplicado a sistemas hardware, estos métodosde verificación pueden jugar un papel importante en el desarrollo de sistemassoftware de calidad. Con el incremento de las aplicaciones distribuidas sobreInternet y la adopción y utilización masiva de lenguajes como Java, laconcurrencia es un elemento bastante común. Por ello, es de esperar que sedesarrollen nuevas técnicas y metodologías que permitan un uso efectivo yeficiente de los comprobadores de modelos como herramientas dentro del ciclo devida de desarrollo de un producto software.

1.2 MotivaciónLas técnicas composicionales y modulares basadas en suposición-compromisopara la verificación formal de sistemas reactivos han sido ampliamente estudiadaspor varios investigadores en las últimas décadas (por ejemplo, [Pnue85] [Alur96][McMi99]), por ser uno de los enfoques que mejor solucionan el problema de laexplosión de estados. Sin embargo, su aplicabilidad a casos prácticos no haevolucionado a la misma velocidad que su fundamento teórico (como comentaShankar [Shan97], “los distintos sistemas de inferencia basados en suposición-compromiso han sido más estudiados que aplicados”).

Una de las principales razones está en que es necesaria la intervención del usuarioen varias fases de su aplicación. Concretamente, el usuario debe especificar eincorporar al proceso de verificación de cada componente un entorno(suposiciones) en el cual se ejecutará. De este modo, el proceso de verificaciónmodular generalmente es realizado de manera interactiva e incremental. En primerlugar, el analista comprueba la propiedad sobre el componente sin establecerninguna suposición sobre el entorno. Si el comprobador de modelos devuelve uncontraejemplo que no es real (falso positivo), el analista realiza manualmentenuevas especificaciones de suposiciones lo suficientemente fuertes para eliminarlos falsos positivos y que a su vez reflejan adecuadamente el comportamiento delentorno (compromiso).

El proceso de incorporación de suposiciones, además de posibilitar la introducciónde errores en su especificación, no es una tarea trivial, ya que implica unconocimiento importante del sistema y de su semántica de ejecución. Además, lassuposiciones así especificadas generalmente son pesimistas [Alfa01a], ya quelimitan escasamente el comportamiento del entorno, lo que en muchos casos no esadecuado en el proceso de verificación del componente. Por ello, un aspectoimportante en la verificación modular es la búsqueda de las suposiciones másadecuadas [Henz98] que permitan limitar el comportamiento del resto del sistemamientras se preservan las propiedades a verificar. Sin duda, un soporte automático

Introducción

6

para construir los entornos de un componente ayudaría a obtener las suposicionesmás adecuadas.

Sin embargo, la construcción automática de entornos para la verificación modularde componentes hasta el momento ha recibido escasa atención por parte de lacomunidad investigadora. Básicamente, y como se comenta arriba, los principalesestudios son fundamentalmente teóricos, sobre sistemas formales de inferenciaque permiten razonar sobre el sistema completo a partir de sus componentesmediante el empleo de suposiciones y compromisos. Sin embargo, no se indicacomo éstos se deben de especificar y construir, dejando al usuario libertad en suespecificación e incorporación a la verificación del componente.

Por ello, este trabajo pretende rellenar el hueco actualmente existente en técnicasy métodos para la construcción automática de entornos en un contexto deverificación modular. De esta forma, en el proceso general de verificaciónúnicamente será necesaria la intervención del usuario para realizar la particióninicial en componentes del sistema, con las consiguientes reducciones de esfuerzoy recursos computacionales empleados en el proceso de verificación del sistemacompleto.

1.3 Objetivos de la TesisPara situar y clarificar los objetivos de esta tesis, en la Figura 1 se muestra elesquema general seguido durante los procesos de especificación y verificaciónmodular de un sistema (reactivo) mediante el paradigma suposición-compromiso[Abad95] y utilizando como herramienta de verificación un comprobador demodelos.

ModularizarEspecificación

Propiedades del SistemaModelo del Sistema

Componente 1 Componente 2 Componente n

RealizarEspecificación

Ingeniero

EspecificarSuposiciones

Comprobador de Modelos

(Verificación Componente i)

DescargarSuposiciones

Suposiciones Componente i

Compromisos Componente i

Figura 1: Proceso general de verificación modular

Introducción

7

Previamente al proceso de verificación, el ingeniero realiza la especificación delsistema mediante un modelo del sistema y un conjunto de requisitos (propiedades)deseables. Suponiendo que el sistema así especificado no pueda ser directamenteverificado con un comprobador de modelos debido a su tamaño (explosión deestados), el ingeniero puede dividir la especificación en componentes de menortamaño con el objetivo de que éstos puedan ser manejados por el comprobador demodelos. Este proceso es indicado en la Figura 1 como “ModularizarEspecificación”. Sin embargo, para que cada uno de los componentes pueda serverificado individualmente, es necesario incorporar un entorno abstracto con elque interacciona cada uno de ellos y que represente al resto del sistema. En elenfoque suposición-compromiso, los entornos abstractos se especifican comosuposiciones que realiza el componente bajo verificación sobre el entorno, y queposteriormente éste debe garantizar en forma de compromisos (“DescargarSuposiciones”).

Si bien la técnica de verificación utilizada (comprobación de modelos) escompletamente automática, el proceso de verificación modular no lo es. Aparte derealizar la especificación del sistema y posteriormente su modularización, elanalista debe especificar manualmente las suposiciones de cada componente.Como se comenta en la sección anterior, la especificación manual de lassuposiciones se basa en el conocimiento que tiene el ingeniero sobre el sistema, ydado que éste, debido a su reactividad, es inherentemente complejo, la tarea no sepuede considerar como sencilla. Además, puede que las suposicionesespecificadas no sean correctas o lo suficientemente adecuadas para representar elentorno, lo que puede originar falsos positivos. En cualquiera de los casos, lassuposiciones realizadas deben ser verificadas sobre el entorno, lo que implica queen el proceso de verificación de un componente sean necesarias al menos dosejecuciones del comprobador de modelos, una para la verificación del componentecon las suposiciones del entorno y otra para la verificación de las suposicionessobre el entorno.

Por tanto, el objetivo fundamental de esta tesis se centra en convertir al procesomanual “Especificar Suposiciones” de la Figura 1 en un proceso automático, deforma que las suposiciones sean obtenidas del entorno del componente bajoverificación sin necesidad de la intervención del usuario. Como consecuencia deello, igualmente desaparecería del esquema el proceso “Descargar Suposiciones”,ya que si éstas se obtienen automáticamente del entorno del componente no esnecesario verificarla de nuevo sobre él. A diferencia de otras aproximacionesutilizadas para aliviar el problema de explosión de estados, por ejemplo [Cheu96][Cous99], donde el principio es “primero abstraer y luego verificar laabstracción”, el enfoque seguido en esta tesis es similar al propuesto en[Alur99]:“primero analizar los componentes, luego usar la información obtenidapara abstraer y finalmente verificar la composición de abstraciones”.

Este objetivo principal se articulará en los siguientes puntos:

1. Especificación formal de la semántica de ejecución del sistema reactivo y delos componentes que lo forman, con el fin de reducir las interpretacionesambiguas sobre la ejecución del modelo. Este punto es fundamental, tanto parael proceso de verificación del sistema, como para el desarrollo e

Introducción

8

implementación de las técnicas de generación automática de entornospropuestas a continuación.

2. Desarrollo de técnicas de exploración de espacios de estados para computar elentorno del componente bajo verificación. El objetivo es generar el conjuntode todas las posibles configuraciones del entorno, de modo que a partir deellas, se puedan extraer las suposiciones automáticamente. Como se comentaen el objetivo anterior, la computación de configuraciones debe realizarse deacuerdo a la semántica utilizada en el modelado.

3. Desarrollo de técnicas para la extracción automática de patrones decomportamiento del entorno de un componente a partir de su conjunto deconfiguraciones. Estos patrones de comportamiento se utilizarán comosuposiciones (restricciones) en la verificación del componente con uncomprobador de modelos.

4. Ampliación de la técnica anterior para generar automáticamente suposicionessobre varios componentes simultáneamente, de forma que las suposicionesobtenidas para un componente puedan estar influenciadas por las generadas enotros componentes con los que se comunica. Esto permitirá obtenersuposiciones mucho más ajustadas al comportamiento real del entorno de uncomponente.

5. Integración de las suposiciones generadas automáticamente en el lenguajesoportado por el comprobador de modelos utilizado para la verificación de loscomponentes.

Como objetivos secundarios, o que servirán de soporte a los indicadosanteriormente, se incluyen:

� Utilización de métodos gráficos para la especificación del sistema reactivo averificar. Estos formalismos gráficos tienen la ventaja, respecto a otros másformales, de ser más intuitivos y estar soportados por herramientas CASE. Sinembargo, en general, no tienen una semántica formalmente definida. Elprimero de los objetivos principales aborda este problema.

� Utilización de comprobadores de modelos para la verificación de loscomponentes. Frente a otras técnicas de verificación formal (por ejemplo, loscomprobadores de teoremas) ofrecen la ventaja de ser completamenteautomáticos y requerir menos conocimiento matemático.

En esta tesis, como método gráfico de especificación se utilizará el formalismopropuesto por Ward y Mellor y que es conocido como SA/RT [Ward86]. Elmodelo se dotará de una semántica de ejecución muy similar a la utilizada enmétodos y herramientas basados en Statecharts [Hare87a], como son RSML[Leve94] y STATEMATE [Hare96]. Los entornos se generarán automáticamentebasándose en una modificación del algoritmo Apriori [Agra93b] para la obtenciónde reglas de asociación. Para la verificación de las propiedades sobre loscomponentes del sistema se usará el comprobador de modelos SPIN [Holz03].

En la Figura 2 se resume la metodología de desarrollo que sigue en la tesis para lageneración de suposiciones (restricciones) y posterior verificación de un

Introducción

9

componente. Los procesos indicados cubren los objetivos 1, 2, 3 y 5 indicadosanteriormente.

Componente C1 Componente C2

Propiedades C2

ComputarConfiguraciones

ExtraerSuposiciones

X → Y

Y → AB

YZ → B

.....

Comprobador deModelos

CodificarSuposiciones

NO (Contrajemplo) SI

Figura 2: Verificación con suposiciones automáticas (I)

La generación de suposiciones de forma simultánea y en paralelo para varioscomponentes (objetivo 4) se resume en la Figura 3.


Propiedades C2


ExtraerSuposiciones

X → Y

Y → AB

YZ → B

.....




Propiedades C1

P → Y

QT → FG

Y → Q

.....

Figura 3:Verificación con suposiciones automáticas (II)

Introducción

10

1.4 Estructura de la TesisEn el Capítulo 2 se proporciona una visión general de los métodos gráficos deespecificación utilizados para realizar el modelo del sistema, y de la lógicatemporal para especificar las propiedades deseadas. Se introduce la verificaciónformal, con énfasis especial en la verificación automática con comprobadores demodelos, y en las diferentes técnicas existentes para evitar el problema de laexplosión de estados (principalmente el razonamiento basado en suposición-compromiso).

En el Capítulo 3 se detalla el modelo computacional basado en máquinas deestados y dotado de una semántica de pasos similar a RSML, y se describen losalgoritmos para la generación del espacio de estados que servirán como base a laextracción de suposiciones.

En el Capítulo 4 se presenta un método para la generación de suposiciones para uncomponente a partir del espacio de estados de su entorno. Las suposiciones sonobtenidas en forma de regla de asociación sobre los eventos que comunican elentorno y el componente.

En el Capítulo 5 se extiende la técnica anterior para la generación de lassuposiciones en varios componentes simultáneamente.

En el Capítulo 6 se aplican las técnicas anteriores a un caso de estudio típico en elcampo de la especificación y verificación de sistemas reactivos: el problema decontrol de la caldera de vapor.

Finalmente, en el Capítulo 7 se enumeran las conclusiones y sugerencias paratrabajos futuros.

Capítulo 2Sistemas Reactivos:Especificación y VerificaciónEn este Capítulo se revisarán brevemente algunos de los formalismos gráficosutilizados para la especificación de los sistemas reactivos. Se introducirán tambiénlas lógicas temporales como lenguajes formales de especificación de laspropiedades que ha de cumplir un sistema.

A continuación se presentará el concepto de verificación formal y los distintosenfoques aplicados a sistemas reactivos para realizar ésta, con enfásis en laverificación automática y en los comprobadores de modelos como herramientasque la soportan. Se revisan las técnicas principales para aliviar el problema de laexplosión combinatoria de estados inherente a los comprobadores de modelos,especialmente el paradigma modular y composicional basado en el razonamientosuposición-compromiso.

Finalmente, se discuten algunas de las aproximaciones existentes para laautomatización del proceso de verificación modular mediante la generaciónautomática de suposiciones.

Sistemas Reactivos: Especificación y Verificación

13

2.1 IntroducciónLa especificación de un sistema puede realizarse de múltiples formas. Según elestándar Std-1233-1998 de IEEE [IEEE98], los requisitos pueden especificarsetextualmente, con modelos o mediante una combinación de ambos, de forma quetengan múltiples vistas en función de la audiencia a quién van dirigidos.

Un modelo [IEEE98] es una simplificación de la realidad cuyo objetivo es facilitarla comprensión del sistema, posiblemente complejo, que se está desarrollando, ypuede ser realizada de forma gráfica, textual o matemática.

En muchas ocasiones modelo y especificación se confunden, pero realmente noson equivalentes, ya que en general los modelos se utilizan para representar unaespecificación, un diseño o en general cualquier otro proceso. Cuando laespecificación es realizada utilizando modelos, se denomina especificaciónbasada en modelos.

Igualmente, los conceptos de verificación y validación también se utilizan comosinónimos. De acuerdo con el estandar Std 610.12-1990 de IEEE [IEEE90], laverificación describe que cada producto de desarrollo es conforme al producto delcual se ha derivado. Por ejemplo, en el caso de una especificación software,indicará que ésta es conforme a las necesidades del cliente, en el caso de undiseño que está conforme a la especificación, etc. El proceso de validaciónestablece que el producto final es conforme con la especificación de requisitosrealizada al inicio del proceso de desarrollo.

La especificación de un sistema se compone de una serie de requisitos funcionalesy requisitos no funcionales, y puede seguir dos enfoques diferentes:

� Operacional, donde se describe el proceso por el cual el sistema va a obtenerun resultado.

� Declarativa, se describe el propio resultado a obtener sin referencias al modode operación.

Las especificaciones declarativas son más fáciles de desarrollar y mantener quelas operacionales, debido a que muestran los resultados a obtener en vez dedetallar la solución. Sin embargo, en general, son más abstractas que lasoperacionales permitiendo una total libertad en el diseño e implementación, por loque un modelo derivado de esta especificación puede ser muy difícil de obtener.Las especificaciones operacionales tienen la desventaja de estar muy cercanas aldiseño e implementación, ya que en cierto modo describen el “cómo” del sistema,sin embargo, la transición de la especificación a la implementación es más sencillaque el caso de la especificación declarativa. Para las especificacionesoperacionales pueden utilizarse formalismos gráficos (por ejemplo, máquinas deestados), mientras que las declarativas se realizan textualmente, bien en lenguajenatural o mediante un lenguaje formal, por ejemplo en lógica temporal.

La verificación puede realizarse en base a los siguientes enfoques:

� Basado en modelos, donde el razonamiento se realiza sobre el modelooperacional del sistema. Un ejemplo es la técnica conocida como análisis de


14

alcanzabilidad donde se explora el grafo de estados del sistema para buscarcódigo “muerto”, interbloqueos, etc.

� Sintáctico, el razonamiento es realizado sobre la especificación declarativa,utilizando fundamentalmente reglas de deducción.

� Híbrido, donde se combinan las especificaciones declarativas y operacionalesen el razonamiento.

El razonamiento híbrido se puede utilizar con el enfoque de lenguaje doble (duallanguage) [Feld94], y es uno de los aspectos más interesantes de la verificaciónformal, ya que permite realizar especificaciones utilizando cada uno de losmodelos (operacional y declarativo) en aquellas partes en las que cada uno deellos sea más adecuado, y comprobar la consistencia entre ambos. Así, se puedeutilizar una herramienta gráfica para soportar el proceso de desarrollo de laespecificación operacional y un comprobador de modelos para verificar laespecificación declarativa sobre el modelo operacional.

En esta tesis se utiliza este estilo de razonamiento, donde el modelo operacional(máquinas de estados) se complementa con una serie de propiedades que ha decumplir el sistema, especificadas como un modelo declarativo. La verificaciónserá realizada utilizando un comprobador de modelos, de forma que éstecomprobará la consistencia entre ambas especificaciones. La especificaciónoperacional se realizará utilizando como formalismo el método SA/RT [Ward86],dotado con una semántica basada en pasos similar a la utilizada en RSML[Leve94] y STATEMATE [Hare90]. El modelo declarativo se especificaráutilizando lógica temporal.

En las siguientes secciones de este capítulo, se resumirán cada uno de losformalismos utilizados en la especificación operacional y declarativa y en laverificación del sistema.

2.2 Métodos de Especificación para SistemasReactivos

Previamente a cualquier proceso de verificación formal sobre un sistema reactivo,es necesario realizar una especificación formal del sistema en base a sucomportamiento y a las propiedades que se desean cumpla el sistema.

En la práctica, es normal que ningún formalismo satisfaga todas las necesidadespara la especificación del sistema, por lo que es habitual que se utilicencombinaciones de diferentes formalismos. Una buena descripción y compendioactualizado de los principales métodos de especificación y diseño de sistemasreactivos se encuentra en [Wier03]. A continuación se presentan algunos de losmétodos y formalismos con soporte gráfico más utilizados.

2.2.1 Métodos Gráficos

Uno de los métodos más utilizados en la especificación del comportamiento de unsistema reactivo es el basado en máquinas de estados, debido a que muestran los


15

diferentes estados del sistema y las transiciones entre ellos. Una de las razones desu amplia difusión es que la mayoría son métodos gráficos y con soporte deherramientas de desarrollo. Sin embargo, debido precisamente a su intuitividadgráfica, no pueden considerarse precisamente como métodos de especificaciónformales, ya que además de existir diferencias sintácticas en función de laherramienta por la que son soportados, no tienen claramente definida su semánticade ejecución. Sin embargo, aún con esta desventaja, son métodos muy flexibles yque gozan de una mayor aceptación que los lenguajes puramente formales.

2.2.1.1 SA/RT

SA/RT es el acrónimo de Structured Analysis/Real-Time y es un conjunto demétodos basados en el análisis orientado al flujo de datos clásico [Marc79]. Enellos, la especificación del sistema se realiza mediante el uso de un conjuntojerárquico de elementos gráficos, conocidos como Diagramas de Flujo de Datos óDFDs. Debido a que éstos no pueden capturar el comportamiento de controlinherente a los sistemas reactivos, Ward [Ward86] propuso un conjunto deextensiones de forma que pudiesen ser utilizados para la especificación desistemas orientados al control.

El método propuesto está compuesto por dos modelos diferentes, pero quebásicamente utilizan la misma notación:

� Modelo esencial, que se corresponde a la especificación del sistema.

� Modelo de implementación, correspondiente al diseño del sistema.

Para la elaboración del modelo esencial se parte de un modelo del entorno (odiagrama de contexto), donde se representa al sistema formado por un únicoproceso y un conjunto de entidades externas (o terminadores) que representan alentorno con el que se comunica. La comunicación entre el entorno y el sistema serealiza por medio de flujos que pueden ser:

� Flujos de datos, discretos, que aparecen en un instante de tiempo determinado,o continuos, representando información que siempre está disponible.

� Flujos de control o eventos, representan la ocurrencia de un evento en uninstante determinado y ante el cual el sistema ha de responder.

En la Figura 4 se representan los elementos presentes en el modelo del entorno.

PSISTEMA Entidad

Externa 2EntidadExterna 1

Flujo Contínuo

Flujo DiscretoFlujo Control

Figura 4: Modelo del entorno

A partir del modelo del entorno, el desarrollo del sistema continúa de formadescendente, refinando sucesivamente cada proceso de forma que representen un


16

mayor nivel de detalle. Cada uno de esos refinamientos dará lugar a un nuevodiagrama de flujo de datos, que se conoce como modelo del comportamiento(Figura 5).

PProceso No

Primitivo

PProceso Primitivo

Datos

PProceso Primitivo

Contínuo

PProceso Control

D Almacen Datos

D Almacen Control

Trigger

Enable/Disable

Figura 5: Modelo de comportamiento

Este diagrama puede contener los siguientes elementos:

� Procesos no primitivos, que se refinarán posteriormente en otros diagramas decomportamiento.

� Procesos primitivos de datos, representan procesos atómicos que seránespecificados de forma textual.

� Procesos de control, describen el comportamiento reactivo del sistema, y portanto únicamente pueden recibir y enviar eventos.

� Almacenes de datos, representan la información que ha de recordar el sistema.

� Almacenes de control, representan eventos que ha de recordar el sistema.

Los procesos de control se modelan utilizando Diagramas de Transición deEstados ó STDs (Figura 6). Las transiciones en estos diagramas se etiquetan porpares evento/acciones, para indicar que cuando un proceso está en un determinadoestado y se recibe un determinado evento, el sistema posiblemente cambiará deestado y realizará las acciones incluidas en la transición ejecutada.


17

Estado 1

Estado 2

evento 1 / accion 1

evento 2 / accion 2

Figura 6: Diagrama de transición de estados

Adicionalmente, existe un conjunto de eventos conocidos con el nombre deactivadores que sirven para controlar la ejecución del resto de procesos:

� Flujo Habilitador o Activador (Enable), el proceso receptor comienza aejecutarse desde su estado inicial.

� Flujos Deshabilitador o Desactivador (Disable), el proceso receptor finalizainmediatamente y permanecerá en un estado indefinido.

� Flujo Disparador (Trigger), comienza la ejecución de un proceso quefinalizará una vez realizada la transformación.

Una de las principales ventajas de realizar especificaciones con un modelooperacional como el definido anteriormente es la posibilidad de realizarejecuciones y simulaciones. En los modelos SA/RT esto se puede realizar conanimaciones, mediante una serie de pasos en los que se visualiza el estado globaldel sistema utilizando marcas o tokens situados sobre los procesos, estados yeventos. La animación también se puede ejecutar de forma interactiva insertandomarcas y examinado la evolución del sistema.

2.2.1.2 Lenguajes Síncronos, Statecharts y RSML

Este tipo de formalismos se suelen englobar dentro de los métodos basados enestados jerárquicos. Las especificaciones basadas en diagramas de transición deestados (como SA/RT), son difíciles de interpretar cuando el sistema es muyreactivo y los niveles de abstracción son muchos, ya que únicamente se puederepresentar un diagrama de transición de estados para cada uno de los procesos.Los métodos basados en estados jerárquicos permiten que un estado estécompuesto a su vez de otros estados (subestados), facilitando de este modo suinterpretación y desarrollo.

Los Statecharts [Hare87a] son diagramas de transición de estados donde cadaestado se puede descomponer en otros subestados que representan un menor nivelde abstracción. La ventaja de este formalismo es que se pueden representargráficamente en un mismo diagrama esta descomposición. Estos estados se


18

denominan estados “OR” debido a que el sistema únicamente puede estar en unode ellos. Existen también los estados “AND” donde el sistema puede encontrarsesimultáneamente en varios de ellos, permitiendo así la ejecución paralela de variosdiagramas de transición de estados.

Los Lenguajes Síncronos [Bene91] son una familia de lenguajes de especificación(originalmente textuales) e implementación que adoptan la denominada hipótesisde sincronismo [Berr92]: las salidas ocurren simultáneamente a las entradas quelas originó. Dicho de otro modo, el sistema es infinitamente más rápido que elentorno. Ejemplos particulares de lenguajes síncronos, aunque no estánsustentados por formalismos gráficos son Lustre [Halb91], Signal [Guer91] yEsterel [Berr92]. Los Statecharts también pueden ser considerados un lenguajesíncrono gráfico.

El lenguaje RSML (Requirements State Machine Languages) [Leve94] es unlenguaje basado en Statecharts con unas ligeras diferencia sintácticas ysemánticas. El lenguaje fue ideado durante la especificación del sistema TCAS II(Traffic Collision Avoidance Systems) y su principal objetivo era desarrollardocumentos de especificación fáciles de revisar y que los requisitos fuesenanalizables de manera formal para garantizar su corrección y el cumplimiento delas propiedades de seguridad. Al igual que el caso de Statecharts, RSML tambiénse puede considerar un lenguaje síncrono ya que su semántica adoptaimplícitamente la hipótesis de sincronismo.

2.2.1.3 Semánticas de Ejecución

Un defecto importante de los métodos SA/RT es la no existencia de una semánticade ejecución formalmente definida, de modo que se pueden presentarambigüedades en la especificación que deben ser resueltas medianteinterpretaciones particularizadas en cada caso. En su formalización original[Ward86], se indican una serie de reglas de ejecución basadas en la colocación detokens, pero no se puede considerar una semántica de ejecución, sino más bienuna recomendación para su animación. Aún así, la descripción propuesta contieneun alto grado de no determinismo. Una enfoque para formalizar su semánticaconsiste en su formulación a través de semánticas provenientes de otrasnotaciones similares (por ejemplo las semánticas de pasos utilizadas enStatecharts [Hare87a]). Una formalización de los métodos SA/RT se puedeencontrar en [Pete94].

Históricamente sobre los Statecharts no se definió ninguna semántica “oficial”,sino que se dejo libertad a los analistas para su definición. Debido a ello no fueronconsiderados un lenguaje formal debido a que tienen múltiples semánticasdefinidas (en [Beec94] se enumeran hasta veinte variantes publicadas hasta 1994)y pueden producirse paradojas causadas por la adopción de la hipótesis desincronismo. Algunas semánticas publicadas solucionan los problemas quepueden producirse en la especificación adoptando dos niveles de tiempo,denominados macropaso y micropaso respectivamente [Hare87b]. Losmacropasos definen los intervalos de tiempo observables y cada uno de ellos sedivide en micropasos de forma que las acciones y reacciones ocurren en diferentesmicropasos; se puede producir una cadena de micropasos en las que se ejecutan


19

varias transiciones, pero las observaciones de los eventos se realizansimultáneamente como indica la hipótesis de sincronismo.

Huizing y Gerth [Huiz91] definen algunos criterios que deben de cumplir lassemánticas para Statecharts. Esos criterios los enuncian como responsividad,modularidad y causalidad e identifican cinco tipos de semánticas que cumplenalguno de los criterios anteriores, pero no existe ninguna semántica que cumplalos tres criterios.

Leveson et al [Leve94] proponen una semántica para RSML más causal y simpleque la definida en [Hare87b], aunque sigue conservando los conceptos demacropaso y micropaso. En [Hare96] se describe una semántica para Statechartstal y como son soportados por la herramienta de especificación y simulaciónSTATEMATE [Hare90]. La semántica propuesta adopta dos vistas diferentes deltiempo, síncrona y asíncrona, donde únicamente se adopta la hipótesis desincronismo para el modelo asíncrono. En dicho trabajo, se demuestra que lasemántica propuesta en [Leve94] es equivalente a la definida adoptando la vistaasíncrona del tiempo.

La semántica de RSML y STATEMATE (en su versión asíncrona) se puederesumir como sigue.

Inicialmente llegan al sistema eventos externos procedentes del entorno quecomienzan un macropaso, y pueden activar transiciones en una o varias máquinasde estados del sistema. Se denomina conjunto máximo de transiciones noconflictivas al conjunto de transiciones habilitadas donde cada máquina de estadoscontribuye exactamente con una transición habilitada; es decir, si una máquina deestados tiene dos transiciones habilitadas, existirán dos conjuntos máximos detransiciones no conflictivas. Si este conjunto es único, el sistema se dicedeterminístico; en otro caso es no determinístico. A partir del conjunto máximo,se ejecutan las transiciones en él incluidas, formándose un micropaso. Cadamicropaso puede generar a su vez nuevos eventos internos y/o de salida quehabilitarán nuevas transiciones y producirán la ejecución de otro micropaso. A noser que los eventos sean nuevamente generados por otra transición, desaparecendespués del micropaso. El macropaso fianaliza cuando no hay más transicioneshabilitadas, y por tanto no se pueden comenzar nuevos micropasos. Entonces, elsistema se dice que está en una situación estable. Las salidas se comunican alexterior todas a la vez a la finalización del macropaso. Dado que la semánticaadopta la hipótesis de sincronismo, los valores de las entradas no cambian duranteun macropaso, por lo que no llegan eventos externos de entrada. En la Figura 7 seilustran los conceptos anteriores.


20

Valores delEnorno Micropasos Estable

Valores delEntorno

Macropaso

Figura 7: Macropasos y micropasos

Esta semántica así definida es la adoptada en muchos trabajos donde se realiza laverificación de sistemas reactivos utilizando notaciones similares a Statecharts.Por ejemplo en [Chan98] se realiza la verificación de los requisitos del TCAS IIespecificados en lenguaje RSML con el comprobador de modelos SMV[McMi93]. En [Tuya97a] se utiliza el comprobador de modelos SPIN [Holz03]para realizar la verificación modular de una caldera de vapor especificadagráficamente con métodos SA/RT y con semántica similar a la definida porRSML.

2.2.2 Lógica Temporal

La lógica temporal tuvo sus inicios en las consideraciones de los filósofos sobre eltiempo a partir de la lógica modal que trataba los aspectos de necesidad yposibilidad. A partir de estos conceptos, la lógica temporal evolucionó de la lógicamodal y fue aplicada por primera vez en la especificación y razonamiento sobresistemas reactivos por Pnueli [Pnue77].

Existen varias familias de lógicas temporales, cada una de ellas diferenciadas porlos operadores temporales que soportan, su semántica y su potencia expresiva.Ejemplos son LTL (lineal temporal logic [Mann91]), CTL (computation treelogic, [Clar86]), CTL* [Clar99] y µ-calculus [Koze83]. En esta introducción secomentará únicamente las lógicas LTL y CTL por ser las soportadas por dos delos comprobadores de modelos más populares, como son SPIN [Holz03] y SMV[McMi93].

LTL es un lenguaje de asertos sobre computaciones. Sus fórmulas son creadasdesde proposiciones atómicas por medio de conectores booleanos y los operadorestemporales X (“en el siguiente instante”) y U (“hasta que”; pUq significa que p secumplirá en algún instante del futuro hasta el instante en el que q se cumpla entodos los instantes). La fórmula trueUp, que se escribe de forma abreviada comoFp, indica que p se cumplirá eventualmente en algún momento del futuro, y lafórmula ¬F¬p (de forma abreviada Gp) indica que p es siempre cierto. Unprograma satisface una fórmula en LTL si todas sus computaciones satisfacen lafórmula.


21

CTL es una lógica temporal ramificada que está caracterizada por árboles decomputación. Sus operadores temporales consisten en cualificadores de caminosseguidos por un operador de la lógica lineal. Los cualificadores son A (“paratodos los caminos”) y E (“para algún camino”).

Además de poder expresar propiedades universales (propiedades que se cumplenpara todas las posibles ejecuciones de un programa) y propiedades existenciales(solamente se cumplen para alguna ejecución del programa), la lógica temporalpermite expresar propiedades de seguridad (safety), que intuitivamente indicanque “no sucederán cosas no deseadas” y propiedades de vivacidad (liveness), queexpresarán que “alguna cosa buena sucederá”.

Independientemente de la potencia expresiva de cada uno de los diferentes tiposde lógica, el aspecto más importante es la posibilidad de realizar la comprobaciónde modelos sobre especificaciones detalladas con lógica temporal (como se verápróximamente en la Sección 2.4.1). Esto permite realizar verificaciones desistemas reactivos de forma automática. Los primeros comprobadores de modelosestaban casi todos basados en la lógica ramificada debido a los problemas paradescribir algoritmos eficientes para el caso de la lógica temporal lineal. Sinembargo, y como se comenta posteriormente en la Sección 2.4.1, se hanimplementando nuevos algoritmos para ambos tipos de lógicas con rendimientos ycomplejidades muy similares.

2.3 Verificación de Sistemas ReactivosEl término general de verificación [IEEE90] es utilizado en sentidos diferentes porinvestigadores e ingenieros. En algunos casos, la verificación es utilizada parareferirse únicamente al proceso de obtener una prueba formal de que un programao modelo de un sistema es correcto (por ejemplo, verificación deductiva). En otroscontextos, la verificación es utilizada para describir el proceso de búsqueda deerrores en un programa o modelo (por ejemplo, comprobación de modelos oprueba).

Debido a que esta tesis está centrada en el uso de técnicas formales, se utiliza eltérmino de verificación formal en el mismo sentido que el propuesto en [Pele01]:el proceso de aplicar un técnica manual o automática para decidir si el software(o modelo) cumple una determinada propiedad, o si está conforme respecto aalguna otra descripción de alto nivel realizada sobre él. Por tanto, con ladefinición anterior, el término verificación incluye técnicas como verificacióndeductiva y verificación algorítmica, pero no incluye técnicas de prueba.

El término verificación deductiva se refiere normalmente al uso de axiomas yreglas de inferencia para probar que un sistema es correcto [Flo67] [Dijk68][Hoar69] [Mann95]. En las primeras etapas de investigación de estas técnicas, elprincipal objetivo era su aplicación a sistemas críticos e inherentementecomplejos, por lo que el establecimiento de su comportamiento deseado y suposterior verificación solía requerir mucho tiempo. Inicialmente, todas las pruebaseran realizadas manualmente (con la consiguiente posibilidad de erroresadicionales). Muchas partes de la verificación deductiva pueden ser automatizadasmediante el uso de comprobadores de teoremas (theorem provers), donde el


22

sistema se especifica formalmente como un conjunto de axiomas y reglas deinferencia. El objetivo es encontrar de forma automática una demostración de unapropiedad en base a partir de los axiomas del sistema. Aún así, los comprobadoresde teoremas son fundamentalmente interactivos y necesitan una fuertecolaboración por parte de un usuario experto. Ejemplos de comprobadores deteorema son HOL [Melh93], PVS [Owre96], ACL2 [KaufM00] y STeP[Mann99]. La principal ventaja de esta técnica es permite razonar sobre programacon estados posiblemente infinitos (por ejemplo, programas parametrizados,estructuras de datos con tamaño variable, etc.). Además, las investigacionesrealizadas en el campo de la verificación deductiva tienen una fuerte influencia enel desarrollo actual del software, por ejemplo mediante el empleo del términoinvariante. Así, hoy en día se utiliza el invariante (aserción) como una condiciónque se necesita cumplir en un cierto punto de control de un programa durante suejecución. Dado que ésta se comprueba en tiempo de ejecución, permite alprogramador tener un mejor conocimiento del funcionamiento del programa. Paramás detalle sobre los principios generales de la verificación deductiva ycomprobadores de teoremas, dos buenas referencias son [Mann95] y [Pele01].

Bajo el término de verificación algorítmica se engloban una serie de métodos ytécnicas cuyo objetivo es la verificación de manera totalmente automática desistemas reactivos. A diferencia de la verificación deductiva, estas técnicasúnicamente tienen aplicabilidad cuando el sistema bajo verificación se puededescribir como un conjunto finito de estados. Las primeras técnicas deverificación automática fueron sugeridas por Zafiropoulo [Zafi77] para analizarprotocolos de comunicación modelados con máquinas de estados finitos medianteun algoritmo de búsqueda sobre su espacio de estados. Posteriormente, West yZafiropoulo [West78] utilizan el mismo algoritmo para verificar el protocoloCCITT X.21.

La comprobación de modelos es la técnica de verificación algorítmica másconocida y fue ideada independientemente por Clarke y Emerson [Clar81] yQuielle y Sifakis [Quie81]. En este enfoque, las propiedades a verificar estánespecificadas en lógica temporal y el sistema se modela operacionalmente comoun sistema de transición de estados. En decir, se comprueba el sistema paradecidir si es un modelo de la especificación mediante la exploración exhaustivadel espacio del sistema. Dado que éste es finito, la búsqueda siempre termina. Encaso de que la propiedad sea falsa, el comprobador de modelos devuelve uncontraejemplo, o traza del programa que demuestra un comportamiento erróneodel programa de acuerdo a la propiedad especificada. Uno de los principalesproblemas de esta técnica es el denominado efecto de la explosión de estados: elnúmero de estados a explorar aumenta exponencialmente con el tamaño delsistema a verificar. Por ello, muchos comprobadores de modelos suelen incorporarheurísticas para aminorar el efecto anterior, entre las que se pueden citar larepresentación simbólica con diagramas binarios de decisión [Burc90], métodosde reducción de orden parcial [Gode93] y simetría [Emer93]. Entre loscomprobadores de modelos más utilizados se encuentran SPIN [Holz03] y SMV[McMi93]. Una introducción a las técnicas utilizadas en comprobación demodelos con una buena referencia a las herramientas más utilizadas se puedeencontrar en [Béra99]. En [Clar99] se presenta el estado del arte de la


23

comprobación de modelos en general y en particular en las técnicas para aminorarel efecto de la explosión de estados.

En principio, no se puede afirmar que ninguna de las técnicas anteriores(deductiva, algorítmica) sea superior a la otra. Si bien los comprobadores demodelos son más utilizados por su carácter automático y que requieren menosconocimiento experto, tienen la desventaja de que únicamente pueden seraplicados sobre sistemas que se puedan modelar sobre un espacio de estadosfinito. Los comprobadores de teoremas permiten razonar sobre sistemasposiblemente infinitos, pero necesitan mucho tiempo de aplicación yconocimiento experto. Por ello, una línea de investigación muy interesante es lacombinación de ambos enfoques, donde, por ejemplo, se puede utilizar laverificación deductiva para obtener una abstracción finita de un sistema, yposteriormente utilizar un comprobador de modelos para su verificación.Ejemplos de combinación de verificación deductiva y algorítmica se puedenencontrar en [Raja95], [Ding95], [Have96] y [Shan00]. En las herramientas PVS ySTeP se utiliza la comprobación de modelos como un procedimiento de decisióndentro de un entorno deductivo guiado por un comprobador de teoremas.

En esta tesis se utilizan los comprobadores de modelos para la verificación, por loque en la siguiente sección se introduce un poco más en detalle alguna de lastécnicas y algoritmos en los que se basa. Posteriormente se comentan las técnicaspara aliviar el problema de la explosión de estados, principalmente los métodos derazonamiento modular y composicional.

2.4 Comprobación de ModelosLos comprobadores de modelos son herramientas automáticas utilizadas para laverificación basada en la comprobación de propiedades (requisitos) sobre unmodelo finito del sistema (máquinas de estados). En general, las especificacioneso propiedades que debe cumplir el sistema se especifican en algún tipo de lógicatemporal o como un autómata, produciendo dos enfoques [Clar96b] [Clar99]:

� Basada en Lógica Temporal [Clar81] [Quie81], donde las propiedades averificar se especifican en lógica temporal proposicional.

� Basada en Teoría de Autómatas [Vard86], tanto el modelo del sistema comolas propiedades deseadas se especifican mediante un autómata finito.

2.4.1 Basada en Lógica Temporal

Un formalismo muy adecuado para especificar las propiedades de un sistemaconcurrente es el basado en lógica temporal, debido a que permite describir elorden de los eventos a lo largo del tiempo sin explícitamente introducirlo. Pnueli[Pnue77] fue el primero en utilizarla para especificar el comportamiento formal delos programas, demostrando que este formalismo es mucho más claro y simpleque la lógica proposicional utilizada en la verificación clásica de programas[Flo67] [Hoar69].


24

Una estructura temporal es un par (S,R) donde S es un conjunto de instantes detiempo y R es una relación en S que relaciona cada instante con su sucesorinmediato. El cierre reflexivo de R se denota por ≤, y representa el ordentemporal, de modo que s≤t indica que el instante s ocurre antes que el instante t, obien s y t se corresponden al mismo instante. En general, la naturaleza de larelación R define dos modelos de tiempo y por tanto de lógica: lineal yramificada.

Dado un conjunto de proposiciones atómicas P, una interpretación temporal Γ esuna tupla (S,R,I), donde (S,R) es la estructura temporal e I es una función deinterpretación que mapea S×P sobre el conjunto {true,false}, es decir, I asigna unvalor de verdad I(s,p) a cada instante en S y cada proposición en P.

En la comprobación de modelos basada en lógica temporal, las propiedades quedebe cumplir el sistema se expresan como fórmulas en algún tipo de lógicatemporal, y el sistema de transición de estados que describe el comportamiento delprograma, como un conjunto de interpretaciones temporales en la lógica. De estemodo, la comprobación de modelos consiste en chequear si las propiedades delprograma son ciertas en el conjunto de interpretaciones definidas por el sistema.Como se comenta anteriormente, si se detectan violaciones de las propiedades, elalgoritmo devuelve contraejemplos o trazas de ejecuciones del programa quedemuestran el comportamiento erróneo.

Aunque se pueden utilizar muchos formalismos basados en máquinas de estadosfinitos para representar el sistema, por simplicidad, mostraremos los fundamentosde la comprobación de modelos utilizando estructuras finitas de Kripke comomodelo del sistema. Una estructura finita de Kripke es una 5-tupla (S,q,P,L,R)donde S es el conjunto de estados, q∈ S es el estado inicial, P es un conjunto finitode proposiciones atómicas, L:S→2P es una función que etiqueta cada estado con elconjunto de proposiciones atómicas en P que se cumplen en dicho estado yR⊆ S×S es una relación de transición entre los estados del sistema. Cada estado enuna estructura de Kripke s=(x0,x1,...,xn) representa una asignación de valores(ui=xi) donde (u0,u1,...,un) es el vector de variables de estado del sistema. Uncamino en una estructura de Kripke (suponiendo que R es una relación total) esuna secuencia infinita de estados (s0,s1,s2,...) tal que ∀ i≥0, (si,si+1)∈ R. La raíz delcamino es el primer estado que aparece en la secuencia.

2.4.1.1 Lógica Lineal (LTL)

En la lógica temporal lineal (LTL) el tiempo es un conjunto linealmente ordenado(normalmente con los números naturales), de forma que la estructura lineal (S,R)es una relación que asigna a cada instante de tiempo únicamente un sucesorinmediato. El orden temporal ≤ es un orden total, y es normal especificar laestructura temporal como (N,Succ) donde N es el conjunto de los númerosnaturales y Succ es la función estándar que asigna a cada número natural susucesor.

Desde el punto de vista de la verificación y suponiendo que M=(S,q,P,L,R) es laestructura de Kripke que modela el programa, cada camino p=(s0,s1,s2,...) en Mdefine una interpretación temporal Γ como una secuencia infinita de asignaciones


25

de valores de verdad a proposiciones atómicas en P de la siguiente manera: encualquier instante n∈ N, una proposición m∈ P es cierta en n, sí y solo sí m∈ L(so).Así, un camino p=(s0,s1,s2,...) satisface una fórmula f, si f es cierta en s0 en lainterpretación definida por p. Por tanto, el sistema M satisface p, si todo camino pcuya raíz es el estado inicial q de M satisface f.Sistla y Clarke [Sist85] mostraron que el problema de la comprobación demodelos con LTL era en general PSPACE-complete. Vardi an Wolper [Vard86]propusieron un algoritmo para la comprobación de fórmulas LTL que eraexponencial en la longitud de la fórmula (número de proposiciones, operadorestemporales y conectivas lógicas), pero lineal en el tamaño del modelo. Estealgoritmo está basado en la teoría de autómatas (Sección 2.4.2) e implementadoen algunos comprobadores de modelos basados en LTL, como SPIN [Holz03].

2.4.1.2 Lógica Ramificada (CTL)

En la lógica temporal ramificada, el modelo de tiempo puede verse como un árbolinfinito, pero donde cada nodo tiene un número finito (distinto de cero) desucesores inmediatos. Desde este punto de vista puede verse la lógica lineal comoun caso especial de la lógica ramificada. En lógica ramificada el tiempo es deorden parcial, donde el pasado de cada instante está ordenado linealmente.

Un camino en la estructura ramificada (S,R) es un conjunto máximo linealmenteordenado de instantes de tiempo en S, Por tanto, el modelo de tiempo en lógicaramificada es inherentemente no determinístico, de modo que cada instante tpuede tener muchos futuros posibles, que se corresponden al camino cuya raíz est.

Una interpretación temporal ramificada Γ=(T,R’,I) se puede obtener fácilmente apartir de una estructura finita de Kripke M=(S,q,P,L,R), comenzando en el estadoinicial q y desdoblando M para conseguir el árbol infinito [Clar99]. Para cualquierinstante de tiempo t∈ T y proposición m∈ P, la interpretación I(t,m) es cierta si ysolo sí m∈ L(s) para el estado s de M en el instante t. Dicho de otro modo, lafunción de interpretación asigna a cada instante de tiempo aquellas proposicionesque son ciertas en el estado de la estructura de Kripke que se corresponden con elinstante de tiempo. Por tanto, decimos que M satisface una fórmula CTL f, siI(q,f)=true, esto es, la fórmula se cumple en el estado inicial de la estructura.

La verificación de fórmulas en CTL puede realizarse con un algoritmo que eslineal en el producto de la longitud de la fórmula y el tamaño del modelo deKripke que representa al sistema [Clar99]. Una caracterización basada en puntosfijos de los operadores CTL produce un algoritmo más eficiente [Clar99].Variaciones de éste, están implementadas en el primer comprobador de modelossimbólico, SMV [McMi93].

2.4.2 Basada en Teoría de Autómatas

En este enfoque tanto el modelo operacional de sistema como las propiedades averificar se especifican utilizando autómatas. El sistema es comparado con laespecificación (propiedad) para determinar si su comportamiento está conforme


26

con la propiedad. Generalmente, tanto la especificación como el modelo delcomportamiento del sistema se representan como autómatas de Büchi [Thom90].Aunque esta introducción está basada en la verificación de fórmulas LTL, puedenconsiderarse otro tipo de lógicas [Thom90]. El algoritmo general para transformaruna fórmula en LTL en un autómata generalizado de Büchi se describe en[GPVW95].

Suponiendo que M y P son los autómatas de Büchi que representan elcomportamiento del sistema y la propiedad a verificar, respectivamente, el modelodel sistema M satisface la especificación P si existe una inclusión entre el lenguajeaceptado por el sistema M y el lenguaje de la especificación P [Kurs95]. Otraforma de representar lo mismo, consiste en computar el complemento del lenguajeaceptado por la especificación P y realizar posteriormente la intersección con ellenguaje aceptado por el modelo M. Si la intersección es vacía, el modelo Msatisface la especificación P. Esta aproximación es similar a la realizadainicialmente por Vardi y Wolper [Vard86].

La implementación de la intersección de lenguajes es más simple que la inclusión,por lo que el algoritmo para comprobar que la intersección entre lenguajes esvacía es más eficiente y simple que el necesario para implementar la inclusión delenguajes. Por otra parte, la computación del complemento de un autómata deBüchi es difícil. Sin embargo, si la especificación de la propiedad es una fórmulaLTL, se puede evitar realizar el complemento, realizando directamente lanegación de la fórmula a verificar, en vez de traducir la fórmula y luego realizar elcomplemento [Pele01].

La “conformidad” del sistema respecto a la especificación (propiedad) se puederealizar de acuerdo a los criterios de comprobación de equivalencia yordenamiento refinado. La comprobación de equivalencia consiste en comparar elmodelo y la especificación del sistema con respecto a alguna relación deequivalencia [Clea93], [Fern96]. Algunas relaciones de equivalencia utilizadas enla práctica incluyen las notaciones de equivalencia observacional y equivalenciafuerte, congruencia observacional de Milner [Miln89] y equivalencia de traza ydivergencia de fallo en Hoare [Hoar85]. En los ordenamientos refinados lasespecificaciones son tratadas como requisitos mínimos que el sistema(denominado en este contexto implementación) debe cumplir, y por tanto puedenser parciales. En este caso, la implementación A necesita garantizar al menos elcomportamiento demandado por la especificación B, mientras existen partes delsistema todavía no especificadas, de modo que se dice que A está más definidoque B, o que A refina a B, lo que establece una relación de orden entre procesos(autómatas). Los algoritmos para comprobar los refinamientos son similares a losutilizados en la comprobación de equivalencia.

La noción anterior de refinamientos proporcionó como resultado un enfoque en eldesarrollo de sistemas que Kurshan denominó refinamientos sucesivos [Kurs95],basada en la creación sucesiva de modelos con un grado de detalle cada vezmayor. De este modo cada nivel refina al modelo del nivel previo y sirve, a suvez, como especificación para el modelo siguiente. Esto permite la verificación decada propiedad en el modelo más simple donde puede ser definida.


27

2.5 Técnicas para Aliviar la Explosión de EstadosDebido al problema de la explosión de estados (existe una relación exponencialentre el número de estados que debe manejar el comprobador de modelos y elnúmero de componentes que forman el sistema) se han desarrollado un conjuntode técnicas y heurísticas cuyo objetivo es aminorar el efecto anterior. Esteconjunto de métodos, describe a su vez una nueva tipología en los comprobadoresde modelos, no ortogonal con la mostrada en la Sección 2.4:

� Representación Simbólica, donde las transiciones entre los estados del sistemase representan implícitamente usando diagramas binarios de decisión, evitandola construcción explícita del espacio de estados.

� Técnicas “On-the-Fly”, la verificación es realizada a la vez que se genera elespacio de estados. En muchos casos no es necesario computar el espacio deestados completo, ya que la verificación finaliza una vez que se ha localizadoun error.

� Métodos de Reducción, basados en la transformación del espacio de estadosen otro de menor tamaño, pero equivalente al primero.

� Métodos de Razonamiento Modular y Composicional, donde el problema deverificación de una propiedad sobre el sistema completo se traslada a laverificación de subpropiedades sobre componentes o partes del sistema. Comolos componentes son de menor tamaño, se evita la explosión combinatoria.

En las siguientes secciones se repasan brevemente los tres primeros enfoques.Dado que esta tesis está centrada en la verificación modular como alternativa a laexplosión de estados, se trata este enfoque por separado en la Sección 2.6.

2.5.1 Representación Simbólica

La comprobación de modelos utilizando técnicas simbólicas está basada en larepresentación del modelo de estados finito del sistema de forma implícita[McMi93]. La forma más común de representación implícita es la codificación defunciones booleanas con diagramas binarios de decisión ordenados (OBDD)[Brya86].

Los árboles binarios de decisión combinan varias ventajas que los hacen atractivosdesde el punto de vista práctico como medio de codificación de grandes espaciosde estados:

� Eficiencia, las operaciones básicas (intersección, complemento, comparación,etc.) pueden realizarse con un orden de complejidad lineal o cuadrática, y enmuchos casos instantánea (en el caso de la comparación). Debido a que sonestructuras de datos muy compactas, requieren poco consumo de memoria.

� Simplicidad, las estructuras de datos y algoritmos son fáciles de describir.

� Generalidad, son apropiados para describir cualquier tipo de sistemas con unespacio de estados finito.


28

Un OBDD es similar a un árbol de decisión binario, excepto que su estructura esun grafo dirigido acíclico donde hay un orden estricto en la ocurrencia de lasvariables igual al del recorrido del árbol de la raíz a las hojas. La representaciónde una función booleana f se obtiene mediante la reducción del árbol binario dedecisión correspondiente a f. Para obtener el valor de verdad dados valoresespecíficos de las variables en f, se recorre el árbol desde la raíz a las hojas. Encada uno de los nodos, el valor de la correspondiente variable determina quecamino se tomará: el nodo hijo de la derecha/izquierda si el valor etiquetado en elnodo es falso/cierto, respectivamente. El árbol binario de decisión se reduce a unOBDD combinando los subárboles isomórficos en un árbol único, y eliminandocualquier nodo cuyo hijo de la izquierda o derecha sea isomórfico.

El modelo finito de un sistema utilizando OBDDs puede realizarse como sigue.Cada estado se codifica mediante una asignación de valores booleanos al conjuntode variables de estado asociadas con el sistema. Si éstas no fuesen binarias, sinoque tuviesen un rango sobre un dominio finito D, se utilizará una codificaciónbinaria apropiada sobre D (en las herramientas que soportan representaciónsimbólica, por ejemplo SMV, se realiza de forma transparente para el usuario). Larelación de transición se expresa como una función booleana (representada comoun OBDD) en términos de dos conjuntos de variables, uno para codificar el estadoglobal actual del sistema y otro para el estado siguiente.

La comprobación simbólica de modelos comprueba directamente la fórmula sobreel OBDD que representa al sistema. Por ejemplo, el algoritmo correspondiente ala comprobación de modelos CTL, utiliza un OBDD para la relación de transicióny para las propiedades atómicas y devuelve otro OBDD que representa los estadosglobales del sistema donde se cumple la fórmula. Todas las operaciones demanipulación requeridas por el algoritmo se realizarán eficientemente sobreOBDDs. Aunque aquí se revisa la representación simbólica en la comprobaciónde modelos CTL, otros formalismos como aquellos basados en teoría deautómatas y LTL pueden beneficiarse de la representación simbólica de estados[Clar97a] [Kurs95].

La representación simbólica de estados, aunque evita en muchos casos elproblema de la explosión de estados, no ha reemplazado a la codificaciónexplícita, ya que no se comporta mejor y más eficientemente en todos los casos.Esto es debido a que el tamaño de OBDD depende del orden de sus variables (elproblema de encontrar la ordenación que genere un menor OBDD es NP-complete).

2.5.2 Verificación “on-the-fly”

El análisis de alcanzabilidad es una técnica de verificación que realiza unaexploración exhaustiva sobre todos los estados alcanzables y transiciones delsistema. Las técnicas “on-the-fly” se basan en la siguiente observación: pararealizar un análisis de alcanzabilidad no es necesario almacenar el grafo completodel sistema, sino que es suficiente simular todas las posibles secuencias detransiciones que el sistema sea capaz de realizar. Por ejemplo, una búsquedaclásica primero en profundidad puede utilizarse para explorar el sistema “on-the-fly”, sin almacenar todas las transiciones tomadas durante la búsqueda [Gode92].


29

Para un recorrido primero en profundidad por el grafo, el mínimo requisito dememoria sería el necesario para almacenar el camino actual que está siendoexplorado. Así, se garantiza la exploración exhaustiva con mínimos consumos dememoria. Sin embargo, el tiempo necesario para realizar una búsqueda puedellegar a ser prohibitivo debido a que es necesario volver a recorrer, y por tantocrear, estados previamente visitados en otro camino. Una solución puede seralmacenar los estados una vez que son visitados, reduciendo el tiempo deejecución necesario, pero aún así, para sistemas con un espacio de estados grande,el número de estados alcanzables puede ser muy elevado.

Para solucionar este compromiso tiempo-espacio se han propuesto variosmétodos. Además de almacenar el camino actual, se crea una caché paraalmacenar temporalmente los estados visitados (state-space caching [Holz87]). Laefectividad del método depende tanto del tamaño inicial de la caché como de laestructura del espacio de estados. En [Gode92] se describe un método que reduceel número de veces que los estados son visitados durante la búsqueda,incrementando los beneficios obtenidos con el método anterior. Esta técnica estábasada en la observación de que en muchos casos la explosión del tiempo deejecución necesario para la exploración exhaustiva es debido a que se recorrenmúltiples veces partes del grafo global que no son necesarias almacenar.Finalmente, cuando el tamaño del sistema no es adecuado para realizar laverificación exhaustiva se pueden utilizar heurísticas basadas en la búsquedaparcial sobre el espacio de estados (bit-state hashing o supertrace [Holz98]).

Aunque tradicionalmente el análisis de alcanzabilidad se ha empleado paradetectar errores relativos a situaciones de interbloqueo (deadlocks) y códigomuerto, la aplicabilidad de los algoritmos de análisis de alcanzabilidad se hanextendido con el desarrollo de los comprobadores de modelos basados en teoría deautómatas. El ejemplo más claro está en el método original de Vardi y Wolper[Vard86], donde la comprobación de modelos LTL puede reducirse a un problemade análisis de alcanzabilidad. En [Cour92] se proponen algoritmos muy eficientespara chequear la intersección vacía de autómatas de Büchi en la comprobación demodelos LTL. Estos algoritmos utilizan técnicas “on-the-fly” y son compatiblescon las técnicas anteriores (bit-state hashing y state-space caching). También sehan propuesto algoritmos “on-the-fly” aplicados a la verificación de fórmulas enlógica temporal ramificada [Bhat95].

Una de las principales ventajas de la verificación “on-the-fly” es que la búsquedafinaliza una vez se encuentre un error. En muchos casos, los errores se detectanpronto, evitándose así el recorrido del resto del grafo de alcanzabilidad. Por tanto,son muy adecuadas para su aplicación en las primeras fases del diseño delsistema, donde se supone que existen más errores.

2.5.3 Técnicas de Reducción

Bajo el nombre de Técnicas Reducción se engloban todas aquellas técnicas que seconcentran en crear parte, o una abstracción, de un sistema, mientras se preservala capacidad de verificar las propiedades originalmente especificadas sobre él.Describimos a continuación los dos tipos principales, que consisten enreducciones directas sobre el grafo de estados (minimización o reducción de orden


30

parcial) y la formulación de algún tipo de abstracción para minimizar el tamañodel sistema.

2.5.3.1 Reducción de Orden Parcial

Cuando se realiza la verificación de sistemas concurrentes y/o reactivos, enmuchos casos la concurrencia es modelada utilizando un modelo entrelazado(ejecución entrelazada de las transiciones que componen el sistema de transiciónde estados). Esta semántica entrelazada puede ser la causa de la explosióncombinatoria de estados, ya que es necesario considerar todas las posiblessecuencias de entrelazado entre los eventos. Los métodos de orden parcial sebasan en la observación de que, en los sistemas concurrentes, el efecto global deun conjunto de acciones o eventos es generalmente independiente del orden enque éstas ocurren. De este modo se evita la exploración de todos las posiblessecuencias de ejecución de transiciones entrelazadas del sistema [Gode90][Gode91] [Wolp93] [Valm93a] [Pele94].

Estos métodos de reducción realizan una búsqueda selectiva del espacio deestados del sistema. Para cada estado s alcanzado durante la exploración secomputa un subconjunto T de transiciones habilitadas en s y a continuación seexploran solamente las transiciones en T. Esta es la principal diferencia conrespecto a los métodos de búsqueda clásicos, en los cuales se exploran todas lastransiciones habilitadas en s. Durante los últimos años se han descrito diferentesalgorítmos para identificar el subconjunto T, con detalles internos diferenciadospero que comparten ideas muy similares: stubborn sets [Valm93a], persistent sets[Gode90] y ample sets [Pele94].

Los métodos de orden parcial se han combinado con la comprobación de modelos“on the fly” [Pele94] y más recientemente con técnicas simbólicas [Alur97]. Enmuchos casos estas técnicas generan el espacio de estados reducidodinámicamente durante la búsqueda, no computando aquellas partes del grafo deestados que son redundantes. En [Holz94] se propone una técnica estática, dondealgunas relaciones de dependencia entre sentencias del modelo se computanpreviamente antes de la generación del espacio de búsqueda, evitando lassobrecargas en tiempos de ejecución y recursos de memoria que inevitablementeintroducen los métodos dinámicos.

2.5.3.2 Abstracción

Muchas técnicas de reducción están basadas en aplicar algún tipo de abstracciónal sistema bajo análisis para obtener un sistema (abstracto) de menor tamaño queel original, de modo que si una propiedad se cumple sobre el sistema abstracto,también se cumple sobre el sistema original.

La reducción de localización [Kurs95] es una técnica de reducción automática ydependiente de la propiedad a verificar que se aplica dinámicamente en lacomprobación de la inclusión de lenguajes (correspondientes al sistema y a lapropiedad) en los métodos de verificación basados en teoría de autómatas(Sección 2.4.2). El algoritmo inicialmente considera una abstracción del sistemaque contiene únicamente un subconjunto de los procesos del sistema y se aplica


31

recursívamente sobre aproximaciones sucesivas hasta que se cumple la inclusiónde los lenguajes, o se devuelve un contraejemplo correspondiente a una ejecuciónpermitida en el sistema. La selección de los procesos que se añaden en cadaiteración está basada en un grafo dirigido de dependencias entre los procesos delsistema original. Está técnica está implementada en la herramienta FormalCheck[Kurs98].

Para programas o sistemas con comportamiento muy dependiente de los datos, en[Clar94] se describe un método para realizar la comprobación de modelos basadaen aproximaciones del espacio de estados. Las aproximaciones están basadas enfunciones que mapean los conjuntos correspondientes a los rangos de las variablesdel programa en conjuntos de valores abstractos. Esta correspondencia entre losconjuntos originales y abstractos se realizan directamente sobre el sistema sinnecesidad de computar previamente el espacio de estados. La idea es muy similara las técnicas de interpretación abstracta [Cous77] inicialmente concebidas parael análisis de los tiempos de compilación de programas, y cuyas ideas fueronadaptadas para la verificación de sistemas [Dams97] [Cous99].

Otras técnicas de abstracción intentar explotar algún tipo de simetría existente enel sistema. Muchos sistemas concurrentes contienen componentes que se puedenconsiderar como replicados (por ejemplo, un protocolo de comunicacionescontiene un conjunto de procesos idénticos que se comunican de alguna manera),por lo que se puede construir modelos del sistema más reducidos. La simetríaimplica la existencia de un grupo de permutaciones no triviales que preservan elgrafo de transición de estados, y que se utiliza para definir una relación deequivalencia entre el espacio de estados del sistema y el espacio de estadosreducido. Las técnicas basadas en simetría se han utilizado como un método deabstracción para la generación del espacio de estados [Ip93] y comprobación demodelos [Emer93].

Las técnicas de inducción [Brow89] [Clar97b] permiten realizar la verificación defamilias enteras de sistemas de estados finitos. Un ejemplo son los sistemasparametrizados (familias infinitas de sistemas de estados finitos) tan frecuentes endiseños hardware y software. El objetivo es verificar que todo sistema en unafamilia dada satisface un conjunto de propiedades. En general este problema esindecidible, pero en muchos casos, es posible realizar el razonamiento mediante eluso de un proceso invariante que representa el comportamiento de un sistemaarbitrario perteneciente a la familia, y utilizarlo para verificar una única vez laspropiedades para todos los miembros de la familia. En este tipo de técnicas seutiliza un argumento inductivo para verificar que el invariante es apropiado yrepresentativo de la familia de sistemas.

2.6 Verificación Modular y ComposicionalLas técnicas conocidas como verificación modular o composicional consisten enaplicar técnicas “divide y vencerás” en la verificación de sistemas reactivos. Esteconjunto de técnicas explotan el diseño del sistema para realizar verificacioneslocales en los componentes o módulos del sistema, de modo que a partir de ellasse puedan deducir la veracidad o falsedad de las propiedades sobre el sistema


32

completo. De este modo, no es necesario computar el espacio de estados delsistema global y por tanto se evita la explosión de estados. En la literatura ambostérminos (modular y composicional) se utilizan con el mismo significado, por loque a lo largo de la tesis se utilizará el término de verificación modular parareferirnos al enfoque anterior.

En el caso más simple, supóngase que tenemos un sistema compuesto por dosprocesos P y Q que se comunican entre ellos (por medio de canales, eventos, etc.)y con el entorno (Figura 8).

P Q

Figura 8: Verficación composicional y modular

El sistema completo se denota por P||Q, donde || es el operador de composición delos procesos P y Q. Dada la especificación declarativa de P y Q, ϕP y ϕQrespectivamente, la verificación modular razona sobre el sistema completo deacuerdo a la siguiente regla de inducción:

ϕϕϕϕ

ϕϕ

=��

�

=

=

|||),,(

|

|

QPCQP

QP

Q

P

En la regla de arriba, M|=ϕ significa que el componente o proceso M satisface lapropiedad ϕ y C(ϕP,ϕQ,ϕ) es una condición lógica relativa a ϕP, ϕQ y ϕ. De estemodo, la verificación modular posibilita la aplicación de los comprobadores demodelos únicamente a partes del sistema (componentes) que tienen un tamaño delespacio de estados más pequeño que el sistema original y se evita la explosióncombinatoria de estados producida en el sistema original.

Sin embargo, los componentes P y Q están diseñados para ejecutarse únicamenteen el entorno del sistema y no en un entorno arbitrario como el que se supone enla verificación de cada uno de los componentes. Por ejemplo, el componente Ppodría por si solo no ser capaz de verificar la propiedad ϕP o cualquier otra, yaque podría recibir una entrada del entorno no esperada y producir uncomportamiento incorrecto. Por esta razón el espacio de estados del componente Pconsiderado individualmente es mucho mayor que el espacio de estados delcomponente P compuesto con Q. Este problema se conoce en la literatura como elproblema del entorno [McMi00] o explosión intermedia de estados [Cheu96].

Existen diferentes soluciones para evitar el problema anterior. De acuerdo aMcMillan [McMi00] se pueden clasificar los métodos de verificación modular endos grupos, que se detallan en las próximas secciones:


33

� Minimización Composicional, donde se genera una versión “reducida” delcomponente Q que caracteriza solamente el comportamiento de Q que esvisible desde P.

� Razonamiento basado en Suposición-Compromiso, donde el entorno delcomponente P se expresa mediante una suposición que el proceso P realizasobre el proceso Q. Esta suposición debe verificarse (compromiso)posteriormente sobre el componente Q.

Aunque inicialmente los métodos composicionales utilizados en la verificaciónestaban dirigidos a aminorar el problema de la explosión combinatoria de estados[Pnue85], tienen otras implicaciones importantes en el campo de la verificación desistemas: Por una parte, una metodología robusta de verificación debería deproporcionar reglas para deducir propiedades del sistema completo a partir de laspropiedades de los componentes o módulos que lo forman [Kupf98]. Por otra,debido al crecimiento de aplicaciones software en sistemas orientados al control(sistemas empotrados) y en aplicaciones sobre Internet con software heterogéneoy distribuido, el término componente y su verificación y validación estánadquiriendo gran importancia. Desde este punto de vista, las técnicas deverificación modular y de abstracción están llamadas a jugar un papel importanteen la validación de estos sistemas [Kest98].

2.6.1 Minimización Composicional

Dado un sistema especificado como una composición de componentes, el objetivode la minimización composicional consiste en obtener una versión reducida delentorno de cada uno de los componentes que caracterizará únicamente aquelloscomportamientos visibles desde el componente bajo verificación (Figura 9).Desde este punto de vista, la minimización composicional puede verse tambiéncomo una técnica de abstracción, ya que oculta detalles del comportamiento delsistema basándose en una descripción de la estructura del sistema y en laespecificación de la interacción entre los componentes.

P Q

PQ'

Figura 9: Minimización composicional

El proceso de minimización debe tener en cuenta el concepto de equivalencia paraasegurar que los componentes pueden ser reemplazados por sus versionesminimizadas sin afectar al resultado obtenido. Esta noción de equivalencia debe


34

ser lo bastante fuerte para preservar las propiedades de interés y lo bastante débilpara producir una buena reducción del espacio de estados [Valm93b]. Másformalmente, considérese la verificación de la propiedad p sobre el sistema S, ysupóngase una equivalencia semántica R que preserva la propiedad p. El sistema Ssatisface p si y solo si S’ satisface p, donde S’ es la máquina de estados mínima talque (S,S’)∈ R. El proceso de construcción de S’ a partir de S se denominaminimización y cuando R representa la aplicación de una abstracción a S, entoncesS’ contiene menos estados que S.

En el contexto de verificación modular, el proceso minimizado que representa alentorno de componente bajo verificación (en la Figura 9, el componente Q’) sedenomina proceso de interfaz. Un interfaz es un proceso que representa unconjunto de secuencias de ejecución permitidas que pueden ser realizadas por elcomponente en un entorno específico. Mientras más detallado sea el interfaz máslimitará el comportamiento del subsistema. Un interfaz es correcto si su inclusiónen la generación del sistema global no modifica el comportamiento del sistema.

En [Clar89] se propone un método que utiliza el conocimiento sobre el alfabetopara abstraer y minimizar los componentes del sistema. Utilizando como ejemploel esquema de la Figura 9, el proceso de interfaz Q’ se obtiene mediante laproyección de Q sobre el alfabeto del proceso P, ΣP (sus entradas y salidas). Laproyección consiste en el borrado de aquellas transiciones en Q cuyas acciones noestán en ΣP. El razonamiento sobre el sistema completo se realiza utilizando lasiguiente regla de inferencia:

P

P

pP

p

QPQP

LQQ

ϕϕ

ϕ =��

�

=

Σ∈

Σ↓≡

||||'||

)(

'

donde el operador ↓ es el operador de proyección y L(ΣP) es algún lenguaje lógicosobre ΣP. Una ventaja de esta técnica es que es fácilmente automatizable.

En [Graf96] se propone un método que incluye al anterior, donde los procesos deinterfaz son especificados por el usuario. Los procesos se modelan comomáquinas de estados finitos y se combinan utilizando un operador similar aldefinido en CSP [Hoar85]. La especificación operacional se extiende utilizandopredicados no definidos como estructuras del tipo (s,A), donde s estado de unproceso o componente y A es un conjunto de acciones, que cuando son ejecutadasdesde s, hacen que el proceso entre en un estado indefinido. Cada componente Ssobre el cual se ha definido un interfaz I, es substituido por la proyección de Ssobre I con una diferencia: cuando en cualquier estado q, S puede ejecutar unatransición etiquetada con una acción a que es finalizada por I, entonces se inserta(q,a) en el predicado no definido de la máquina de estados resultante de laproyección. Así, la validez de los procesos de interfaz introducidos se realizamediante la comprobación de la no existencia de predicados no definidos en elgrafo global construido. En otro caso, algunos de los procesos de interfazintroducidos no son correctos.

En [Cheu96] se presenta un método similar pero enfocado a la composiciónjerárquica de componentes en niveles (diseño ascendente), y donde los procesos


35

de interfaz se consideran determinísticos. Para comprobar que los procesos deinterfaz son correctos, se especifican un conjunto de condiciones necesarias ysuficientes en el denominado teorema del interfaz. La especificación operacionalse extiende en este caso con un estado de error π, y todos los procesos de interfazse transforman en completos con respecto a su alfabeto substituyendo lastransiciones perdidas con transiciones hasta el estado de error. Cuando uncomponente S es compuesto con su interfaz I, todas las transiciones de S que sonparadas por I en S||I, pasan a ser transiciones al estado de error en S||I. Si el estadode error no es alcanzable en el grafo global, se cumplen las condiciones delteorema de interfaz y por tanto el interfaz especificado es correcto.

En el mismo trabajo, se propone también un algoritmo para construir los procesosde interfaz automáticamente. Para cada componente S, el algoritmo aplica unareducción a cada una de las máquinas de estados Mi en S, que consiste en elborrado de transiciones etiquetadas con acciones que no pertenecen a S. En casode que la máquina de estados obtenida fuese no determinística, se traduce a otraequivalente determinística. El interfaz para el componente P es la composiciónparalela de las máquinas de estados determinísticas obtenidas con el procesoanterior. Los interfaces obtenidos cumplen siempre el teorema de interfaz, por loque son correctos por construcción.

Yeh [Yeh93] propone una técnica composicional donde el interfaz no esespecificado como un proceso separado, sino que se utilizan una serie detransiciones predefinidas (SLEEP, WEAK y ACTIVATE) como limitadores delentorno del componente. Dichas transiciones son especificadas por el usuario eincorporadas en cada uno de los procesos que forman el sistema para limitar elcomportamiento del entorno. Una de las desventajas de este método es que eloperador de composición propuesto no es asociativo, lo que implica que ademásde la especificación del sistema y las transiciones limitadoras, el usuario debeincluir explícitamente el orden de composición de cada uno de los subsistemas.

Alur et [Alur99] proponen una técnica que construye automáticamente módulosabstractos a partir de la información obtenida acerca de la alcanzabilidad ycontrolabilidad en el espacio de estados del módulo concreto. La ventaja de estemétodo es que es completamente automático, siendo necesaria únicamente laintervención del usuario para especificar las variables que son relevantes a otrosmódulos. La técnica se ha implementado en la herramienta de verificaciónMOCHA [Alur98].

2.6.2 Razonamiento Suposición-Compromiso

Las técnicas conocidas en general como suposicion-compromiso (tambiénassume-guarantee ó rely-guarantee) tratan el problema del entorno limitando sucomportamiento mediante las especificaciones de suposiciones que hace uncomponente sobre el entorno (resto de componentes), y que posteriormente elentorno debe garantizar. Por tanto, la técnica se aplica a la verificación de cadauno de los componentes por separado.

Supóngase que tenemos un sistema formado por dos procesos P y Q que secomunican entre ellos. Dado que el comportamiento del proceso P depende del


36

comportamiento del proceso Q, el analista especificará un conjunto desuposiciones que debe satisfacer el proceso Q para garantizar la corrección delproceso P. Dado que también el proceso Q depende del proceso P, igualmente elusuario especificará un conjunto de suposiciones que debe cumplir el proceso Ppara garantizar la corrección del proceso Q. Combinando el conjunto depropiedades asumidas y garantizadas por los procesos P y Q de una formaadecuada, es posible realizar la verificación del sistema completo P||Q sinconstruir el grafo global de estados. Por tanto, en el contexto de verificaciónmodular utilizando suposiciones y compromisos, la especificación debe incluirdos partes [Misr81] [Jone83] [Lamp83]: una parte describe el comportamiento delcomponente o módulo y la otra describe el comportamiento que se supone delsistema cuando interactúa con el componente.

De forma general, se puede expresar lo anterior mediante la siguiente regla deinferencia para mostrar que el proceso P satisface la propiedad φP:

PQ

PQ QPQP

φϕ

φϕ=�

��

=

=|||

||||

La propiedad ϕQ representa la suposición realizada por el proceso P sobre elentorno (componente Q). La primera parte de la regla representa la introducciónde suposiciones en el componente a verificar (en este caso, el proceso P) y lasegunda el proceso de comprobación de que la suposición es correcta en elentorno. Nótese que en la regla anterior, P || ϕQ |= φP significa que P || Q’ |= φPpara todo Q’ tal que Q’ |= ϕQ. Desde este punto de vista, este método es másflexible que la minimización composicional, pero suele requerir más intervencióndel usuario.

Existen multitud de formas de representar las reglas de inducción en un contextode razonamiento suposición compromiso. En [Pnue85] una fórmula es un tupla<A>M<P> donde M es un componente, P es una propiedad y A es una suposiciónsobre el entorno de M. La fórmula es cierta, si cuando M es parte de un sistemaque satisface A, entonces el sistema también debe garantizar P. La reglacomposicional más simple muestra que si las formulas <A>M1<P> y<true>M2<A> se cumplen, entonces <true>M1||M2 <P> también se cumple. Loanterior se puede representar por la siguiente regla de inferencia:

��

��

��PMMtrue

AMtruePMA

212

1 ||

En el paradigma basado en lógica temporal, las fórmulas A y P son fórmulas LTL,por lo que el significado de la fórmula <A>M<P> indica que todas lascomputaciones del componente M están garantizadas para satisfacer P,suponiendo que todas las computaciones del entorno satisfacen A. En este caso,las fórmulas A y P puede ser combinadas en una única fórmula LTL, A→P.Es importante notar que la regla anterior no es simétrica en el uso de amboscomponentes y no soporta circularidad. Abadi y Lamport [Abad93] mostraron quebajo ciertas condiciones en los procesos y propiedades a verificar, si P se cumplesuponiendo Q y Q se cumple suponiendo P, entonces P y Q se cumplen. Las


37

propiedades a verificar únicamente pueden ser especificadas como propiedades deseguridad y los procesos solamente pueden modificar conjuntos disjuntos devariables bajo un modelo de concurrencia entrelazado. Alur y Henzinger [Alur96]relajaron esta última restricción, pero mantienen la limitación de aplicación apropiedades de seguridad. McMillan [McMi99] extiende la técnica también apropiedades de vivacidad, implementándola en el comprobador de modelos SMV.

Otro sistema inductivo de razonamiento modular basado en suposicióncompromiso, muy similar al anterior, es el conocido como el teorema decomposición de Lamport [Abad95]. Dado un sistema M=[M1||M2] se deseaverificar la propiedad expresada como φ = φ1 ∧ φ2. Siguiendo el teorema decomposición, basta con verificar que cada propiedad φi es cierta en cadacomponente Mi cuando se cumple una cierta suposición ϕi del entorno de cadacomponente Mi. Además se ha de cumplir que cada componente Mi garantiza lasuposición ϕj para i≠j. Para dos componentes, se puede representar lo anteriormediante la siguiente regla:

2121

12

21

222

111

|||

||

)(|)(|

φφ

ϕϕ

φϕφϕ

Λ=��

�

�

====

MM

MMMM

La expresión Mi |=(ϕi) φi indica que la formula φi es cierta sobre el modelo Misuponiendo que en su entorno se cumple ϕi. Aunque, en esencia, el significado dela anterior regla de inducción es el mismo que cualquier otra especificación delrazonamiento basado en suposición compromiso (por ejemplo, el indicadoanteriormente en [Pnue85]), en esta tesis nos basaremos en el teorema decomposición anterior.

Sin embargo, sea cual sea el sistema inductivo de verificación, hay una serie dedificultades para que este estilo de razonamiento pueda ser implementado en uncomprobador de modelos. En primer lugar, se debe asegurar que todo sistema quecontiene a un componente dado satisface una determinada propiedad local. Ensegundo lugar, está propiedad puede cumplirse únicamente bajo ciertascondiciones, por lo que es necesario realizar suposiciones sobre el componentecuando se realiza la verificación. Grumber y Long [Grum94] describen uncomprobador de modelos que soporta el razonamiento basado en suposición-compromiso que automatiza el primer problema. Para ello, identifican unsubconjunto de la lógica CTL cuyas propiedades se preservan bajo composición ydefinen una relación de preorden entre los modelos que representan al sistema y alcomponente, de modo de que, si una determinada fórmula es cierta en un modelo(componente), también es cierta en cualquier modelo que es más pequeño en elpreorden (sistema).

En el siguiente apartado se comentan y discuten brevemente algunas técnicas ymétodos para automatizar el segundo de los problemas enunciado anteriormente.Dado que es el objetivo principal de esta tesis, más detalles se pueden encontraren los Capítulos 4 y 5.


38

2.6.3 Derivación Automática de Suposiciones

Uno de los aspectos menos estudiados en el contexto de la verificación modularbasada en suposición compromiso es el referido al desarrollo de técnicas ymétodos que permitan derivar automáticamente suposiciones o entornosabstractos sobre los componentes a verificar. Aunque realmente el problema no esnuevo (tiene la misma “antigüedad” que los primeros trabajos en razonamientomodular), hasta donde llega el conocimiento del autor, existen pocas soluciones alproblema de la generación automática de suposiciones y todas ellas son muyrecientes.

El objetivo es encontrar la suposición más adecuada para un componente dado deforma automática (o semiautomática) [Henz98], de forma que, durante el procesode verificación de cada componente, no se requiera la intervención del usuariopara especificar el entorno abstracto con el cual se comunica el componente, sinoque éste sea generado automáticamente. De este modo y colateralmente, si elproceso de construcción de los entornos es correcto, no es necesario realizar lacomprobación de que las suposiciones obtenidas son válidas (descarga de lasuposición en las reglas de inducción de la Sección 2.6.2). Además, existe uninterés creciente en el desarrollo de técnicas y teorías sobre el análisis y diseño desistemas basados en componentes [Alfa01a] [Alfa01b], y su utilización en nuevasaplicaciones basadas en desarrollos soportados por componentes (softwareempotrado, aplicaciones para Internet, etc.). Por tanto, el desarrollo de nuevosmétodos para generar de forma automática los entornos de ejecución de loscomponentes sería muy interesantes para su validación.

El problema de generar automáticamente un conjunto de suposiciones para uncomponente dado es un problema similar al de generar componentes de interfazen el contexto de la minimización composicional [Cheu96] (Sección 2.6.1). Sinembargo, tal y como se apunta en [Cheu96], los componentes de interfazobtenidos automáticamente necesitan en muchos casos ser completados conresguardos especificados manualmente por el usuario, dado que los generadosalgorítmicamente pueden no limitar suficientemente el comportamiento delentorno.

Colby et al [Colb98] detallan una técnica de análisis estática basada en un análisisde flujo de datos para determinar la influencia de los datos externos de entradarecibidos por un componente, y la utilizan para obtener el entorno más general enel cual se puede ejecutar el sistema. La técnica es implementada en la herramientade verificación Verisoft [Gode97] y se aplica al análisis de un componente escritoen el lenguaje C. Una desventaja del método propuesto es que no se describe laforma de controlar la precisión del sistema generado.

En el trabajo presentado en [Gian02] se muestra un método para incrementar lainformación que el usuario obtiene en la verificación de una determinadapropiedad sobre un componente. Específicamente, el algoritmo propuestodevuelve uno de los siguientes resultados: el componente satisface la propiedadpara cualquier entorno, el componente viola la propiedad para cualquier entorno óse obtiene automáticamente una suposición que caracteriza exactamente aquellosentornos en los que el componente satisface la propiedad. Esta última salida


39

representa la suposición más débil del entorno sobre la cual se verifica lapropiedad. Utilizando esta suposición se puede automatizar el proceso derazonamiento de suposición-compromiso. Una desventaja de la técnica es ladependencia de la propiedad a verificar, ya que las suposiciones obtenidas secomputan en base a la propiedad requerida, por lo que en el caso de que sobre elcomponente fuese necesario verificar varias propiedades, se debería de ejecutar elalgoritmo tantas veces como propiedades existan a verificar. Los autores nodetallan cuantitativamente los resultados de la verificación, por lo que no se puedeestablecer a priori la bondad del método propuesto.

En [CoblP03] se describe un método que utiliza el algoritmo de aprendizaje L*

[Angl87] para computar las suposiciones de un componente en la verificaciónlocal de una determinada propiedad. El método es incremental, en el sentido queinicialmente las suposiciones obtenidas son aproximadas, pero gradualmente sehacen más precisas por medio de los contrajemplos obtenidos en la verificacióndel componente y de la suposición. Al igual que en la técnica anterior, el métodoes dependiente de la propiedad a verificar, las suposiciones obtenidas en cada unode los pasos deben ser descargadas sobre el entorno para que el proceso derefinamiento sea efectivo y las suposiciones dependen también del componente averificar, por lo que no parecen adecuadas para su utilización en verificaciones deregresión. Esta técnica se ha implementado sobre programas escritos en JAVA yrecientemente se ha desarrollado una herramienta que la soporta [Tkac03].

En trabajos previos en los que ha participado el autor [Riva01b], se propone unmétodo para generar automáticamente entornos abstractos en forma de reglas deasociación que explican patrones de comportamiento del entorno. Estos patronesse pueden utilizar como suposiciones en la verificación de cualquier propiedadsobre el componente. La técnica está basada en la exploración del espacio estadosde entorno de componente, sobre el cual se generan patrones de comportamientotemporales relativos a las variables de “interés” del módulo bajo análisis (paramás detalle ver Capítulo 4). Una de las principales ventajas del método propuestoes su generalidad, ya que las suposiciones obtenidas son válidas para cualquierpropiedad a verificar sobre el componente. Este método se extiende en [Riva03]para generar suposiciones (más refinadas y posiblemente más detalladas) paravarios componentes del sistema en un único paso (Capítulo 5).

Capítulo 3Computación de Espacios deEstadosPara poder obtener restricciones de un componente que sean independientes de lapropiedad a verificar y del propio componente, es preciso establecer un métodopara generar las configuraciones o secuencias de ejecución del entorno de dichocomponente.

En este Capítulo, se describe en primer lugar el modelo computacional utilizadopara la representación y verificación del sistema y sus componentes. Elformalismo se denominará Sistema Reactivo Síncrono y está basado en máquinasde estados con una semántica similar a la utilizada en RSML o STATEMATE.

Posteriormente, se expone el algoritmo realizado para la generación del espacio deestados del entorno del componente bajo verificación, utilizando como modelocomputacional un Sistema Reactivo Síncrono. El algoritmo se basa en técnicas deanálisis de alcanzabilidad, pero haciendo visibles las interacciones internas omicropasos que están presentes en la semántica del modelo computacionalpropuesto.

Finalmente se discuten algunas optimizaciones y modificaciones que se realizaránpara la generación del espacio global de configuraciones.

Computación de Espacios de Estados

43

3.1 IntroducciónComo se comenta al inicio de esta tesis, el objetivo fundamental es la generaciónde suposiciones del entorno de componentes para su utilización en un contexto deverificación modular. Por tanto, es preciso desarrollar previamente un método quepermita obtener una representación del entorno del componente, o dicho de otraforma, un método que permita generar el espacio de estados del entorno delcomponente, para posteriormente derivar las suposiciones.

Dicho método debe ser consistente con la sintaxis y semántica de ejecución delverificador, de forma que, el proceso posterior de generación de suposiciones apartir de las configuraciones no introduzca limitaciones erróneas. Por tanto, lasemántica utilizada para la generación de las configuraciones del entorno de uncomponente debe ser la misma que la utilizada por el comprobador de modelospara su verificación.

Para ello, en este Capítulo se define un modelo formal que describe la semánticadel sistema y de sus componentes, y que posteriormente será utilizada tanto parala generación de las configuraciones del entorno de los componentes como para suposterior verificación con un comprobador de modelos.

3.2 Modelo ComputacionalEn esta sección se describe el formalismo utilizado para la especificación delsistema y de cada uno de sus componentes, y que servirá igualmente comomodelo formal para su verificación utilizando un comprobador de modelos.

El modelo computacional se desarrolla a partir de los formalismos gráficos quedescriben la parte de control del sistema en una especificación gráfica SA/RT(Diagramas de Transición de Estados o STDs). La semántica de ejecución seproporciona con dos niveles de tiempo (macropasos y micropasos) similar a lautilizada en el lenguaje RSML y la herramienta de soporte a StatechartsSTATAMATE.

El formalismo está basado en el modelo de Autómata Jerárquico Extendido paraStatecharts presentado en [Mikk97]. La semántica operacional será similar a ladescrita en el trabajo anterior y está basada en reglas de ejecución.

3.2.1 Diagramas de Transición de Estados

Como se comenta en el Capítulo 2, en las especificaciones SA/RT elcomportamiento de los procesos primitivos de control se detalla utilizando unDiagrama de Transición de Estados (STD). Un STD contiene un conjunto deestados en los que puede estar el proceso y un conjunto de transiciones que puederealizar entre los estados. Dado que se utilizará un STD para definir a un proceso,el término “proceso” y “STD” se utilizarán de forma indistinta a lo largo de estatesis.

Formalmente, un STD es una quíntupla (Σ,so,I,O,δ) donde:


44

� Σ: es el conjunto de estados del proceso

� so: es el estado inicial, so∈ Σ� I: es el conjunto de eventos que recibe el proceso

� O: es el conjunto de eventos que envía o produce el proceso

� δ: es la relación de transición entre estados, δ ⊆ Σ×I×O×Σ

Se denota la transición τ=(s,c,a,s’)∈δ como →ac que significa que el proceso

ejecuta la transición τ cuando recibe el evento c, cambiando al estado s’ yproduciendo el conjunto de eventos a⊂ O. El par (c,a) se denomina etiqueta de latransición, donde c representa a la condición, y a es el conjunto de acciones.

La sintaxis y semántica original para SA/RT [Ward86] especificaba que unacondición en un STD solamente podía estar formada por eventos individuales.Para que la especificación sea más potente y expresiva, en esta tesis se relaja elcondicionante anterior, de modo que las condiciones en un STD puedan estarformadas por combinaciones lógicas de eventos en I, valores de estados de otrosprocesos (nos referimos a éstos como S.proceso=estado, donde proceso es elnombre de un proceso en la especificación y estado es un estado del proceso) y laproposición true, que será equivalente a la condición vacía en el modelo gráfico.

Todo STD tiene implícitamente una variable de control o estado de control π quedenota el estado local del proceso (inicialmente, π=so). Una transición τ=(s,c,a,s’)se dice que está activa o habilitada (enabled) si π=s y la evaluación de c es cierta.El conjunto de todas las transiciones activas en un estado s se denotan porenabled(s).

3.2.2 Sistema Reactivo Síncrono

Un Sistema Reactivo Síncrono (en adelante SRS) está formado por un conjunto deSTDs interaccionando sobre un conjunto de eventos de entrada y un conjunto deeventos de salida. Intuitivamente, se puede ver un SRS como un subsistema querecibe un conjunto de eventos de entrada y produce un conjunto de eventos desalida en función de un comportamiento definido por un conjunto de Diagramasde Transición de Estados.

La semántica que describe el comportamiento del SRS está basada en la hipótesisde sincronismo de Berry [Berr92] relativa a los lenguajes de especificaciónsíncronos y en la semántica de macropasos y micropasos utilizada en RSML[Leve94] y STATEMATE [Hare96]. Aunque sería posible adoptar para el SRS lasemántica original de Ward [Ward86], ésta contiene un alto de no determinismo(aunque sí estaba especificada en términos de macropasos o interaccionesexternas). Las semánticas de RSML y STATEMATE son más casuales ydeterminísticas.

Básicamente, la ejecución de un SRS puede ser vista como una serie infinita demacropasos que producen secuencias de eventos de salida en respuesta a loseventos de entrada, e internamente la ejecución es una cadena de micropasos,donde, en cada uno, el sistema reacciona a eventos de entrada produciendo


45

eventos de salida y eventos internos (no visibles en el SRS para un observadorexterno) que pueden iniciar otro micropaso. El macropaso finaliza cuando no sepueden ejecutar más micropasos. A continuación se define la sintaxis y semánticade un SRS.

3.2.2.1 Sintaxis

Un Sistema Reactivo Síncrono (SRS) es una quíntupla (∆,GE,IE,OE,→µ) donde:

� ∆ es el conjunto de STD que lo forman, ∆={M1,M2,...,Mn}� GE es el conjunto de eventos internos que comunican cada STD

��n

ii

n

ii OIGE

11 ==

∩=

donde Ii y Oi son los conjuntos de eventos de entrada y salida, respectivamente, decada STD Mi∈∆� IE es el conjunto de eventos de entrada que recibe el SRS

GEIIEn

ii −=

=�

1

� OE es el conjunto de eventos de salida que produce el SRS

GEOOEn

ii −=

=�

1

� →µ es la relación de transición que describe la semántica introducida arriba.

El estado inicial de un SRS está formado por el conjunto de estados iniciales decada STD del SRS, So={so,s1,...,sn}. Un estado (global) de un SRS está formadopor los estados de control de cada STD, S={π1,π2,...,πn}. Se denota porC=(S,G,I,O) una configuración del SRS, donde G, I y O son los valores de loseventos internos, de entrada y de salida, respectivamente, y S es el estado del SRS.El conjunto de todas las posibles configuraciones de un SRS Φ se denota porGlobal(Φ). La relación de transición →µ define la semántica, y se detallará en lapróxima sección.

Dado un sistema formado por varios SRS, se denomina interfaz de entrada (II)para un SRS i (IIi⊆ IE) al conjunto de eventos enviados o generados por otrosSRSs en el sistema que son de entrada para el SRS i. Es decir:

ijOESalidasSalidasIEII

jj

ii

≠=

∩=

�

Análogamente se define el interfaz de salida(IO):

ijIEEntradasEntradasOEIO

jj

ii

≠=

∩=

�


46

3.2.2.2 Semántica

La semántica de un SRS Φ se define en función de su relación de transición→µ⊆ Global(Φ)×Global(Φ), de acuerdo a las siguientes reglas de inferencia:

Regla de Avance 1: Se aplica a un STD Mi si tiene transiciones habilitadas en unestado de la configuración actual. Si el STD tiene varias transiciones habilitadasen la configuración, se toma una de ellas de forma no determinística:

)),,'),,...,',...,(),,),,...,,...,((

))(/':()(

11 iinini

iiiaciii

AOAsOIGs

senabledsss i

i

∪∅→

∈∈→∃∧=

ππππ

τδτπµ

donde Ai={e∈ ai/e∈ O} y A’i={e∈ ai/e∈ G}.

Es decir, el STD ejecuta su transición habilitada, cambiando de estado ygenerando nuevos eventos de salida e internos. Nótese que de acuerdo a lahipótesis de sincronismo los eventos internos “desaparecen” una vez utilizadoshasta el siguiente macropaso.

Regla de Avance 2: Se aplica a varios STDs que tienen transiciones habilitadas.Este caso corresponde con la ejecución simultánea y paralela de varios procesos:

)),,''),,...,',...,',...,(),,),,...,,...,,...,((

))(/':()(

))(/':()(

11 jijinjinji

jjjacjjj

iiiaciii

AAOAAssOIGss

senabledsss

senabledsssj

j

i

i

∪∪∅∪→

∈∈→∃∧=

∈∈→∃∧=

ππππ

ρδρπ

τδτπ

µ

Si para un STD Mi existe un estado sj tal que πi=sj y card(enabled(sj))>1,entonces el SRS se considera no determinístico. En caso contrario, el SRS esdeterminístico.

Regla de Avance 3 (“Stuttering”): Esta regla se aplica a un STD Mi que tiene unestado en la configuración actual y no tiene transiciones habilitadas. En este caso,el STD “consume” eventos, pero no los produce:

)),,),,...,,...,(),,),,...,,...,((

))(/':()(

11 OsOIGs

senabledsss

nini

iiiaciii

i

i

∅∅→

∈∈→¬∃∧=

ππππ

τδτπµ

Esta regla es adecuada para representar el concepto de reactividad de los SistemasReactivos Síncronos: en cualquier estado existe, al menos, una transición aejecutar.

Las tres reglas anteriores muestran la ejecución del SRS a nivel de micropaso.Cuando todos los STDs M1,M2,...,Mn en el SRS únicamente puedan avanzarejecutando la regla 3, el sistema ha alcanzado una configuración estable, es decirno se puede ejecutar más transiciones en el macropaso.

Por tanto a nivel de macropaso, la ejecución de un SRS puede verse como unasecuencia de configuraciones estables, donde en cada una de ellas el SRS recibeun conjunto de eventos de entrada I y produce un conjunto de eventos de salida O:

),,,'('),,,( OSCISC ∅∅=→∅∅= η


47

donde S y S’ representan los estados globales del SRS antes y después delmacropaso, C’ es una configuración estable, y →η intuitivamente representa unacadena de micropasos:

''' 1 CCCCCC nµµµµη →→→→≅→ �

3.3 Generación de ConfiguracionesComo se comenta en la introducción, una vez definida la sintaxis y la semánticadel sistema, y previamente al proceso de obtención de suposiciones, es necesarioproporcionar un método para la computación y representación de los estados oconfiguraciones del entorno. Este es el objetivo de esta sección.

La generación de configuraciones para un componente consistirá básicamente enla exploración de todas las posibles trazas de ejecución del componente utilizandola semántica para Sistemas Reactivos Síncronos propuesta anteriormente.

Esta sección comienza con una breve descripción de la técnica general empleada,para posteriormente adaptarla a la semántica del modelo computacional.

3.3.1 Esquema Básico de un Algoritmo de Alcanzabilidad

Una de las técnicas más utilizadas en el análisis automático de sistemasconcurrentes de estados finitos son aquellas basadas en el análisis dealcanzabilidad (reachability analysis). Las técnicas de este tipo intentan generar yexplorar todos los estados de un sistema que son alcanzables desde un estadoinicial, enumerando explícitamente cada uno de los posibles caminos deejecución. En un sistema concurrente se construye un grafo de alcanzabilidad apartir de los modelos de procesos individuales que contiene todos los estadosalcanzables. Un posterior análisis del grafo de alcanzabilidad permite laverificación de ciertas propiedades de estado (terminaciones impropias, validaciónde asertos, etc.) y de secuencias de estados (ciclos de no progreso o “livelocks”,propiedades temporales, etc.).

El análisis de alcanzabilidad es una técnica muy atractiva, ya que es simple yrelativamente fácil de automatizar. Se ha aplicado al análisis de protocolos decomunicación [Suns81] [Holz91], en sistemas orientados a objeto [Iyer01] yutilizado conjuntamente con técnicas de comprobación de modelos [Clar86].

Un algoritmo general de búsqueda para un espacio de estados basado en el análisisde alcanzabilidad aplicado a un sistema de transiciones de estados se muestra enla Figura 10.


48

W = {estado_inicial} /*Working Set: Estados a Analizar */A = { } /*Estados Visitados */mientras ( W no vacio ) hacer Seleccionar algun estado s de W Eliminar s de W Añadir s a A para cada transicion t activa en s hacer Ejecutar t sobre s, obteniendo s’ si ( s’ no esta en W || s’ no esta en A ) entonces Añadir s’ a W fin_si fin_parafin_mientras

Figura 10: Algoritmo de alcanzabilidad

La estructura de W determina dos tipos diferentes de algoritmos. Si W esimplementado como una cola (eliminando los estados en base a primero que entraprimero que sale), se tiene una estrategia de búsqueda basada en anchura o BFS(breadth-first search). Si W se representa por una pila (eliminando los estados enbase a último que entra primero que sale), la búsqueda es en profundidad o DFS(depth-first search). A la finalización de la ejecución del algoritmo anterior, elconjunto A contiene el espacio de estados alcanzables del sistema de transiciones.

Una técnica basada en profundidad necesita un menor tamaño de W, sin embargouna técnica basada en anchura obtiene primero las secuencias de error más cortas(camino más corto desde el estado inicial hasta el estado que produce el error).

En este tipo de técnicas estáticas para el análisis automático de sistemas esimportante representar cada estado del espacio global con la suficienteinformación, de modo que, se puedan calcular los estados sucesores respecto a lastransiciones habilitadas. También es importante distinguir un estado de otro, yaque en caso contrario podría suceder que la búsqueda nunca terminase. Por otraparte, la forma en que los estados se almacenan en memoria afecta profundamentea la eficiencia del análisis. En general, para que los estados se puedan recuperar deuna forma rápida, éstos se almacenan en memoria en una tabla hash. También sepueden utilizar técnicas de compresión de estados [Holz91] para minimizar eltamaño del espacio de estados.

3.3.2 Computación del Conjunto de Configuraciones

Para la generación del espacio de configuraciones del entorno del componentebajo verificación se utiliza un algoritmo basado en el esquema presentado en lasección anterior. El proceso de generación y representación de las configuracionesdebe tener en cuenta la semántica de ejecución del Sistema Reactivo Síncrono querepresenta al componente. A continuación, se discuten las posiblesrepresentaciones de configuraciones en el grafo de alcanzabilidad, paraposteriormente presentar el algoritmo que computa las configuraciones delcomponente.


49

3.3.2.1 Representación de Configuraciones

Como paso previo a la descripción del algoritmo utilizado para la generación delconjunto de configuraciones de un componente, se comentan brevemente algunosmatices sobre su representación.

El concepto de estado al que se hace referencia en el algoritmo de alcanzabilidaddebe ser discutido. Una configuración C=(S,G,I,O) de un Sistema ReactivoSíncrono (componente) describe completamente el estado del sistema en uninstante determinado, donde S es el estado (global) del Sistema Reactivo Síncronoy G, I,O son los valores de los eventos internos, de entrada y salidarespectivamente en ese mismo instante. Desde ese punto de vista, unaconfiguración realiza el papel de estado en el algoritmo básico de alcanzabilidad.

Un punto fundamental en la representación de configuraciones es aquel que hacereferencia explícitamente al instante al que produce. De acuerdo a la semántica dedos niveles de tiempo – macropaso y micropaso - adoptada para los sistemasreactivos síncronos, una determinada configuración puede referirse bien a unmacropaso o bien a un micropaso. Se discuten las posibles representaciones:

Configuraciones a nivel de macropaso: Permiten representar la ejecución delsistema desde una visión externa. El entorno produce eventos de entrada (I) y elsistema responde cambiando de estado y enviando eventos de salida (O). No sonvisibles las interacciones internas (micropasos), y por tanto no es necesarioalmacenar de forma permanente los valores de las variables o eventos internos(G). Así, un macropaso del sistema podría representarse por la siguiente relaciónentre dos configuraciones consecutivas i y j, donde Ci hace referencia a laconfiguración al comienzo del macropaso y Cj se refiere a la configuración alfinalizar el macropaso:

Ci=(Si,Ii,∅ ) → Cj=(Sj,∅ ,Oj)

En este nivel de representación, la relación “→” indica la ejecución de unatransición global realizada en el sistema observable desde un punto de vistaexterno.Configuraciones a nivel de micropaso: Representan la ejecución del sistema “endetalle”, es decir permiten representar explícitamente las interacciones internasque se producen en el sistema. Por tanto, es necesario guardar de formapermanente los valores de las variables internas del sistema (G) ya que configuransu estado y, por tanto, el posible conjunto de transiciones habilitadas. Unmicropaso se puede representar por la siguiente relación entre configuracionesconsecutivas i y j:

Ci=(Si,Gi,Ii,Oi) → Cj=(Sj,Gj,∅ ,Oj)

Al igual que la representación anterior, la relación “→” representa la ejecución deuna transición global en el sistema, pero se corresponde con una visión interna,donde las interacciones son visibles.

Desde este punto de vista, un macropaso es un conjunto de micropasos y para surepresentación son necesarias las configuraciones internas correspondientes a cadauno de los micropasos:


50

Ci=(Si,∅ ,Ii,∅ ) → C1 → C2 →...→Cn → Cj=(Sj,∅ ,∅ ,Oj)

donde C1 → C2 →....→ Cn representan la secuencia de micropasos dentro delmacropaso.

Teniendo en cuenta factores tales como la eficiencia en el almacenamiento yrepresentación de configuraciones no cabe duda de que aquella referente a unavisión de macropaso es más adecuada; por una parte, se necesitan menos variablespara representar las configuraciones (las variables internas no se consideran), ypor otra, se necesitan menos configuraciones en el espacio global de estados delsistema.

Sin embargo, existe una razón poderosa para la elección de la representaciónexplícita de los micropasos. En el contexto de verificación modular, los eventosinternos que comunican los componentes deben tratarse de forma diferente alresto dependiendo de si su ejecucición se corresponde con un macropaso o con unmicropaso, y de si actúan como entradas o salidas. Supóngase por ejemplo unsistema S formado por dos componentes P y Q, que se comunican por medio deun evento interno f que envía el componente P al componente Q. Para realizar laverificación del componente Q, es necesario realizar suposiciones sobre el eventof que comunica ambos componentes. Para no alterar la semántica del sistemacompleto S, f debería de tomar valores en cada micropaso. Si se utiliza comorepresentación de las configuraciones de P la basada en macropasos, no seríaposible deducir los valores que toma f en cada uno de los micropasos, ya quesolamente su valor estaría disponible en un macropaso dado, y por tanto lageneración de comportamientos para f estaría en cierto modo falseada.

3.3.2.2 Contador de Micropasos

Por la misma razón, las configuraciones deben hacer referencia explícita a losinstantes en que se producen por lo que a la configuración se le añade una variableµP que realiza las veces de contador del micropaso. Dicha variable pasa a formarparte de la configuración del sistema y se incrementa en uno en las interaccionesinternas o micropasos, y se inicializa cuando el sistema alcanza una configuraciónestable (fin del macropaso). De este modo, una configuración contieneinformación de los valores de las variables y del instante en que éstos se toman:

C = ( S, I, O,G, µP)

Siguiendo el mismo formato utilizado para la representación de micropasos, yteniendo en cuenta la variable contador de micropaso, un micropaso se puederepresentar utilizando la siguiente relación entre configuraciones consecutivas:

Ci=(Si, Gi, Ii, Oi, µP) → Cj=(Sj, Gj,∅ , Oj, µP+1)

Representado los micropasos dentro de un macropaso, la relación entreconfiguraciones sería:

Ci=(Si, ∅ , Ii, ∅ , 0) → C1 → C2 →...→Cn → Cj=(Sj, ∅ , ∅ , Oj, n)

En la configuración correspondiente al inicio del macropaso (Ci), el contador demicropaso está inicializado a cero y se incrementa en uno en cada ejecución de unmicropaso. Al final del macropaso (Cj), el contador de micropasos contiene la


51

longitud del macropaso o número de micropasos ejecutados en el macropaso. A lallegada de nuevos eventos procedentes del exterior (I), el contador se inicializaríade nuevo para reflejar la ejecución de un nuevo macropaso.

3.3.3 Algoritmo Básico

Dado un componente M, el algoritmo de la Figura 11 genera el conjuntoGlobal(M) de todas las configuraciones posibles del componente de acuerdo a lasemántica definida en la Sección 3.2 utilizando un algoritmo de alcanzabilidad.

/* Formar la configuración inicial */ S = estado inicial de M; ∀ evento fi ∈ I fi=0; /* Valores de eventos de entrada de M, I */ ∀ evento fo ∈ O fo=0; /* Valores de eventos de salida de M, O */ ∀ evento fg ∈ G fg=0; /* Valores de eventos internas de M, G*/ µP = 0; /* Contador de micropasos µP */ C = (S,G,I,O,µP); Global = {C}; Alcanzables = { }; Pendientes = {S}; mientras ( Pendientes ! = ∅ ) hacer

estado = Pop(Pendientes); Push(estado,Alcanzables); para cada combinacion de valores en I, V(I) hacer /* Valores del entorno */ /* Comienzo de macro pasos */ S = estado; CI = V(I); /* Reset variables internas y de salida */ ∀ evento fg ∈ G fg = 0; ∀ evento fo ∈ O fo = 0; microPaso = 0; C = (S,G,I,O, µP); Añadir C a Global; C’ = MicroPasos (C); /* C’ es una configuracion estable */ estado’ = C’.S; si ( estado’ no esta en Alcanzables || estado’ no esta en Pendientes ) entonces Añadir estado’ a Pendientes; fin_si fin_para fin_mientras

Figura 11: Algoritmo para la generación de configuraciones

Al igual que en el esquema básico del algoritmo de alcanzabilidad de la Figura10, se utilizan dos estructuras de datos, Alcanzables y Pendientes para almacenarlos estados (globales) alcanzables y aquellos pendientes de analizar,respectivamente. También se utiliza una estructura Global (implementada comouna tabla hash) para almacenar cada una de las configuraciones generadas.


52

El bucle más interno del algoritmo representa la ejecución de un macropaso delsistema dada una combinación de valores de los eventos de entrada delcomponente (I) partiendo de un estado (global) alcanzable. La cadena demicropasos del macropaso se realiza utilizando la función MicroPasos que seespecifica en la Figura 12. Cuando ya se ha completado un macropaso a partir deuna combinación de valores de los eventos del entorno, la configuración resultantese almacena en Pendientes, y se continua con otra combinación de valores en loseventos de entrada, para así generar otro macropaso. Este proceso se repite paratodas las posibles combinaciones de valores en los eventos del entorno y para cadaestado alcanzable pendiente de analizar. Debido a que se consideran todas lasposibles combinaciones de valores en los eventos de entrada, se exploran todas lasconfiguraciones del componente.

3.3.4 Computación de Micropasos

En la Figura 12 se describe el algoritmo para el cómputo de la cadena demicropasos a partir de una configuración estable.

Accion MicroPasos (Configuracion C)

mientras ( H=Habilitadas (C) != ∅ ) hacer /* ejecucion de un micropaso */ µP = µP + 1; C’ = Aplica_Regla_Avance (C,H); Añadir C’ a Global; C= C’; fin_mientras /* C es una configuracion estable */ Devolver C;

fin_accion

Figura 12: Computación de micropasos

Partiendo de una configuración que corresponde al “inicio” de un macropaso, sedetermina el conjunto de transiciones habilitadas en H y se ejecutan de acuerdo alas reglas de avance descritas en la Sección 3.2, formándose un micropaso. Laejecución de este micropaso, a su vez, puede habilitar otro conjunto detransiciones que darán comienzo a otro nuevo micropaso, y así sucesivamentehasta que no haya más transiciones habilitadas. La configuración al final de lacadena de micropasos es una configuración estable y finaliza el macropaso. Esimportante hacer notar, y así está reflejado en el algoritmo de ejecución demicropasos, que cada una de las configuraciones correspondientes al micropaso seguardan también en Global, haciendo de este modo visibles las interaccionesinternas. Los estados solamente se almacenarán en Alcanzables cuando se alcanzauna situación de estabilidad (Figura 11) que se corresponde con una visiónexterna de la ejecución del sistema.

En la Figura 13 se muestra de izquierda a derecha un esquema de la secuencias degeneración de las configuraciones de acuerdo al algoritmo de la Figura 11.


53

1 2 3...

Figura 13: Secuencia de generación de configuraciones

Los nodos sombreados representan configuraciones estables (o estadosalcanzables globales) mientras que los nodos en blanco representanconfiguraciones correspondientes a los diferentes micropasos. Cada arco que salede una configuración estable corresponde a una combinación de valores de loseventos de entrada del componente y cada arco que parte de una configuración demicropaso representa la ejecución de una transición global en el componente.

El esquema etiquetado con 1 corresponde a la generación de un macropaso a partirde la primera combinación de valores en los eventos de entrada partiendo de laconfiguración inicial del componente. Posteriormente y de igual manera, segeneraría otro macropaso para otra combinación de valores de entrada (esquema2). El esquema 3 refleja la situación donde ya se han generado todos los posiblesmacropasos (y micropasos) a partir de la configuración inicial teniendo en cuentatodos los posibles valores de los eventos de entrada (debido a que hay cuatro arcosque salen de la configuración inicial, el componente tendría dos eventos deentrada) y el comienzo de la generación de macropasos para la primera de lasconfiguraciones estables pendientes de analizar (el nodo “estable” situado más a laizquierda). Si se sigue representando la secuencia completa, al final se obtendríael grafo global de ejecución del componente.

3.3.5 Ejemplo

Para ilustrar el proceso de generación de configuraciones siguiendo los procesosdescritos en las secciones anteriores, supóngase el componente especificado en laFigura 14. El componente, en función de ciertos eventos procedentes del exterior(ALTO y BAJO) y del evento procedente de otro componente (Fin_Operación),envía dos órdenes, Comenzar y Finalizar, que iniciarán/finalizarán ciertasoperaciones de apertura/cierre de un dispositivo físico


54

Chequeando

Iniciando

STD Check_Inicio

BAJO/Nivel_Bajo

ALTO/Nivel_Alto

Fin_Operacion

Cerrando Abriendo

Inicio

STD Envio Ordenes

Nivel_Alto /Finalizar

Nivel_Bajo /Comenzar



Figura 14: Especificación de un componente

En la Figura 15 se muestra una traza parcial de configuraciones generadas paradicho componente:

*** Estado Inicial <Chequeando,Inicio>*** Alcanzable <Chequeando,Inicio>

*** Ejecucion desde Inicial+++ Valores Entorno (MACROPASO)

Recibido ALTO = 1;MICROPASO 1

<Chequeando, Inicio> -> <Iniciando,Inicio>Emite Nivel_Alto = 1MICROPASO 2

<Iniciando,Inicio> -> <Iniciando,Cerrando>Emite Finalizar***Estable <Iniciando, Cerrando>***Alcanzable <Iniciando, Cerrando>

+++ Valores Entorno (MACROPASO)Recibido BAJO = 1;MICROPASO 1

<Chequeando,Inicio> -> <Iniciando,Inicio>Emite Nivel_Bajo = 1MICROPASO 2

<Inicando,Inicio> -> <Iniciando,Abriendo>Emite Comenzar****Estable <Iniciando,Abriendo>****Alcanzable <Iniciando,Abriendo>

......*** Ejecucion desde <Iniciando,Cerrando>+++ Valores Entorno (MACROPASO)

Recibido Fin_OperaciónMICROPASO 1

<Iniciando,Cerrando> -> <Chequeando,Cerrando>****Estable <Chequeando,Cerrando>****Alcanzable <Chequeando,Cerrando>

*** Ejecucion desde <Iniciando,Abriendo>......

Figura 15: Ejemplo de generación de configuraciones

Los estados globales del componente se representan utilizando la notación<S1,S2>, donde S1 y S2 indican los estados locales de los STDs Check_Inicio yEnvio_Ordenes, respectivamente. La ejecución de una transición en STD en un


55

micropaso se representará mediante un cambio en el estado global del componentedebido a la ejecución de una transición global. Esto se indica en el ejemploanterior mediante una relación (->) entre el estado global anterior a producirse laejecución de la transición y el posterior a su ejecución. La primera parte delejemplo de la Figura 15 muestra la generación de configuraciones a partir de laconfiguración inicial para algunas combinaciones de valores de entrada (Figura13, esquemas 1 y 2). La segunda parte refleja la generación de configuraciones apartir de una configuración estable generada en fases previas para unacombinación de valores de entrada (Figura 13, esquema 3).

3.3.6 Discusión

En esta sección se ha presentado un algoritmo para la generación y registro de lasconfiguraciones de un componente, utilizando una estrategia en anchura a nivel demacropaso (en cada configuración estable se exploran todas las combinaciones deeventos del entorno) y en profundidad a nivel de micropaso (se genera la cadenacompleta de micropasos para cada configuración estable).

Dado que, el objetivo de la creación del grafo de alcanzabilidad de un componenteno tiene como finalidad la verificación de sus propiedades, podría considerarseque una estrategia en profundidad a nivel de macropaso sería más eficiente, yaque en general el tamaño de las estructuras de datos (en el algoritmo de la Figura11, el conjunto Pendientes) es más pequeño. Sin embargo, las configuraciones quepodrían producir un mayor tamaño en las estructuras de datos no son las referidasa los macropasos sino aquellas referidas a los micropasos, y éstas realmente no seconsideran parte del grafo generado, sino que únicamente se registran en Globalpara su posterior análisis. En experimentos iniciales sobre modelos de tamañomedio no se observaron diferencias importantes en el rendimiento del algoritmocon los dos tipos de estrategias comentados.

3.4 Generación Bajo Condiciones de NoDeterminismo

Hasta este momento el concepto de no determinismo no había sido tratado. Unejemplo de transiciones no deterministas en un STD se muestra en la Figura 16.


56

S1

S2

t1 t2

Figura 16: Transiciones no deterministas

De acuerdo al algoritmo de computación de micropasos de la Figura 12 y a ladescripción de las reglas de avance descritas en la Sección 3.2, la selección delconjunto de transiciones habilitadas en una determinada configuración esdeterminista, es decir si un STD tiene dos transiciones habilitadas en un mismoestado, se selecciona una de ellas y se añade a las habilitadas para laconfiguración.

Sin embargo este tratamiento no es muy realista. Aunque Leveson [Leve95]indica que el no determinismo es el “cáncer de la concurrencia”, muchasespecificaciones de sistemas software se modelan controladamente de manera nodeterminista. En [Heim96] se presenta un método para detectar el nodeterminismo en especificaciones basadas en máquinas de estados, de modo quepueda ser utilizada por el ingeniero como guía para obtener otra especificacióncon un menor grado de no determinismo. Además, tanto la semántica de modelosSA/RT [Ward86] como la de STATEMATE [Hare96] y RSML [Leve94] en lasque se basa las especificación y semántica de esta tesis, contemplan la ejecuciónno determinista. Este concepto de no determinismo también se formula de acuerdoa las notaciones descritas en [Hare96] [Leve94], donde en cada uno de losmicropasos se selecciona un conjunto máximo de transiciones habilitadas. Si ésteno es único, es decir algún proceso tiene más de una transición habilitada, elsistema es no determinista.

Desde este punto de vista, el esquema de generación de configuraciones de uncomponente no es tan trivial como el señalado en la Figura 13, sino que cadanodo (configuración) que corresponde a un micropaso puede dar lugar a variasconfiguraciones y éstas a su vez a otras generadas de forma no determinista hastallegar a diferentes configuraciones estables.

En la Figura 17 se representa el esquema de generación de configuracionesteniendo en cuenta especificaciones no deterministas. Cada arco que parte de unaconfiguración no estable (micropaso) representa una situación de no determinismo(uno de los STDs del componente tiene en un micropaso más de una transiciónhabilitada) y debe ser almacenado igualmente en el conjunto de configuracionesdel componente para reflejar todas las posibles secuencias de ejecución.


57

Figura 17: Configuraciones no deterministas

Por tanto es necesario replantear el algoritmo de la Figura 12 para contemplar elno determinismo en la generación de la cascada de micropasos.

3.4.1 Computación de Micropasos No Determinista

Dado un componente M formado por los STDs M1,M2,...,Mn, sea H={H1,H2,...,Hm}el conjunto de transiciones habilitadas en un determinado micropaso, donde Hi≠∅es el conjunto de transiciones habilitadas del STD Mi (si hubiese algún STD sintransiciones habilitadas, no se tendría en cuenta). El algoritmo de la Figura 18computa el conjunto de configuraciones del componente M teniendo en cuentasituaciones de no determinismo.


58

Accion MicroPasos (Configuracion C,Conjunto_de_Habilitadas H)

N = H1; mientras ( N ! = ∅ ) hacer t = Pop (N); Push(t , A); /* T = Transiciones habilitadas de otro STD */ /* Si t ∈ Hi , T = Hi+1 */ T = Siguientes_Habilitadas(t); si ( T == ∅ ) entonces /* Ejecutar micropaso */ µP = µP + 1; C’ = Aplica_Regla_Avance (C,A); Añadir C’ a Global; C = C’; /* Continua generando micropasos */ MicroPasos (C,A); /* Actualizar A */ tr = Top(N); si ( tr ∈ Hj ) entonces Eliminar de A (|A|-j) transiciones; fin_si sino para cada transicion t ∈ T si ( t no esta en A || t no esta en N ) entonces Añadir t a N; fin_si fin_para fin_si fin_mientras

fin_accionFigura 18: Computación de micropasos (no determinista)

Partiendo del vector de transiciones habilitadas (H) y de una determinadaconfiguración del componente (C), el algoritmo calcula todas las posiblescombinaciones de transiciones que se pueden ejecutar en un micropaso, de modoque en cada combinación solamente aparezca una transición habilitada porproceso. Con cada una de ellas, se ejecuta la cascada de micropasos guardando encada generación las configuraciones relativas al micropaso. Debido a que seexploran todas las posibles transiciones habilitadas, el algoritmo contempla todaslas situaciones de no determinismo que se pueden producir dentro de unmicropaso.

El algoritmo utiliza una pila N para almacenar transiciones pendientes de explorary un vector A para guardar las transiciones seleccionadas que se ejecutarán en elmicropaso, por lo que se amolda a una exploración primero en profundidad sobreel conjunto de transiciones habilitadas en un micropaso.


59

3.4.2 Ejemplo

El esquema anterior garantiza que toda transición habilitada en un micropaso seráexplorada y por tanto ejecutada. Para ilustrarlo, se comprobará mediante elejemplo de la Figura 19, que muestra un componente formado por tres STDs A, By C, alguno de ellos con transiciones no deterministas.

C2A3A2

C1A1

STD CSTD A

t2: Y/Z

t4: Z t7: X/Z t8: Y/Zt3: X

t1: X/Y

B2

B1

STD B

t5: Y/Z t6: X

Figura 19: Ejemplo de transiciones no deterministas

En la Tabla 1 se representa la construcción de combinaciones de transicioneshabilitadas que se ejecutarán en el primer micropaso, suponiendo que laconfiguración actual (inicial) es <A1, B1, C1> y que se reciben los eventos X e Y.

Los rótulos de las columnas tienen la misma notación y significado que losdescritos en el algoritmo de la Figura 18. Inicialmente el conjunto de transicioneshabilitadas está formado por {H1,Hs,H3}, donde H ={t1,t2}, H2={t5} y H3={t7} secorresponden con los conjuntos de transiciones habilitadas en los STDs A, B y Crespectivamente, por lo que habría dos posibles construcciones de transicioneshabilitadas, una referente a la transición habilitada t1 y otra a la t2.

En la columna etiquetada por A se muestra la construcción de cada una de lascombinaciones de habilitadas, y en negrita se destaca la combinación final. Loscontenidos de las estructuras de datos que no se detallan en la tabla correspondena la ejecución de la cadena de micropasos con la combinación de habilitadas(recursividad en el algoritmo de la Figura 18), y no se consideran importantespara ilustrar el proceso general. Se puede comprobar con este ejemplo quesiempre se explorarán todas las combinaciones de transiciones habilitadas en unmicropaso, garantizando de este modo que se generarán todas las configuracionesdel componente.


60

C H N t Siguientes_Habilitadas(T) A<A1,B1,C1> t1, t2, t5, t7 t1, t2 t2 t5 t2

t1,t5 t5 t7 t2,t5

t1,t7 t7 ∅ t2,t5,t7

<A2,B2,C2> ................... ............ ..... ................... .................

................... .......... ..... ................... .................

<A1,B1,C1> t1, t2, t5, t7 t1 t1 t5 t1

t5 t5 t7 t1,t5

t7 t7 ∅ t1,t5,t7

<A2,B2,C2> ................... ........... ..... ................... .................

................... .......... .... ................... .................

Tabla 1: Exploración de transiciones no deterministas

3.5 Interfaz con Otros ComponentesLas técnicas anteriores basadas en la exploración del grafo de alcanzabilidad deun componente son básicamente técnicas no composicionales (no modulares)debido a que consideran que el grafo representa a un sistema cerrado, completo yque es creado en un solo paso: en base al conjunto de valores de eventos deentrada se crea el grafo de alcanzabilidad y no se tiene en cuenta el interfaz conotros componentes del sistema (este interfaz se considera igualmente comoeventos de entrada al componente).

Sin embargo, se debe tener en cuenta que en un entorno modular/composicionallos componentes deben ser considerados como sistemas abiertos,interrelacionados con otros componentes o subsistemas, de forma que larepresentación del grafo de alcanzabilidad para cada uno de los componentespueda ser independientemente derivado del sistema completo(composicionalidad). Este nuevo conjunto de técnicas, denominadas en generalAnálisis de Alcanzabilidad Composicional, surgió para remediar los problemasdel análisis clásico de alcanzabilidad, principalmente los relativos a la explosiónde estados, y está basado en técnicas de minimización intermedias realizadas encada uno de los componentes [Graf96] [Cheu96].

En este caso, el problema no es exactamente el mismo, ya que, como se comentópreviamente en este Capítulo, únicamente se utiliza el análisis de alcanzabilidadcomo una herramienta para la generación de configuraciones de un componente yno con fines de análisis o verificación directa de propiedades sobre elcomponente. La información obtenida del análisis de alcanzabilidad de uncomponente se utilizará para verificar otro componente del sistema. Sin embargo,sí es necesario tener en cuenta que el grafo del componente debe representarlocomo un sistema abierto, es decir en un entorno “composicional”.


61

3.5.1 Componentes Cerrados y Abiertos

En la Figura 20 se describe el esquema de un componente cerrado con unasemántica de ejecución basada en pasos.


Valores delEntorno

Macropaso

Figura 20: Componente cerrado

El sistema responde a los eventos externos (eventos del entorno) ejecutando unacadena de micropasos hasta alcanzar una situación de estabilidad. De acuerdo a lahipótesis de sincronismo que se adopata en la semántica, durante un macropasolos valores de las entradas externas que provienen del entorno no cambian, por loque no se reciben eventos del entorno (o dicho de otra forma, el sistema esinfinitamente más rápido que el entorno). Durante el macropaso, únicamente seproducen cambios en los estados del sistema y en los valores de los eventosinternos. El esquema se corresponde con la visión global que se tiene del sistemaconsiderado como un todo.

Análogamente, en la Figura 21 se muestra el esquema de ejecución de uncomponente abierto.


Valores delEntorno

Valores de eventos deotros componentes

Macropaso

Figura 21: Componente abierto


62

El componente reacciona ante la llegada de eventos externos y ejecuta su cadenade micropasos teniendo en cuenta la hipótesis de sincronismo, pero además encada uno de los micropasos se pueden recibir eventos procedentes de otroscomponentes del sistema. Esta consideración debe tenerse en cuenta, ya que encaso contrario estaríamos falseando la semántica del sistema completo.

3.5.2 Computación de Micropasos

De acuerdo a los aspectos comentados en la sección anterior y al modelo decomputación basado en Sistemas Reactivos Síncronos, los componentes a analizarse deben de considerar como componente abiertos.

Estos aspectos deben quedar recogidos en la generación de las configuraciones encada uno de los micropasos y es preciso, por tanto, modificar el algoritmo de laFigura 18, de forma que en cada uno de los micropasos los eventos de entrada alcomponente, y que son de salida de otro, tomen todos los valores posibles.

Sea S=[C1||C2] un sistema dividido en dos componentes C1 y C2 y sea F elconjunto de eventos internos de S que son a la vez de entrada de C1 y de salida deC2, F=I1∩O2. El algoritmo de generación de las configuraciones de micropasospara el componente C1 teniendo en cuenta el interfaz con C2, y con ligerasmodificaciones respecto al de la Figura 18 (remarcadas mediante un borde), semuestra en la Figura 22.


63

Accion MicroPasos (Configuracion C,Conjunto_de_Habilitadas H) es

N = H1; mientras ( N ! = ∅ ) hacer t = Pop (N); Push(t , A); /* T = Transiciones habilitadas de otro STD */ /* Si t ∈ Hi , T = Hi+1 */ T = Siguientes_Habilitadas(t); si ( T == ∅ ) entonces /* Ejecutar micropaso */ para cada combinacion de valores en F, F(I) µP = µP + 1; C’ = Aplica_Regla_Avance (C,A); I’ = F(I); Añadir C’ a Global; C = C’; /* Continua generando micropasos */ MicroPasos (C,A); /* Actualizar A */ tr = Top(N); si ( tr ∈ Hj ) entonces Eliminar de A (|A|-j)elementos; fin_si fin_para sino para cada transicion t ∈ T si ( t no esta en A || t no esta en N ) entonces Añadir t a N; fin_si fin_para fin_si fin_mientras

fin_accion

Figura 22: Computación de micropasos con interfaz de otro componente

Para la exploración de todas las posibles configuraciones del componente,teniendo en cuenta los eventos que proceden de otro componente, se generantodos las posibles combinaciones de valores de estos eventos (si los eventos seconsideran binarios, 2|F| combinaciones de valores posibles) en cada uno de losmicropasos. Nótese que, aunque estos eventos se reciban en un micropaso,habilitarán transiciones en el micropaso siguiente. Por ello, en la configuración deun micropaso se reflejan estos valores como eventos de entrada del componente(I’=F(I)) y se tomarán una vez ejecutadas las transiciones del micropaso actual,pasando a formar parte de los eventos de entrada en el siguiente micropaso.

3.5.3 Ejemplo

El proceso de generación de estas configuraciones se ilustra en la Figura 23,donde se muestra parte de una traza de ejecución correspondiente al componente


64

descrito en Figura 14 con el interfaz de entrada formado por el eventoFin_Operación recibido de otro componente.

....*** Ejecucion desde <Chequeando,Inicio>+++ Valores Entorno (MACROPASO)

Recibido Alto = 1;MICROPASO 1

<Chequeando,Inicio> -> <Iniciando,Inicio>Emite Nivel_Alto = 1*** Recibido Fin_Operacion = 1MICROPASO 2

<Iniciando,Inicio> -> <Chequeando,Cerrando>Emite Finalizar = 1*** Recibido Fin_Operación = 1MICROPASO 3

<Chequeando,Cerrando> -> <Chequeando,Cerrando>**Estable <Chequeando,Cerrando>***Alcanzable <Chequeando, Cerrando>

MICROPASO 2<Iniciando,Inicio> -> <Chequeando,Cerrando>Emite Finalizar = 1*** Recibido Fin_Operación = 0MICROPASO 3

<Chequeando,Cerrando> -> <Chequeando,Cerrando>***Estable <OFF,Cerrando>

MICROPASO 1<Chequeando,Inicio> -> <Iniciando,Inicio>Emite Nivel_Alto = 1*** Recibido Fin_Operacion = 0......

Figura 23: Ejemplo: Configuraciones con interfaz de otro componente

La traza de generación muestra los micropasos generados partiendo del estadoglobal del componente <Chequeando,Inicio> y considerando que se recibe delentorno el evento Alto. Como consecuencia de ello, el componente comienza laejecución de micropasos teniendo en cuenta que en cada uno de ellos se puedenrecibir eventos procedentes de otro componente, en este caso el eventoFin_Operación (señalados en negrita en la Figura 23). Por ello, más que formarseuna cadena de micropasos para un macropaso dado, se forman cadenas demicropasos a distintos niveles (micropasos a nivel 1, micropasos a nivel 2, etc.),cada uno correspondiente a cada uno de los valores de los eventos de interfaz conotro componente. Es decir, partiendo de un estado global de un componente y unacombinación de valores de entrada, existen varias cadenas de micropasos que sepueden formar.

Nótese la diferencia con el ejemplo de la Figura 15, donde se muestra una trazade generación de configuraciones para el mismo ejemplo, pero sin tener en cuentael interfaz con otro componente, es decir el componente es cerrado. En este caso,estos eventos de interfaz son tratados como eventos externos de entrada ysolamente toman valor al comienzo del macropaso, por lo que existe únicamenteuna cadena de micropasos (micropaso 1, micropaso 2, etc.), a no ser que seproduzcan situaciones de no determinismo.


65

3.5.4 Micropasos de Estabilización

Un micropaso de estabilización en un macropaso es un micropaso en el que no seejecuta ninguna transición, sino que su utilidad es servir de control sobre lafinalización del macropaso. Estos micropasos son necesarios cuando seconsideran los componentes abiertos, como veremos a continuación.

Con la introducción de los eventos de interfaz en la generación de configuracionesde un componente, la longitud de cada uno de las cadenas de micropasos para unmacropaso dado se verá incrementada al menos en un micropaso. Obsérvese en laFigura 23 el primero de los micropasos numerado como “3”. La ejecución de estemicropaso no va a producir ningún cambio significativo en la configuración delcomponente ya que no realiza ninguna transición en los STDs, ni recibe niproduce ningún tipo de evento. Sin embargo es necesario tenerlo en cuenta comomicropaso de estabilización (realmente ya esta formado un macropaso), debido aque en el micropaso precedente se puede haber recibido un evento de interfaz y esnecesario determinar si puede producir nuevas transiciones y/o eventos. La Figura24 muestra las modificaciones al esquema original de macro y micropasosteniendo en cuenta lo comentado anteriormente.

Valores delEnorno Micropasos

Estable Valores delEntorno

Valores de eventos deotros componentes

Macropaso Real

Micropaso deestabilizacion

Macropaso Modificado

Figura 24: Micropaso de estabilización

Este fenómeno un tanto extraño, pero necesario para determinar el fin de unmacropaso y asegurar por tanto la finalización del proceso, está recogido en elalgoritmo, ya que no es más que aplicar la regla de avance denominada “regla destuttering” en la Sección 3.2. Un tratamiento similar es descrito en [Chan99][Chan01], donde se determina estáticamente la máxima longitud de un macropasoa partir de la especificación del modelo, y se utiliza un contador de micropasospara establecer la condición de estabilidad y realizar optimizaciones en laverificación simbólica de Statecharts.


66

3.5.5 Problemas de No Terminación

Debido a la aparición de eventos procedentes de otros componentes del sistema,pueden producirse situaciones en las que la ejecución del componente no finaliza.En la Figura 25 se muestra un componente formado por un único STD que recibedel entorno el evento A y de otro componente del sistema el evento b.

S2

S1

A || bb

Figura 25: Componente que no finaliza

Partiendo de su estado inicial (S1) el componente recibe el evento A y procede conel primer micropaso ejecutando la transición de S1 a S2. Supóngase que recibetambién en ese micropaso el evento b procedente de otro componente. En elsegundo micropaso estará activa la transición de S2 a S1 y se ejecutará. Si entodos los micropasos se recibe b el componente estará infinitamente ejecutandoesa cadena de micropasos.

Esta situación es una consecuencia directa de la propia semántica de ejecuciónque adaptamos para los componentes, ya que la semántica RSML [Leve94] puedellegar a producir ciclos infinitos debido a que el sistema ejecuta una secuenciainfinita de micropasos (situación potencial de “livelock”). Esta situación puededetectarse estableciendo una profundidad máxima de micropasos. Si en laejecución de un macropaso se supera esta cota, el sistema podría estar ejecutandouna secuencia infinita de micropasos y por tanto la especificación no seríacorrecta. Esta limitación en la longitud del macropaso es lógica, ya que si elcomponente ejecuta muchos micropasos, o bien no está correctamenteespecificado, o la partición del sistema no es adecuada.

De igual forma, se podrían detectar estos ciclos infinitos utilizando uncomprobador de modelos que soportase la detección de ciclos de no progreso,asegurando que el componente ejecuta una secuencia infinita de macropasos[Tuya97a].

3.6 OptimizaciónDebido a la inclusión de transiciones no deterministas y de los eventos de interfaz,la generación del espacio global de configuraciones, tal y como es propuesta enlos apartados anteriores, puede originar para componentes de tamaño medio y altoproblemas con la explosión de estados.


67

3.6.1 Explosión de Configuraciones

Para ilustrar el problema, considérese un componente que recibe del entorno ochoeventos de entrada y cuatro eventos procedentes de otros componentes (eventos deinterfaz), y supóngase que el número medio de micropasos realizados en elsistema es de cuatro por cada macropaso y hay diez estados (globales) en elsistema. Considerando que todos los eventos recibidos son binarios y no existentransiciones no deterministas, los algoritmos anteriores deberían manejar elsiguiente espacio de estados:

� 256 (28) macropasos, uno por cada posible combinación de los eventos deentrada para cada estado alcanzable. En total, 2.560 macropasos.

� 16 (24) combinaciones posibles de eventos de interfaz en cada micropaso.

� 69.888 (164+163+162) micropasos en cada macropaso.

El número máximo de configuraciones calculadas son 2.560×6.988=178.913.280.Aunque este dato representa una cota máxima y no todas las configuracionesdeben ser almacenadas (aunque sí visitadas para asegurar una exploraciónexhaustiva), sino solamente aquellas diferentes entre sí, la cantidad deconfiguraciones obtenidas es una dato negativo en cuanto al tipo de componentesque puedan ser tratados en unos requisitos de tiempo y espacio razonables.

En la Figura 30 se ilustra gráficamente el efecto de la explosión de estados en lageneración de configuraciones para un estado alcanzable (por ejemplo, el inicial).Aunque formalmente la estructura generada sería la de grafo en vez de árbol comola mostrada (no se generan nuevas configuraciones, si previamente fueroncomputadas), se representa ésta para clarificar el concepto de explosión delespacio de estados. Las configuraciones correspondientes a los micropasos serepresentan mediante nodos en blanco y aquellas correspondientes a estadosalcanzables con nodos sombreados. Las fechas que parten del nodo inicialcorresponden a transiciones calculadas como consecuencia de las diferentescombinaciones de eventos del entorno. Las que parten de los nodos de losmicropasos reflejan la ejecución de transiciones como consecuencia de laaparición de eventos de interfaz. La profundidad del árbol representa el númeromedio de micropasos.


68

......

.. ...... ..

.. ......

.. ...... ..

Figura 26: Explosión de estados en la generación de configuraciones

En general, si bien la presencia de transiciones no deterministas obedece a uncriterio del analista en la especificación del sistema, y por tanto podríamodificarse la especificación de forma que fueran todas deterministas, los eventosde interfaz son un aspecto propio de la semántica con dos niveles de tiempo, y porello no se pueden suprimir.

3.6.2 Cortocircuito de Micropasos

Para evitar el efecto anterior en la generación de configuraciones en componentes,se propone la siguiente observación. Dado que la generación del espacio deconfiguraciones se realiza secuencialmente en anchura para cada estadoalcanzable (para cada combinación del entorno se ejecutan todas las posiblesejecuciones de micropasos), si una determinada configuración ya fue previamentecomputada, se cortocircuita a partir de ahí la generación de micropasoscorrespondiente a esa configuración.

Por ejemplo, considérese el componente mostrado en la Figura 27 que recibe delentorno los eventos E1 y E2 y de otro componente el evento f, y genera loseventos de salida S1, S2 y S3.

B2

B1

A2

A1

E1 / S1

E2 / b

b / S2

f / S3

Figura 27: Ejemplo: Cortocircuito de micropasos


69

Supóngase que se están calculando las configuraciones a partir del estadoalcanzable <A2,B1>. Para los valores del entorno E1=0 y E2=1 las secuenciasgeneradas serían:

<A2,B1> → <A1,B1> → <A1,B2> → <A1,B1> (para f=1)

<A2,B1> → <A1,B1> → <A1,B2> (para f=0)

Si se continua con la generación con otros valores del entorno, para lacombinación E1=1 y E2=1 las secuencias generadas serían exactamente lasmismas y no haría falta ni computarlas ni visitarlas. En el momento de generar laconfiguración correspondiente al primer micropaso, se observa que ésta ya fuecalculada, y a partir de ahí, se puede suspender la generación de configuraciones ycontinuar con otra combinación de valores del entorno.

Como se desprende del ejemplo, la decisión de cortocircuitar la generación de lacadena de micropasos se basa en la comparación de la configuración generadapara un micropaso, y las ya previamente computadas.

Dado que las configuraciones contienen bastante información y la compariciónpuede ser costosa, una forma más efectiva es la comparación entre las transicioneshabilitadas en un estado para un micropaso. Para ello se mantiene una tablaindexada por micropaso donde en cada registro se almacenan los conjuntos detransiciones habilitadas por micropaso. Así, cuando se calculan para un micropasolas transiciones habilitadas, éstas se comparan con las ya generadas, y si ya fueroncomputadas, no es necesario continuar con la cadena de micropasos.

En la Figura 28 se describe la pequeña modificación que sería necesario recogeren el algoritmo básico de la figura Figura 11 para que soportase la optimizacióncomentada, donde Generadas(C,n) referencia a las transiciones habilitadas yarecorridas en el micropaso n para la configuración C.

......H = Habilitadas (C)si H ∉ Generadas (C, n) ) entonces Añadir H a Generadas(C, n); Micropasos (C,H); ......sino...... /* Cortocircuito: No se continua con los micropasos (Fin del Macropaso) */fin_si.....

Figura 28: Cortocircuito en los micropasos

Sin embargo, esta solución, aún siendo efectiva en la mayor parte de los sistemas,puede plantear un problema cuando se aplica a modelos que contienen variablescuyos valores deben ser recordados a lo largo de toda la ejecución (por ejemplo,almacenes). En este caso, dado que se puede cortocircuitar la generación demicropasos en función de comparar conjuntos de transiciones habilitadas, podríasuceder que en uno de los micropasos cortocircuitados (no generados) sehabilitase una transición como consecuencia de la actualización de datos en otromicropaso previamente generado. Esto no sucedería en el caso de comparar


70

configuraciones, ya que los valores de los almacenes pertenecen a laconfiguración y en la comparación se detectaría el cambio de estado del almacén,por lo que la generación continuaría. En todo caso, cualquiera de las dos formasexpuestas reduce de manera significativa el tamaño del espacio deconfiguraciones y ofrece rendimientos muy aceptables para sistemas de tamañomedio-grande.

3.7 Comentarios y DiscusiónEn este Capítulo se muestra un conjunto de técnicas para la generación delconjunto de configuraciones del entorno de un sistema reactivo síncrono. El finúltimo, como se comenta varias veces a lo largo de esta tesis, es el de utilizarposteriormente las configuraciones generadas para crear abstracciones del entornoen un contexto de verificación modular.

Los algorimos para la generación del espacio de configuraciones están basados enla enumeración exhaustiva del conjunto de configuraciones (análisis dealcanzabilidad) y ampliados convenientemente para los propósitos perseguidos.Dado que, la semántica adoptada se basa en dos niveles de tiempo (macro ymicropasos), la generación del espacio de estados debe hacer visibles lasconfiguraciones en ambos modelos de tiempo, y por otra parte, el sistema debeconsiderarse abierto facilitando así la composicionalidad. El principal problemade este enfoque está en la explosión combinatoria del espacio de estados. Sinembargo, la visión del sistema es más intuitiva con la noción de paso (externos einternos), y la inclusión de eventos de interfaz permite tratar al componente deuna forma global con el resto del sistema, y por tanto con la semántica del sistemacompleto. La no inclusión de estos eventos no sería consecuente con la semánticapropuesta. Además, con la heurística basada en el cortocircuito de micropasos sepueden sortean los problemas anteriores en algunos tipos de sistemas.

En otras técnicas de análisis de sistemas síncronos (p.e. [Jaga95]) los eventos deinterfaz no son tratados como tales. Previamente a la verificación, se construye elgrafo global de procesos y se eliminan los micropasos. Aunque la representaciónde configuraciones en el grafo resultante es menor y más compacta que la aquípropuesta, la semántica del sistema completo no es consecuente con la semánticade cada uno de los componentes que lo forman.

Otras soluciones que existen para aminorar el problema de la explosión de estadosen la verificación de sistemas de estados finitos, y que podrían utilizarseigualmente para la generación de configuraciones, es la representación simbólicautilizando BDDs [Brya86] y los métodos de órden parcial [Gode93]. En [Chan01]se utiliza una representación simbólica basada en BDDs aplicado a sistemas conuna semántica similar a la aquí descrita, pero aplicado a la verificación desistemas completos más que a componentes individuales. Las reducciones basadasen orden parcial son menos aplicables a la semántica del modelo computacionaldescrito por la causalidad entre transiciones que éste implica.

71

Capítulo 4Generación Automática deRestriccionesEn este Capítulo se muestra cómo a partir del conjunto de configuraciones de uncomponente obtenido aplicando los algoritmos del Capítulo anterior, se puedenobtener automáticamente patrones de comportamiento en los eventos de interfazde salida del componente y los instantes en que se producen (micropasos). Elobjetivo es utilizar estos patrones de comportamiento como suposiciones paraverificar de forma más eficiente otro componente del sistema con el cual comparteeventos de interfaz.

La técnica presentada está basada en una adaptación del problema dedescubrimiento de reglas de asociación en Minería de Datos (Data Mining). Lasreglas de asociación obtenidas en un componente se utilizarán como restriccionesdel entorno para el componente a verificar.

En primer lugar se introduce el problema y se presenta la solución propuesta.Posteriormente, se introducen las reglas de asociación, junto con los principalesalgoritmos para su determinación, como una notación válida para la especificaciónde relaciones entre los eventos del entorno. Finalmente, se detallan lasmodificaciones al método general para su utilización como suposiciones orestricciones en la verificación del componente.

Generación Automática de Restricciones

73

4.1 IntroducciónUno de los aspectos menos tratados en los métodos de verificación modularbasados en suposición-compromiso es el relacionado con la generaciónautomática de restricciones del entorno, y que éstas puedan ser utilizadas comosuposiciones en las verificaciones locales de los componentes.

El objetivo de este Capítulo es abordar el problema anterior, como una alterntativaa la especificación manual, mediante el desarrollo de una técnica que permite laextracción de restricciones a partir del espacio de estados del entorno delcomponente, generado este último con los algoritmos descritos en el Capítulo 3.

En la Figura 29 se reproduce el esquema del proceso general que se presentó alinicio de la tesis (Figura 2, Capítulo 1), remarcando los procesos que seabordarán en este Capítulo.


Propiedades C2


ExtraerSuposiciones

X → Y

Y → AB

YZ → B

.....




Figura 29: Generación automática y codificación de suposiciones

El resto del Capítulo es cómo sigue. En primer lugar se presenta un ejemplointroductorio que compara las vertientes manual y automática en la especificaciónde suposiciones en la verificación de un componente y se detalla el procesogeneral propuesto. A continuación se introducen las reglas de asociación comouna notación adecuada para la especificación de relaciones entre los eventosprocedentes del entorno del componente, y se describen los algoritmosfundamentales para su cálculo. Posteriormente, y con el objetivo de mejorar laeficiencia del proceso de determinación de reglas y la verificación delcomponente, se detalla un conjunto de modificaciones que permitirán lautilización de las reglas obtenidas como restricciones o suposiciones en laverificación del componente.


74

4.1.1 Ejemplo Introductorio

Para ilustrar el proceso de determinación de suposiciones del entorno en unesquema de verificación modular, se utiliza el pequeño sistema formado por doscomponentes C1 y C2 descrito en la Figura 30. El componente C1 en función deciertos eventos procedentes del exterior (ALTO y BAJO) envía al componente C2dos órdenes, Comenzar y Finalizar que iniciarán/finalizarán ciertas operacionesde apertura/cierre de un dispositivo físico (eventos ABRIR y CERRAR).

PC2

PC1

Comenzar

CTRL_OK

Fin_OperacionBAJO

ALTO

CERRAR

ABRIRFinalizar

Figura 30: Ejemplo: Sistema a verificar modularmente

Supóngase que deseamos verificar sobre el modelo representado en la Figura 30la siguiente propiedad de seguridad: “Si se recibe el evento ALTO nunca se envíaal dispositivo externo la orden ABRIR”. Esta propiedad se puede expresar comosigue:

φ = (ALTO → ABRIR=0 )

Si se divide la propiedad anterior en dos propiedades φ1 y φ2 tal que φ1∧φ 2→φ,siendo φ1=(ALTO→ Finalizar) y φ2=(Finalizar→ABRIR=0) propiedades localesreferidas a cada uno de los componentes C1 y C2, respectivamente, se reduce elproblema de la verificación sobre el sistema global a un problema de verificaciónlocal sobre cada uno de los componentes. Aplicando las reglas de inferencia delteorema de composición de Lamport [Abad95], para verificar la propiedad φ2sobre el componente C2 es necesario realizar alguna suposición sobre elcomportamiento de su entorno (en este caso los eventos Finalizar y Comenzar).Lo mismo es aplicable para la verificación del componente C1 donde deberemosformular alguna suposición para el evento Fin_Operación.

Para simplificar, y debido a que el proceso de verificación local de laspropiedades sobre cada componente es totalmente análogo, únicamente nosreferiremos al proceso de determinación de suposiciones para el componente C2,es decir, establecer suposiciones para los eventos Comenzar y Finalizar. EnFigura 31 se muestra una especificación más detallada del componente C1formado por dos STDs “Check Inicio” y “Envío Ordenes”. El primero de ellosactúa como un mero reconocedor de los eventos de entrada y pone enfuncionamiento y parada el resto del sistema. El segundo de ellos envía las pre-órdenes de apertura/cierre en función de los eventos detectados por el STDanterior.


75

Chequeando

Iniciando

STD Check_Inicio

BAJO/Nivel_Bajo

ALTO/Nivel_Alto

Fin_Operacion

Cerrando Abriendo

Inicio

STD Envio Ordenes


Nivel_BajoComenza



Figura 31: Ejemplo: Especificación del componente C1

En general, la determinación de las suposiciones no es una tarea fácil. En muchasocasiones éstas se obtienen en base al conocimiento que tiene el ingeniero acercadel sistema, imponiendo un cierto orden en la llegada de eventos a un componente(“el evento a se recibe antes que el b”) y/o restricciones entre los valores de loseventos (“si se recibe a no se recibe b”). Otra forma de determinar lassuposiciones “a posteriori” consiste en ejecutar el verificador sin ningún tipo desuposición sobre el componente para una propiedad que es verdadera. Debido aque el espacio de estados que explora el verificador contiene más estados que losque realmente debería de contener considerando el componente junto con suentorno (los eventos de su entorno no están sujetos a ninguna restricción), podríasuceder que el verificador produjese un contraejemplo aún siendo la propiedadsiempre verdadera. En el ejemplo, que se recibiesen a la vez en el componente C2los eventos Comenzar y Finalizar, y debido al no determinismo en laespecificación, se enviase la orden de apertura del dispositivo, falseando así lapropiedad sobre el componente. Un análisis cuidadoso del contraejemploproporcionado por el verificador ayudaría a la determinación de las suposiciones.

Para el ejemplo, una suposición “razonable” para el componente C2 podría ser quelos eventos Comenzar y Finalizar no se reciban en el mismo instante de tiempo, odicho de otro modo, Comenzar=1→Finalizar=0 y Finalizar=1→Comenzar=0.Una vez verificada la propiedad sobre el componente C2, y siguiendo el teoremade composición de Lamport, es necesario verificar sobre C1 que las suposicionesson correctas. Teniendo en cuenta la descripción detallada del componente C1 dela Figura 31 y la semántica adoptada (Capítulo 3) se puede observar fácilmenteque la suposición es correcta, ya que ambos eventos (de salida para C1) nunca segenerarán en un mismo instante.

Sin embargo, se pueden establecer aún más suposiciones para el componente C2,menos obvias que las anteriores, pero en muchos casos más efectivas. Unconjunto interesante de ellas que permiten limitar el comportamiento del entorno,son aquellas que tienen en cuenta el instante concreto en el que se producen loseventos del entorno. Por ejemplo, se puede observar que los eventos Comenzar yFinalizar no se envían hasta el segundo micropaso en cualquier macropaso. Deacuerdo a la Figura 31 los eventos de salida Comenzar y Finalizar solamente segeneran cuando se producen los eventos internos Nivel_Bajo y Nivel_Alto


76

respectivamente, y éstos a su vez se producen como respuesta a los eventos delentorno BAJO y ALTO en el primer micropaso.

Aún para este sencillo ejemplo estas suposiciones pueden pasar desapercibidas, yaque implican no solamente un conocimiento profundo del sistema a verificar, sinotambién de la semántica de ejecución del modelo. Sin embargo, desde el punto devista de la ejecución del verificador, son muy efectivas ya que limitan el entornodel componente a verificar, y por tanto, el tamaño del espacio de estadosproduciendo un mayor rendimiento del verificador.

Por tanto, la obtención de forma automática de suposiciones no solamente permitedescubrir comportamientos del entorno no detectados manualmente, sino tambiéndichas suposiciones mejorarán el rendimiento del verificador, debido a quepermiten limitar el número de variables y estados (espacio de estados) que debemanejar el comprobador de modelos.

4.1.2 Descomposición del Problema

En general, el sistema objeto de estudio se representará por medio de un modelocompuesto por Sistemas Reactivos Síncronos (Capítulo 3) intercomunicados:

S = [C1 || C2 || ...|| Cn]

donde S es el modelo del sistema1 y C1, C2, ..., Cn son Sistemas ReactivosSíncronos. En el contexto de verificación modular, denominaremos a cada uno delos Sistemas Reactivo Síncronos anteriores, componentes. Sin pérdida degeneralidad y para simplificar la notación, se considerará que el sistema estáúnicamente constituido por dos componentes, C1 y C2.

En este contexto, y de acuerdo al esquema presentado al inicio de este Capítulo, elobjetivo es obtener las restricciones o suposiciones para el componente C2 a partirde las configuraciones computadas previamente para su entorno, es decir elconjunto Global(C1). El proceso de determinación de restricciones para elcomponente C2 se describe en los siguientes puntos:

� Las suposiciones o restricciones para el componente C2 estarán referidas a suseventos de interfaz de entrada (eventos de salida de C1, que también son deentrada para C2) y al instante en que se producen (variable contador demicropaso, µP). Sin embargo, en el conjunto Global(C1) cada configuracióncontiene información no solamente de los eventos de interfaz de C2, sinotambién del resto de eventos (de entrada, de salida, internos, etc.). Por tanto,un primer paso será filtrar en cada configuración de Global(C1) únicamente lainformación sobre los valores de las variables de interfaz de C2 y del contadorde micropasos.

� A partir del conjunto anterior de configuraciones “filtradas”, el objetivo esencontrar relaciones entre los valores de los eventos de las variables deinterfaz de entrada C2 y de los instantes en que se producen, de forma que

1 De acuerdo al formalismo utilizado para representar modelos SA/RT, el modelo S también es unSistema Reactivo Síncrono


77

expliquen patrones de comportamiento de dichas variables. Dicho de otraforma, el objetivo es encontrar reglas de asociación entre las variables deinterfaz de entrada y el contador de micropasos. Denominaremos a cada reglaobtenida restricción.

� Cada una de las restricciones anteriores se utilizará como una suposición en laverificación del componente C2, y se suministrarán conjuntamente con elcomponente para su verificación con un comprobador de modelos. Por tanto,es necesario proporcionar un mecanismo de traducción o codificación dedichas restricciones al lenguaje aceptado por el comprobador de modelos.

Más formalmente, sea E=O1∩I2 el conjunto de eventos de interfaz delcomponente C2. El conjunto de restricciones R2 para dicho componente sedeterminará conforme al siguiente algoritmo:

Entrada: Conjunto de configuraciones Global(C1) y Conjunto de Eventos ESalida: Conjunto de restricciones R2 para el componente C2

para cada configuracion Conf ∈ Global(C1)Conf’ = Conf ↑ (E ∪ {µP}) /*Filtrado de eventos*/Insertar Conf’ en Global’(C1)

fin_paraR2 = Extraer_Restricciones( Global’(C1) ) /* Reglas de asociación entre eventos*/

Figura 32: Algoritmo para generación de restricciones

El bucle del algoritmo anterior realiza el filtrado de los eventos que no pertenecena la interfaz de entrada del componente C2, mediante el operador de proyección ↑ ,que debe ser entendido como el “borrado” de los elementos de configuración queno se refieren a los eventos en E∪ {µP}. Sobre el conjunto obtenido de laproyección (Global’(C1)), se aplicarán los algoritmos de extracción derestricciones basados en reglas de asociación que se comentarán en las próximassecciones.

4.2 Introducción a las Reglas de AsociaciónLas técnicas conocidas en general como Minería de Datos [Agra93a] [Hols94][Chen96], o también Descubrimiento de Conocimiento en Bases de Datos[Piat91b] [Han92], surgen como una necesidad para aumentar la calidad de lasdecisiones tomadas en las organizaciones sobre datos almacenados en grandesbases de datos [Ston93]. El problema de obtener reglas de asociación entreatributos en un conjunto de transacciones o base de datos es uno de los campos deinvestigación y desarrollo más activos dentro de la Minería de Datos, yoriginariamente fue propuesto como una forma de obtener información acerca delos patrones de comportamiento de clientes en la compra de determinadosproductos (atributos); es decir, cómo la presencia de un producto en unatransacción o compra, afecta a la presencia de otro producto diferente.


78

A continuación se formula brevemente el problema y se presentan técnicasrelacionadas.

4.2.1 Formulación Básica

El problema conocido como descubrimiento de reglas de asociación entreatributos en una base de datos (en general, conjunto de transacciones) fueintroducido por primera vez en [Agra93b] e informalmente consiste en algoritmosy técnicas para responder a la pregunta “¿qué artículos se compran juntos en unatransacción?”.

Más específicamente, el problema se puede formular como sigue. Dado unconjunto de transacciones donde cada transacción es un conjunto de atributos, unaregla de asociación es una expresión de la forma X→Y, donde X e Y sonconjuntos de atributos. Intuitivamente, la implicación de una regla de asociaciónindica que la presencia de un conjunto de atributos en X, también indica laposibilidad del conjunto de atributos en Y. Para establecer la “fuerza” de unaregla, se introducen los conceptos de soporte mínimo y confianza mínima. Unejemplo típico de una regla de asociación es el siguiente: “el 50% de los clientesque compran leche también compran mantequilla; el 15% compran ambascosas”. En esta regla, el porcentaje 50% representa el factor de confianza y 15%el soporte de la regla.

Con esta base, el problema de descubrimiento de reglas de asociación se reduce aencontrar en el conjunto de transacciones, asociaciones entre sus atributos quesatisfagan un soporte mínimo (minsupport) y un factor de confianza mínimo(minconf) especificados por el usuario.

Este problema se puede descomponer en los subproblemas siguientes:

� Generar todas las posibles combinaciones de conjuntos de atributos(denominados itemsets) que tengan soporte por encima de minsupport. Cadauna de estas combinaciones se denominan large itemset.

� Usar los large itemset para generar reglas de asociación. La idea general esque si ABCD y AB son large itemtsets, entonces se genera la regla AB→CD, si(soporte(ABCD) / soporte(AB)) ≥ minconf.

El primero de ellos es el proceso que más recursos consume, ya que en general losalgoritmos para contabilizar el soporte de los diferentes conjuntos de atributos(large itemsets) realizan varias pasadas sobre el conjunto de transacciones. En laprimera pasada se contabiliza el soporte de los atributos individuales y sedetermina cuales de ellos tienen soporte mínimo. En siguientes pasadas, seutilizan como semilla los obtenidos en exploraciones anteriores generando nuevoselementos. El proceso continua hasta que no se pueden obtener más. Una vezdeterminados los large itemsets, el segundo subproblema es directo.

4.2.2 Otras Técnicas

En general, el descubrimiento de reglas a partir de un conjunto de datos es un áreade investigación muy activa en el campo del aprendizaje automático.


79

En [Piat91b], los algoritmos de búsqueda de reglas se tipifican en dos: aquellosque descubren reglas cuantitativas y aquellos que descubren leyes cualitativas.

El propósito de los primeros es el de automatizar el descubrimiento de leyes orelaciones numéricas que se pueden encontrar normalmente en datos científicos, yse utiliza conocimiento del dominio de aplicación para aproximar y guiar laobtención de las relaciones más apropiadas entre las variables.

Las técnicas de descubrimiento de reglas cualitativas utilizan poco o ningún tipode conocimiento del dominio, y son en principio más aplicables a las bases dedatos, ya que éstas reflejan muchos patrones que pueden coexistir. Entre estasúltimas se encuentran las técnicas de inducción de reglas de clasificación[BreiS84] [Quin93], descubrimiento de reglas causales [Coop92], dependenciasfuncionales [Mann87], etc. Un algoritmo denominado KID3 se presenta en[Piat91a] y puede ser utilizado para descubrir reglas de asociación. Este algoritmorealiza tantas pasadas sobre el conjunto de transacciones como número decombinaciones de atributos existan en el antecedente de la regla, lo que puedellegar a producir un gran consumo de recursos de entrada/salida.

Durante los últimos años en la comunidad científica se ha producido un interéscreciente en el estudio y aplicación de técnicas de Inteligencia Artificial y Apoyoa la Decisión en problemas habituales de la Ingeniería del Software. Muchas deellas utilizan técnicas metaheurísticas como Algoritmos Genéticos [Holl75],Búsqueda Tabú [Glov93] y otras, aplicadas principalmente a la generación decasos de prueba [Parg99], y a la estimación de costes de proyectos software[Dola00] [Dola01]. En [Clar03] se presenta una introducción a este tipo detécnicas aplicadas a la Ingeniería del Software. Más cercano al tema de esta tesis,pero no por ello directamente aplicable, es el trabajo reciente de Godefroid yKhurshid [Gode02], donde aplican algoritmos genéticos a la exploración delespacio de estados de sistemas reactivos para la verificación de interbloqueos yviolación de aserciones.

4.2.3 Comentarios

En el contexto de esta tesis, se utilizarán las reglas de asociación como una formaadecuada para representar las restricciones del entorno en la verificación de uncomponente. Dada la definición previa en la Sección 4.2, permitirán obtener, conlas modificaciones que se detallarán en las secciones siguientes, relaciones entrelos eventos del entorno en un componente.

Aunque, en principio, algunas de las técnicas de aprendizaje automático (entreotras, las comentadas en la Sección anterior) podrían ser adecuadas para resolverel mismo problema, las reglas de asociación presentan para el autor de esta tesisun marco lo suficientemente formal, una interpretación sencilla, tanto a nivelsemántico como de descripción de los algoritmos utilizados, y un gran desarrolloen investigación y aplicación que las hacen adecuadas para resolver los objetivosinicialmente planteados.

Queda más allá de los objetivos de esta tesis discutir, comparar y analizar losdiferentes métodos y técnicas existentes en el descubrimiento de reglas, pero nopor ello se puede obviar el interés de estos análisis, que en todo caso se pueden


80

plantear como trabajos futuros. Como muestra del interés creciente en lacomunidad científica por la interrelación entre el aprendizaje automático yverificación, consultar [LFV02].

4.3 Algoritmos de Cálculo de Reglas de AsociaciónEn esta sección se describen los algoritmos básicos utilizados en la minería dereglas de asociación a partir de un conjunto de datos, tal y como fueron propuestosen los trabajos originales de Agrawal et. al.[Agra93b] [Agra94]. El marco formalse presentará utilizando la notación detallada en [Agra93b], y los algoritmos seránlos descritos en [Agra94]. En ambos casos, los atributos del conjunto detransacciones se consideran binarios, es decir solamente tomarán los valores 0 y 1.Una revisión y análisis actual de otros algoritmos y técnicas para obtener reglas deasociación se puede encontrar en [Agga98a] y [Hipp00].

4.3.1 Definición

Sea I={i1, i2,...,im} un conjunto de atributos binarios denominados items, y sea Tuna base de datos de transacciones, donde cada transacción t está representada porun vector binario tal que t[k]=1, si en la transacción aparece el item ik, y t[k]=0en otro caso.

Una regla de asociación es una condición de la forma X→Y donde X⊆ I, Y⊆ I,X∩Y=∅ son conjuntos de items. Intuitivamente, la regla anterior indica que lapresencia del conjunto de items X también indica la posibilidad de presencia delos items en Y. El soporte de una regla X→Y es la fracción de transacciones de Tque contienen la unión de items en el antecedente y el consecuente de la regla. Laconfianza de una regla es la fracción de transacciones que conteniendo a Xtambién contiene a Y. Mientras la confianza es una medida de la “fuerza” o“potencia” de la regla, el soporte solamente tiene significado estadístico.

En este contexto, el problema de encontrar las reglas de asociación en un conjuntode transacciones se puede descomponer en los dos subproblemas siguientes:

� Generar todas las combinaciones de items que tengan soporte por encima deumbral dado por el usuario, denominado minsupport. Cada una de lascombinaciones de items que cumple lo anterior se denomina large itemsets.

� Para un large itemset dado L={i1,i2,...,ik}, generar al menos k reglas de laforma (L-{ir})→{ir} para cada r∈ {1..k}. De estas reglas únicamente interesanaquellas que tienen una confianza por encima del valor umbral de confianzadenominado minconf.

De los dos subproblemas anteriores, el primero de ellos es el más recursosconsume y que más investigación ha originado, ya que son necesarias variaspasadas sobre el conjunto de transacciones para determinar los large itemsets. Enuna primera pasada se computa el soporte de los items individuales y se determinacuales tienen soporte mínimo. En cada una de las siguientes iteraciones, secomienza con una semilla formada por los items obtenidos en la pasada anterior yse utilizan para generar nuevos itemsets potenciales (itemsets candidatos). Al


81

mismo tiempo, se cuentan los soportes actuales de los itemsets candidatos. Alfinal de la iteración, se determina cuales de los items candidatos son large itemsets(soporte por encima de minsupport) y pasan a formar parte de la semilla para lasiguiente pasada. Una vez determinados, el segundo subproblema tiene unasolución casi trivial.

En las siguientes secciones se muestran los algoritmos que abordan los problemasanteriores.

4.3.2 Determinación de Itemsets. Algoritmo Apriori

Aunque en el trabajo pionero sobre reglas de asociación [Agra93b] se presenta unalgoritmo para determinar los large itemsets (aunque no para la generación dereglas), aquí describiremos uno posterior y más eficiente, conocido con el nombrede Apriori [Agra94]. Dicho algoritmo tiene mucha influencia en trabajosposteriores sobre reglas de asociación, ya que prácticamente todas las mejoras,extensiones y generalizaciones lo toman como base.

El fundamento de este algoritmo estriba en una interesante propiedad de cierre delsoporte de un itemset: todos los subconjuntos de un large itemset también sonlarge itemset. Así, si algún (k-1) subconjunto de un itemset I∈ Ck no pertenece aLk-1, entonces el itemset no se considera en siguientes iteraciones, y por tanto, noes necesario contabilizar su soporte. Esta observación permite obtener unalgoritmo mucho más rápido que el propuesto en [Agra93b], ya que evitarecorridos redundantes sobre el conjunto de transacciones.

En la Figura 33 se muestra el esquema general del algoritmo Apriori. Un k-itemset es un conjunto formado por k items. El conjunto Lk hace referencia alconjunto de large k-itemsets (itemsets con k items con soporte superior aminsupport). Ck hace referencia al conjunto de k-itemsets candidatos. Loselementos de ambos conjuntos tienen dos campos: el itemset propiamente dicho yun contador de su soporte.

L1 = {large 1-itemsets};para ( k =2 ; Lk-1 ≠ ∅ ; k++ )

Ck = Genera_Candidatos (Lk-1);para cada transicion t de T hacer

Ct = SubConjunto(Ck,t); // Candidatos contenidos en tpara cada candididato c de Ct hacer

c.contador_soporte++;fin_para

fin_paraLk = {c ∈ Ck / c.contador_soporte ≥ minsupport}

fin_paraSalida = ∪ k Lk;

Figura 33: Algoritmo Apriori

La primera pasada del algoritmo contabiliza la ocurrencia de items para obtenerlos large 1-itemsets. Una k pasada posterior consta de dos fases. En la primera, los


82

large itemsets Lk-1 de la pasada previa se utilizan para generar los itemsetscandidatos Ck usando la función Genera_Candidatos que se describe acontinuación. En la segunda fase, y más crítica en cuanto a consumo de recursos,se vuelve a recorrer el conjunto de transacciones T y se determina el soporte delos candidatos en Ck utilizando la función SubConjunto, que implementa unaestructura propia muy eficiente denominada hashtree, de forma que se puedanbuscar los candidatos en cada transacción de una forma rápida (para más detallesver [Agra94]).

En la Figura 34 se especifica el algoritmo Genera_Candidatos referenciado en elalgoritmo Apriori. Toma como argumento el conjunto Lk-1 de todos los large (k-1)-itemsets y devuelve un superconjunto de los conjuntos de todos los k-itemsetscandidatos.

1) Ck = Join (Lk-1, Lk-1)2) para cada itemset c ∈ Ck hacer

para cada (k-1)-subconjunto s de c hacersi ( s ∉ Lk-1 ) entonces

eliminar c de Ckfin_si

fin_parafin_para

Figura 34: Algoritmo para generación de candidatos

En una primera fase se juntan y mezclan los (k-1)-subconjuntos en Lk-1produciendo un superconjunto de k-itemsets candidatos. Posteriormente, seeliminan de él los itemsets que tengan algún (k-1) subconjunto que no esté en Lk-1.Por ejemplo, supóngase que L3 está formado por {{1,2},{1,3},{2,3},{2,4}}.Después de la primera fase, C4 estará formado por {{1,2,3},{2,3,4}}. La segundafase eliminaría el subconjunto {2,3,4}, porque {3,4} no está en L3.

4.3.3 Generación de Reglas

El proceso de generación de las reglas a partir del conjunto de large itemsets esbastante intuitivo. Para todo large itemset l, el proceso se basa en encontrar todoslos subconjuntos a no vacios de l, y generar la regla a→(l-a), si la fracción entreel soporte de l y el soporte de a es al menos minconf.Este proceso puede ser mejorado teniendo en cuenta la siguiente observación. Siun subconjunto a de un large itemset l no genera una regla, no es necesarioconsiderar los subconjuntos de a, ya que tampoco podrán formar la regla debido aque no tienen suficiente confianza. Es decir, si no se puede formar la regla a→(l-a), tampoco se pueden formar las reglas b→(l-b), para cualquier b⊂ a.

De forma similar, también se puede escribir que, si se puede formar una regla (l-c)→c, también se pueden formar todas las reglas de la forma (l-d)→d, donde d esun subconjunto no vacío de c. Por ejemplo, si se tiene una regla AB→XY, tambiénse pueden formar las reglas ABX→Y y ABY→X.


83

Todas estas observaciones se resumen en el algoritmo especificado en la Figura35.

para cada large k-itemset lk con k≥2 hacerH1 = {consecuentes de reglas de lk con un item en el consecuente}Genera_Reglas (lk, H1);

fin_para

accion Genera_Reglas (lk: large k-itemset ; Hm: conjunto de consecuentes conm-items)

si (k > m+1) entoncesHm+1 = Genera_Candidatos (Hm);para cada hm+1 ∈ Hm+1 hacer

conf = soporte(lk)/soporte(lk - hm+1);si (conf ≥ minconf) entonces

regla (lk – hm+1) → hm+1;sino

eliminar hm+1 de Hm+1;fin_si

fin_paraGenera_Reglas (lk,Hm+1);

fin_sifin_accion

Figura 35: Algoritmo para generación de reglas de asociación

A partir de un large itemset, en primer lugar se generan las reglas con un solo itemen el consecuente. Después, se utilizan los consecuentes de estas reglas y elprocedimiento de generación de itemsets candidatos en el algoritmo Apriori(Figura 34) para generar todos los posibles consecuentes con dos items quepueden aparecer en la regla generada desde el itemset, y así sucesivamente, hastaque se hayan comprobado todos los posibles consecuentes en la regla.

4.4 Utilización de Reglas de Asociación comoRestricciones del Entorno

Tomando como base los algoritmos de descubrimiento y generación de reglas deasociación de la sección anterior, y el proceso de generación del espacio deconfiguraciones del entorno descrito en el Capítulo 3, se mostrarán lasmodificaciones y adaptaciones de los algoritmos relativos a reglas de asociación,con el objetivo de que éstas se pueden utilizar como restricciones del entorno en laverificación de un componente.

A continuación se presentan algunas definiciones, y posteriormente se describe elproceso general.

4.4.1 Restricciones del Entorno

Siguiendo el mismo marco propuesto durante el desarrollo de esta tesis, sea [E||C]un sistema formado por el componente C a verificar y E el componente que


84

representa al entorno del componente C. Sea I el conjunto de eventos de interfazde entrada del componente C.

Una restricción del entorno o suposición para el componente C es unaimplicación de la forma X→Y donde X⊂ (I∪ {µP}), Y⊂ (I∪ {µP}), X∩Y=∅ . Esdecir, las restricciones del entorno para un componente hacen referencia a loseventos de interfaz de entrada y el contador de micropasos. Por ejemplo, larestricción del entorno {µP=1}→{Alto=0,Bajo=1} indicaría que en el micropaso 1el evento Alto no se recibe, pero sí el evento Bajo.

En este contexto, el problema de la generación automática de restricciones delentorno para el componente C, es un problema que se puede reformular en base aldescubrimiento de reglas de asociación, considerando como conjunto detransacciones el conjunto Global(E) de todas las configuraciones del entorno.

El único problema en la anterior formulación estriba en el dominio de los datosdel contador de micropasos (µP). En general, el dominio de esta variable es el delos números naturales, es decir, información de tipo cuantitativa, por lo que enprincipio, la variable no podría formar parte de las reglas generadas, debido a quelos algoritmos presentados en la Sección 4.3 están formulados para reglas dondelos atributos son booleanos. En [Srik96] se muestra cómo adaptar el problema dereglas de asociación “booleanas” o cualitativas a reglas de asociacióncuantitativas, o que involucran atributos que no son binarios. Básicamente, en vezde tener solamente atributo cuantitativo, éste se subdivide en tantos atributoscomo valores tenga el atributo, de modo que estos nuevos items son ya booleanos.Por ejemplo, si tenemos el atributo <µP=2>, sería un “1” si µP toma el valor 2 enla configuración original, y un “0” en otro caso. Esta solución es factible cuandoel conjunto de valores que puede tomar un atributo es pequeño. Para atributos quepueden tomar muchos valores, en vez de subdividir el atributo original en tantosatributos como valores, se subdivide en intervalo o rango de valores, de forma quecada intervalo se considera como un item binario.

Dado que la longitud de los macropasos (número de micropasos) en lasconfiguraciones de un componente no será nunca muy elevada (aunque dependedel diseño del sistema y de la partición en componentes), se adopta la primera delas soluciones propuestas en el párrafo anterior, es decir se considera a cada par<µP=n> como un item binario, donde n es un valor del contador de micropaso enun macropaso.

4.4.2 Representación de Restricciones del Entorno

Debido a que las restricciones o suposiciones del entorno, tal y como se entiendenen un marco de verificación modular hacen referencia únicamente a los eventos deinterfaz de entrada en el componente C y al contador de micropasos, se utilizacomo conjunto de transacciones el conjunto Global’(E), obtenido mediante laproyección de éste sobre el conjunto I∪ {µP}, es decir:

Global’(E)=Global(E)↑ (I∪ {µP})

donde ↑ es el operador de proyección comentado al inicio de este Capítulo.


85

Para simplificar la notación y acercar el concepto de una configuración en uncomponente al de transacción ó registro, de forma que se puedan manejar por losalgoritmos de reglas de asociación, se considera que los elementos de Global’(E)son tuplas de la forma <µP,i1,i2,...,in>, ii∈ I. Es decir, formadas por los atributoscontador de micropaso y cada uno de los eventos de interfaz de entrada delcomponente C. Por ejemplo, si Alto y Bajo son los eventos de interfaz delcomponente C por ese orden, la tupla <1,1,0> indicaría que el entorno E generauna configuración en el micropaso 1, donde el evento Alto toma valor 1 y elevento Bajo valor 0, o lo que es lo mismo en un micropaso 1 el componente delentorno E genera el evento de Alto.

Simbólicamente, también se puede considerar las restricciones como reglas deltipo “SI <condicion> ENTONCES <valores_eventos>”, donde <condicion>representa una conjunción lógica de valores de elemento en <µP,i1,i2,...,in>, ii∈ I y<valores_eventos> representa a un conjunto de valores de los elementos en I.

Tal y como se verá en el Capítulo 6 relativo a la evaluación de casos prácticos,esta forma de representación de las restricciones permitirá una traducción casidirecta al lenguaje soportado por el comprobador de modelos, debido a que sepueden codificar mediante asertos interpretables por el verificador.

4.4.3 Proceso de Determinación de Restricciones delEntorno

Las restricciones del entorno para el componente C son reglas de asociación entreeventos y el instante (micropaso) en el que ocurren. Una primera aproximaciónpara obtener dichas reglas relativas al entorno del componente se muestra acontinuación:

� Determinar en Global’(E) el conjunto de eventos (evensets) con soporte mayorque minsupport. Asociado a cada eventset existe un contador para almacenarsu soporte. Es decir, determinar los large eventsets. Para ello se puede utilizarel algoritmo Apriori descrito en la Sección 4.3, Figura 33.

� Usar los large eventsets del paso anterior para generar reglas de asociacióncon una confianza mayor que minconf. Estas reglas son restricciones delentorno para el componente C obtenidas del entorno E. Las reglas se puedengenerar utilizando el algoritmo de la Figura 35.

Del proceso anterior, se deduce que, una vez que se ha generado el espacio deconfiguraciones del entorno del componente, se pueden utilizar los algoritmos dereglas de asociación sobre dicho espacio para generar restricciones, dados unosfactores de confianza y soporte mínimos especificados por el usuario.

Este proceso generalizado se representa en la Figura 36 que se consideraautoexplicativa.


86

Configuraciones del Entorno delcomponente C (Global'(E))

µP=1 e1=0 e2=0 e3=0

µP=2 e1=0 e2=0 e3=1

µP=3 e1=1 e2=1 e3=1

µP=1 e1=0 e2=0 e3=0

.....

Algoritmos para Generaciónde Reglas de Asociación

minsupportminconf

Componente C aVerificar

Restricciones del Entorno

µP=1 → (e1=0 e2=1 e3=0)

µP=2 → e3=0

.....

Comprobador de Modelos

Figura 36: Utilización de reglas de asociación como restricciones del entorno

Sin embargo, el proceso anterior no es totalmente automático, ya que, al menos, esnecesaria la intervención del analista para especificar los umbrales de soporte yconfianza. En los siguientes apartados se discutirán y presentarán modificacionesa este esquema básico con el objetivo fundamental de aumentar la automatizaciónen el proceso.

4.5 Modificaciones al Proceso GeneralA continuación se presentan algunas modificaciones que se realizarán al procesogeneral de determinación de restricciones usando reglas de asociación descrito enla sección anterior.

4.5.1 Eliminación de minsupport y minconf

Los umbrales de confianza (minconf) y soporte (minsupport) son valoresindicados por el usuario previamente al proceso de generación de reglas, y encierto modo indican una “calidad” en las reglas que se generan. Otra utilidad deestos umbrales es la disminuir el número de reglas obtenidas. Es decir, obtenerreglas significativas y a la vez interesantes para el usuario. En la mayoría de loscasos esta medida o cuantificación de la “utilidad” o “interés” dependen de laaplicación, y en general se necesita la intervención del usuario para que el proceso


87

de generación de reglas tenga éxito. Trabajos que cuantifican el interés de unaregla se pueden encontrar en [Srik96] y [Klem94].

Sin embargo, el objetivo que se aborda aquí es diferente. Las restricciones delentorno que se generen utilizando reglas de asociación deben explicarcomportamientos de eventos que estén siempre presentes en el conjunto deconfiguraciones del entorno. Por ejemplo, supóngase que la reglaAlto=1→Bajo=0 tiene un factor de confianza del 90%, o lo que es lo mismo, en el90% de las configuraciones donde se genera el evento Alto no se genera el eventoBajo. Sin embargo, existe un 10% de configuraciones en el componente delentorno donde puede suceder, por ejemplo, que se generen ambos eventos, Alto yBajo al mismo tiempo (Alto=1→Bajo=1). Si incluyésemos la regla comorestricción en la verificación de un componente estaríamos falseando elcomportamiento del entorno, y la verificación del componente podría darresultados totalmente erróneos. En consecuencia, aún teniendo la regla unaconfianza alta, no serviría como restricción ya que se estaría limitando elcomportamiento del entorno con suposiciones que no son reales.

Por tanto, se debe definir el concepto de restricción del entorno como sigue: unarestricción del entorno es una regla de asociación cuyo factor de confianza debeser siempre del 100%. De este modo, las restricciones que se obtengan abstraencomportamientos del entorno que están siempre presenten en el entorno.

Igualmente, se puede hacer el mismo razonamiento para el soporte mínimo.Siguiendo con el ejemplo anterior, supóngase que la regla Alto=1→Bajo=0 segeneró a partir de una configuración del componente para un tamaño del espaciode estados de 100 configuraciones, es decir su soporte es del 1%. Si seespecificase como soporte mínimo uno superior al 1%, la regla anterior no sedescubriría. Sin embargo, esa regla, aún teniendo un soporte muy pequeño, puedeproducir en el componente a verificar una reducción importante en los eventosque tiene que tratar y colateralmente mejorar el rendimiento del verificador.

Resumiendo, aún cuando las restricciones obtenidas sean a partir de una únicaconfiguración del entorno, son importantes y deben ser tenidas en cuenta. En estesentido y ampliando la definición anterior, una restricción del entorno es una reglade asociación cuyo factor de confianza debe ser siempre del 100%, y donde elsoporte mínimo no se considera.

Estas consideraciones realizadas sobre los umbrales de confianza y soportepermitirán optimizar algunos de los procedimientos utilizados en la formulaciónoriginal del problema de obtención de restricciones del entorno.

4.5.2 Obtención de large eventsets

La aplicación inmediata de los algoritmos básicos de reglas de asociación paraobtener restricciones del entorno, se basa en un primer punto en obtener lo que sedenomina large eventsets, cuyo significado es básicamente el mismo que largeitemsets, es decir conjuntos de eventos que tienen un soporte por encima de undeterminado umbral mínimo (minsupport).


88

Si embargo, en la sección anterior se mostró que desde el punto de vista de lageneración de restricciones, dicho valor umbral no tiene ningún significado, por loque todos los eventsets son large eventsets. Por tanto, una consecuencia directa delo anterior, permite deducir que todos los conjuntos de eventos que aparecen enuna determinada configuración son siempre large eventsets. De este modo, en ladeterminación de los large eventsets se evita recorrer varias veces el conjunto deconfiguraciones del componente para calcular previamente el conjunto de eventoscandidatos (como sucede en la formulación original del algoritmo Apriori, Figura33).

Otra consecuencia importante es la siguiente: la contabilización del soporte decada (sub)conjunto de eventos (eventsets) puede realizarse a la vez que lacomputación del conjunto de configuraciones. Es decir, cada vez que se generauna nueva configuración de acuerdo a los algoritmos de computación de espaciosde estados (Sección 3.3), se incrementa un contador asociado en cada uno de losposibles subconjuntos de eventos que aparecen en la configuración. De estaforma, en una sola pasada y al mismo tiempo (“on the fly”) obtenemos loseventsets y sus soportes.

Estas nuevas modificaciones se incluyen en el algoritmo de la Figura 37.

Entrada: Una configuración Cj∈ Global(E) obtenida a partir de alguna Ci∈ Global(E)Salida: Conjunto Hj de eventset en Cj

1) Hj = SubConjuntos(Cj);2) para cada hk ∈ Hj hacer

hk.soporte++;fin_para

Figura 37: Algoritmo para la computación de eventsets

En 1) se genera el superconjunto de todos los posibles subconjuntos de eventospara una configuración Cj, y en 2) se incrementa el contador de cada uno de ellos.

En la implementación del algoritmo, ambas fases se realizan en un único paso, demodo que, a la vez que se generan los subconjuntos de eventos, se incrementa elcontador de soporte de cada uno de ellos. Igualmente, para que el acceso a cadauno de los eventsets previamente generados a partir de otras configuraciones serealice de una forma rápida, todos los eventsets se almacenan en una tabla hash.

Para ilustrar este proceso, supóngase que se tiene el siguiente elemento deconfiguración del entorno: <µP=1,e1=1,e2=0>. A partir de esta configuración, elalgoritmo de la Figura 37 computaría siete eventsets, tres correspondientes a loseventos individuales {µP=1}, {e1=1} y {e2=0}, otros tres correspondientes acombinaciones dos a dos, {µP=1,e1=1}, {µP=1,e2=0} y {e1=1,e2=0}, y por último,otro correspondiente al conjunto de todos los eventos de la configuración{µP=1,e1=1,e2=0}. Para cada uno de ellos se incrementa el valor de su contadoren la entrada de la tabla hash correspondiente.


89

4.5.3 Generación de Restricciones

La generación de restricciones a partir de los conjuntos de eventos computados enla sección anterior, puede realizarse aplicando el algoritmo de generación dereglas de asociación de la Figura 35. En una primera fase se obtendrían lasrestricciones con un único evento en el consecuente, y posteriormente, a partir dedichos consecuentes, se generarían las reglas con n eventos en el consecuente,siempre y cuando su factor de confianza estuviese por encima de un umbralmínimo (minconf).

Por ejemplo, supóngase que con el algoritmo de generación de conjuntos deeventos (Figura 37) se han determinado, entre otros, los eventsets {µP=1,e1=1}con soporte 4, {µP=1}con soporte 5, {e1=1} con soporte también 4. De acuerdo alalgoritmo de generación de reglas (Figura 35), se obtendría, entre otras, la reglaµP=1→e1=1, siempre y cuando el factor de confianza mínimo (minconf) seainferior al 80%. La regla obtenida indica que en el 80% de los micropasos convalor 1, el evento e1 tomará el valor 1.

Sin embargo, dicha regla no puede ser considerada como una restricción delentorno, ya que no explica comportamientos siempre presentes en dicho entorno.En concreto, en el ejemplo anterior existe al menos una configuración el entornocorrespondiente al primer micropaso, donde el evento e1 no toma el valor 1. Paraque esa regla pudiese ser utilizada como restricción, el soporte del eventset{µP=1,e1=1} debería ser también igual a 5.

En otras palabras, para que dos conjuntos de eventos puedan formar unarestricción, es condición necesaria que ambos tengan el mismo soporte. Estaconsideración permite simplificar el algoritmo de generación de restricciones en elsentido indicado en la Figura 38.

Entrada: Conjunto H de eventsets del entorno ESalida: Restricciones del entorno para el componente C

para cada hi, hj ∈ H tal que |hi| ≥ 2 hacersi ( hi.soporte = hj.soporte ) y

( hj ⊂ hi ) entoncesgenerar_restriccion hj → (hi – hj)

fin_sifin_para

Figura 38: Algoritmo para la generación de restricciones del entorno

El algoritmo selecciona del conjunto de eventsets H aquellos con una longitud(número de eventos) mayor o igual a 2, como candidatos para formar unarestricción. Para cada candidato hi, se vuelve a recorrer el conjunto, seleccionandoaquellos eventsets hj que a la vez sean subconjunto del candidato (hj ⊂ hi) y tenganigual soporte, formando, en ese caso, la restricción hj→(hi –hj). Como se observa,una consecuencia directa de la condición necesaria para la formación derestricciones (eventsets con el mismo soporte), es que no es necesario realizar la


90

computación del ratio entre los soportes de los eventsets y su comparación con elfactor de confianza.

En caso del ejemplo anterior, se seleccionaría como único eventset candidato{µP=1,e1=1}. Tomando éste, el único eventset que cumple la condición deinclusión e igual soporte es {e1=1}. Entonces, se formaría la restriccióne1=1→µP=1.

4.5.4 Normalización de Macropasos

Dado que los algoritmos de generación del espacio de configuraciones de uncomponente computan diferentes longitudes de macropaso en los diferentesmacropasos explorados, la posterior aplicación de los métodos hasta aquídiscutidos pueden producir restricciones que no son reales de acuerdo alcomportamiento del componente.

Supóngase, por ejemplo, que el entorno de un componente, por simplicidad,ejecuta dos únicos macropasos con longitudes de dos y tres micropasosrespectivamente. El objetivo es observar el comportamiento de un determinadoevento de interfaz a. Supóngase también que el conjunto global deconfiguraciones computado por el algoritmo de exploración es el siguiente:

Macropaso1:

µP =1 ; a = 0

µP =2; a = 1

Macropaso 2:

µP = 1 ; a = 1

µP = 2 ; a = 0

µP = 3 ; a = 1

De acuerdo a los algoritmos presentados a lo largo de este capítulo, la únicarestricción que se obtiene a partir del espacio de configuraciones anterior esµP=3→a=1, es decir, en el tercer micropaso el entorno siempre envía el evento a.Sin embargo, se puede observar en el espacio de configuraciones, que larestricción anterior no es válida: en el primer macropaso el evento a no se envíaen el tercer micropaso.

Este problema es debido a que en la ejecución del sistema, éste puede desarrollarlongitudes diferentes en sus macropasos. Una solución es forzar a que el sistemaejecute siempre la misma longitud de macropaso, insertando en el conjunto globallas configuraciones nulas necesarias que eviten el problema anterior. Laconfiguraciones nulas son configuraciones que tienen valores en el contador demicropaso, pero donde los eventos de interfaz se consideran siempre con el valor0. En el ejemplo anterior, el espacio original de configuraciones se completaríacon la configuración nula <µP=3;a=0> en el primer macropaso.

Por tanto, el proceso de normalización de macropasos consiste en la generación deconfiguraciones nulas que aseguren que todos los macropasos tienen la misma


91

longitud. Esto implica conocer previamente la longitud máxima de macropasocomputada en la generación del espacio de configuraciones. Los macropasos conuna longitud inferior deben ser rellenados con tantas configuraciones nulas comosean necesarias hasta alcanzar la cota superior de longitud de macropaso,incrementando en cada nueva inserción el contador de micropasos, y poniendo acero los valores de los eventos de interfaz.

Este proceso debe realizarse una vez computado el espacio global deconfiguraciones, y previamente al proceso de generación de restricciones.

4.6 Comentarios y DiscusiónEn este Capítulo se presenta una técnica para la generación automática derestricciones del entorno de un componente para su posterior verificación.

La técnica está basada en la extracción de reglas de asociación entre los eventosde interfaz del componente a verificar y el entorno. Debido a la visibilidadexplícita de los micropasos en el modelo computacional de un Sistema ReactivoSíncrono, la variable que enumera los diferentes micropasos se utiliza tambiéncomo atributo en las reglas obtenidas, permitiendo así la generación de patronesdel entorno referidos a instantes temporales (micropasos).

De este modo, es posible automatizar parte del proceso de verificación modularsobre un componente, y evitar la especificación de las suposiciones por parte delusuario y su descarga posterior sobre el entorno del componente.

La técnica aquí descrita está basada en los trabajos previos del autor en [Riva01a][Riva01b]. Recientemente, Cobleigh et al [CoblP03] describen un enfoque quepersigue los mismos objetivos que los tratados en este Capítulo. En dicho trabajo,las suposiciones se aprenden en pasos sucesivos a partir de los contraejemplosproducidos por el verificador utilizando el algoritmo de aprendizaje L* [Angl87].Sin embargo, las suposiciones son dependientes tanto de la propiedad como delcomponente a verificar, por lo que ante cualquier cambio o modificación en ellos,es necesario volver a computar las suposiciones. En la técnica propuesta en esteCapítulo, las restricciones se generan a partir del entorno del componente, por loque son independientes del componente y de la propiedad a verificar, lo que lasdota de la generalidad suficiente para ser utilizadas en la verificación de variaspropiedades sobre el mismo componente sin necesidad de recalcular el entorno.

93

Capítulo 5Generación Simultánea deEntornosLas técnicas descritas en los Capítulos 3 y 4 permiten la generación de entornosde forma automática para un componente. En este Capítulo, se extienden dichosmétodos para la generación simultánea y en paralelo de los entornos en varioscomponentes del sistema, de modo que, las restricciones que explican elcomportamiento del entorno para un componente dado, estén influenciadas por lasobtenidas en otro componente del sistema. Por tanto, esta técnica puede utilizarsepara obtener más restricciones y como un método alternativo al descrito en elCapítulo anterior.

En primer lugar, se introduce el problema mediante un ejemplo sencillo.Posteriormente, se revisan las técnicas de generación de configuraciones y derestricciones detalladas en los capítulos anteriores, y se desarrollan nuevosalgoritmos para su adaptación al nuevo enfoque, considerando inicialmente doscomponentes en paralelo. Finalmente, se generaliza el método para su aplicación avarios componentes.

Generación Simultánea de Entornos

95

5.1 IntroducciónEn el Capítulo 4 se mostró una técnica automática para la derivación automáticade restricciones del entorno para un componente, combinando técnicas de análisisde alcanzabilidad con reglas de asociación. Fijado un componente y explorandoexahaustívamente el entorno del componente (resto del sistema), se extraen reglasde asociación entre los eventos de interfaz del entorno para su utilización comorestricciones en la verificación del componente. El proceso se repite para cada unode los componentes del sistema de manera independiente.

En general, los componentes que forman el sistema estarán acoplados medianteeventos de interfaz de entrada y salida. En la técnica comentada anteriormente,para asegurar la exploración de todas las posibles configuraciones, cada uno deeventos de interfaz de entrada a un componente toma en cada uno de losmicropasos todos los valores posibles. Desde este punto de vista, el proceso degeneración del entorno se basa en considerarlo totalmente “libre”. Sin embargo,los eventos de interfaz de entrada a un componente (entorno) no tienenexactamente un comportamiento libre, sino que realmente están determinados porlos valores producidos por otro u otros componentes.

Por ejemplo, supóngase dos componentes A y B que se comunican mediante doseventos c y d (A envía el evento c a B, y B envía d a A). En la determinación de lassuposiciones para el componente B, c tomaría en cada uno de los micropasostodos los valores posibles 0 ó 1, para asegurar que se extraen todas loscomportamientos de su entorno. Lo mismo se realizaría para el componente Arespecto al evento d. Sin embargo, podría suceder que el comportamiento delevento c estuviese determinado por los valores del evento d, o viceversa, de formaque, en un determinado micropaso, el evento c no tomase nunca el valor 1 debidoa que en otro micropaso previo el evento d tampoco toma nunca el valor 1. Portanto, desde el punto de vista del componente B, no sería necesario considerar enel proceso de generación de su entorno el valor 1 para el evento c. Estasconsideraciones acerca del acoplamiento entre los componentes, producirán, enprincipio, restricciones más ajustadas al comportamiento real del entorno dedichos componentes, ya que previo al proceso de determinación del entorno, ésteya estaría limitado.

Por tanto, el objetivo de este Capítulo es el de abordar la generación derestricciones de forma simultánea para varios componentes del sistema, de formaque las obtenidas en un componente estén basadas en la generadas previamentepara otro u otros componentes del sistema. Para ello, el proceso de generación deconfiguraciones en un componente utilizará las restricciones calculadaspreviamente en otro componente. En la Figura 39 se reproduce el esquema degeneración simultánea de entornos para dos componentes mostrado inicialmenteen el Capítulo 1, Figura 3. En la Tabla 2 se comparan los diferentes procesos dedeterminación de restricciones tratados en esta tesis, suponiendo que se deseaverificar una determinada propiedad en el sistema reactivo síncrono M=[C1||C2].


96


Propiedades C2


ExtraerSuposiciones

X → Y

Y → AB

YZ → B

.....




Propiedades C1

P → Y

QT → FG

Y → Q

.....

Figura 39: Generación simultánea de entornos

Metodología Proceso

Manual

(Capítulo 2)

Establecer suposiciones R2 para el componente C2

Verificar el componente C2 con las suposiciones R2

Verificar en el componente C1 las suposiciones R2 (Descarga)

Establecer suposiciones R1 para el componente C1


Verificar en el componente C2 las suposiciones R1 (Descarga)

Automática un componente

(Capítulos 3 y 4)

Generar suposiciones R2 para C2

Verificar el componente C2 con suposiciones R2

Generar suposiciones R1 para C1

Verificar el componente C1 con suposiciones R1

Automática varios componentes (EsteCapítulo)

Generar suposiciones R1 y R2 para los componentes C1 y C2



Tabla 2: Diferentes grados de automatización en la generación de restricciones

Por comparación con la técnica expuesta en el Capítulo 4, obsérvese que lageneración de suposiciones para ambos componentes se realiza en un único paso


97

independientemente del número de componentes, a diferencia de la anterior, quedebe ser realizada en tantos pasos como componentes.

5.1.1 Ejemplo Introductorio

Para ilustrar el proceso de determinación simultánea de restricciones en paralelopara varios componentes, y los beneficios que aporta el nuevo enfoque comparadocon la técnica discutida en el Capítulo 4, supóngase el modelo descrito en laFigura 40. El sistema está formado por dos componentes, C1 y C2, que secomunican por medio de los eventos a,b y c, donde a y b son eventos de interfazde entrada para el componente C2 y de salida para el componente C1, y c es eventode interfaz de entrada para el componente C1 y de salida para C2. El sistema secomunica con el entorno a través de los eventos de entrada E1, E2, E3 y E4 y desalida S1 y S2. Ambos componentes están formados por los STDs que seespecifican en la Figura 41 y en la Figura 42.

PC2

PC1

E4

a

c

b

E3

E1

E2

S1

S2

Figura 40: Ejemplo: Sistema a verificar modularmente (II)

1

0

STD 11

E1 / i1

i2 / S1

c / a

1

0

STD 12

i1 / b E2 / i2

Figura 41: Ejemplo: Componente C1


98

1

0

STD 21

i2 / cE3 / i1

E4 / c

2

0

1

STD 22

i1 / i2

b / S2

a

Figura 42: Ejemplo: Componente C2

Supóngase que sobre el sistema se ha especificado una propiedad a verificar φdividida a su vez en dos propiedades φ1 y φ2, de modo que cada una pueda serverificada por separado en cada componente, junto con las restricciones(suposiciones) del entorno para cada uno.

La determinación automática de estas restricciones utilizando la técnicapresentada hasta ahora, y discutida en el Capítulo 4, se basa en aislar cadacomponente y obtener las restricciones de forma independiente, es decir, sin teneren cuenta las posibles restricciones o limitaciones en los eventos de interfaz deentrada a cada componente. En el ejemplo, el espacio de configuración para elcomponente C1 se computa de forma que el evento c tome todos los posiblesvalores en cada micropaso, y para el componente C2, los eventos a y b igualmentetomarán todos los posibles valores. Así, las restricciones obtenidas delcomponente C1 para el componente C2 serían:

� µP=1 → a=0 ∧ b=0

� µP=3 → b=0y las del componente C2 para el componente C1:

� (µP=2 || µP=4 || µP=5) → c=0 (éstas se pueden expresar como tresrestricciones independientes, una por cada disyunción del antecedente)

Estas restricciones se incluirían junto con la propiedad a verificar sobre cadacomponente, y se ejecutaría el comprobador de modelos.

Con un estudio más en detalle del modelo del sistema, se puede observar que en elcomponente STD 11, la transición del estado 1 al 0 tiene como condición el valorde un evento de interfaz de entrada c, y como acción un evento de interfaz desalida a. Es decir, existe una relación directa de causalidad entre la aparición deun evento de interfaz de entrada y uno de salida. Dado que c es un evento deinterfaz de entrada y toma en cada micropaso cada uno de los posibles valores (0 ó1), aplicando las técnica de determinación de restricciones para un únicocomponente, no se obtendría ninguna para el evento a (salvo la relativa al primermicropaso), ya que en un micropaso dado siempre producirá los valores que tengac, es decir 0 ó 1.

Sin embargo, lo anterior puede ser considerado como una determinación derestricciones pesimista; realmente los valores del evento c no son libres, sino que


99

su valor está determinado por el comportamiento del componente C2 en undeterminado micropaso. Dicho de otro modo, si se conociesen las restriccionesproducidas por el componente C2 en el micropaso (i-1) para el evento c, sepodrían utilizar para determinar con más exactitud las restricciones delcomponente C1 para el evento a en el micropaso i, y éstas a su vez, se utilizaríanpara determinar las restricciones del componente C2 en el micropaso (i+1).

En el ejemplo, en el componente C2 el evento c tomará siempre el valor 0 en elmicropaso 2 independientemente de los valores de los eventos de interfaz deentrada a y b en el micropaso 1. Teniendo en cuenta esta observación, en lageneración de restricciones para el componente C1, además de las obtenidas parael micropaso 1, se generaría una nueva restricción: dado que en el micropaso 2 elevento c es siempre 0, en el micropaso 3 a es siempre 0 (µP=3→a=0). A su vez, elcomponente C2, utilizaría esta restricción en el micropaso 3 para generarrestricciones referidas al micropaso 4, y así sucesivamente, hasta que se hayanexplorado todas las configuraciones por micropaso en ambos componentes. Alfinalizar el proceso, se obtendrían las restricciones para los componente C1 y C2.

Este nuevo enfoque permite no solamente computar las restricciones de loscomponentes de forma paralela, sino que, también permite generar nuevasrestricciones que no se obtendrían en el caso de la generación considerando loscomponentes por separado (por ejemplo, la restricción µP=2→c=0 no se generaríaen el caso de se tratase el componente C1 individualmente).

5.2 Determinación de Entornos para DosComponentes

En esta Sección, se describen las técnicas y algoritmos que serán utilizados para laobtención de restricciones simultáneamente en un sistema formado por doscomponentes, para, en la próxima sección, ampliar el enfoque a varioscomponentes.

El sistema a verificar S=[W1||W2] estará formado por los componentesW1=<∆1,I1,G1,O1,→1

µ> y W2=<∆2,I2,G2,O2,→2µ>, y sea E el conjunto de eventos

de interfaz, clasificados para cada componente en eventos de interfaz de entrada ysalida:

� Eventos de Interfaz de Entrada para W1, II(W1)=I1∩E

� Eventos de Interfaz de Salida para W2, IO(W1)=O1∩EAnálogamente se definirían los eventos de interfaz de entrada y salida para W2II(W2) y IO(W2), y además se tiene que II(W1)=IO(W2) y II(W2)=IO(W1).

5.2.1 Algoritmo General

Dado un componente, el proceso de extracción de restricciones se basa endeterminar en cada uno de los micropasos de ejecución restricciones en suseventos de interfaz de salida, teniendo en cuenta restricciones en sus eventos de


100

interfaz de entrada previamente computadas en un micropaso previo por otrocomponente.

Más específicamente, dado el sistema S=[W1||W2], el componente W1 desarrollaríael siguiente conjunto de acciones en un micropaso i:� Utilizar Restricciones: Limita el comportamiento de los eventos de interfaz de

entrada de W1 con las restricciones calculadas en el componente W2 en elmicropaso i-1.

� Generar Configuraciones: Computa el conjunto de todas las posiblesconfiguraciones del componente W1 en el micropaso i.

� Generar Restricciones: Partiendo del conjunto de configuraciones de W1,determina restricciones R1 de W1.

El mismo conjunto de acciones se realizaría en el componente W2 para computarlas restricciones correspondientes al micropaso i+1.

Como ejemplo, en la Tabla 3 se muestra una traza de las acciones (y susecuenciación) a realizar por micropaso en cada uno de los componentes,suponiendo que el sistema se estabiliza en el cuarto micropaso para todos losmacropasos.

Micropaso W1 W2

1 Generar Configuraciones

Generar Restricciones

Generar Configuraciones


2 Utilizar Restricciones



Utilizar Restricciones



3 Utilizar Restricciones



Utilizar Restricciones



4 Estable Estable

Tabla 3: Encadenamiento de acciones en la generación de restricciones en paralelo

Inicialmente, se computa para ambos componentes (W1 y W2) el espacio deestados correspondiente al primer micropaso. A partir de estas configuraciones seobtienen relaciones (restricciones) en las variables de interfaz de salida para cadacomponente. En el segundo micropaso, el componente W2 utiliza las restriccionescorrespondientes al primer micropaso generadas en el componente W1, computalas configuraciones y genera las restricciones correspondientes a dicho micropaso.Análogamente, el componente W1 realizará el mismo conjunto de accionesrespecto a las restricciones computadas por el W2. Dado que en ese momento,


101

también están generadas las restricciones correspondientes al micropaso 2 por elcomponente W1, el proceso puede continuar en W2, utilizando esas restriccionespara generar las configuraciones y restricciones correspondientes al tercermicropaso. La generación de configuraciones y restricciones continúa de la mismaforma hasta que el sistema sea estable en ambos componentes.

Las tres acciones anteriores, se condensan en las siguientes:

� Generar_Configuraciones (componente, micropaso, restricciones):Computa las configuraciones del componente en el micropaso especificadoteniendo en cuenta el conjunto de restricciones restricciones. Para generar lasconfiguraciones sin restricciones en los eventos de interfaz de entrada,simplemente se especifican restricciones como el conjunto vacío.

� Generar_Restricciones (configuraciones): Dado un conjunto deconfiguraciones, determina las restricciones en los eventos de interfaz desalida utilizando los algoritmos especificados en el Capítulo 4. Dado que lasconfiguraciones son las calculadas para un micropaso utilizando la acciónanterior, las restricciones obtenidas se referirán siempre al micropaso en curso,por lo que, en principio, no es necesario considerar en cada configuración lavariable contador de micropaso (µP).

En la Figura 43 se formalizan las ideas anteriores mediante un algoritmoaplicable a un sistema S formado por dos componentes W1 y W2.

accion Generacion_Restricciones_Paralelo (Sistema S) es

µP = 1;/* Computación de configuraciones y restricciones micropaso 1 */para cada componente Wi en S (i=1,2)

CµP(Wi) = Generar_Configuraciones (Wi,µP,∅ );RµP(Wi) = Generar_Restricciones (CµP(Wi));

fin_para

a=2;b=1;/* Resto de micropasos */mientras !( Estable (S) ) hacer

µP = µP + 1;para cada componente Wj en S (j=a,b)

k = (j mod 2) + 1;CµP(Wj) = Generar_Configuraciones (Wj, µP, RµP-1(Wk));RµP(Wj) = Generar_Restricciones (CµP(Wj));

fin_para/* Intercambio de componentes */a = (a mod 2) + 1;

fin_mientras

fin_accion

Figura 43: Algoritmo de generación simultánea de restricciones (I)


102

El algoritmo está dividido en dos partes: la primera correspondiente a las accionesa realizar en el primer micropaso, y la segunda en el resto de micropasos.

En el primer micropaso, se computa el espacio de estados para dicho micropasoen cada componente (C1(W1) y C1(W2)). Dado que en el primer micropaso cadacomponente únicamente reacciona a los eventos procedentes del entorno (eventosexternos de entrada), y no a los eventos de interfaz, la computación deconfiguraciones se realiza sin ninguna restricción. A partir del conjunto deconfiguraciones calculadas para cada componente, se generan las restricciones enlos eventos de interfaz de salida (R1(W1) y R1(W2)).

Utilizando las restricciones obtenidas en el primer micropaso para el componenteW1 (R1(W1)), el componente W2 genera el espacio de estados correspondiente a susegundo micropaso y genera nuevas restricciones (R2(W2)). Igualmente, elcomponente W1 realizará las mismas acciones utilizando las restriccionesgeneradas en el componente W2 en micropaso anterior (R1(W2)), generando lasconfiguraciones y restricciones correspondientes a su segundo micropaso. Elproceso continúa hasta que no se puedan generar más configuraciones en ningunode los componentes.

Al final del proceso se obtiene los conjuntos Global(W1) y Global(W2) quecontienen el espacio global de configuraciones para los componentes W1 y W2,respectivamente, y al mismo tiempo las restricciones R(W1) y R(W2).Generalizando, y suponiendo que la longitud de macropasos es m, para cadacomponente Wj se tiene:

�m

i

WjCiWjGlobal1

)()(=

=

�m

i

jij WRWR1

)()(=

=

En las próximas secciones, se comentan más en detalle cada una de las acciones arealizar por micropaso.

5.2.2 Computación de Configuraciones

Aunque muchas de los principios básicos presentados en el Capítulo 3 referentes ala generación del espacio global de configuraciones, pueden ser directamenteaplicables, se hace una necesaria una revisión de las técnicas para su adaptación aeste nuevo enfoque.

En el Capítulo 3, la computación del espacio global de configuraciones se basabaen la generación de todas las posibles secuencias de ejecución (micropasos) apartir de cada estado global alcanzable, utilizando para ello variaciones detécnicas básicas utilizadas en análisis de alcanzabilidad. Partiendo del estadoinicial del componente, y para cada posible combinación de valores del entorno,se determinaban nuevos estados alcanzables almacenando las configuraciones encada micropaso. Para cada estado alcanzable, se repetía el proceso hasta que seexplorasen todos los estados alcanzables. Al final, se obtiene el espacio global deconfiguraciones para el componente (véase el algoritmo de la Figura 11).


103

Dado que cada componente se trataba de manera independiente sin tener encuenta posibles limitaciones del entorno producidas por otros componentes (en elpeor de los casos se toman todos los posibles valores), la anterior aproximación escorrecta, y permite generar para las configuraciones calculadas ciertos patrones decomportamiento en sus eventos de interfaz de salida que se pueden utilizar comorestricciones del componente. Dicho de otro modo, la estrategia para generarconfiguraciones consiste en una exploración en profundidad a nivel de micropaso(micropaso 1, micropaso 2, etc.). Cada secuencia de micropasos computadosforma un macropaso.

Sin embargo, y aunque el objetivo final es el mismo, en este nuevo enfoque laestrategia debe ser diferente. Dado que el objetivo es obtener y utilizarrestricciones en eventos producidas en un micropaso, sin tener en cuenta lasmicropasos siguientes, es necesario conocer “a priori” todas las posiblesconfiguraciones que se produzcan en ese micropaso. O lo que es lo mismo, esnecesario conocer todas las posibles configuraciones del sistema en todos losmacropasos para un micropaso dado. La estrategia en profundidad no sirve paraestos fines, ya que generaría las configuraciones de todos los micropasos para unmacropaso.

Por tanto, es necesario que en la generación de configuraciones se utilice unaexploración en anchura a nivel de micropaso (micropaso n, micropaso n,micropaso n, etc.). Cada macropaso no está formado hasta el final del proceso,pero se conocen todas las configuraciones del sistema relativas a un micropaso.En la Figura 44 se ilustran los procesos de generación de configuraciones en ladeterminación de restricciones considerando, componentes independientes y enparalelo.

Generación de configuracionespara micropaso 1

(Componentes en Paralelo)

Generación de configuracionespara macropaso 1

(Componentes Independientes )

Figura 44: Estrategias de generación de configuraciones

5.2.2.1 Configuraciones para el Primer Micropaso

De acuerdo al algoritmo de la Figura 43, el proceso en un componente comienzacalculando todas las posibles configuraciones correspondientes a su primermicropaso de ejecución. Dado que la exploración es en anchura por micropasos yno es posible conocer “a priori” los estados alcanzables (no se forman losmacropasos), la generación de configuraciones para el primer micropaso debe


104

realizarse considerando todos los posibles estados globales del componente, ypara cada uno de éstos, todas las posibles combinaciones de los eventos queprovienen del entorno.

A partir de este conjunto de configuraciones que se pueden considerar iniciales, segeneraran el conjunto de configuraciones correspondientes al primer micropasodel componente. La Figura 30 representa de forma esquemática este proceso enun componente que recibe dos eventos binarios procedentes del entorno, y queestá formado por dos STDs, cada uno de ellos con dos estados locales.

Configuraciones estados globales

Configuraciones primer micropaso

Figura 45: Esquema de generación de configuraciones para el primer micropaso

Los detalles comentados en el Capítulo 3 relativos a transiciones no deterministas,optimizaciones en la generación del espacio global de configuraciones e interfazcon otros componentes, son también aplicables a este nuevo enfoque.

En la Figura 46 se especifica el algoritmo correspondiente a la generación deconfiguraciones para el primer micropaso en un componente W, que secorrespondería a la acción Generar_Configuraciones(W,1,∅ ) en el algoritmo dela Figura 43.


105

accion Generar_Configuraciones_Primer_MicroPaso es

para cada estado global s del componente W/* Formar configuracion inicial */c = (s,CG,CI,C0);Añadir c a C1(W);para cada combinación de valores en I(W), V(I)

/* valores de los eventos del entorno */c.I ← V(I);/* determinar conjuntos de transiciones habilitadas y ejecutarlas */para cada conjunto H máximo de habilitadas en c

c’ = Aplicar_Regla_Avance (c,H);Añadir c’ a C1(W);

fin_parafin_para

fin_paraDevolver C1(W);

fin_accion

Figura 46: Algoritmo de generación de configuraciones para el primer micropaso

En el bucle más externo se generan las configuraciones iniciales correspondientesa cada estado global del componente. A partir de ellas, se asignan valores a suseventos de entrada del entorno, y se determina el conjunto máximo de transicioneslocales a ejecutar en el primer micropaso. Debido a que este conjunto puede no serúnico (debido a situaciones de no determinismo), y para que las configuracionesreflejen todas las posibles transiciones ejecutadas, para cada conjunto máximo seejecutan sus transiciones. La determinación de los conjuntos máximos puederealizarse siguiendo un esquema similar al descrito en el algoritmo de la Figura18. La ejecución de las transiciones en cada conjunto máximo (acciónAplicar_Regla_Avance) generarán las configuraciones correspondientes al primermicropaso para todos los macropasos.

5.2.2.2 Configuraciones para el Resto de Micropasos

De acuerdo al algoritmo general presentado en la Figura 43, la computación deconfiguraciones para los micropasos distintos del primero debe ser diferente a lacomentada en la sección anterior, debido a que deben reflejar loscomportamientos del sistema ante posibles restricciones previamente calculadasen los micropasos previos.

En la Figura 47 se representa esquemáticamente el proceso de generación deconfiguraciones para el segundo micropaso en el componente W2, teniendo encuenta las restricciones R1(W1) calculadas en el otro componente en el primermicropaso.


106

C1 (W2)R1 (W1) ≠≠≠≠ ∅∅∅∅

C2 (W2)

Figura 47: Configuraciones para el resto de micropasos (con restricciones)

El primer nivel de nodos representa las configuraciones computadas en el primermicropaso para el componente W2 de acuerdo al algoritmo de la Figura 46. Enuna primera fase, se crean nuevas configuraciones derivadas de la aplicación delas restricciones (segundo nivel de nodos en la Figura 47). Por ejemplo,suponiendo que el componente W2 tiene un evento de interfaz a y R1(W1)={a=1},se crearían tantas configuraciones como hubiese en C1(W2) con los mismosvalores en su estado global, eventos internos, eventos de salida, pero donde elevento de interfaz a tendría el valor 1. En la figura esta asignación de valores deeventos de interfaz se refleja mediante una flecha con línea discontinua. En unasegunda y última fase, se ejecutaría propiamente el segundo micropaso,seleccionando las habilitadas, obteniéndose el conjunto de configuraciones delsegundo micropaso (tercer nivel de nodos).

En la Figura 48 se muestra el mismo esquema anterior, pero suponiendo que elconjunto de restricciones computadas para el otro componente sea vacío o noexista. Suponiendo igualmente un único evento de interfaz a de entrada alcomponente W2, en la primera fase deben generarse para cada configuración enC1(W2) dos nuevas configuraciones, una con valor 0 y otra con valor 1 para elevento de interfaz a. Nótese que esto es necesario para reflejar todos los posiblescomportamientos del componente en el segundo micropaso, debido a la presenciadel evento de interfaz que puede tomar cualquier valor en el primer micropaso.

C1 (W2)R1 (W1) = ∅∅∅∅

C2 (W2)

Figura 48: Configuraciones para el resto de micropasos (sin restricciones)


107

Aunque en los esquemas anteriores, tanto para la generación con restriccionescomo sin ellas, se representan explícitamente las configuraciones derivadas de laasignación de valores a las variables de interfaz (nodos en blanco), este conjuntode configuraciones no pertenece al espacio de estados del componente, ya queúnicamente se utilizan como un paso previo a la ejecución de las transiciones delsistema. Por tanto, únicamente necesitan ser almacenadas en el sistema hasta laejecución propiamente dicha del micropaso.

El proceso anterior se corresponde con la particularización de la acciónGenerar_Configuraciones(W2,2,R1(W1)) en el algoritmo general de la Figura 43.En la Figura 49 se representa el algoritmo que generaliza la acciónGenerar_Configuraciones(W2,µP,RµP-1(W1)) para µP ≠1.

accion Generar_Configuraciones_Resto_MicroPasos es

Conf_Temp = ∅ ;/* Crear nuevas configuraciones utilizando RµP-1(W1) */para cada configuración ci ∈ CµP-1(W1)

configuracion t;si RµP-1(W1) = ∅ entonces

para cada combinacion de valores en II(W2), V(II)t ← ci;t.II ← V(II);Añadir t a Conf_Temp;

fin_parasino

t ← cit.II ← RµP-1(W1);Añadir t a Conf_Temp;

fin_sifin_para

/* Ejecutar transiciones a partir de las configuraciones en Conf_Temp */para cada configuración cj ∈ Conf_Temp

para cada conjunto H máximo de habilitadas en cjc’ = Aplicar_Regla_Avance (cj,H);Añadir c’ a CµP(W2);

fin_parafin_paraDevolver CµP(W2);

fin_accion

Figura 49: Algoritmo de generación de configuraciones para el micropaso n

El primero de los bucles implementa la creación de nuevas configuracionespartiendo de las configuraciones del micropaso anterior, pero contemplando lasposibles restricciones computadas en el otro componente en el micropaso previo(RµP-1(W1)). Si el conjunto de esas restricciones es distinto de vacío, las nuevasconfiguraciones son una réplica de las del micropaso anterior, salvo en lasvariables de interfaz de entrada, que reflejarán las restricciones en RµP-1(W1). Sifuese vacío, se crean igualmente nuevas configuraciones, pero contemplando en


108

cada una todos los posibles valores que pueden tomar los eventos del interfaz deentrada.

El segundo de los bucles computa el micropaso µP propiamente dicho. A partirdel conjunto de configuraciones Conf_Temp calculadas en el primero de losbucles, se determinan los conjuntos máximos de habilitadas en cada configuraciónde Conf_Temp, produciendo nuevas configuraciones correspondientes almicropaso µP, y obteniendo CµP(W2).

5.2.3 Generación de Restricciones

En general, la extracción de restricciones para dos componentes en paralelo siguelos mismos fundamentos y principios que los descritos para componentesindividuales comentados en el Capítulo 4.

De acuerdo al algoritmo general descrito en la Figura 43, las restricciones debenser computadas en cada micropaso calculado en cada componente, para otrocomponente, a su vez, las utilice en la generación del siguiente micropaso. Portanto, para su determinación no es necesario el conjunto completo deconfiguraciones del componente (como sucedía en el caso de componentesindividuales), sino solamente las configuraciones relativas al micropaso µP que seesté computando en el componente W, CµP(W).

A continuación, se define el formato que se utilizar para las restricciones yposteriormente se detallarán los algoritmos para su determinación.

5.2.3.1 Formato de las Restricciones

Dado un sistema S formado por dos componentes Wi y Wj, sean II(Wi), IO(Wi),II(Wj), IO(Wj) el conjunto de eventos de interfaz de entrada y salida de cadacomponente, respectivamente.

Una restricción en el micropaso µP para el componente Wj es una implicación dela forma X→Y, donde X⊆ IO(Wi)∩II(Wj) e Y⊆ IO(Wi)∩II(Wj), X∩Y≠∅ .Análogamente se definiría para el componente Wi en el micropaso µP.

Es decir, para un componente dado, las restricciones hacen referencia a suseventos de interfaz de entrada. Aunque el concepto de restricción es igual tanto enla generación individual y simultánea, en este último caso la variable contador demicropasos (µP) no forma parte explícitamente de la restricción, sino que,implícitamente, su valor se deducirá del conjunto de configuraciones CµP(Wj) apartir del cual se determinan. Nótese también que, debido a esto, una restricciónen un determinado micropaso puede no cumplir el formato anterior cuando elevento es único y con un único valor. Por ejemplo, supóngase que se estándeterminando las restricciones para el micropaso k; la restricción a=0 es unarestricción válida, pero sin embargo no cumple el formato anterior (no tieneantecedente). Realmente, dicha restricción se traducirá posteriormente en(µP=k)→(a=0), expresando que durante todos los macropasos, si el micropaso esk, el evento a nunca se enviará.


109

5.2.3.2 Extracción de Restricciones en un Micropaso

El proceso de extracción de restricciones para un micropaso es similar al procesoutilizado para la generación de restricciones en un componente (Capítulo 4), sinmás que substituir el conjunto global de configuraciones de un componente W(Global(W)) por el conjunto de configuraciones del componente en un micropasodado (CµP(W)).

Previo a la aplicación de los algoritmos descritos, es necesario filtrar en cadaconfiguración c∈ CµP(W) los valores que no son necesarios. En otras palabras, parala determinación de restricciones únicamente son necesarios en cadaconfiguración los valores de los eventos de interfaz de salida del componente(IO(W)). Por tanto, las restricciones se obtendrán a partir deC’µP(W)=CµP(W)↑ IO(W), donde ↑ es el operador de proyección.

En la Figura 50 se describe el proceso de generación de restricciones para unmicropaso utilizando los algoritmos descritos en el Capítulo 4.

accion Generar_Restricciones ( CµP(W):conjunto configuraciones ) es

H=∅ ; /* Conjunto de eventsets para luego generar reglas */C’µP(W) = CµP(W) )↑ IO(W);para cada configuracion ci ∈ C’µP(W)

Hi = EventSets(ci);Añadir Hi a H;

fin_paraRµP(W) = Reglas(H);Devolver RµP(W);

fin_accion

Figura 50: Algoritmo de generación de restricciones para un micropaso

En primer lugar se determina el conjunto de eventsets (todos los subconjuntos devalores de eventos de interfaz de salida que se puedan formar) del micropaso y apartir de él se obtienen las reglas entre dichos eventsets. Las reglas obtenidasforman el conjunto de restricciones en ese micropaso.

5.2.3.3 Restricciones para Todos los Micropasos

La aplicación sistemática de la computación de configuraciones y generación derestricciones en cada uno de los componentes de un sistema de acuerdo a lodescrito en las secciones anteriores, permite la generación de restricciones en uncomponente derivadas de las restricciones en otro componente y viceversa. Secomputan a nivel de micropaso para cada componente, por lo que al final, lasrestricciones de un componente son la unión de las obtenidas en cada uno de losmicropasos.

Sin embargo, y de acuerdo al formato y proceso descrito para su obtención,pueden existir problemas para restricciones que se refieren a valores de eventos


110

durante todos los micropasos. Supóngase, por ejemplo, que para un componenteque ejecutó una longitud de macropaso 3 se obtuvieron, entre otras, lasrestricciones (a=1→b=0) en cada micropaso. Debido a que, las restricciones de uncomponente son la unión de las obtenidas por micropaso, el componente generaríatres restricciones: {µP=1∧ a=1→b=0, µP=2∧ a=1→b=0, µP=3∧ a=1→b=0}. Lomismo, se podría codificar por la restricción (a=1→b=0), ya que al no haberreferencia al contador de micropasos, se interpretaría para todos los micropasos.Sin embargo, ésta nunca se podría obtener en la determinación de restricciones enparalelo, ya que se calculan localmente a partir de las configuraciones en cadamicropaso y no es posible derivar para un micropaso comportamientos en losmicropasos anteriores. Nótese que esto no afecta a la obtención de restricciones encomponentes individuales (Capítulo 4), ya que las restricciones se calculanpartiendo de todas las configuraciones del componente, y en particular, de todoslos micropasos.

Una solución a la limitación anterior es almacenar todas las configuraciones detodos los micropasos de un componente, y posteriormente extraer las restriccionesa partir del conjunto global. Sin embargo, computacionalmente no es viabledebido a que se deben mantener a la vez tantos espacios globales deconfiguraciones como componentes, lo que en muchos de los casos produciría unexcesivo consumo de memoria principal.

Otra solución, derivada de la anterior, es almacenar, en vez de todas lasconfiguraciones, las “configuraciones preprocesadas” o conjuntos de eventsets (enel algoritmo de la Figura 50, el conjunto H), que ocupan menos espacio y elacceso a sus elementos se puede optimizar mediante tablas hash. De este modo,más que recordar todas las configuraciones, se guardan ocurrencias deconfiguraciones, para posteriormente generar las reglas.

Por tanto, la obtención de restricciones de forma paralela en varios componentesdebe realizarse en los dos pasos siguientes:

� Paso 1 (Restricciones por Micropaso): Determinar las restricciones pormicropaso en cada componente, de forma que influyan en la computación delsiguiente micropaso.

� Paso 2 (Restricciones para todos los Micropasos): Generar las restriccionesa partir de los conjuntos de eventsets de cada componente calculados en elpaso anterior, obteniendo restricciones que afectan a todos los micropasos.

El objetivo del Paso 1 es obtener restricciones a nivel de micropaso en cadacomponente de modo que se puedan utilizar para la computación deconfiguraciones y micropasos en otros micropasos posteriores. El objetivo delPaso 2 es obtener restricciones en cada componente y para todos los micropasospara su verificación modular. Si R1 y R2 son los conjuntos de restriccionesobtenidos de los pasos 1 y 2 anteriores, respectivamente, claramente R1⊆ R2. Seilustran gráficamente ambos pasos en la Figura 51 para dos componentes A y B.


111

A B

R1(A) R1(B)

R2(A) R2(B)

R3(A) R3(B)

R(A) R(B)Paso 1

Paso 2

Figura 51: Pasos en la obtención de restricciones para dos componentes

Esta observación supone una modificación al proceso general de extracción derestricciones como sigue. A nivel de computación de los micropasos, se utilizaríala generación de restricciones indicada en el Paso 1, de modo que en cadamicropaso se computasen los espacios de estados de acuerdo a las restriccionesgeneradas por micropaso. Una vez estabilizado el sistema, es necesario generar lasrestricciones para todos los micropasos, basándose en las obtenidas a nivel demicropaso, utilizando el proceso descrito como Paso 2. Estas serán las utilizadasen la verificación de cada uno de los componentes.

5.2.4 Condición de Estabilidad

En el algoritmo general presentado de la Figura 43, la computación deconfiguraciones y generación de restricciones en un sistema S formado por doscomponentes W1 y W2 finaliza cuando el sistema S alcanza la estabilidad, es decir,cuando no se pueden ejecutar más transiciones globales en el sistema.

Sin embargo, debido a que la generación del espacio del sistema S se hacecomputando los espacios de estados de W1 y W2, es necesario definir la condiciónde estabilidad del sistema en función de la condición de estabilidad de loscomponentes que lo forman.

5.2.4.1 Estabilidad en un Componente

Un componente W se considera estable en un micropaso µP cuando:

)(),(1

WCccEstable(W)Estable µP PjjP

m

jµµ ∈= Λ

=

Es decir, un componente es estable en un micropaso cuando lo son todas lasconfiguraciones de ese micropaso. Intuitivamente, una configuración es establecuando a partir de ella no se pueden ejecutar transiciones.


112

Sin embargo, debido a la forma de computar las configuraciones en undeterminado micropaso, que tienen en cuenta posibles restricciones del entorno (elotro componente del sistema), la anterior definición no implica que si uncomponente es estable en un micropaso el componente se consideré ya estable.

Efectivamente, un componente puede ser estable en una determinadaconfiguración debido al hecho de recibir una restricción en algún evento deinterfaz de entrada que hace que no se pueda ejecutar ninguna transición en lasconfiguraciones de ese micropaso. Sin embargo, esto no puede ser consideradocomo una estabilidad del componente, ya que el entorno (otro componente) puedeenviar en otro micropaso un evento de interfaz que hace que el componente puedeejecutar alguna transición, y por tanto salir de la condición de estabilidad.Considérese por ejemplo, los componentes W1 y W2, formados cada uno de ellospor un único STD, que se representan en la Figura 52:

0

1

2

A

b/a

W10

1

2

B/b

a

W2

Figura 52: Ejemplo: Avance de un componente en condiciones de estabilidad

Ambos componentes tienen un evento de entrada procedente del entorno (A y B,respectivamente), y se comunican mediante dos eventos de interfaz (a y b,respectivamente). De acuerdo al procedimiento descrito en las seccionesanteriores, ambos componentes computarán las configuraciones para su primerpaso, y el componente W1 generará la restricción para el primer micropaso a=0. Elcomponente W2 utilizará la restricción anterior para computar y generar lasrestricciones correspondientes al segundo micropaso. Dado que a=0, no se puedeejecutar ninguna transición en W2, y el componente es estable en el segundomicropaso. Sin embargo, el componente W1 seguirá computando su segundomicropaso, en concreto ejecutando la transición desde el estado 1 al 2 con b=1 yb=0, ya que en el primer micropaso no hay ninguna restricción en el componenteW2. Las configuraciones correspondientes al segundo micropaso en W1, noproporcionan ninguna restricción al evento a, y por tanto, el componente W2abandonará su condición de estabilidad en el tercer micropaso, ejecutando latransición del estado 1 al 2.

En el anterior ejemplo, el componente W2 pasa por condiciones de estabilidadproducidas por restricciones (en el segundo micropaso), que abandona en elsiguiente micropaso al no existir restricciones.


113

5.2.4.2 Estabilidad del Sistema

Por tanto, la estabilidad del sistema se consigue cuando ambos componentes sonestables en un determinado micropaso. Formalmente:

jiWEstableWEstable(S)Estable ji =Λ= ,)()( 21

En el ejemplo de la Figura 52 esto se consigue en el cuarto micropaso.

5.2.4.3 Longitud Máxima de Macropaso

Debido a la anterior definición, la longitud máxima de los macropasos (o máximonivel de micropaso alcanzado en un macropaso) en los componentes computadosen paralelo difiere respecto a la computación de configuraciones paracomponentes individuales. En este último caso, y aún considerando elcomponente “abierto”, el máximo número de micropasos viene condicionadoúnicamente por la estabilidad de dicho componente (salvo en posibles situacionesde no terminación). Una vez computados todos los macropasos (componenteestable), la longitud máxima de macropaso es el mayor número de micropasos enlos macropasos. Por tanto, es factible que si un sistema está formado por doscomponentes, el número de micropasos varíe de un componente a otro. Utilizandola anterior definición de estabilidad, la longitud máxima de macropaso para uncomponente, considerándolo individualmente puede expresarse:

)(CEstablen(C)Max P n⇔=µ

Sin embargo, en la generación para componentes en paralelo el número demicropasos computados no viene determinado solamente por la estabilidad delcomponente, sino también por la estabilidad del resto del sistema. Un componentepuede ser estable en varios micropasos y salir de la estabilidad en otro posterior,debido a la influencia (o no) de restricciones calculadas en otro componente.Desde este punto de vista, la longitud de macropaso es igual para todos loscomponentes que forman el sistema, ya que es determinada de forma global. Portanto, si el sistema está formado por dos componentes W1 y W2 se tiene:

)()( 211 WEstableWEstablen)(WMax P nn Λ⇔=µ

Aunque ambos métodos puedan obtener desde un componente restriccionesexpresadas para diferentes longitudes, no va a influir (a priori) en la verificacióndel componente que haga uso de ellas. Es decir, en la verificación delcomponente, tales restricciones se utilizarán si dicho componente puede ejecutarla longitud de macropaso expresada en ella.

5.2.5 Ejemplo Completo

Se ilustran las técnicas y algoritmos presentados en las secciones anteriores sobreel sistema especificado en la Figura 52.

En la Figura 53 se muestra el espacio de estados (simplificado) generado durantela aplicación de los algoritmos de computación de configuraciones y restricciones


114

de forma paralela. Cada nivel de nodos corresponde a la generación deconfiguraciones para un micropaso, comenzando por los estados globales delcomponente. Los nodos representan las configuraciones computadas para cadacomponente, y se identifican con su estado global. Aquellos nodos sombreadosindican configuraciones estables. Los arcos que unen configuraciones representanla ejecución de una transición (global) en el componente, y se marcan con flechasdiscontinuas las acciones que son simplemente una copia de configuraciones, y,por tanto, no implican explícitamente la ejecución de ninguna transición.W1

0 1 2

0 1 2

0 1 2

2

2

W2

0 1 2

0 1 2

0 1 2

21

2

1

0

Figura 53: Espacio de configuraciones para los componentes de la Figura 52

El proceso comienza computando las configuraciones y las restriccionescorrespondientes al primer paso de ejecución en cada uno de los componentes.Para ello, se consideran todas y cada una de las posibles combinaciones de valoresen los eventos de entrada a cada componente en cada uno de sus estados globales.Debido a que ambos componentes reciben un único evento del entorno, seconsideran dos transiciones por cada configuración inicial, una correspondiente alvalor 0 y otra al valor 1. Nótese que el cálculo de la transición no implicanecesariamente la ejecución de una transición o cambio de estado, sino que puedeser simplemente una copia de configuración. Por ejemplo, la configuraciónresultante de considerar la configuración inicial correspondiente al estado 1 convalor de A=0 en W1, no ejecutará ninguna transición en el componente W1, por loque la configuración resultante en el primer micropaso es una copia de laconfiguración inicial. En el otro sentido, con A=1 se ejecutaría la transición de 0 a1 y se generaría una nueva configuración con el estado global 1. En elcomponente W2 se procede de la misma forma. Dos de las configuraciones estánidentificadas por el mismo estado global (1), pero se deben considerarconfiguraciones diferentes, dado que, la obtenida a partir del estado global 0representa la ejecución de la transición de estado 0 al 1, y por tanto con valor delevento a igual a 1, y la obtenida a partir del estado 1, no representa la ejecución deninguna transición, y por tanto el valor del evento a es igual a 0.


115

A partir de las configuraciones correspondientes, se generan las restriccionesrelativas a las variables de interfaz en el primer micropaso, que se muestranglobalmente para todos los micropasos en la Tabla 4.

En el componente W1 se obtiene a=0 debido a que nunca se ejecutará en esemicropaso la transición de 1 a 2, y en el componente W2 no se puede generarninguna debido a la ejecución de la transición de 0 a 1 cuando el evento externo Bes 1.

µµµµP RµµµµP(W1) RµµµµP(W2)

1 a=0

2 b = 0

3 a=0 b = 0

4 a=0 b =0

Tabla 4: Restricciones para el sistema de la Figura 52

La generación de configuraciones continua en el segundo micropaso para elcomponente W2 considerando la restricción a=0. Por ello, no se puede ejecutarninguna transición a partir de las configuraciones del primer micropaso, y elcomponente es estable en el segundo micropaso. Para permitir el avance del restode componentes, las configuraciones del primer micropaso pasan a ser lasconfiguraciones del segundo micropaso, y se generan la restricción b=0.

En el componente W1 se procede de igual forma, salvo que no existenrestricciones que puedan ser tenidas en cuenta. En ese caso, a partir de lasconfiguraciones almacenadas del primer micropaso, se generan nuevasconsiderando todos los valores que pueda tomar la variable de interfaz b,determinándose igualmente las restricciones correspondientes al evento a, que eneste caso este caso son vacías.

El proceso de generación de configuraciones y restricciones se repite en cadacomponente hasta que se alcance un micropaso donde todas las configuracionesson estables. En el ejemplo esto sucede en el micropaso 4.

Reseñar por último, que no todas las configuraciones representadas en la Figura53 van a constituir los espacios de estados de ambos componentes, sino que lageneración de configuraciones tiene en cuenta las consideraciones relativas a lasoptimizaciones discutidas en el Capítulo 3.

A modo de ejemplo, en la Tabla 5 se muestra la relación a nivel de micropasoentre las transiciones computadas (Calculadas), que se corresponden con los arcosentre configuraciones en el espacio de estados de la Figura 53, y lasconfiguraciones almacenadas para el cálculo de restricciones (Almacenadas), deacuerdo a las optimizaciones derivadas del cortocircuito de micropasos e igualdadde configuraciones.


116

W1 W2µµµµP

Calculadas Almacenadas Calculadas Almacenadas1 6 3 6 4

2 6 1 4 3

3 1 1 6 1

4 1 1 1 1

Total 14 6 17 9

Tabla 5: Configuraciones calculadas/almacenadas para el ejemplo de la Figura 52

Se puede observar, tal y como se esperaba, que el mayor esfuerzo computacionales el que se realiza en aquellos micropasos donde no existen restriccionesgeneradas en el micropaso previo: micropaso 2 en W1 y micropaso 3 en W2,debido a que R1(W2)=∅ y R2(W1)=∅ . En el primer micropaso, obviamente, no seconsideran restricciones en el micropaso previo.

5.3 Determinación de Entornos para VariosComponentes

Todas las técnicas y algoritmos comentados en la sección anterior referentes a laobtención de restricciones para dos componentes se pueden extrapolar fácilmentepara el caso de sistemas formados en general por n componentes.

En esta sección comentaremos los aspectos relativos a la generación deconfiguraciones y restricciones por micropaso que puedan diferir respecto al casode dos componentes.

5.3.1 Algoritmo General

El proceso general de computación de configuraciones y obtención derestricciones por micropaso en varios componentes sigue el mismo esquema deacciones presentado al inicio de este Capítulo, es decir, supone unencadenamiento de acciones Generar_Configuraciones y Generar_Restriccionespor micropaso y componente, tal y como allí fueron definidas.

Mientras que, para dos componentes la generación de configuraciones utilizabalas restricciones computadas en el micropaso previo en el otro componente,cuando el sistema consta de varios componentes, la generación de configuracionesdebe tener en cuenta las restricciones calculadas no solamente en un componente,sino en todos con los que comparte eventos de interfaz. Por ejemplo, supóngamosel sistema de la Figura 54 formado por tres componentes W1, W2 y W3.


117

W1 W2

W3

c

b

aA B

d

C

Figura 54: Ejemplo: Restricciones en varios componentes (I)

El componente W1, para generar las configuraciones y restricciones de undeterminado micropaso µP (µP≠1), utiliza las restricciones computadas en elmicropaso µP-1 para sus eventos de interfaz de entrada b y d generados en loscomponentes W2 y W3, respectivamente. Dicho de otro modo, utilizará en unmicropaso µP (µP≠1) el conjunto de configuraciones RµP-1(W2)∪ R µP-1(W3).

En la Tabla 6 se detallan los conjuntos de configuraciones y restriccionesutilizadas y generadas por micropaso para el ejemplo anterior, en un hipotéticocaso donde se alcanza la estabilidad del sistema en el micropaso 3. Para cadacomponente y micropaso se utiliza la notación <Rutilizadas, Cgeneradas, Rgeneradas> pararepresentar a las restricciones utilizadas, configuraciones generadas y restriccionesgeneradas, respectivamente.

µµµµP W1 W2 W3

1 ∅ , C1(W1), R1(W1) ∅ , C1(W2), R1(W2) ∅ , C1(W3), R1(W3)

2 R1(W2)∪ R1(W3), C2(W1), R2(W1) R1(W1), C2(W2), R2(W2) R1(W2), C2(W3), R2(W3)

3 R2(W2)∪ R2(W3), C3(W1), R3(W1) R2(W1), C3(W2), R3(W2) R2(W2), C3(W3), R3(W3)

Tabla 6: Configuraciones y restricciones para el ejemplo de la Figura 54

Con esta consideración, el algoritmo para varios componentes en paralelo es unageneralización del descrito en la Figura 43 para el caso de dos componentes. Enla Figura 55 se muestra la generalización para un sistema con n componentes.


118

accion Generacion_Restricciones_Paralelo (Sistema S) es

µP = 1;/* Computación de configuraciones y restricciones micropaso 1 */para cada componente Wi en S (i=1,2,..n)

CµP(Wi) = Generar_Configuraciones (Wi,µP,∅ );RµP(Wi) = Generar_Restricciones (CµP(Wi));

fin_para

a=n;b=1;/* Resto de micropasos */mientras !( Estable (S) ) hacer

µP = µP + 1;para cada componente Wj en S (j= a..b)

R’µP-1 = RµP-1 ↑ II(Wj);CµP(Wj) = Generar_Configuraciones (Wj, µP, R’µP-1);RµP(Wj) = Generar_Restricciones (CµP(Wj));

fin_para/* Intercambio de orden en análisis componentes */a = 1;b = n;

fin_mientras

faccionFigura 55: Algoritmo de generación simultánea de restricciones (II)

El proceso de generación de restricciones y configuraciones para el primermicropaso es igual que para el caso de dos componentes. Para el resto demicropasos, en vez de utilizar las restricciones del micropaso anterior para uncomponente, se toman las de todos los componentes (RµP-1) proyectadas sobre loseventos de interfaz de entrada del componente bajo análisis (R’µP-1). Si para elejemplo de la Figura 54 se tienen las restricciones RµP-1={a=0,b=0,c=0,d=1}, enla generación de configuraciones para el siguiente micropaso en el componenteW1, éstas se reducen a R’µP-1={b=0,d=1}, es decir, se consideran únicamente loseventos que afectan al entorno del componente.

El resto de técnicas y algoritmos que describen la generación de entornos para doscomponentes (generación de configuraciones para los micropasos, generación derestricciones, estabilidad del sistema, etc.) son de directa aplicación para el casode varios componentes, y no necesitan más modificaciones que las comentadas,por lo que no haremos ninguna mención a ellos

5.3.2 Ejemplo Completo

En la Figura 56 se especifican cada uno de componentes de la Figura 54,formados por un único STD.


119

0

1

2

b/a

W1

A

d

0

1

2

B/b

a/c

W2

0

1

2

C

c/d

W3

Figura 56: Ejemplo: Restricciones en varios componentes (II)

Como se observa, el sistema está fuertemente acoplado por eventos de interfaz, yademás existen en cada componente relaciones de causalidad entre los eventos deinterfaz de entrada y salida.

Al igual que en el caso de dos componentes, el proceso comienza con ladeterminación de configuraciones y restricciones para el primer micropaso entodos lo componentes, y continua con el resto de micropasos utilizando lasrestricciones calculadas en el micropaso previo, analizando los componentes en elorden inverso al micropaso anterior.

Al término del proceso, se obtienen las restricciones por micropaso y porcomponente especificadas en la Tabla 7.

µµµµP RµµµµP(W1) RµµµµP(W2) RµµµµP(W3)

1 a=0 c=0 d=0

2 b=0 ; c=0 d=0

3 a=0 b=0 d=0

4 a=0 b=0 ; c=0

5 a=0 b=0 ; c=0 d=0

6 a=0 b=0 ; c=0 d=0


En el primer micropaso, los valores de las variables de interfaz son todas cero,salvo para el evento b, cuyo valor viene determinado por la aparición en elentorno del evento externo B. Por ello, en el segundo micropaso quedan estableslos componentes W2 y W3, debido a las restricciones generadas en el micropasoanterior para los eventos a y c, respectivamente. El componente W2 sí puedecomputar las configuraciones de su segundo micropaso, ya que no existerestricción en sus eventos de interfaz de entrada, b. En siguientes micropasos, los


120

componentes W2 y W3 abandonan su condición de estabilidad por la no existenciade restricciones en sus eventos de interfaz. Nótese que, de acuerdo al algoritmoque describimos en la sección anterior, las configuraciones y restricciones pormicropaso calculadas en el componente W1 se nutren de las restriccionesproporcionadas en el micropaso previo por los componentes W2 y W3, ya quecomparten eventos de interfaz. Sin embargo, éstos últimos únicamente utilizanrestricciones provenientes de un único componente.

La longitud máxima de macropaso alcanzada es de 5. El micropaso 6 se considerade estabilización. En la Tabla 8 se indican las configuraciones calculadas yalmacenadas por componentes en cada uno de los micropasos.

W1 W2 W3µµµµP

Calcul. Almac. Calcul. Almac. Calcul. Almac.1 6 3 6 4 6 3

2 12 4 4 3 3 3

3 4 3 6 1 3 1

4 3 3 1 1 6 1

5 12 3 1 1 1 1

6 3 3 1 1 1 1

Total 40 19 19 11 20 12

Tabla 8: Configuraciones calculadas/almacenada para el Ejemplo de la Figura 56

En negrita se indican, por componente, los micropasos (excluyendo el primero)con más configuraciones computadas.

Como es de esperar, el componente que necesita más carga computacional es W1debido a que tiene dos eventos de interfaz de entrada b y d, y por tanto, puedeejecuta más transiciones. Sin embargo, nótese que ésta solamente es importante enaquellos micropasos (2 y 5) donde no hay restricciones para ambos eventos en elmicropaso previo (1 y 4 en la Tabla 7). Para el resto de micropasos, el número deconfiguraciones computadas es muy inferior, debido a que se aplican restriccionespara los dos eventos. Para el resto de componentes se puede concluir lo mismo. Elcomponente W2 computa el mayor número de configuraciones en el micropaso 3,ya que en micropaso 2 no existe restricción para su evento de interfaz de entradaa. En el resto de micropasos se obtiene la restricción a=0, y ésta se utiliza paradisminuir su espacio global de configuraciones. Lo mismo es aplicable para W3 enel micropaso 4.

Finalmente, y para comparar la obtención de restricciones con las técnicaspresentadas en este capítulo frente a los métodos aplicables a los componentesindividualmente (Capítulo 4), en la Tabla 9 se reproducen nuevamente lasrestricciones obtenidas considerando los componentes simultáneamente (Tabla 7),pero remarcando en negrita aquellas que únicamente se obtienen aplicando estemétodo. El resto, se obtienen aplicando cualquiera de los dos enfoques.


121

µµµµP RµµµµP(W1) RµµµµP(W2) RµµµµP(W3)

1 a=0 c=0 d=0

2 b=0 ; c=0 d=0

3 a=0 b=0 d=0

4 a=0 b=0 ; c=0

5 a=0 b=0 ; c=0 d=0

6 a=0 b=0 ; c=0 d=0


Como se observa, el número de restricciones obtenidas con el método simultáneoen varios componentes es mayor que en el caso de componentes individuales. Estoes debido, principalmente, a que se pueden detectar situaciones de causalidadentre la aparición de eventos. Por ejemplo, en el componente W2 se genera larestricción c=0 en el segundo micropaso, debido a que en el micropaso previo sedeterminó que el componente W1 no envía el evento a (a=0). Además, secomputan un mayor número de micropasos, y por tanto, de restricciones. Para elcaso de la generación considerando los componentes individuales, la longitudmáxima de macropaso alcanzada es de 4 en el componente W1 (limitadamanualmente debido a la presencia de ciclos de ejecución infinitos) y 3 en loscomponentes W2 y W3.

Algunas de las restricciones obtenidas con el método simultáneo e indicadas enTabla 9 no podrán ser aplicadas en la verificación de cada componente, debido aque éste no podrá ejecutar los micropasos referenciados por ella. Por ejemplo, larestricción µP=4→a=0 obtenida del componente W1, y que afecta al componenteW2, no se utilizará, ya que para su verificación se considera individualmente, ypor tanto, solamente ejecutará como mucho tres micropasos (el último deestabilización). Contrariamente, la restricción µP=2→d=0 obtenida mediante elmétodo paralelo e imposible de determinar con el método individual, sí puede serinterpretada por el componentes W1 con lo que espacio de estados que tiene queexplorar el verificador se reduce.

5.4 Comentarios y DiscusiónEl algoritmo aquí expuesto computa simultáneamente los entornos de varioscomponentes presentes en el sistema utilizando como base los algoritmos degeneración de configuraciones y restricciones de los capítulos precedentes. Paraque esto sea posible sin almacenar el grafo global de estados de todos loscomponentes, y por tanto evitar el problema de la explosión de estados, lasconfiguraciones se computan incrementalmente en base a un algoritmo deexploración en anchura a nivel de micropaso. En cada uno de los pasos,únicamente es necesario almacenar las configuraciones correspondientes almicropaso que se está generando.


122

Las restricciones para cada componente se obtienen a partir de las configuracionesdel micropaso computado y de las restricciones generadas en el micropaso previode otro u otros componentes. De este modo, es posible que las suposicionesobtenidas reflejen con mayor exactitud los comportamientos del entorno.

Una de las desventajas del algoritmo es la sensibilidad respecto al tamaño de loscomponentes. Sin embargo, debido a que utiliza información exacta del entorno(restricciones en otros componentes), en muchos casos se obtienen másrestricciones y más exactas que con el método individual. Además, conserva lapropiedad de independencia respecto a las propiedades a verificar, lo que tambiénlo hace apropiado para la realización de verificaciones interactivas.

123

Capítulo 6Implementación y EvaluaciónEn este Capítulo se muestra la aplicación y experimentación realizada con losmétodos y técnicas descritas a lo largo de esta tesis a un caso de estudio bienconocido en la literatura relativa a la Especificación y Verificación de SistemasSoftware Reactivos: el problema de la caldera de vapor (Steam Boiler Problem).Dicho sistema es lo suficiente complejo como para permitir la evaluación de losmétodos propuestos.

Inicialmente, se presentan un conjunto de herramientas como prototipo para laexperimentación y validación de los métodos y técnicas de esta tesis, y suintegración con herramientas de especificación y verificación existentes.

Posteriormente, se muestra la especificación operacional de la Caldera de Vaporjunto con las propiedades a verificar (especificación declarativa) a partir de laespecificación textual original en [Abri96], y se realiza la partición encomponentes.

Finalmente, se aplican los diferentes métodos de generación automática derestricciones a cada uno de los componentes del sistema, se verifican cada uno deellos y se comparan cualitativa y cuantitativamente los resultados obtenidos.

Implementación y Evaluación

125

6.1 Descripción de las Herramientas deExperimentación

Una de las principales causas por las que el uso de las técnicas y métodosformales no gozan de mucha popularidad y aplicación en el ámbito de laIngeniería del Software, y particularmente en la verificación formal de sistemassoftware, es debido a la escasa integración de métodos y herramientas que lassoportan [CraiT93] [Clar96b] [Parn98].

A lo largo de la realización de esta tesis y bajo diferentes proyectos deinvestigación en los que el autor fue partícipe, se han desarrollando un conjuntode herramientas, en principio independientes, que, utilizadas conjuntamenteofrecen un entorno integrado, tanto para la especificación como para laverificación modular de sistemas software reactivos. A continuación, se describenbrevemente los proyectos anteriores, y finalmente se describe la integración detodas las herramientas en un entorno de especificación y verificación modular.

6.1.1 Proyecto AUTOVER

El proyecto AUTOVER (Automatización de la Verificación de Sistemas enTiempo Real Utilizando Métodos Estructurados y Lógica Temporal) tenía comoobjetivo general la realización de un prototipo para la integración de unaherramienta CASE para análisis y especificación de sistemas en tiempo real conuna herramienta de verificación automática (el comprobador de modelos SMV[McMi93]), con soporte para la verificación modular y una semántica de pasosbasada en RSML.

La herramienta CASE se utiliza para la especificación operacional (modelo delsistema en notación SA/RT) y declarativa (propiedades que ha de cumplirformuladas en lógica temporal). Esta información gráfica se procesa para obteneruna especificación textual independiente a la herramienta CASE, y posteriormentese traduce al lenguaje soportado por el comprobador de modelos SMV pararealizar la verificación. En caso de que se produzca un contrajemplo, éste setraduce la secuencia de cambios de valores de eventos y estados de procesos a unformato estándar, posibilitando la visualización y animación gráfica delcontraejemplo a través de la navegación por los diferentes macropasos ymicropasos (valores de eventos y procesos, última transición ejecutada, etc.).

En concreto, se desarrollaron las siguientes herramientas de soporte:

� Traductor Sintáctico: Extracción del modelo gráfico en SA/RT (modelooperacional) y de las propiedades (modelo declarativo) a un formato textualintermedio que será utilizado posteriormente por el resto de herramientas.Igualmente, se forman los componentes que serán considerados como launidad mínima de verificación. Estos estarán compuestos por partes delmodelo (submodelos) junto con las (sub)propiedades a verificar sobre cadasubmodelo, suposiciones y compromisos.


126

� Traductor Semántico: Realiza la transformación de los componentesanteriores al lenguaje del comprobador de modelos SMV, preservando lasemántica de ejecución del modelo en macropasos y micropasos.

� Traductor de Contrajemplos: Transforma los contrajemplos proporcionadospor SMV a un formato textual para animación basado en macropasos ymicropasos.

� Animador de Contraejemplos: Utilizando los modelos (operacionales ydeclarativos) permite la visualización y animación del contrajemplo a nivel demacro o micro paso proporcionado por el comprobador de modelos.

Una visión general del sistema se presenta en [Tuya97b]. El proceso de traducciónsemántica al comprobador se describe en [Riva00a] para SMV y en [Tuya97a]para SPIN. Para más detalles sobre los formatos de interfaces internos (traductorsintáctico y traductor de contraejemplos) y el animador de contraejemplos,consultar [AUTO96]. Una vista del Animador de Contrajemplos de AUTOVERse muestra en la Figura 57.

Figura 57: Animación de contraejemplos en AUTOVER

6.1.2 Proyecto EDIC

El proyecto EDIC (Entorno Integrado para Desarrollo de Sistemas Industriales deControl) es una continuación del anterior. Se revisan y reformulan los objetivos deAUTOVER en cuanto al modelado y verificación modular, y se combinan lassemánticas síncronas basadas en pasos con semánticas similares basadas en latécnica de descripción formal ISO Estelle [ISO89]. De esta forma, se podrán


127

integrar en el modelo las partes de control (sistema síncrono) con las partes decomunicaciones (semántica Estelle). Una adaptación de Estelle para especificarcomportamientos síncronos reactivos se puede encontrar en [Ries02] [Ries03].

A parte de los objetivos generales anteriores, EDIC incorpora:

� Soporte a la ejecución y simulación de sistemas reactivos síncronos, ademásde la verificación y modelado.

� Manejo de temporizadores, iteradores, disparadores y STDs múltiples en laespecificación gráfica. Estas nuevas incorporaciones sintácticas afectan altraductor sintáctico.

� Gestión de configuración en las propiedades a verificar en los diferentescomponentes.

� Soporte para verificación de los comprobadores de modelos SMV y SPIN. Portanto, el traductor semántico ofrecerá también soporte para el lenguajePROMELA del comprobador de modelos SPIN.

En lo que respecta a los contenidos y objetivos de esta tesis, la funcionalidad delas herramientas en EDIC son las mismas que AUTOVER, pero ampliadas paracapturar los objetivos anteriores, por lo que no es necesario describirlas más endetalle. En [EDIC98] se encuentra detallada la especificación y diseño de EDIC.

6.1.3 Herramientas de Generación de Restricciones

En este apartado se describe el conjunto de herramientas diseñadas eimplementadas a partir de los diferentes algoritmos especificados en esta tesis,cuyo objetivo es la obtención automática de restricciones en verificación modular.

� Generador de Restricciones para Componente (GenInd): Para uncomponente de un sistema, computa el espacio global de configuraciones delentorno del componente y extrae dichas restricciones. Los algoritmosimplementados son los que se especifican en los Capítulos 3 y 4.

� Generador de Restricciones para varios Componente en Paralelo(GenPar):Computa de forma paralela los espacios de configuraciones y extraelas restricciones de cada uno para varios componentes del sistema. En elCapítulo 5 se describen en profundidad los algoritmos implementados en estaherramienta

� Generador de Restricciones (Gen): Mientras en las dos herramientasanteriores se generan las restricciones a la vez que se determinan los espaciosde estados de uno o varios componentes, esta herramienta permite generarúnicamente las restricciones a partir de un conjunto previo de configuracionesalmacenadas. Los algoritmos de extracción son los descritos en el Capítulo 4.

De esta forma, es posible utilizar la herramienta GenPar únicamente para generarlas configuraciones del entorno de un componente, y posteriormente utilizar Genpara obtener sus restricciones.

Además esta estrategia es necesaria para evitar los problemas de generación derestricciones en varios micropasos descritos en el Capítulo 5. En primer lugar se


128

ejecutaría GenPar para determinar los conjuntos de configuraciones en loscomponentes del sistema, obteniendo restricciones a nivel de micropasosindividuales, y posteriormente, se ejecutaría Gen para determinar restricciones queafectan a todos (varios) micropasos.

� Traductor de Restricciones: Traduce las restricciones obtenidas al lenguajedel comprobador de modelos (PROMELA), de modo que puedan serincorporadas junto con el componente para su verificación.

En cierto modo, el Traductor de Restricciones se comporta como el TraductorSemántico descrito en AUTOVER. En vez de traducir componentes, traducerestricciones de un componente, pero preservando igualmente el concepto demicropaso de la semántica del sistema.

6.1.4 El Comprobador de Modelos SPIN

SPIN es un paquete software utilizado para la verificación formal y simulación desistemas distribuidos [Holz91] [Holz97b] [Holz03], e incluye un comprobador demodelos (denominado también SPIN) basado en análisis de alcanzabilidad conenumeración explícita del espacio de estados que está siendo analizado.

SPIN acepta especificaciones escritas en PROMELA (Process Meta Language) ypropiedades especificadas en lógica temporal lineal LTL. El lenguaje PROMELAestá inspirado en el lenguaje de guardas de Dijkstra [Dijk75] y en el lenguaje CSPde Hoare [Hoar85], y ofrece un amplio rango de construcciones que pueden serutilizadas para la especificación de sistemas reactivos. Por ejemplo:

� Variables locales y globales (como bit, byte, int y short)

� Sentencias de asignación, composición secuencial y bucles

� Procesos paralelos bajo un modelo de concurrencia entrelazado

� Sincronización de procesos vía canales

Esta lista está muy lejos de ser completa, por lo que se remite al lector a losmanuales via Web [SPIN03], al libro [Holz91], a la revisión en [Holz97b], o másrecientemente a la nueva versión descrita en [Holz03].

La comprobación de modelos se realiza mediante un algoritmo eficiente basado enla inclusión de lenguajes (Sección 2.4.2) para determinar si alguna secuencia deestados en el modelo está conforme con la negación de la propiedad a verificar(convertida previamanente en lo que se denomina never claim). Si no existen esassecuencias, la propiedad se cumple en el modelo. En otro caso, se genera uncontraejemplo que demuestra la falsedad de la propiedad especificada. Elcomprobador de modelos utiliza enumeración explícita de estados combinada contécnicas de reducción de orden parcial [Holz94] (Sección 2.5.3). Por defecto, losestados alcanzables son almacenados en una pila, aunque existen técnicas queutilizan un autómata que acepta exactamente los estados alcanzables [Holz99].Una codificación eficiente de este automata utilizando técnicas como BDD reduceel consumo de memoria, pero se penaliza el tiempo de ejecución.


129

Una referencia completa relativa al uso de la comprobación de modelos durante elciclo de vida de verificación y validación de un sistema software, particularizandoen el comprobador de modelos SPIN, se encuentra en [Ruys01].

6.1.5 Conjunto de Herramientas de Soporte a laVerificación Modular

En la Figura 58 se muestra el diagrama de arquitectura con las herramientascomentadas en las secciones anteriores, y que se utilizará como entorno de trabajopara la experimentación.

Herramienta CASE

Submodelos

ModeloDeclarativo

ModeloOperacional

Traductor Sintáctico

Componentes

GenParGenInd

Gen

Traductor de Restricciones

Traductor Semántico

Comprobadorde Modelos

SPIN

Animador deContrajemplos

Suposiciones y Compromisos

Restricciones Automáticas

Figura 58: Herramientas de soporte para la ejecución de los experimentos

Se utilizará una herramienta CASE para la especificación gráfica del modelo y delos diferentes submodelos. Estos submodelos, junto las propiedades a verificar


130

sobre cada uno de ellos especificadas en lógica temporal, se traducen acomponentes, que consideraremos como la unidad mínima de verificación.

Para su verificación individual, es necesario especificar un conjunto desuposiciones para cada uno de los componentes. Esto puede realizarsemanualmente, en función del conocimiento del sistema, o utilizando las técnicasde generación automáticas de entornos que se detallan en esta tesis.

En este último caso, se pueden generarar individualmente para cada uno de loscomponentes (GenInd) o de forma simultánea para varios componentes (GenPar).Otra alternativa, es computar para cada componente las configuraciones concualquiera de las herramientas anteriores, y en base a ellas, generar lasrestricciones utilizando (Gen). En cualquiera de los casos, las restricciones setraducen traducen a PROMELA y se incorporan al componente para suverificación con SPIN. Esta forma de especificación y generación de restriccionesevita la posterior descarga de las suposiciones (ejecución del verificador con lasuposición como propiedad).

En caso de que durante la verificación exista un contraejemplo, éste se puedeanimar sobre la especificación gráfica del componente (submodelo) realizadapreviamente con la herramienta CASE.

6.2 Caso de Estudio: La Caldera de VaporEl problema conocido como “Steam-boiler Control Specification Problem”[Abri96] fue utilizado por los participantes en el seminario “Methods forSemantics and Specification”[DAGS95] como un benchmark para evaluar laaplicabilidad de los métodos formales y sus diferentes notaciones a laespecificación, y en menor medida verificación, del software de control ensistemas industriales empotrados.

Básicamente, el sistema está compuesto de una caldera de vapor para una plantanuclear con cuatro bombas, cada una con su propio controlador de supervisión, undispositivo para medir la cantidad de agua, otro para medir la cantidad de vaporque sale de la caldera y los correspondientes programas de operación y control detransmisión de mensajes. El modelo del sistema no es trivial, ya que los requisitosenfatizan en un comportamiento tolerante a fallos, es decir, el sistema debe seguirfuncionando aún con fallos en alguno de los dispositivos.

La especificación original consiste en una descripción informal en texto donde seespecifica brevemente el entorno físico y ciertos modos de operación delprograma de control, a partir de los cuales se desea extraer los requisitos para sumodelado. Por tanto, no incluye detalles de implementación tales como elcontenido y formato exacto de los mensajes que se intercambian los dispositivosfísicos, o el comportamiento exacto de ellos. Está especificación está derivada deun caso real originariamente formulado por LtCol. J.C. Bauer del Instituto deAnalisis de Fallos de la Universidad de Waterloo en Ontario (Canadá).

El sistema se ha especificado en varios lenguajes y técnicas y lenguajes formalesde especificación como LUSTRE, SIGNAL, NUT, FOCUS, VDM, LOTOS,Statecharts, Z y otros. Estas especificaciones pueden consultarse en [Abri96]. Así


131

mismo, también se han verificado partes del modelo anterior utilizandoherramientas como PVS [Vitt96], CADP (Caesar/Aldebaran DevelopmentPackage) [Carr00], Promela/SPIN [Duva96] [Loef97] [Tuya97b] y ExtendedLOTOS [Will96]. También se ha realizado la especificación de una versión másreducida de la caldera de vapor utilizando métodos gráficos SA/RT y laverificación modular con SPIN [Tuya97a] [Riva01a] [Riva01b].

6.2.1 Descripción del Sistema

Físicamente, y de acuerdo a la descripción en [Abri96], el sistema consta de lossiguientes elementos:

� La caldera de vapor propiamente dicha, con una válvula para la evacuación deagua

� Un dispositivo para medir la cantidad de agua en la caldera de vapor

� Cuatro bombas para inyectar agua a la caldera de vapor

� Cuatro dispositivos para controlar a cada una de las bombas anteriores

� Un dispositivo para medir la cantidad de vapor que sale de la caldera

� Un interruptor para paradas de emergencia

� Un sistema de transmisión de mensajes entre el programa de control y lacaldera de vapor

La tarea principal del programa de control es mantener el nivel de agua entre dosniveles M1 y M2. Por encima de M2 y por debajo de M1, el sistema entra en unestado de avería y el operador deberá de activar el interruptor de parada deemergencia. Así mismo, se mantienen dos niveles de seguridad, N1 (M1<N1) yN2 (N2<M2), que de ser alcanzados, el sistema deberá actuar inyectando oevacuando agua de la caldera. La especificación no detalla la fuente dealimentación, por lo que no se tendrá en cuenta. Por tanto, la única forma decontrolar el nivel de agua en la caldera es mediante la apertura/cierre de lasbombas. En la Figura 59 (tomada de [Loef97]) se representa la estructura físicadel sistema, salvo el interruptor de parada de emergencia.


132

Caldera de Vapor

M1

N1

N2

M2

Medidorde Vapor

BombaControlador

Programa de Control

Válvula

Figura 59: Estructura física de la caldera de vapor

El ciclo de funcionamiento del programa de control está formado por la siguientesecuencia de acciones:

� Recepción de mensajes enviados por los dispositivos o unidades físicas

� Análisis y procesamiento de la información que ha recogido

� Transmisión de mensajes a las unidades físicas

6.2.1.1 Modos de Operación

El programa de control debe implementar los siguientes modos de operación:

� Modo de Inicialización: Como su nombre indica, es el modo de comienzo delprograma de control. El sistema espera por un mensaje que le indique que lasunidades físicas están preparadas, y tan pronto como lo reciba, intentamantener los niveles de agua en la caldera entre M1 y M2, activando lasbombas para su llenado o abriendo la válvula para su vaciado. La válvulaúnicamente se abre en este modo de operación.

� Modo Normal: Es el modo de operación estándar del programa de control. Eneste modo, se intenta mantener los niveles de agua entre N1 y N2 cuandotodos los dispositivos físicos operan correctamente. El programa de control secomunica con los dispositivos accediendo a su estado y utiliza esa informaciónpara abrir y cerrar las bombas. El programa se mantiene en este modo hastaque se detecta un fallo en cualquier dispositivo físico o hasta que se reciba unaseñal de emergencia.

� Modo Degradado: En este modo, el programa intenta mantener un nivelsatisfactorio de agua en la caldera, aún cuando se detecte un fallo en algunaunidad física (salvo en el dispositivo de medida del nivel de agua). Por tanto,la funcionalidad de este modo es la misma que en el modo normal, y elprograma pasará a modo normal cuando el fallo de la unidad ya esté reparado.


133

� Modo de Rescate: El programa intenta mantener un nivel adecuado de aguaen presencia de un fallo en la unidad de medida del nivel de agua. En estecaso, el nivel de agua se estima en función de la dinámica del vapor que salede la caldera.

� Modo Parada de Emergencia: El programa alcanzará este modo cuando sedetecte un fallo vital en alguna de las unidades físicas del sistema, cuando losniveles de agua alcanzan los valores M1 ó M2 ó cuando se produzca un errorde transmisión entre el programa y los dispositivos físicos. En este modo, elprograma enviará un mensaje a los dispositivos físicos y finaliza.

6.2.1.2 Mensajes Enviados y Recibidos por el Programa de Control

La descripción de los mensajes enviados y recibidos por el programa de controlhasta/desde las unidades físicas está en la especificación original [Abri96]. Acontinuación se descibren cada uno de ellos, que serán utilizados posteriormenteen los modelos declarativos y operacional.

El programa de control enviará los siguientes mensajes a las unidades físicas:

� PROGRAM_READY, enviado a las unidades físicas en el modo deinicialización tan pronto como el programa considera que está preparado. Estemensaje es enviado contínuamente hasta que recibe el mensajePHYSICAL_UNITS_READY de los dispositivos físicos.

� VALVE, únicamente enviado en modo inicialización para comunicar a lasunidades físicas la apertura/cierre de la válvula de evacuación de vapor de lacaldera

� OPEN_PUMP, mensaje a las unidades físicas para la apertura de una bomba.

� CLOSE_PUMP, mensaje a las unidades físicas para el cierre de una bomba.

� PUMP_FAILURE, enviado (hasta la recepción del correspondiente acuse derecibo) para indicar que el programa ha detectado un fallo en una bomba

� PUMP_CONTROL_FAILURE, enviado (hasta la recepción delcorrespondiente acuse de recibo) para indicar que el programa ha detectado unfallo en el dispositivo controlador de la bomba

� LEVEL_FAILURE, enviado (hasta la recepción del correspondiente acuse derecibo) para indicar que el programa ha detectado un fallo en la unidad demedida del nivel de agua.

� STEAM_FAILURE, enviado (hasta la recepción del correspondiente acusede recibo) para indicar que el programa ha detectado un fallo en la unidad quemide la salida de vapor de la caldera.

� PUMP_REPAIRED_ACK, este mensaje es enviado por el programa comoacuse de recibo al enviado por una de las bomba para indicar que ésta se hareparado de un fallo previo.

� PUMP_CONTROL_REPAIRED_ACK, este mensaje es enviado por elprograma como acuse de recibo al enviado por un controlador de una bombapara indicar que se ha reparado de un fallo previo.


134

� LEVEL_REPAIRED_ACK, este mensaje es enviado por el programa comoacuse de recibo al enviado por la unidad de medida de agua para indicar que seha reparado de un fallo previo.

� STEAM_REPAIRED_ACK, este mensaje es enviado por el programa comoacuse de recibo al enviado por la unidad de medida del vapor de salida de lacaldera para indicar que se ha reparado de un fallo previo.

� EMERGENCY_SHUTDOWN, enviado a las unidades físicas para indicarque se ha detectado una situación de emergencia y que el programa finalizará.

Los siguientes mensajes son recibidos por el programa de control:

� STEAM_BOILER_WAITING, cuando es recibido en el modo deinicialización, comienza realmente el programa de control.

� PHYSICAL_UNITS_READY, acuse de recibo al enviado previamentePROGRAM_READY.

� PUMP_STATE_ON/OFF, indica el estado de una bomba, abierto o cerradorespectivamente

� PUMP_CONTROL_STATE_ON/OFF, enviado por el controlador de unabomba para indicar si hay o no flujo de agua en dicha bomba

� LEVEL, contiene la información enviada por la unidad de medida del nivel deagua

� STEAM, contiene la información enviada por la unidad de medida de vaporde salida de la caldera

� PUMP_REPAIRED, indica que una bomba ha sido reparada. Este mensaje esenviado hasta que el programa de control envía el correspondiente acuse derecibo.

� PUMP_CONTROL_REPAIRED, indica que la unidad de control de unabomba ha sido reparada. Este mensaje es enviado hasta que el programa decontrol envía el correspondiente acuse de recibo.

� LEVEL_REPAIRED, indica que la unidad de medida de agua ha sidoreparada. Este mensaje es enviado hasta que el programa de control envía elcorrespondiente acuse de recibo.

� STEAM_REPAIRED, indica que la unidad de medida de vapor de salida dela caldera ha sido reparada. Este mensaje es enviado hasta que el programa decontrol envía el correspondiente acuse de recibo.

� PUMP_FAILURE_ACK, acuse de recibo al mensaje correspondiente al fallode una bomba enviado previamente por el programa.

� PUMP_CONTROL_FAILURE_ACK, acuse de recibo al mensajecorrespondiente al fallo de la unidad de control de una bomba enviadopreviamente por el programa.

� LEVEL_FAILURE_ACK, acuse de recibo al mensaje correspondiente alfallo de la unidad de medida del agua enviado previamente por el programa.


135

� STEAM_FAILURE_ACK, acuse de recibo al mensaje correspondiente alfallo de la unidad de medida del agua enviado previamente por el programa.

� EMERGENCY, enviando por las unidades físicas para indicar una situaciónde emergencia.

� TRANSMISSION_ERROR, indica un fallo en la unidad de transmisión demensajes.

6.2.1.3 Comportamiento Físico de la Caldera

Además de la especificación comentada en las secciones anteriores, laespecificación original incluye a modo de apéndice un apartado donde detalla elcomportamiento físico de la caldera de vapor.

Esta información concierne al modo en el que se pueden considerar los valoresmedidos en los diferentes sensores de las unidades físicas relativos a la cantidadde agua (LEVEL), a la cantidad de vapor de salida de la caldera (STEAM) y a laproductividad de cada una de las bombas. Así, en vez de utilizar directamenteestas cantidades se pueden utilizar valores ajustados (máximos y mínimos). Estosvalores ajustados se obtienen bien de las cantidades medidas (LEVEL y STEAM),o bien a partir de valores calculados estimados de un ciclo de ejecución previo.Los valores ajustados serán los medidos cuando no exista ningún fallo en lasunidades físicas y serán los calculados en otro caso. No es objetivo de esta tesismodelizar ni verificar sistemas híbridos, por lo que no entraremos en más detalle.Para ampliar consultar [Abri96].

6.2.2 Modelo Operacional

A partir de la descripción textual del funcionamiento de la caldera de vapor en[Abri96], se ha realizado la especificación operacional del sistema utilizando lanotación gráfica de modelado SA/RT [Ward86]. En la Figura 60 se muestra eldiagrama de subsistemas para el problema de control de la caldera de vapor.


136

P

CONTROL

P7All Pumps

P6Water

P5Steam

D Adjusted Pump

D Adjusted Steam

D Adjusted Level

E/D.AllPump

Level Range

Start/StopPump

Level Risk

PUMP CONTROL REPAIREDACK

PUMP CONTROL FAILURE

PUMP CONTROL FAILUREACKPUMP CONTROL REPAIRED

PUMP STATEON/OFF

PUMP CONTROL STATEON/OFF

CLOSE PUMP

OPEN PUMP

LEVELFAILURE

LEVEL REPAIREDACKLEVEL

REPAIRED

LEVEL FAILUREACK

LEVEL

STEAM FAILUREACK

STEAM REPAIREDACK

STEAMREPAIRED

STEAM FAILURE

EMERGENCY SHUTDOWN

STEAM

PROGRAM READY

PHYSICAL UNITSREADY

VALVE

E.Water

E.Steam

STEAM BOILERWAITING

TRANSMISION ERROR

EMERGENCY

Figura 60: Diagrama de subsistemas de la caldera de vapor

La estructura lógica está dividida en cuatro procesos de alto nivel (subsistemas),cada uno controlando cada unidad física (bombas y sus controladores, unidad demedida del nivel de agua, unidad de medida del vapor de salida y mesa deoperador). A saber:

� Control: Básicamente este proceso realizara el mantenimiento de losdiferentes modos de operación dependiendo de las combinaciones particularesde fallos en las unidades físicas, y enviará los comandos de apertura y cierre(Start/StopPump) al proceso de control de cada una de las bombas (AllPumps)en función del nivel de agua (LevelRange) detectado por el proceso de controldel nivel de agua (Water).

� AllPumps: Este proceso controla el comportamiento de las cuatro bombas yde sus correspondientes controladores. Mantiene y monitoriza el estado de lasbombas y controladores, y modela la apertura/cierre de las bombas enviandolos correspondientes mensajes a las unidades físicas.

� Water: Su objetivo es determinar la cantidad de agua en la caldera de vaporque comunicará al proceso de control (Control) y detectar fallos internos.

� Steam: Similar al proceso anterior, pero para el control del sensor de cantidadde vapor de salida de la caldera.

Los mensajes, tanto de entrada como de salida, para cada uno de los procesos queaparecen en el diagrama de la Figura 60 tienen el mismo significado que eldescrito en la sección anterior. Los almacenes AdjustedLevel, AdjustedSteam yAdjustedPump modelizan los valores de las cantidades ajustadas a las quehacíamos referencia también en el apartado anterior.


137

Dado que la especificación no solamente incluye procesos de control, sinotambién transformaciones discretas y continuas de datos, se utiliza la siguientenotación para su descripción:

TRANS(a,b,c): SI a es cierto ENTONCES b = c

El parámetro a hace refencia a una condición boolena que puede incluircondiciones acerca de valores y/o estados de un determinado proceso o evento.Los parámetros b y c referencian a eventos y/o valores de eventos.

De la misma forma, también es necesario discretizar los diferentes valores quepueden tomar los flujos contínuos de datos. Para ello, se utiliza la siguientenotación:

ENVIRONMENT(evento,ONEOF<n><lista_n_valores>)

donde <n> indica el número de valores que puede tomar y <lista_n_valores>detalla esos cada uno de los valores.

De acuerdo a lo anterior, la especficación de un proceso discreto o continuo dedatos estará formado por un conjunto de sentencias del tipo “TRANS” y“ENVIRONMENT. De este modo, es fácilmente traducible a un STD de formaque la especificación operacional incluya en un marco homogéneotransformaciones contínuas y discretas compatible con el modelo de un SistemaReactivo Síncrono. En la Figura 61 se muestra un esquema simple de traducciónde una especificación discretizada en un STD equivalente.

ENVIRONMENT (B, ONEOF(B1,B2))

TRANS (A, B, B1)

TRANS (!A, B, B2)A /

B=B1

!A /

B=B2

Figura 61: Transformación de datos

A continuación se especifica en más detalle cada uno de los subsistemasanteriores utilizando también modelado SA/RT y detallando las transformacionesde control con STDs y las de datos y discretización de eventos continuos conTRANS y ENVIRONMENT, respectivamente.

6.2.2.1 Control

En la Figura 62 se muestra el diagrama de flujo de datos con cada uno de losprocesos de control en los que se ha dividido el subsistema Control.


138

P3Control Run Mode

P4Control Level

PControl Init Failures

PControl Init Mode

P2Control Modes

E/D.AllPumps

E/D.Control Level

End InitE/D.Control Run Mode

Level RangeLevel Range

Start/Stop Pump

Level Risk

Transmision Failure

Emergency

EMERGENCY SHUTDOWN

Start/Stop Pump

Init Failure

PROGRAM READY

PHYSICAL UNITS READY

VALVE

E/D.Control Init Failures

E.Water

E.Steam

STEAM BOILER WAITING

Init Too Fast E/D.Control Init Mode

TRANSMISION ERROREMERGENCY

Figura 62: CONTROL: Diagrama de subsistema

Se describen a continuación los procesos de control que se detallan con STDs enla Figura 63.

� Control Init Mode: Se encarga del control del modo de operación deinicialización.

� Control Init Failure: Monitoriza los fallos en la fase de inicialización enalguna de las unidades físicas

� Control Modes: Mantiene los diferentes modos de operación del programa decontrol

� Control Run Mode: Encargado de controlar y mantener los modos deoperación Normal, Rescate, Degradado y Parada de Emergencia.

� Control Level: Envía a las bombas los comandos de apertura/cierre enfunción del nivel de agua detectado.


139

Init

Run

Emergency Stop

/E.Control Init Mode

End Init /D.Control Init ModeE.Control Run Mode Level Risk

| Transmision Failure| Emergency

| TRANSMISION ERROR| EMERGENCE

/ D.Control Run ModeD.Control Level

D.All PumpsEMERGENCY SHUTDOWN

Init Failure| Transmision Failure

| TRANSMISSION ERROR| EMERGENCE

/ D.Control Init Mode

Control Modes

Failure

No Failure

( S.Steam Failure Status = Failure| S.Level Failure Status = Failure

| S.Pump Set Failure Status = Failure^(*,|)| Init Too Fast )

/ Init Failure

Control Init FailuresBelow

Above

Between Limits

.

Level Range Low/ Start Pump

Level Range High/ Stop Pump

Level Range Middle

Level Range Middle

Level Ramge High/ Stop Pump


Control Level

Waiting

End

Waiting PhysicalUnits Ready

Emptying

Checking StartConditions

Filling

STEAM BOILER WAITING/E.Control Init Failures

E.SteamE.Water

E.All Pumps


Level Range High/ VALVE=1

Level Range Middle/ Stop Pump

PROGRAM READYE.Control Level

Level Range Middle/ VALVE=0

PROGRAM READYE.Control Level

PHYSICAL UNITS READY/ D.Control Init Failures

End Init

Level Range Middle/ PROGRAM READY

E.Control Level

! (Level Range=High| Level Range=Middle)

/Init Too Fast! (Level Range=Low

| Level Range=Middle)/Init Too Fast

Control Init Mode

Started

Starting

Disabled

Started Pump

PUMP STATE ON

PUMP STATE OFF/ Pump Not Responds

/ OPEN PUMP=1CLOSE PUMP=0

T.Adjust Undefined Pump

PUMP STATE ON& PUMP CONTROL STATE ON

/ T.Adjust Measured Open Pump

PUMP STATE OFF/ Pump Changes State


PUMP CONTROL STATE OFF/ Pump Control Not Responds

PUMP CONTROL STATE OFF/ Pump Control Changes State

Control Run Mode

Figura 63: CONTROL: Diagramas de transición de estados

6.2.2.2 All Pumps

Como se comentó previamente, este subsistema es el encargado de mantener elestado de todas las bombas y sus controladores, y de enviar los mensajes deapertura/cierre a las unidades físicas. En la Figura 64 se detalla el subsistemaAllPumps.


140

MULTIPLE 1..4

P

PumpPAll Pump Failure

Status

PAll Pump Status

D Adjusted Pump

E/D.AllPumps

Stop Pump

Stop Pumps Start Pump

Start Pumps

PUMP CONTROL FAILUREPUMP CONTROL FAILURE ACK

PUMP CONTROL REPAIREDPUMP CONTROL REPAIRED ACK

PUMP STATE ON/OFF

PUMP CONTROL STATE ON/OFF

OPEN PUMP

CLOSE PUMP

Figura 64: ALLPUMPS: Diagrama de subsistema

El proceso de control AllPumpStatus es el encargado de enviar los comandos deapertura a cada una de las bombas de forma individual, y el procesoAllPumpFailureStatus monitoriza el estado de las bombas y sus controladores enfunción de sus estados particulares. Ambos procesos se detallan en la Figura 65.

OFF

ON

Stop Pumps/ Stop Pump^[*]

Start Pumps/ Start Pump^[*]

All Pump Status

No Failure

Failure

S.Pump Set Failure Status^[*,&]= No Failure

S.Pump Set Failure Status^[*,|]<> NoFailure

All Pump Failure Status

Figura 65: ALLPUMPS: Diagramas de transición de estados

Dado que los procesos AllPumpsStatus y AllPumpFailureStatus mantienen laapertura/cierre y los estados de fallo de todas bombas, respectivamente, esnecesario que en su especificación (Figura 65) se incluyan eventos y/ocondiciones de estado referidas a todas las bombas. Para ello, en los eventos seincluye el cualificador [*], que indica que el evento se enviará a todas las bombas.


141

Por ejemplo, para el proceso AllPumpStatus, la acción StopPump^[*] indica quese enviará el evento StopPump a cada una de las bombas. Análogamente, para lascondiciones se utiliza el cualificador [*,<operador_lógico>] indicando que eloperador lógico debe ser aplicado a cada una de las condiciones especificadas. Porejemplo, en el proceso AllPumpFailureStatus la transición etiquetada con lacondición S.PumpSetFailureStatus^[*,&]=NoFailure será cierta cuando todos losprocesos PumpSetFailureStatus relativos a cada bomba estén en el estadoNoFailure.

El proceso Pump representa en el modelo físico a cada una de las bombas y susrespectivos controladores, por lo que es el la parte más compleja de estesubsistema. La especificación para cada bomba (y su controlador) se muestra en eldiagrama de flujo de datos de la Figura 66.

PAdjust Measured

Closed Pump

PAdjust Measured

Open Pump

PAdjust Undefined

Pump

PPump Set Failure

Status

PPump

ControlFailureStatus

PPump Closing

PPump Failure

Status

PPump Opening

PPump Status

D Adjusted Pump

OPEN PUMP

CLOSE PUMP

PUMP STATE PUMP CONTROL STATE

CLOSE PUMP

OPEN PUMP

PUMP REPAIRED ACKPUMP CONTROL REPAIRED ACK

PUMP CONTROL REPAIRED

PUMP CONTROL FAILURE ACK

PUMP CONTROL FAILURE

Pump Control ChangesState

Pump Control NotResponds

Pump Control ChangesState

Pump Control NotResponds PUMP FAILURE

PUMP CONTROL STATEPUMP STATE

Pump ChangesState

Pump Not Responds

E/D.Pump Closing

Pump Set Repaired

E/D.PumpOpening

Pump ChangesState

PUMP FAILURE ACK

PUMP REPAIRED

Pump Not Responds

Stop Pump Start Pump

Figura 66: PUMP: Diagrama de subsistema

El comportamiento de cada bomba individual incluye procesos para lamonitorización de los estados de fallo de la bomba (PumpFailureStatus), de sucontrolador (PumpControlFailureStatus) y de ambos (PumpSetFailureStatus), yprocesos para el control de estado de la bomba (PumpStatus) y del envío demensajes de apertura y cierre del dispositivo físico (PumpOpening yPumpClosing). Su especificación se detalla en la Figura 67.


142

Started

Starting

Disabled

Started Pump

PUMP STATE ON

PUMP STATE OFF/ Pump Not Responds

/ OPEN PUMP=1CLOSE PUMP=0


PUMP STATE ON& PUMP CONTROL STATE ON/ T.Adjust Measured Open Pump



PUMP CONTROL STATE OFF/ Pump Control Not Responds

PUMP CONTROL STATE OFF/ Pump Control Changes State

Pump Opening

Failure ACK

Failure

No Failure

PUMP REPAIRED /PUMP REPAIRED ACK

Pump Not Responds| Pump Changes State

/ PUMP FAILURE

PUMP FAILURE ACK

Pump Failure Status ON

OFF

Start Pump/ D.Pump ClosingE.Pump Opening

Stop Pump/ D.Pump Opening

E.Pump Closing

Pump Set Repaired/ D.Pump ClosingE.Pump Opening

Pump Set Repaired/ D.Pump OpeningE.Pump Closing

Pump Status

Closed

Closing

Disabled

/ CLOSE PUMP=1OPEN PUMP=0


PUMP STATE OFF& PUMP CONTROL STATE OFF

/ T.Adjust Measured Closed Pump

PUMP CONTROL STATE ON/ Pump Control Not Responds

PUMP STATE ON/ Pump Changes State

PUMP STATE ON/ Pump Changes State

PUMP CONTROL STATEON/ Pump Control Changes State

Pump Closing

Failure ACK

Failure

No Failure

Pump Control Not Responds| Pump Control Changes State/ PUMP CONTROL FAILURE

PUMP CONTROL REPAIRED /PUMP CONTROL REPAIRED

ACK

PUMP CONTROL FAILUREACK

Pump Control Failure Status

Failure

No Failure

S.Pump Failure Status <> NoFailure| S.Pump Control Failure Status

<> NoFailure/ T.Adjust Undefined Pump

S.Pump Failure Status = No Failure& S.Pump Control Failure Status

= No Failure/ Pump Set Repaired

Pump Set Failure Status

Figura 67: PUMP: Diagramas de transición de estados

El resto de procesos que aparecen en el diagrama de la Figura 66 son procesosdiscretos de datos que realizan actualizaciones referentes a las cantidadesajustadas de la productividad máxima (AdjustedPump2) y mínima(AdjustedPump1) de la bomba. En la Figura 68 se describen los procesos dedatos.


143

Adjust Undefined PumpTRANS(1, AdjustedPump1,Zero)TRANS(1, AdjustedPump2,MaxPump)

Adjust Measured Closed PumpTRANS(1, AdjustedPump1,Zero)TRANS(1, AdjustedPump2, Zero)

Adjust Measured Open PumpTRANS(1, AdjustedPump1,MaxPump)TRANS(1, AdjustedPump2, MaxPump)

Figura 68: PUMP: Procesos de datos

6.2.2.3 Water

En la Figura 69 se muestran los procesos que componen el subsistema Water.

PEmit Level

PAdjust Calculated

Level

PAdjust Measured

LevelP

Check MeasuredLevel

PLevel Failure Status

D Adjusted Level

D Calculated Level

D Measured Level

D Adjusted Steam

D Adjusted Pump

E.CheckMeasuredLevel

Level Risk

LEVEL

Level Range

Correct Level

Wrong Level

LEVEL FAILURE ACK

LEVEL FAILURE

LEVEL REPAIRED ACK

LEVEL REPAIRED

Figura 69: WATER: Diagrama de subsistema

El proceso de control LevelFailureStatus (Figura 70) se encarga de monitorizar elestado de la unidad de medida del nivel de agua en función de la información quele suministra el proceso continuo de datos CheckMeasuredLevel. Este proceso, leedirectamente la información del mensaje correspondiente al nivel de agua. Elproceso discreto de datos EmitLevel tiene como objetivo suministrar los valores denivel de agua (previamente ajustados por los procesos AdjustMeasuredLevel yAdjustCalculatedLevel) al subsistema Control para que éste emita, si procede, lascorrespondientes órdenes de apertura y cierre a las bombas. El flujo continuo de


144

datos LEVEL se discretiza a los valores NotPresent, Overflow, LessM1,BetweenM1N1, BetweenN1N2 y GreaterM2.

Failure

No Failure

Failure ACK

Wrong Level/LEVEL FAILURE

T.Adjust CalculatedLevel

T. Emit Level

/E.Check MeasuredLevel

LEVEL REPAIRED/ LEVEL REPAIRED

ACKCorrect Level/T.Adjust Measured

LevelT.Emit Level

(Correct Level | WrongLevel)

/T.Adjust Calculated LevelT.Emit Level

LEVEL FAILUREACK

(Correct Level | WrongLevel)

/T.Adjust Calculated LevelT.Emit Level

Figura 70: WATER: Diagrama de transición de estados

Las especificaciones para los procesos discretos y continuos (discretizados) dedatos y eventos continuos se muestran en la Figura 71 y Figura 72,respectivamente:

Adjust MeasuredLevelTRANS (1, AdjustedLevel1, MeasuredLevel)TRANS (1, AdjustedLevel2, MeasuredLevel)

Adjust CalculatedLevelTRANS (1, AdjustedLevel1, CalculatedLevel1)TRANS (1, AdjustedLevel2, CalculatedLevel2)

Emit LevelTRANS (AdjustedLevel2=GreaterM2 || AdjustedLevel1=LessM1, LevelRisk, 1)TRANS (LevelRisk=0 && AdjustedLevel1==BetweenM1N1 &&

AdjustedLevel2==BetweenM1N1, LevelRangeLow, 1)TRANS (LevelRisk=0 && AdjustedLevel1==BetweenM1N1 &&AdjustedLevel2==BetweenN1N2, LevelRangeLow, 1)TRANS (LevelRisk=0 && AdjustedLevel1==BetweenM1N1 &&AdjustedLevel2==BetweenN2M2, LevelRangeMiddle, 1)TRANS (LevelRisk=0 && AdjustedLevel1==BetweenN1N2 &&AdjustedLevel2==BetweenN1N2, LevelRangeMiddle 1)TRANS (LevelRisk=0 && AdjustedLevel1==BetweenN1N2 &&AdjustedLevel2==BetweenN1M2, LevelRangeHigh, 1)TRANS (LevelRisk=0 && AdjustedLevel1==BetweenN2M2 &&AdjustedLevel2==BetweenN2M2, LevelRangeHigh, 1)

Figura 71: WATER: Procesos de datos discretos


145

ENVIRONMENT(LEVEL, ONEOF7(NotPresent, Overflow, LessM1, BetweenM1N1,BetweenN1N2, BetweenN2M2, GreaterM2)

Check MeasuredLevelTRANS(1, MeasuredLevel, LEVEL)TRANS(1,CalculatedLevel1,CalculatedLevel1,ONEOF(LessM1,BetweenM1N1,BetweenN1N2, BetweenN2M2, GreaterM2))TRANS(1,CalculatedLevel2,CalculatedLevel1,ONEOF(LessM1,BetweenM1N1,BetweenN1N2, BetweenN2M2, GreaterM2))TRANS(MeasuredLevel=NotPresent || MeasuredLevel=Overflow,WrongLevel,1)TRANS(MeasuredLevel<CalculatedLeve1 || MeasuredLevel>CalculatedLevel2,WrongLevel,1)TRANS(WrongLevel=0,CorrectLevel,1)

Figura 72: WATER: Procesos de datos continuos

6.2.2.4 Steam

El subsistema Steam es muy parecido en su funcionalidad al componente Water,pero en este caso el control se hace sobre el sensor de medida del vapor de salidade la caldera, y no se envía mensajes a las unidades físicas u otros subsistemas,salvo aquellos referidos al estado de fallo o acuse de recibo de reparación deldispositivo. En la Figura 73 se muestra el diagrama para este subsistema

PUpdate Init Steam

PAdjust Calculated

Steam

PCheck Measured

SteamP

Adjust MeasuredSteam

PSteam Failure

Status

D Adjusted Steam

D Calculated Steam

D Adjusted Steam

D Measured Steam

E.CheckMeasuredSteam

E/D.UpdateInitSteam

Steam Value Not ZeroSTEAM

Correct SteamWrong Steam

STEAM FAILURE ACK

STEAM

STEAM REPAIRED ACK

STEAM REPAIRED

STEAM FAILURE

Steam Value Zero

Figura 73: STEAM: Diagrama de subsistema


146

El proceso SteamFailureStatus (Figura 74) monitoriza los estados de fallo de launidad de medida de vapor enviando los mensajes correspondientes a dichaunidad. El proceso continuo de datos UpdateInitSteam se encarga de actualizar losvalores ajustados (máximos y mínimos) de la cantidad de vapor de salida de lacaldera, en la fase inicial. El proceso CheckMeasuredSteam es igual al anterior,pero realiza las actualizaciones siempre y cuando el valor de vapor sea cero. Elresto de procesos (AdjustedMeasuredSteam y AdjustedCalculatedSteam)actualizan los valores medidos y calculados, respectivamente, en valores losvalores ajustados para su utilización en los procesos CheckMeasuredSteam yUpdateInitSteam. El flujo continuo STEAM se discretiza a los valores NotPresent,Overflow, Zero, Normal y Maximum.

No Failure

Init Steam

Failure

Failure ACK

/ E.Update Init Steam

Steam Value Zero/D.Update Init Steam

E.Check Measured Steam

Steam Value Not Zero/ D.Update Init Steam

STEAM FAILURE

STEAM REPAIRED/ STEAM REPAIRED

ACK

STEAM FAILUREACK

Wrong Steam/T.Adjust Calculated Steam

STEAM FAILURE

(Correct Steam | Wrong Steam)/T.Adjust Calculated Steam

Correct Steam/T.Adjust Measured Steam

(Correct Steam | Wrong Steam)/T.Adjust Calculated Steam

Figura 74: STEAM: Diagrama de transición de estados

Los procesos de datos (discretos y continuos) anteriores se detallan en la Figura75 y Figura 76.


147

AdjustMeasuredSteamTRANS (1, AdjustedSteam1, MeasuredSteam)TRANS (1, AdjustedSteam2, MeasuredSteam)

AdjustMeasuredSteamTRANS (1, AdjustedSteam1, Zero)TRANS (1, AdjustedSteam2, Maximum)

Figura 75: STEAM: Procesos discretos de datos

ENVIRONMENT(STEAM, ONEOF7(NotPresent, Overflow,Zero,Normal,Maximum)

UpdateInitSteamTRANS(STEAM=NotPresent || STEAM=Overflow,AdjustedSteam1,Zero)TRANS(STEAM=NotPresent || STEAM=Overflow,AdjustedSteam2, Maximum)TRANS(STEAM=Zero || STEAM=Normal || STEAM=Maximum,AdjustedSteam1=STEAM)TRANS(STEAM=Zero || STEAM=Normal || STEAM=Maximum,AdjustedSteam2=STEAM)

CheckMeasuredSteamTRANS (1, MeasuredSteam, STEAM)TRANS (1, CalculatedSteam1, ONEOF(Zero,Normal,Maximum))TRANS (1, CalculatedSteam2, ONEOF(Zero,Normal,Maximum))TRANS((STEAM=Zero || STEAM=Normal || STEAM=Maximum) &STEAM<AdjustedSteam2 & STEAM>AdjustedSteam1,CorrectSteam, 1)TRANS ( CorrectSteam=0, WrongSteam, 1)

Figura 76: STEAM: Procesos de datos continuos

6.2.3 Requisitos del Programa de Control: Propiedades

A partir del análisis de los diferentes modos de operación, del significado de losmensajes tanto recibidos como emitidos por el programa de control detallados enla especificación original y de la especificación operacional de la sección anterior,se detallan los requisitos que debe cumplir el programa de control de la caldera devapor.

La mayoría de los requisitos fueron obtenidos de la descripción de los diferentesmodos de operación del programa de control, por lo que se clasificarán en funciónde su relación con dicho modo (Normal, Degradado, Rescate, Parada deEmergencia). Igualmente, se proporcionan requisitos para la detección de fallosen las unidades físicas y otros requisitos obtenidos directamente de laespecificación funcional (no se hace mención a ellos explícitamente en laespecificación original en [Abri96])


148

El objetivo es establecer inicialmente los requisitos (modelo declarativo) para queposteriormente puedan ser verificados sobre un modelo del sistema (modelooperacional). Aunque el objetivo general de esta tesis se centra en la verificaciónmodular, en esta sección y para que guarde la mayor relación posible con laespecificación textual y operacional, los requisitos se detallan globalmente, esdecir para el sistema completo. En próximas secciones veremos como estosrequisitos (en términos de verificación, propiedades) se dividirán en otros, paraque su verificación independiente sobre partes del modelo.

Para cada uno de los requisitos, se detalla la especificación textual y la fórmulalógica equivalente para especificar la propiedad, donde cada variable hacereferencia a elementos del modelo operacional (eventos, almacenes, estados deprocesos, activadores, desactivadores y disparadores), junto con macros “WAS” e“INTERVAL”. Estas macros permiten razonar sobre el valor de eventos y procesosen instantes anteriores (macropasos o micropasos):

� WAS0(evento), es cierta si el evento tomó el valor uno en algún micropasoanterior del macropaso actual

� WAS1(evento), cierto si el evento tomó el valor uno en algún instánte delmacropaso anterior

� WAS2(evento), idem al anterior para dos macropasos anteriores

� INTERVAL(evento1,evento2), es cierto cuando el evento1 pasa a tomar elvalor uno y es falso cuando el evento2 toma el valor falso

Como luego se verá, la codificación de las propiedades utilizando estas macrospermiten evitar la utilización de fórmulas LTL en su especificación [Tuya97a] yreducir el tiempo y memoria durante su verificación.

En total, la especificación declarativa está formada por cincuenta y dospropiedades de seguridad. Todas las propiedades se verificarán posteriormentecon el comprobador de modelos SPIN. Dado que cada una de esas propiedadesserán chequeadas al final de cada uno de los macropasos [Tuya97a] [Riva00a], noes necesario reespecificarlas en lógica LTL, sino que se codificarán enPROMELA tal y como están especificadas con la sentencia assert.

6.2.3.1 Modo Normal

(N.1) En modo normal todos los dispositivos físicos deben de operancorrectamente

ControlRunMode==Normal -> SteamFailureStatus==NoFailure &&LevelFailureStatus==NoFailure &&PumpFailureSetFailureStatus==NoFailure

(N.2) Igualmente, el nivel de agua debe estar entre unos límites admisibles, esdecir, entre M1 y N1, entre N1 y N2 ó entre N2 y M2.


149

ControlRunMode==Normal -> LEVEL==BetweenM1N1 ||LEVEL==BetweenN1N2 || LEVEL==BetweenN2M2 ||ControlModes==EmergencyStop

(N.3) Cuando el nivel de agua en la caldera es inferior a N1 se intenta ajustar conla apertura de las bombas. De otro modo: tan pronto como se detecta que elnivel de agua es inferior a N1 o bien se manda abrir la bomba o ya estabapreviamente abierta.

ControlRunMode==Normal && Level==BetweenM1N1 -> OPENPUMP ||PUMPSTATEON

(N.4) Recíproca a la anterior, para el cierre de las bombas. Cuando el nivel essuperior a N2 se intenta ajustar con el cierre de las bombas. De otro modo:tan pronto como se detecta que el nivel de agua es superior N2 se mandacerrar la bomba o ya está estaba cerrada

ControlRunMode==Normal && Level==BetweenN2M2 -> CLOSEPUMP ||PUMPSTATEOFF

(N.5) En modo normal, un fallo en el detector de nivel lleva al sistema a modorescate siempre y cuando las demás unidades físicas operen correctamente.

LevelFailureStatus!=NoFailure &&SteamFailureStatus==NoFailure &&PumpSetFailureStatus==NoFailure -> ControlRunMode==Rescue

(N.6) El fallo de cualquier otra unidad que no sea el detector de nivel de aguaorigina que el sistema entre en modo degradado

LevelFailureStatus==NoFailure &&(SteamFailureStatus!=NoFailure ||PumpSetFailureStatus!=NoFailure ) -> ControlRunMode==Degraded

(N.7) Si el medidor de nivel de agua detecta que el nivel llega a límites nopermitidos (≥M2 ó ≤M1), se entra en modo emergencia

ControlRunMode==Normal && (LEVEL==LessM1 || LEVEL==GreaterM2)-> ControlModes==EmergencyStop

6.2.3.2 Modo Degradado

(D.1) En modo degradado debe existir algún fallo en alguno de los dispositivosfísicos, salvo en el sensor del nivel de agua.

ControlRunMode=Degraded -> LevelFailureStatus==NoFailure &&(SteamFailureStatus!=NoFailure ||PumpSetFailureStatus!=NoFailure)


150

(D.2) En este modo el nivel de agua en la caldera de vapor se mantiene dentro delos límites admisibles, es decir, entre M1 y N1, entre N1 y N2 ó entre N2 yM2.

ControlRunMode==Degraded -> LEVEL==BetweenM1N1||LEVEL==BetweenN1N2 || LEVEL==BetweenN2M2

(D.3) Al igual que en el modo de operación normal (requisito N.3), cuando el nivelde agua es inferior a N1 se intentará ajustar con la apertura de las bombas

ControlRunMode==Degraded && Level==BetweenM1N1->OPENPUMP ||PUMPSTATEON

(D.4) Recíproco al anterior y similar al requisito N.4. Cuando el nivel es superior aN2 se ajustará enviando los mensajes de cierre a las bombas.

ControlRunMode==Degraded && Level==BetweenN2M2 -> CLOSEPUMP ||PUMPSTATEOFF

(D.5) Cuando las unidades físicas se reparan, se pasa al modo de operación normal.

SteamFailureStatus==NoFailure && LevelFailureStatus==NoFailure&& PumpSetFailureStatus -> ControlRunMode==Normal

(D.6) Si en modo degradado se detecta un fallo del sensor del nivel de agua, elprograma de control debe pasar al modo de operación de rescate

WAS0(ControlRunMode==Degraded)&& LevelFailureStatus==Failure-> ControlRunMode==Rescue

(D.7) Al igual que el requisito N.7. para el modo normal, si en modo degradado sedetecta que el nivel de agua llega a límites no permitidos (≥M2 ó ≤M1) elprograma de control debe pasar a modo de emergencia

ControlRunMode==Degraded &&(LEVEL==LessM1 ||LEVEL==GreaterM2)-> ControlModes==EmergencyStop

6.2.3.3 Modo de Rescate

(R.1) En este modo de operación, se detectó fallo del sensor del nivel de agua, perono del resto de unidades físicas

ControlRunMode==Rescue -> LevelFailureStatus!=NoFailure &&SteamFailureStaus==NoFailure &&PumpSetFailureStatus==NoFailure

(R.2) El nivel de agua se mantiene mediante la estimación de la dinámica supuesta


151

ControlRunMode==Rescue -> AdjustedLevel1>=BetweenM1N1 &&AdjustedLevel2<=BetweenN2M2

(R.3) Se pasa a nivel de emergencia desde este modo, cuando hay un fallo enalgunas de las unidades físicas (excepto el medidor de nivel de agua) ocuando el nivel de agua llega a límites no permitidos (ver requisitos N.7 yD.7).

WAS0(ControlRunMode==Rescue)&&(SteamFailureStatus==Failure ||PumpSetFailureStatus==Failure || (LEVEL<=LessM1 ||LEVEL>=GraterM2)) -> ControlModes==EmergencyStop

6.2.3.4 Modo Parada de Emergencia

(E.1) El programa de control pasará a este modo cuando se produzca un fallo enalguna de las unidades físicas vitales, es decir cuando existe un fallo en elsensor de nivel y la caldera de vapor o bien en el sensor de nivel y lasbombas (incluidos los controladores independientes)

WAS0(ControlRunMode!=NULL) && ((LevelFailureStatus==Failure&& (SteamFailureStatus<>Failure ||PumpSetFailureStaus==Failure)) || (LEVEL<=LessM1 ||LEVEL>=GreaterM2)) -> ControlModes==EmergencyStop

(E.2) También se pasará a este modo, cuando el nivel está en la zona de riesgo(≥M2 ó ≤M1)

LEVEL<=LessM1 || LEVEL>=GreaterM2 ->ControlModes==EmergencyStop

(E.3) Si hay un error de transmisión, el programa cambiará al modo de emergencia

TRANSMISSIONERROR -> ControlRunMode==EmergencyStop

(E.4) Si se recibe un mensaje de emergencia debido a la activación delinterrumptor de parada de emergencia, el programa deberá responderpasando igualmente a modo de emergencia.

EMERGENCY -> ControlRunMode == EmergencyStop

(E.5) En este modo, el programa finaliza, es decir, no debe responder ni emitirningún mensaje a los dispositivos físicos.

ControlModes==EmergencyStop -> OPENPUMP==0 && CLOSEPUMP==0


152

6.2.3.5 Detección de Fallos en Unidades Físicas

(F.1) Tras enviar un mensaje de apertura a alguna de las bombas en un ciclo detransmisión anterior, el programa de control deberá detectar ese fallo en lasbombas (y/o sus controladores)

WAS1(OPENPUMP) && PUMPSTATEON ->PumpSetFailureStatus!=NoFailure

(F.2) Igual que la anterior pero para el envío de órdenes de cierre

WAS1(CLOSEPUMP)&& PUMPSTATEOFF ->PumpSetFailureStatus!=NoFailure

(F.3) El programa detectará si las bombas cambian de estado espontáneamente

1)PumpOpening==StartedPump && PUMPSTATEOFF ->PumpSetFailureStatus!=NoFailure

2)PumpOpening==Started && PUMPSTATEOFF ->PumpSetFailureStatus!=NoFailure

3)PumpOpening==Closed && PUMPSTATEON ->PumpSetFailureStatus!=NoFailure

(F.4) Tras el envío de un mensaje de apertura a alguna de las bombas realizadosen dos ciclos de transmisión anteriores, el programa detectará que elcontrolador no ha respondido

WAS2(OPENPUMP) && !PUMPCONTROLSTATEON ->PumpSetFailureStatus!=NoFailure

(F.5) Idem al anterior para el caso de cierre

WAS2(CLOSEPUMP)&& !PUMPCONTROLSTATEOFF ->PumpSetFailureStatus!=NoFailure

(F.6) Igualmente, el programa detectará que el controlador cambia de estadoespontáneamente.

1)PumpOpening==Started && PUMPCONTROLSTATEOFF ->PumpSetFailureStatus!=NoFailure

2)PumpOpening==Closed && PUMPCONTROLSTATEON ->PumpSetFailureStatus!=NoFailure

(F.7) Si el nivel de agua es erróneo o está fuera del rango permitido, el programadetectará el fallo en la unidad física de medida del nivel de agua

LEVEL==NotPresent || LEVEL==Overflow ->LevelFailureStatus!=NoFailure


153

(F.8) Además, se debe enviar el mensaje de fallo a la unidad física que mide elnivel de agua

WAS0(LevelFailureStatus=NoFailure) &&LevelFailureStaus!=NoFailure -> LEVELFAILURE

(F.9) Si el nivel de vapor es erróneo o está fuera de rango, el programa detectaráel fallo en la unidad física de medida del vapor de salida de la caldera

STEAM==Overflow || STEAM==NotPresent ->SteamFailureStatus!=NoFailure || !WAS1(E.Steam)

(F.10) Igualmente, si el nivel de vapor es incompatible con la dinámica del sistemase detectará el fallo

STEAM<AdjustedSteam1 || STEAM>AdjustedSteam2 ->SteamFailureStatus!=NoFailure || !WAS1(E.Steam)

(F.11) Además, se debe enviar el mensaje de fallo a la unidad física que controla elnivel de vapor de salida de la caldera.

WAS0(SteamFailureStatus=NoFailure) &&SteamFailureStaus!=NoFailure -> STEAMFAILURE

(F.12) Se detectará fallo cuando el nivel de agua es incompatible con la dinámicadel sistema

LEVEL<AdjustedLevel1 || LEVEL>AdjustedLevel2 ->LevelFailureStatus!=NoFailure || !WAS1(E.Water)

6.2.3.6 Otras

(O.1) Si el estado de la unidad de medida de vapor no indica fallo, los valoresajustados deben ser iguales a los enviados por dicha unidad física

SteamFailureStatus==NoFailure -> (AdjustedSteam1==STEAM &&AdjustedSteam2==STEAM) || !WAS1(E.Steam)

(O.2) Todos los valores ajustados relativos al vapor medido tienen un valordefinido siempre

(AdjustedSteam1!=NotPresent && AdjustedSteam2!=NotPresent)|| !WAS1(E.Steam)

(O.3) El estado de inicio relativo al control de la unidad de vapor es siempretransitorio, es decir el programa siempre reaccionará antes estímulos(mensajes) de las unidades físicas


154

SteamFailureStatus!=InitSteam || !WAS1(E.Steam)

(O.4) Igual que (O.1) pero para el caso del nivel de agua: Si esta unidad está enno fallo, sus valores ajustados deben ser iguales a los medidos.

LevelFailureStatus==NoFailure -> (AdjustedLevel1==LEVEL &&AdjustedLevel2==LEVEL) || !WAS1(E.Steam)

(O.5) Igual que (O.2) pero para el caso del nivel de agua: Todos los valoresajustados relativos al nivel de agua tienen un valor definido siempre

(AdjustedLevel1!=NotPresent && AdjustedLevel2!=NotPresent)|| !WAS1(E.Water)

(O.6) Si una bomba está en estado de fallo, no enviará mensajes a las unidadesfísicas

PumpSetFailureStatus!=NoFailure -> OPENPUMP==0 &&CLOSEPUMP==0

(O.7) Las bombas nunca enviarán comandos contradictorios, en particular nuncase enviarán mensajes de apertura y cierre de la bomba a la vez

!(OPENPUMP==1 && CLOSEPUMP==1)

(O.8) Si la bomba se mandó abrir, los valores ajustados tienen sus valoresmáximos

PumpOpening==Started -> AdjustedPump1=MaxPump &&AdjustedPump2==MaxPump

(O.9) Si la bomba está cerrada, los valores ajustados son cero

PumpClosing==Closed -> AdjustedPump1==Zero &&AdjustedPump2==Zero

(O.10) En otro caso deben estar entre el mínimo (cero) y el máximo

PumpOpening==Started && PumpClosing==Closed ->AdjustedPump1=Zero && AdjustedPump2==MaxPump

(O.11) Cuando se solicita la apertura de la bomba, ésta se abre o hay un fallo

WAS1(OPENPUMP) -> PUMPSTATEON ||PumpSetFailureStatus!=NoFailure

(O.12) Simétrica a la anterior para el caso del cierre


155

WAS1(CLOSEPUMP) -> PUMPSTATEOFF ||PumpSetFailureStatus!=NoFailure

(O.13) En el modo inicialización, debe abrirse la válvula de evacuación de aguacuando el nivel está llegando a M2, siempre y cuando se haya recibido elmensaje de inicio del programa de control (STEAMBOILERWAITING)

WAS1(STEAMBOILERWAITING) && ControlModes == Init &&LEVEL==BetweenN2M2 -> VALVE==1

(O.14) En el modo inicialización y una vez recibido el mensaje de inicio delprograma de control (STEAMBOILERWAITING), cuando el nivel deagua es bajo deben abrirse las bombas, o bien ya estaban abiertas

WAS1(STEAMBOILERWAITING) && ControlModes == Init &&LEVEL==BetweenN1M1 -> OPENPUMP || PUMPSTATEON

(O.15)2 En cualquiera de los modos de ejecución del programa de control, salvo elde inicialización y de parada de emergencia, si los niveles de agua estánpor encima de M2 o por debajo de M1, no se abrirán o cerrarán lasbombas, respectivamente

ControlModes==Run && (LEVEL ≥ GraterM2 || LEVEL ≤ LessM1) ->OPENPUMP=0 && CLOSEPUMP=0

(O.16) Si cada una de las bombas no recibe un evento de inicio de apertura(StartPump), no se emitirá un mensaje de apertura (OPENPUMP) a no serque la bomba o su controlador hayan sido reparados

!StartPump -> OPENPUMP=0 || WAS0(PUMPREPAIRED) ||WAS0(PUMPCONTROLREPAIRED)

(O.17) Cuando se solicita la apertura de la bomba, no se envían eventos desolicitud de cierre

INTERVAL(StartPumps,StopPums) -> CLOSEPUMP ||WAS0(StartPumps)

(O.18) Cuando se solicita el cierre de la bomba, no se envían eventos de solicitudde apertura

INTERVAL(StopPumps,StartPums) -> OPENPUMP ||WAS0(StartPumps)

2 Esta propiedad puede obtenerse a partir de E.2 y E.5


156

6.3 Verificación del Sistema CompletoEn esta sección abordaremos el problema de la verificación formal del caso deestudio que detallamos en el anterior apartado.

La especificación del sistema es básicamente reactiva y está realizada casi en sutotalidad mediante diagramas de transición de estados (los procesos de datos setraducen previamente a una máquina de estados con un único estado), por lo queel sistema se adapta perfectamente a los mecanismos de verificación discutidos enlos capítulos precedentes de esta tesis.

6.3.1 Tamaño del Sistema

Como indicador a priori de la complejidad del proceso de análisis y verificacióndel sistema, en la Tabla 10 se muestra el tamaño de los modelos de especificaciónrealizados en la sección anterior en función del número de STDs, transiciones yeventos.

Elemento TOTALDiagramas de Transición de Estados (STDs) 26Eventos de Entrada Externos (Binarios) 12Eventos de Entrada Externos (Discretizados) 2Eventos de Salida 13Eventos Internos 66Transiciones Sintácticas 147

Tabla 10: Tamaño del modelo de la caldera de vapor

Se distingue entre eventos binarios (flujos de control en el modelo estructurado),que tomarán únicamente dos valores, y eventos discretizados (flujos de datoscontinuos), que tomarán los valores que se detallan en su especificacióndiscretizada.

Utilizando la siguiente expresión, se determina el número de estados del modelocompleto:

Nb

j

Ncj

ii VEN 2×

��

�×��

��

�= ∏∏

donde Ei es el número de estados del proceso i, Vj es el número de valores quepuede tomar el evento contínuo discretizado j, Nc es el número de eventoscontinuos discretizados con Vj valores y Nb es el número de eventos binarios.

Dado que el subsistema AllPumps está realmente formado por cuatro bombas,para el cálculo del número de estados totales, se considera inicialmente el modelodividido en dos partes: el substistema AllPumps formado únicamente por unabomba y el resto de procesos. Entonces, para este caso, el número de estados delsubsistema AllPumps (NAllPumps) y el número de estados para el resto del sistema(Nresto):

NAllPumps = 109 = 230


157

Nresto = 1031 = 2103

Por tanto, el número total de estados para el modelo completo, considerandotambién una única bomba en AllPumps:

N = Nresto × NAllPumps = 1040 = 2133

Es decir, para codificar y enumerar todos los posibles estados del sistema senecesita una variable de 133 bits. Aunque no todos los estados serán alcanzables,esta cifra proporciona una idea del efecto de la explosión de estados.

Teniendo en cuenta además las cuatro bombas que forman el sistema, se tiene queel tamaño del espacio de estados del subsistema AllPumps será deaproximadamente 104×9, con lo que el tamaño total del sistema considerando lascuatro bombas es de aproximadamente 2223. Este número de estados no esmanejable por los comprobadores de modelos.

Burch et al [Burc90] demostraron que utilizando una codificación simbólicabasada en árboles binarios de decisión, se podrían verificar algunos tipos desistemas con un tamaño del espacio de estados superior a 1020 estados. Incluso enciertos tipos de problemas (típicamente circuitos secuenciales), utilizando técnicasrefinadas de la anterior, este límite a nivel teórico y bajo condiciones muyestrictas podría llegar a 10120 estados [Burc93]. Con una técnica de enumeraciónexplícita de estados como la empleada por SPIN en la verificación deespecificaciones de sistemas software esta cantidad se reduce a aproximadamente108 estados. Aún cuando hoy en día tanto los recursos computacionales comológicos (nuevos algoritmos de exploración y codificación de espacios de estados)permiten verificar sistemas de mayor tamaño que los indicados en la referencia, enmuchos casos la tecnología actual es todavía insuficiente para realizar unaexploración exhaustiva de especificaciones software, como es el control de lacaldera de vapor.

6.3.2 Resultados Obtenidos

Sobre el modelo completo de la caldera de vapor, considerado inicialmente conuna única bomba, se realizaron experimentos para verificar cada una de laspropiedades derivadas de los requisitos especificados en la Sección 6.2.3. Laverificación se realizó (al igual que en el resto de experimentos de esta tesis)utilizando el comprobador de modelos SPIN versión 3.4.8 sobre una máquinaCompaq Proliant a 933 MHz y 1GB. de memoria principal. El proceso previo detraducción sintáctica del modelo gráfico con semántica de pasos al lenguajePROMELA soportado por SPIN se realizó siguiendo los esquemas en [Tuya97a][Riva00a].

En todas las propiedades, el comprobador de modelos produjo siempre undesbordamiento de memoria, o bien se finalizó manualmente su ejecución despuésde cinco días, por lo que no fue posible realizar la verificación de ninguna de laspropiedades. Los experimentos de verificación de cada propiedad se realizaron,además de con la técnica de búsqueda primero en profundidad en SPIN [Holz96](opción por defecto), con la técnica codificación del espacio de estados en unautomata (similar a los BDDs, y que en principio reduce el consumo de memoria)


158

[Holz99], con la técnica de indexación recursiva del espacio de estados [Holz97a]y el algoritmo bitstate hashing [Holz98], como alternativa a la exploraciónexhaustiva. Aún con estas opciones, la verificación del sistema completo no fueposible para ninguna de las propiedades.

6.4 Verificación ModularDebido a la imposibilidad de la verificación del sistema completo por el problemade la explosión de estados, se plantea en esta sección la verificación modular, demodo que, con los resultados de la verificación de propiedades sobre componentes(partes del modelo), se puedan inferir resultados acerca del sistema completo.

Para este caso de estudio, se consideran como componentes (unidades mínimas deverificación) cada uno de los subsistemas especificados en el diagrama desubsistemas de la Figura 60. En la Figura 77 se representan cada uno de loscomponentes y la comunicación entre ellos por medio de los eventos de interfaz.No se represan los eventos externos de entrada y salida para mayor legibilidad.

Start/Stop Pumps

E. All Pumps

Level RangeLevel Risk

E.Water

E. Steam

CONTROL

ALL PUMPS

WATERSTEAM

Figura 77: Componentes de la caldera de vapor

Cada uno de los componentes está formado por los procesos especificados en cadalos subsistemas relacionados (Sección 6.2.2). Nótese que el componente AllPumpscontiene los procesos de control de las cuatro bombas y sus controladoresrespectivos, por lo que los eventos StartPumps y StopPumps deben ser entendidoscomo eventos de apertura y cierre para las cuatro bombas. Aunque en el diagramaanterior se representa un único evento para LevelRange, éste hace referencia a treseventos diferentes: LevelRangeLow, LevelRangeHigh y LevelRangeMiddle(Figura 71).

Aunque sería posible realizar otra partición del sistema en componentes, lamostrada es una partición lógica que coincide básicamente con la estructura dediseño del sistema, y que se puede inferir fácilmente a partir de la descripcióntextual del problema en [Abri96].


159

6.4.1 Modularización de Propiedades

De acuerdo a la metodología de verificación modular presentada a lo largo de estatesis, además de realizar una partición operacional del sistema en submodelos ocomponentes, es necesario proceder igualmente a la modularización de laespecificación declarativa (requisitos), ya que ésta hace referencia al sistemacompleto, y no a cada uno de los submodelos.

A continuación, mostraremos la partición de cada una de las propiedades averificar sobre el sistema completo (requisitos del programa de controlespecificados en la Sección 6.2.3) en subpropiedades a verificar sobre cada uno delos submodelos especificados anteriormente.

Dado un sistema M=[C1||C2] y una propiedad φ a verificar sobre M, el proceso demodularización coincide con el propuesto en el teorema de composición deAbadi[Abad95] (Capítulo 2, Sección 2.6.2), y consiste en dividir la propiedad φ en φ1 yφ2 tal que φ∧φ2→φ, de modo que, cada una de las subpropiedades φ1 y φ2 puedanser verificadas en cada uno de los componentes C1 y C2 respectivamente, juntocon las suposiciones del entorno de cada componente.

Por ejemplo, considérese el requisito N.7 en la Sección 6.2.3 referido a unapropiedad de seguridad del sistema completo (“si el nivel de agua está fuera delos límites permitidos, se entra en modo de emergencia”):

φ: ControlRunMode==Normal && (LEVEL==LessM1 || LEVEL==GreaterM2)→ ControlModes==EmergencyStop

dónde, como se observa, la especificación de la propiedad contiene variables quepertenecen a los distintos componentes del sistema (ControlRunMode yControlModes pertenecen al componente CONTROL y LEVEL al componenteWATER).

Una reespecificación de la propiedad para que pueda ser verificada sobre cada unode los componentes:

φ1: LevelRisk -> LEVEL==LessM1 || LEVEL==GreaterM2

φ2 ControlRunMode==Normal && LevelRisk →ControlModes==EmergencyStop

Ambas propiedades se puede verificar de forma independiente sobre cada uno delos componentes (φ1 sobre WATER y φ2 sobre CONTROL). Además, se puedecomprobar fácilmente que φ1∧φ 2→φ.

Aunque en algunos casos el razonamiento anterior podría ser suficiente paragarantizar la veracidad o falsedad de la propiedad global φ sobre el sistema M, enla mayoria de los casos no es así. En la verificación de cada propiedad sobre cadacomponente se supone un entorno universal, es decir el entorno puede enviar encualquier instante un evento. Esta situaciación podría producir lo que se denominaun falso positivo, o propiedades que siendo ciertas sobre el modelo son falsasdebido a un comportamiento no permitido del entorno del componente.


160

En el contexto de verificación modular que se utiliza en esta tesis, el problemaanterior se soluciona mediante la especificación de las suposiciones orestricciones impuestas al entorno que se introducen junto con el componente averificar, y posteriormente deben ser verificadas sobre el entorno (garantía de lasuposición ó compromiso).

Este proceso de modularización de propiedades se realizará manualmente.

6.4.2 Formación de Componentes para Verificación

Hasta ahora, se había usado el término genérico de componente para referirse auna parte del sistema con una funcionalidad propia y separable, y además con uninterfaz claramente definido. Desde este punto de vista, el término componentefue utilizado en la sección anterior para describir un subconjunto del modelooperacional que podría ser, en principio, verificado por separado, pero nada semenciona referente a las propiedades (especificación declarativa) que sobre él severificarán.

De acuerdo al enfoque de verificación modular que se maneja en esta tesis[Abad95], el componente no solamente estará formado por su especificaciónoperacional, sino también por las propiedades que debe cumplir. Por tanto laspropiedades a verificar también deben ser consideradas parte de lo que sedenomina componente.

Dado que, la especificación operacional de cada uno de los componentes está yaindicada en la partición del sistema global (Figura 77 y Figura 60), y detallada encada uno de los subsistemas correspondientes (Sección 6.2.2), en los siguientesapartados se especifican cada una de las propiedades a verificar en cadacomponente, siguiendo el enfoque de verificación modular con razonamientosuposición-compromiso

Debido a que, posteriormente se hará referencia a las propiedades en el análisis delos resultados de verificación, se identifican cada una de ellas con el mismoidentificador de la propiedad de la cual son modularizadas (Sección 6.2.3),añadiéndole un sufijo con la letra inicial del componente sobre el que seráverificada (Control, Pump, Water ó Steam). Así, por ejemplo, la propiedad φ1especificada en la sección anterior se codificará como N.7.W.

El proceso de modularización de las propiedades globales se realizó conforme alprocedimiento descrito en la sección anterior. A continuación se detallan, porcomponente, cada una de las propiedades modularizadas:

CONTROL

1 E.3.C TRANSMISSIONERROR -> ControlRunMode==EmergencyStop

2 E.4.C EMERGENCY -> ControlRunMode==EmergencyStop

3 N.7.C ControlRunMode==Normal&&LevelRisk->ControlModes==EmergencyStop


161

4 N.2.1.C ControlRunMode==Normal ->LevelFailureStatus==NoFailure

5 D.2.C ControlRunMode==Degraded ->LevelFailureStatus==NoFailure

6 D.6.C WAS0(ControlRunMode==Degraded)&&LevelFailureStatus==Failure -> ControlRunMode==Rescue

7 D.5.C WAS0(ControlRunMode!=NULL) &&SteamFailureStatus==NoFailure &&LevelFailureStatus==NoFailure && PumpSetFailureStatus→ ControlRunMode == Normal

8 D.1.C ControlRunMode=Degraded -> LevelFailureStatus==NoFailure && (SteamFailureStatus!=NoFailure ||PumpSetFailureStatus!=NoFailure)

9 N.1.C ControlRunMode==Normal ->SteamFailureStatus==NoFailure &&LevelFailureStatus==NoFailure &&PumpFailureSetFailureStatus==NoFailure

10 N.5.C LevelFailureStatus!=NoFailure &&SteamFailureStatus==NoFailure &&PumpSetFailureStatus==NoFailure ->ControlRunMode==Rescue

11 N.6.C LevelFailureStatus==NoFailure &&(SteamFailureStatus!=NoFailure ||PumpSetFailureStatus!=NoFailure) ->ControlRunMode==Degraded

12 R.1.C ControlRunMode==Rescue ->LevelFailureStatus!=NoFailure &&SteamFailureStaus==NoFailure &&PumpSetFailureStatus==NoFailure

13 R.3.C WAS0(ControlRunMode==Rescue)&&(SteamFailureStatus==Failure ||PumpSetFailureStatus==Failure || LevelRisk) ->ControlModes==EmergencyStop

14 E.1.C WAS0(ControlRunMode!=NULL) &&((LevelFailureStatus==Failure &&(SteamFailureStatus<>Failure ||PumpSetFailureStaus==Failure)) || LevelRisk) ->ControlModes==EmergencyStop

15 R.2.C ControlRunMode==Rescue ->LevelFailureStatus!=NoFailure ||ControlModes==EmergencyStop

16 E.5.C ControlModes==EmergencyStop -> E_AllPump == 0

17 O.13.C WAS1(STEAMBOILERWAITING) && ControlModes==Init &&WAS0(LevelRangeHigh) -> VALVE==1

18 O.14.C WAS1(STEAMBOILERWAITING) && ControlModes==Init&&WAS0(LevelRangeLow) -> StopPumps

19 O.15.C ControlModes=Run && WAS0(LevelRisk) -> StartPump==0 &&StopPump==0


162

WATER

1 F.7.W LEVEL==Overflow || LEVEL==NotPresent ->LevelFailureStatus!=NoFailure || !WAS1(E.Level)

2 F.1.2.W LEVEL<AdjustedLevel1 || LEVEL>AdjustedLevel2 ->LevelFailureStatus!=NoFailure || !WAS1(E.Level)

3 O.5.W (AdjustedLevel1!=NotPresent &&AdjustedLevel2!=NotPresent) || !WAS1(E.Level)

4 O.4.W LevelFailureStatus==NoFailure ->(AdjustedLevel1==LEVEL && AdjustedLevel2==LEVEL) ||!WAS1(E.Level)

5 F.8.W WAS0(LevelFailureStatus=NoFailure) &&LevelFailureStaus!=NoFailure -> LEVELFAILURE

6 N.7.W LevelRisk -> (LEVEL==LessM1 || LEVEL==GreaterM2)

7 N.2.W LevelFailureStatus==NoFailure -> LEVEL==BetweenM1N1|| LEVEL==BetweenN1N2 || LEVEL==BetweenN2M2 ||LevelRisk

8 R.3.W LevelRisk -> LEVEL<=LessM1 || LEVEL>=GreaterM2

9 R.2.W LevelFailureStatus!=NoFailure ->(AdjustedLevel1>=BetweenM1N1 &&AdjustedLevel2<=BetweenN2M2) || LevelRisk

10 E.2.W LEVEL<=LessM1 || LEVEL>=GreaterM2 -> LevelRisk

STEAM

1 F.10.S STEAM==Overflow || STEAM==NotPresent ->SteamFailureStatus!=NoFailure || !WAS1(E.Steam)

2 F.9.S STEAM<AdjustedSteam1 || STEAM>AdjustedSteam2 ->SteamFailureStatus!=NoFailure || !WAS1(E.Steam)

3 O.1.S SteamFailureStatus==NoFailure -> (AdjustedSteam1==STEAM&& AdjustedSteam2==STEAM) || !WAS1(E.Steam)

4 O.2.S (AdjustedSteam1!=NotPresent &&AdjustedSteam2!=NotPresent) || !WAS1(E.Steam)

5 O.3.S SteamFailureStatus!=InitSteam || !WAS1(E.Steam)

6 F.11.S WAS0(SteamFailureStatus=NoFailure) &&SteamFailureStaus!=NoFailure -> STEAMFAILURE

ALL PUMPS

1 F.1.P WAS1(OPENPUMP)&& PUMPSTATEON ->PumpSetFailureStatus!=NoFailure

2 F.2.P WAS1(CLOSEPUMP)&& PUMPSTATEOFF ->PumpSetFailureStatus!=NoFailure

3 F.3.1.P PumpOpening==StartedPump && PUMPSTATEOFF ->PumpSetFailureStatus!=NoFailure


163

4 F.3.2.P PumpOpening==Started && PUMPSTATEOFF ->PumpSetFailureStatus!=NoFailure

5 F.3.3.P PumpOpening==Closed && PUMPSTATEON ->PumpSetFailureStatus!=NoFailure

6 F.6.1.P PumpOpening==Started && PUMPCONTROLSTATEOFF ->PumpSetFailureStatus!=NoFailure

7 F.6.2.P PumpOpening==Closed && PUMPCONTROLSTATEON ->PumpSetFailureStatus!=NoFailure

8 O.6.P PumpSetFailureStatus!=NoFailure -> OPENPUMP==0 &&CLOSEPUMP==0

9 O.6.P !(OPENPUMP==1 && CLOSEPUMP==1)

10 O.8.P PumpOpening==Started -> AdjustedPump1=MaxPump&&AdjustedPump2==MaxPump

11 O.9.P PumpClosing==Closed -> AdjustedPump1==Zero &&AdjustedPump2==Zero

12 O.10.P PumpOpening==Started && PumpClosing==Closed ->AdjustedPump1=Zero && AdjustedPump2==MaxPump

13 E.5.P E_AllPump == 0 -> OPENPUMP==0 && CLOSEPUMP==0

14 F.4.P WAS2(OPENPUMP) && !PUMPCONTROLSTATEON ->PumpSetFailureStatus!=NoFailure

15 F.5.P WAS2(CLOSEPUMP) && !PUMPCONTROLSTATEOFF ->PumpSetFailureStatus!=NoFailure

16 O.11.P WAS1(OPENPUMP) -> PUMPSTATEON ||PumpSetFailureStatus!=NoFailure

17 0.12.P WAS1(CLOSEPUMP) -> PUMPSTATEOFF º||PumpSetFailureStatus!=NoFailure

18 0.16.P !StartPump -> OPENPUMP=0 || WAS0(PUMPREPAIRED) ||WAS0(PUMPCONTROLREPAIRED)

19 0.17.P INTERVAL(StartPumps,StopPumps)-> CLOSEPUMP ||WAS0(StopPumps)

20 0.18.P INTERVAL(StopPumps,StartPumps)-> OPENPUMP ||WAS0(StartPumps)

6.5 Verificación de ComponentesUn enfoque habitual en la verificación de componentes consiste en seguir unproceso incremental e interactivo, como sigue. Inicialmente, se chequea lapropiedad a verificar sin ninguna suposición sobre el entorno; en caso de que éstasea falsa (falsos positivos), se analiza el contraejemplo producido para determinarcomportamientos no reales del entorno que falsifican la propiedad, y se fijan lasrestricciones (suposiciones) para eliminar los falsos positivos. El proceso deverificación y especificación de suposiciones continúa hasta que éstas sean lobastante fuertes para eliminar los comportamientos no reales del entorno.Básicamente este proceso es manual, en el sentido que las suposiciones estánbasadas en la especificación que de ellas hace el analista.


164

Como solución a los problemas derivados de la especificación manual, en estatesis se proponen un conjunto de técnicas que permiten obtener los entornos deforma automática, utilizando dos enfoques diferentes:

� Para componentes individuales (Capítulo 4).

� Simultáneamente para varios componentes (Capítulo 5)

El objetivo, además de la propia automatización y eliminación del componentemanual, es, por una parte, obtener restricciones más ajustadas al comportamientoreal del entorno que eviten posibles falsos positivos, y por otra, evitar la posteriorverificación de las suposiciones realizadas manualmente.

A continuación, se analizan ambos enfoques en la verificación de cada uno de loscomponentes especificados en este Capítulo. En primer lugar, se plantea laverificación sin ningún modelo del entorno y con suposiciones especificadasmanualmente. Posteriormente, se realiza la verificación de los componentes consuposiciones generadas automáticamente, y se comparan las estrategias Manual yAutomática, tanto del punto de vista cualitativo (suposiciones obtenidas paramodelar el entorno del componente), como cuantitativo (rendimiento delcomprobador de modelos en la verificación de la propiedad sobre el componente).

Indicar finalmente que el proceso de verificación de cada componente se realizóutilizando como soporte el conjunto de herramientas especificadas al inicio de esteCapítulo (Figura 58). La especificación gráfica en SA/RT de un componente setraduce a un formato intermedio independiente de la herramienta deespecificación (traductor sintáctico), y de aquí se realiza la traducción a códigoPROMELA (traductor semántico) con semántica de ejecución en macro y micropasos para su verificación con el comprobador de modelos SPIN. Los modelos delentorno de cada componente pueden especificarse en forma de suposiciones ycompromisos por parte del analista (verificación con suposiciones manuales), oser generados automáticamente utilizando los algoritmos descritos en esta tesis(verificación con suposiciones automáticas).

6.5.1 Componente CONTROL

El componente CONTROL, como ya se comentó a lo largo de este capítulo, es elencargado del mantenimiento de los diferentes modos de operación de la caldera yenviará las órdenes respectivas al componente ALLPUMPS para la apertura ycierre de las bombas. Desde el punto de vista del interfaz con el resto decomponentes (Figura 77), el componente recibe el nivel de agua detectado por launidad física (LevelRange) y/o un evento que indica un fallo potencial en launidad de medida (LevelRisk) y en función de esos valores mantiene el modo deoperación deseado en función de la especificación, enviando los eventos parainiciar el cierre o apertura de la bombas de vapor (Start/Stop Pumps). En el modode operación de inicialización, una vez recibido el evento desde la unidad físicaSTEAM BOILER WAITING activará el resto de componentes (eventos deactivación E.Water, E.Steam y E.AllPumps respectivamente). Aunque no sereflejan explícitamente como eventos de interfaz, el componente CONTROLnecesita “conocer” los estados (de fallo o no) del resto de componentes (Figura63), por lo que las variables que acceden a los estados de los componentes


165

(S.SteamFailureStatus, S.LevelFailureStatus y S.SetPumpFailureStatus) deben serconsiderados también como eventos de interfaz. Las propiedades (modularizadas)a verificar son las indicadas en la Sección 6.4.2.

6.5.1.1 Verificación sin Suposiciones

En primer lugar se realizará la verificación del componente CONTROL sinningún tipo de restricción sobre el comportamiento del resto de componentes conlos que interactuan, o dicho de modo, el componente se ejecutará bajo un entornouniversal, donde el componente puede recibir/enviar cualquier evento y encualquier orden. En concreto, los eventos LevelRange y LevelRisk pueden tomarcualquier valor en cualquiera de los micropasos de ejecución.

La mayoría de las propiedades analizadas sobre el componente CONTROL nonecesitaron ninguna suposición (en el sentido de que no produjeron falsospositivos), salvo en el caso de las propiedades 17(O.13.C), 18(O.14.C),19(O.15.C) y 3(N.7.C), que produjeron un contrajemplo. Estas propiedades y suscontrajemplos se analizan en la próxima sección.

6.5.1.2 Verificación con Suposiciones Manuales

A continuación se reproducen y analizan las propiedades que produjeron uncontrajemplo en la verificación anterior, con el objetivo de establecer suposicionesque permitan detectar posibles falsos positivos.

Las dos primeras son relativas al modo de inicialización del programa de control:

17 En el modo de inicialización y una vez recibido el mensaje de inicio delprograma de control (STEAMBOILERWAITING), si se recibe un evento deWATER con nivel de agua alto (LevelRangeHigh), se debe abrir la válvulade evacuación de agua (VALVE)

WAS1(STEAMBOILERWAITING)&&ControlModes==Init &&WAS0(LevelRangeHigh) -> VALVE==1

18 En el modo de inicialización y una vez recibido el mensaje de inicio delprograma de control (STEAMBOILERWAITING), si se recibe un evento deWATER con nivel de agua bajo (LevelRangeLow), se debe enviar un eventode apertura de bombas (StartPumps) al componente ALLPUMPS

WAS1(STEAMBOILERWAITING) && ControlModes==Init&&WAS0(LevelRangeLow) -> StopPumps

Un análisis de contrajemplo producido por SPIN en ambas propiedades permitedescubrir la causa del error. Una vez que el componente CONTROL (Figura 63)entra en estado de inicialización (estado Init del proceso ControlModes), elproceso Control Init Modes quedará a la espera del mensaje


166

STEAMBOILERWAITING para proceder al llenado (StartPump), o vaciado(VALVE=1) inicial de la caldera en función de los valores medidos por elcomponente WATER. Sin embargo, y dada la forma de especificación de loseventos de interfaz (un evento para cada valor indicativo del nivel de agua,LevelRangeLow, LevelRangeMiddle y LevelRangeHigh), éstos pueden recibirse encualquier micropaso y además todos a la vez. Por tanto, en el estado anteriorpueden estar habilitadas varias transiciones y el sistema podrá reaccionar nodeterminísticamente abriendo las bombas, cuando en realidad debería de activar laválvula de evacuación debido a la presencia del evento LevelRangeHigh. Elmismo razonamiento puede aplicarse a ambas propiedades.

La situación anterior puede evitarse estableciendo como restricción del entornoque los eventos LevelRangeLow, LevelRangeMiddle y LevelRangeHigh no sereciban a la vez en un mismo instante (micropaso). En el comprobador demodelos SPIN podrán codificarse como un conjunto de reglas a evaluar en cadauno de los micropasos, de forma que ciertos eventos de interfaz tomen sus valoresen función del valor o valores de otros eventos de interfaz:

LevelRangeLow==1 -> LevelRangeHigh=0 && LevelRangeMiddle=0

LevelRangeMiddle==1 -> LevelRangeLow=0 && LevelRangeHigh=0

LevelRangeHigh==1 -> LevelRangeLow=0 && LevelRangeMiddle=0

Ejecutando de nuevo el comprobador con las suposiciones anteriores, laspropiedades 17 y 18 pasan a ser cierta. Además, el proceso se debe completar,verificando las suposiciones sobre el componente WATER. Realizado este últimopaso, las suposiciones son ciertas en WATER.

Sin embargo, y aún teniendo en cuenta el modelo del entorno anterior, laspropiedades 19 y 3 sigue siendo falsa sobre el componente WATER.

La propiedad 19 es una propiedad de seguridad que indica que una vez detectadoun posible fallo o error de medida en el componente WATER (LevelRisk), elsistema no debe responder ni abriendo ni cerrando las bombas:

19 ControlModes=Run && WAS0(LevelRisk) -> StartPump==0 &&StopPump==0

El análisis del contraejemplo producido por el verificador lleva a conclusionesparecidas al caso anterior. En cualquiera de los modos de ejecución (salvo el deinicialización y emergencia), ante la llegada del evento LevelRisk, el procesoControlModes pasaría a modo de parada de emergencia y el programa finalizaría,desactivando el resto de procesos. Sin embargo, el entorno no está lo suficientelimitado para evitar que los eventos LevelRisk y LevelRange se reciban endiferentes instantes (micropasos), por lo que podría suceder que a la vez que el


167

componente CONTROL entrase en modo de emergencia, envíase una orden deapertura o cierre a las bombas, produciendo una situación atípica y potencialmentepeligrosa.

De la misma forma que en el caso anterior, una solución pasa por indicar nuevassuposiciones (además de las anteriores). Una de ellas, obvia y razonable deacuerdo a la especificación del proceso WATER, es evitar que en un mismomicropaso se reciban los eventos de nivel de agua (LevelRange, con todos suseventos asociados High, Middle y Low) y error (LevelRisk):

LevelRisk==1 -> LevelRange=0

LevelRange==0 -> LevelRisk=0

Verificada la propiedad 19 con las nuevas suposiciones es cierta en CONTROL ylas suposiciones son ciertas también en el componente WATER

La propiedad restante, que en principio produce un falso positivo (propiedad 3), esejecutada nuevamente con todas las suposiciones anteriores y continua siendofalsa.

3 ControlRunMode==Normal && WAS0(LevelRisk)->ControlModes==EmergencyStop

La interpretación y seguimiento del contraejemplo para esta propiedad es muchomás complicado que en los casos anteriores. Básicamente, el problema detectadoes debido a un pérdida de eventos en el componente CONTROL, que no puedereaccionar en un micropaso determinado ante un evento recibido en un micropasoprevio.

La situación reproducida del contraejemplo es la siguiente: El componenteCONTROL recibe el mensaje de fin del modo de inicialización(PHYSICALUNITSREADY) para que pase a modo de ejecución. Internamente, enel primer micropaso, el proceso ControlInitMode reaccionará ante el mensajeexterno y enviará a su vez un evento de fin de inicialización al proceso de controlde los modos de ejecución (Control Modes), que cambiará al modo de ejecuciónnormal en el segundo micropaso. En esta situación y estado, el componenteCONTROL puede reaccionar a los eventos que indican el fallo en la unidad demedida (LevelRisk). Sin embargo, si LevelRisk se recibe en el primer micropaso elcomponente ControlModes no pasará a modo emergencia, ya que en ese instanteinternamente no está en el modo ejecución, sino que está en transición a modo deejecución normal, por lo que la propiedad es falsa.

Una solución para que la propiedad anterior sea cierta es “obligar” al procesoControlModes a reaccionara ante el evento LevelRisk desde cualquier estado,modificando la especificación de este proceso, incluyendo nuevas transiciones


168

desde todos los estados hasta el estado de emergencia (Emergency Stop) con lacondición LevelRisk. Sin embargo entraríamos en una contradicción respecto a laespecificación original, ya que en el modo de inicialización esta situación setratará de manera diferente.

Sin embargo, la propiedad anterior será cierta siempre y cuando se limite alentorno a que envíe el evento LevelRisk en el primer micropaso, ya que en elcontraejemplo analizado, el estado real de cambio al modo de ejecución normal seproduce en el segundo micropaso. Esta limitación se refleja con la siguienterestricción:

µP==1 -> LevelRisk=0

Tanto la propiedad 3 con esta nueva suposición, como la suposición sobreWATER, son ciertas en el componente CONTROL.

Este tipo de suposiciones que hacen referencia a valores o conjuntos de valoresconcretos de micropasos, son difíciles de obtener. Aún siendo un usuario concierto conocimiento del sistema, su especificación involucra aspectos relacionadoscon la semántica del modelo de difícil comprensión (conceptos de macro ymicropaso). Es de suponer que la solución en la mayoría de los casos antesituaciones como la comentada, fuese la de cambiar la especificación del sistemapara que la propiedad fuese cierta. Sin embargo, en muchos casos no es lasolución correcta, ya que podría suponer que se falseasen otras propiedades.

6.5.1.3 Verificación con Suposiciones Automáticas

Del mismo modo que en la sección anterior, realizaremos la verificación de laspropiedades del componente CONTROL, generando previamente las suposicionesutilizando los métodos GenInd y GenPar.

Algoritmo GenInd

La aplicación del algoritmo GenInd se basa en la generación de suposiciones apartir de una exploración exhaustiva del entorno del componente CONTROL. Deacuerdo a la partición en componentes de la Figura 60, el entorno de CONTROLestá formado por el resto de componentes (componentes ALLPUMPS, WATER ySTEAM). Por tanto, idealmente deberíamos de aplicar el algoritmo sobre elentorno formado por los tres componentes anteriores para obtener las suposicionesen los eventos de interfaz de entrada del componente CONTROL.

Sin embargo, la comunicación entre los diferentes componentes que forman elentorno de CONTROL (ALLPUMPS, WATER, STEAM) es casi nula, es decir elentorno está débilmente acoplado. Por tanto, es de esperar que las restricciones asíobtenidas no aporten información extra respecto a considerar el entorno formadopor los componentes individualmente, y además se evita generar el espacio deestados generado por la ejecución de los tres componentes.


169

Lla computación del entorno se realizará en tres pasos, generando en cada uno deellos las suposiciones derivadas de los componentes WATER, ALLPUMPS ySTEAM, respectivamente:

� Computación del entorno de CONTROL relativo al componente STEAM(suposiciones en el evento de interfaz de estado S.SteamFailureStatus)

� Computación del entorno de CONTROL relativo al componente ALLPUMPS(suposiciones en el evento de interfaz de estado S.WaterFailureStatus)

� Computación del entorno de CONTROL relativo al componente WATER(suposiciones en los eventos de interfaz LevelRangeHigh, LevelRangeLow,LevelRangeMiddle y LevelRisk, y en el evento de interfaz de estadoS.PumpSetFailureStaus.

En la Tabla 11 se muestran algunos parámetros de rendimiento de la ejecución deGenInd sobre los componentes descritos anteriormente.

Parámetro STEAM WATER ALLPUMPSMáxima Profundidad en Macropasos 3 3 10

Número de Micropasos Computados (Configuraciones) 13153 229816 160416

Tiempo Generación Espacio de Estados (seg.) 40 804 815

Número de Restricciones 2 8 3

Tiempo Generación Restricciones(seg.) <1 <1 <1

Tabla 11: CONTROL: Rendimiento de GenInd sobre diferentes entornos

Como era de esperar, el número de suposiciones obtenidas para cada uno de losentornos está directamente relacionado con el número de eventos de interfaz dedicho entorno (en el componente WATER se obtiene el mayor número desuposiciones debido a que existe un mayor número de eventos de interfaz alimitar). Como se comenta anteriormente, el rendimiento global del algoritmoestará determinado por el tamaño del componente o el espacio de estados aexplorar (en la Tabla 11 parámetros Número de Micro Pasos Computados yMáxima Profundidad en Micro Pasos), y no por el número de restriccionesobtenidas, ya que el tiempo de generación de éstas es despreciable.

En la Tabla 12 se detallan cada una de las suposiciones obtenidas con laaplicación de GenInd sobre cada uno de los entornos anteriores.


170

WATER1 LevelRangeLow== 1->LevelRangeHigh=0 && LevelRangeMiddle=0 &&

LevelRisk=0

2 LevelRangeMiddle==1->LevelRangeHigh=0&&LevelRangeLow=0&&LevelRisk=0

3 LevelRangeLow == 1->LevelRangeHigh=0 && LevelRangeMiddle=0&& LevelRisk=0

4 LevelRisk==1->LevelRangeLow=0 && LevelRangeHigh=0 &&LevelRangeMiddle=0

5 WAS0(LevelRangeLow) || WAS0(LevelRangeHigh) ||WAS0(LevelRangeMiddle)||WAS0(LeveRisk) -> LevelRangeHigh =0 && LevelRangeMiddle=0 && LevelRangeLow=0 && LevelRisk=0

6 µP≤2 -> LevelRisk=0 && LevelRangeHigh=0 &&LevelRangeMiddle=0 && LevelRangeLow=0

7 WAS0(S.LevelFailureStatus==NoFailure) &&S.LevelFailureStatus==Failure ->S.LevelFailureStatus=Failure

8 WAS0(S.LevelFailureStatus==Failure) &&S.LevelFailureStatus==NoFailure ->S.LevelFailureStatus=NoFailure

STEAM1 WAS0(S.SteamFailureStatus==NoFailure) &&

S.SteamFailureStatus==Failure-> S.SteamFailureStatus=Failure

2 WAS0(S.SteamFailureStatus==Failure) &&S.SteamFailureStatus==NoFailure ->S.SteamFailureStatus=NoFailure

ALLPUMPS1 WAS0(S.SetPumpFailureStatus==NoFailure) &&

S.SetPumpFailureStatus==Failure ->S.SetPumpFailureStatus=Failure

2 WAS0(S.SetPumpFailureStatus==Failure) &&S.SetPumpFailureStatus==NoFailure ->S.SetPumpFailureStatus=NoFailure

3 µP > 3 -> !SetPumpFailureStatus(NoFailure->Failure) &&!SetPumpFailureStatus(Failure->NoFailure)

Tabla 12: CONTROL: Restricciones obtenidas con GenInd sobre diferentes entornos

Las suposiciones obtenidas en el entorno WATER incluyen a las especificadasmanualmente en la sección anterior (señaladas en negrita en la Tabla 12). Lascuatro primeras indican restricciones relativas a los eventos de interfaz quepueden ser recibidos simultáneamente por el componente en cada uno de losmicropasos, y la quinta indica que, durante un macropaso a lo sumo únicamente serecibe un evento de interfaz. Como se verá posteriormente, esta suposición es vitalpara asegurar que no hay presencia de ciclos infinitos en la ejecución delcomponente. La sexta restricción indica que durante los dos primeros micropasos


171

no se recibirá los eventos de interfaz. Al igual que las primeras de la Tabla 12, sonimportantes para detectar falsos positivos, pero también permiten al comprobadorde modelos explorar un menor número de estados, por lo que se conseguirá unaimportante reducción en el consumo de recursos computacionales delcomprobador de modelos. Las restricciones 7 y 8 no están relacionadasdirectamente con los eventos de interfaz, sino con estados de otros procesos queno están directamente accesibles para el componente CONTROL, pero que sí haceuso de ellos en alguno de sus procesos (proceso ControlModes). Básicamenteindican que durante un macropaso solamente se ejecutará una transición en elproceso WaterFailureStatus, bien de Failure a NoFailure (suposición 7) oviceversa (suposición 8). Restricciones similares se obtienen con los componentesSTEAM y WATER (suposiciones 1y 2 para cada componente).

Verificando el componente CONTROL con el conjunto de restriccionesanteriores, todas las propiedades pasan a ser ciertas, eliminando el falso positivodetectado en la propiedad 3 del componente CONTROL con la suposición 6 delcomponente WATER.

Algoritmo GenPar

Se plantea a continuación la generación de suposiciones para el componenteCONTROL utilizando varios componentes a la vez mediante el algoritmoGenPar. Al igual que en el caso anterior, para la obtención de dichassuposiciones, idealmente deberíamos de aplicar el algoritmo GenParconjuntamente a los componentes CONTROL y al componente que representa alentorno, formado por el resto de componentes. Por la misma razón anterior (pocoacoplamiento del entorno) se hace innecesaria esta ejecución. Por tanto, seproponen tres ejecuciones del algoritmo, cada una aplicada sobre los siguientescomponentes:

� CONTROL || WATER

� CONTROL || STEAM

� CONTROL || ALLPUMPS

En la Tabla 13 se muestran los parámetros de rendimiento y número desuposiciones obtenidas para cada una de las ejecuciones anteriores. Nótese quecon la utilización de esta técnica no solamente se espera generar las suposicionespara el componente CONTROL, sino también y de forma paralela, para el entorno(otro componente, según el caso). Por tanto, se indican de forma individual eltamaño del espacio de estados y el número de restricciones generadas para elcomponente CONTROL y el entorno considerado según el caso (STEAM,WATER ó ALLPUMS). Sin embargo, en este caso únicamente son interesanteslas suposiciones generadas para el componente CONTROL, por lo que el análisisestará centrado en éstas, dejando para próximas secciones relativas a laverificación del resto de componentes el análisis de las aquí obtenidas para elcomponente en cuestión.


172

Parámetro STEAM WATER ALLPUMPSMáxima Profundidad en Macropasos 10 10 10

Número de Micropasos Computados (CONTROL) 251045 258668 259140

Número de Micropasos Computados (Componente) 10934 16768 87026

Tiempo Generación Espacio de Estados (seg.) 2084 2644 6209

Número de Restricciones (CONTROL) 3 10 2

Número de Restricciones (Componente) 2 3 9

Tiempo Generación Restricciones(seg.) <1 <1 <1

Tabla 13: CONTROL: Rendimiento de GenPar sobre diferentes entornos

Como se observa en la Tabla 13, además de las suposiciones obtenidas con elalgoritmo GenInd, se obtienen dos restricciones más a partir del componenteWATER y una en el componente STEAM, respectivamente. Para el componenteALLPUMPS se obtuvieron las mismas restricciones que con la ejecución delalgoritmo GenInd. En la Tabla 14 se detallan las nuevas restricciones obtenidas,respecto a la ejecución con GenInd.

WATER1 µP > 4 -> LevelRisk=0 && LevelRangeHigh=0 &&

LevelRangeLow=0 && LevelRangeMiddle=0

2 µP >3 -> !LevelFailureStatus(NoFailure->Failure) &&!LevelFailureStatus(Failure->NoFailure)

STEAM1 µP >3 -> !SteamFailureStatus(NoFailure->Failure) &&

!SteamFailureStatus(Failure->NoFailure)

Tabla 14: CONTROL: Nuevas suposiciones obtenidas con GenPar

En el componente WATER, la primera de ellas indica que el componenteCONTROL no recibirá los eventos de interfaz a partir del quinto micropaso. Lasegunda es relativa al estado del proceso LevelFailureStatus y representa que apartir del cuarto micropaso, no se ejecutarán transiciones en dicho proceso. Larestricción obtenida en el componente STEAM es relativa también al proceso demonitorización del estado de fallo (SteamFailureStatus), y es similar a lacomentada anteriormente en el componente WATER.

Si bien este conjunto de restricciones por sí solo no ayuda a la detección de falsospositivos (si previamente se verificó el componente CONTROL utilizando lassuposiciones generadas con GenInd), sí que parecen ser interesantes desde elpunto de vista de la optimización de la verificación, ya que reduce el número devalores que pueden tomar en cada uno de los micropasos los eventos de interfazy/o el estado de los procesos de fallo en cada componente. Dado que, en laejecución del comprobador de modelos sobre el componente CONTROL se


173

explorarán longitudes de macropaso mayores de cinco, las nuevas restriccionesevitan que se exploren aquellos estados relativos al valor “1” en cada uno de loseventos de interfaz y se “simulen” transiciones en los procesos de fallo prohibidaspor el entorno.

Nótese que, en principio, estas nuevas restricciones no podrían ser generada por elalgoritmo GenInd, ya que éste al computar los espacios de estados decomponentes de forma individual, únicamente alcanzará para los componentesWATER y STEAM una longitud máxima de macropaso de tres (Tabla 11). Sinembargo, en el algoritmo GenPar, la longitud máxima de macropaso alcanzada esmayor debido a que se considera globalmente las interacciones en amboscomponentes, y por tanto se pueden obtener restricciones para los eventos en losmicropasos computados. No sucede lo mismo en el componente ALLPUMPS(con una longitud de macropaso máxima mayor), ya que con el algoritmo GenIndse obtiene una restricción similar (Tabla 12, componente ALLPUMPS, restricción3) a las obtenidas con GenPar.

6.5.1.4 Análisis de Resultados

En esta sección se muestran y analizan los resultados obtenidos en la verificacióndel componente CONTROL considerando los diferentes métodos de obtención desuposiciones discutidos anteriormente. La verificación en todos los casos serealizó con el comprobador de modelos SPIN.

En la Tabla 15 se muestran los resultados relativos al rendimiento de SPIN en laverificación de cada de las propiedades sobre CONTROL. La primera columnaindica el número de propiedad de acuerdo a la codificación en la sección 6.4.2. Elresto de columnas indican el tiempo de usuario (en segundos) y memoria utilizada(en Mbytes) necesario para la verificación de la propiedad sin restricciones (NoRest), con las suposiciones obtenidas manualmente y con las obtenidasautomáticamente aplicando los métodos de generación GenInd y GenParrespectivamente. Los resultados numéricos se indican únicamente parapropiedades que son ciertas en el componente. En caso de producir falsospositivos se indican mediante “falsos positivos” en la propiedad correspondiente.Finalmente, se indica a modo de resumen el tiempo total de verificación empleadoen la verificación de todas las propiedades sobre el componente con los diferentesmétodos de generación de suposiciones analizados.


174

No Rest. Manual GenInd GenPar

Prop t mem t mem t mem t mem1 135 3,6 30 2,3 9 1,9 3 1,5

2 135 3,6 30 2,3 9 1,9 3 1,5

3 falso positivo falso positivo 13 2,2 5 1,8

4 135 3,6 30 2,3 9 1,9 3 1,5

5 135 3,6 30 2,3 9 1,9 3 1,5

6 196 3,9 41 2,5 12 2 5 1,7

7 154 3,6 34 2,3 10 1,9 4 1,5

8 135 3,6 30 2,3 9 1,9 3 1,5

9 135 3,6 30 2,3 9 1,9 3 1,5

10 154 3,6 34 2,3 9 1,9 4 1,5

11 154 3,6 34 2,3 10 1,9 4 1,5

12 139 3,6 30 2,3 9 1,9 3 1,5

13 178 3,8 40 2,5 12 2,1 5 1,7

14 150 3,6 35 2,3 9 1,9 4 1,5

15 139 3,6 30 2,3 9 1,9 3 1,5

16 139 3,6 30 2,3 9 1,9 3 1,5

17 falso positivo 51 3 16 2,4 4 1,5

18 falso positivo 82 3,8 27 2,9 6 1,5

19 falso positivo falso positivo 34 3,5 6 1,5

TOTAL 1943 561 229 73

Tabla 15: CONTROL: Resultados de SPIN en la verificación

Como se puede observar, el tiempo de verificación total del componentedesciende paulatinamente con la incorporación de nuevas suposiciones en laverificación. Frente a los 1.943 segundos empleados por SPIN en la verificacióndel componente bajo un entorno universal (sin restricciones), se obtieneaproximadamente un minuto si se incorporan restricciones obtenidas con elmétodo GenPar.

Igualmente, en todas las propiedades analizadas sobre el componente CONTROL,los resultados obtenidos muestran siempre una verificación más rápida y conmenos consumo de memoria empleando suposiciones obtenidas automáticamentefrente a la verificación sin suposiciones o especificando estas manualmente.

En la Figura 78 se muestra el ratio de mejora entre el tiempo de CPU y memoriaempleado por SPIN en la verificación con restricciones obtenidas con GenIndfrente a la verificación sin suposiciones (tGenInd/tNoRest y memGenInd/memNoRest) ycon restricciones manuales (tGenInd/tMan y memGenInd/memMan). Si bien, con laintroducción de suposiciones manuales, se produce un aumento del rendimientodel comprobador de modelos, este incremento se hace mayor si los entornos songenerados automáticamente. Esta ventaja en rendimiento se debe a que, engeneral, la inclusión de restricciones durante la verificación generará espacios de


175

estados a explorar más pequeños que en el caso donde las restricciones no seespecifiquen. En este caso, durante la verificación del componente, elcomprobador de modelos debe explorar todas las posibles combinaciones devalores de los eventos de interfaz del componente y en cualquier orden, por lo elespacio de estados es mayor.

Tiempo CPU

0,00

0,05

0,10

0,15

0,20

0,25

0,30

0,35

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

GenInd/NoRestGenInd/Man

Memoria

0,000,100,200,300,400,500,600,700,800,90

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

GenInd/NoRestGenInd/Man

Figura 78: CONTROL: Comparativa de rendimiento con GenInd

En la Figura 79 se muestran también los ratios de mejora en la verificación consuposiciones obtenidas con GenPar frente a las obtenidas con GenInd(GenPar/GenInd), con restricciones manuales (GenPar/Man) y verificación sinrestricciones (GenPar/NoRest). Conclusiones similares a las comentadas para elcaso de GenInd pueden formularse para este método. En este caso, la mejora deltiempo de verificación es aún mayor que en el caso de utilizar GendInd.

Nótese en la comparativa GenPar/GenInd, como con la inclusión de pocasrestricciones se puede llegar a producir una importante reducción de recursos en laverificación. Esto se debe principalmente a la “calidad” de la primera restricciónde la Tabla 14, que limita el comportamiento de todos los eventos de interfaz apartir del quinto micropaso de ejecución para todos los macropasos a explorar. Encaso del componente CONTROL esto es importante, debido a que éste puede


176

exhibir potencialmente un comportamiento infinito debido precisamente a que loseventos de nivel de agua (LevelRange) se pueden recibir en cada uno de losmicropasos. Evitando que tomen valores a partir del quinto micropaso, se reduciráel espacio de estados a explorar como indican los resultados obtenidos.

El consumo de memoria sigue la misma tendencia, aunque la mejora obtenida noes tan importante como en el caso del tiempo de verificación. La razón puede estaren los algoritmos internos de SPIN que en principio evitan la generación completadel espacio de estados mediante técnicas “on-the-fly”. Aún sin la existencia derestricciones en las variables, SPIN incorpora heurísticas de reducción del espaciode estados.

Tiempo CPU

0,000,050,100,150,200,250,300,350,400,45

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

GenPar/NoResGenPar/ManGenPar/GenInd

Memoria

0,000,100,200,300,400,500,600,700,800,90

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

GenPar/NoRestGenPar/ManGenPar/GenInd

Figura 79: CONTROL: Comparativa de rendimiento con GenPar

Por último, en la Tabla 16 se muestra, a modo de resumen, el esfuerzo deverificación en términos de tiempo del conjunto de todas las propiedades sobre elcomponente CONTROL. La columna “Propiedades” muestra el número depropiedades que se pudieron verificar sobre CONTROL sin que produjesen falsospositivos utilizando cada una de las estrategias de inclusión y generación de


177

suposiciones. La columna “Verificación” recoge el tiempo total de verificación delas propiedades ciertas (no produjeron falsos positivos). La columna “Descarga”muestra el tiempo de verificación necesario para la descarga de las suposicionesrealizadas manualmente (para el componente CONTROL, es necesario realizar ladescarga de las suposiciones manuales sobre el componente WATER). En lacolumna “Generación” se indican los tiempos de ejecución obtenidos aplicandolas dos técnicas de generación automática de suposiciones. Dado que la mayoríade las suposiciones se obtienen a partir del componente WATER (debido a sumayor acoplamiento), en la tabla se considera únicamente el tiempo de generaciónde este componente (en el caso de GenInd) y el tiempo de generación de entornosparalelos con los componentes CONTROL y WATER (para GenPar). Finalmenteen la columna “TOTAL” se resume el tiempo total real necesario para laverificación utilizando cada una de las estrategias de inclusión de suposiciones.

Propiedades Verificación Descarga Generación TOTAL

NoRest 15 1943 1943

Manual 17 561 664 1225

GenInd 19 229 804 1033

GenPar 19 73 2664 2737

Tabla 16: CONTROL: Resumen de resultados

Desde un punto de vista cuantitativo, la verificación del componente CONTROLcon las suposiciones obtenidas de forma paralela con el componente WATER(GenPar), es la ofrece un mayor tiempo total de verificación, debido al tiempoempleado en la generación de las suposiciones, que contemplará la computación,no solamente del entorno de CONTROL, sino también del componente WATER.Como veremos posteriormente, el componente WATER se puede considerarcomplejo desde el punto de vista de su exploración exhaustiva, ya que estáformado por eventos y procesos discretos que generarán un espacio de estadosgrande. Sin embargo, una vez generado el entorno del componente, el tiempo deverificación (columna Verificación) es muy inferior al resto de estrategias. Estaapreciación puede ser interesante en el caso de que se especificasen nuevaspropiedades sobre el componente CONTROL. Desde este punto de vista, no seríanecesario volver a ejecutar el algoritmo de generación paralelo, sino queúnicamente se verificarían las propiedades sobre el componente con lassuposiciones obtenidas previamente. Lo mismo es aplicable si se utilizase elmétodo GenInd.

Por el contrario, la verificación con los entornos obtenidos con el algoritmoGenInd es el que produce un tiempo menor de verificación. El menor tiempo degeneración de suposiciones con respecto a GenPar es debido a que éste exploraúnicamente el entorno de CONTROL (componente WATER). Con respecto a laverificación con suposiciones manuales, aunque el tiempo de generación desuposiciones es similar al tiempo de descarga de las suposiciones manuales (804segundos y 828 segundos, respectivamente), el tiempo de verificación (columna


178

Verificación) es inferior debido al mayor número de restricciones obtenidas y a lacalidad de ellas. Lo más costoso es el cálculo del entorno, pero éste solamente secomputa una sola vez. De este modo, se facilita la verificación interactiva, quepermitirá incluir nuevas propiedades a verificar, sin la necesidad de recalcular elentorno, debido a que éste es independiente de la propiedad a verificar.

Indicar también que, en la Tabla 16 no se detalla como parte del tiempo total de laverificación con suposiciones manuales el tiempo necesario para especificar éstas.Si bien este tiempo no es cuantificable, ya que depende de la “habilidad” yconocimiento del analista para especificar el entorno, sí supone una desventajaclara respecto a los métodos automáticos de generación de entornos.

Por otra parte, únicamente con los métodos de generación automática desuposiciones fue posible realizar la verificación de la totalidad de las propiedadessin que éstas produjesen falsos positivos. Con suposiciones manuales seprodujeron dos falsos positivos, y sin suposiciones cuatro.

6.5.2 Componente ALL PUMPS

Según la partición en componentes mostrada en la Figura 77, este componente esel encargado del envío de las órdenes de apertura y cierre a las bombas en funciónde los niveles de agua medidos por la unidad física correspondiente, así como delmantenimiento del estado (Fallo/No Fallo) de las bombas y de sus controladoresrespectivos (recuérdese que, de acuerdo a la especificación original, cada bombasy controlador respectivo se deben considerar como dispositivos independientes).

Internamente, y aunque la especificación operacional de la Sección 6.2.2 muestrael comportamiento de una única bomba, el sistema físicamente está formado porcuatro bombas (cada una además con su propio controlador), de modo que loseventos de interfaz StartPumps y StopPumps recibidos del componenteCONTROL iniciarán la apertura/cierre de cada una de las bombas (Figura 65,proceso AllPumpStatus). El componente no estará activo hasta que el componenteCONTROL envié el evento de activación correspondiente (E.AllPumps), por loque este evento también debe ser considerado como evento de interfaz. Ademásde estos eventos de interfaz, el componente ALLPUMPS reaccionará ante losmensajes procedentes de la unidad física correspondiente, y enviará, entre otros,los mensajes de apertura y cierre (OPEN/CLOSE PUMP) a cada una de lasbombas físicas (Figura 64).

Dado que el componente está formado por cuatro instancias (una por cadabomba), se plantea la verificación desde un punto de vista incremental,considerando inicialmente el componente formado por una única bomba, paraposteriormente ir añadiendo cada una de las bombas restantes.

Las propiedades a verificar sobre el componente son las indicadas en la Sección6.4.2. Al igual que en la especificación operacional, las propiedades estánreferidas al componente formado por una única bomba, por lo que deberán sermodificadas cuando el componente esté formado por más de una bomba.


179

La verificación de este componente se realizará sin suposiciones, con suposicionesestablecidas manualmente y con suposiciones obtenidas con los algoritmosGenInd y GenPar.

6.5.2.1 Verificación de una Bomba sin Suposiciones

De forma similar a la verificación del componente CONTROL descrito en lasección anterior, la mayoría de las propiedades a verificar en ALLPUMPS nonecesitaron ninguna suposición del entorno del componente. Dicho de otra forma,la mayoría de las propiedades fueron ciertas sobre el entorno universal.Únicamente se detectó como propiedad falsa la siguiente propiedad de seguridad:

8 Si una bomba está en estado de fallo, no enviará mensajes a las unidadesfísicas

PumpSetFailureStatus!=NoFailure -> OPENPUMP==0 &&CLOSEPUMP==0

La falsedad de la anterior propiedad no deja de ser una sorpresa a la vista de laespecificación operacional del proceso PumpStatus: la activación del cierre yapertura de la bomba (procesos PumpClosing y PumpOpening) en las transicionesrespectivas en PumpStatus, están guardadas por la condiciónPumpSetFailureStaus!=NoFailure (Figura 67). Por tanto, si el procesoPumpSetFailureStatus está en un estado distinto a NoFailure, no se ejecutarán lastransiciones respectivas en PumpStatus y como consecuencia tampoco se enviaránlas órdenes de apertura y/o cierre a las bombas. La extraña causa del error sepuede determinar analizando el último macropaso del contrajemplo producido porSPIN.

En dicho macropaso, se recibe de las unidades físicas un mensaje que indica unfallo en la unidad de control de la bomba (PUMPCONTROLSTATEOFF). En elprimer micropaso, el proceso PumpOpening (que en el macropaso anterior habíaenviado un mensaje de apertura de la bomba) reacciona ante el mensaje, quedandodesactivado y enviando el evento PumpControlChangesState. En ese mismomicropaso se recibe del componente CONTROL un evento de inicio de cierre dela bomba (StopPump) debido a un nivel alto de agua medido por el detector denivel. Como consecuencia, en el segundo micropaso el procesoPumpControlFailureStatus cambia al estado de fallo (Failure). Dado que, elproceso PumpStatus al inicio del macropaso se encontraba en estado ON, debido aque previamente se había ordenado la apertura de la bomba, ejecutará la transiciónde ON a OFF (la bomba todavía está en el estado NoFailure) e iniciará el cierre dela bomba. En el siguiente micropaso, el proceso PumpSetFailureStatus cambia aestado de fallo y termina el macropaso. Por tanto, la propiedad es falsa, ya que seenvía un evento de cierre estando la bomba o su controlador en estado de fallo.

Como se puede observar, tanto la interpretación, como la búsqueda de la fuentedel error anterior, no es una tarea fácil. En él se hace referencia a aspectos muy


180

relacionados con la semántica del sistema que no resultan triviales. Dado que, elresto de propiedades son ciertas sobre la misma especificación operacional, pareceque la causa del error puede no estar en modelo operacional del sistema, sino enuna incorrecta especificación del entorno del componente. Como se comentó a lolargo de esta tesis, la estrategia típica en estos caso consiste en aplicar técnicas de“prueba y error”, especificando incremental e interactivamente entornos cada vezmás restrictivos hasta que la propiedad sea cierta (en caso de que pueda serlo).Esto se aborda en la próxima sección.

6.5.2.2 Verificación de una Bomba con Suposiciones Manuales

A la vista del análisis del contrajemplo anterior, se plantearán un conjunto desuposiciones para limitar el entorno del componente, con el objetivo de eliminar elerror descrito.

Al igual que en el componente CONTROL, un conjunto de restricciones obviasbasadas en la incompatibilidad en la llegada de los eventos de interfaz alcomponente ALLPUMPS, se indican a continuación:

StartPumps==1 -> StopPumps=0

StopPumps==1 -> StartPumps=0

E.AllPumps==1 -> D.AllPumps=0

D.AllPumps==1 -> E.AllPumps=0

Tabla 17 : ALLPUMPS: Suposiciones Manuales

Las restricciones de la Tabla 17 indican que, por una parte, no se recibirán en unmismo micropaso los eventos de interfaz StartPumps y StopPumps, y por otra,los eventos de activación (que también son de interfaz) E.AllPump y D.AllPump.La descarga de estas suposiciones sobre el componente CONTROL son ciertas.

Sin embargo, realizando una verificación de regresión sobre el componenteALLPUMPS con las suposiciones anteriores, la propiedad 8 sigue siendo falsa,produciendo un contraejemplo similar a la verificación sin suposiciones (secciónanterior). Por tanto es necesario limitar el entorno con nuevas suposiciones quecomplementen a las de la Tabla 17.

Dado que, la especificación de suposiciones adicionales puede ser una tarea difícilal necesitar un conocimiento más avanzado del sistema, aplicaremos, en lapróxima sección, las técnicas de generación de suposiciones automáticas.

6.5.2.3 Verificación de una Bomba con Suposiciones Automáticas

Algoritmo GenInd

Para la obtención de las suposiciones automáticas sobre el componenteALLPUMPS, se debe ejecutar el algoritmo GendInd sobre el componente


181

CONTROL, que es el único con el que comparte eventos de interfaz (StartPumps,StopPumps, E.AllPumps y D.AllPumps). Dado que en la Sección 6.5.1 se computóel entorno del componente CONTROL, y que el algoritmo GenInd deberá tenerloen cuenta para realizar la exploración de las configuraciones, se pueden seguir lassiguientes estrategias:

� Aplicación directa sobre CONTROL (entorno universal)

� Utilización del entorno computado en CONTROL (entorno calculado, Sección6.5.1)

La primera de ellas explorará todas las posibles configuraciones del componenteconsiderando un entorno libre (eventos LevelRange y LevelRisk y eventos deestado de procesos SteamFailureStatus y LevelFailureStatus). La segunda, utilizalos entornos calculados para el componente CONTROL en la generación delconjunto de configuraciones. La segunda de las opciones parece más eficiente altener que explorar un número más reducido de configuraciones, y a su vez, másrealista, ya que las configuraciones y restricciones obtenidas tendrán en cuenta, asu vez, un entorno más limitado.

En la Tabla 18 se muestran algunos parámetros de rendimiento del algoritmoGenInd aplicado sobre el componente CONTROL utilizando las dos estrategiasanteriores:

Entorno Universal Entorno Calculado

Máxima Profundidad en Macropasos3 10 7

Número de Micropasos Computados(Configuraciones)

102912 35078

Tiempo Generación Espacio de Estados 435,8 139,3

Número de Restricciones 8 9

Tiempo Generación Restricciones < 1 seg. < 1 seg.

Tabla 18: ALLPUMPS: Rendimiento de GendInd sobre el componente CONTROL

Como era de esperar, la utilización de GenInd con los entornos calculados delcomponente CONTROL es más ventajosa tanto en términos de espacio como dememoria. Además, se generó una restricción más que si considerásemos elentorno universal en CONTROL. En este caso, el componente CONTROL puedeexhibir un comportamiento infinito debido a la aparición en cada uno de losmicropaso de los eventos LevelRangeLow, LevelRangeMiddle y LevelRangeLow,que a su vez enviarán los eventos StartPumps y StopPumps. Por ello no es posibleestablecer ninguna restricción para estos eventos. Sin embargo, si la exploracióndel espacio de estados del componente CONTROL se realiza utilizando lasrestricciones computadas para él (Tabla 12), todos los eventos estarán limitados

3 La ejecución de GenInd suponiendo un entorno universal generará una ejecución infinita debidoa que los eventos LevelRange y LevelRisk pueden aparecer infinitamente en un mismo macropaso.En el experimento, se establece como límite máximo de micropasos 10.


182

en alguno de sus micropasos, por lo que el componente no exhibirá uncomportamiento infinito, sino que la longitud máxima de macropaso alcanzada esde siete. La restricción generada en este caso, y no detectada considerando elentorno universal, es la número 9 de la Tabla 19.

En la Tabla 19 se muestra el conjunto de restricciones obtenidas aplicando GenIndal componente CONTROL utilizando el entorno calculado en la sección anterior.Se indican en negrita las especificadas manualmente en la sección anterior.

Nº Restricción1 StartPumps==1 || E.AllPumps==1-> StopPumps=0

2 StopPumps==1 || E.AllPumps==1 -> StartPumps=0

3 E.AllPumps==1 -> D.AllPumps=0

4 D.AllPumps==1 || StartPumps==1 || StopPumps==1 -> E.AllPumps=0

5 µP==1 -> StopPumps=0 && StartPumps==0

6 µP>1 -> E.AllPumps=0

7 WAS0(StopPumps) || WAS0(StartPumps) -> StartPumps=0 &&StopPumps=0

8 WAS0(E.AllPumps) || WAS0(D.AllPump) -> E.AllPump=0 &&D.AllPumps=0

9 µP>5 -> StartPumps=0 && StopPumps=0 && D.AllPumps==0

Tabla 19: ALLPUMPS: Restricciones obtenidas con GenInd sobre CONTROL

Todas suposiciones establecidas manualmente en la sección anterior estánincluidas en las generadas automáticamente con GenInd (restricciones 1, 2, 3 y 4).Además de la incompatibilidad en la recepción en los micropasos de los eventosStartPumps y StopPumps, ésta se extiende también al evento de interfazE.AllPumps (restricciones 1, 2 y 4). En conjunto, el entorno computado indica quenunca se recibirán simultáneamente los eventos StartPumps, StopPumps yE.AllPumps.

Las restricciones 5 y 6 de la Tabla 19 indican además que los eventos StopPumpsy StartPumps no se reciben en el primer micropaso, y que el evento de activaciónE.AllPumps, sí se recibe es únicamente en el primer micropaso. La suposiciones 7y 8 muestran que, a lo sumo, en un macropaso solamente se recibirán un evento deinicio de apertura/cierre (StartPumps o StopPumps) y un evento deactivación/desactivación (E.AllPumps o D.AllPumps). Al igual que en lassuposiciones obtenidas para CONTROL, estas restricciones nos permitirándetectar situaciones potenciales de error en la verificación de ciertos tipos depropiedades de vivacidad (Sección 6.5.4). La última restricción limita la recepciónen el componente ALLPUMS de los eventos de interfaz StartPumps, StopPumps yD.AllPumps hasta el cuarto micropaso. A partir de ese micropaso, para todos losmacropasos, no se recibirán estos eventos.

Con este conjunto de restricciones obtenidas automáticamente, se realizanuevamente la verificación del conjunto de propiedades del componente


183

ALLPUMPS. Todas las propiedades son ciertas, eliminado de este modo el “falsopositivo” obtenido con las suposiciones manuales en la propiedad 8. De acuerdo alcontrajemplo obtenido en la sección anterior, se falsificaba la propiedad debido aque, si en el primer micropaso el componente ALLPUMPS recibía delcomponente CONTROL el evento StopPumps, aún estando el controlador de labomba en estado de fallo (PUMPCONTROLSTATEOFF), se emitía la orden decierre CLOSEPUMP falseando la propiedad.

Esto es debido a que el proceso PumpStatus realmente detecta el fallo delcontrolador en el cuarto micropaso (en el primer micropaso el procesoPumpOpening detecta el fallo del controlador, en el segundo el procesoPumpControlFailureStatus cambia al estado de fallo y en el tercero el procesoPumpSetFailureStatus cambia también al estado de fallo). Si en el primermicropaso se recibe un evento de inicio de cierre StopPumps, el procesoAllPumpStatus emitirá a su vez el evento de cierre a la bomba correspondiente(StopPump) en el segundo micropaso, y en el tercer micropaso el procesoPumpStatus activará el cierre de la bomba, ya que en ese instante el procesoSetPumpFailureStatus aún no está en el estado de fallo. Sin embargo, con larestricción obtenida que indica que en el primer micropaso no se recibe el eventode inicio de cierre, se resuelve el problema anterior, ya que “retrasa” un micropasola recepción de este evento de interfaz, y el proceso PumpStatus ya detecta el falloen la bomba, no emitiendo, por tanto, la activación del proceso de cierre.

Algoritmo GenPar

El entorno del componente ALLPUMPS está formado únicamente por elcomponente CONTROL, por lo que únicamente existe la posibilidad de ejecuciónde GenPar en los componentes CONTROL y ALLPUMPS. La ejecución delalgoritmo sin considerar el entorno calculado (entorno universal) fue realizadapreviamente en la verificación modular del componente CONTROL (Sección6.5.1) y los resultados de su ejecución y las restricciones obtenidas se muestran enla Tabla 13 (columna ALLPUMPS).

Se realiza a continaución el mismo experimento, pero considerando el entornocalculado previamente para el componente CONTROL. En la Tabla 20 semuestran los resultados de dicha ejecución.

Máxima Profundidad en Macropasos 8

Número de Micropasos Computados (ALLPUMPS) 87026

Número de Micropasos Computados (CONTROL) 99940

Tiempo Generación Espacio de Estados (seg.) 1901

Número de Restricciones (CONTROL) 1

Número de Restricciones (Componente) 9

Tiempo Generación Restricciones(seg.) <1

Tabla 20: ALLPUMPS: Rendimiento de GenPar sobre ALLPUMPS y CONTROL


184

Comparando ambas ejecuciones en términos de rendimiento (con/sin entornocalculado, Tabla 20 frente a Tabla 13, columna ALLPUMPS), es fácilmenteobservable las ventajas de la generación con el entorno calculado. Sin embargo, elnúmero de restricciones generadas es el mismo, y además en ambos casos soniguales a las obtenidas con la aplicación del algoritmo GenInd a amboscomponentes.

Por tanto, la aplicación de GenPar en este caso no aporta nuevas restricciones quepreviamente no hayan sido conseguidas por otro método (en concreto GenInd).Sin embargo, los tiempos necesarios para la generación de las suposiciones sonmás elevados que en la caso anterior.


Para mostrar la mejora de rendimiento y la detección de falsos positivos obtenidoscon los métodos de generación de suposiciones, se realiza la verificación delcomponente ALLPUMPS (1 bomba).

En la Tabla 21 se muestran los datos obtenidos de SPIN en términos de tiempo (t)y memoria (mem) para cada una de las propiedades del componente ALLPUMPS,considerando la verificación sin restricciones (NoRest), con suposicionesespecificadas manualmente (Manual) y con restricciones generadasautomáticamente (GenInd). No se considera la verificación con las suposicionesobtenidas a partir de GenPar, porque en este caso son las mismas que lasobtenidas con GenInd. Las propiedades que proporcionaron falsos negativos seespecifican con “falso positivo”.


185

NoRest Manual GenInd

Prop t mem t mem t mem1 4,5 9,5 2 6,3 0,5 2,1

2 4,5 9,5 2 6,3 0,5 2,1

3 4,5 9,5 2 6,3 0,5 2,1

4 4,5 9,5 2 6,3 0,5 2,1

5 4,5 9,5 2 6,3 0,5 2,1

6 4,5 9,5 2 6,3 0,5 2,1

7 4,5 9,5 2 6,3 0,5 2,1

8 falso positivo falso positivo 0,5 2,1

9 4,5 9,5 2 6,3 0,5 2,1

10 7,8 9,6 3,5 6,4 0,6 2,1

11 7,8 9,6 3,5 6,4 0,6 2,1

12 7,8 9,6 3,5 6,4 0,6 2,1

13 4,5 9,5 2 6,3 0,5 2,1

14 4,5 9,5 2 6,3 0,5 2,1

15 4,5 9,5 2 6,3 0,6 2,1

16 7 9,6 3,2 6,4 0,9 2,2

17 7 9,6 3,2 6,4 0,9 2,2

18 28,3 11 14,2 7,2 2 2,4

19 9,6 9,6 3,2 3,2 0,7 2,1

20 9,6 9,6 3,2 6,4 0,7 2,1

TOTAL 134,4 59,5 13,1

Tabla 21: ALLPUMPS: Resultados de SPIN en la verificación

Un primer análisis de los resultados mostrados en la Tabla 21 muestran que laverificación con suposiciones obtenidas automáticamente es más rápida y ocupamenos memoria que con las suposiciones especificadas manualmente. Además esposible la eliminación del falso negativo de la propiedad 8.

Aunque, el tiempo de verificación no es lo suficientemente elevado paraestablecer conclusiones categóricas sobre la mejora obtenida con los métodosautomáticos, si nos sirve como indicador de las mejoras a obtener cuando seincorporen al componente nuevas bombas.

En el gráfico de la Figura 80 se muestra el ratio de mejora entre el tiempo deCPU y memoria empleado por SPIN en la verificación con restricciones obtenidascon GenInd frente a la verificación sin suposiciones (GenInd/NoRest) y conrestricciones manuales (GenInd/Man).


186

Tiempo CPU

0,00

0,05

0,10

0,15

0,20

0,25

0,30

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

GenInd/NoRest

GenInd/Man

Memoria

0,000,050,100,150,200,250,300,350,40

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

GenInd/NoRest

GenInd/Man

Figura 80: ALLPUMPS (1 bomba): Comparativa de rendimiento

En todas las propiedades, los entornos automáticos producen mejoresrendimientos en la verificación, tanto en términos de espacio como de memoria.Como en caso del componente CONTROL, esta ventaja en rendimiento es debidaa que la inclusión de restricciones durante la verificación generará espacios deestados a explorar más pequeños que en el caso donde las restricciones no seespecifiquen. Además, aunque no está reflejado en la Figura 80, únicamente conlas suposiciones automáticas es posible la detección de falsos positivos en laspropiedades a verificar. Si bien esta ventaja no se puede cuantificar,cualitativamente es muy importante.

Finalmente, en la Tabla 22 se muestra un resumen de los tiempos totales deverificación para todas las propiedades en el componente ALLPUMPS con losdiferentes métodos analizados. En la columna “Propiedades” se indica el númerode propiedades que pueden ser verificadas sin producir falsos positivos. Lacolumna “Verificación” muestra el tiempo total de verificación empleado porSPIN en todas las propiedades y la columna “Descarga” el tiempo de verificaciónde las suposiciones manuales. En la columna “Generación” se detallan los tiemposobtenidos en la generación de los entornos empleados en los métodos GenInd yGenPar.


187


NoRest 19 134,4 134,8

Man 19 59,5 827,6 887,1

GenInd 20 13,1 139,3 152,4

GenPar 20 13,1 1901 1914,1

Tabla 22: ALLPUMPS (1 bomba): Resumen de resultados

El menor esfuerzo de verificación se consigue en la verificación de laspropiedades sin establecer ninguna restricción del entorno. Sin embargo, no esposible verificarlas todas debido a la presencia de falsos positivos. Desde estepunto de vista, el método más adecuado es el proporcionado por el algoritmoGenInd, donde, aunque el tiempo total de verificación es ligeramente superior alcaso de verificación sin restricciones, es posible verificar el componente en sutotalidad. Por los resultados obtenidos, el método GenPar parece que no esadecuado para este caso, debido al tiempo empleado en la generación de lassuposiciones. Además, obtiene las mismas que con el algoritmo GenInd.

6.5.2.5 Verificación de dos Bombas

Realizaremos ahora la verificación del componente ALLPUMPS peroconsiderando el componente formado por dos bombas (Figura 81).

PPump 2

PPump 1

PAll Pump Failure

Status

PAll Pump Status

PUMP CONTROL FAILURE 1

PUMP CONTROL REPAIRED ACK 1

OPEN PUMP 1

CLOSE PUMP 1PUMP FAILURE ACK 1

PUMP CONTROL REPAIRED 1

PUMP STATE ON/OFF 1

PUMP CONTROL STATE ON/OFF 1

CLOSE PUMP 2

OPEN PUMP 2

PUMP CONTROL REPAIRED ACK 2

PUMP CONTROL FAILURE 2

PUMP CONTROL STATE ON/OFF 2

PUMP STATE ON/OFF 2

PUMP CONTROL REPAIRED 2

PUMP FAILURE ACK 2

StopPump 2StartPump 2

StopPump 1

StartPump 1

Stop Pumps

Start Pumps

Figura 81: ALLPUMPS (2 bombas): Diagrama de subsistema

El modelo operacional es igual al mostrado originalmente en Figura 64, pero elproceso múltiple que representa a cada una de las bombas se ha instanciado


188

(replicando los eventos internos y externos) con un proceso para cada una de lasbombas. La especificación de cada bomba es la mostrada en la Figura 67.

De igual manera, es necesario reformular cada una de las propiedades sobre elcomponente ALLPUMPS especificadas en 6.4.2. Por ejemplo, la propiedad 4 parael componente con una bomba:

PumpOpening==Started&&PUMPSTATEOFF ->PumpSetFailureStatus!=NoFailure

se transformará en las siguientes:

PumpOpening_1==Started&&PUMPSTATEOFF_1 ->PumpSetFailureStatus_1!=NoFailure &&

PumpOpening_2==Started&&PUMPSTATEOFF_2 ->PumpSetFailureStatus_2!=NoFailure

Obviamente, aunque esta transformación pueda ser vista como una duplicacióndel modelo declarativo, y por tanto, en vez de considerar veinte propiedades seconsideren cuarenta, internamente se traducirán a SPIN como una única propiedadformada por dos conjunciones de implicaciones. Lógicamente es equivalente ypermite reducir el tiempo de verificación.

Según la partición inicial realizada en componentes (Figura 77), donde el entornodel componente ALLPUMS es independiente del número de bombas de lacaldera, para la verificación del componente con dos bombas se puede utilizar elentorno calculado para el componente con una bomba. Por tanto, realizaremos laverificación del componente con los mismos entornos computados con GenInd enla verificación del componente con una bomba. No se consideran las suposicionesgeneradas con GenPar debido a que, por una parte, implica la exploración delcomponente ALLPUMPS con dos bombas, y por tanto es de esperar unaexplosión de estados, y por otra, basándose en que los resultados del algoritmoGenPar no aportaron restricciones adicionales a las obtenidas con GenInd, estambién de esperar el mismo resultado para el caso del componente con dosbombas.


En la Tabla 23 se muestra los resultados proporcionados por SPIN en laverificación de todas las propiedades sobre el componente ALLPUMPS con dosbombas, con las diferentes estrategias de generación de entornos. Al igual que enel resto de modelos anteriores, las celdas etiquetadas con “falso positivo” indicanun resultado falso en la verificación (falso positivo) de una propiedad.


189

NoRest Manual GenInd

Prop t mem t mem t mem1 8032 177 5052 164 524 147

2 8508 178 5070 164 543 147

3 8018 177 4918 164 519 147

4 8013 177 4916 164 520 147

5 8004 177 5035 164 516 147

6 8044 177 4826 164 520 147

7 8110 177 4907 164 521 147

8 falso positivo falso positivo 535 147

9 8512 178 5045 164 544 147

10 24130 224 13265 192 591 148

11 24597 224 13275 193 591 148

12 23778 224 13275 193 599 148

13 8062 177 4828 164 519 147

14 8054 177 4901 164 523 147

15 8520 178 4834 164 538 147

16 16887 211 9492 188 1645 150

17 14486 194 7543 175 941 148

18 out of mem out of mem 7927 168

19 25030 208 14734 181 532 146

20 27259 230 15171 182 743 148

TOTAL 246044 141087 19891

Tabla 23: ALLPUMPS (2 bombas): Resultados de SPIN en la verificación

Cualitativamente, se obtienen los mismos resultados en términos de verificacionespositivas y negativas (falsos positivos) que en el caso del componente con unabomba, salvo la propiedad 18, donde no es posible su verificación consuposiciones manuales y automáticas debido a que SPIN proporciona un resultadode memoria insuficiente (explosión de estados, “out of memory”). Sin embargo, yaunque con un tiempo de verificación elevado (aproximadamente dos horas), esposible su verificación con las suposiciones generadas automáticamente, debido ala limitación que proporcionan en el número de estados que deben ser explorados.Para este caso y considerando el tiempo total de verificación del componente, lasmejoras son más evidentes que en caso del componente con una bomba. Mientrasla verificación del componente sin restricciones tarda aproximadamente 68 horas,la verificación con restricciones manuales reduce el tiempo a 59 horas. En el casode utilización de restricciones automáticas, el tiempo total de verificación es deaproximadamente 5 horas.

En la Figura 82 se muestra el ratio de mejora en los experimentos de verificacióncon los métodos de generación de suposiciones.


190

Tiempo CPU

0,00

0,10

0,20

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

GenInd/NoRest

GenInd/Man

Memoria

0,000,100,200,300,400,500,600,700,800,901,00

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

GenInd/NoRest

GenInd/Man

Figura 82: ALLPUMPS (2 bombas): Comparativa de rendimiento

Todas las propiedades verificadas produjeron mejores resultados con lassuposiciones generadas automáticamente frente a las suposiciones manuales. Lasmejoras son espectaculares en el caso del tiempo de verificación (ratio siempreinferior a 0,1 respecto a la verificación sin suposiciones e inferior a 0,2 respecto ala verificación con las suposiciones manuales). Para la memoria consumida por elverificador, también las mejoras son importantes (ratio siempre inferior a 1), peroen menor medida que en el tiempo de verificación, y también menores en mediaque las conseguidas en el caso del componente con una bomba (Figura 80). Aúnsiendo el espacio de estados a explorar menor, SPIN todavía necesita una cantidadimportante para realizar la verificación. La razón del porqué en este caso lareducción de memoria no sigue la misma proporción que el tiempo deverificación, no está clara, y es necesario una mayor experimentación conmodelos de tamaño medio. Una posible explicación puede estar en los algoritmosde generación del espacio de estados de SPIN.

Por otra parte, este caso permite mostrar la complejidad de la comprobación demodelos en la verificación de sistemas de tamaño medio. La inclusión de unanueva bomba (con un tamaño individual no excesivo), origina un aumentoexponencial en el consumo de recursos en la verificación del sistema. Sirva comoejemplo el tiempo de verificación, donde para la propiedad 10 en el componente


191

con una bomba se verifica en 7,8 segundos y en el componente con dos bombasnecesita aproximadamente 6 horas.

Finalmente, y también como en el resto de los componentes anteriores, se muestraen la Tabla 24 el esfuerzo global (en segundos) de la verificación completa delcomponente.


NoRest 18 246044 246044

Man 18 141087 827 141914

GenInd 20 19891 139 20030

Tabla 24: ALLPUMPS (2 bombas): Resumen de resultados

En términos absolutos, la verificación completa del componente ALLPUMPS condos bombas necesita aproximadamente 68 horas y 39 horas sin la inclusión derestricciones y con restricciones manuales, respectivamente. Incorporando en elsistema las suposiciones generadas automáticamente (cuyo tiempo de generaciónes prácticamente despreciable) es posible realizar la verificación del sistema en 5horas, y además y muy importante, se pueden verificar la totalidad de requisitosespecificados. Estos resultados serán mejores cuanto mayor sea el número depropiedades a verificar.

6.5.2.7 Verificación del resto de bombas

Siguiendo el enfoque incremental presentado al inicio de la verificación delcomponente ALLPUMPS, el paso siguiente sería incorporar una nueva bomba alcomponente.

Como es de esperar a tenor de los resultados obtenidos en la verificación delcomponente con dos bombas, la verificación de cualquiera de las propiedades ycon cualquier método de generación de suposiciones produce en SPIN unaexplosión de estados, por lo que estrictamente hablado no se puede dar ningúnresultado de verificación en un sentido u otro.

Básicamente, se puede considerar el componente ALLPUMPS como uncomponente parametrizado por el número de bombas, donde la inclusión deprocesos correspondientes a cada bomba no afectarán, en principio, alcomportamiento global del sistema, salvo en tamaño y número de mensajesemitidos y recibidos desde/hacia las unidades físicas. Efectivamente, y de acuerdoa la especificación operacional, cada una de las bombas tiene un comportamientoindependiente en el componente ALLPUMPS, en el sentido que los eventos decada una de las bombas no están relacionados entre sí salvo, posiblemente, en elinstante en que son activados. Por ejemplo, la bomba i y la bomba j pueden recibirlos eventos de inicio de apertura StartPump i y StartPump j, y cada una de ellasrealizará la apertura en función de su estado de control propio y de los mensajes,también propios para cada bomba, que reciben de la unidad física. Dicho de otro


192

modo, y como se deduce de la especificación original del sistema, el estado de unabomba no dependerá del estado de cualquier otra. Posteriormente, en la Sección6.5.5 se discuten otras particiones posibles en componentes.

Debido a la independencia anterior y a los resultados obtenidos en los casos deuna y dos bombas, inductivamente se pueden extrapolar los resultados obtenidospara el caso de tres y cuatro bombas. Es decir, sin la inclusión de suposiciones ocon las especificadas manualmente, la propiedad 8 produciría un falsos positivo,mientras que todas las propiedades serían ciertas con la inclusión de lassuposiciones generadas automáticamente.

6.5.3 Componentes WATER y STEAM

Tanto el componente WATER (Figura 69) como el componente STEAM (Figura73), son componentes que tienen un entorno de entrada reducido formadoúnicamente por los eventos de activación procedentes del componenteCONTROL, E.Water y E.Steam (además de los procedentes de las unidadesfísicas).

Debido a ello es de esperar que los resultados de la verificación del sistema seansimilares en el caso de realizarla sin suposiciones del entorno y con suposiciones(bien especificadas manualmente o generadas automáticamente).

En el componente WATER todas las propiedades verificadas (Sección 6.4.2) sonciertas, por lo que en principio no son necesarias suposiciones del entorno paraeliminar los falsos positivos. Sin embargo, se generarán automáticamente paracomprobar el rendimiento del verificador con y sin suposiciones.

Con el algoritmo GenInd sobre el componente CONTROL (recuérdese que estamisma ejecución se realizó para el computo del entorno de ALLPUMPS, por loque los resultados son los mostrados en la Tabla 18, salvo el número derestricciones) se obtuvieron las suposiciones siguientes:

µP>1 -> E.Water=0

WAS0(E.Water) -> E.Water=0

La primera suposición indica que el evento de activación E.Water, si se recibe, esúnicamente en el primer micropaso. La segunda es una suposición redundante, yaque muestra que si durante un macropaso se recibe un evento de activación, no sevuelve a recibir en ese mismo macropaso. Dado que, únicamente el evento deactivación se puede recibir en el primer micropaso (suposición primera), seasegura que no se recibirá en otro micropaso, por lo que la segunda suposición noaporta información adicional.

Con el algoritmo GenPar (los resultados de su ejecución figuran en la Tabla 13),además se generó la restricción:


193

WAS0(LevelRangeHigh) || WAS0(LevelRangeMiddle) ||WAS0(LevelRangeLow) || WAS0(LevelRangeLow) -> E.Water=0

Esta nueva restricción indica que, si previamente el componente WATER envíacualquier evento al componente CONTROL, éste no enviará durante el mismomacropaso el evento de activación. De nuevo, esta restricción, es redundante conrespecto a las obtenidas anteriormente. De acuerdo a otras suposicionesgeneradas, los eventos de interfaz de entrada al componente CONTROL(LevelRange y LevelRisk) no se envían en los dos primeros micropasos, por lo quela suposición evitaría como poco la recepción de E.Water en el tercer micropaso.Sin embargo, la primera suposición generada automáticamente indica que siempreel valor de E.Water es 0 a partir del segundo micropaso.

Por tanto, la aplicación de métodos automáticos únicamente aporta una restricciónal evento de interfaz de WATER. Sin embargo, realizaremos los experimentos deverificación sobre WATER con las restricciones obtenidas automáticamente(aunque fuesen redundantes). En la Tabla 25 se muestran los resultados de laverificación con SPIN de las propiedades sobre el componente WATER, realizadaésta sin restricciones y con restricciones obtenidas automáticamente.

NoRest GenInd GenPar

Prop t mem t mem t mem1 407 15 429 14 588 14

2 420 15 434 14 582 14

3 412 15 430 14 593 14

4 413 15 435 14 583 14

5 139 12 142 12 401 14

6 447 15 474 14 582 14

7 453 15 466 14 582 14

8 92 12 197 12 275 13,5

9 445 15 467 14 576 14

10 445 15 467 14 583 14

Tabla 25: WATER: Resultados de SPIN en la verificación

Como se observa en este caso, en términos de rendimiento del verificador losresultados son similares en todos los casos.Una de las razones principales está enque las suposiciones son redundantes entre sí, y realmente no producen el efectodeseado de reducción del espacio de estados a explorar por el verificador, sino quese obtiene justamente el resultado contrario: se deben de evaluar en cada uno delos micropasos las suposiciones incluidas y esto supone tiempo y espacio en elcomprobador de modelos. Nótese por ejemplo, como con la inclusión de unarestricción obtenida con GenPar se incrementa el tiempo de verificación (y enmenor medida el consumo de memoria) con respecto a los resultados de GenInd.


194

Otra razón por la que no se mejoran resultados en el rendimiento del verificador,es debido a la propia naturaleza del componente a verificar. El componenteWATER está básicamente constituido por procesos de control (continuos ydiscretos) que ejecutarán como mucho tres micropasos, y por ello, aunque lassuposiciones obtenidas son bastantes restrictivas en cuanto a en qué micropasospueden tomar valores los eventos de interfaz, la longitud del macropaso es muypequeña para que los efectos se puedan notar. Para validar este razonamientobasta con realizar los experimentos anteriores, pero eliminando las suposicionesque son redundantes. Los resultados que se obtuvieron, si bien no son peores queen el caso de la verificación sin suposiciones, son prácticamente iguales entérminos de tiempo de verificación y memoria consumida.

Por tanto, y dado que la verificación inicial sin restricciones no produjo falsospositivos, la utilización en este componente de suposiciones generadasautomáticamente no mejora sustancialmente el rendimiento del comprobador demodelos.

Para el caso del componente STEAM, es aún más evidente la escasa necesidad degenerar los entornos automáticamente. Todas las propiedades a verificar sobre elcomponente (Sección 6.4.2) sin suposiciones fueron ciertas y siempre con unconsumo de recursos muy pequeño (< 1 seg., 1,5 Mbytes). Al igual que elcomponente WATER, el entorno está constituido únicamente por el evento deactivación procedente de CONTROL, pero además STEAM no envía eventos aningún otro componente del sistema, sino que se comunica a través de lamonitorización del estado del proceso control de fallo (SteamFailureStatus). Conlos métodos automáticos, se generaron suposiciones similares a las obtenidas paraWATER (el evento de activación E.Steam únicamente se podrá recibir en elprimer micropaso; el resto son redundantes), y los resultados de verificación paralas seis propiedades con suposiciones automáticas son iguales a los obtenidos sinsuposiciones.

6.5.4 Verificación de Ciclos de No Progreso

Uno de los problemas potenciales de la semántica RSML [Leve94] es laposibilidad de ejecución de ciclos infinitos, donde el sistema podrá llevar a cabouna secuencia infinita de micropasos. Este tipo de fallo potencial puede ser vistocomo la situación contraria a un interbloqueo de procesos (deadlock), y sedenomina en la literatura como livelock. La ausencia de este tipo de situaciones sesuele categorizar dentro de las propiedades de vivacidad simple de un sistema(simple liveness ó progress) [Béra99]. Estas situaciones no solamente puedenafectar al comportamiento no deseado del sistema (ciclos infinitos de ejecución),sino que también deben ser detectadas para que el rendimiento del sistema no sedegrade ante su presencia. Dicho de otro modo, se debe asegurar que el sistemapueda ejecutar una secuencia infinita de macropasos, en vez de micropasos.

Por tanto, se debe asegurar que cada uno de los componentes del sistema noejecuten una cadena infinita de micropasos. El comprobador de modelos SPINpermite detectar estas situaciones mediante la búsqueda de ciclos de no progreso(non-progress cycles, opción -l). Por tanto, se ejecutará de nuevo SPIN sobre


195

cada uno de los componentes verificados anteriormente, con el fin de detectarciclos infinitos

Comenzando por el componente CONTROL, y sin la inclusión de ningún tipo desuposición, SPIN proporciona un contrajemplo en el cual se producen ciclosinfinitos. Analizado el contrajemplo, se demuestra que los eventosLevelRangeLow, LevelRangeHigh, LevelRangeMiddle pueden recibirse de formainfinita durante un micropaso, llegando a derivar esta situación en un ciclo infinitode ejecución del proceso ControlLevel (Figura 63). Recuérdese que este mismoproblema es susceptible de aparecer en la exploración del componente para lageneración de suposiciones, y se soluciona limitando el número máximo demicropasos. Este potencial problema no lo sería siempre y cuando el componenteWATER no permitiese el envío infinito de esos eventos durante un macropaso.Por tanto, es necesario realizar una suposición sobre el componente CONTROLindicando que, durante un macropaso no se reciben más de una vez los eventosLevelRange, y posteriormente verificarla sobre el componente WATER.Ejecutado nuevamente el comprobador de modelos, se obtiene un nuevocontrajemplo, mostrando que es posible otro ciclo infinito en el procesoControlRunMode debido a que se pueden ejecutar de forma infinita transicionesde Failure a NoFailure, y viceversa, en los procesos de monitorización de fallodel resto de componentes (SteamFailureStatus, LevelFaiureStatus yPumpSetFailureStatus). Al igual que en el contrajemplo anterior, se deben derealizar las suposiciones que limiten a una única ejecución de transiciones Failurea NoFailure, o viceversa, en los procesos de control de estado, y de nuevo,verificarlas sobre los respectivos componentes. Ejecutado ahora el comprobador,no se produce ningún contraejemplo.Las suposiciones anteriores que evitan las ejecuciones infinitas de micropasos enel componente CONTROL podrían haber sido obtenidas automáticamente con losmétodos de generación automática. En concreto, las suposiciones descritasanteriormente se corresponden a las obtenidas automáticamente para CONTROLe indicadas en la Tabla 12, en WATER suposiciones 5, 7 y 8 y en ALLPUMPS ySTEAM suposiciones 1 y 2. Efectivamente, la ejecución del comprobador demodelos incorporando las suposiciones automáticas no produce trazas con ciclosinfinitos en el componente CONTROL.

El mismo problema se detecta en el componente ALLPUMPS (con una y dosbombas) en la verificación con suposiciones manuales o sin suposiciones, debidoa que pueden aparecer infinitamente en un mismo micropaso los eventosStartPumps y StopPumps. Sin embargo, si se ejecuta con las suposicionesgeneradas automáticamente, el comprobador no produce ningún contraejemplo,debido a que la existencia de la restricción que indica que durante un macropaso alo sumo se recibe en un micropaso StartPumps o StopPump (Tabla 19, suposición7).

En los componentes STEAM y WATER no se detectó ningún ciclo de ejecucióninfinita de micropasos.

Por tanto, las suposiciones generadas automáticamente permiten también laeliminación (en los casos tratados) de ciclos infinitos de ejecución en loscomponentes. De este modo se evita, por una parte la difícil interpretación de los


196

contrajemplos producidos, y por otra la especificación y posterior descarga de lassuposiciones que eliminen el ciclo de no progreso.

6.5.5 Otras Particiones en Componentes

Aunque la partición en componentes realizada es una descomposición natural ylógica de acuerdo a la descripción textual del problema de la caldera de vapor, sehan experimentado otras particiones en componentes con el objetivo de poderrealizar la verificación del sistema completo formado por las cuatro bombas.

Una primera posibilidad incluye la modificación del componente CONTROL,añadiéndole los procesos de estado de todas la bombas (proceso AllPumpStatus) yde control de los estados de fallo de las bombas (proceso AllPumpFailureStatus),y suprimiendo éstos del componente ALLPUMPS. El objetivo es reducirprocesos, y por tanto eventos y estados, del proceso ALLPUMPS de forma quepueda ser manejado por SPIN. Sin embargo, si bien esta aproximación reduce elnúmero de procesos al elimarlos del modelo, también incrementa el interfaz deentrada con el componente CONTROL, ya que, como se observa en la Figura 83,son necesarios un evento de apertura y otro de cierre para cada una de las bombas(en total, ocho variables de interfaz). En el contexto de la verificación modular delcomponente ALLPUMPS, esto degradará el rendimiento del comprobador, altener que explorar en cada uno de los micropasos todas las posiblescombinaciones de valores en los ocho eventos de interfaz (nótese que en lapartición original, el componente ALLPUMPS únicamente tenía tres eventos deinterfaz).

CONTROL

ALLPUMPS

StartPump[*]

StopPump[*]

Figura 83: Partición de componentes alternativa

Se experimentaron igualmente otras posibilidades con el objetivo de reducir elnúmero de componentes que forman el sistema, de forma que el esfuerzo deverificación total del sistema fuese menor. Las aproximaciones se basaban en laintegración de dos o más componentes en uno. Sin embargo, en las combinacionesensayadas, o bien se produce una explosión combinatoria de estados, o losresultados obtenidos distan mucho de ser los mejores.

En resumen, la partición realizada incialmente además de ser en cierto modo lamás lógica, es la más efectiva desde el punto de vista de la verificación modularde sus componentes.


197

6.6 Resumen y DiscusiónEn este Capítulo se realizó la especificación y verificación del problema decontrol de la caldera de vapor a partir de al especificación original en [Abri96]. Laespecificación se realizó utilizando métodos gráficos basados en el análisisestructurado SA/RT. Debido al tamaño del problema, se utilizó un enfoquemodular basado en suposición-compromiso para reducir el problema de laexplosión de estados, donde los entornos asociados a las suposiciones segeneraron automáticamente utilizando los métodos descritos en los Capítulos 4 y5. Esta aproximación permite realizar la verificación del sistema hasta con dosbombas.

Aunque el problema de la caldera de vapor se ha especificado y verificadoutilizando diferentes formalismos de especificación y herramientas deverificación (ver referencias en la Sección 6.2), hasta donde llega el conocimientodel autor, la especificación y verificación no se había abordado con el mismogrado de detalle que la aquí propuesta, en el sentido de que la verificación sereducía a un subconjunto de los requisitos descritos en la especificación original.En la especificación detallada en este Capítulo, se aborda el problemaconsiderando las cuatro bombas, y se realiza la especificación y verificación detodos las requisitos. Por otra parte, la utilización de métodos gráficos en laespecificación permite una mejor comprensión de ésta por parte de los analistas, alser más intuitivos y con mejores posibilidades para su mantenimiento.

Por otra parte, la utilización de métodos de verificación modular basados ensuposición-compromiso permiten realizar la verificación local de componentes delmodelo, y deducir a partir de dichas verificaciones locales, la veracidad o falsedadde los requisitos del sistema completo sin producir el efecto de la explosión deestados.

En el caso de estudio de la caldera de vapor, se aborda la verificación local de loscomponentes sobre entornos universales sin utilizar restricciones (NoRest), consuposiciones obtenidas manualemente (Man) y automáticamente con las técnicasdetalladas a lo largo de la tesis (GenInd y GenPar). La verificación sinrestricciones obtienen en muchos casos falsos positivos (o falsificaciones erróneasde la propiedad a verificar) debido a la libertad del entorno. La inclusión desuposiciones manuales especificadas por el analista permite reducir elcomportamiento del entorno, y colateralmente reducir también los recursoscomputacionales utilizados por el comprobador de modelos, aunque en muchoscasos depende de la “habilidad” del analista para su especificación. Comoconsecuencia de ello, es posible que aún con ciertas suposiciones, queden latentesfalsos positivos. Los métodos automáticos evitan este problema, generando losentornos de forma automática, por lo que las suposiciones producidas serán másexactas que las obtenidas manualemente, y además se elimna el tiempo y esfuerzoen su especificación. Muchas de las obtenidas automáticamente no podrían serespecificadas manualmente, ya que están relacionadas con la semántica deejecución del modelo (macropasos y micropasos).

Los resultados experimentales obtenidos en la verificación de cada uno de loscomponentes demuestran siempre una reducción de recursos computacionales del


198

comprobador de modelos cuando las suposiciones son generadas automáticamentefrente a NoRest y Man, y además permiten evitar falsos positivos no detectadoscon la inclusión de suposiciones manuales o con entorno universales. Si bien latécnica denominada GenPar cuantitavamente no mejora los resultados obtenidoscon GenInd, debido a que el tiempo de cálculo del entorno es muy elevado, sípermite obtener un conjunto de restricciones más refinadas y que pueden serutilizadas como complemento a la obtenidas con GenInd, o cuando éstas no seanlo suficientemente restrictivas.

Aunque en el algoritmo GenInd los tiempos de cálculo del entorno pueden llegara ser elevados, las restricciones obtenidas permiten reducir los tiempos deverificación de las propiedades. Durante la verificación de los componentes esnormal que alguna de las propiedades sean falsas, debido a una incorrectaespecificación del componente, lo que conllevará a una modificación de dichocomponente. Una posterior verificación del componente (verificación deregresión) implicará la verificación de todas las propiedades para comprobar que,por una parte, las propiedades falsas pasan a ser ciertas, y por otra, que no se hanintroducido errores adicionales que falsean otras propiedades inicialmente ciertas.Con GenInd no es necesario volver a computar el entorno, ya fue generado deforma independiente al componente modificado. Esta observación permite unareducción importante del esfuerzo total en varias verificaciones. Para ilustrar esteefecto, en la Tabla 26 se muestran los tiempos (en segundos) obtenidos ensucesivas verificaciones del componente CONTROL utilizando restriccionesmanuales y automáticas con el algoritmo GenInd, de acuerdo a los datos indicadosen la Tabla 16.

1 2 3 ... NTdesc 664 664 664 ...

Tverif 561 1122 1683 ... N TverifManTotal 1225 1786 2347 ... Tdesc + N Tverif

Tent 804 804 804 ...

Tverif 229 458 687 ... N TverifGenIndTotal 1033 1262 1491 ... Tent + N Tverif

Tabla 26: Coste en tiempo para varias verificaciones de un componente

Para la verificación con restricciones manuales se indica el tiempo de descarga delas suposiciones (Tdesc), y el tiempo de verificación de todas las propiedades(Tverif). Para la verificación las restricciones obtenidas con GenInd se indica eltiempo de cálculo del entorno (Tent) y el tiempo de verificación de todas laspropiedades (Tverif). En columnas se muestra el tiempo total empleadoconsiderando sucesivas verificaciones del componente. Si únicamente se realizaseuna verificación, el esfuerzo total empleado restricciones manuales y restriccionesautomáticas es sensiblemente mejor en ésta última. Sin embargo, a medida que seincrementa el número de verificaciones, la ganancia en tiempo obtenidaempleando GenInd se hace cada vez más importante, debido a que el tiempo de


199

verificación (Tverif) es menor y únicamente es necesario calcular el entorno en laprimera de la verificaciones.

Una ventaja de los métodos propuestos respecto a otras enfoques automáticos degeneración de entornos (por ejemplo [CoblP03]), es la generalidad de la técnica,ya que el cálculo del entorno es independiente de la propiedad a verificar. De estemodo, se facilita la verificación interactiva e incremental del componente,verificando nuevas propiedades bajo el entorno computado previamente sinnecesidad de que sea nuevamente recalculado. Igualmente, con el método GenIndse facilita la verificación de regresión, de modo que cambios realizados en laespecificación del componente no implicarán un recálculo del entorno.

Finalmente, las técnicas automáticas también sirven como ayuda para la detecciónde ciclos de no progreso inherentemente relacionados con la semántica deejecución propuesta en el modelo computacional. De este modo, se evita laejecución infinita de cadenas de micropasos en el modelo, lo que redundará en unmejor comportamiento del sistema y en un mejor rendimiento de las herramientasempleadas en su verificación.

201

Capítulo 7ConclusionesEn este Capítulo se exponen las diferentes conclusiones y aportaciones del trabajode investigación y se indican algunas líneas de trabajo futuro.

Conclusiones

203

7.1 Resumen y ConclusionesLa verificación modular es una de las técnicas más adecuadas para aminorar elproblema de la explosión de estados derivado de la exploración exhaustiva delespacio de estados en las técnicas automáticas de verificación (comprobación demodelos). En ellas, se reduce el problema de la verificación del sistema completoa la verificación de sus partes o componentes, mediante la incorporación desuposiciones que reflejan el comportamiento del entorno. Dichas suposiciones,que posteriormente deben ser verificadas sobre el entorno, se realizanmanualmente, por lo que el proceso completo de verificación no escompletamente automático.

En esta tesis se aborda el problema de la automatización de la verificaciónmodular. Dicha automatización se consigue mediante el desarrollo de técnicas quepermiten la extracción de las suposiciones o restricciones de cada uno de loscomponentes de forma automática, aplicado a sistemas reactivos con semánticasbasadas en pasos de ejecución, similares a las adoptadas en RSML ySTATEMATE. Las restricciones obtenidas se suministran junto con elcomponente para su verificación con un comprobador de modelos. Además de lapropia automatización, esto permite la simplificación del proceso global deverificación, de modo que no es necesario ni realizar las suposicionesmanualmente, ni posteriormente verificarlas sobre el entorno.

Como consecuencia de la investigación encaminada a conseguir el objetivoanterior, se desarrollaron dos técnicas para la generación de las suposiciones. Enla primera de ellas (GenInd), las restricciones se generan para cada uno de loscomponentes del sistema, mediante un algoritmo que extrae relaciones entre lasvariables de interfaz del componente y su entorno (Capítulos 3 y 4). En la segunda(GenPar), las restricciones se generan simultáneamente para varios componentes,de modo que las obtenidas en uno de los componentes están basadas en lasobtenidas en otro u otros componentes (Capítulo 5). El objetivo es obtenerrestricciones en cada componente aún más ajustadas al comportamiento delentorno. Ambas técnicas son consecuentes con la semántica de pasos adoptadapara los componentes del sistema.

Las técnicas anteriores se implementan en un prototipo integrado que permite laespecificación y verificación de sistemas reactivos, utilizando métodos gráficosSA/RT para la especificación (soportada por una herramienta CASE) y elcomprobador de modelos SPIN para su análisis y verificación. Finalmente, serealiza la experimentación de ambas técnicas a la verificación de un sistemacomplejo que especifica el programa de control de una caldera de vapor en unaplanta nuclear (Capítulo 6).

Como consecuencia del desarrollo de las técnicas automáticas de generación desuposiciones y los experimentos con ellas realizados, se puede concluir losiguiente:

� Aún cuando el conocimiento del usuario del sistema es alto, la especificaciónmanual de las suposiciones produce en muchos casos falsos positivos(propiedades que siendo ciertas en el sistema completo, son falsas en el

Conclusiones

204

componente). Dichas suposiciones no son los suficientemente fuertes pararepresentar al entorno, y por tanto, permitirán comportamientos que no sonreales.

� Por otra parte, es imposible o muy difícil expresar manualmente suposicionesrelativas a comportamientos del entorno en pasos internos (micropasos),debido a que no son observables por el usuario. Estas restricciones son muyinteresantes para reducir el consumo de recursos del comprobador de modelos,ya que limitan el número de eventos que puede recibir el componente, y portanto el número de estados que debe manejar el comprobador de modelos.

� Ambas técnicas descritas (GenInd y GenPar) obtienen todos loscomportamientos en el entorno relativos a los eventos de interfaz delcomponente. De este modo, se obtienen todas las posibles relaciones entredichos eventos, y además, dado que su generación es consecuente con lasemántica de pasos, se obtienen relaciones entre los instantes en que seproducen. Desde este punto de vista, se elimina el esfuerzo (tiempo) necesariopara su especificación.

� Como consecuencia de la generación de todas las posibles relaciones entre loseventos de entrada a un componente, se detectan y eliminan los falsospositivos aludidos anteriormente.

� En los experimentos realizados, el rendimiento del comprobador de modeloses mejor cuanto mayor sea el número de restricciones incorporadas. En estesentido, las técnicas automáticas obtienen siempre mejores resultados (tantoen tiempo como en memoria) que las manuales, ya que además de producir unmayor número de restricciones, éstas están más ajustadas al comportamientoreal del entorno. Debido a ello, con las suposiciones derivadas de las técnicasautomáticas, es posible realizar la verificación de sistemas de tamaño notrivial, que no se podrían realizar en el caso de especificarse manualmente.

� Con la utilización de las técnicas automáticas, no es necesario realizar laverificación de las suposiciones sobre el entorno (descarga de la suposición),debido a que el método de exploración del entorno ya las garantiza.

� Ambas técnicas (GenInd y GenPar) son independientes de la propiedad averificar. A diferencia de otras aproximaciones automáticas (por ejemplo[CoblP03]), la generación de restricciones se realiza exclusivamente en base asu entorno. Esto las hace especialmente adecuadas para la verificación en unentorno interactivo.

� Además, la generación de restricciones para entornos individuales (GenInd)es, a su vez, independiente del componente a verificar. Es decir, se computanlas restricciones del entorno del componente, y éstas son válidas paracualquier especificación del componente. Esto es especialmente adecuado pararealizar verificaciones de regresión en un desarrollo incremental, donde antecualquier cambio en el componente, no es necesario de nuevo calcular elentorno.

� Si bien, la técnica GenPar es más penalizadora que GenInd sobre el tiempototal en el proceso de verificación, obtiene restricciones más refinadas. Portanto, aunque en algunos experimentos realizados cuantitativamente

Conclusiones

205

proporcione peores resultados, se debe contemplar como una segunda técnicao técnica alternativa, aplicable a ciertos tipos de sistemas (por ejemplo,componentes muy acoplados).

7.2 ContribucionesEl objetivo principal del trabajo presentado en esta tesis ha sido el desarrollo denuevas técnicas y métodos para la automatización de la verificación modularbasada en razonamiento suposición-compromiso. Más específicamente, elesfuerzo se ha centrado en la generación automática de restricciones del entornopara minimizar la intervención del usuario en los procesos de especificación delos entornos de los componentes bajo verificación.

Se han desarrollado dos técnicas automáticas para la generación de suposicionesdel entorno. La primera de ellas se aplica a un único componente para derivar susrestricciones del entorno. La segunda, permite su aplicación a diferentescomponentes del sistema, de modo que las restricciones del entorno se obtienensimultáneamente para todos los componentes. Para su validación, se especifica uncaso de estudio no trivial y se aplican ambas técnicas a la verificación modular desus componentes.

Como resumen, las principales contribuciones de esta tesis incluyen:

� Integración de tecnologías existentes en el proceso de verificación modularcon razonamiento basado en suposición-compromiso. Esta integración se harealizado con el objetivo de que el proceso sea lo más intuitivo y automatizadoposible para el ingeniero, de modo que la especificación se realiza conformalismos gráficos y la verificación con herramientas automáticas(comprobadores de modelos).

� Formalización de la semántica de ejecución de los modelos gráficos utilizandouna semántica basada pasos, que hace posible la verificación modular de loscomponentes de un sistema haciendo visibles explícitamente los micropasos.Así, la verificación de un componente es compatible con la semántica delsistema completo.

� Desarrollo de una técnica para la computación del espacio de estados delentorno (conjunto de configuraciones) del componente. Dicho espacio deestados, servirá como base para la posterior generación de restricciones. Lageneración del conjunto de configuraciones para un componente contemplaaspectos tales como, generación bajo condiciones de no determinismo, ciclosinfinitos de ejecución y comunicación con el entorno, todo ello enconsonancia con la semántica anterior. Para el soporte completo de estascaracterísticas sin producir una explosión combinatoria de estados, se detallauna heurística (cortocircuito de micropasos) que evita el almacenamiento deconfiguraciones previamente visitadas en la exploración del componente.

� Desarrollo de una técnica (GenInd) que permite la generación de suposicionespara un componente a partir de las configuraciones calculadas de su entorno.Durante el proceso de verificación del sistema completo únicamente serequiere la intervención del usuario para especificar la partición del sistema en

Conclusiones

206

componentes y propiedades. Hasta donde llega el conocimiento del autor, latécnica es novedosa, ya que es independiente del componente y de lapropiedad a verificar. Esto es especialmente importante en las verificacionesinteractivas y de regresión.

� Ampliación de la técnica anterior, para la generación de restricciones en varioscomponentes simultáneamente (GenPar). El objetivo es obtener restriccionesmás ajustadas en cada componente mediante la información proporcionada, asu vez, por las restricciones de otro componente. Al igual que la técnicaanterior, es independiente de la propiedad a verificar, pero no del componente,por lo que se puede considerar como una segunda técnica o una alternativa a laanterior.

� Integración de las restricciones obtenidas en los puntos anteriores en ellenguaje aceptado por un comprobador de modelos de amplia utilización comoes SPIN, de forma que no es necesaria la recodificación para su especificaciónen el comprobador de modelos. Esto permite una automatización completa delproceso de verificación modular.

� Implementación e integración de las técnicas anteriores en un entorno deespecificación y verificación de sistemas reactivos.

� Especificación completa y verificación de un problema bien conocido en elárea de la verificación de sistemas reactivos, como es el problema de lacaldera de vapor, para la experimentación de las técnicas desarrolladas.

7.3 Trabajo FuturoEl trabajo presentado en esta tesis incluye el desarrollo de técnicas que se puedenconsiderar novedosas y que pueden abrir nuevas líneas de investigación dentro delcampo de la verificación formal de sistemas reactivos.

Desde el punto de vista de mejora de las técnicas discutidas, algunas de estaslíneas son:

� Estudio y desarrollo de nuevas técnicas y estructuras de datos para lageneración eficiente del espacio de estados del entorno del componente. Deacuerdo a los resultados experimentales mostrados en el Capítulo 6, elprincipal “cuello de botella” en la aplicación de los métodos automáticos degeneración de suposiciones está precisamente en la generación del espacio deestados del entorno bajo verificación. La aplicación de técnicas utilizadas parala exploración eficiente del espacio de estados (por ejemplo, métodos de ordenparcial) o para su codificación (por ejemplo, diagramas binarios de decisión),podrían redundar en un mejor rendimiento de las técnicas automáticas degeneración de entornos aplicadas a componentes de mayor tamaño.

� Reducción automática de las restricciones obtenidas. Dado que puede sucederque muchas restricciones obtenidas sean redundantes entre sí, en el sentido deque unas incluyen a otras, sería interesante detectarlas antes de suincorporación al proceso de verificación, de forma similar a como se realizacon reglas de asociación [Agga98b].

Conclusiones

207

� Experimentación con nuevas técnicas para el aprendizaje de entornos de uncomponente, que sean independientes de la propiedad a verificar.

Enfocadas en el soporte por herramientas:

� Implementación de las técnicas dentro del comprobador de modelos SPIN, deforma que, bajo la semántica propuesta se puedan computar entornos y/overificar los componentes en una única herramienta de verificación. En lamisma línea, los algoritmos optimizados y eficientes empleados en laverificación por SPIN se reutilizarán para la generación de entornos.

� Desarrollo de herramientas integradas para soporte al desarrollo y verificaciónbasada en componentes implementando técnicas similares a las descritas en latesis. Idealmente dichas herramientas deberían permitir la especificación delsistema y sus propiedades, la partición del sistema en componentes y realizarla verificación de cada componente con entornos especificados manual yautomáticamente para mayor flexibilidad. Así mismo, sería interesante laincorporación de métodos deductivos para demostrar que la conjunción de laspropiedades locales implica la propiedad global.

Desde el punto de vista de su aplicabilidad a otros sistemas o campos afines:

� Utilizar especificaciones basadas en el lenguaje Statecharts con la mismasemántica que la propuesta.

� Estudiar su aplicabilidad a diseños y/o especificaciones orientadas a objetorealizadas con formalismos soportados por el Lenguaje Unificado deModelado [OMG03], tales como diagramas de comportamiento.

� Aplicar las técnicas directamente a especificaciones en un lenguaje deprogramación con soporte de concurrencia, como por ejemplo JAVA. Uno delos principales problemas está en la modelización de estructuras de datos notriviales (listas, colas, árboles, etc.) dentro del modelo de estados finito quedebe manejar el comprobador. Una posible solución sería la de utilizar algunatécnica de abstracción.

� En general, integración de una tecnología emergente, aunque establecida,como es la comprobación de modelos, con técnicas más clásicas utilizadas enel aseguramiento de la calidad de sistemas software, como es la prueba delsoftware. Ver, por ejemplo [Groc02] y [Rusu02], para una visión actual de laintegración de ambos métodos.

Referencias

209

Referencias[Abad93] Abadi, M.,Lamport,L.: “Composing Specifications”. ACM Transactions on

Programming Languages and Systems, 15(1):73-132, 1993

[Abad95] Abadi, M.,Lamport,L.: “Conjoining Specifications”. ACM Transactions onProgramming Languages and Systems, 17(3):507-534, 1995

[Abri96] Abrial, J-R, Börger, E., Langmaack, H. “Formal Methods for IndustrialApplications: Specifying and Programming the Steam Boiler” LNCS 1165,Springer-Verlag, 1996

[Agga98a] Aggarwal, C.C., Yu, P.S. “Mining Large Itemsets for Association Rules”, IEEEComputer Society Technical Committee on Data Engineering, 21(2), pp. 23-31,1998

[Agga98b] Aggarwal, C.C., Yu, P.S. “Online Generation of Association Rules”, InProceedings of the International Conference on Data Engineering, pp. 402-411,1998

[Agra93a] Agrawal, R., Imielinski, T., Swami, A. “Database Mining: A PerformancePerspective” IEEE Transactions on Knowledge and Data Engineering, 5(6) :914—925, 1993

[Agra93b] Agrawal, R., Imielinski, T., Swami, A. “Mining Association Rules between Setsof Items in Large Databases” In Proceedings of the ACM SIGMOD InternationalConference on Management of Data, pp. 207—216, 1993.

[Agra94] Agrawal, R., Srikant, R. “Fast Algoritms for Mining Association Rules” InProceedings of the International Conference on Very Large Databases, pp. 487-499, 1994

[Alfa01a] Alfaro, L. de, Henzinger, T.A. “Interface Automata” In Proceedings of the 8th

European Software Engineering Conference, pp. 109-120, 2001

[Alfa01b] Alfaro, L. de, Henzinger, T.A. “Interface Theories for Component-Based Design”In Proceedings of the 1st Workshop on Embedded Software, pp. 148-165, 2001

[Alur96] Alur, R., Henzinger, T.A. “Reactive Modules” In Proceedings of the 11th AnnualIEEE Symposium on Logic in Computer Science, 1996

[Alur97] Alur, R., Brayton, R.K., Henzinger, T.A., Qudeer, S., Rajamani, S.K. “Partial-Order Reduction in Symbolic State Space Exploration” In Proceedings of th 9th

International Conference on Computer Aided Verification, LNCS, Vol. 1254, pp.340-351, Springer-Verlag, 1997

[Alur98] Alur, R., Henzinger T.A:, Mang, F.Y.C., Qadeer, S., Rajamani, S.K., Tasiran, S.“Mocha: Modularity in Model Checking” In Proceedings of InternationalConference on Computer Aided Verification, LNCS, Vol, 1427, pp. 521-525,1998

[Alur99] Alur, R., Alfaro,L. de, Henzinger, T.A., Mang, F.Y.C.: “Automating ModularVerification”. Proceedings of the Tenth International Conference on ConcurrencyTheory, Volume 1664 LNCS, pages 82—97, Springer-Verlag, 1999.

Referencias

210

[Angl87] Angluin, D. “Learning Regular Sets from Queries and Counterexamples”Information and Computation, 75(2):87-106, 1987.

[AUTO96] “AUTOVER: Automatización de la Verificación de Sistemas en Tiempo Realusando Métodos Estructurados y Lógica Temporal”. Documento deEspecificación del Sistema, Departamento de Informática, Universidad deOviedo, 1996.

[Beec94] Beeck, M. von der “A Comparasion of Statecharts Variants” In Proceedings ofFormal Techniques in Real-Time and Fault-Tolerant Systems, LNCS, Vol. 863,pp. 128-148, Springer-Verlag, 1994

[Bene91] Beneviste, B, Berry, G. “The Synchronous Approach to Reactive and Real-TimeSystems” In Proceedings of IEEE, 79(9):1270-1282, 1991

[Béra99] Bérard, B., Bidoit, M., Finkel, A., Laroussinie, F., Petit, A., Petrucci, L.,Schnoebelen, P., McKenzie, P. “System and Software Verification: Model-Checking Techniques and Tools”, Springer-Verlag, 1999.

[Berr92] Berry, G., Gonthier, G. “The ESTEREL Synchronous Programming Language:Design, Semantics and Implementation” Science of Computer Programming, vol.19, pp. 87-152, 1992

[Bhat95] Bhat, G., Cleaveland, R., Grumberg, O. “Efficient on-the-fly model checking forCTL*” In Proceedings of the 10th Annual Symposium on Logic in ComputerScience, pp. 388-397, 1995.

[Brya86] Bryant, R.E. “Graph-based algorithms for boolean function manipulation”, IEEETransactions on Computeres, C-35(8), pp. 667-691, 1986

[BreiS84] Breiman, L., Friedman, J.H., Olshen, R.A., Stone, C.J. “Classification andRegression Trees”, Wadsworth, Belmont, 1984

[Burc90] Burch, J.R., Clarke, E.M., McMillan, K.L., Dill, D.L., Hwang, L.J. “SymbolicModel Checking: 1020 States and Beyond”. In Proceedings of Fitht Annual IEESymposium on Logic in Computer Science pp. 1-33, 1990

[Burc93] Burch, J.R., Clarke, E.M., McMillan, K.L., Dill, D.L. “Symbolic Model Checkingfor Sequential Circuit Verification” IEEE Transaction on Computer-Aided Designof Integrated Circuits 13(4): 401-424, 1993

[Brow89] Browne, M.C., Clarke, E.M., Grumberg, O. “Reasoning about Networks withmany Identical Finite-State Processes” Information and Computation, 81(1):13-31, 1989

[Carr00] Carreira, P.J.F., Costa, M.E.F. “Automatically Verifying and Object OrientedSpecification of the Steam Boiler System”. In Proceedings of the 5th InternationalWorkshop on Formal Methods for Industrial Critical Systems FMICS’2000(Berlin, Germany), GMD Report 91, pp. 345-360, 2000

[Clar03] Clark, J., Dolado, J.J., Harman, M., Hierons, R., Jones, B., Lumkin, M., Mitchell,B., Mancoridis, S., Rees, K., Roper, M., Shepperd, M. “Reformulating SoftwareEngineering as a Search Problem” IEE Proceedings-Software, 150(3):161-175,2003

[Clar81] Clarke, E.M. Emerson, E.A. “Design and Synthesis of Synchronization SkeletonsUsing Branching Time Temporal Logic”. In Proceedings of Workshop on Logicof Programs, LNCS Vol. 131, pp. 52-71, 1981

[Clar86] Clarke, E.M., Emerson, E.A., Sistla, A.P. “Automatic Verification of Finite-StateConcurrent Systems using Temporal Logic”, ACM Transactions on ProgrammingLanguages and Systems, 8(2): 244-263, 1986

Referencias

211

[Clar89] Clarke, E.M., Long, D, McMillan, K. “Compositional Model Checking” InProceedings of the 4th IEEE Symposium on Logic in Computer Science, pp. 353-362, 1989

[Clar94] Clarke, E.M., Grumberg, O., Long, D. “Model Checking and Abstraction” ACMTransactions on Programming Languages and Systems, 16(5):1512-1542, 1994

[Clar96a] Clarke, E.M., Filkorn, T., Jha, S. “Exploiting Symmetry in Temporal LogicModel Checking” Formal Methods in System Design, Vol 9, pp. 77-104, 1996

[Clar96b] Clarke, E.M., Wing, J.M. “Formal Methods: State of the Art and FutureDirections”, ACM Computing Surveys, 28(4): 626-643, 1996

[Clar97a] Clarke, E.M., Grumberg, O., Hamaguchi, K. “Another Look to LTL ModelChecking” Formal Methods in System Designs, 10(1), 1997.

[Clar97b] Clarke, E.M., Grumberg, O., Jha, S. “Verifiying Parametrized Networks” ACMTransactions on Programming Languages and Systems 19(5):726-750, 1997

[Clar99] Clarke, E.M., Grumberg, O., Peled, D.A. “Model Checking”, MIT Press, 1999

[Clea93] Cleaveland, R., Parrow, J., Steffen, B. “The Concurrency Workbench: ASemantics-Based Tool for the Verification of Concurrent Systems” ACMTransactions on Programming Languages and Systems, 15(1):36-72, 1993

[Chan98] Chan, W., Anderson, R.J., Beame, P., Burns, S., Modugno, F, Notkin, D., Reese,J.D. “Model Checking Large Software Specifications” IEEE Transactions onSoftware Engineering, 24(7):498-519, 1998

[Chan99] Chan, W., Anderson, R.J., Beame, P., Jones, D.H., Notkin, D., Warner, W.E.“Decoupling Synchronization from Local Control for Efficient Symbolic ModelChecking of Statecharts”, In Proceedings of International Conference onSoftware Engineering (ICSE’99), pp. 142—151, 1999.

[Chan01] Chan, W., Anderson, R.J., Beame, P., Jones, D.H., Notkin, D., Warner, W.E.“Optimizing Symbolic Model Checking for Statecharts”, IEEE Transactions onSoftware Engineering, 27(2) pp. 170—190, 2001

[Chen96] Chen, M.S., Han, J., Yu, P.S. “Data Mining: An Overview from DatabasePerspective” IEEE Transactions on Knowledge and Data Engineering, 8(6):866—883, 1996

[Cheu96] Cheung, S.C., Kramer,J. : “Context Constraints for Compositional ReachabilityAnalysis” ACM Transactions on Software Engineering, 5(4): 344--377, 1996

[CoblP03] Cobleigh, Giannakipoulou, Pasareanu, C. “Learning Assumptions forCompositional Verification” In Proceedings of Tools and Algorithms for theConstruction and Analysis of Systems, 2003

[Colb98] Colby, C. Godefroid, P., Jagadesan, L.J. “Automatically Closing Open ReactivePrograms” In Proceedings of the SIGPLAN Conference on ProgrammingLanguages Design and Implementation, pp. 345-357,1998

[Corb96] Corbett, J.C. “Evaluating Deadlock Detection for Concurrent Software” IEEETransactions on Software Engineering, 22(3) 161--180, 1996

[Coop92] Cooper, G., Herskovits, E. “A Bayesian Method for the Induction of ProbabilisticNetworks from Data”, Machine Learning, 1992.

[Cour92] Courcoubetis, C., Vardi, M., Wolper, P., Yannakakis, M. “Memory-EfficientAlgorithms for the Verification of Temporal Properties” Formal Methods inSystem Design, Vol 1, pp. 275-288, 1992

Referencias

212

[Cous77] Cousot, P., Cousot, R. “Abstract Interpretation: A Unified Lattice Model forStatic Analysis of Programs by Construction or Approximation of Fixpoint”. InProceedings of the 4th ACM Symposium on Principles of ProgrammingLanguages, pp. 238-252, 1977

[Cous99] Cousot, P., Cousot, R.: “Refining Model Checking by Abstract Interpretation”Automated Software Engineering Journal, 6(1):69-95, 1999

[CraiT93] Craigen, D. Gerhart, S., Talston, T.: “An International Survey of IndustrialApplicantions of Formal Methods (Volume 1: Purpose, Approach, Analysis andConclusions. Volume 2: Case Studies)”. Technical Report NIST GCR 93/626,National Institute of Standards and Technology, 1993.

[DAGS95] Dagstuhl Seminar on “Methods for Semantics and Specifiction”. Dagstuhl,Germany, 1995

[Dams97] Dams, D., Gerth, R., Grumberg, O. “Abstract Interpretation of Reactive Systems”ACM Transactions on Programming Languages and Systems, 19(2):253-291,1997.

[Dijk68] Dijkstra, E.W. “Cooperating Sequential Processes”. Programming Languages, F.Genuys (Ed.), Academic Press, London, pp. 43-112, 1968.

[Dijk75] Dijkstra, E.W. “Guarded Commands, Nondeterminancy and Formal Derivation ofPrograms” Communications of the ACM, 18(8):453-457, 1975

[Ding95] Dingel, J., Filkorn, T. “Model Checking for Infinite State Systems Using DataAbstraction, Assumptiom-Commitment Style Reasoning and Theorem Proving”.In Proceedings of the 7th International Conference on Computer AidedVerification. LNCS Vol. 939, pp.54-69, Springer-Verlag, 1995

[Dola00] Dolado, J.J. “A Validation of the Componente-based Method for Software SizeEstimation” IEEE Transactions on Software Engineering, 26(10), pp. 1006—1021, 2000

[Dola01] Dolado, J.J. “On the Problem of the Software Cost Function” Information andSoftware Technology, vol. 43, pp. 61—72, 2001

[Duva96] Duval, G., Cattel, T. “Specifying and Verifying the Steam Boiler Problem withSPIN” In [Abri96], pp. 203-217, 1996.

[Emer93] Emerson, E.A., Sistla, A.P. “Symmetry and Model Checking” In Proceedings ofthe 5th Workshop on Computer Aided Verification, LNCS Vol. 697, pp. 463-478,Springer-Verlag, 1993.

[EDIC98] “EDIC: Entorno Integrado para Desarrollo de Sistemas Industriales de Control”Documento de Especificación y Diseño del Sistema, Departamento deInformática, Universidad de Oviedo, 1998

[Feld94] Felder, M., Mandrioli, D., Morzenti, A. “Proving Properties of Real-TimeSystems Through Logical Specifications and Petri Nets Models” IEEETransactions on Software Engineering, 20(2):127-141, 1994

[Fern96] Fernández, J.C., Garavel, H., Kerbrat, A., Mateesku, R., Mounier, L., Sighireanu,M. “CADP: A Protocol Validation and Verification Toolbox” In Proceedings ofthe 8th International Conference on Computer Aided Verification, Vol. 1102,pp.437-440, Springer-Verlag, 1996.

[Flo67] Floyd, R. Assigning Meaning to Programs. In Proceedings of Symposium onAplied Mathematical Aspects of Computer Science, J.T. Schwartz, ed. AmericanMathematical Society, 19-32, 1967.

[GPVW95] Gerht, R., Peled, D., Vardi, M.Y., Wolper, P. “Simple on-th.fly AutomaticVerification of Linear Temporal Logic” In Protocol Specification, Testing andVerification, pp. 176-185, Chapman & Hall, 1995

Referencias

213

[Gian02] Giannakopoulou, D., Pasareanu, C.S., Barringer, H. “Assumption Generation forSoftware Component Verification”, In Proceedings of IEEE InternationalConferencein Automated Software Engineering, 2002

[Gode90] Godefroid, P. “Using Partial Orders to Improve Automatic Verification Methods”In Proceedings of the 2nd Workshop on Computer Aided Verification, LNCS Vol.531, pp. 176-185, Springer Verlag, 1990

[Gode91] Godefroid, P., Wolper P. “Using Partial Orders for the Efficient Verification ofDeadlock Freedom and Safety Properties” In Proceedings of the 3rd Workshop onComputer Aided Verification, LNCS Vol. 575, pp. 332-342, Springer Verlag,1991

[Gode92] Godefroid, P., Holzmann, G.J., Pirottin, D. “State Space Caching Revisited”. InProceedings of the 4th International Conference on Computer Aided Verification.LNCS Vol. 663, pp. 178-191, Springer-Verlag, 1992

[Gode93] Godefroid, P., Pirottin, D. “Refining dependences improves partial-orderverification methods” In Proccedings of the 2nd Workshop on Computer Aided-Verification, Volume 697 LNCS, Springer-Verlag, 1993.

[Gode97] Godefroid, P.,” Model Checking for Programming Languages using Verisoft” InProceedings of the 24th ACM Symposium on Principles of ProgrammingLanguages, pp. 174-186, 1997

[Gode02] Godefroid, P., Khurshid, S. “Exploring Very Large State Spaces Using GeneticAlgorithms”, In Proceedings of the Tools and Algorithms for the Constructionand Analysis of Systems (TACAS), 2002

[Glov93] Glover, F., Laguna, M. “Tabu Search”, In Modern Heuristic Techniques forCombinatorial Problems C.R. Reeves (editor) John Wiley & Sons, 1993

[Graf96] Graf, S., Steffen, B., Lüttgen, G. “Compositional Minimisation of Finite StateSystems Using Interface Specifications” Formal Aspects of Computing, 8(5):607-616, 1996

[Groc02] Groce, A., Peled, D.A., Yannakakis, M. “Adaptive Model Checking” InProceedings of the International Conference of Tools and Algorithms for theConstructions and Analysis of Systems, pp. 357-370, 2002

[Grum94] Grumberg, O., Long, D. “Model Checking and Modular Verification” ACMTransactions on Programming Languages and Systems, 16(3):843-871,1994.

[Guer91] Guernic, P., Gautier, T., Borgne, M., Marie, C. “Programming Real-TimeApplications with Signal” Proceedings of the IEEE, 79(9):1321-1336, 1991

[Halb91] Halbwachs, N., Caspi, P., Raymond, P., Pilhaud, D. “The Synchronous Data FlowProgramming Language Lustre” In Proceedings of the IEEE, 79(9):1305-1320,1991

[Han92] Han, J., Cai, Y., Cercone, N. “Konwledge Discovery in Databases: An AttributeOriented Approach”, In Proceedings of the International Conference on VeryLarge Databases, pp. 547-559, 1992

[Hare87a] Harel, D. “Statecharts: A Visual Formalism for Complex Systems” Science ofComputer Programming 8:231-274, 1987

[Hare87b] Harel, D., Pnueli, A., Pruzan-Schmidt, J., Sherman, R. “On the Formal Semanticsof Statecharts” In Proceedings of the 2nd Symposium on Logic in ComputerScience, pp.56-64, 1987

[Hare90] Harel, D., Lachove, H., Naamad, A., Pnueli, A., Politi, M., Sherman, R.,Tachtenbrot, M. “Statemate: a Working Environment for the Development ofComplex Reactive Systems” IEEE Transactions on Software Engineering, 16(4),pp. 403-414, 1990

Referencias

214

[Hare96] Harel, D., Naamad, A.: “The STATEMATE semantics of Statecharts”. ACMTransactions on Software Engineering and Methodology, 5(4):293--333, 1996

[Have96] Havelund, K., Shankar, N. “Experiments in Theorem Proving and ModelChecking for Protocol Verification”. In Proceedings of the 3rd InternationalSymposium of Formal Methods Europe, LNCS Vol. 1051, pp. 662-681, Springer-Verlag, 1996

[Heim96] Heimdahl, M.P.E., Leveson, N. “Completeness and Consistency in HierarchicalState-based Requirements”. IEEE Transactions on Software Engineering, 22(6),pp. 363-377, 1996

[Henz98] Henzinger, T.A., Qadeer, S., Rajamani, S.K. “You Assume, We Guarantee:Methodology and Case Studies”, In Proceedings of the 10th InternationalConference on Computer Aided Verificaction, LNCS, Vol. 1427 ,pp. 440-451,1998.

[Hipp00] Hipp, J., Güntzer, U., Nakhaeizadeh, G. “Algorithms for Association Rule Mining– A General Survey and Comparison”, ACM SIGKDD Explorations, 2(1) pp.58—64, 2000

[Hoar69] Hoare, C.A.R. “An Axiomatic Basis for Computer Programming”.Communications of ACM 12, 576-580, 1969

[Hoar85] Hoare, C.A.R “Communicating Sequential Processes”. Prentice-Hall, 1985

[Holl75] Holland, J.H. “Adaption in Natural and Artificial Systems”, MIT Press, AnnArbor, 1975

[Hols94] Holsheimer, M., Siebes A. “Data Mining: The Search for Knowledge inDatabases”, Technical Report CS-R9406, CWI, Netherlands, 1994

[Holz87] Holzmann, G.P “Automated Protocol Validation in Argos: Assertion Proving andScatter Searching”. IEEE Transactions on Software Engineering 13(6):683-696,1987

[Holz91] Holzmann, G.J. “Design and Validation of Computer Protocols” Prentice-HallSoftware Series, 1991

[Holz94] Holzmann, G.J., Peled, D.A. “An Improvement in Formal Verification”. InProceedings of the 7th Conference on Formal Description Techniques, pp. 177-194, 1994

[Holz96] Holzmann, G.J., Peled, D., Yannakakis, M. “On nested depth first search”. In TheSpin Verification System, pp. 23-32, American Mathematical Society, 1996.

[Holz97a] Holzmann, G.J. “State Comprenssion in SPIN” In Proceedings Third SpinWorkshop, 1997

[Holz97b] Holzmann, G.J. “The Model Checker SPIN” IEEE Transactions on SoftwareEngineering 23(5):279--295, 1997.

[Holz98] Holzmann, G.J. “An Analysis of Bitstate Hashing” In Formal Methods in SystemDesign 13(3), 298-307, 1998.

[Holz99] Holzmann, G.J, Puri, A. “A Minimized Automaton Representation of ReachableStates” In Software Tools for Technology Transfer 2(3) 270-278, 1999

[Holz03] Holzmann, G.J. “The Spin Model Checker: Primer and Reference Manual”,Addison-Wesley, 2003

[Huiz91] Huizing, C., Gerth, R. “On the Semantics of Reactive Systems” Technical Report,ESPRIT Basic Research, Action Number 3096, SPEC, 1991.

[IEEE90] IEEE-Std-610.12-1990 “Glossary of Software Engineering Terminology” IEEE,1990.

Referencias

215

[IEEE98] IEEE-Std-1233-1998 “Developing System Requirements Specifications”, IEEE,1998

[Ip93] Ip, C., Dill, D. “Better Verification through Symmetry”. In Proceedings of the11th IFIP WG10.2 International Conference on Computer Hardware DescriptionLanguages and their Applications, 1993

[ISO89] ISO - Information Processing Systems, Open Systems Interconnection. “Estelle:A Formal Description Technique based on an Extended State Transition Model”.Intenational Standard ISO 9074, 1989.

[Iyer01] Iyer, S., Ramesh, S. “Apportioning: A Technique for Efficient ReachabilityAnalysis of Concurrent Object-Oriented Programs” IEEE Transactions onSoftware Engineering , 27(11):1037—1056, 2001

[Jaga95] Jagadeesan, L.J., Puchol, C. Olnhausen, J.E.V.: “A formal approach to reactivesystems software: A telecommunications application in ESTEREL”, InProceedings of the Workshop on Industrial-Strength Formal SpecificationTechniques, 1995.

[Jone83] Jones, C.B. “Specification and Design of (Parallel) Programs” InformationProcessing 83:321-332, 1983.

[KaufM00] Kauffman, M., Manolios, P., Moore, J.S. “Computer-Aided Reasoning: AnApproach”, Kluwer Academics Publishers, 2002

[Kest98] Kesten, Y., Pnueli, A. “Modulization and Abstraction: The Keys to FormalVerification”. In Proceedings of 23rd International Symposium on MathematicalsFoundations of Computer Science, LNCS, Vol. 1450, pp. 54-71, Springer-Verlag,1998.

[Klem94] Klemettinen, M., Manila, H., Ronkianen, P., Toivonen, H., Verkamo, A.I.“Finding Interesting Rules form Large Sets of Discovered Association Rules”, InProceedings of the 3rd. International Conference on Information and KnowledgeManagement, pp. 401—407, 1994

[Koze83] Kozen, D. “Result on the Propositional µ-calculus”. Journal of TheoreticalComputer Science 27:333-354, 1983.

[Kupf98] Kupferman, O., Vardi, M.Y. “ Modular Model Checking” In Proceedings of theCompositionality Workshop, LNCS, Vol. 1536, pp. 381-401, Springer-Verlag,1998

[Kurs95] Kurshan, R.P. :”Computer-Aided Verification of Coordinating Processes: TheAutomata-Theoretic Approach”, Princeton University Press, 1995

[Kurs98] Kurshan, R.P. :”FormalCheck User’s Manual” Cadence Design, Inc, 1998.

[Lamp83] Lamport, L. “Specifiying Concurrent Programs Modules” ACM Transactions onProgramming Languages and Systems 5:190-222, 1983

[LFV02] “Learning and Formal Verification: A Workshop in Honor of Eli Shamir”, NeveIlan, Israel, May 2002

[Leve94] Leveson, N.G., Heimdahl, M.P.E., Hildreth, H., Reese, J.D.: “RequirementsSpecification for Process Control Systems”, IEEE Transactions on SoftwareEngineering, 20(9):684-707, 1994

[Leve95] Leveson, N.G. :”Safeware: System Safety and Computers”, Addison-Wesley, 1995

[Loef97] Loeffler, S., Serhrouchni, A. “Creating a Validated Implementation of the SteamBoiler Control”. In Proceedings of the Third SPIN Workshop, 1997.

[Long93] Long, D.E. “Model Checking, Abstranction and Compositional Reasoning” PhDThesis, Carnegie Mellon University, 1993

Referencias

216

[Mann91] Manna, Z., Pnueli, A. “The Temporal Logic of Reactive and ConcurrentSystems”. Springer-Verlag, 1991

[Mann95] Manna, Z., Pnueli, A. “Temporal Verification of Reactive Systems: Safety”.Springer-Verlag, 1995.

[Mann99] Manna, Z., Bjorner, N.S., Browne, A., Colón, M., Finkbeiner,B, Pichora, M,Sipma, H.B.,Uribe,T.E. “An Update on SteP: Deductive-Algorithmic Verificationof Reactive Systems”. In Tool Support for System Specification, Development andVerification, Advances in Computing Science, pp. 174-188, Springer-Verlag,1999.

[Mann87] Mannila, H., Raiha, K. “Dependency Inference”, In Proceedings of theInternational Conference on Very Large Databases, pp 155-158, 1987.

[Marc79] Marco, T. de “Structured Analysis and System Specification”, Yourdon Press,1979

[McMi93] McMillan, K.L. “Symbolic Model Checking: An Approach to the State ExplosionProblem”, Kluwer Academic, 1993.

[McMi99] McMillan, K.L. “Circular Compositional Reasoning about Liveness” InProceedings of the Correct Hardware Design and Verification Methods: 10th IFIPWG 10.5 Advanced Research Working Conference, LNCS, Vol. 1703, pp. 342-346,1999

[McMi00] McMillan, K.L. “Compositional Systems and Methods” Verification of Digitaland Hybrid Systems, Vol. F-170 of NATO Advanced Summer Institutes,Springer-Verlag, 2000

[Melh93] Melham, T.F. “Introduction to Hol: A Theorem Proving Environment fo HigherOrder Logic”. Crambridge University Press, 1993.

[Mikk97] Mikk, E., Lakhnech, Y., Siegel, M. “Hierarchical Automata as Model forStatecharts” In Proceedings of the Asian Computing Science Conference, LNCS,Vol. 1345, 1997

[Miln89] Milner, R. “Communication and Concurrency”. Prentice-Hall, 1989

[Misr81] Misra, B., Chandy, K.M. “Proofs of Networks of Processes” IEEE Transactionson Software Engineering, 7:417-426, 1981

[OMG03] OMG "UML Notation Guide", UML 1.5 Specification, 2003

http://www.omg.org/cgi-bin/doc?formal/03-03-01

[Acceso: Septiembre 2003]

[Owre96] Owre, S, Rajan, J., Rushby, J.M., Shankar, N., Srivas, M.K. “PVS: CombiningSpecification, Proof Checking and Model Checking”. In Proceedings of Intl.Conf. on Computer Aided Verification, LNCS Vol. 1102, pp. 411-414, Springer-Verlag, 1996

[Parn98] Parnas, D.L. “ Formal Methods Technology Transfer Will Fail”, Journal ofSystems and Software, 40(3), pp. 95-98, 1998.

[Pasa01] Pasareanu, C.S. “Abstraction and Modular Reasoning for the Verification ofSoftware”, PhD Thesis, Department of Computing and Information Sciences,Kansas State University, 2001

[Parg99] Pargas, R.P., Harrold, M.J. Peck, R.R. “Test-data generation using geneticalgorithms” The Journal of Software Testing, Verification and Reliability, vol. 9,pp. 263—282, 1999

Referencias

217

[Pele94] Peled, D.A.”Combining Partial Order Reductions with On-the-Fly ModelChecking” In Proceedings of the 6th International Conference on Computer AidedVerification, LNCS, Vol. 818, pp. 377-390, 1994.

[Pele01] Peled, D.A. “Software Reliability Methods”. Springer-Verlag, 2001

[Pete94] Petersohn, C., Peleska, J., Huizing, C. de Roever, W.P: “Formal Semantics forWard and Mellor Transformation Schema’s and its Application to Fault-TolerantSystems”. In Proceedings of the 1st European Dependable ComputingConference, LNCS, Vol. 852, pp. 59-76, 1994

[Piat91a] Piatetsky-Shapiro, G. “Discovery, Analysis and Presentation of Strong Rules”, In[Piat91b], pp 229—248, 1991

[Piat91b] Piatetsky-Shapiro, G. “Knowdledge Discovery in Databases” AAAI/MIT Press,1991

[Pnue77] Pnueli, A. “The Temporal Logic of Programs” In Proceedings of the 18th IEEESymposium on Foundations of Computer Science, pp. 46-57, 1977

[Pnue85] Pnueli, A “In Transition for Global to Modular Temporal Reasoning aboutPrograms” Logics and Models of Concurrent Systems, Vol F-13 of NATO-Advanced Summer Institutes, pp.123-144, Springer-Verlag, 1985.

[Quie81] Quielle, J.P., Sifakis, J. “Specification and Verification of Concurrent Systems inCESAR”. In Proceedings of the 5th Intenational Symposium on Programming, pp.337-350, 1981.

[Quin93] Quinlan, J.R. “C4.5: Programs for Machine Learning”, Morgan Kaufman, 1993

[Raja95] Rajan, S., Shankar, N., Srivas, M.K. “An Integration of Model Checking withAutomated Proof Checking”. In Proceedings of the 7th International Conferenceon Computer Aided Verification, LNCS Vol. 939, pp. 84-97, Springer-Verlag,1995.

[Ries02] Riesco, M. “Especificación de Sistemas Reactivos Síncronos utilizando EstelleSíncrono”, Tesis Doctoral, Departamento de Informática, Universidad de Oviedo,2002.

[Ries03] Riesco, M., Tuya, J. “Synchronous Estelle: Just Another SynchronousLanguage?” In Proceedings of Synchronous Languages, Applications andProgramming, pp. 69-83, 2003

[Riva00a] Riva, C. de la, Tuya, J., de Diego, J.R. “Translating SA/RT Models toSynchronous Reactive Systems: An Approximation to Modular VerificationUsing the SMV Model Checker” In Proceedings of Third International AndereiErshov Memorial Conference PSI’99, LNCS, Vol. 1755, pp. 493-502, SpringerVerlag, 2000.

[Riva00b] Riva, C. de la, Tuya, J., de Diego, J.R., “Verificación Modular de SistemasReactivos con Abstracciones del Entorno”, In Actas de V Jornadas de Ingenieríadel Software y Bases de Datos, pp. 53-58, 2000

[Riva01a] Riva, C. de la, Tuya, J., de Diego, J.R. “Generación de Restricciones del Entornopara Verificación Modular Utilizando Reglas de Asociación”, In Actas de VIJornadas de Ingeniería del Software y Bases de Datos, pp. 391-403, 2001.

[Riva01b] Riva, C. de la, Tuya, J., de Diego, J.R. “Modular Model Checking of SA/RTModels Using Association Rules” In Proceedings of First International Workshopon Model-based Requirements Engineering, pp.61-68, 2001

[Riva03] Riva, C. de la, Tuya, J., de Diego, J.R. “Generación Automática y Paralela deEntornos en la Verificación de Componentes Software”, In Actas de VIIIJornadas de Ingeniería del Software y Bases de Datos, pp. 35-45, 2003.

Referencias

218

[Roev02] Roever, W.P.de, Boer, F.S. de, Hannemann, U.,Hooman, J.,Lakhnech, Y.,Poel,M., Zwiers, J. “Concurrency Verification: Introduction to Compositional andNoncompositional Methods”. Cambridge Tracts in Theoretical Computer Science54, Cambridge University Press, 2002

[Rusu02] Rusu, V. “Verification using Test Generation Techniques” In Proceedings of theFormal Methods Europe, LNCS; Vol. 2391, pp. 252-271, Springer-Verlag, 2002

[Ruys01] Ruys, T. “Towards Effective Model Checking”. PhD. Thesis, Centre forTelematics and Information Technology, University of Twente, 2001

[Shan97] Shankar, N. “Lazy Compositional Verification” In Compositionality: TheSignificant Difference (COMPOS’97), LNCS, Vol. 1536, Springer-Verlag, 1997

[Shan00] Shankar, N. “Combining Theroem Proving and Model Checking throughtSymbolic Analysis”. In Proceedings of the CONCUR 2000, LNCS Vol. 1877, pp.1-16, Springer, 2000.

[Sist85] Sistla, A.P., Clarke, E.M. “Complexity of Propositional Temporal Logics”Journal of the ACM, 32(3):733-749, 1985

[SPIN03] “SPIN Documentation” http://spinroot.com/spin/whatispin.html.

[Acceso: Septiembre 2003]

[Srik96] Srikant, R., Agrawal, R. “Mining Quantitative Association Rules in LargeRelational Tables” In Proceedings of ACM SIGMOD Conference on Managementof Data pp. 1—12, 1996

[Ston93] Stonebraker, M., Agrawal, R. Dayal, U., Neuhold, E.J., Reuter, A. “The DBMSResearch at CrossRoads” In Proceedings of the Very Large Data Bases(VLDB’93), pp. 688-692, 1993

[Suns81] Sunshine, C.A. editor. “Communication Protocol Modeling”. Artech House,DedHam, MA, 1981

[Tkac03] Tkachuk, O., Dwyer, B., Pasareau, C.S. “Automated Environment Generation forSoftware Model Checking” To appear in Proceedings of the IEEE Conference onAutomated Software Engeneering, 2003

[Thom90] Thomas, W. “Automata on Infinite Objects” In Handbook of TheoreticalComputer Science, Vol. B, pp. 133-191, J. van Leeuwen, ed., Elsevier, 1990

[Tuya97a] Tuya, J., de Diego, J.R., de la Riva, C., Corrales, J.A: “Dynamic Analysis ofSA/RT Models Using SPIN and Modular Verification”, DIMACS Series inDiscrete Mathematics and Theoretical Computer Science, Vol. 32, pp 165—183,1997

[Tuya97b] Tuya, J, de la Riva, C., de Diego, J.R. “CASE Support for Modular Verificationof Synchronous Reactive Systems” In Proceedings of the 2nd InternationalWorkshop on Formal Methods for Industrial Critical Systems, pp. 125-137, 1997

[Valm93a] Valmari, A. “On -the-Fly Verification with Stubborn Sets”. In Proceedings of the5th International Conference on Computer Aided Verification, LNCS, Vol. 697,pp. 397-408, Springer-Verlag, 1993.

[Valm93b] Valmari, A. “ Compositional State Space Generation” In Proceedings of theAdvances in Petri Nets, LNCS, Vol. 674, pp. 427-457, Springer-Verlag, 1993

[Vard86] Vardi, M., Wolper, P. “An Automata-Theoretic Approach to Automatic ProgramVerification”. In Proceedings of the 1st Annual Symposium on Logic in ComputerScience, pp. 332-344, 1986.

[Vitt96] Vitt, J.,Hooman, J. “Assertional Specification and Verification using PVS of theSteam Boiler Control System”. In [Abri96], pp. 453-472, 1996

Referencias

219

[Ward86] Ward, P. “The Transformation Schema: An Extension of the Data Flow Diagramto Represent Control and Timing”. IEEE Transactions on Software Engineering,12(2):198-210, 1986

[West78] West, C.H., Zafiropoulo, P. “Automated Validation of Communications Protocol:the CCITT X.21 Recommendation”. IBM Journal of Research and Development,Vol. 22, pp. 60-71, 1978.

[Wier03] Wieringa, R.J. “Design Methods for Reactive Systems: Yourdon, Statemate andthe UML”. Morgan Kaufman, 2003

[Will96] Willig, A., Schieferdecker, I. “Specifying and Verifying the Steam Boiler ControlSystem with Time Extended LOTOS”, In [Abri96], pp.473-492, 1996.

[Wolp93] Wolper, P., Godefroid, P. “Partial-Orders Methods for Temporal Verification”. InProceedings of the 4th Intenational Conference on Concurrency Theory, LNCS,Vol. 715, pp. 233-246, Springer-Verlag, 1993

[Xu97] Xu, Q., de Roever, W.P., He, J. “The Rely-Guarantee Method fo Verifying SharedVariable Concurrent Programs” Formal Aspect of Computing, 9(2):149-174, 1997

[Yeh93] Yeh, W.J. “Controlling State Explosion in Reachability Analysis”, PhD Thesis,Purdue University, 1993

[Zafi77] Zafiropoulo, P. “A New Approach to Protocol Validation”. In Proceedings of theIntl. Communications Conference ICC’77, Vol II, 1997

cd universidad de oviedodi002.edv.uniovi.es/~claudio/tesis.pdf · resumen los sistemas reactivos...

Documents