Simulacion Textobase

MODELADO DE SISTEMAS MEDIANTE DEVS
Teora y Prctica
Texto base de la asignatura Modelado de Sistemas Discretos de la Ingeniera en Informtica de la UNED
Alfonso Urqua
Departamento de Inform atica y Autom atica Escuela T ecnica Superior de Ingenier a Inform atica Universidad Nacional de Educaci on a Distancia (UNED) Juan del Rosal 16, 28040, Madrid, Espa na aurquia@dia.uned.es http://www.euclides.dia.uned.es
INDICE
1. Introducci on al modelado y la simulaci on
1.1. Introducci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.2. Sistemas, modelos y experimentaci on . . . . . . . . . . . . . . . . . . 11 1.2.1. Denici on de los t erminos modelo y sistema . . . . . . . . 11 1.2.2. Experimentaci on con el sistema real . . . . . . . . . . . . . . . 12 1.2.3. Experimentaci on con el modelo . . . . . . . . . . . . . . . . . 13 1.3. Tipos de modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.3.1. Modelos mentales . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.3.2. Modelos verbales . . . . . . . . . . . . . . . . . . . . . . . . . 15 1.3.3. Modelos f sicos . . . . . . . . . . . . . . . . . . . . . . . . . . 15 1.3.4. Modelos matem aticos . . . . . . . . . . . . . . . . . . . . . . . 15 1.4. Clasicaci on de los modelos matem aticos . . . . . . . . . . . . . . . . 16 1.4.1. Determinista o estoc astico . . . . . . . . . . . . . . . . . . . . 16 1.4.2. Est atico o din amico . . . . . . . . . . . . . . . . . . . . . . . . 17 1.4.3. Tiempo continuo o discreto . . . . . . . . . . . . . . . . . . . 18 1.5. Niveles en el conocimiento de los sistemas . . . . . . . . . . . . . . . 19 1.5.1. Niveles en el conocimiento de un sistema . . . . . . . . . . . . 19 1.5.2. An alisis, inferencia y dise no . . . . . . . . . . . . . . . . . . . 20 1.6. Jerarqu a en la especicaci on de sistemas . . . . . . . . . . . . . . . . 21 1.6.1. Nivel 0 - Marco de observaci on . . . . . . . . . . . . . . . . . 22 1.6.2. Nivel 1 - Comportamiento E/S . . . . . . . . . . . . . . . . . 23
1.6.3. Nivel 2 - Funci on E/S . . . . . . . . . . . . . . . . . . . . . . 24 1.6.4. Nivel 3 - Transici on de estado . . . . . . . . . . . . . . . . . . 24 1.6.5. Nivel 4 - Componentes acoplados . . . . . . . . . . . . . . . . 26 1.7. Modelado modular y jer arquico . . . . . . . . . . . . . . . . . . . . . 26 1.8. Marco formal para el modelado y la simulaci on . . . . . . . . . . . . 28
1.8.1. Sistema fuente . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 1.8.2. Base de datos del comportamiento . . . . . . . . . . . . . . . 29 1.8.3. Marco experimental . . . . . . . . . . . . . . . . . . . . . . . . 29 1.8.4. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 1.8.5. Simulador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 1.8.6. Relaci on de modelado: validez . . . . . . . . . . . . . . . . . . 33 1.8.7. Relaci on de simulaci on: correcci on . . . . . . . . . . . . . . . . 34 1.9. Ejercicios de autocomprobaci on . . . . . . . . . . . . . . . . . . . . . 35 1.10. Soluciones a los ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . 37 2. Formalismos de modelado y sus simuladores 47
2.1. Introducci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 2.2. Modelado y simulaci on de tiempo discreto . . . . . . . . . . . . . . . 51 2.2.1. Descripci on de modelos de tiempo discreto . . . . . . . . . . . 52 2.2.2. Aut omatas celulares . . . . . . . . . . . . . . . . . . . . . . . 54 2.2.3. Aut omatas conmutados . . . . . . . . . . . . . . . . . . . . . 58
2.2.4. Redes lineales de tiempo discreto . . . . . . . . . . . . . . . . 60 2.3. Modelado y simulaci on de tiempo continuo . . . . . . . . . . . . . . . 62 2.3.1. Variables y ecuaciones . . . . . . . . . . . . . . . . . . . . . . 63 2.3.2. Algoritmo para la simulaci on . . . . . . . . . . . . . . . . . . 66
2.3.3. Causalidad computacional . . . . . . . . . . . . . . . . . . . . 71 2.3.4. M etodos de integraci on num erica . . . . . . . . . . . . . . . . 80 2.4. Modelado y simulaci on de eventos discretos . . . . . . . . . . . . . . . 85
INDICE
2.4.1. Aut omata celular de eventos discretos . . . . . . . . . . . . . . 85 2.4.2. Simulaci on de eventos discretos . . . . . . . . . . . . . . . . . 89 2.4.3. Elementos del modelo . . . . . . . . . . . . . . . . . . . . . . 93 2.4.4. Descripci on del funcionamiento del sistema . . . . . . . . . . . 97 2.5. Ejercicios de autocomprobaci on . . . . . . . . . . . . . . . . . . . . . 102 2.6. Soluciones a los ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . 106 3. DEVS cl asico 121
3.1. Introducci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 3.2. Modelos DEVS at omicos SISO . . . . . . . . . . . . . . . . . . . . . . 125 3.2.1. Modelo de un sistema pasivo . . . . . . . . . . . . . . . . . . . 130 3.2.2. Modelo de un sistema acumulador . . . . . . . . . . . . . . . . 132 3.2.3. Modelo de un generador de eventos . . . . . . . . . . . . . . . 136 3.2.4. Modelo de un contador binario . . . . . . . . . . . . . . . . . 138 3.2.5. Modelo de un proceso . . . . . . . . . . . . . . . . . . . . . . 139 3.3. Modelos DEVS at omicos MIMO . . . . . . . . . . . . . . . . . . . . . 142 3.3.1. Modelo de un conmutador . . . . . . . . . . . . . . . . . . . . 143 3.4. Modelos DEVS acoplados modularmente . . . . . . . . . . . . . . . . 145 3.4.1. Modelo de una secuencia de etapas . . . . . . . . . . . . . . . 149 3.4.2. Modelo de una red de conmutaci on . . . . . . . . . . . . . . . 152 3.5. Simulador abstracto para DEVS . . . . . . . . . . . . . . . . . . . . . 153 3.5.1. Estructura del simulador abstracto . . . . . . . . . . . . . . . 153 3.5.2. Intercambio de mensajes . . . . . . . . . . . . . . . . . . . . . 155 3.5.3. Devs-simulator . . . . . . . . . . . . . . . . . . . . . . . . . . 156 3.5.4. Devs-coordinator . . . . . . . . . . . . . . . . . . . . . . . . . 160 3.5.5. Devs-root-coordinator . . . . . . . . . . . . . . . . . . . . . . 168 3.6. Modelos DEVS acoplados no modularmente . . . . . . . . . . . . . . 169 3.6.1. DEVS multicomponente . . . . . . . . . . . . . . . . . . . . . 170
3.6.2. MultiDEVS denido como DEVS . . . . . . . . . . . . . . . . 172 3.6.3. Modelo multiDEVS del Juego de la Vida . . . . . . . . . . . . 174 3.6.4. Modularizaci on . . . . . . . . . . . . . . . . . . . . . . . . . . 175 3.7. Ejercicios de autocomprobaci on . . . . . . . . . . . . . . . . . . . . . 178 3.8. Soluciones a los ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . 183 4. DEVS paralelo 197
4.1. Introducci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 4.2. Modelos at omicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 4.2.1. Modelo de un proceso con una cola . . . . . . . . . . . . . . . 203 4.3. Modelos compuestos . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 4.4. Ejercicios de autocomprobaci on . . . . . . . . . . . . . . . . . . . . . 212 4.5. Soluciones a los ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . 214 5. Modelado h brido en DEVS 227
5.1. Introducci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 5.2. Formalismo DEV&DESS . . . . . . . . . . . . . . . . . . . . . . . . . 231 5.2.1. Detecci on de los eventos en el estado . . . . . . . . . . . . . . 232 5.2.2. Modelos at omicos . . . . . . . . . . . . . . . . . . . . . . . . . 233 5.2.3. Simulaci on de modelos at omicos . . . . . . . . . . . . . . . . . 234 5.2.4. Modelos compuestos . . . . . . . . . . . . . . . . . . . . . . . 236 5.2.5. Proceso de llenado de barriles . . . . . . . . . . . . . . . . . . 236 5.3. Formalismos b asicos y DEV&DESS . . . . . . . . . . . . . . . . . . . 240 5.3.1. Formalismo DESS . . . . . . . . . . . . . . . . . . . . . . . . . 241 5.3.2. Formalismo DTSS . . . . . . . . . . . . . . . . . . . . . . . . 242 5.3.3. Formalismo DEVS cl asico . . . . . . . . . . . . . . . . . . . . 244 5.4. Modelado multiformalismo . . . . . . . . . . . . . . . . . . . . . . . . 245 5.5. Tratamiento de los eventos en el estado . . . . . . . . . . . . . . . . . 249
INDICE
5.6. Simulador para modelos DESS . . . . . . . . . . . . . . . . . . . . . . 250 5.6.1. M etodos num ericos de integraci on causales . . . . . . . . . . . 250 5.6.2. M etodos num ericos de integraci on no causales . . . . . . . . . 252 5.7. Ejercicios de autocomprobaci on . . . . . . . . . . . . . . . . . . . . . 255 5.8. Soluciones a los ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . 259 6. DEVSJAVA 267
6.1. Introducci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 6.2. Paquetes en DEVSJAVA 3.0 . . . . . . . . . . . . . . . . . . . . . . . 271 6.3. Modelos SISO en DEVS cl asico . . . . . . . . . . . . . . . . . . . . . 273 6.3.1. Sistema pasivo . . . . . . . . . . . . . . . . . . . . . . . . . . 273 6.3.2. Sistema acumulador . . . . . . . . . . . . . . . . . . . . . . . 275 6.3.3. Generador de eventos . . . . . . . . . . . . . . . . . . . . . . . 277 6.3.4. Contador binario . . . . . . . . . . . . . . . . . . . . . . . . . 279 6.4. Clases y m etodos en DEVSJAVA . . . . . . . . . . . . . . . . . . . . 280 6.4.1. Clases contenedor . . . . . . . . . . . . . . . . . . . . . . . . . 280 6.4.2. Clases DEVS . . . . . . . . . . . . . . . . . . . . . . . . . . . 280 6.4.3. Clases DEVS SISO . . . . . . . . . . . . . . . . . . . . . . . . 285 6.5. Modelos DEVS at omicos . . . . . . . . . . . . . . . . . . . . . . . . . 288 6.5.1. Modelo de un recurso . . . . . . . . . . . . . . . . . . . . . . . 288 6.5.2. Modelo de un proceso con una cola . . . . . . . . . . . . . . . 291 6.5.3. Modelo de un conmutador . . . . . . . . . . . . . . . . . . . . 292 6.5.4. Modelo de un generador . . . . . . . . . . . . . . . . . . . . . 294 6.5.5. Modelo de un generador aleatorio . . . . . . . . . . . . . . . . 295 6.5.6. Modelo de un transductor . . . . . . . . . . . . . . . . . . . . 297 6.6. Modelos DEVS compuestos y jer arquicos . . . . . . . . . . . . . . . . 300 6.6.1. Modelo de una secuencia de etapas . . . . . . . . . . . . . . . 300 6.6.2. Marco experimental . . . . . . . . . . . . . . . . . . . . . . . . 301
6.6.3. Modelo de una red de conmutaci on . . . . . . . . . . . . . . . 304 6.7. SimView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306 6.8. Ejercicios de autocomprobaci on . . . . . . . . . . . . . . . . . . . . . 312 6.9. Soluciones a los ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . 315
TEMA 1 AL MODELADO INTRODUCCION Y LA SIMULACION
1.1. Introducci on 1.2. Sistemas, modelos y experimentaci on 1.3. Tipos de modelos 1.4. Clasicaci on de los modelos matem aticos 1.5. Niveles en el conocimiento de los sistemas 1.6. Jerarqu a en la especicaci on de sistemas 1.7. Modelado modular y jer arquico 1.8. Marco formal para el modelado y la simulaci on 1.9. Ejercicios de autocomprobaci on 1.10. Soluciones a los ejercicios
AL MODELADO Y LA SIMULACION INTRODUCCION
OBJETIVOS DOCENTES Una vez estudiado el contenido del tema deber a saber: Discutir los conceptos sistema, modelo y simulaci on. Discutir en qu e situaciones el modelado y la simulaci on son t ecnicas adecuadas para el estudio de sistemas. Describir y comparar los diferentes tipos de modelos. Comparar y reconocer los distintos tipos de modelos matem aticos. Discutir los niveles en el conocimiento de los sistemas de la clasicaci on de Klir, y su relaci on con los conceptos an alisis, inferencia y dise no de sistemas. Discutir los niveles en la especicaci on de sistemas (clasicaci on de Zeigler). Discutir las entidades y las relaciones b asicas del marco formal para el modelado y la simulaci on.
1.1.
INTRODUCCION
En este primer tema se denen conceptos fundamentales en el a mbito del modelado y la simulaci on, como son modelo, sistema, experimento y simulaci on. Se describir an cuatro tipos diferentes de modelos, uno de los cuales es el empleado en simulaci on: el modelo matem atico. Tambi en se discutir an varias clasicaciones de los modelos matem aticos, realizadas atendiendo a diferentes criterios. Se describir a una clasicaci on en cuatro niveles del conocimiento acerca de un sistema, a partir de la cual se denir an tres actividades relacionadas con los sistemas: el an alisis, la inferencia y el dise no. Finalmente, se plantear a una clasicaci on de los niveles en la descripci on de un sistema, en el ambito del modelado y la simulaci on. Esta discusi on motivar a la explicaci on de conceptos tales como modularidad y jerarqu a en la descripci on de los modelos, as como la descripci on de las entidades y relaciones b asicas del modelado y la simulaci on.
1.2.
SISTEMAS, MODELOS Y EXPERIMENTACION
En esta secci on se denen los t erminos modelo y sistema. Asimismo, se muestran dos formas de estudiar los sistemas. La primera es mediante experimentaci on con el sistema real. La segunda es mediante la realizaci on de un modelo del sistema real y la experimentaci on con el modelo. Veremos que, en ocasiones, esta segunda forma es la u nica posible.
1.2.1.
Denici on de los t erminos modelo y sistema
En el sentido amplio del t ermino, puede considerarse que un modelo es una representaci on de un sistema desarrollada para un prop osito espec co. Puesto que la nalidad de un modelo es ayudarnos a responder preguntas sobre un determinado sistema, el primer paso en la construcci on de un modelo deber a ser denir cu al es el sistema y cu ales son las preguntas. En este contexto, se entiende por sistema cualquier objeto o conjunto de objetos cuyas propiedades se desean estudiar.
11
Con una denici on tan amplia, cualquier fuente potencial de datos puede considerarse un sistema. Algunos ejemplos de sistema son: Una planta de fabricaci on con m aquinas, personal, dispositivos de transporte y almac en. El servicio de emergencias de un hospital, incluyendo al personal, las salas, el equipamiento y el transporte de los pacientes. Una red de ordenadores con servidores, clientes, dispositivos de disco, impresoras, etc. Un supermercado con control de inventario, cajeros y atenci on al cliente. Un parque tem atico con atracciones, tiendas, restaurantes, trabajadores, clientes y aparcamientos.
1.2.2.
Experimentaci on con el sistema real
Un procedimiento para conocer el comportamiento de los sistemas es la experimentaci on. De hecho, este ha sido el m etodo empleado durante siglos para avanzar en el conocimiento: plantear las preguntas adecuadas acerca del comportamiento de los sistemas y responderlas mediante experimentaci on. Puede considerarse que un experimento es el proceso de extraer datos de un sistema sobre el cual se ha ejercido una acci on externa. Por ejemplo, el encargado de un supermercado puede ensayar diferentes procedimientos de control del inventario y de distribuci on del personal, para determinar qu e combinaciones demuestran ser m as rentables y proporcionan un mejor servicio. Cuando es posible trabajar directamente con el sistema real, el m etodo experimental presenta indudables ventajas. Sin embargo, para que los resultados del experimento sean v alidos, debe garantizarse que no existen variables ocultas confundidas con las variables experimentales. Por ejemplo, continuando con el modelo del supermercado, si la auencia de p ublico durante el periodo en que se experimenta una estrategia de servicio es signicativamente mayor que durante el periodo en que se experimenta la otra, no podr a extraerse ninguna conclusi on v alida sobre el tiempo medio de espera de los clientes en la cola de las cajas.
12
1.2.3.
Experimentaci on con el modelo
El m etodo experimental est a basado en s olidos fundamentos cient cos. Sin embargo, tiene sus limitaciones, ya que en ocasiones es imposible o desaconsejable experimentar con el sistema real. En estos casos, el modelado y la simulaci on son las t ecnicas adecuadas para el an alisis del sistema, puesto que, a excepci on de la experimentaci on con el sistema real, la simulaci on es la u nica t ecnica disponible que permite analizar sistemas arbitrarios de forma precisa, bajo diferentes condiciones experimentales. Existen diversas razones por las cuales la experimentaci on con el sistema real puede resultar inviable. Algunas de estas razones son las siguientes: Quiz a la m as evidente de ellas es que el sistema aun no exista f sicamente. Esta situaci on se plantea frecuentemente en la fase de dise no de nuevos sistemas, cuando el ingeniero necesita predecir el comportamiento de los mismos antes de que sean construidos. Otra posible raz on es el elevado coste econ omico del experimento. Consideremos el caso de un empresario que planea ampliar las instalaciones de su empresa, pero que no est a seguro de que la ganancia potencial justique el coste de la ampliaci on. Ciertamente, no ser a razonable que, para salir de dudas, realizara la ampliaci on y luego se volviera atr as si esta demostrara no ser rentable. Una alternativa consiste en simular la operaci on de la conguraci on actual de la empresa, simular la operaci on de la conguraci on alternativa y realizar una comparaci on de los resultados econ omicos de ambas. El experimento puede producir perjuicio o incomodidad. Por ejemplo, experimentar con un nuevo sistema de facturaci on en un aeropuerto puede producir retrasos y problemas imprevisibles que perjudiquen al viajero. En ocasiones el tiempo requerido para la realizaci on del experimento lo hace irrealizable. Casos extremos pueden encontrarse en los estudios geol ogicos o cosmol ogicos, de evoluci on de las especies, sociol ogicos, etc. Algunos experimentos son peligrosos, y por tanto es desaconsejable realizarlos. Por ejemplo, ser a peligroso usar el sistema real para adiestrar a los operarios de una central nuclear acerca de c omo deben reaccionar ante situaciones de emergencia.
13
En ocasiones el experimento requiere modicar variables que en el sistema real o bien no est an accesibles, o bien no pueden ser modicadas en el rango requerido. Con un modelo matem atico adecuado, se pueden ensayar condiciones de operaci on extremas que son impracticables en el sistema real.
1.3.
TIPOS DE MODELOS
Tal como se ha explicado en la secci on anterior, una forma de estudiar los sistemas consiste en experimentar directamente con ellos. Otra forma es realizar un modelo del sistema y emplear el modelo para extraer conclusiones acerca del comportamiento del sistema. Como se explicar a a continuaci on, pueden distinguirse cuatro tipos de modelo (v ease la Figura 1.1): mental, verbal, f sico y matem atico.
SISTEMA
EXPERIMENTAR CON EL SISTEMA REAL
EXPERIMENTAR CON EL MODELO DEL SISTEMA
MODELO MENTAL
MODELO VERBAL
MODELO FSICO
MODELO MATEMTICO
SOLUCIN ANALTICA
SIMULACIN
Figura 1.1: Formas de estudiar un sistema.
1.3.1.
Modelos mentales
En nuestra vida cotidiana empleamos continuamente modelos mentales para comprender y predecir el comportamiento de los sistemas. Por ejemplo, considerar que alguien es amable constituye un modelo del comportamiento de esa persona. Este modelo nos ayuda a responder, por ejemplo, a la pregunta de c omo reaccionar a si le pedimos un favor. Tambi en disponemos de modelos de los sistemas t ecnicos, que est an basados en la intuici on y en la experiencia. Por ejemplo, aprender a conducir un coche consiste parcialmente en desarrollar un modelo mental de las propiedades de la conducci on
14
del coche. Asimismo, un operario trabajando en determinado proceso industrial sabe c omo el proceso reacciona ante diferentes acciones: el operario, mediante el entrenamiento y la experiencia, ha desarrollado un modelo mental del proceso.
1.3.2.
Modelos verbales
Otro tipo de modelos son los modelos verbales, en los cuales el comportamiento del sistema es descrito mediante palabras: si se aprieta el freno, entonces la velocidad del coche se reduce. Los sistemas expertos son ejemplos de modelos verbales formalizados. Es importante diferenciar entre los modelos mentales y los verbales. Por ejemplo, nosotros usamos un modelo mental de la din amica de la bicicleta cuando la conducimos. Sin embargo, no es sencillo convertirlo en un modelo verbal.
1.3.3.
Modelos f sicos
Adem as de los modelos mentales y verbales, existe otro tipo de modelos que tratan de imitar al sistema real. Son los modelos f sicos, tales como las maquetas a escala que construyen los arquitectos, dise nadores de barcos o aeronaves, para comprobar las propiedades est eticas, aerodin amicas, etc.
1.3.4.
Modelos matem aticos
Finalmente, existe un cuarto tipo de modelo: el modelo matem atico. En el las relaciones entre las magnitudes del sistema que pueden ser observadas (distancias, velocidades, ujos, etc.) son descritas mediante relaciones matem aticas. La mayor a de las teor as sobre las leyes de la naturaleza son descritas empleando modelos matem aticos. Por ejemplo, para el sistema masa puntual, la Ley de Newton del movimiento describe la relaci on entre la fuerza y la aceleraci on. Asimismo, para el sistema resistencia el ectrica, la Ley de Ohm describe la relaci on entre la ca da de tensi on y la corriente el ectrica. En algunos casos, las relaciones matem aticas que constituyen los modelos son sencillas y pueden resolverse anal ticamente. Sin embargo, en la mayor a de los casos los modelos no pueden resolverse anal ticamente y deben estudiarse con ayuda del ordenador aplicando m etodos num ericos. Este experimento num erico realizado sobre el modelo matem atico recibe el nombre de simulaci on.
15
Al igual que se distingue entre el sistema real y el experimento, es conveniente distinguir entre la descripci on del modelo y la descripci on del experimento. Esto es as tanto desde el punto de vista conceptual como pr actico. Sin embargo, en el caso de los modelos matem aticos esta separaci on implica cierto riesgo: el empleo del modelo matem atico en unas condiciones experimentales para las cuales no es v alido. Cuando se trabaja con sistemas reales este riesgo nunca existe, ya que un sistema real es v alido para cualquier experimento. Por el contrario, cualquier modelo matem atico est a fundamentado en un determinado conjunto de hip otesis. Cuando las condiciones experimentales son tales que no se satisfacen las hip otesis del modelo, este deja de ser v alido. Para evitar este problema, la descripci on del modelo matem atico debe ir acompa n ada de la documentaci on de su marco experimental. Este establece el conjunto de experimentos para el cual el modelo matem atico es v alido.
1.4.
DE LOS MODELOS MATEMATICOS CLASIFICACION
La nalidad de un estudio de simulaci on (es decir, las preguntas que debe responder) condiciona las hip otesis empleadas en la construcci on del modelo y estas a su vez determinan qu e tipo de modelo resulta m as adecuado. De hecho, un mismo sistema puede ser modelado de m ultiples formas, empleando diferentes tipos de modelos, dependiendo de la nalidad perseguida en cada caso. Existen diferentes clasicaciones de los modelos matem aticos, atendiendo a diferentes criterios. A continuaci on, se describen algunas de las clasicaciones m as com unmente usadas.
1.4.1.
Determinista o estoc astico
Un modelo matem atico es determinista cuando todas sus variables de entrada son deterministas. Es decir, el valor de cada una de ellas es conocido en cada instante. Un ejemplo de modelo determinista es un servicio al cual los clientes acceden ordenadamente, cada uno a una hora preestablecida (de acuerdo, por ejemplo, con un libro de citas), y en el cual el tiempo de servicio a cada cliente est a igualmente
16
preestablecido de antemano. No existe incertidumbre en la hora de inicio o de nalizaci on de cada servicio. Por el contrario, un modelo es estoc astico cuando alguna de sus variables de entrada es aleatoria. Las variables del modelo calculadas a partir de variables aleatorias son tambi en aleatorias. Por ello, la evoluci on de este tipo de sistemas debe estudiarse en t erminos probabil sticos. Por ejemplo, consid erese el modelo de un parking, en el cual las entradas y salidas de coches se producen en instantes de tiempo aleatorios. La aleatoriedad de estas variables se propaga a trav es de la l ogica del modelo, de modo que las variables dependientes de ellas tambi en son aleatorias. Este ser a el caso, por ejemplo, del tiempo que transcurre entre que un cliente deja aparcado su veh culo y lo recoge (tiempo de aparcamiento), el n umero de veh culos que hay aparcados en un determinado instante, etc. Es importante tener en cuenta que realizar una u nica r eplica de una simulaci on estoc astica es equivalente a realizar un experimento f sico aleatorio una u nica vez. Por ejemplo, si se realiza una simulaci on del comportamiento del parking durante 24 horas, es equivalente a observar el funcionamiento del parking real durante 24 horas. Si se repite la observaci on al d a siguiente, seguramente los resultados obtenidos ser an diferentes, y lo mismo sucede con la simulaci on: si se realiza una segunda r eplica independiente de la primera, seguramente los resultados ser an diferentes. La consecuencia que debe extraerse de ello es que el dise no y el an alisis de los experimentos de simulaci on estoc asticos debe hacerse teniendo en cuenta esta incertidumbre en los resultados. Es decir, debe hacerse empleando t ecnicas estad sticas.
1.4.2.
Est atico o din amico
Un modelo de simulaci on est atico es una representaci on de un sistema en un instante de tiempo particular, o bien un modelo que sirve para representar un sistema en el cual el tiempo no juega ning un papel. Por otra parte, un modelo de simulaci on din amico representa un sistema que evoluciona con el tiempo.
17
1.4.3.
Tiempo continuo o discreto
Un modelo de tiempo continuo est a caracterizado por el hecho de que el valor de sus variables de estado puede cambiar innitas veces (es decir, de manera continua) en un intervalo nito de tiempo. Un ejemplo es el nivel de agua en un dep osito. Por el contrario, en un modelo de tiempo discreto los cambios pueden ocurrir u nicamente en instantes separados en el tiempo. Sus variables de estado pueden cambiar de valor s olo un n umero nito de veces por unidad de tiempo. Pueden denirse modelos con algunas de sus variables de estado de tiempo continuo y las restantes de tiempo discreto. Este tipo de modelo, con parte de tiempo continuo y parte de tiempo discreto, de llama modelo h brido. Tal como se ha indicado al comienzo de la secci on, la decisi on de realizar un modelo continuo o discreto depende del objetivo espec co del estudio y no del sistema en s . Un ejemplo de ello lo constituyen los modelos del ujo de tr aco de veh culos. Cuando las caracter sticas y el movimiento de los veh culos individuales son relevantes, puede realizarse un modelo de tiempo discreto. En caso contrario, puede resultar m as sencillo realizar un modelo de tiempo continuo. En este punto es conveniente realizar una consideraci on acerca de los modelos de tiempo continuo y discreto. Al igual que las variables continuas (aquellas que pueden tomar cualquier valor intermedio en su rango de variaci on) son una idealizaci on, tambi en lo son los modelos de tiempo continuo. Cualquiera que sea el procedimiento que se emplee para medir el valor de una variable, tendr a un l mite de precisi on. Este l mite implica la imposibilidad de obtener una medida continua y supone que, en la pr actica, todas las medidas son discretas. Igualmente, los ordenadores trabajan con n umeros representados mediante un n umero nito de d gitos. Por otra parte, al simular mediante un computador digital un modelo de tiempo continuo, debe discretizarse el eje temporal a n de evitar el problema de los innitos cambios en el valor de los estados. Esta discretizaci on constituye una aproximaci on (con su error asociado) que transforma el modelo de tiempo continuo en un modelo de tiempo discreto. Por ejemplo, si se discretiza el eje temporal del modelo de tiempo continuo dx = f (x, u, t) dt (1.1)
18
con un intervalo de discretizaci on t, se obtiene (empleando el m etodo de Euler expl cito) el modelo de tiempo discreto siguiente:
xK +1 xK = f (xK , uK , tK ) xK +1 = xK + t f (xK , uK , tK ) t 1.5. NIVELES EN EL CONOCIMIENTO DE LOS SISTEMAS
(1.2)
En la teor a de sistemas se diferencian dos aspectos fundamentales, ortogonales entre s , en lo que respecta a la especicaci on de los sistemas. Por una parte, se encuentra el formalismo empleado para la especicaci on del sistema, que determina el tipo de modelo matem atico a emplear para describir el sistema. Por ejemplo, si va a emplearse un modelo de tiempo discreto, de tiempo continuo o h brido. Por otra parte, se encuentra el nivel de conocimiento que poseemos del sistema. A este respecto, G.J. Klir estableci o una clasicaci on del conocimiento que puede poseerse acerca de un sistema. Distingui o cuatro niveles en el conocimiento, de modo que en cada nivel se conocen aspectos importantes del sistema que no se conocen en los niveles inferiores del conocimiento.
1.5.1.
Niveles en el conocimiento de un sistema
De acuerdo con la clasicaci on propuesta por G.J. Klir, los cuatro niveles en el conocimiento de un sistema son los siguientes: Nivel 0 - Fuente. En este nivel, se identica la porci on del mundo real que vamos a modelar y las maneras mediante las cu ales vamos a observarlo. Dicha porci on del mundo real puede denominarse sistema fuente, puesto que constituye una fuente de datos. Nivel 1 - Datos. En este nivel, disponemos de una base de datos de medidas y observaciones del sistema fuente. Nivel 2 - Generaci on. En este nivel, somos capaces de recrear estos datos usando una representaci on m as compacta, por ejemplo, mediante f ormulas matem aticas. Puesto que es posible generar un determinado conjunto de datos
19
mediante diferentes f ormulas y empleando otros procedimientos, la manera en concreto a la que hemos llegado para generar los datos constituye un conocimiento que no ten amos al Nivel 1 (datos). En el contexto del modelado y la simulaci on, cuando se habla de un modelo, frecuentemente nos referimos a una representaci on del conocimiento a este nivel. Nivel 3 - Estructura. En este u ltimo nivel, disponemos de un tipo muy espec co de sistema de generaci on de datos. Es decir, sabemos c omo generar los datos observados en el Nivel 1 de una manera m as espec ca: en t erminos de componentes interconectados entre s .
1.5.2.
An alisis, inferencia y dise no
Esta clasicaci on proporciona una perspectiva unicada de varios conceptos. Por ejemplo, desde esta perspectiva hay u nicamente tres tipos b asicos de problemas relacionados con sistemas, y estos implican moverse entre los distintos niveles del conocimiento. Los tres tipos b asicos de problema son los siguientes: En el an alisis de un sistema se intenta comprender el comportamiento del sistema, existente o hipot etico, bas andose para ello en el conocimiento que se tiene de su estructura. En la inferencia sobre un sistema se intenta conocer la estructura del sistema a partir de las observaciones que pueden realizarse del mismo. En el dise no de un sistema se investigan diferentes estructuras alternativas para un sistema completamente nuevo o para el redise no de uno ya existente. La idea central es que cuando nos movemos hacia niveles inferiores del conocimiento, como sucede en el caso del an alisis de sistemas, no estamos generando conocimiento nuevo. Estamos u nicamente haciendo expl cito lo que ya est a impl cito en la descripci on que tenemos. Podr a considerarse que hacer expl cito un conocimiento impl cito ayuda a comprender o entender mejor el sistema, con lo cual es una forma de adquirir nuevo conocimiento. Sin embargo, ganar esa clase de conocimiento subjetivo, dependiente de la persona que realiza el modelo, no se considera (en este contexto) adquirir conocimiento nuevo. Abundando en la idea anterior, una forma de an alisis de sistemas en el ambito del modelado y la simulaci on es la simulaci on por ordenador, que genera datos de
20
acuerdo a las instrucciones proporcionadas por un modelo. Aunque con ello no se genera nuevo conocimiento, pueden salir a relucir propiedades interesantes de las que no eramos conscientes antes de iniciar el an alisis. Por otra parte, la inferencia acerca de los sistemas y el dise no de sistemas son problemas que requieren ascender en los niveles de conocimiento. En ambos casos, tenemos una descripci on del sistema de bajo nivel y queremos obtener una descripci on equivalente de m as alto nivel. En la inferencia, disponemos de una base de datos del comportamiento del sistema fuente y tratamos de encontrar una representaci on del conocimiento al Nivel 2 (generaci on) o al Nivel 3 (estructura), que nos permita recrear los datos de que disponemos. Este proceso de denomina construcci on del modelo. En el caso de la inferencia, el sistema fuente existe. Sin embargo, en el caso del dise no el sistema fuente no existe y el objetivo es construir un sistema que tenga la funcionalidad deseada, es decir, funcione de la manera deseada. Si el objetivo es llegar a construir el sistema, debe llegarse a un Nivel 3 (estructura) del conocimiento, puesto que la construcci on se realizar a mediante la interconexi on de diferentes componentes tecnol ogicos. Finalmente, el proceso denominado ingenier a inversa tiene elementos tanto de inferencia como de dise no. Para hacer ingenier a inversa de un sistema existente, en primer lugar se realiza un gran n umero de observaciones de el. A partir de estas observaciones, se inere el comportamiento del sistema y se dise na una estructura alternativa que tenga ese comportamiento.
1.6.
DE SISTEMAS JERARQU IA EN LA ESPECIFICACION
Los cuatro niveles epistemol ogicos (del conocimiento) que han sido descritos en la Secci on 1.5 fueron propuestos por G.J. Klir a principios de la d ecada de 1970. Aproximadamente en la misma fecha, B.P. Zeigler introdujo una clasicaci on similar, pero m as enfocada al modelado y la simulaci on. Esta jerarqu a en la especicaci on de sistemas, a diferencia de la propuesta por Klir, emplea el concepto de sistema din amico y reconoce que la simulaci on est a relacionada con la din amica, es decir, con la forma en que los sistemas se comportan en el tiempo. Asimismo, reconoce que conceptualmente puede considerarse que los sistemas tienen interfaces, a trav es de las cuales pueden interactuar con otros sistemas. Los
21
sistemas reciben est mulos ordenados en el tiempo a trav es de sus puertos de entrada y responden a trav es de sus puertos de salida. Obs ervese que el t ermino puerto conlleva impl citamente una manera espec ca de interpretar la interacci on con el sistema, estimul andolo a trav es de sus puertos de entrada y observ andolo a trav es de sus puertos de salida. Las est mulos aplicados a las entradas del sistema, ordenados en el tiempo, se denominan trayectorias de entrada, mientras que las observaciones realizadas en las salidas del sistema, ordenadas en el tiempo, se denominan trayectorias de salida. Por denici on, los puertos son los u nicos canales a trav es de los cuales se puede interaccionar con el sistema. Esto es equivalente a considerar que los sistemas son modulares. La jerarqu a en la especicaci on de los sistemas consta de los cinco niveles descritos a continuaci on. Un determinado sistema puede ser descrito de varias maneras, correspondientes a diferentes niveles en su especicaci on. Cuanto mayor es el nivel en la descripci on de un sistema, mayor es el conocimiento sobre el que se hace expl cito en dicha descripci on.
1.6.1.
Nivel 0 - Marco de observaci on
En este nivel, sabemos c omo estimular las entradas del sistema, qu e variables de salida medir y c omo observarlas en funci on del tiempo. La descripci on del sistema a este nivel es como una caja negra, cuyo comportamiento s olo es observable a trav es de sus puertos de entrada y de salida. Este nivel en la especicaci on del sistema se corresponde con el Nivel 0 - Fuente de la clasicaci on de Klir. En este nivel de conocimiento del sistema, suele darse la circunstancia de que, para unas mismas trayectorias de entrada, se obtienen diferentes trayectorias de salida. Es decir, si se replica el experimento varias veces, usando en todos los casos unas determinadas trayectorias de entrada, en las sucesivas r eplicas se obtienen diferentes trayectorias de salida. En la Figura 1.2 se muestra un ejemplo de especicaci on al Nivel 0 de un sistema consistente en un bosque, sobre el cual caen rayos y hay viento y lluvia. Estas variables constituyen los puertos de entrada: los rayos, la lluvia y el viento. El humo producido por un incendio en el bosque es el puerto de salida (v ease la Figura 1.2a). Los valores que puede tomar la variable humo, denominados el rango de la variable, se obtienen aplicando alg un procedimiento de medida, por ejemplo, midiendo la densidad de part culas en el aire.
22
rayos
humo
rayos lluvia viento
humo
t0
t0
Bosque
rayos
humo
t0
t0
Figura 1.2: Modelo de un bosque: a) especicado en el Nivel 0 - Marco de observaci on; y b) algunas parejas de trayectorias de entrada y salida.
Obs ervese que la elecci on de las variables que incluimos en los puertos, as como su orientaci on (si son puertos de entrada o de salida), depende de cu ales sean nuestros objetivos al realizar el modelo.
1.6.2.
Nivel 1 - Comportamiento E/S
En la Figura 1.2b se muestran algunos ejemplos de trayectorias de entrada y de salida. La trayectoria de entrada muestra la ca da de un rayo en el instante t0 . Es el u nico rayo que cae en el periodo de tiempo representado. La evoluci on del humo (trayectoria de salida) mostrada en la parte superior de la Figura 1.2b parece indicar que el fuego se propaga, y se hace m as y m as extenso con el paso del tiempo. Por el contrario, la evoluci on del humo en la parte inferior de la Figura 1.2b parece indicar que el fuego se extingue transcurrido un cierto tiempo. Esta situaci on, en la cual se obtienen diferentes trayectorias de salida para una misma trayectoria de entrada, es t pica del conocimiento en el Nivel 1. La colecci on de todos los pares de trayectorias de entrada y salida, recogidas mediante observaci on, se llama comportamiento de entrada/salida del sistema (abreviadamente, comportamiento de E/S) y corresponde con el Nivel 1 de especicaci on del sistema.
23
1.6.3.
Nivel 2 - Funci on E/S
Supongamos ahora que somos capaces de predecir cu al ser a la evoluci on del humo producido en respuesta a la ca da de un rayo. Por ejemplo, sabemos que si la vegetaci on est a h umeda, el fuego se extinguir a r apidamente. Si est a seca, se propagar a. El conocimiento acerca de este factor determinante de la respuesta (vegetaci on seca o h umeda), que es el estado inicial en que se encuentra el sistema, supone un conocimiento en el Nivel 2 - Funci on E/S. En el Nivel 2 se dispone del conocimiento de los niveles inferiores y adem as se conoce la inuencia del estado inicial en la respuesta del sistema. Conocido el estado en que se encuentra inicialmente el sistema, se conoce la relaci on funcional entre las trayectorias de entrada y de salida. En otras palabras, el estado inicial permite determinar de manera un voca cu al es la trayectoria de salida para una determinada trayectoria de entrada (v ease la Figura 1.3).
1.6.4.
Nivel 3 - Transici on de estado
En el Nivel 3 de la especicaci on del sistema, no s olo se aporta informaci on sobre c omo afecta el estado inicial a la trayectoria de salida, sino tambi en c omo evoluciona el estado en respuesta a la trayectoria de entrada. Los dos ejemplos mostrados en la Figura 1.4 tratan de ilustrar este concepto. En la parte superior de la gura se presenta la situaci on en la cual el bosque est a en el estado {vegetaci on seca, sin quemar} cuando en el instante t0 cae un rayo. El estado en el que se encuentra el bosque cuando cae el segundo rayo es {vegetaci on seca, quemado}. Este estado reeja el hecho de que el fuego ha estado ardiendo en el intervalo de tiempo que va desde t0 hasta t1 . Dado que el bosque se encuentra en un estado diferente, el efecto del segundo rayo es diferente al efecto del primero: puesto que cuando cae el segundo rayo queda poco por quemar, el efecto del segundo rayo es despreciable. Por el contrario, en la parte inferior de la Figura 1.4 se muestra la situaci on en la cual el bosque est a en el estado {vegetaci on h umeda, sin quemar} cuando cae el primer rayo. El rayo no produce un incendio importante, pero seca la vegetaci on, de modo que el estado cuando cae el segundo rayo es {vegetaci on seca, sin quemar}. Por este motivo, la ca da del segundo rayo produce un incendio importante, an alogamente a lo que suced a con el primer rayo en la situaci on mostrada en la parte
24
rayos
humo
t0
t0
Estado inicial = vegetacin seca
rayos
humo
t0
t0
Estado inicial = vegetacin hmeda
Figura 1.3: La especicaci on de Nivel 2 toma en consideraci on el estado inicial.
rayos
humo
t0
t1
t0
t1
Estado inicial = vegetacin seca, quemada Estado inicial = vegetacin seca, sin quemar
rayos
humo
t0
t1
t0
t1
Estado inicial = vegetacin seca, sin quemar Estado inicial = vegetacin hmeda, sin quemar
Figura 1.4: La especicaci on de Nivel 3 describe adem as la evoluci on el estado.
rayos lluvia viento
humo
celda
Figura 1.5: Especicaci on de Nivel 4 - Estructura del bosque.
25
superior de la gura: puesto que en ambos casos el estado y la trayectoria de entrada son las mismas, la respuesta del sistema es la misma.
1.6.5.
Nivel 4 - Componentes acoplados
Al mayor nivel de la especicaci on del sistema, describimos su estructura interna. En los niveles 0 a 3, el sistema se describe como una caja negra, observable s olo a trav es de sus puertos de entrada y salida. Por el contrario, en el Nivel 4 se describe c omo el sistema est a compuesto de componentes interactuantes. Por ejemplo, en la Figura 1.5 se muestra que el modelo del bosque est a compuesto de celdas interactuantes, cada una representativa de una cierta regi on espacial, de modo que las celdas adyacentes se hayan conectadas entre s . Cada una de las celdas es modelada al Nivel 3: se emplea la denici on de sus transiciones de estado y de la generaci on de sus salidas, para describir c omo la celda act ua sobre las dem as celdas y el efecto de estas sobre ella. Las celdas son conectadas por medio de sus puertos. Los puertos de salida de una celda se conectan a los puertos de entrada de las celdas vecinas. Obs ervese que en esta clasicaci on se distingue entre el conocimiento de la estructura del sistema (c omo est a constituido internamente) y el conocimiento de su comportamiento (su manifestaci on externa). Viendo el sistema como una caja negra, el comportamiento externo del sistema es la relaci on que este impone entre las entradas aplicadas sobre el y la secuencia de salidas obtenidas. La estructura interna del sistema incluye su estado, el mecanismo de transici on de los estados (c omo las entradas transforman el estado del sistema), y la relaci on entre el estado y las salidas. Conocer la estructura del sistema permite deducir su comportamiento. Por el contrario, normalmente no es posible inferir de forma un voca la estructura del sistema a partir de la observaci on de su comportamiento.
1.7.
MODELADO MODULAR Y JERARQUICO
Una manera de abordar el modelado de sistemas complejos consiste en descomponerlos y describirlos mediante cierto n umero de componentes que interact uan entre s . En lugar de intentar describir globalmente el comportamiento del sistema completo, es m as sencillo realizar un an alisis por reducci on. Es decir, dividir el sistema en partes, modelar las partes independientemente y nalmente describir la interacci on entre las partes.
26
Para describir un sistema de esta manera, es preciso denir los componentes que componen el sistema y especicar c omo los componentes interaccionan entre s . La interacci on entre los componentes puede describirse de las dos formas siguientes: Acoplamiento modular: la interacci on entre los componentes es descrita mediante la conexi on de los puertos de sus interfaces. Es decir, la interacci on de cada componente con el resto de componentes es descrita mediante la conexi on de sus puertos de entrada y salida de manera modular. Este tipo de modelos se denominan modelos modulares. Acoplamiento no modular: consiste en describir la interacci on entre los componentes a trav es de la inuencia que tiene el estado de unos componentes (componentes inuenciadores) sobre la transici on del estado de otros (componentes inuenciados). En este tipo de modelos, el estado de los componentes inuenciadores interviene directamente en las funciones de transici on de estados de los componentes inuenciados. Como veremos, este tipo de acoplamiento se emplea com unmente en los aut omatas celulares. En los modelos modulares, cada componente es a su vez un modelo con sus propios puertos de entrada y de salida. La transmisi on de los valores desde los puertos de salida hasta los puertos de entrada se produce instant aneamente. Igualmente, la transmisi on de los valores desde las entradas al modelo compuesto hasta las entradas a los componentes, o desde las salidas de los componentes hasta las salidas del modelo compuesto, se producen instant aneamente. Inmediatamente surge la cuesti on de qu e condiciones deben satisfacer los modelos de los componentes y la conexi on entre ellos para garantizar que el modelo compuesto resultante est a bien denido. La respuesta a esta pregunta, planteada de forma general, no se conoce. No obstante, estas condiciones s son bien conocidas para los formalismos b asicos, tales como DEVS, DTSS, DESS y DEV&DESS, los cuales ser an descritos en los sucesivos temas de este texto. Se dice que un formalismo es cerrado bajo acoplamiento si el modelo resultante de cualquier conexi on de componentes descritos mediante ese formalismo es, a su vez, un modelo especicado en dicho formalismo. Esta propiedad de los formalismos b asicos de ser cerrados bajo acoplamiento hace posible la construcci on jer arquica de modelos. Los conceptos de modularidad y de acoplamiento permiten: a) desarrollar y probar los modelos como unidades independientes; b) situarlos en un repositorio de modelos;
27
y c) reutilizarlos en cualquier contexto de aplicaci on en el cual su comportamiento sea apropiado y tenga sentido conectarlos a otros componentes.
1.8.
MARCO FORMAL PARA EL MODELADO Y LA SIMULACION
En esta secci on se presenta un marco formal para el modelado y la simulaci on, en el cual se dene un conjunto de entidades (sistema fuente, base de datos del comportamiento, modelo, simulador y marco experimental) y las relaciones entre ellas. De entre estas relaciones cabe destacar las dos fundamentales: la relaci on de modelado y la relaci on de simulaci on. Como veremos, todo ello est a relacionado con los cinco niveles para la especicaci on de sistemas descritos en la Secci on 1.6. En la Figura 1.6 se han representado esquem aticamente las cinco entidades y las dos relaciones fundamentales entre ellas. A continuaci on, se describen las entidades, as como las relaciones de modelado y de simulaci on.
Marco experimental
Sistema fuente
Base de datos del comportamiento
Simulador
Relacin de modelado
Relacin de simulacin Modelo
Figura 1.6: Entidades b asicas del modelado y simulaci on, y su relaci on.
1.8.1.
Sistema fuente
El sistema fuente es el entorno real o virtual que estamos interesados en modelar, el cual constituye una fuente de datos observables, en la forma de trayectorias (observaciones indexadas en el tiempo) de variables. Esta entidad es conocida en el Nivel 0 - Marco de observaci on de la especicaci on del sistema.
28
1.8.2.
Base de datos del comportamiento
Los datos que se han recogido a partir de observaciones o experimentando con el sistema se llaman base de datos del comportamiento del sistema. Estas observaciones son caracter sticas de la especicaci on al Nivel 1 - Comportamiento E/S del sistema. Los datos son observados o adquiridos a trav es de marcos experimentales de inter es para quien realiza el modelo. Las distintas aplicaciones del modelado y la simulaci on dieren en la cantidad de datos disponibles para poblar la base de datos del comportamiento del sistema. En entornos ricos en datos, suele disponerse de abundantes datos hist oricos y pueden obtenerse f acilmente nuevos datos realizando medidas. Por el contrario, los entornos pobres en datos ofrecen pocos datos hist oricos o datos de baja calidad (cuya representatividad del sistema de inter es es cuestionable). En algunos casos, es imposible obtener mejores datos y en otros casos es caro hacerlo. En este u ltimo caso, el proceso de modelado puede dirigir la adquisici on de datos a aquellas areas que tienen un mayor impacto en el resultado nal.
1.8.3.
Marco experimental
Un marco experimental es una especicaci on de las condiciones bajo las cuales el sistema es observado o se experimenta con el. Es la formulaci on operacional de los objetivos que motivan un proyecto de modelado y simulaci on. Continuando con el ejemplo del modelado del bosque, de la multitud de variables que podr an estudiarse, el conjunto {rayos, lluvia, viento, humo} representa una elecci on en particular. Este marco experimental est a motivado por el inter es en modelar la propagaci on del incendio provocado por un rayo. Un marco experimental m as renado contendr a adem as variables tales como el contenido en humedad de la vegetaci on y la cantidad de material sin quemar. As pues, pueden formularse muchos marcos experimentales para un mismo sistema y un mismo marco experimental puede aplicarse a varios sistemas. Cabe preguntarse cu al es el prop osito de denir varios marcos experimentales para un mismo sistema, o de aplicar el mismo marco experimental a varios sistemas. Las razones son las mismas por las cuales tenemos diferentes objetivos al modelar un mismo sistema, o perseguimos un mismo objetivo al modelar diferentes sistemas. Hay dos visiones igualmente v alidas acerca de qu e es un marco experimental. La primera ve el marco experimental como la denici on del tipo de datos que
29
se incluir an en la base de datos del comportamiento del sistema. La segunda ve el marco experimental como un sistema que interact ua con el sistema de inter es para obtener observaciones, bajo determinadas condiciones experimentales. En esta visi on, el marco experimental est a caracterizado por su implementaci on como sistema de medida u observador, y t picamente tiene los tres componentes siguientes (v ease la Figura 1.7): Generador Receptor Genera las secuencias de entrada al sistema. Monitoriza el experimento, para comprobar que se satisfacen las condiciones experimentales requeridas. Transductor Observa y analiza las secuencias de salida del sistema.
SISTEMA
MARCO EXPERIMENTAL
GENERADOR
RECEPTOR
TRANSDUCTOR
Figura 1.7: Marco experimental y sus componentes.
Como ya se ha indicado anteriormente, es importante establecer lo antes posible en el proceso de desarrollo del modelo cu ales son los objetivos del estudio, ya que los objetivos sirven para enfocar el modelo en aquellos aspectos del sistema que son relevantes para el prop osito del estudio. En otras palabras, conocer los objetivos del estudio permite plantear los marcos experimentales adecuados. Los marcos experimentales trasladan los objetivos a condiciones de experimentaci on m as precisas para el sistema fuente y sus modelos. Una vez jados los objetivos, presumiblemente existir a un nivel en la especicaci on del sistema que ser a el m as adecuado para contestar la cuesti on planteada. Cuanto m as exigentes sean las preguntas, normalmente mayor es la resoluci on necesaria (nivel en la descripci on del modelo) para contestarlas. Por ello, la elecci on de un nivel de abstracci on apropiado repercute en la consecuci on de los objetivos. Un procedimiento para transformar los objetivos en marcos experimentales, en aquellos casos en que los objetivos se reeren al dise no del sistema, es el siguiente:
30
1. Se establece qu e medidas van a usarse para evaluar las diferentes alternativas de dise no. Estas medidas deben cuanticar la ecacia con la que el sistema cumple con sus objetivos. Llamaremos a estas medidas las medidas de salida. 2. Para calcular esas medidas, el modelo deber a incluir ciertas variables (llamadas variables de salida) cuyo valor deber a calcularse durante la ejecuci on del modelo. 3. El c alculo de las medidas de salida a partir de las variables de salida se realiza en el componente transductor del marco experimental. Para ilustrar c omo diferentes objetivos conducen a diferentes marcos experimentales y a diferentes modelos, consideremos nuevamente el problema de los incendios forestales. Hay dos aplicaciones fundamentales del modelado y la simulaci on en este area. La primera relacionada con la extinci on del incendio una vez se ha desencadenado. La segunda relacionada con la prevenci on y la evaluaci on de los da nos. Formulados como objetivos para el modelado, estos prop ositos conducen a marcos experimentales diferentes. En el primer marco experimental, actuaci on en tiempo real por parte de los bomberos, se precisan predicciones precisas de hacia d onde se extender a el fuego en las pr oximas horas. Estas predicciones se emplean para situar los recursos en los lugares m as adecuados, con el n de alcanzar la m axima ecacia. Dado que los bomberos pueden ser situados en un grave peligro, es necesario realizar predicciones a corto plazo muy precisas. Una pregunta t pica planteada en este tipo de estudios es: en qu e medida es seguro situar durante las pr oximas horas una cuadrilla de bomberos en un determinado emplazamiento, que se encuentra al alcance del frente del fuego. Para mejorar la capacidad de realizar predicciones precisas, el estado del modelo debe ser actualizado con datos de sat elite para mejorar su correspondencia con la situaci on del fuego real seg un este evoluciona. En la prevenci on de incendios, el enfasis se pone menos en las predicciones a corto plazo de propagaci on del fuego y m as en responder preguntas del tipo qu e pasa si relativas a la planicaci on. Por ejemplo, los planicadores urban sticos pueden preguntar qu e anchura debe tener el cortafuegos alrededor de una zona residencial de modo que haya una probabilidad inferior al 0.1 % de que las casas sean alcanzadas por el fuego. En este caso, el modelo debe describir una mayor area de terreno y necesita una precisi on considerablemente menor que en el caso anterior. De hecho, un modelo puede ser capaz de ordenar diferentes alternativas sin necesariamente predecir adecuadamente la propagaci on del fuego.
31
As pues, los marcos experimentales desarrollados para estos dos objetivos, extinci on y prevenci on, son diferentes. El primero de ellos (extinci on) sugiere experimentar con un modelo en el cual el estado inicial viene determinado por el material combustible, el viento y las condiciones topogr acas. La salida deseada es un mapa detallado de la propagaci on del fuego despu es de, por ejemplo, 5 horas, en la regi on de inter es. El segundo marco experimental (prevenci on) sugiere un mayor alcance, menor resoluci on en la representaci on del terreno en el cual los reg menes esperados de rayos, viento, lluvia y temperaturas son inyectados como trayectorias de entrada. Puede colocarse el modelo en diferentes estados, correspondientes a diferentes alternativas de prevenci on. Por ejemplo, pueden investigarse diferentes distribuciones de los cortafuegos. La salida de cada ejecuci on puede ser tan simple como una variable binaria que indique si la zona residencial fue o no alcanzada por el fuego. El resultado global del estudio, en el cual se recopila la informaci on de todas las ejecuciones, puede ser una ordenaci on de las diferentes alternativas, mostrando la ecacia de cada una de ellas en prevenir que el fuego alcance la zona residencial. Por ejemplo, para cada alternativa puede mostrarse el porcentaje de ejecuciones en las cuales la zona residencial no fue alcanzada por el fuego.
1.8.4.
Modelo
En general, un modelo es una especicaci on del sistema proporcionada en cualquiera de los niveles descritos en la Secci on 1.6. Normalmente, en el ambito del modelado y la simulaci on, los modelos se especican en los Niveles 3 y 4, es decir, transici on de estados y estructura. Una posible denici on del t ermino modelo es la siguiente. Un modelo es un conjunto de instrucciones, reglas, ecuaciones o ligaduras para reproducir el comportamiento de entrada/salida.
1.8.5.
Simulador
Dado que un modelo es un conjunto de instrucciones, reglas, ecuaciones o ligaduras, es necesario disponer de un agente capaz de obedecer las instrucciones y reglas, y de evaluar las ecuaciones, con el n de generar el comportamiento descrito en el modelo. Este agente se denomina simulador.
32
As pues, un simulador es cualquier agente computacional (tal como un u nico procesador, una red de procesadores, la mente humana, o de manera m as abstracta, un algoritmo) capaz de ejecutar el modelo para generar su comportamiento. Un simulador en s es t picamente un sistema especicado al Nivel 4 - Componentes acoplados, puesto que es un sistema que dise namos intencionadamente para ser sintetizado a partir de la conexi on de componentes tecnol ogicos bien conocidos.
1.8.6.
Relaci on de modelado: validez
La relaci on b asica de modelado, denominada validez, se reere a la relaci on entre el modelo, el sistema y el marco experimental. A menudo se piensa en la validez como el grado en el cual el modelo representa elmente al correspondiente sistema. Sin embargo, resulta m as pr actico requerir que el modelo capture de forma el el comportamiento del sistema s olo hasta el punto demandado por los objetivos del estudio de simulaci on. De esta forma, el concepto de validez responde a la pregunta de si es posible distinguir entre el modelo y el sistema en el marco experimental de inter es. El tipo m as b asico de validez, la validez replicativa, se arma si, para todos los posibles experimentos del marco experimental, el comportamiento del modelo y del sistema se corresponden dentro de una tolerancia aceptable. As pues, la validez replicativa requiere que el modelo y el sistema concuerden al Nivel 1 - Relacion E/S. Formas m as estrictas de validez son la validez predictiva y la validez estructural. En la validez predictiva no s olo requerimos validez replicativa, sino tambi en la habilidad de predecir. La validez predictiva requiere la concordancia con el sistema en el siguiente nivel de la jerarqu a de sistemas, es decir, al Nivel 2 - Funci on E/S. Finalmente, validez estructural requiere concordancia en el Nivel 3 - Transici on de estados o en el Nivel 4 - Acoplamiento de componentes. Esto signica que el modelo no s olo es capaz de replicar los datos observados del sistema, sino que tambi en reproduce paso a paso, componente a componente, la forma en que el sistema realiza sus transiciones. El t ermino precisi on se usa a veces en lugar de validez. Otro t ermino, delidad, se usa a menudo para una combinaci on de validez y detalle. As , un modelo de gran delidad se reere a un modelo que tiene tanto un gran detalle como una gran validez (en determinado marco experimental). Obs ervese que el detalle no siempre implica
33
validez, puesto que un modelo puede ser muy detallado y tener, sin embargo, mucho error, simplemente porque algunos de los componentes resueltos con gran detalle funcionan de forma diferente a los correspondientes en el sistema real.
1.8.7.
Relaci on de simulaci on: correcci on
La relaci on b asica de simulaci on, denominada la correcci on del simulador, es una relaci on entre un simulador y un modelo. Un simulador simula correctamente un modelo si genera elmente la trayectoria de salida del modelo dados su estado inicial y su trayectoria de entrada. As pues, la correcci on del simulador se dene en t erminos del Nivel 2 - Funci on E/S. En la pr actica, los simuladores son construidos para ejecutar no s olo un modelo, sino una familia de posibles modelos. Esta exibilidad es necesaria si el simulador va a emplearse en un rango de aplicaciones. En estos casos, debemos establecer que el simulador ejecuta correctamente esa clase particular de modelos. El hecho inexcusable acerca del modelado es que est a severamente constre nido por las limitaciones de la complejidad. La complejidad de un modelo puede medirse por los recursos requeridos por un determinado simulador para interpretar el modelo correctamente. Si bien la complejidad se mide relativa a un determinado simulador o familia de simuladores, a menudo las propiedades intr nsecas al modelo est an fuertemente correlacionadas con su complejidad, la cual es pr acticamente independientemente del simulador. El modelado exitoso puede verse como la simplicaci on v alida. Necesitamos simplicar, o reducir la complejidad, para posibilitar que nuestros modelos sean ejecutados ecientemente en los simuladores (de recursos limitados) de que disponemos. En el proceso de la simplicaci on est an implicados dos modelos: el modelo base y el modelo simplicado. El modelo base es m as capaz, pero requiere m as recursos para ser interpretado que el modelo simplicado. En este contexto, m as capaz, signica que el modelo base es v alido dentro de un conjunto de marcos experimentales (con respecto a un sistema real) m as amplio que el modelo simplicado. Sin embargo, el punto importante es que, dentro del marco experimental particular de inter es, el modelo simplicado y el modelo base sean igualmente v alidos.
34
1.9.
EJERCICIOS DE AUTOCOMPROBACION
Ejercicio 1.1 Describa cu al ser a en su opini on la forma m as ecaz de estudiar cada uno de los sistemas siguientes, en t erminos de las posibilidades mostradas en la Figura 1.1. 1. Un ecosistema compuesto por varias especies (animales y vegetales) y por recursos (agua, luz, etc.). 2. Una glorieta en la que convergen varias calles y que frecuentemente presenta atascos. 3. Una presa para el suministro de agua y electricidad que se planea construir en un r o. 4. El servicio de urgencias de un hospital que se encuentra en funcionamiento. 5. Un circuito el ectrico.
Ejercicio 1.2 Describa qu e caracter sticas tiene cada uno de los tipos de modelo siguientes: mental, verbal, f sico y matem atico. Ponga un ejemplo de modelo de cada tipo, indicando cu al es su nalidad.
Ejercicio 1.3 Para cada uno de los sistemas mencionados en el Ejercicio 1.1, suponga que se ha decidido realizar el estudio mediante simulaci on. Discuta de qu e tipo deber a ser, en su opini on, el modelo matem atico: est atico o din amico, determinista o estoc astico, de tiempo continuo, discreto o h brido.
Ejercicio 1.4 Plantee un ejemplo de conocimiento de un sistema en cada uno de los cuatro niveles de la clasicaci on de Klir.
35
Ejercicio 1.5 Para un sistema de su elecci on, plantee un ejemplo de an alisis del sistema, inferencia sobre el sistema y dise no del sistema. Indique el nivel en el conocimiento del sistema que se precisa, seg un la clasicaci on de Klir, para realizar cada una de estas tres actividades.
Ejercicio 1.6 Para un sistema y un marco experimental de su elecci on, indique c omo podr a descomponerse el sistema de manera modular y jer arquica con el n de realizar su an alisis por reducci on. Para cada uno de los componentes, indique qu e magnitudes escoger a como puertos de la interfaz.
Ejercicio 1.7 Describa c omo podr a especicarse el sistema que ha propuesto al resolver el Ejercicio 1.4 en cada uno de los cinco niveles para la especicaci on de sistemas propuestos por Zeigler.
Ejercicio 1.8 Discuta la diferencia entre acoplamiento modular y acoplamiento no modular. Ponga un ejemplo.
Ejercicio 1.9 Explique el signicado de los tres conceptos siguientes: validez replicativa, validez predictiva y validez estructural.
Ejercicio 1.10 Ponga un ejemplo de modelo base y, para un determinado marco experimental de su elecci on, describa un posible modelo simplicado.
36
1.10.
SOLUCIONES A LOS EJERCICIOS
Soluci on al Ejercicio 1.1 La forma m as adecuada de estudiar cada uno de los sistemas depende de cu al sea en cada caso el objetivo del estudio. Puesto que en el enunciado no se indican los objetivos, al contestar a la pregunta debe plantearse el objetivo del estudio de cada sistema y, una vez jado el objetivo, deber a explicarse qu e forma o formas de estudio del sistema podr an ser v alidas para alcanzar ese objetivo. En algunos de los casos citados en el enunciado ser a posible experimentar con el sistema real, mientras que en otros puede ser costoso y complejo (como en el caso del ecosistema), o imposible (como en el caso del dise no de una presa, puesto que el sistema aun no existe). La experimentaci on con el sistema real y el modelado matem atico son frecuentemente actividades complementarias, dado que los datos experimentales sirven de base para la construcci on del modelo y para realizar su validaci on. En aquellos casos en que no se disponga de datos del sistema real, la construcci on del modelo puede basarse en el conocimiento te orico disponible acerca del comportamiento de los diferentes componentes del sistema. Por ejemplo, el dise no de la presa puede realizarse empleando modelos matem aticos basados en una combinaci on de leyes f sicas, relaciones emp ricas y conjuntos de datos que describen el comportamiento mec anico de los materiales de construcci on, del agua, etc. A continuaci on, se plantea un posible objetivo en el estudio de cada sistema y una forma de estudiarlo que podr a permitir alcanzar el objetivo. Otros objetivos y formas de estudio podr an ser igualmente v alidas. 1. Un ecosistema compuesto por varias especies (animales y vegetales) y por recursos (agua, luz, etc.). El objetivo del estudio podr a ser analizar la evoluci on del n umero de individuos de determinadas especies animales y vegetales, a partir de unas determinadas condiciones iniciales y para una cierta evoluci on en el tiempo de los factores ambientales. Para ello, podr a plantearse un modelo matem atico del sistema y experimentar con el mediante simulaci on. Puede considerarse que la variaci on en el tiempo de la cantidad de individuos de una especie vegetal depende de determinados factores ambientales (agua, luz, etc.) y de su tasa de reproducci on, as como de la densidad de depredadores
37
(herb voros) e individuos de otras especies vegetales que compitan con ella por los recursos (por ejemplo, por la luz). An alogamente, podr a suponerse que la variaci on en el n umero de individuos de una especie animal depende de su frecuencia reproductora, as como de la densidad de depredadores y presas, y de la abundancia de recursos tales como el agua. 2. Una glorieta en la que convergen varias calles y que frecuentemente presenta atascos. El objetivo del estudio podr a ser estudiar la conveniencia de colocar sem aforos en las calles de acceso a la glorieta y determinar qu e programaci on de los sem aforos resulta m as adecuada en funci on de la hora del d a. Podr a emplearse para ello la simulaci on de un modelo matem atico. Si el objetivo del estudio fuera se nalizar los accesos a la glorieta, de modo que se diera prioridad a unos frente a otros, quiz a podr a emplearse un modelo mental. 3. Una presa para el suministro de agua y electricidad que se planea construir en un r o. Si la nalidad del estudio es determinar la forma, altura y espesor de la presa, podr a emplearse simulaci on de modelos matem aticos. Una vez determinada la forma, dimensiones y ubicaci on de la presa, ser a u til realizar un modelo f sico (una maqueta a escala) con el n de dar a conocer las conclusiones del estudio. 4. El servicio de urgencias de un hospital que se encuentra en funcionamiento. Si el objetivo es estimar el tiempo de espera de los pacientes en funci on de su frecuencia de llegada, del tiempo del proceso de admisi on, del n umero de boxes, enfermeros y m edicos, entonces podr a emplearse la simulaci on de un modelo matem atico. 5. Un circuito el ectrico. Si el objetivo es calcular la tensi on en los nodos del circuito y la corriente que circula a trav es de los componentes el ectricos, entonces podr a emplearse un modelo matem atico. En algunos casos sencillos el modelo matem atico podr a ser resuelto de manera anal tica. En la pr actica lo m as habitual es analizar el modelo matem atico mediante su simulaci on por ordenador. Otra posibilidad ser a construir el circuito y realizar directamente las medidas.
38
En algunos casos sencillos podr a emplearse un modelo mental, para decidir si es necesario aumentar o disminuir el valor de ciertos componentes, con el n de conseguir modicar la tensi on o la corriente de determinada forma.
Soluci on al Ejercicio 1.2 Un modelo mental es un conjunto de ideas que sirve de ayuda para predecir el comportamiento de un sistema. El modelo mental puede haber sido desarrollado a trav es de la experiencia, la observaci on o el aprendizaje. Por ejemplo, cuando vamos a cruzar una calle y vemos un coche que se aproxima, empleamos un modelo mental para decidir si nos dar a tiempo a cruzar o si, por el contrario, debemos esperar. Asimismo, los modelos mentales constituyen el estadio inicial en el desarrollo de cualquiera de los otros tipos de modelos, ya que no ser a posible desarrollar un modelo verbal, f sico o matem atico sin previamente haber desarrollado un modelo mental del sistema. Un modelo verbal es la descripci on del comportamiento del sistema mediante palabras. Se ajusta al esquema: si se cumple esta condici on, entonces deber a ocurrir aquello. Un ejemplo de modelo verbal ser a la descripci on verbal del funcionamiento de un electrodom estico (por ejemplo, una lavadora) donde se van describiendo las posibles acciones a realizar y sus resultados. Un modelo f sico es una maqueta que reproduce total o parcialmente un sistema. Un ejemplo de modelo f sico es una maqueta de un veh culo cuyas caracter sticas aerodin amicas quieren estudiarse en el t unel de viento. Otra nalidad de los modelos f sicos es analizar los dise nos desde el punto de vista est etico. Un modelo matem atico consiste en la representaci on de las magnitudes de inter es del sistema mediante variables y de la relaci on entre estas magnitudes mediante ecuaciones. Un ejemplo de modelo matem atico ser an las ecuaciones de Maxwell, que describen los fen omenos electromagn eticos.
Soluci on al Ejercicio 1.3 El modelo matem atico del ecosistema podr a ser din amico, determinista y de tiempo continuo. Din amico dado que se quiere estudiar la evoluci on en el tiempo de las variables. Determinista puesto que se conocen de manera precisa las condiciones iniciales y adem as se conoce en cada instante el valor de las variables de entrada al
39
modelo (los factores ambientales). Es de tiempo continuo puesto que las variables analizadas var an de forma continua en el tiempo. El modelo de la glorieta podr a ser din amico, estoc astico y de tiempo discreto. Din amico puesto que se pretende analizar la evoluci on temporal del sistema. Es estoc astico si el proceso de llegada de los coches por cada una de las calles que conuye en la glorieta se describe mediante un proceso estoc astico. Es decir, si se supone que el tiempo que transcurre entre la llegada de dos coches sucesivos est a distribuido de acuerdo a cierta distribuci on de probabilidad. Es de tiempo discreto si el modelo se construye de modo que el valor de sus variables s olo cambie en los instantes de tiempo en que se producen eventos: cuando se produce la llegada de un nuevo veh culo, cuando cambia el estado de un sem aforo, etc. Otra alternativa ser a describir la glorieta mediante un modelo de tiempo continuo: en lugar de representar cada coche como una entidad independiente, puede ser m as eciente computacionalmente considerar que el tr aco de coches es un ujo continuo, de valor cero cuando los coches est an detenidos y de valor f (t) veh culos/minuto cuando los coches est an en movimiento. Se escribe f (t) para indicar que el ujo, f , es una funci on del tiempo, t. El modelo de la presa podr a ser est atico y determinista. El modelo ser a est atico si se trata de calcular la distribuci on de estr es en los materiales de la pared, que corresponde a cierta presi on ejercida por el agua. Ser a determinista si el valor de las variables de entrada al modelo (por ejemplo, la presi on ejercida por el agua) es conocida. El modelo del servicio de urgencias, como sucede habitualmente con los modelos de los procesos log sticos, podr a ser un modelo din amico, estoc astico y de tiempo discreto. El modelo es estoc astico ya que los procesos de llegada son estoc asticos y los tiempos de proceso son variables aleatorias. Es de tiempo discreto ya las variables del sistema s olo cambian en los instantes en que se producen los eventos: llegada de un paciente, un paciente comienza o termina de ser atendido en alguno de los procesos (recepci on, primera diagnosis, curas, etc.). En los intervalos de tiempo entre eventos las variables del modelo permanecen constantes. Finalmente, el modelo del circuito el ectrico podr a ser din amico, determinista y de tiempo continuo. Din amico puesto que se desea conocer la evoluci on temporal de tensiones y corrientes. Determinista si se conoce de manera precisa el estado inicial del modelo y en cada instante el valor de las variables de entrada. De tiempo continuo ya que las variables del modelo var an continuamente en el tiempo.
40
Soluci on al Ejercicio 1.4 Veamos dos ejemplos. En primer lugar, consideremos los niveles en el conocimiento acerca de un dispositivo dise nado y fabricado por el hombre, como puede ser un colector solar, tambi en llamado panel solar t ermico. Se trata de un dispositivo que forma parte de los calentadores solares y que aprovecha la energ a de la radiaci on solar para calentar un uido (por ejemplo, una mezcla de agua y glicol) que circula por unos conductos situados dentro del panel. El uido caliente circula desde el panel hasta su punto de uso (por ejemplo, los radiadores del sistema de calefacci on de una vivienda), retornando luego al panel. En el Nivel 0 del conocimiento se identica la porci on del mundo que vamos a modelar y las maneras mediante las cu ales vamos a observarlo. Esta porci on del sistema real, que en nuestro caso ser a el panel solar t ermico, constituye el sistema fuente. La forma en que vamos a observar el colector ser a midiendo la radiaci on solar incidente, la temperatura de entrada del uido y su temperatura de salida. En el Nivel 1 disponemos de una base de datos de medidas del sistema. En este caso, de las temperaturas de entrada y salida del uido que se han medido para un cierto valor medido de la radiaci on incidente. En el Nivel 2 hemos sido capaces de correlacionar el incremento en la temperatura del uido con la intensidad de la radiaci on incidente. Esta correlaci on la hemos obtenido ajustando los par ametros de una f ormula a los datos experimentales. Finalmente, en el Nivel 3 conocemos la estructura del sistema y somos capaces de entender su comportamiento a partir del comportamiento y la interacci on de sus componentes. Sabemos que el panel solar t ermico est a compuesto por una caja rectangular, dentro del cual est a el sistema captador de calor. Una de las caras de esta caja est a cubierta de un vidrio muy no y las otras cinco caras son opacas y est an aisladas t ermicamente. Dentro de la caja, expuesta al sol, se sit ua una placa met alica, que est a tratada para que aumente su absorci on del calor, y a la cual est an soldados los conductos por los que circula el uido transportador del calor. Podr a ponerse como ejemplo tambi en un sistema log stico, como podr a ser una gasolinera, compuesta por varios surtidores, una tienda y varias cajas para realizar el pago.
41
En el Nivel 0 conocemos qu e porci on del mundo vamos a estudiar y las maneras mediante las cuales vamos a observarlo. Una forma de observar el funcionamiento de la gasolinera ser a medir el instante de tiempo en que se produce la llegada de un cliente y el instante en que se produce su marcha. Con ello podr a estimarse la distribuci on de probabilidad del tiempo que se tarda en atender a un cliente. Tambi en podr a conocerse el n umero de clientes que est an siendo atendidos en la gasolinera en cada instante. Entre ambos estad sticos existir a una correlaci on. En el Nivel 1 dispondr amos de una base de datos de medidas: n umero de clientes en la gasolinera y tiempos de atenci on. En el Nivel 2 dispondr amos de un modelo que permite predecir el tiempo medio de atenci on al cliente en funci on del n umero de clientes que se encuentran en la gasolinera. En el Nivel 3 conocemos de manera detallada la estructura de la gasolinera: n umero de surtidores, n umero de cajas de pago, tipo de cola que se forma frente a las cajas de pago (una cola com un a todas o una cola frente a cada caja), etc. Para un determinado proceso de llegada de clientes y conociendo la distribuci on de los tiempos de proceso de llenado en los surtidores, compra en la tienda y cobro en las cajas, podemos simular el funcionamiento de la gasolinera y calcular estad sticos representativos del mismo. Es decir, podemos conocer el funcionamiento del sistema completo a partir del funcionamiento e interacci on de sus partes.
Soluci on al Ejercicio 1.5 Consideremos el colector solar descrito al contestar al Ejercicio 1.4. El an alisis del sistema consistir a en intentar comprender su funcionamiento bas andose para ello en el conocimiento que se tiene de su estructura. A partir del an alisis de su estructura, podemos comprender que el colector solar funciona aprovechando el efecto invernadero. El vidrio deja pasar la luz visible del sol, que incide en la placa met alica calent andola. Sin embargo, el vidrio no deja salir la radiaci on infrarroja de baja energ a que emite la placa met alica caliente. A consecuencia de ello, y a pesar de las p erdidas por transmisi on (el vidrio es mal aislante t ermico), el volumen interior de la caja se calienta por encima de la temperatura exterior. En la inferencia, disponemos de una base de datos del comportamiento del sistema fuente y tratamos de encontrar una representaci on del conocimiento al Nivel
42
2 (generaci on) o al Nivel 3 (estructura), que nos permita recrear los datos de que disponemos. Por ejemplo, hemos observado experimentalmente que el rendimiento de los colectores mejora cuanto menor sea la temperatura de trabajo. El modelo que describe la estructura del sistema deber a reproducir este comportamiento: a mayor temperatura dentro de la caja (en relaci on con la exterior), mayores ser an las p erdidas por transmisi on en el vidrio. Tambi en, a mayor temperatura de la placa captadora, m as energ etica ser a su radiaci on, y m as transparencia tendr a el vidrio a ella, disminuyendo por tanto la eciencia del colector. En el dise no de un sistema se investigan diferentes estructuras alternativas para un sistema completamente nuevo o para el redise no de uno ya existente. Como parte del dise no del colector solar podr an investigarse el efecto sobre la absorci on de calor de diferentes longitudes de los conductos, diferente volumen interno de la caja, diferentes pinturas aplicadas sobre la capa met alica, diferentes condiciones de operaci on (por ejemplo, causal de uido), etc.
Soluci on al Ejercicio 1.6 El colector solar podr a analizarse descomponi endolo en los componentes siguientes: el vidrio, el volumen de aire contenido dentro de la caja, la placa met alica, el tubo por el cual circula el uido y el uido en s . Los modelos del volumen de aire, la placa met alica, el tubo y el uido deber an describir c omo cambia la temperatura de cada uno de estos elementos en funci on del ujo de energ a entrante y saliente al elemento. As pues, la interfaz de estos componentes deber a contener al menos las dos siguientes variables: el ujo de energ a y la temperatura. El modelo del vidrio deber a permitir calcular qu e proporci on de la radiaci on incidente es transmitida, con lo cual en la interfaz del modelo deber a aparecer la intensidad de la radiaci on incidente y transmitida. La gasolinera podr a analizarse descomponi endola en diferentes procesos, a trav es de los cuales van pasando las entidades (los clientes). El proceso de llenado de combustible tendr a tantos recursos como surtidores y tendr a asociada una distribuci on de probabilidad del tiempo de proceso. Igualmente suceder a con las cajas de pago. Cada uno de estos procesos tendr a asociadas unas colas. La interfaz entre los componentes debe transmitir al menos la informaci on acerca de qu e cliente abandona o accede al proceso (por ejemplo, cada cliente podr a ser identicado mediante un n umero). Esa informaci on puede ser usada por cada uno de los componentes (procesos) para actualizar el valor de estad sticos del proceso (por ejemplo, el tiempo medio en cola o en n umero medio de clientes en cola), de variables globales del modelo
43
y de atributos asociados a cada entidad (por ejemplo, el tiempo total que lleva cada cliente en el sistema).
Soluci on al Ejercicio 1.7 En el Nivel 0 se sabe c omo estimular el sistema, qu e variables de salida medir y c omo observarlas en funci on del tiempo. En el caso del colector solar, podr amos medir la radiaci on solar incidente, la temperatura del uido que entra al colector y la temperatura del uido que sale de el. En el Nivel 1, disponemos de medidas de la radiaci on incidente, y de la temperatura a la entrada y a la salida. En el Nivel 2, podemos predecir la temperatura de salida del uido dadas una determinada temperatura de entrada, una radiaci on incidente y sabiendo que los componentes en el interior de la caja se encuentran a determinada temperatura. En el Nivel 3, ser amos adem as capaces tambi en de predecir la evoluci on de la variable de estado: la temperatura dentro de la caja. Finalmente, en el Nivel 4 somos capaces de explicar el funcionamiento del sistema en t erminos de componentes acoplados. El comportamiento de cada uno de los componentes (vidrio, aire contenido dentro de la caja, placa met alica, tubo y uido) podr an describirse al Nivel 3.
Soluci on al Ejercicio 1.8 En el acoplamiento modular, la interacci on entre los componentes es descrita mediante la conexi on de los puertos de sus interfaces. En el acoplamiento no modular, la interacci on entre los componentes es descrita a trav es de la inuencia que tiene el estado de unos componentes (componentes inuenciadores) sobre la transici on del estado de otros (componentes inuenciados). Un ejemplo de modelo con acoplamiento modular ser a el de la gasolinera descrito anteriormente. En ese modelo los componentes que describen los procesos est an conectados a trav es de sus interfaces. El modelo modular del colector solar podr a realizarse conectando entre s las interfaces de los componentes. Estas interfaces transmiten informaci on acerca de la temperatura del componente y del ujo de energ a establecido al conectar los
44
componentes entre s . Este mismo modelo podr a formularse de manera no modular, describiendo la variaci on en la temperatura de cada componente en funci on de la temperatura a la que se encuentren los dem as componentes y del ujo de energ a proveniente de la radiaci on solar.
Soluci on al Ejercicio 1.9 El concepto de validez responde a la pregunta de si es posible distinguir entre el modelo y el sistema en el marco de experimentaci on de inter es. La validez replicativa es el tipo m as b asico de validez. Solamente requiere que el comportamiento del modelo y del sistema concuerden dentro de una cierta tolerancia aceptable para el prop osito del estudio. Este tipo de validez requiere que el modelo y el sistema concuerden al Nivel 1, Relaci on E/S. En la validez predictiva se necesita que, adem as de cumplirse la validez replicativa, haya la capacidad de predecir. La concordancia entre modelo y sistema debe ser al Nivel 2, Funci on E/S. La validez estructural requiere que el modelo sea capaz de reproducir paso a paso, componente a componente, la forma en que el sistema realiza sus transiciones. La concordancia entre modelo y sistema debe ser ahora al Nivel 3, Transici on de estados o al Nivel 4, Acoplamiento de componentes.
Soluci on al Ejercicio 1.10 En ingenier a es pr actica frecuente escoger entre modelos con diferente nivel de detalle dependiendo de la aplicaci on en concreto a la que se destinen. Los modelos con menor nivel de detalle normalmente constan de menor n umero de ecuaciones que los modelos m as detallados, con lo cual pueden ser resueltos num ericamente en un tiempo menor. Por tanto, elecci on de un modelo u otro se realiza atendiendo a la precisi on necesaria y al tiempo de simulaci on admisible. Por ejemplo, se han desarrollado diferentes modelos matem aticos de los dispositivos semiconductores (diodos, transistores MOS, BJT, etc.), que son empleados dependiendo de su aplicaci on. Cuando el dispositivo forma parte de un circuito digital, el modelo del dispositivo necesita ser menos detallado que cuando ese mismo dispositivo forma parte de un circuito anal ogico.
45
En general, el prop osito del estudio de simulaci on tiene implicaciones decisivas en el nivel de detalle requerido del modelo. Por ejemplo, si el prop osito es evaluar el comportamiento de un sistema en t erminos absolutos, deber a existir un alto grado de correspondencia entre el comportamiento del modelo y del sistema. Por el contrario, si el prop osito del estudio es comparar varios dise nos, el modelo puede ser v alido en un sentido relativo incluso cuando sus respuestas en un sentido absoluto dieran considerablemente de las del sistema real.
46
TEMA 2 FORMALISMOS DE MODELADO Y SUS SIMULADORES
2.1. Introducci on 2.2. Modelado y simulaci on de tiempo discreto 2.3. Modelado y simulaci on de tiempo continuo 2.4. Modelado y simulaci on de eventos discretos 2.5. Ejercicios de autocomprobaci on 2.6. Soluciones a los ejercicios
FORMALISMOS DE MODELADO Y SUS SIMULADORES
OBJETIVOS DOCENTES Una vez estudiado el contenido del tema deber a saber: Describir modelos de tiempo discreto mediante la tabla de transici on/salidas, y mediante las funciones de transici on de estados y salida. Plantear el algoritmo de simulaci on de modelos sencillos de tiempo discreto. Discutir qu e es un aut omata celular y plantear su algoritmo de simulaci on. Discutir qu e es un aut omata conmutado. Discutir qu e es una red lineal de tiempo discreto, expresarla en forma matricial y, a partir de dicha expresi on, generar las trayectorias de salida y del estado. Asignar la causalidad computacional de un modelo de tiempo continuo, plantear el diagrama de ujo de su algoritmo de simulaci on, y codicarlo y ejecutarlo empleando alg un lenguaje de programaci on. Aplicar los siguientes m etodos de integraci on num erica: Euler expl cito, punto medio (Euler-Richardson), Runge-Kutta y Runge-Kutta-Fehlberg. Discutir las diferencias conceptuales entre el modelado de tiempo discreto y de eventos discretos. Discutir las reglas y la simulaci on del Juego de la Vida. Simular modelos sencillos de eventos discretos empleando el m etodo de la planicaci on de eventos. Discutir e identicar los componentes de los modelos de eventos discretos. Discutir las diferencias entre el modelado orientado a los eventos y al proceso.
49
2.1.
INTRODUCCION
En este tema se presentan, de manera informal, los formalismos b asicos para el modelado de sistemas de tiempo discreto, de tiempo continuo y de eventos discretos. Se pretende proporcionar una idea de cu al es el tipo de modelo empleado en cada formalismo, c omo emplearlos para representar el comportamiento del sistema y qu e tipo de comportamiento cabe esperar observar de cada tipo de modelo.
2.2.
DE TIEMPO DISCRETO MODELADO Y SIMULACION
Los modelos de tiempo discreto son normalmente el tipo de modelo m as f acil de entender de manera intuitiva. En este formalismo, el modelo va ejecut andose en sucesivos instantes de tiempo, equiespaciados entre s . El intervalo de tiempo entre dos instantes sucesivos se denomina periodo de muestreo. En cada instante, el modelo se encuentra en un estado, recibe unas entradas y genera unas salidas. El modelo permite predecir, a partir de su estado y de sus entradas actuales, cu ales son sus salidas actuales y cu al ser a su estado en el siguiente instante de tiempo. El estado en el siguiente instante normalmente depende del estado actual y de las entradas actuales al modelo. Los modelos de tiempo discreto tienen numerosas aplicaciones. Una aplicaci on importante es la descripci on de circuitos digitales s ncronos, en los cuales la frecuencia del reloj dene el tama no del paso de avance en el tiempo. Asimismo, los modelos de tiempo discreto se emplean frecuentemente como aproximaciones de modelos de tiempo continuo. En este caso, se escoge una base de tiempo (por ejemplo, 1 segundo, 1 minuto o 1 a no), que determina los instantes de evaluaci on del modelo, y se hace avanzar el reloj de la simulaci on en pasos que son m ultiplos enteros de esta base de tiempo. El sistema es representado mediante el cambio que sufre su estado entre los sucesivos instantes de evaluaci on. Es decir, entre un instante de observaci on y el siguiente. As pues, para construir un modelo de tiempo discreto a partir de un modelo de tiempo continuo, debemos denir c omo el estado actual y las entradas determinan el siguiente estado del modelo de tiempo discreto.
51
2.2.1.
Descripci on de modelos de tiempo discreto
Cuando el sistema tiene un n umero nito de estados y sus entradas pueden tomar un n umero nito de posibles valores, una forma sencilla de especicar el comportamiento del modelo es mediante una tabla, en la cual se escriben todas las posibles combinaciones de valores de los estados y las entradas, y para cada una de estas se indica el valor de la salida y del siguiente estado. Esta tabla se denomina tabla de transici on/salidas. A continuaci on, se muestra un ejemplo. Ejemplo 2.2.1. La tabla de transici on/salidas siguiente corresponde a un sistema con dos estados, una entrada y una salida. Estado Entrada Estado actual actual siguiente 0 0 0 0 1 1 0 1 0 1 1 1 Salida actual 0 1 0 1
Los dos estados est an representados mediante 0 y 1. La entrada puede tomar dos posibles valores, representados mediante 0 y 1. Hay cuatro combinaciones entre los posibles valores del estado y los posibles valores de la entrada. Estas cuatro combinaciones se escriben en las dos primeras columnas de la tabla. El n umero de combinaciones determina el n umero de las de la tabla. Para cada una de estas combinaciones, se escribe en la tercera columna el valor del estado siguiente. En la cuarta columna se escribe el valor de la salida actual del sistema. Por ejemplo, en la primera la se indica que cuando el estado actual es 0 y la entrada es 0, entonces la salida del sistema es 0 y el estado en el siguiente instante de tiempo vale 0. En los modelos de tiempo discreto, el tiempo avanza a pasos, que normalmente son m ultiplos enteros de la base de tiempo. La tabla de transici on/salidas puede reinterpretarse especicando c omo cambia el estado en funci on del tiempo: Si el estado en el instante t es q y la entrada en el instante t es x, entonces el estado en el instante t + 1 ser a (q, x) y la salida y en el instante t ser a (q, x). La funci on de denomina funci on de transici on de estado y permite representar, de manera m as abstracta, la informaci on mostrada en las tres primeras columnas
52
de la tabla de transici on/salidas. La funci on se denomina la funci on de salida y corresponde con las primeras dos columnas y con la u ltima columna de la tabla. Las funciones de transici on de estados y de salida constituyen una forma m as general de representar la informaci on. Por ejemplo, el modelo de la tabla mostrada en el Ejemplo 2.2.1 puede representarse, de manera m as compacta, de la forma siguiente:
(q, x) = x (q, x) = x
(2.1) (2.2)
que indica que el estado siguiente y la salida actual est an ambos determinados por la entrada actual. La secuencia de estados, q (0), q (1), se denomina trayectoria de los estados. Conocido el estado inicial, q (0), los siguientes estados de la secuencia se determinan de la forma siguiente: q (t + 1) = (q (t), x(t)) y similarmente, la trayectoria de salida viene dada por la expresi on siguiente: y (t) = (q (t), x(t)) (2.4) (2.3)
A continuaci on, se muestra un algoritmo para calcular el estado y la trayectoria de salida de un modelo de tiempo discreto, a partir de la trayectoria de entrada y el estado inicial. Este algoritmo es un ejemplo de simulador.
Ti = 0, Tf = 9 q(0) = 0 t = Ti while ( t <= Tf ) { y(t) t } = ( q(t), x(t) ) = t + 1 q(t+1) = ( q(t), x(t) ) tiempo inicial y final, en este caso 0 y 9 trayectoria de entrada
x(0) = 1, ..., x(9) = 0 estado inicial
53
2.2.2.
Aut omatas celulares
Aunque el algoritmo anterior es muy sencillo, la naturaleza abstracta de las funciones de transici on de estado y de salida permite aplicarlo a la resoluci on de problemas complejos. Por ejemplo, podemos conectar sistemas en la, de modo que cada uno de ellos tenga conectado un sistema a su izquierda y otro a su derecha. En la Figura 2.1 se muestra una representaci on esquem atica de un modelo de este tipo.
Figura 2.1: Espacio celular unidimensional.
Supongamos que cada sistema tiene dos estados, 0 y 1, y que recibe como entrada los estados de los sistemas vecinos. En este caso, hay 8 posibles combinaciones de los valores de las 2 entradas y del estado del sistema. La tabla de transici on de estados de cada uno de los sistemas ser a de la forma siguiente:
Estado actual 0 0 0 0 1 1 1 1
Entrada Entrada Estado izquierda actual derecha actual siguiente 0 0 ? 0 1 ? 1 0 ? 1 1 ? 0 0 ? 0 1 ? 1 0 ? 1 1 ?
Asignando valor a la cuarta columna, que hemos dejado con interrogaciones, queda denida la funci on de transici on de estado. Dado que la cuarta columna tiene 8 las y que el estado del sistema puede tomar 2 valores, hay 28 = 256 posibles funciones de transici on de estado. Este tipo de modelo se denomina automata celular. Para simular un modelo de este tipo, debemos escoger la funci on de transici on de estados, asignar valor inicial al estado de cada uno de los sistemas que componen el espacio celular y aplicar una versi on adecuadamente adaptada del algoritmo simulador.
54
Un aut omata celular es una idealizaci on de un fen omeno f sico en el cual el espacio y el tiempo est an discretizados, y el conjunto de estados es discreto y nito. El aut omata celular est a compuesto de componentes iguales entre s , llamados c elulas, todos ellos con id entico aparataje computacional. La distribuci on espacial de las c elulas puede ser un mallado unidimensional, bidimensional o multidimensional, conectado de manera uniforme. Las c elulas que inuyen sobre una c elula en particular, denominadas sus vecinas, son a menudo aquellas situadas m as cerca en el sentido geom etrico. Los aut omatas celulares, introducidos originalmente por von Neumann y Ulam como una idealizaci on de la autorreproducci on de los sistemas biol ogicos, muestran comportamientos muy interesantes y diversos. En el texto (Wolfram 1986) se investigan sistem aticamente todas las posibles funciones de transici on en aut omatas celulares unidimensionales. La conclusi on fue que existen cuatro tipos de aut omatas celulares cuyo comportamiento diere signicativamente. Estos son: 1. Aut omatas en los cuales cualquier din amica se extingue r apidamente. 2. Aut omatas que r apidamente exhiben un comportamiento peri odico. 3. Aut omatas que muestran un comportamiento ca otico. 4. Finalmente, los m as interesantes: aut omatas cuyo comportamiento es no peri odico e impredecible, pero que muestran patrones regulares interesantes. Un ejemplo interesante de aut omata bidimensional es el denominado Juego de la Vida de Conway (Gardner 1970). El juego tiene lugar en un espacio celular bidimensional, cuyo tama no puede ser nito o innito. Cada celda est a acoplada a aquellas que se encuentran m as pr oximas a ella, tanto lateral como diagonalmente. Esto signica que, para una c elula situada en el punto (0, 0), sus c elulas vecinas laterales est an situadas en los puntos (0, 1), (1, 0), (0, 1) y (1, 0), y sus c elulas vecinas diagonales est an situadas en (1, 1), (1, 1), (1, 1) y (1, 1), como se muestra en la Figura 2.2a. En la Figura 2.2b se muestran las c elulas vecinas de una c elula situada en la posici on (i, j ). El estado de cada c elula puede tomar dos valores: 1 (viva) y 0 (muerta). Cada una de las c elulas puede sobrevivir (est a viva y permanece viva), nacer (su estado pasa de 0 a 1) y morir (su estado pasa de 1 a 0) a medida que el juego progresa. Las reglas, tal como fueron denidas por Conway, son las siguientes: 1. Una c elula permanece viva si tiene en su vecindad 2 o 3 c elulas vivas.
55
Figura 2.2: C elulas vecinas en el Juego de la Vida a la situada en: a) (0, 0); y b) (i, j ).
2. Una c elula muere debido a superpoblaci on si hay m as de 3 c elulas vivas en su vecindad. 3. Una c elula muere a causa del aislamiento si hay menos de 2 c elulas vivas en su vecindad. 4. Una c elula muerta vuelve a la vida si hay exactamente 3 c elulas vivas en su vecindad. Cuando el juego comienza con ciertas conguraciones de c elulas vivas, el Juego de la Vida muestra una evoluci on interesante. A medida que la trayectoria de los estados evoluciona, la forma de los grupos de c elulas vivas va cambiando. La idea del juego es encontrar nuevos patrones y estudiar su comportamiento. En la Figura 2.3 se muestran algunos patrones interesantes. El Juego de la Vida ejemplica algunos de los conceptos expuestos anteriormente. Se desarrolla en una base de tiempo discreto (el tiempo avanza a pasos: 0, 1, 2, ) y se trata de un modelo multicomponente: compuesto de componentes (c elulas) conectados entre s . En contraste con el estado local (el estado de la c elula), el estado global es el conjunto de estados de todas las c elulas en un determinado instante de tiempo. Cada uno de estos estados globales inicia una trayectoria de estados (una secuencia de estados globales indexada en el tiempo) que termina en un ciclo o contin ua evolucionando para siempre. El procedimiento b asico para simular un automata celular sigue el algoritmo descrito anteriormente. Esto es, en cada instante de tiempo se inspeccionan todas las
56
Figura 2.3: Algunos patrones que aparecen en el Juego de la Vida de Conway. Los patrones a), b) y c) son estables, ya que no cambian. El patr on d) es oscilante. En e) se muestra un ciclo de patrones que se mueve.
c elulas, aplicando la funci on de transici on de estado a cada una de ellas, y salvando el siguiente estado global en una segunda copia de la estructura de datos empleada para almacenar el estado global. Una vez calculado el siguiente estado global, este se convierte en el estado global actual y se avanza el reloj de la simulaci on un paso. En aquellos casos en que el espacio de c elulas es innito, el tiempo necesario para calcular el siguiente estado de todas las c elulas es innito. Para evitar este problema, la parte del espacio examinada se limita a una cierta regi on nita. En muchos casos, esta regi on nita es ja a lo largo de la simulaci on. Por ejemplo, un espacio bidimensional puede estar representada por una matriz cuadrada de lado N . En este caso, el algoritmo examina N 2 c elulas en cada paso de tiempo. Debe idearse un procedimiento adicional que tenga en cuenta el hecho de que las c elulas de los bordes de la regi on no poseen todos sus vecinos. Una soluci on es asumir que las c elulas situadas en los bordes de la regi on mantienen un estado constante (por ejemplo, todas est an muertas). Otra soluci on es envolver el espacio de manera toroidal, es decir, interpretar el ndice N tambi en como 0. Existe un procedimiento alternativo al de examinar las N 2 c elulas en cada paso en el tiempo. Consiste en examinar u nicamente aquellas c elulas cuyo estado puede potencialmente cambiar. Este procedimiento se denomina de eventos discretos. En los modelos de tiempo discreto, en cada paso de tiempo cada componente sufre una transici on en el estado, lo cual sucede con independencia de que el valor del estado cambie o no. Por ejemplo, en el Juego de la Vida si una c elula est a muerta y todas las que le rodean tambi en lo est an, entonces en el siguiente paso de tiempo
57
la c elula continua muerta. Si en el espacio celular innito la inmensa mayor a de las c elulas est an muertas, pocas de ellas cambian su estado. En otras palabras, si de denen los eventos como cambios en el estado, entonces en la mayor a de los casos se producir an relativamente pocos eventos en el sistema. Inspeccionar todas las c elulas en una regi on innita es imposible. Pero hacerlo, incluso si la regi on es nita, es claramente ineciente. En contraste con los simuladores de tiempo discreto, que inspeccionan las N 2 c elulas en cada paso de tiempo, los simuladores de eventos discretos se concentran en procesar los eventos en lugar de las c elulas, lo cual es considerablemente m as eciente. La idea b asica es tratar de predecir cu ando una c elula puede posiblemente cambiar su estado o, por el contrario, cu ando su estado permanecer a inalterado en el estado global del siguiente paso en el tiempo. Supongamos que conocemos el conjunto de c elulas cuyo estado potencialmente puede cambiar. Entonces s olo tendr amos que examinar esas c elulas, en algunas de las cuales cambiar a el valor del estado y en otras no cambiar a. A continuaci on, en las nuevas circunstancias, obtenemos el conjunto de c elulas que potencialmente pueden cambiar en el siguiente paso en el tiempo. Puede obtenerse el conjunto de c elulas susceptibles de cambiar su estado realizando la consideraci on siguiente. Si ninguna de sus vecinas cambia su estado en el instante actual, entonces la c elula en cuesti on no cambiar a su estado en el siguiente instante de tiempo. El procedimiento para la simulaci on basada en eventos sigue la l ogica siguiente: En una transici on de estado deben se nalarse aquellas c elulas cuyo estado cambia. A continuaci on, establ ezcase el conjunto de todas las c elulas vecinas de aquellas. Este conjunto contiene todas las c elulas que pueden posiblemente cambiar su estado en el siguiente paso de tiempo. El estado de las c elulas no pertenecientes a este conjunto permanecer a inalterado en el siguiente paso de tiempo. Obs ervese que aunque podemos determinar el conjunto de c elulas que posiblemente cambiar an su estado, no sabremos si cada una de ellas realmente cambia el estado o no hasta que no evaluemos su funci on de transici on de estado.
2.2.3.
Aut omatas conmutados
Los aut omatas celulares son uniformes tanto en su composici on como en el patr on de sus interconexiones. Si eliminamos estas restricciones, considerando aun la
58
conexi on de componentes de estado nito entre s , obtenemos otra clase de modelos de tiempo discreto. Los aut omatas conmutados (tambi en llamados circuitos digitales) se construyen a partir de ip-ops (tambi en denominados biestables) y puertas l ogicas. El biestable m as sencillo es el tipo D, cuya tabla de transici on de estado y salidas es la siguiente:
Estado Entrada actual actual 0 0 0 1 1 0 1 1
Estado siguiente 0 1 0 1
Salida actual 0 0 1 1
En lugar de permitir que la entrada del ip-op se propague directamente a su salida, la salida es el estado actual (al igual que en el aut omata celular). El estado siguiente es igual a la entrada actual. En la tabla siguiente, se muestra un ejemplo del funcionamiento del biestable D, en el cual se comprueba que la salida sigue a la entrada, pero retrasada un paso en el tiempo:
Tiempo Trayectoria de entrada Trayectoria de estado Trayectoria de salida
0 1 0 0
1 0 1 1
2 1 0 0
3 0 1 1
4 1 0 0
5 0 1 1
6 1 0 0
7 0 1 1
8 1 0 0
9 0 1 0 1
La diferencia entre los modelos de m aquinas secuenciales de Mealy y de Moore es que en los modelos de Mealy la entrada puede propagarse instant aneamente a la salida. Esta caracter stica de los modelos de Mealy (la propagaci on a trav es del espacio en un tiempo cero) permite que la realimentaci on de la salida a la entrada pueda producir c rculos viciosos. Para la construcci on de redes, adem as de ip-ops podemos usar puertas l ogicas, que permiten implementar funciones booleanas. La salida de las puertas l ogicas est a determinado por sus entradas, sin intervenci on de ning un estado interno. El reloj, empleado normalmente en circuitos s ncronos, determina el paso de avance en el tiempo, que es constante.
59
Por ejemplo, en la Figura 2.4 se muestran un aut omata conmutado construido conectando en serie varios ip-ops tipo D. La realimentaci on est a denida mediante la conexi on de varias puertas XOR. Cada ip-op es un componente elemental de memoria, como suced a con las c elulas. Los ip-ops q1 a q7 est an conectados en serie, es decir, el estado del ip-op i dene el siguiente estado del ip-op i 1.
q8
q7
q6
q5
q4
q3
q2
q1
Figura 2.4: Registro de desplazamiento construido conectando ip-ops D y puertas XOR.
Esta secuencia lineal de ip-ops se llama registro de desplazamiento, ya que desplaza la entrada hacia el primer componente de la derecha en cada paso de tiempo. La entrada al ip-op situado m as a la izquierda se construye usando puertas l ogicas. En este caso, mediante la conexi on XOR de estados y de la entrada global: x q8 q6 q5 q3 q1 . La salida de una puerta XOR es la operaci on or-exclusiva de sus entradas: la salida vale 0 si y s olo si ambas entradas tienen el mismo valor; en caso contrario la salida vale 1.
2.2.4.
Redes lineales de tiempo discreto
En la Figura 2.5 se muestra una red de Moore con dos elementos de memoria y dos elementos sin memoria. A diferencia de los aut omatas conmutados descritos en la Secci on 2.2.3, que emplean n umeros binarios, la red est a denida sobre los n umeros reales. 0 g , g 0 donde g y g representan las ganancias de los elementos sin memoria. Supongamos que el estado inicial de los elementos con memoria est a representado por el vector 1 , es decir, cada retardo est a inicialmente en el estado 1. Entonces, puede 1 La estructura de la red puede representarse mediante una matriz, calcularse el estado de la red en el siguiente paso de tiempo, siguiente: q1 q2 , de la forma
60
Retardo de Moore
Retardo de Moore
-g
Figura 2.5: Red de Moore lineal y trayectorias del estado en funci on del valor de g .
q1 q2
0 g g 0
1 1
g g
(2.5)
Es posible emplear una representaci on matricial y la operaci on producto porque la red tiene una estructura lineal. Esto signica que todos los componentes producen salidas o estados que son combinaci on lineal de sus entradas y estados. Un retardo es un elemento lineal muy simple: su siguiente estado es igual a su entrada actual. Un elemento sin memoria con un factor de ganancia se denomina un elemento coeciente, y multiplica su entrada actual por la ganancia para producir la salida. Ambos son ejemplos sencillos de linealidad. Un sumador, que es un elemento sin memoria que suma sus entradas para obtener la salida, es tambi en un elemento lineal.
61
Un sistema de tiempo discreto de Moore est a en forma matricial lineal si sus funciones de transici on de estado y de salida pueden expresarse mediante matrices {A, B, C}. Esto signica que su funci on de transici on de estado puede expresarse de la forma siguiente: (q, x) = Aq + Bx (2.6)
donde q es un vector n-dimensional de estado y A es una matriz cuadrada de dimensi on n n. Igualmente, x es un vector m-dimensional de entrada y B es una matriz de dimensi on n m. La funci on de salida es: (q) = Cq (2.7)
donde, si la salida y es un vector p-dimensional, entonces C es una matriz de dimensi on p n. La trayectoria en el estado del sistema lineal mostrado en la Figura 2.5 se obtiene g multiplicando la matriz q por los sucesivos estados. As , si es el estado que g sigue a 1 1 , entonces el siguiente estado es: 0 g g 0 g g g 2 g 2
(2.8)
y as sucesivamente. En este sistema, hay tres tipos diferentes de trayectorias del estado (v ease la Figura 2.5): Cuando g = 1 hay una oscilaci on indenida entre los valores 1 y 1. Cuando g < 1 la envolvente de los valores decae exponencialmente. Cuando g > 1 la envolvente de los valores crece exponencialmente.
2.3.
DE TIEMPO CONTINUO MODELADO Y SIMULACION
En los modelos de tiempo discreto, si se conoce el valor actual de las variables de estado y de las entradas, entonces la funci on de transici on de estado permite calcular las variables de estado en el siguiente paso de tiempo.
62
Por el contrario, los modelos de tiempo continuo no especican de manera directa el valor de las variables de estado en el siguiente paso de tiempo. En su lugar, el modelo describe la velocidad con la que cambian en el tiempo las variables de estado. La derivada de una variable de estado es la velocidad de cambio de dicha variable de estado respecto al tiempo. En un determinado instante de tiempo, conocido el valor de las variables de estado y de las entradas, podemos calcular el valor de la derivada respecto al tiempo de las variables de estado, es decir, la velocidad a la que cambian las variables de estado. Conocido el valor de las derivadas de las variables de estado, mediante integraci on num erica se calcula el valor de las variables de estado en el instante futuro de tiempo. A continuaci on, describiremos todo esto de manera m as detallada.
2.3.1.
Variables y ecuaciones
Los modelos matem aticos de tiempo continuo est an compuestos por ecuaciones, que describen la relaci on entre las magnitudes relevantes del sistema. Estas magnitudes reciben el nombre de variables. El siguiente ejemplo pretende ilustrar estos conceptos. Ejemplo 2.3.1. Sobre un objeto de masa constante (m) act uan dos fuerzas: la fuerza de la gravedad (m g ), y una fuerza arm onica de amplitud (F0 ) y frecuencia ( ) constantes. La fuerza total (F ) aplicada sobre el objeto es: F = m g + F0 sin ( t) (2.9)
donde g es la aceleraci on gravitatoria, que se considera constante. Se aplica el criterio siguiente: la aceleraci on tiene signo positivo cuando tiene sentido vertical ascendente. Por ejemplo, la aceleraci on gravitatoria terrestre ser a g = 9.8 m s2 La fuerza neta (F ) aplicada sobre el objeto hace que este adquiera una aceleraci on (a), que viene determinada por la relaci on siguiente: ma=F (2.10)
La posici on y la velocidad del objeto pueden calcularse teniendo en cuenta que la derivada respecto al tiempo de la posici on es la velocidad, y que la derivada respecto al tiempo de la velocidad es la aceleraci on. El modelo obtenido es el siguiente:
63
F = m g + F0 sin ( t) ma = F dx = v dt dv = a dt
(2.11) (2.12) (2.13) (2.14)
Este modelo est a compuesto por cuatro ecuaciones, Ecs. (2.11) (2.14), las cuales describen la relaci on existente entre las magnitudes relevantes del sistema, que son las variables del modelo: La aceleraci on gravitatoria (g ), La amplitud (F0 ) y frecuencia ( ) de la fuerza arm onica, La fuerza neta (F ) aplicada sobre el objeto La masa (m), posici on (x), velocidad (v ) y aceleraci on (a) del objeto.
Par ametros, variables de estado y variables algebraicas El punto de partida para la simulaci on del modelo consiste en clasicar sus variables de acuerdo al criterio siguiente: Par ametros. Son aquellas variables cuyo valor permanece constante durante la simulaci on. Variables de estado. Son las variables que est an derivadas respecto al tiempo. Variables algebraicas. Son las restantes variables del modelo. Es decir, aquellas que no aparecen derivadas en el modelo y que no son constantes. Ejemplo 2.3.2. De acuerdo con la clasicaci on anterior, el modelo descrito en el Ejemplo 2.3.1 tiene: Cuatro par ametros: g , m, F0 , .
64
Dos variables de estado: x, v . Dos variables algebraicas: a, F . Obs ervese que la variable tiempo (t) no se incluye en la clasicaci on. Ejemplo 2.3.3. Consid erese el circuito el ectrico mostrado en la Figura 2.6, el cual est a compuesto por un generador de tensi on, dos resistencias y un condensador.
R i i
u
C
Figura 2.6: Circuito RC.
El modelo de este circuito consta de las ecuaciones siguientes:
u = u0 sin ( t) iR1 = iR2 + iC u uC = R1 iR1 duC = iC C dt uC = iR2 R2
(2.15) (2.16) (2.17) (2.18) (2.19)
La Ec. (2.15) es la relaci on constitutiva del generador de tensi on. La amplitud (u0 ) y la frecuencia ( ) son independientes del tiempo (t). Las Ecs. (2.17) y (2.19) son las relaciones constitutivas de las resistencias. La Ec. (2.18) es la relaci on constitutiva del condensador. Los valores de la capacidad (C ) y de las resistencias (R1 , R2 ) son independientes del tiempo. Finalmente, la Ec. (2.16) impone que la suma de las corrientes entrantes a un nodo debe ser igual a la suma de las corrientes salientes del mismo. Las variables de este modelo se clasican de la manera siguiente: Par ametros: u0 , , C , R1 , R2 .
65
Variable de estado: uC . Variables algebraicas: u, iR1 , iR2 , iC .
Ecuaciones En la siguiente tabla se muestra una clasicaci on de los modelos de tiempo continuo descritos mediante ecuaciones algebraicas y diferenciales. El vector x representa las variables del modelo. En la formulaci on semi-expl cita, en la cual las derivadas aparecen despejadas, el vector x se ha dividido en dos vectores, x1 y x2 , que representan las variables de estado y algebraicas respectivamente.
Semi-expl cito
Impl cito
Lineal
x 1 + B11 (t) x1 (t) + B12 (t) x2 (t) = f1 (t) B21 (t) x1 (t) + B22 (t) x2 (t) = f2 (t)
A (t) x (t) + B (t) x (t) = f (t)
No lineal
x 1 (t) = f1 (t, x1 (t) , x2 (t)) 0 = f2 (t, x1 (t) , x2 (t))
F (t, x (t) , x (t)) = 0
2.3.2.
Algoritmo para la simulaci on
En la Figura 2.7 se muestra un algoritmo para la simulaci on de modelos de tiempo continuo. Puede comprobarse que la clasicaci on de las variables del modelo en par ametros, variables de estado y variables algebraicas constituye la base para la simulaci on del modelo: Al comenzar la simulaci on, se asignan valores a los par ametros. Estos valores permanecen constantes durante toda la simulaci on. Las variables de estado son calculadas mediante la integraci on num erica de sus derivadas. Por ejemplo, la funci on de paso del m etodo expl cito de Euler para
66
Inicio Asignar valor al incremento en el tiempo (t) t=0 Asignar valor a los parmetros Asignar valor inicial a las variables de estado Calcular el valor, en el instante t, de las variables algebraicas y de las derivadas
s
t=t+t
Terminar
no
Fin
Calcular el valor, en instante t+t, de las variables de estado
Figura 2.7: Algoritmo de la simulaci on de los modelos matem aticos de tiempo continuo.
Inicio

t = 0.01
t=0

m = 10, F0 = 15, w = 10, g = -9.8

x(0) = 10, v(0) = 7

t=t+t F(t) = m*g + F0 * sin(w*t) a(t) = F(t) / m derx(t) = v(t) derv(t) = a(t)
s

x(t) < 0
no
Fin
x(t+t) = x(t) + derx(t) * t v(t+t) = v(t) + derv(t) * t
Figura 2.8: Algoritmo de la simulaci on del modelo descrito en el Ejemplo 2.3.1.
67
la ecuaci on diferencial ordinaria dx = f (x, t) dt es la siguiente: xi+1 = xi + f (xi , ti ) t (2.21) (2.20)
donde xi y xi+1 representan el valor de la variable de estado x en los instantes ti y ti + t respectivamente, y f (xi , ti ) representa el valor de la derivada de x (es decir, dx ) en el instante ti . dt El valor de las variables algebraicas se calcula, en cada instante de tiempo, a partir de valor de las variables de estado en ese instante y del valor de los par ametros. La condici on de terminaci on de la simulaci on depende del estudio en concreto que vaya a realizarse sobre el modelo. Puede ser, por ejemplo, que se alcance determinado valor de la variable tiempo, o que una determinada variable satisfaga cierta condici on. El valor del tama no del paso de integraci on (t) debe escogerse alcanzando un compromiso entre precisi on y carga computacional. Cuanto menor sea el valor de t, menor es el error que se comete en el c alculo de las variables del modelo, pero mayor es el tiempo de ejecuci on de la simulaci on. Un procedimiento para estimar el error cometido al escoger un determinado valor de t es comparar los resultados obtenidos usando ese valor y los obtenidos usando t un valor menor, por ejemplo, . Si la diferencia entre ambos resultados es aceptable 2 para los prop ositos del estudio de simulaci on que se est a realizando, entonces el valor t t es adecuado. En caso contrario, se comparan los resultados obtenidos usando 2 t t y . Si el error es aceptable, de emplea . Si el error es demasiado grande, se 4 2 t t investigan los valores 4 y 8 , y as sucesivamente. El m etodo explicado anteriormente es conceptualmente muy sencillo, sin embargo no es eciente desde el punto de vista computacional. Por ese motivo, los m etodos num ericos de paso variable no emplean este procedimiento. Como ilustraci on de los procedimientos empleados en la pr actica, en la Secci on 2.3.4 se describir a el m etodo para adaptar el tama no del paso de integraci on empleado por el algoritmo de RungeKutta-Fehlberg (RKF45) . Ejemplo 2.3.4. En la Figura 2.8 se muestra el algoritmo de la simulaci on del modelo descrito en el Ejemplo 2.3.1. Obs ervese que:
68
Las derivadas de las variables de estado se han sustituido por variables auxiliares, cuyo nombre es igual al de la variable de estado, pero anteponi endole el prejo der:
dx derx dt dv derv dt
(2.22) (2.23)
Para realizar el c alculo de las variables algebraicas y las derivadas, se ha despejado de cada ecuaci on la variable a calcular y se han ordenado las ecuaciones, de modo que sea posible resolverlas en secuencia. Se ha obtenido la siguiente secuencia de asignaciones:
F = m g + F0 sin ( t) F a = m derx = v derv = a
(2.24) (2.25) (2.26) (2.27)
La secuencia de c alculos, seg un se muestra en la Figura 2.8, es la siguiente:
t=0
m = 10, F0 = 15, = 10, g = 9.8 x(0) = 10, v (0) = 7 F (0) = m g + F0 sin ( t) F (0) = 10 (9.8) + 15 sin(10 0) = 98 a(0) = F (0)/m a(0) = 98/10 = 9.8 derx(0) = v (0) derx(0) = 7 derv (0) = a(0) derv (0) = 9.8 x(0.01) = x(0) + derx(0) t x(0.01) = 10 + 7 0.01 = 10.07 v (0.01) = v (0) + derv (0) t v (0.01) = 7 + 9.8 0.01 = 6.902
t = 0.01
F (0.01) = m g + F0 sin ( t) F (0.01) = 10 (9.8) + 15 sin(10 0.01) = 96.5025 a(0.01) = F (0.01)/m a(0.01) = 96.5025/10 = 9.65025 derx(0.01) = v (0.01) derx(0.01) = 6.902 derv (0.01) = a(0.01) derv (0.01) = 9.65025 x(0.02) = x(0.01) + derx(0.01) t x(0.02) = 10.07 + 6.902 0.01 = 10.139 v (0.02) = v (0.01) + derv (0.01) t v (0.02) = 6.902 + 9.65025 0.01 = 6.8055
t = 0.02
Y as sucesivamente ...
69
14 12 10 8 6 4 2 0 0
10 5 0 -5 -10 -15 -20

1 2
Figura 2.9: Resultado de la ejecuci on del algoritmo mostrado en la Figura 2.8.
0.01 0.00 -0.01 -0.02 -0.03 -0.04 -0.05 -0.06

0
{x con t=0.005} {x con t=0.01}
Figura 2.10: Diferencia en la evoluci on temporal de la posici on para dos valores de t.
En la Figura 2.9 se muestra la evoluci on de la posici on, la velocidad y la aceleraci on del objeto, obtenidas ejecutando el algoritmo mostrado en la Figura 2.8. En el eje horizontal de ambas gr acas se representa el tiempo. La condici on de nalizaci on de la simulaci on es que el objeto toque el suelo. Es decir, que se satisfaga la condici on: x < 0. Cabe plantearse si el valor 0.01 para el tama no del paso de integraci on (t) es adecuado. En la Figura 2.10 se muestra la diferencia entre la posici on del objeto, calculada usando t = 0.005, y la posici on calculada usando t = 0.01. En el eje horizontal est a representado el tiempo. Esta gr aca permite obtener una idea de c omo va acumul andose el error y cu al es la magnitud de este. Dependiendo cu al sea el objetivo del estudio de simulaci on, esta magnitud del error (y consecuentemente, el valor t = 0.01) ser a o no aceptable.
70
2.3.3.
Causalidad computacional
Como se ha mostrado en el Ejemplo 2.3.4, para realizar el c alculo de las variables algebraicas y las derivadas, es preciso despejar de cada ecuaci on la variable a calcular y ordenar las ecuaciones, de modo que sea posible resolverlas en secuencia. Esto tiene un car acter general. Para plantear el algoritmo de la simulaci on de un modelo de tiempo continuo, es preciso realizar las tareas siguientes: 1. Decidir qu e variable debe calcularse de cada ecuaci on y c omo deben ordenarse las ecuaciones del modelo, de modo que puedan ser resueltas en secuencia. A esta decisi on se la denomina asignaci on de la causalidad computacional. 2. Una vez se ha decidido qu e variable debe evaluarse de cada ecuaci on, debe manipularse simb olicamente la ecuaci on a n de despejar dicha variable. Ejemplo 2.3.5. Sup ongase que se desea modelizar una resistencia el ectrica mediante la Ley de Ohm. La Ley de Ohm establece que la ca da de potencial, u, entre los bornes de una resistencia es igual al producto de un par ametro caracter stico de la resistencia, R, por la intensidad de la corriente el ectrica, i, que circula a trav es de la resistencia: u=iR (Ley de Ohm) (2.28)
Esta ecuaci on constituye una relaci on entre las tres variables u, R e i, que es v alida para cualquiera de las tres posibles causalidades computacionales admisibles de la ecuaci on: [u] = i R [i] = u R [R] = u i (2.29)
donde se ha se nalado la variable a evaluar de cada ecuaci on incluy endola entre corchetes y se ha despejado escribi endola en el lado izquierdo de la igualdad. La consideraci on fundamental que debe hacerse llegado este punto es que la causalidad computacional de una determinada ecuaci on del modelo no s olo depende de ella misma, sino que tambi en depende del resto de las ecuaciones del modelo. Es decir, la causalidad computacional es una propiedad global del modelo completo. Ejemplo 2.3.6. La casualidad computacional de la ecuaci on de la resistencia, presentada en el Ejemplo 2.3.5, depende del resto de las ecuaciones del modelo. Si la
71
[ ] = ( )
[ ]=

[ ]=

( )
[ ] =
a)
b)
Figura 2.11: La causalidad computacional es una propiedad del modelo completo.
resistencia se conecta a un generador de tensi on senoidal, las ecuaciones del modelo son:
u = [i] R
Relaci on constitutiva de la resistencia
(2.30)
[u] = u0 sin ( t) Relaci on constitutiva del generador de tensi on (2.31) donde R, u0 y son par ametros del modelo, es decir, su valor se supone conocido y no es preciso evaluarlos de las ecuaciones del modelo. En las Ecs. (2.30) y (2.31) se ha se nalado entre corchetes la variable que debe evaluarse de cada ecuaci on. Para simular el modelo es preciso ordenar las ecuaciones y despejar la variable a evaluar en cada una de ellas. Realizando la ordenaci on y la manipulaci on simb olica, se obtiene (v ease la Figura 2.11a):
[u] = u0 sin ( t) u [i] = R
(2.32) (2.33)
Como puede verse, en primer lugar debe calcularse el valor de la ca da de tensi on, a partir de la relaci on constitutiva del generador, y a continuaci on debe calcularse la corriente, a partir de la relaci on constitutiva de la resistencia (para lo cual debe usarse el valor de la tensi on que ha sido previamente calculado). En cambio, si esta misma resistencia se conecta a un generador sinusoidal de corriente, las ecuaciones del modelo, una vez ordenadas y manipuladas simb olicamente, ser an (v ease la Figura 2.11b):
72
[i] = i0 sin ( t) [u] = i R
(2.34) (2.35)
En este caso, en primer lugar debe calcularse el valor de la corriente, a partir de la relaci on constitutiva del generador, y a continuaci on debe calcularse la ca da de tensi on, a partir de la relaci on constitutiva de la resistencia (para lo cual debe usarse el valor de la corriente que se ha sido previamente calculado). Se observa que en el caso de la Ec. (2.33) la relaci on constitutiva de la resistencia se usa para calcular la corriente, mientras que en el caso de la Ec. (2.35) se usa para calcular la ca da de tensi on. La variable a evaluar depende no s olo de la relaci on constitutiva de la resistencia, sino tambi en del resto del modelo. A continuaci on, se describe un procedimiento sistem atico para asignar la causalidad computacional de un modelo. Sin embargo, para aplicarlo deben previamente clasicarse las variables del modelo en conocidas y desconocidas, seg un sean conocidas o desconocidas en el instante de evaluaci on. En primer lugar, por tanto, se explicar a c omo realizar esta clasicaci on.
Variables conocidas y desconocidas A efectos de la asignaci on de la causalidad computacional, las variables del modelo se clasican en desconocidas (o inc ognitas) y conocidas. Dicha clasicaci on se realiza en funci on de que el valor de la variable deba o no ser evaluado de las ecuaciones del modelo. Las variables conocidas son las siguientes: La variable tiempo. Los par ametros del modelo. La persona que formula el modelo decide qu e variables son par ametros. La caracter stica distintiva de este tipo de variables es que no son calculadas de las ecuaciones del modelo, sino que se les asigna valor al inicio de la simulaci on (en la llamada fase de nicializaci on del modelo) y este permanece constante durante toda la simulaci on. Puesto que los par ametros no deben ser calculados de las ecuaciones del modelo, a efectos de la asignaci on de la causalidad computacional, se considera que los par ametros son variables conocidas.
73
Las entradas globales al modelo, es decir, aquellas variables cuyo valor se especica, independientemente del de las dem as variables, para cada instante de la simulaci on. Las variables que aparecen derivadas en el modelo, ya que son consideradas variables de estado, es decir, se asume que se calculan mediante la integraci on num erica de su derivada. El motivo es evitar tener que derivar num ericamente en tiempo de simulaci on. Por tanto, toda variable que aparece derivada en el modelo se clasica como una variable de estado. Con el n de formular el modelo de manera adecuada para su simulaci on, se sustituye la derivada de cada variable de estado, all donde aparezca, por una variable auxiliar (por ejemplo, de nombre igual al de la variable de estado, pero anteponiendo el prejo der). Estas variables auxiliares se clasican como desconocidas y se a nade al modelo la condici on de que cada variable de estado se calcula por integraci on num erica de su correspondiente variable auxiliar. As pues, las variables desconocidas son las siguientes: Las variables auxiliares introducidas, de la forma descrita anteriormente, sustituyendo a las derivadas de las variables de estado. Las restantes variables del modelo, es decir, aquellas que, no apareciendo derivadas, dependen para su c alculo en el instante de evaluaci on del valor de otras variables. Estas variables se denominan variables algebraicas. Ejemplo 2.3.7. Consid erese el circuito mostrado en la Figura 2.6. El modelo est a compuesto por las ecuaciones siguientes: u = u0 sin ( t) iR1 = iR2 + iC u uC = R1 iR1 duC C = iC dt uC = iR2 R2 (2.36) (2.37) (2.38) (2.39) (2.40)
La variable uC aparece derivada, con lo cual es una variable de estado del modelo. Con el n de realizar la asignaci on de la causalidad computacional, se sustituye duC C en el modelo dt por la variable auxiliar deruC . Realizando esta sustituci on ( du dt por deruC ), se obtiene el modelo siguiente:
74
u = u0 sin ( t) iR1 = iR2 + iC u uC = R1 iR1 C deruC = iC uC = iR2 R2
(2.41) (2.42) (2.43) (2.44) (2.45)
A efectos de la asignaci on de la causalidad computacional, se considera que: La variable de estado, uC , es conocida. La derivada de la variable de estado, deruC , es desconocida. Al realizar la simulaci on, uC se calcular a integrando deruC . Descontando del n umero total de ecuaciones el n umero de variables de estado, se obtiene el n umero de ecuaciones disponibles para el c alculo de variables algebraicas. Este n umero determina el n umero de variables algebraicas del modelo. El resto de las variables deber an ser par ametros. La persona que realiza el modelo deber a decidir, de entre las variables que no son estados, cu ales son las variables algebraicas y cu ales los par ametros. En este ejemplo s olo hay una variable de estado: uC . As pues, debe emplearse una de las ecuaciones del modelo para evaluar su derivada: deruC . Puesto que deruC s olo interviene en la Ec. (2.44), debe emplearse esta ecuaci on para calcular deruC . Las restantes cuatro ecuaciones permiten calcular cuatro variables algebraicas. Una posible elecci on de las variables algebraicas es la siguiente: u, iR1 , iR2 , iC . En consecuencia, las variables desconocidas son las siguientes: u, iR1 , iR2 , iC y deruC . El resto de las variables del modelo deber an ser par ametros: u0 , , R1 , R2 y C . Este modelo tiene s olo 5 ecuaciones y 5 inc ognitas, con lo cual la causalidad computacional puede asignarse de manera sencilla (en el siguiente ep grafe se explica un m etodo sistem atico para hacerlo). Asignar la causalidad computacional es decidir en qu e orden deben evaluarse las ecuaciones y qu e inc ognita debe evaluarse de cada ecuaci on, a n de calcular las inc ognitas u, iR1 , iR2 , iC y deruC del conjunto de Ecuaciones (2.41) (2.45). A continuaci on, se se nala en cada ecuaci on del modelo qu e inc ognita debe calcularse de ella. Para ello, se incluye entre corchetes la inc ognita a evaluar de cada ecuaci on:
75
[u] = u0 sin ( t) iR1 = iR2 + [iC ] u uC = R1 [iR1 ] C [deruC ] = iC uC = [iR2 ] R2 Ordenando las ecuaciones del modelo, se obtiene:
(2.46) (2.47) (2.48) (2.49) (2.50)
[u] = u0 sin ( t) uC = [iR2 ] R2 u uC = R1 [iR1 ] iR1 = iR2 + [iC ] C [deruC ] = iC
(2.51) (2.52) (2.53) (2.54) (2.55)
Finalmente, despejando en cada ecuaci on la inc ognita que debe ser evaluada de ella, se obtiene el modelo ordenado y resuelto:
[u] = u0 sin ( t) uC [iR2 ] = R2 u uC [iR1 ] = R1 [iC ] = iR1 iR2 iC [deruC ] = C
(2.56) (2.57) (2.58) (2.59) (2.60)
Adem as, debe realizarse el c alculo de la variable de estado mediante la integraci on de su derivada: d [uC ] = deruC dt (2.61)
76
Obs ervese que, en general, la clasicaci on de las variables en algebraicas y par ametros puede realizarse de varias maneras, en funci on de cu al sea el experimento que desee realizarse sobre el modelo. Para comprobar si una determinada clasicaci on es v alida, es preciso realizar la asignaci on de la causalidad computacional, y comprobar que efectivamente las variables algebraicas seleccionadas pueden evaluarse de las ecuaciones del modelo. Una selecci on de las variables algebraicas alternativa a la anterior consistir a en escoger R1 y R2 como variables algebraicas, en lugar de iR1 e iR2 . En este caso, iR1 e iR2 ser an par ametros.
Asignaci on de la causalidad computacional A continuaci on, se describe un procedimiento sistem atico para asignar la causalidad computacional de un modelo. Consta de dos pasos. En primero consiste en comprobar que el modelo no es estructuralmente singular. El segundo paso es la asignaci on en s de la causalidad. Paso 1 - Singularidad estructural del modelo. Antes de realizar la partici on se comprueba la no singularidad estructural del modelo. Es decir, se comprueba que: El n umero de ecuaciones y de inc ognitas (obtenido siguiendo el criterio anterior de clasicaci on de las variables en conocidas y desconocidas) es el mismo. Cada inc ognita puede emparejarse con una ecuaci on en que aparezca y con la cual no se haya emparejado ya otra inc ognita. Si alguna de estas dos condiciones no se verica, se dice que el modelo es singular y es necesario reformularlo para poder simularlo. Si el modelo no es singular, se procede a asignar la casualidad computacional. Ejemplo 2.3.8. Considere un modelo con tres variables: x, y , z . El modelo est a compuesto por tres ecuaciones, en cada una de las cuales intervienen las variables siguientes: f1 (x, y, z ) = 0 dx f2 x, , y = 0 dt f3 (x, z ) = 0 (2.62) (2.63) (2.64)
77
Sustituyendo la derivada de la variable x por la variable auxiliar (derx), se obtiene un modelo compuesto por las tres ecuaciones siguientes: f1 (x, y, z) = 0 f2 (x, derx, y ) = 0 f3 (x, z ) = 0 (2.65) (2.66) (2.67)
Dicho modelo tiene tres inc ognitas: derx, y , z . La variable x, por aparecer derivada, se supone que es una variable de estado: se calcula integrando derx, y no de las ecuaciones del modelo. Se comprueba que este modelo no es singular, ya que cada ecuaci on puede asociarse con una inc ognita que interviene en ella y que no se ha asociado con ninguna otra ecuaci on (obs ervese que, en general, esta asociaci on puede no ser u nica):
f1 (x, y, z ) = 0 f2 (x, derx, y ) = 0 f3 (x, z ) = 0
y derx z
(2.68) (2.69) (2.70)
Ejemplo 2.3.9. Considere un modelo con tres variables: x, y , z . El modelo est a compuesto por tres ecuaciones, en cada una de las cuales intervienen las variables siguientes: f1 (z ) = 0 dx ,y = 0 dt f3 (x) = 0 (2.71) (2.72) (2.73)
f2
Dicho modelo tiene tres inc ognitas: derx, y , z . Observe que la tercera ecuaci on (f3 (x) = 0) no contiene ninguna inc ognita, mientras que la segunda ecuaci on contiene dos inc ognitas que no aparecen en ninguna otra ecuaci on del modelo (f2 (derx, y ) = 0). En consecuencia, el modelo es singular y por tanto es necesario reformularlo. Paso 2 - Asignaci on de la causalidad computacional. Una vez se ha comprobado que el modelo no es singular, se realiza la asignaci on de causalidad computacional siguiendo las tres reglas siguientes:
78
1. Las variables que aparecen derivadas se consideran variables de estado y se suponen conocidas, ya que se calculan por integraci on a partir de sus derivadas. Las derivadas de las variables de estado son desconocidas y deben calcularse de las ecuaciones en que aparezcan. 2. Las ecuaciones que poseen una u nica inc ognita deben emplearse para calcularla. 3. Aquellas variables que aparecen en una u nica ecuaci on deben ser calculadas de ella. Aplicando las tres reglas anteriores a sistemas no singulares, pueden darse las dos situaciones siguientes: 1. Se obtiene una soluci on que permite calcular todas las inc ognitas usando para ello todas las ecuaciones. Esto signica que las variables pueden ser resueltas, una tras otra, en secuencia. En este caso, el algoritmo proporciona una ordenaci on de las ecuaciones tal que en cada ecuaci on hay una y s olo una inc ognita que no haya sido previamente calculada. En ocasiones ser a posible despejar la inc ognita de la ecuaci on. En otros casos, la inc ognita aparecer a de forma impl cita y deber an emplearse m etodos num ericos para evaluarla. 2. Se llega a un punto en que todas las ecuaciones tienen al menos dos inc ognitas y todas las inc ognitas aparecen al menos en dos ecuaciones. Corresponde al caso en que hay sistema de ecuaciones. Si en este sistema las inc ognitas intervienen linealmente, ser a posible despejarlas resolviendo el sistema simb olicamente. Si al menos una de las inc ognitas interviene de forma no lineal, deber an emplearse m etodos num ericos para evaluar las inc ognitas. El algoritmo de partici on asegura que la dimensi on de los sistemas de ecuaciones obtenidos es m nima. Ejemplo 2.3.10. A continuaci on, se realiza la partici on del modelo descrito en el Ejemplo 2.3.8. Indicando u nicamente las inc ognitas que intervienen en cada ecuaci on se obtiene: f1 (y, z) = 0 f2 (derx, y ) = 0 f3 (z ) = 0 (2.74) (2.75) (2.76)
La variable z es la u nica inc ognita que aparece en la ecuaci on f3 , por tanto debe emplearse esta ecuaci on para calcular z . Las ecuaciones que quedan por emplear, y
79
las inc ognitas que quedan por evaluar son: f1 (y ) = 0 f2 (derx, y ) = 0 (2.77) (2.78)
Debe emplearse f1 para calcular y . Seguidamente, debe emplearse f2 para calcular derx. Las ecuaciones ordenadas, con la causalidad computacional se nalada, son las siguientes: f3 (x, [z ]) = 0 f1 (x, [y ] , z ) = 0 f2 (x, [derx] , y ) = 0 (2.79) (2.80) (2.81)
2.3.4.
M etodos de integraci on num erica
Como hemos visto anteriormente, las ecuaciones del modelo permiten calcular las variables algebraicas y las derivadas de las variables de estado. En esta secci on analizaremos diferentes formas de calcular las variables de estado a partir del valor de sus derivadas. El c alculo se realiza mediante la aplicaci on de alg un m etodo num erico de integraci on. Una vez conocidas en el instante ti las variables de estado, las variables algebraicas y las derivadas de las variables de estado, el problema consiste en calcular la variables de estado en el siguiente instante, ti+1 . Se supone que el modelo es continuo en el intervalo [ti , ti+1 ], y que las entradas, el estado y las variables de salida cambian de manera continua en ese intervalo de tiempo. A continuaci on, se describen cuatro m etodos de integraci on num erica sencillos. Los cuatro m etodos pertenecen a la categor a de los m etodos expl citos de integraci on. Estos son: Euler expl cito Punto medio (Euler-Richardson) Runge-Kutta (4 orden) Runge-Kutta-Fehlberg (4 -5 orden)
80
En los tres primeros m etodos, el paso de integraci on se escoge antes de iniciar la simulaci on y se mantiene jo durante toda la simulaci on. Por el contrario, el m etodo de Runge-Kutta-Fehlberg es de paso variable. Es decir, el algoritmo de integraci on va estimando el error cometido, y reduce o aumenta en consecuencia el tama no del paso de integraci on.
M etodo de Euler expl cito La funci on de paso del m etodo de Euler para la ecuaci on diferencial ordinaria dx = f (x, t) dt es la siguiente: xi+1 = xi + f (xi , ti ) t que corresponde con un desarrollo de Taylor truncado en el primer orden. Ejemplo 2.3.11. El modelo cinem atico de una masa puntual (m), sobre la que act ua una fuerza (F ), consta de las ecuaciones siguientes: (2.83) (2.82)
dy dt dv a = dt F (y, v, t) a = m v =
(2.84) (2.85) (2.86)
El algoritmo para integrar este modelo, empleando el m etodo de Euler expl cito, es el siguiente: 1. Deben conocerse los valores de las variables de estado (y , v ) en el instante inicial de la simulaci on (t0 ). Sean estos valores: y0 , v0 . Tambi en debe jarse el tama no del paso de integraci on (t). 2. C alculo de la aceleraci on de la part cula (ai ), que es una variable algebraica: ai = F (yi , vi , ti ) m (2.87)
81
3. Se calcula el valor de las variables de estado en el nuevo instante de tiempo: vi+1 = vi + ai t yi+1 = yi + vi t (2.88) (2.89)
La velocidad al nal del intervalo (vi+1 ) se calcula de la aceleraci on al principio del intervalo (ai ). Igualmente, la posici on al nal del intervalo (yi+1 ) se calcula de la aceleraci on al principio del intervalo (vi ). 4. Avance de un paso en el tiempo e incremento del ndice i: ti+1 = ti + t i = i+1 5. Volver al Paso 2. (2.90) (2.91)
M etodo de Euler-Richardson El algoritmo de Euler-Richardson usa la derivada en el principio del intervalo para estimar el valor de la variable de estado en el punto medio del intervalo (tmed = t t+ ). A continuaci on, emplea la derivada en este punto medio para calcular la 2 variable de estado al nal del intervalo. Este algoritmo tambi en se conoce como algoritmo de Runge-Kutta de 2 orden o del punto medio. La funci on de paso del m etodo de Euler-Richardson para la ecuaci on diferencial ordinaria dx = f (x, t) (2.92) dt es la siguiente: xmed = xi + f (xi , ti ) xi+1 = xi + f t 2 t 2 t (2.93) (2.94)
xmed , ti +
Ejemplo 2.3.12. El modelo de la masa puntual descrito en el Ejemplo 2.3.11 puede integrarse, empleando el algoritmo de Euler-Richardson, de la forma siguiente:
82
vmed = vi + ai ymed amed y
t 2 t = yi + vi 2 F ymed , vmed , ti + = m
(2.95) (2.96)
t 2
(2.97)
vi+1 = vi + amed t yi+1 = yi + vmed t
(2.98) (2.99)
M etodo de Runge-Kutta (4 orden) Este m etodo se emplea con mucha frecuencia. Requiere cuatro evaluaciones de la derivada por cada paso en el tiempo. Se denomina de 4 orden porque considera el desarrollo de Taylor hasta 4 orden. La funci on de paso para la ecuaci on diferencial ordinaria dx = f (x, t) (2.100) dt es la siguiente: k1 = t f (xi , ti ) k2 = t f k3 k4 xi+1 k1 t , ti + 2 2 k2 t = t f xi + , ti + 2 2 = t f (xi + k3 , ti + t) k1 k2 k3 k4 = xi + + + + 6 3 3 6 xi + (2.101) (2.102) (2.103) (2.104) (2.105)
M etodo de Runge-Kutta-Fehlberg (4 -5 orden) Se trata de un m etodo de 4 orden embebido dentro de un m etodo de 5 orden. El error cometido al aplicar el m etodo de cuarto orden se obtiene restando las funciones
83
paso de ambos m etodos, y corresponder a con el t ermino de 5 orden del desarrollo 5 5 t i de Taylor ( ddtx 5 5! ). La funci on de paso para la ecuaci on diferencial ordinaria dx = f (x, t) dt es la siguiente: (2.106)
k1 = t f (xi , ti ) k2 = t f k3 = t f k4 = t f k5 = t f k6 = t f k1 t , ti + 4 4 3 9 3 k1 + k2 , ti + t xi + 32 32 8 1932 7200 7296 12 xi + k1 k2 + k3 , ti + t 2197 2197 2197 13 439 3680 845 xi + k1 8 k2 + k3 k4 , ti + t 216 513 4104 8 3544 1859 xi k1 + 2 k2 k3 + k4 27 2565 4104 t 11 k5 , ti + 40 2 xi +
(2.107) (2.108) (2.109) (2.110) (2.111) (2.112) (2.113)
La f ormula de paso de 4 orden es: xi+1, 4 orden = xi + y la de 5 orden es: 25 1408 2197 k5 k1 + k3 + k4 216 2565 4104 5 (2.114)
xi+1, 5 orden = xi +
16 6656 28561 9 2 k1 + k3 + k4 k5 + k6 135 12825 56430 50 55
(2.115)
En cada paso de integraci on, se compara la soluci on obtenida aplicando el m etodo de 4 orden con la soluci on obtenida aplicando el m etodo de 5 orden. La nalidad es determinar si el tama no del paso que se est a usando, t, es el adecuado. Conceptualmente el procedimiento es el siguiente. Si ambas soluciones no se encuentran sucientemente pr oximas, se reduce el tama no del paso de integraci on. Si ambas
84
soluciones coinciden en m as d gitos signicativos de los necesarios, se aumenta el paso de integraci on.
2.4.
DE EVENTOS DISCRETOS MODELADO Y SIMULACION
En la Secci on 2.2 se discuti o c omo aplicar una estrategia de eventos discretos a la simulaci on de aut omatas celulares, constituyendo una forma m as eciente de realizar la simulaci on. En esta secci on se considerar a el modelado de eventos discretos como un paradigma en s mismo. En primer lugar, estudiaremos una formalizaci on del aut omata celular de eventos discretos. Finalmente, consideraremos el tipo de modelos m as habitualmente asociados con la simulaci on de eventos discretos.
2.4.1.
Aut omata celular de eventos discretos
La versi on original del Juego de la Vida asume que todos los nacimientos y las muertes tardan el mismo tiempo en producirse: un paso de tiempo. Otra posible representaci on del ciclo de vida de una c elula consiste en suponer que el nacimiento y la muerte dependen de una magnitud, denominada factor ambiental, que representa en qu e medida el entorno le resulta favorable u hostil a la c elula. El entorno resulta favorable para la c elula cuando tiene exactamente 3 c elulas vecinas. En este caso, el factor ambiental toma un valor positivo. Por el contrario, esta magnitud disminuye r apidamente cuando el entorno se torna hostil y cuando alcanza el valor 0, la c elula muere. En la Figura 2.12 se muestra un ejemplo de comportamiento del modelo de la c elula en funci on de su entorno, es decir, en funci on del n umero de c elulas vecinas que est an vivas. Tal como se muestra en la Figura 2.12, cuando el n umero de c elulas vecinas vivas cambia de 4 a 3, el factor ambiental comienza a crecer linealmente y en el instante en que el factor ambiental cruza el cero, la c elula nace. El factor ambiental sigue creciendo hasta que alcanza un valor de saturaci on, que en este ejemplo se ha considerado que es 6. Por el contrario, cuando el n umero de c elulas vecinas vivas cambia de 3 a 4, el entorno se vuelve hostil, con lo cual el factor ambiental comienza a decrecer linealmente y cuando alcanza el valor 0, se produce la muerte de la c elula y el factor ambiental pasa de manera discontinua a valer 2, que es el menor valor posible del factor ambiental.
85

Figura 2.12: Comportamiento del Juego de la Vida considerando el factor ambiental.
Hay varias formas de modelar el comportamiento de la c elula. Una ser a calcular la trayectoria del factor ambiental y detectar cu ando se produce el cruce por cero, es decir, el nacimiento y la muerte. Este procedimiento ser a una combinaci on de simulaci on de tiempo continuo y tiempo discreto. Es decir, se trata de un modelo h brido. Sin embargo, este procedimiento es computacionalmente poco eciente, ya que hay que calcular el valor del factor ambiental en cada punto de su trayectoria. Un procedimiento mucho m as eciente es realizar un modelo orientado a los eventos, en el cual nos concentramos u nicamente en los eventos de inter es: los nacimientos y las muertes, as como los cambios en el n umero de c elulas vecinas vivas. Un modelo de eventos discretos salta de un evento al siguiente, omitiendo describir el comportamiento sin inter es que se produce entremedias. El requisito para poder realizar un modelo de eventos discretos es tener la capacidad de predecir cu ando se producen los eventos de inter es. Los eventos pueden clasicarse en externos e internos. Eventos externos. Son los eventos generados por el entorno. Por ejemplo, cuando el n umero de c elulas vecinas cambia. El suceso de este tipo de eventos no est a bajo el control del componente modelado (en este caso, de la c elula). Eventos internos. Por otra parte, el componente debe planicar el suceso de cierto tipo de eventos. La ocurrencia de estos eventos, denominados internos,
86
es planicada por el propio componente. Dado un estado en concreto de la c elula, es decir, un valor particular de su factor ambiental, puede calcularse el tiempo que debe transcurrir hasta que ocurra el siguiente evento interno (nacimiento o muerte), supuesto que mientras tanto no haya sucedido ning un evento externo. Puesto que el valor del factor ambiental var a de forma lineal, los instantes de nacimiento y muerte pueden ser calculados de manera muy sencilla. Cuando transcurre el tiempo hasta el siguiente evento interno (v ease la Figura 2.13), se actualiza el valor del estado de la c elula, y se continua avanzando hasta el instante en que se produce el siguiente evento. En la simulaci on de eventos discretos del modelo del Juego de la Vida, deben ejecutarse los eventos internos de las diferentes c elulas en sus respectivos instantes de disparo. Cuando se cambia el estado de una c elula debido a un evento interno, hay que examinar las c elulas vecinas para ver si se produce alg un cambio de estado. Un cambio en el estado puede producir la programaci on de nuevos eventos y la cancelaci on de eventos que estaban programados. En la Figura 2.14 se ilustra este proceso. Supongamos que todas las c elulas que aparecen sombreadas en la Figura 2.14a est an vivas. La c elula que est a en la casilla (0,0) tiene tres vecinas vivas, as que puede nacer. Por el contrario, la c elula situada en la casilla (1,1) tiene s olo una vecina viva, con lo cual morir a. Por tanto, se programa el nacimiento y la muerte de estas dos c elulas en los instantes t1 y t2 , respectivamente. Obs ervese que en la Figura 2.14a se ha se nalado en cada c elula el instante en que est a programado el suceso de su siguiente evento interno. En el instante t1 , la c elula situada en (0,0) nace. Se ha se nalado esta c elula con una estrella en la Figura 2.14b. Como resultado de ello, las c elulas situadas en (0,1), (0,1) y (1,1) pasan a tener 3 vecinas vivas, con lo cual se programa el evento futuro de su nacimiento, que se producir a en el instante t3 . La c elula (1,1) tiene 4 c elulas vecinas vivas, con lo cual se programa su muerte para el instante t3 . La c elula (1,1) ten a un evento planicado para el instante t2 : su muerte. Sin embargo, debido al nacimiento de la c elula (0,0), ahora tiene dos c elulas vecinas vivas, con lo cual ya no se re unen la condiciones para que muera: se cancela el evento planicado para t2 . Como vemos, el efecto de las transiciones de estado no s olo es planicar eventos futuros, sino tambi en puede ser cancelar eventos ya planicados. A continuaci on, el reloj de la simulaci on salta hasta el siguiente evento planicado, que sucede en t3 . El hecho de saltar de un evento al siguiente, sin considerar el intervalo de tiempo entre ambos, es una ventaja de la simulaci on de eventos discretos
87

Figura 2.13: Comportamiento del Juego de la Vida considerando el factor ambiental y empleando simulaci on de eventos discretos.
) * + (* () ,-
) * + (* ()
,/ ,/ ,/ ,/ () (* + * ) $ !" %
) ,0 * + (* ()
,/ ,/
,.
() (* + * ) !" #
() (* + * ) & !" '
Figura 2.14: Ejemplo de procesamiento de los eventos en el Juego de la Vida.
88
en lo relativo a su eciencia computacional. Este mecanismo contrasta con el de la simulaci on de tiempo discreto, en el cual las c elulas se inspeccionan en cada paso de tiempo. La situaci on en t3 ilustra un problema que acontece en la simulaci on de eventos discretos: los eventos simult aneos. En la Figura 2.14b vemos que hay varios eventos planicados para el instante t3 : el nacimiento de (0,1), (0,1) y (1,1), y la muerte de (1,1). la cuesti on es qu e evento se ejecuta primero y cu al es el resultado. Si en primer lugar (1,1) muere, entonces deja de satisfacerse la condici on de que (0,1) tiene tres c elulas vecinas vivas, con lo cual se cancelar a el evento del nacimiento de (0,1). V ease la Figura 2.14c. Se ha se nalado con una estrella la c elula (1,1), que muere, y se ha cancelado el evento en el instante t3 asociado a (0,1). Sin embargo, si en primer lugar se dispara el evento interno de (0,1), entonces efectivamente se produce el nacimiento de (0,1). En consecuencia, el resultado es diferente dependiendo del orden de activaci on de los eventos. Hay varias posibles soluciones al problema de los eventos simult aneos. Una de ellas es realizar simult aneamente todas las transiciones asociadas a los eventos simult aneos. Como veremos, este es el procedimiento empleado en el formalismo DEVS paralelo. El m etodo empleado por la mayor a de los paquetes de simulaci on y por el formalismo DEVS cl asico es denir una prioridad entre los componentes, de tal modo que se dispara el evento del componente con mayor prioridad. A continuaci on, se describe el m etodo m as com unmente empleado para la simulaci on de los modelos de eventos discretos: la planicaci on de eventos. Este m etodo puede emplearse para simular el Juego de la Vida.
2.4.2.
Simulaci on de eventos discretos
En los modelos de eventos discretos, los cambios en el estado del sistema f sico se representan mediante una serie de cambios discretos o eventos en instantes espec cos de tiempo. Dado que las variables y atributos permanecen constantes entre eventos consecutivos, los cambios en las variables necesarios para activar un evento en el estado s olo pueden producirse como resultado de la ejecuci on de un evento en el tiempo. Entre eventos, las variables de estado del sistema permanecen constantes.
89
La planicaci on de los eventos en el tiempo es muy sencilla, ya que se sabe con antelaci on en qu e instantes se van a producir. Durante el curso de la simulaci on se lleva un registro de los instantes de activaci on de los eventos en el tiempo. Este se denomina el calendario de eventos. En el instante de inicio de la simulaci on, se activa el evento Inicio de la Simulaci on. Como parte de las acciones asociadas a la ejecuci on de este evento, se pone el reloj de la simulaci on a cero y se planican determinados eventos para su ejecuci on en instantes futuros. Estos eventos en el tiempo son registrados en el calendario de eventos, ordenados de menor a mayor instante de ejecuci on. Una vez ejecutado este primer evento, el reloj de la simulaci on es avanzado hasta el instante de ejecuci on del primer evento del calendario, el cual es entonces borrado del calendario. Se ejecuta el evento, actualiz andose, si procede, el calendario de eventos. A continuaci on, el reloj de la simulaci on salta hasta el instante de ejecuci on del evento m as pr oximo (el primero del calendario), este es borrado del calendario, es ejecutado y, si procede, se actualiza el calendario. Se procede de esta manera hasta que se activa el evento Finalizaci on de la Simulaci on. Una vez este es ejecutado, naliza la simulaci on. En funci on de su condici on de activaci on, los eventos pueden clasicarse en eventos en el tiempo y eventos en el estado: Los eventos en el tiempo son aquellos cuya condici on de activaci on es que el reloj de la simulaci on (es decir, el tiempo simulado) alcance un determinado valor. La condici on de activaci on de los eventos en el estado no es funci on exclusiva del tiempo, sino que tambi en es funci on de variables del sistema. Los modelos orientados a los eventos u nicamente contienen eventos en el tiempo, es decir, la condici on de disparo de los eventos es que el reloj de la simulaci on alcance determinado valor. No se contempla la posibilidad de que los eventos puedan dispararse como resultado de inspeccionar el estado del modelo y comprobar que se satisfacen determinadas condiciones de disparo. Es decir, en los modelos de eventos discretos no hay eventos en el estado. Planicar un evento, es decir, determinar con antelaci on el instante de tiempo en el cual debe dispararse, es sencillo cuando pueden conocerse con antelaci on todas las condiciones para su disparo. Sin embargo, este no es siempre el caso. Ejemplo 2.4.1. Va a emplearse un modelo sencillo para ilustrar la pr actica de la simulaci on orientada a los eventos: el modelo de una ocina de atenci on al p ublico
90
atendida por un u nico empleado. La estructura l ogica del modelo es la siguiente (v ease la Figura 2.15): Si llega un nuevo cliente y el empleado est a ocupado, el cliente se pone al nal de una cola FIFO en espera de su turno. Si el empleado est a libre, el cliente es atendido inmediatamente. Si el empleado termina de atender a un cliente, este se marcha y comienza a ser atendido el primer cliente de la cola. Si la cola est a vac a, el empleado permanece desocupado hasta la llegada de un nuevo cliente. El intervalo de tiempo entre llegadas de clientes y el tiempo de servicio son variables aleatorias, con probabilidad distribuida exponencialmente, expo(10 minutos), y uniformemente, U(5 minutos, 10 minutos), respectivamente. En la Figura 2.16 se muestra un ejemplo del comportamiento del modelo. El objetivo de la simulaci on es estimar el tiempo medio de espera en cola y el n umero medio de clientes que esperan en la cola. El tiempo medio de espera del cliente en la cola, se dene de la forma siguiente:
n
Di (2.116) n donde n es el n umero total del clientes que han abandonado la cola y Di es el tiempo de espera en la cola del cliente i. Para calcularlo es preciso llevar registro, a lo largo de la simulaci on, del n umero de clientes que han abandonado la cola hasta ese momento (n) y de la suma del tiempo de espera de los clientes que han abandonado la cola hasta ese momento:
n
(n) = d
i:1
D (n) =
i:1
Di
(2.117)
El n umero medio de clientes que componen la cola se dene de la forma siguiente:

T 0
q (T ) =
Q ( ) d T
(2.118)
donde T es el tiempo que dura la simulaci on y Q ( ) es el n umero de clientes que hay en la cola en el instante .
91
EVENTO: FIN DE SERVICIO EVENTO: LLEGADA DE UN NUEVO CLIENTE EL CLIENTE SE MARCHA No EMPLEADO LIBRE Si No COLA VACIA Si
EL CLIENTE SE PONE A LA COLA
EL CLIENTE COMIENZA A SER ATENDIDO
EL PRIMER CLIENTE DE LA COLA COMIENZA A SER ATENDIDO
EL EMPLEADO QUEDA LIBRE
Figura 2.15: Esquema de la estructura l ogica del modelo.

!" # *+,-./* 01234 !$ % %# ) ( ' &
Figura 2.16: Ejemplo del comportamiento del modelo de la ocina.
92
Para calcularlo, es preciso llevar registro a lo largo de la simulaci on del valor t de la integral: 0 Q ( ) d . Para ello se dene un acumulador estad stico, R (t). Inicialmente R vale cero. Cada vez que cambia el n umero de clientes de la cola, debe actualizarse el valor de R: se suma al valor actual de R el producto del n umero de clientes de la cola (antes del cambio) por el tiempo transcurrido desde el anterior cambio. De este modo va calcul andose el area bajo la curva Q (t). Para ello, es preciso denir otro acumulador estad stico, tevento , que almacene el instante en que se produjo el anterior evento. Obs ervese que hay dos tipos de eventos que pueden modicar el tama no de la cola: la llegada de un cliente y el nal del servicio a un cliente (el primero de la cola comienza entonces a ser atendido). Si la condici on de nalizaci on no coincide con uno de estos dos tipos de eventos, al t ermino de la simulaci on debe tambi en actualizarse R. En este modelo hay cuatro tipos de eventos: inicio de la simulaci on, llegada a la ocina de un nuevo cliente, n de servicio a un cliente y nal de la simulaci on. Los ujos de acciones asociados a los tres primeros tipos se muestran en la Figura 2.17.
2.4.3.
Elementos del modelo
Aparte de los eventos, un modelo de eventos discretos tiene otros tipos de componentes. En general, cabe distinguir siete tipos de componentes en un modelo de eventos discretos: los componentes del sistema (entidades, recursos y colas), las variables que los describen (atributos, variables y contadores estad sticos) y la interacci on entre ellos (eventos). A continuaci on, se describe cada uno de ellos. 1. Entidades. Las entidades son objetos din amicos en la simulaci on, que son creados y se mueven por el sistema, cambiando el valor de sus atributos, afectados por otras entidades y por el estado del sistema. Las entidades pueden abandonar el sistema o bien permanecer indenidamente circulando en el. En el ejemplo anterior de la ocina, existe un u nico tipo de entidad: cliente. Cada cliente que se encuentra en la ocina es una realizaci on (o instanciaci on, como se preera) de este tipo de entidad, que es creada a su llegada, circula a trav es del sistema y es destruida cuando el cliente abandona la ocina. Si en el modelo se hubieran denido diferentes tipos de clientes, que requirieran
93
LLEGADA CLIENTE i INICIO
D=0 R=0 n=0

reloj = 0 Leer Q Leer E
Inicializacin de los contadores estadsticos Inicializacin del reloj de la simulacin Asignar valor al estado inicial del sistema Generacin del intervalo entre llegadas Inicializacin de la lista de eventos
Instante de llegada del cliente i+1
Generar A i+ i 1
llegada = reloj + Ai +1
E =1
Generacin del intervalo entre llegadas Actualizacin de la lista de eventos
E Actualizacin del rea bajo Q(t) R = R + Q (reloj t evento ) Instante de llegada t = reloj i del cliente i Incremento del Q = Q +1 tamao de la cola
E = 0 (libre) E =1
Empleado pasa a estar ocupado

Incremento del nmero de a ser atendidos
t evento = 0 Generar A1
n = n + 1 clientes que han comenzado Generar S i marcha = reloj + S i Generacin del tiempo de servicio Actualizacin de la lista de eventos
llegada = A1 marcha = NO _ DEFINIDO

RETURN
t evento = reloj Actualizacin del instante en que se produjo el ltimo evento

RETURN
MARCHA CLIENTE i
se atiende al Q>0 cliente i+1 Incremento del nmero de clientes que han comenzado a ser atendidos Actualizacin del tiempo total de espera en cola Actualizacin del rea bajo Q(t) Decremento del nmero de clientes en la cola Generacin del tiempo de servicio Actualizacin de la lista de eventos. Instante en que se marcha el cliente i+1
n = n +1
D = D + relo j t i +1
Q = 0 (co la vaca)
E =0
El empleado queda libre Actualizacin de la lista de eventos
m a rch a = N O _ D E F IN ID O
R = R + Q (reloj t evento )
Q = Q 1
Generar S i +1 marcha = reloj + S i+1

t even to = relo j
Actualizacin del instante en que se ha producido el ltimo evento
RETURN
Figura 2.17: Flujos de acciones asociadas a los eventos.
94
procesos de atenci on diferentes o a los que se asignara diferente prioridad, cada tipo de cliente podr a representarse como un tipo diferente de entidad. 2. Atributos. Los atributos permiten individualizar cada instanciaci on de una determinada clase de entidad. Al denir el tipo de entidad, se declaran sus atributos. Se pueden asignar valores diferentes a los atributos de cada instanciaci on de la clase de entidad, lo cual permite especicar las caracter sticas particulares de cada uno de ellos. Por ejemplo, algunos atributos que podr an denirse para el tipo de entidad cliente son: la prioridad con que debe ser atendido o determinados datos personales, como son el nombre y los apellidos, la edad, la nacionalidad, etc. En general, el valor de los atributos diferir a de un cliente a otro y es lo que permite diferenciarlos. 3. Variables. Las variables representan caracter sticas del sistema que son independientes de los tipos de entidades o del n umero de realizaciones existentes en determinado instante. Por tanto, las variables no est an asociadas a entidades en concreto, sino que pertenecen al conjunto del sistema. Son accesibles desde todas las entidades y pueden ser modicadas por todas las entidades. Puede considerarse que cada variable es como una pizarra colgada en la pared, en la que se escribe el valor de la variable. Todas las entidades pueden leer la pizarra, y tambi en pueden borrar el valor escrito y escribir uno nuevo. Algunas de las variables son intr nsecas a los elementos del modelo y, por ello surgen en casi todos los modelos de simulaci on. Algunas de estas son: el n umero de entidades (en nuestro caso, clientes) que hay en cada instante en cada cola, el n umero de recursos (en nuestro caso, empleados) ocupados, el estado (ocupado o libre) de cada recurso, el valor del reloj de la simulaci on (variable que va registrando el tiempo simulado) , etc. Por el contrario, otras variables surgen debido a necesidades concretas del modelo en cuesti on. Por ejemplo, sup ongase que cada cliente tiene que ser atendido consecutivamente por dos empleados diferentes, situados a cierta distancia, y que el tiempo que emplea la entidad en ir de un empleado a otro se considera jo. Entonces, el valor de este tiempo de tr ansito ser a una variable del modelo. Las variables permiten parametrizar el modelo, es decir, denir magnitudes que pueden cambiar para adaptar el modelo a sus diferentes aplicaciones. Por ejemplo, mediante la modicaci on del tiempo de tr ansito entre los dos puntos de atenci on, puede adaptarse un mismo modelo para representar diferentes sistemas.
95
Asimismo, las variables pueden representar magnitudes cuyo valor cambie durante el curso de la simulaci on. Por ejemplo: el n umero total de clientes que esperan, que est an siendo atendidos y que se encuentran en tr ansito entre los dos puntos de atenci on. 4. Recursos. Los recursos pueden ser el personal (en nuestro caso, el empleado), las m aquinas (por ejemplo, si las entidades son piezas que deben ser procesadas), el espacio (por ejemplo, en un almac en), etc. Una entidad captura un recurso cuando este est a disponible, a n de obtener un servicio de el, y lo libera una vez ha terminado. El recurso puede ser individual o estar compuesto por un grupo de elementos individuales, cada uno de los cuales se llama una unidad del recurso . Por ejemplo, el caso de varios mostradores paralelos e id enticos de atenci on al p ublico, puede representarse como un recurso con tantas unidades como puntos de atenci on. El n umero de unidades disponibles de un recurso puede variar durante el curso de la simulaci on, representando mostradores que son cerrados o abiertos. 5. Colas. Cuando una entidad no puede circular, debido tal vez a que necesita usar una unidad de un recurso que en ese momento no se encuentra disponible, entonces la entidad necesita un sitio donde esperar: este es el prop osito de la cola. 6. Acumuladores estad sticos. A n de calcular el valor de las variables de salida, es preciso calcular durante el curso de la simulaci on el valor de determinadas variables intermedias. Estas se llaman acumuladores estad sticos. Algunos ejemplos son: el n umero total de clientes atendidos hasta ese momento, la suma de los tiempos de espera en cola de los clientes hasta ese momento, el n umero total de clientes que han comenzado a ser atendidos hasta ese momento, el mayor tiempo de espera en cola hasta ese momento, etc. Los contadores son inicializados a cero al comenzar la simulaci on. Cuando algo sucede en la simulaci on (es decir, se ejecuta un evento), los contadores estad sticos afectados deben ser convenientemente actualizados. 7. Eventos. Un evento es un suceso que ocurre en un determinado instante de tiempo simulado y, como resultado de la ejecuci on de sus acciones asociadas, puede cambiar el valor de los atributos, las variables y los acumuladores estad sticos. De hecho, los atributos, las variables y los acumuladores estad sticos s olo pueden cambiar a consecuencia de la ejecuci on de los eventos. Los cambios en sus valores se producen en los instantes en que son activados
96
los eventos, manteni endose constantes durante el intervalo de tiempo entre eventos sucesivos. Cada evento tiene asociado dos tipos de informaci on. Por una parte, su condici on de activaci on, tambi en llamada condici on de disparo. Es decir, la condici on que hace que el evento pase de estar desactivado a estar activado. Por otra, las acciones que deben realizarse en el instante en que el evento es activado.
2.4.4.
Descripci on del funcionamiento del sistema
Llegado este punto, se han descrito los componentes del sistema (entidades, recursos y colas), las variables que los describen (atributos, variables y contadores estad sticos) y la interacci on entre ellos (eventos). No obstante, todav a falta describir en el modelo los detalles acerca del funcionamiento del sistema. B asicamente, puede realizarse desde dos opticas distintas: la orientaci on a los eventos y la orientaci on a los procesos. A continuaci on, se describe las caracter sticas fundamentales de cada una de ellas, usando para ello el modelo de la ocina de atenci on al cliente.
Modelado orientado a los eventos Como su nombre indica, el modelado orientado a los eventos se centra en la descripci on de los eventos. Es decir, en describir: Qu e tipos de eventos se producen. Qu e condici on de activaci on tiene cada uno. Cu al es el ujo l ogico de acciones asociadas a la activaci on de cada evento. Anteriormente se describi o el modelado orientado a los eventos de la ocina de atenci on al cliente. En la Figura 2.17 se mostraron los ujos de acciones correspondientes a los eventos inicializaci on, llegada de un nuevo cliente y marcha de un cliente. El modelado orientado a los eventos presenta dos ventajas fundamentales. La primera es que permite una exibilidad total en la descripci on del modelo. La segunda es que la realizaci on, empleando un lenguaje de programaci on, del c odigo
97
de la simulaci on a partir de este tipo de descripci on del modelo es conceptualmente sencilla. Sin embargo, la orientaci on a los eventos presenta tambi en una desventaja importante: la realizaci on de modelos de grandes dimensiones, con diferentes tipos de eventos, entidades y recursos, resulta excesivamente compleja, ya que este enfoque requiere que el programador adquiera el papel de supervisor omnisapiente, llevando el control de todos los eventos, entidades, atributos, variables y acumuladores estad sticos.
Modelado orientado a los procesos Una forma alternativa, m as natural y sencilla, de describir el modelo consiste en tomar el punto de vista de las entidades y describir su circulaci on a trav es del sistema. Este enfoque se centra en los procesos que llevan a cabo las entidades, por ello se llama modelado orientado a los procesos. Su pr actica es posible gracias al empleo de lenguajes de simulaci on, que traducen de manera autom atica la descripci on orientada a los procesos a una descripci on orientada a los eventos, y esta en c odigo escrito en alg un lenguaje de programaci on. En u ltima instancia, el c odigo ejecutable de la simulaci on siempre est a orientado a los eventos. El modelo orientado a los procesos de la ocina de atenci on al p ublico se realiza tomando el punto de vista de un cliente cualquiera. Como en el caso anterior, las variables de salida son el tiempo medio de espera en la cola y el n umero medio de clientes que componen la cola. Los pasos en el proceso de atenci on son: 1. Llego a la ocina. 2. Escribo en mi atributo Instante de llegada el valor que tiene en este momento el reloj de la simulaci on. As m as tarde podr e calcular el tiempo que he estado esperando en la cola. 3. Me pongo al nal de la cola e incremento en uno el valor de la variable N umero de clientes de la cola. 4. Espero hasta que yo sea el primero de la cola y el empleado est e libre (si tengo suerte, el tiempo de espera ser a cero). 5. En el instante en que abandono la cola, calculo mi tiempo de espera (restando el valor de mi atributo Instante de llegada del valor del reloj de la simulaci on), decremento en uno el valor de la variable N umero de clientes de la cola,
98
incremento en uno la variable N umero de clientes que abandonan la cola y comienzo a ser atendido por el empleado. 6. El empleado me atiende durante el tiempo que requiero. 7. Finaliza mi tiempo de servicio, con lo que dejo libre al empleado y abandono la ocina. Existen varios entornos de simulaci on que permiten realizar una descripci on orientada al proceso de los modelos. Uno de ellos es Arena (Kelton et al. 2002, Pedgen et al. 1995). Con el n de ilustrar c omo se realiza la descripci on del modelo en este tipo de entornos, en la Figura 2.18 se muestra el modelo en Arena de la ocina atendida por un empleado. En la Figura 2.18a se muestra el modelo en un instante de su simulaci on. Est a compuesto por tres m odulos: el m odulo de creaci on de las entidades, el m odulo que describe el proceso y el m odulo por el cual las entidades abandonan el sistema. La conexi on entre los m odulos dene el ujo de las entidades por el sistema. Los modelos pueden construirse de manera modular y jer arquica, empleando los diferentes bloques para la descripci on del ujo de entidades que proporciona Arena. Haciendo doble clic en cada uno de los m odulos se abre un men u de conguraci on. En las Figuras 2.18b y 2.18c se muestran los men us de conguraci on de los m odulos de creaci on de entidades y de proceso. Arena permite denir el experimento (condici on de nalizaci on de cada r eplica, n umero de r eplicas, etc.), calcula por defecto determinados estad sticos (tiempo de espera en las colas, tiempo de proceso, ocupaci on de los recursos, etc.), permite al usuario denir su propios c alculos, y genera autom aticamente informes en los que se muestra de manera textual y gr aca esta informaci on. El entorno de simulaci on de Arena se distribuye como parte de un conjunto de herramientas que cubren el ciclo t pico de un estudio mediante simulaci on. Una herramienta permite ajustar distribuciones de probabilidad a los datos experimentales, proporcionando informaci on sobre la bondad del ajuste. Otra herramienta permite denir juegos de experimentos (factores experimentales, niveles de cada factor, n umero de r eplicas en cada punto del dise no experimental, etc.) sobre un modelo denido en Arena, ejecuta el conjunto de simulaciones que componen el experimento y muestra el an alisis estad stico de los resultados. A la vista de las capacidades que ofrecen herramientas comerciales del tipo de Arena, cabe plantearse cu al es la ventaja de emplear el formalismo DEVS. La principal ventaja del formalismo DEVS es su total versatilidad, caracter stica que
99
Figura 2.18: Modelo en Arena de la ocina atendida por un empleado.
no comparten los m odulos predenidos, los cuales permiten describir u nicamente los comportamientos espec cos para los cu ales han sido ideados. Cuando una herramienta de simulaci on basadas en m odulos predenidos pretende soportar la descripci on de un amplio abanico de comportamientos, el n umero de m odulos que debe proporcionar la herramienta se hace muy grande, as como el n umero de variables y par ametros asociados, con lo cual su documentaci on se hace muy extensa (la relaci on de variables y atributos de Arena es un documento de aproximadamente 70 p aginas). En opini on del autor de este texto, las herramientas basadas en m odulos predenidos son de gran ayuda para la descripci on de modelos convencionales, pero
100
su empleo es complejo y tedioso cuando se pretenden modelar comportamientos fuera de los habituales, cosa que frecuentemente sucede cuando se describen modelos complejos. Es en estas situaciones en las cuales el esfuerzo invertido en el aprendizaje del formalismo DEVS se ve recompensado.
101
2.5.
Ejercicio 2.1 Ejecute manualmente el algoritmo que realiza la simulaci on del modelo representado por la tabla de transici on/salidas mostrada a continuaci on, para varias trayectorias de entrada y estado inicial. Explique por qu e este sistema se denomina contador binario. Estado actual 0 0 1 1 Entrada actual 0 1 0 1 Estado siguiente 0 1 1 0 Salida actual 0 0 0 1
Ejercicio 2.2 Escriba un simulador para un aut omata celular unidimensional, en el cual pueda congurarse el n umero de c elulas, el estado inicial y la funci on de transici on de estados. Codif quelo empleando un lenguaje de programaci on de su elecci on y ejec utelo para varios estados iniciales y varias funciones de transici on de estado.
Ejercicio 2.3 Reescriba el simulador que plante o al resolver el Ejercicio 2.2. En este caso, en lugar de inspeccionar todas las c elulas en cada paso de tiempo, emplee simulaci on basada en eventos, es decir, inspeccione en cada paso de tiempo s olo aquellas c elulas cuyo estado tiene posibilidad de cambiar. Compare ambas alternativas en t erminos de tiempo de ejecuci on.
Ejercicio 2.4 Lea los documentos lectura2a.pdf y lectura2b.pdf. A continuaci on, reproduzca el comportamiento de alguno de los aut omatas mostrados en estas lecturas.
102
Ejercicio 2.5 Plantee el algoritmo de la simulaci on del modelo que se describe a continuaci on de un dep osito, empleando para ello el m etodo num erico de integraci on de Euler expl cito. Llamando x al ujo (m3 /s) de entrada o salida de l quido del dep osito, e y al 3 volumen (m ) de l quido almacenado en el dep osito, y teniendo en cuenta que la variaci on respecto al tiempo del volumen de l quido acumulado dentro del dep osito es igual al ujo, podemos escribir el modelo del dep osito de la forma siguiente: y =x (2.119)
donde y representa la derivada de y respecto al tiempo, es decir, dy . En la Figura 2.19 dt se muestra la analog a entre el modelo del dep osito y un integrador.
Figura 2.19: Integrador: a) representaci on como bloque; y b) analog a con un dep osito: x es el ujo de entrada o salida (m3 /s), y es el volumen almacenado de l quido (m3 ). La relaci on constitutiva del dep osito es y = x.
Ejercicio 2.6 Plantee un modelo matem atico de tiempo continuo de un sistema de su elecci on. Clasique las variables del modelo en par ametros, variables de estado y variables algebraicas. Asigne la causalidad computacional del modelo. Plantee el diagrama de ujo del algoritmo para su simulaci on.
Ejercicio 2.7 En la Figura 2.20 se muestra el esquema de una casa que dispone de un sistema de calefacci on, que introduce un ujo de energ a in (W). Asimismo, hay un ujo
103
Figura 2.20: Esquema de una casa, con sistema de calefacci on y disipaci on de calor al exterior.
de energ a que sale de la casa, out (W), debido a la diferencia entre la temperatura en el interior de la casa T (K) y la temperatura en el exterior Text (K). La evoluci on de la temperatura en el interior de la casa puede calcularse aplicando tres leyes b asicas. 1. Balance de energ a. La diferencia entre los ujos de energ a in y out incrementa la energ a almacenada en la casa, Q (J). dQ = in out dt (2.120)
2. La relaci on entre Q y la temperatura T depende de la capacidad calor ca de la casa C (J/K). Q=C T (2.121)
3. El ujo de energ a que sale al exterior a trav es de las paredes y ventanas depende de la diferencia entre la temperatura interior de la casa y la temperatura del exterior. out = k (T Text ) (2.122)
donde la constante de proporcionalidad, k (W/K), es la conductividad t ermica de las paredes y ventanas. Suponiendo que la temperatura exterior, Text (K), y el ujo de energ a proporcionado por la calefacci on, in (W), son funciones conocidas del tiempo, y tambi en que C (J/K) y k (W/K) son par ametros conocidos, realice la asignaci on de causalidad computacional de las ecuaciones del modelo.
104
Asigne un valor arbitrario a la evoluci on temporal de Text y in , y a los par ametros C y k . A continuaci on, escriba el algoritmo de la simulaci on de este modelo. El objetivo de la simulaci on es calcular la evoluci on temporal del ujo de energ a de salida (out ), de la energ a acumulada en la casa (Q) y la temperatura en el interior de la casa (T ). Finalmente, codique el algoritmo anterior empleando un lenguaje de programaci on de su elecci on y ejec utelo. Ponga como condici on de nalizaci on que el tiempo simulado alcance 24 horas. Represente las dos gr acas siguientes. En la primera gr aca, represente in , out y Q frente al tiempo. En la segunda gr aca, represente Text y T frente al tiempo.
105
2.6.
Soluci on al Ejercicio 2.1 Consideremos la trayectoria de entrada siguiente:

x(0)=0 x(1)=1 x(2)=0 x(3)=1 x(4)=1 x(5)=0 x(6)=0 x(7)=1 x(8)=0 x(9)=1
Para esta trayectoria, con un estado inicial q(0)=0, se obtiene las trayectorias de los estados y de salida siguientes:
q(0)=0 x(0)=0 q(1)=0 y(0)=0 q(1)=0 x(1)=1 q(2)=1 y(1)=0 q(2)=1 x(2)=0 q(3)=1 y(2)=0 q(3)=1 x(3)=1 q(4)=0 y(3)=1 q(4)=0 x(4)=1 q(5)=1 y(4)=0 q(5)=1 x(5)=0 q(6)=1 y(5)=0 q(6)=1 x(6)=0 q(7)=1 y(6)=0 q(7)=1 x(7)=1 q(8)=0 y(7)=1 q(8)=0 x(8)=0 q(9)=0 y(8)=0 q(9)=0 x(9)=1 q(10)=1 y(9)=0
Para la misma trayectoria de entrada, pero con estado inicial q(0)=1, se obtiene:
q(0)=1 x(0)=0 q(1)=1 y(0)=0 q(1)=1 x(1)=1 q(2)=0 y(1)=1 q(2)=0 x(2)=0 q(3)=0 y(2)=0 q(3)=0 x(3)=1 q(4)=1 y(3)=0 q(4)=1 x(4)=1 q(5)=0 y(4)=1 q(5)=0 x(5)=0 q(6)=0 y(5)=0 q(6)=0 x(6)=0 q(7)=0 y(6)=0 q(7)=0 x(7)=1 q(8)=1 y(7)=0 q(8)=1 x(8)=0 q(9)=1 y(8)=0 q(9)=1 x(9)=1 q(10)=0 y(9)=1
El estado del sistema almacena el bit menos signicativo de la suma binaria de los valores de entrada. La salida es el acarreo.
Soluci on al Ejercicio 2.2 A continuaci on se muestra una forma de programar el aut omata en Java.
public class AutomataCelular { public static void main(String[] args) { // -------------// ESTADO INICIAL // -------------int estadoActual[] = {0,0,0,1,1,1,0,0,0,1,1,1,0,0,0}; // -----------------------------// TABLA DE TRANSICION DE ESTADOS // -----------------------------int tabla[] = new int[8]; // Estado Entrada Entrada Estado // actual izqda drcha siguiente /* 0 0 0 */ tabla[0]=0;
106
/* 0 0 1 */ tabla[1]=1; /* 0 1 0 */ tabla[2]=0; /* 0 1 1 */ tabla[3]=1; /* 1 0 0 */ tabla[4]=0; /* 1 0 1 */ tabla[5]=1; /* 1 1 0 */ tabla[6]=0; /* 1 1 1 */ tabla[7]=1; // --------------// NUMERO REPLICAS // --------------int numReplicas = 10; // ---------------// Genera resultado // ---------------int numCeldas = estadoActual.length; for (int t = 0; t < numReplicas; t++) { System.out.print("t="+ t + "\t"); for(int i=0; i<numCeldas; i++) System.out.print(Integer.toString(estadoActual[i])); System.out.println(); int[] estadoAnterior = (int[])estadoActual.clone(); for (int i = 1; i < numCeldas - 1; i++) estadoActual[i] = tabla[4*estadoAnterior[i]+2*estadoAnterior[i-1]+estadoAnterior[i+1]]; } } }
Por simplicidad, la conguraci on del aut omata se realiza en el propio programa. Otra posible opci on ser a que el programa solicitara la entrada de datos por teclado o bien que leyera los datos de un chero. La conguraci on del aut omata consiste en especicar el estado inicial y la tabla de transici on de estados. Del estado inicial se obtiene el n umero de c elulas. Asimismo, debe indicarse el n umero de r eplicas de que constar a la simulaci on. A continuaci on, se muestran algunos ejemplos de ejecuci on del programa.
Ejemplo 1
// -------------// ESTADO INICIAL // -------------int estadoActual[] = {0,0,0,0,0,1,0,0,0,0,0}; // -----------------------------// TABLA DE TRANSICION DE ESTADOS // -----------------------------int tabla[] = new int[8]; // Estado Entrada Entrada Estado // actual izqda drcha siguiente /* 0 0 0 */ tabla[0]=0; /* 0 0 1 */ tabla[1]=1; /* 0 1 0 */ tabla[2]=1; /* 0 1 1 */ tabla[3]=1;
107
/* /* /* /*
1 1 1 1
0 0 1 1
0 1 0 1
*/ */ */ */
tabla[4]=0; tabla[5]=0; tabla[6]=0; tabla[7]=0;
Resultado de la ejecuci on:

t=0 t=1 t=2 t=3 t=4 t=5 t=6 t=7 t=8 t=9 00000100000 00001010000 00010101000 00101010100 01010101010 00101010100 01010101010 00101010100 01010101010 00101010100
Ejemplo 2
// -------------// ESTADO INICIAL // -------------int estadoActual[] = {0,0,0,1,1,1,0,0,0,1,1,1,0,0,0}; // -----------------------------// TABLA DE TRANSICION DE ESTADOS // -----------------------------int tabla[] = new int[8]; // Estado Entrada Entrada Estado // actual izqda drcha siguiente /* 0 0 0 */ tabla[0]=1; /* 0 0 1 */ tabla[1]=0; /* 0 1 0 */ tabla[2]=0; /* 0 1 1 */ tabla[3]=1; /* 1 0 0 */ tabla[4]=0; /* 1 0 1 */ tabla[5]=1; /* 1 1 0 */ tabla[6]=1; /* 1 1 1 */ tabla[7]=0;

t=0 t=1 t=2 t=3 t=4 t=5 t=6 t=7 t=8 t=9 000111000111000 010101010101010 001010101010100 000101010101000 010010101010010 000001010100000 011100101001110 010100010001010 001001000100100 000000010000000
108
Ejemplo 3

t=0 t=1 t=2 t=3 t=4 t=5 t=6 t=7 t=8 t=9 000111000111000 001110001110000 011100011100000 011000111000000 010001110000000 000011100000000 000111000000000 001110000000000 011100000000000 011000000000000
Soluci on al Ejercicio 2.3 A continuaci on se muestra una posible forma de programar el aut omata en Java.
public class AutomataCelular2 { public static void main(String[] args) { // -------------// ESTADO INICIAL // -------------int estadoActual[] = {0,0,0,0,0,1,0,0,0,0,0}; // -----------------------------// TABLA DE TRANSICION DE ESTADOS // -----------------------------int tabla[] = new int[8]; // Estado Entrada Entrada Estado // actual izqda drcha siguiente
109
/* 0 0 0 */ tabla[0]=0; /* 0 0 1 */ tabla[1]=1; /* 0 1 0 */ tabla[2]=1; /* 0 1 1 */ tabla[3]=1; /* 1 0 0 */ tabla[4]=0; /* 1 0 1 */ tabla[5]=0; /* 1 1 0 */ tabla[6]=0; /* 1 1 1 */ tabla[7]=0; //----------------------------------------------------// --------------// NUMERO REPLICAS // --------------int numReplicas = 10; // ---------------// Genera resultado // ---------------int numCeldas = estadoActual.length; HashSet hSetSiguiente = new HashSet(); for (int i=1; i<numCeldas - 1; i++) hSetSiguiente.add(new Integer(i)); for (int t = 0; t < numReplicas; t++) { System.out.print("t="+ t + "\t"); for(int i=0; i<numCeldas; i++) System.out.print(Integer.toString(estadoActual[i])); System.out.println("\tCeldas examinadas: " + hSetSiguiente.size()); int[] estadoAnterior = (int[])estadoActual.clone(); HashSet hSet = hSetSiguiente; Iterator itr = hSet.iterator(); hSetSiguiente = new HashSet(); while (itr.hasNext()) { int i = ((Integer)itr.next()).intValue(); estadoActual[i] = tabla[4*estadoAnterior[i]+2*estadoAnterior[i-1]+estadoAnterior[i+1]]; if (estadoActual[i]!=estadoAnterior[i]) { if (i-1>0) hSetSiguiente.add(new Integer(i-1)); hSetSiguiente.add(new Integer(i)); if (i+1<numCeldas-1) hSetSiguiente.add(new Integer(i+1)); } } } } }
Ejemplo 1
// -------------// ESTADO INICIAL // -------------int estadoActual[] = {0,0,0,0,0,1,0,0,0,0,0}; // -----------------------------// TABLA DE TRANSICION DE ESTADOS
110
// -----------------------------int tabla[] = new int[8]; // Estado Entrada Entrada // actual izqda drcha /* 0 0 0 */ /* 0 0 1 */ /* 0 1 0 */ /* 0 1 1 */ /* 1 0 0 */ /* 1 0 1 */ /* 1 1 0 */ /* 1 1 1 */
Estado siguiente tabla[0]=0; tabla[1]=1; tabla[2]=1; tabla[3]=1; tabla[4]=0; tabla[5]=0; tabla[6]=0; tabla[7]=0;

t=0 t=1 t=2 t=3 t=4 t=5 t=6 t=7 t=8 t=9 00000100000 00001010000 00010101000 00101010100 01010101010 00101010100 01010101010 00101010100 01010101010 00101010100 Celdas Celdas Celdas Celdas Celdas Celdas Celdas Celdas Celdas Celdas examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: 9 5 7 9 9 9 9 9 9 9
Ejemplo 2

t=0 000111000111000 Celdas examinadas: 13 t=1 001110001110000 Celdas examinadas: 12 t=2 011100011100000 Celdas examinadas: 11
111
t=3 t=4 t=5 t=6 t=7 t=8 t=9
011000111000000 010001110000000 000011100000000 000111000000000 001110000000000 011100000000000 011000000000000
Celdas Celdas Celdas Celdas Celdas Celdas Celdas
examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: examinadas:
9 9 8 6 6 5 3
Soluci on al Ejercicio 2.4 Reproduzcamos el comportamiento de dos de los aut omatas descritos en la lectura2b.pdf. El primero de ellos corresponde con la Regla 250 (Repetition).
// -------------// ESTADO INICIAL // -------------int estadoActual[] = {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}; // -----------------------------// TABLA DE TRANSICION DE ESTADOS // -----------------------------int tabla[] = new int[8]; // Estado Entrada Entrada Estado // actual izqda drcha siguiente /* 0 0 0 */ tabla[0]=0; /* 0 0 1 */ tabla[1]=1; /* 0 1 0 */ tabla[2]=1; /* 0 1 1 */ tabla[3]=1; /* 1 0 0 */ tabla[4]=0; /* 1 0 1 */ tabla[5]=1; /* 1 1 0 */ tabla[6]=1; /* 1 1 1 */ tabla[7]=1;

t=0 t=1 t=2 t=3 t=4 t=5 t=6 t=7 t=8 t=9 t=10 t=11 t=12 t=13 t=14 t=15 ------------------------------X----------------------------------------------------------X-X--------------------------------------------------------X-X-X------------------------------------------------------X-X-X-X----------------------------------------------------X-X-X-X-X--------------------------------------------------X-X-X-X-X-X------------------------------------------------X-X-X-X-X-X-X----------------------------------------------X-X-X-X-X-X-X-X--------------------------------------------X-X-X-X-X-X-X-X-X------------------------------------------X-X-X-X-X-X-X-X-X-X----------------------------------------X-X-X-X-X-X-X-X-X-X-X--------------------------------------X-X-X-X-X-X-X-X-X-X-X-X------------------------------------X-X-X-X-X-X-X-X-X-X-X-X-X----------------------------------X-X-X-X-X-X-X-X-X-X-X-X-X-X--------------------------------X-X-X-X-X-X-X-X-X-X-X-X-X-X-X------------------------------X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X--------------Celdas Celdas Celdas Celdas Celdas Celdas Celdas Celdas Celdas Celdas Celdas Celdas Celdas Celdas Celdas Celdas examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: 59 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33
112
t=16 t=17 t=18 t=19 t=20 t=21 t=22 t=23 t=24 t=25 t=26 t=27 t=28 t=29
--------------X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X--------------------------X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X------------------------X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X----------------------X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X--------------------X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X------------------X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X----------------X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X--------------X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X------------X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X----------X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X--------X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X------X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X----X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X--X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-
Celdas Celdas Celdas Celdas Celdas Celdas Celdas Celdas Celdas Celdas Celdas Celdas Celdas Celdas
examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: examinadas:
35 37 39 41 43 45 47 49 51 53 55 57 59 59
A continuaci on, reproduzcamos el comportamiento del aut omata que sigue la Regla 90 (Nesting).
// -------------// ESTADO INICIAL // -------------int estadoActual[] = {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}; // -----------------------------// TABLA DE TRANSICION DE ESTADOS // -----------------------------int tabla[] = new int[8]; // Estado Entrada Entrada Estado // actual izqda drcha siguiente /* 0 0 0 */ tabla[0]=0; /* 0 0 1 */ tabla[1]=1; /* 0 1 0 */ tabla[2]=1; /* 0 1 1 */ tabla[3]=0; /* 1 0 0 */ tabla[4]=0; /* 1 0 1 */ tabla[5]=1; /* 1 1 0 */ tabla[6]=1; /* 1 1 1 */ tabla[7]=0;

t=0 t=1 t=2 t=3 t=4 t=5 t=6 t=7 t=8 t=9 t=10 t=11 ------------------------------X----------------------------------------------------------X-X--------------------------------------------------------X---X------------------------------------------------------X-X-X-X----------------------------------------------------X-------X--------------------------------------------------X-X-----X-X------------------------------------------------X---X---X---X----------------------------------------------X-X-X-X-X-X-X-X--------------------------------------------X---------------X------------------------------------------X-X-------------X-X----------------------------------------X---X-----------X---X--------------------------------------X-X-X-X---------X-X-X-X------------------Celdas Celdas Celdas Celdas Celdas Celdas Celdas Celdas Celdas Celdas Celdas Celdas examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: 59 5 7 9 11 10 14 17 19 10 14 18
113
t=12 t=13 t=14 t=15 t=16 t=17 t=18 t=19 t=20 t=21 t=22 t=23 t=24 t=25 t=26 t=27 t=28 t=29
------------------X-------X-------X-------X----------------------------------X-X-----X-X-----X-X-----X-X--------------------------------X---X---X---X---X---X---X---X------------------------------X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X----------------------------X-------------------------------X--------------------------X-X-----------------------------X-X------------------------X---X---------------------------X---X----------------------X-X-X-X-------------------------X-X-X-X--------------------X-------X-----------------------X-------X------------------X-X-----X-X---------------------X-X-----X-X----------------X---X---X---X-------------------X---X---X---X--------------X-X-X-X-X-X-X-X-----------------X-X-X-X-X-X-X-X------------X---------------X---------------X---------------X----------X-X-------------X-X-------------X-X-------------X-X--------X---X-----------X---X-----------X---X-----------X---X------X-X-X-X---------X-X-X-X---------X-X-X-X---------X-X-X-X----X-------X-------X-------X-------X-------X-------X-------X--X-X-----X-X-----X-X-----X-X-----X-X-----X-X-----X-X-----X-X-
Celdas Celdas Celdas Celdas Celdas Celdas Celdas Celdas Celdas Celdas Celdas Celdas Celdas Celdas Celdas Celdas Celdas Celdas
examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: examinadas: examinadas:
22 20 28 33 35 10 14 18 22 20 28 34 38 20 28 36 44 38
Soluci on al Ejercicio 2.5 La ecuaci on dy = x describe c omo var a el volumen de l quido almacenado dentro dt del dep osito (y ) en funci on del ujo de l quido (x). Para poder realizar la simulaci on del modelo, es necesario especicar c omo var a el ujo de l quido en funci on del tiempo, que de forma gen erica puede representarse x = f (t, y ). El modelo a simular ser a:
dy = x dt x = f (t, y )
(2.123) (2.124)
La variable y aparece derivada, siendo la variable de estado del modelo. La variable x es una variable algebraica. La funci on de paso del m etodo de Euler expl cito para la ecuaci on yi+1 = yi + xi t El algoritmo para simular este modelo podr a ser el siguiente: 1. Debe conocerse el valor inicial de la variable de estado (p. e., y0 = 10). Tambi en debe jarse el tama no del paso de integraci on (p. e., t = 0.001). Se ja el valor inicial del tiempo (p. e., t0 = 0). Se asigna valor al ndice: i = 0.
dy dt
= x es: (2.125)
114
2. C alculo del ujo (variable algebraica) en el instante ti : xi = f (yi, ti ) (2.126)
3. Se comprueba si se satisface la condici on de nalizaci on. Si se satisface, termina la simulaci on. Si no, se continua en el paso siguiente. 4. Se calcula el valor de la variable de estado en el instante ti+1 : yi+1 = yi + xi t 5. Avance de un paso en el tiempo e incremento del ndice i: ti+1 = ti + t i = i+1 6. Volver al paso 2. En la Figura 2.21 se muestra el algoritmo para la simulaci on del modelo.
Inicio
(2.127)
(2.128) (2.129)
t = 0.001
t = 0, i = 0
y = 10
x = f ( t , y )
t+ = t + t i = i +1
t 10
No S Fin
y + = y + x t
Figura 2.21: Algoritmo para la simulaci on del modelo del dep osito.
115
Soluci on al Ejercicio 2.6 Como ejemplo podemos escoger el modelo de Lotka-Volterra, que describe la interacci on entre depredadores y presas. El modelo tiene dos variables: densidad de presas (h) y densidad de depredadores (p).
dh = rhahp dt dp = bhpmp dt El signicado de los par ametros r , a, b y m es el siguiente: r a b m
(2.130) (2.131)
Velocidad intr nseca de incremento de la poblaci on de presas Coeciente de velocidad de la depredaci on Velocidad de reproducci on de los depredadores por cada presa comida Tasa de mortandad de los depredadores
El modelo posee dos variables de estado: h y p. Sustituyendo las derivadas de las variables de estado por variables mudas, se obtiene el siguiente modelo con la causalidad computacional se nalada:
[derh] = r h a h p [derp] = b h p m p
(2.132) (2.133)
En la Figura 2.22 se muestra el algoritmo para la simulaci on del modelo. Para ello, se han asignado valores a los par ametros, al tama no del paso de integraci on, se ha dado valores iniciales a las variables de estado y se ha jado la condici on de terminaci on.
Soluci on al Ejercicio 2.7 Deniendo (arbitrariamente) la forma en que Text y in var an con el tiempo, se obtiene que el modelo completo est a compuesto por las ecuaciones siguientes:
116
Inicio
t = 0.001
t = 0, i = 0 m = 3, b = 1.5, r = 4.5, a = 1.5

h = 20, p = 2

derh = r h a h p

derp = b h p m p
t + = t + t

i = i +1
t 10
Fin
No
h + = h + derh t

p + = p + derp t
Figura 2.22: Algoritmo para la simulaci on del modelo de Lotka-Volterra.
dQ = in out dt Q = C T out = k (T Text ) Text in 2t = 275 + 10 sin( ) 3600 24 = 1e3;
(2.134) (2.135) (2.136) (2.137) (2.138)
Para simular el modelo es preciso asignar valores a los par ametros y tambi en especicar el valor inicial de las variables de estado. Supongamos que C = 1e5 (J/K), k = 55 (W/K) y tambi en que el valor inicial de Q es 3e7 (J). La variable Q aparece derivada, siendo la variable de estado. Sustituyendo la derivada de la variable de estado por la variable muda derQ y realizando la asignaci on de la causalidad computacional, se obtiene el siguiente modelo ordenado y con la causalidad computacional se nalada:
117
[in ] = 1e3; 2t [Text ] = 275 + 10 sin( ) 3600 24 Q = C [T ] [out ] = k (T Text ) [derQ] = in out
(2.139) (2.140) (2.141) (2.142) (2.143)
En la Figura 2.23 se muestra el algoritmo para la simulaci on del modelo. Dado que se ha supuesto que in no cambia con el tiempo, se asigna valor a esa variable al inicio de la simulaci on y no se modica (es decir, esa variable es tratada como un par ametro). Finalmente, en la Figura 2.24 puede observarse la evoluci on de in , out , Q, Text y T frente al tiempo.
118
Inicio
t = 0.001 t = 0, i = 0
= 1e3, C = 1e5, k = 55 Q = 3e7
t+ = t + t i = i +1
2 t T = 275 + 10 sin 3600 24 T = Q / C

= k (T T ) derQ =

t 3600 24
No S Fin
Q+ = Q + derQ t
Figura 2.23: Algoritmo para la simulaci on del modelo de la casa.
Figura 2.24: Evoluci on de algunas variables a lo largo de 24 horas (en las gr acas el tiempo se mide en segundos).
119
TEMA 3 DEVS CLASICO
3.1. Introducci on 3.2. Modelos DEVS at omicos SISO 3.3. Modelos DEVS at omicos MIMO 3.4. Modelos DEVS acoplados modularmente 3.5. Simulador abstracto para DEVS 3.6. Modelos DEVS acoplados no modularmente 3.7. Ejercicios de autocomprobaci on 3.8. Soluciones a los ejercicios
DEVS CLASICO
OBJETIVOS DOCENTES Una vez estudiado el contenido del tema deber a saber: Discutir el formalismo DEVS cl asico para modelos at omicos y compuestos. Describir modelos de eventos discretos mediante el formalismo DEVS cl asico. Discutir los fundamentos del simulador abstracto para DEVS y programar, usando un lenguaje de programaci on, el simulador de modelos DEVS at omicos y modelos DEVS modulares y jer arquicos sencillos. Discutir y aplicar el formalismo DEVS multicomponente. Discutir su relaci on con el formalismo DEVS. Discutir el modelo multiDEVS del Juego de la Vida. Discutir y aplicar el procedimiento de modularizaci on.
123
DEVS CLASICO
3.1.
INTRODUCCION
En este tema se describe la aplicaci on del formalismo DEVS (Discrete Event System Specication) al modelado de eventos discretos y se aplica en varios ejemplos sencillos. Este formalismo fue el propuesto, a mediados de la d ecada de 1970, por el profesor Bernard Zeigler (Zeigler 1976). El nombre DEVS cl asico proviene del hecho de que dos d ecadas m as tarde Chow y Zeigler (Chow 1996) realizaron una revisi on de este formalismo, con el n de explotar las posibilidades que ofrece la computaci on paralela. En el nuevo formalismo que surgi o de esta revisi on, denominado DEVS paralelo, se suprimieron algunas de las restricciones del DEVS cl asico, que se impusieron debido a la forma secuencial en que operaban los ordenadores en la d ecada de 1970. El formalismo DEVS paralelo, que ser a explicado en el Tema 4, es el que se emplea com unmente hoy en d a, si bien por motivos did acticos suele explicarse en primer lugar el formalismo DEVS cl asico. Esta es la aproximaci on seguida en este texto.
3.2.
MODELOS DEVS ATOMICOS SISO
Se dice que un modelo DEVS at omico es SISO (single-input single-output) cuando tiene un puerto de entrada y un puerto de salida. Un modelo de este tipo procesa una trayectoria de eventos de entrada y, de acuerdo a las condiciones iniciales del modelo y a esta trayectoria de entrada, produce una trayectoria de eventos de salida. En la Figura 3.1 se representa el comportamiento entrada/salida de este tipo de modelo DEVS.
DEVS
Figura 3.1: Comportamiento E/S de un modelo DEVS SISO.
El formalismo DEVS permite representar cualquier sistema que satisfaga la condici on siguiente: en cualquier intervalo acotado de tiempo, el sistema experimenta un n umero nito de cambios (eventos). La trayectoria de entrada al sistema es una secuencia ordenada de eventos y la funci on de transici on del modelo tiene una forma
125
especial, que limita la trayectoria de salida para que sea tambi en una secuencia de eventos. La especicaci on de un modelo DEVS at omico con un puerto de entrada y un puerto de salida (SISO) es la tupla siguiente: DEVS = X, S, Y, int , ext , , ta donde: X S
Conjunto de todos los posibles valores que un evento de entrada puede tener. Conjunto de posibles estados secuenciales. La din amica del modelo DEVS consiste en una secuencia ordenada de estados pertenecientes a S.
(3.1)
Y int : S S
Conjunto de posibles valores de los eventos de salida. Funci on de transici on interna, que describe la transici on de un estado al siguiente estado secuencial S . Mediante int : S S u nicamente pretende indicarse que la funci on int tiene un u nico argumento, que es un elemento del conjunto S , y la salida de la funci on es tambi en un elemento del conjunto S .
ext : Q X S
Funci on de transici on externa. La funci on tiene dos argumentos de entrada: un elemento del conjunto Q y un elemento del conjunto X . La funci on devuelve un elemento del conjunto S . El conjunto Q, llamado estado total, se dene de la forma siguiente: Q = { (s, e) | s S, 0 e ta(s) } Cada elemento del conjunto Q est a formado por dos valores: (s, e), donde s es un elemento del conjunto S y e es un n umero real positivo: el tiempo transcurrido desde la anterior transici on del estado. Como veremos, el valor de e siempre est a acotado de la forma siguiente: 0 e ta(s).
:SY
Funci on de salida. El argumento de entrada a la funci on es un elemento del conjunto S . La funci on devuelve un elemento del conjunto Y .
126
DEVS CLASICO
ta : S R+ 0,
Funci on de avance de tiempo (time advance function). El argumento de entrada a esta funci on es un elemento de S , que llamamos s. La salida devuelve un n umero real positivo, incluyendo 0 e , es decir, un elemento del conjunto R+ 0, . Este n umero, que se denomina avance de tiempo, es el tiempo que permanecer a el modelo en el estado s en ausencia de eventos de entrada.
La interpretaci on de estos elementos es la siguiente. Supongamos que en el instante de tiempo t1 el sistema est a en el estado s1 . Si no se produce ning un evento de entrada, el sistema permanecer a en el estado s1 durante ta(s1 ) unidades de tiempo, es decir, hasta el instante t1 + ta(s1 ). Obs ervese que ta(s1 ) puede ser un n umero real positivo, cero o innito. Si ta(s1 ) es cero, entonces el sistema est a en el estado s1 un tiempo cero, con lo cual los eventos externos (eventos de entrada) no pueden intervenir. En este caso, se dice que s1 es un estado transitorio. Por el contrario, si ta(s1 ) vale innito, el sistema permanecer a en el estado s1 hasta que suceda un evento externo. En este caso, se dice que s1 es un estado pasivo. Llegado el instante t2 = t1 + ta(s1 ), se produce una transici on interna. Es decir, se realizan las siguientes acciones (en el orden indicado): 1. Se asigna a e el tiempo transcurrido desde la u ltima transici on: e = ta(s1 ). 2. La salida del sistema cambia al valor y1 = (s1 ). 3. El estado del sistema pasa de ser s1 a ser s2 = int (s1 ). 4. Se planica la siguiente transici on interna para el instante t2 + ta(s2 ). Para ello, se a nade dicha transici on a la lista de eventos. Si antes del instante en que est a planicada la siguiente transici on interna llega un evento de entrada al sistema, entonces en el instante de llegada del evento de entrada se produce una transici on externa. Supongamos que el sistema pasa (mediante una transici on interna o externa) al estado s3 en el instante t3 y que en el instante t4 llega un evento de entrada de valor
127
x1 . Obs ervese que se satisfar a ta(s3 ) > e = t4 t3 , ya que en caso contrario se habr a producido una transici on interna antes de la llegada del evento externo. En respuesta a la llegada en t4 del evento externo, se producen las acciones siguientes: 1. El estado del sistema cambia instant aneamente debido al evento de entrada. El nuevo estado viene dado de evaluar la funci on de transici on externa, pas andole los tres argumentos siguientes: el valor del evento de entrada, el estado y el tiempo que ha transcurrido desde la u ltima transici on (interna o externa) del estado. El nuevo estado es s4 = ext (s3 , e, x1 ), donde e = t4 t3 . 2. Se elimina de la lista de eventos el evento interno que estaba planicado para el instante t3 + ta(s3 ). En su lugar, se planica un evento interno para el instante t4 + ta(s4 ). En ausencia de eventos externos, ese ser a el instante en que se produzca la pr oxima transici on interna. Hay dos variables que se emplean en todos los modelos DEVS para representar intervalos de tiempo. Estas son: La variable e almacena el tiempo transcurrido desde la anterior transici on del estado, ya sea interna o externa. La variable almacena el tiempo que resta hasta el instante en que est a planicada la siguiente transici on interna. Se satisface la relaci on: = ta(s) e. Es importante darse cuenta de que durante la transici on externa no se produce ning un evento de salida. Los eventos de salida s olo se producen justo antes de las transiciones internas. La explicaci on anterior acerca del funcionamiento del modelo DEVS sugiere c omo podr a ser la operaci on de un simulador que ejecute este tipo de modelos para generar su comportamiento. A continuaci on, se muestra un ejemplo del funcionamiento de un modelo DEVS. Ejemplo 3.2.1. En la Figura 3.2 se muestra un ejemplo del funcionamiento de un sistema DEVS. La trayectoria de entrada consiste en dos eventos, que ocurren en los instantes t0 y t2 . Entre estos dos instantes de tiempo, en t1 , sucede un evento interno. Los tres eventos, producen sendos cambios en el estado del sistema. La salida y0 se produce justo antes de producirse la transici on interna del estado.
128
DEVS CLASICO
= (
! "
= (
'
= (
! " (
$% &
( #)

= ( )
Figura 3.2: Ejemplo de funcionamiento de un modelo DEVS.
Inicialmente, el sistema se encuentra en el estado s0 . La siguiente transici on interna se planica para que ocurra transcurridas ta(s0) unidades de tiempo, pero antes de que llegue ese momento se produce un evento de entrada, en el instante t0 (t0 < ta(s0)). Por ello, la transici on interna planicada para el instante ta(s0) no llega a producirse: se elimina de la lista de eventos. Como resultado del evento de entrada en t0 , se produce inmediatamente un cambio en el estado. El nuevo estado viene dado por s1 = ext (s0 , e, x0 ). Es decir, el nuevo estado se calcula de la funci on de transici on externa, pas andole como par ametros el estado anterior (s0 ), el tiempo que ha permanecido el sistema en dicho estado (e) y el valor del evento de entrada (x0 ). La siguiente transici on interna se planica para dentro de ta(s1 ) unidades de tiempo, es decir, para el instante t0 + ta(s1 ). Como no se produce ning un evento externo (evento de entrada) antes de ese instante, en t0 + ta(s1 ) se produce una transici on interna. Se genera la salida, cuyo valor se calcula de la funci on de salida, pas andole como par ametro el valor del estado: y0 = (s1 ). A continuaci on, se produce la transici on del estado. El nuevo estado se calcula a partir del estado anterior: s2 = int (s1 ). Obs ervese que en las transiciones internas tanto la salida como el nuevo estado se calculan u nicamente a partir del valor anterior del estado. Una vez calculado el nuevo estado, s2 , se planica la siguiente transici on interna para dentro de ta(s2 ) unidades de tiempo, es decir, para el instante t1 + ta(s2 ). Sin
129
embargo, antes de que llegue ese instante se produce un evento externo en t2 , con lo cual se elimina el evento interno de la lista de eventos. El nuevo estado en t2 se calcula del estado anterior (s2 ), del tiempo durante el cual el sistema ha permanecido en el estado s2 (e) y del valor del evento de entrada (x1 ). El nuevo estado es: s3 = ext (s2 , e, x1 ). Se planica la siguiente transici on interna para el instante t2 + ta(s3 ) y as sucesivamente. En la denici on del modelo DEVS at omico no se indica qu e ocurre si se produce un evento externo precisamente en el mismo instante en que est a planicada una transici on interna. Habr a dos posibles formas de proceder: 1. Primero se ejecuta la transici on interna y luego la transici on externa. 2. Unicamente se ejecuta la transici on externa, elimin andose de la lista de eventos la transici on interna, que no llega a producirse. Ambas alternativas son v alidas y puede escogerse una u otra dependiendo del comportamiento del sistema que se desee modelar. Por defecto se escoge la segunda opci on: DEVS ignora la transici on interna y aplica la funci on de transici on externa. Como veremos, este conicto se resuelve en el formalismo DEVS paralelo. A continuaci on, se describen varios ejemplos de modelos DEVS at omicos, con un puerto de entrada y un puerto de salida, y se muestra cu al es su comportamiento. En la Secci on 3.3 se denen los modelos DEVS at omicos con varios puertos de entrada y varios puertos de salida. Finalmente, en la Secci on 3.4 se denir a la especicaci on de los modelos DEVS acoplados, en la cual se proporciona informaci on acerca de qu e componentes componen el modelo y c omo se realiza el acoplamiento entre ellos.
3.2.1.
Modelo de un sistema pasivo
El modelo DEVS m as sencillo es aquel que no responde con salidas a ninguna trayectoria de entrada y se encuentra siempre en su u nico estado, que denominamos pasivo. La denici on de este modelo es la siguiente: DEVS = X, S, Y, int , ext , , ta donde: (3.2)
130
DEVS CLASICO
X Y S ext (pasivo, e, x) int (pasivo) (pasivo) ta (pasivo)
= = = = = = =
R R {pasivo} pasivo pasivo
(3.3)
Los conjuntos de entrada y salida son num ericos: los eventos de entrada y de salida toman valores reales. S olo hay un estado, que es pasivo. En este estado, el tiempo que debe transcurrir hasta que se produzca una transici on interna es innito. Eso signica que el sistema permanecer a indenidamente en ese estado a no ser que sea interrumpido por un evento externo, en cuyo caso el estado dado por ext tambi en es pasivo. En consecuencia, el estado siempre es pasivo. Las funciones de transici on interna y externa llevan el sistema desde el estado pasivo hasta el estado pasivo, con lo cual no modican el estado del sistema. La funci on de salida devuelve el conjunto vac o, es decir, el sistema no produce ninguna salida. No obstante, puesto que ta vale innito, las funciones de transici on interna y de salida nunca llegan a evaluarse. Ejemplo 3.2.2. En la Figura 3.3 se muestra un ejemplo del comportamiento del DEVS pasivo.

DEVS pasivo

Figura 3.3: DEVS pasivo.
131
3.2.2.
Modelo de un sistema acumulador
Este sistema almacena internamente el valor introducido en su entrada, cosa que hace hasta que recibe el siguiente evento de entrada. El sistema dispone de una variable de estado del tipo real, llamada almacena, en la cual guarda el valor. Asimismo, necesitamos disponer de un procedimiento para indicar al sistema que queremos que genere un evento de salida con el valor almacenado. Para ello, el sistema podr a disponer de una segunda entrada, de modo que un evento externo en esa entrada indique al sistema que debe producir un evento de salida con el valor que en ese instante tiene almacenado. Sin embargo, por el momento no aplicaremos esta soluci on, ya que estamos analizando modelos DEVS at omicos con s olo un puerto de entrada. Otro procedimiento es establecer el convenio siguiente respecto a los eventos de entrada: Cuando el evento de entrada tiene valor cero, signica que queremos obtener en la salida del sistema el valor que se encuentra en ese momento almacenado. Cuando el evento de entrada tiene valor distinto de cero, signica que queremos que el sistema almacene internamente dicho valor. Una peculiaridad de este sistema es que, cuando solicitamos que genere un evento de salida con el valor almacenado, no se produce inmediatamente el evento de salida, sino que se produce un retardo desde el instante de la petici on (evento de entrada con valor cero) hasta que el sistema produce el evento de salida. Este tiempo de respuesta es un par ametro del sistema que llamaremos . Mientras transcurre el tiempo de respuesta, es decir, mientras el sistema est a procesando la petici on, todos los eventos de entrada que se produzcan son ignorados. El comportamiento del sistema tiene, por tanto, dos fases diferentes: mientras acepta eventos de entrada y mientras est a procesando una petici on. Denimos una segunda variable de estado, llamada fase, que puede tomar s olo dos valores: {pasivo, responde}. Mientras fase = pasivo, el sistema acepta eventos de entrada. Si el valor de la entrada es diferente de cero, lo almacena. Si es igual a cero, pasa al estado responde. Mientras el sistema est a en el estado responde, ignora todos los eventos de entrada. Una vez han transcurrido unidades de tiempo en el estado
132
DEVS CLASICO
responde, el sistema genera un evento de salida cuyo valor es igual al de la variable almacena, pasando seguidamente al estado pasivo. Ejemplo 3.2.3. En la Figura 3.4 se muestra un ejemplo del comportamiento din amico del DEVS acumulador. En el instante t0 la variable de estado fase vale pasivo, con lo cual el sistema almacena el valor del evento de entrada, que es x1 . El valor se guarda en una variable de estado llamada almacena, la cual pasa en el instante t0 a valer x1 .

!"#$%&'(#) !%*$+,&)

+
+ + +
Figura 3.4: Comportamiento del DEVS acumulador.
En el instante t1 se produce un evento de entrada con valor 0. Como consecuencia, fase pasa a valer responde y se programa un evento de salida, de valor x1 , para el instante t1 + . Llegado el instante t1 + , se produce el evento de salida con valor x1 y fase vuelve a tomar el valor pasivo, con lo cual el sistema vuelve a estar listo para aceptar una nueva entrada. En el instante t2 se produce un evento de entrada de valor cero. Como consecuencia de ello, fase pasa a valer responde y se programa un evento de salida, de valor
133
x1 (que es el valor guardado en la variable de estado almacena), para el instante t2 + . En el instante t3 se produce un evento de entrada de valor x2 . Sin embargo, como no ha transcurrido todav a el tiempo de respuesta, es decir, como t3 < t2 + , el evento de entrada es ignorado. En el instante t2 + se produce el evento de salida y la variable de estado fase vuelve a valer pasivo. Posteriormente, en el instante t4 se produce un evento de entrada de valor cero. Nuevamente, fase pasa a valer responde y se programa un evento de salida de valor x1 para el instante t4 + . Llegado ese instante, se produce el evento de salida y fase vuelve a valer pasivo. En el instante t5 se produce un evento de entrada de valor x3 = 0. Puesto que fase=pasivo, el valor x3 se almacena inmediatamente en la variable de estado almacena. Finalmente, en el instante t6 se produce un evento de entrada de valor 0, con lo cual fase pasa a valer responde y se programa un evento de salida de valor x3 para el instante t6 + . El comportamiento del DEVS acumulador puede expresarse formalmente de la manera siguiente: DEVS = X, S, Y, int , ext , , ta (3.4)
Se ha escrito como sub ndice de la palabra DEVS para indicar que el sistema tiene un par ametro llamado (el tiempo de respuesta). Un par ametro es una variable cuyo valor debe especicarse antes de iniciar la simulaci on del modelo y cuyo valor no se modica posteriormente. Los elementos de la tupla tienen los valores siguientes:
134
DEVS CLASICO
X Y S ext (f ase, , almacena, e, x)
= = = =
int (responde, , almacena) = (responde, , almacena) = ta (f ase, , almacena) =
R R { pasivo,responde} R+ 0 R {0} si f ase = pasivo y x = 0 (pasivo, , x) (responde, , almacena) si f ase = pasivo y x = 0 (responde, e, almacena) si f ase = responde (pasivo, , almacena) almacena (3.5)
Como puede verse en la denici on anterior, el conjunto de los estados secuenciales del modelo, S , es el producto cartesiano (representado mediante el s mbolo ) de tres conjuntos: El conjunto de posibles valores de la variable fase: {pasivo, responde}. El conjunto de posibles valores de la variable , que almacena el tiempo durante el cual el sistema va a permanecer en el estado actual. La variable puede tomar valores en el conjunto de los n umeros reales positivos, incluyendo el + cero. Este conjunto de representa: R0 El conjunto de posibles valores de la variable almacena, que son los n umeros reales menos el cero: R {0}. Consecuentemente, el conjunto S se dene de la forma: S = {pasivo,responde} R+ 0 R {0} (3.6)
por lo cual, el estado del sistema queda especicado mediante los valores que toman las tres variables: (f ase, , almacena). De la denici on de ta, vemos que la variable de estado almacena el tiempo durante el cual el sistema va a permanecer en el estado actual. Es decir, el tiempo que debe transcurrir hasta que se produzca la siguiente transici on interna, suponiendo que en ese intervalo de tiempo no se produzcan eventos de entrada. La funci on de transici on externa, ext , determina el nuevo estado del sistema cuando se produce un evento externo:
135
Cuando el sistema est a en fase = pasivo y se produce un evento de entrada con un valor x = 0, entonces fase continua valiendo pasivo y la variable de estado almacena pasa a valer x. No se planica ninguna transici on interna, con lo cual el valor de pasa a ser innito. El nuevo estado es (pasivo, , x). Cuando el sistema est a en fase = pasivo y se produce un evento de entrada de valor x = 0 en el instante t, entonces se planica una transici on interna para el instante t + . As pues, se asigna a el valor . La variable de estado fase pasa a valer responde y el valor de la variable de estado almacena no se modica. El nuevo estado es (responde, , almacena). Cuando el sistema est a en fase = responde y se produce un evento de entrada, este es ignorado. Es decir, fase sigue valiendo responde, no se modica el valor de la variable de estado almacena y se actualiza el valor de . Puesto que e es el tiempo transcurrido desde que se produjo el anterior evento, entonces se reduce el valor de , rest andole e, para reejar el tiempo mas peque no durante el cual el sistema permanece en el estado actual. El nuevo estado es (responde, e, almacena). Finalmente, la funci on de transici on interna, int , dene el nuevo estado cuando se produce una transici on interna: la variable fase pasa de valer responde a valer pasivo, no se modica el valor de almacena y, puesto que no se planica ninguna transici on interna, se asigna innito a . As pues, el nuevo estado es: (pasivo, , almacena).
3.2.3.
Modelo de un generador de eventos
Este sistema genera una salida, de valor uno, cada cierto intervalo de tiempo constante. La duraci on de dicho intervalo es un par ametro del modelo, llamado periodo. El conjunto de valores posibles del estado del modelo es el producto cartesiano de los valores posibles de dos variables: La variable de estado fase puede tomar dos valores: activo y pasivo. La variable de estado puede tomar valores reales positivos. En consecuencia, el conjunto de posibles valores del estado del sistema es:
136
DEVS CLASICO
S = {pasivo, activo} R+
(3.7)
en consecuencia, el estado del sistema queda denido mediante el valor de las dos variables siguientes: (f ase, ). El comportamiento del sistema es el siguiente. El generador permanece en la fase activo durante el intervalo de tiempo periodo, transcurrido el cual la funci on de salida genera un evento de valor uno y la funci on de transici on interna resetea fase al valor activo y asigna a el valor periodo. Estrictamente hablando, no ser a necesario volver a asignar valor a estas variables, ya que este sistema no posee entradas y, por ello, los valores de esas variables no pueden ser cambiados externamente. Ejemplo 3.2.4. En la Figura 3.5 se muestra un ejemplo del comportamiento din amico del DEVS generador.

Figura 3.5: Comportamiento del DEVS generador.
La denici on formal del comportamiento del DEVS generador es la siguiente: DEVSperiodo = X, S, Y, int , ext , , ta donde: (3.8)
137
X Y S int (f ase, ) (activo, ) ta (f ase, )
= = = = = =
{} {1} {pasivo, activo} R+ (activo, periodo) 1
(3.9)
3.2.4.
Modelo de un contador binario
En este sistema, los eventos de entrada s olo pueden tomar el valor cero o el valor uno. Los eventos de salida s olo pueden tomar un valor: el uno. As pues, el conjunto de posibles valores de los eventos de entrada y salida son los siguientes:
X = {0, 1} Y = {1}
(3.10) (3.11)
Se genera un evento de salida, de valor uno, cada dos eventos de entrada de valor uno. Para ello, el sistema contiene un contador m odulo 2 del n umero de eventos de entrada de valor uno recibidos hasta el momento. Este contador es la variable de estado cuenta. El conjunto de valores posibles del estado del sistema es el producto cartesiano de los valores posibles de las tres variables siguientes: La variable fase, que puede tomar dos valores: pasivo y activo. La variable , que puede tomar valores reales positivos, incluyendo el cero. Como siempre en los modelos DEVS, esta variable almacena el tiempo restante hasta que se produzca la pr oxima transici on interna. La variable cuenta, que tiene dos valores posibles: 0 y 1. As pues, el conjunto de valores posibles del estado puede representarse de la forma siguiente: S = {pasivo, activo} R+ 0 {0, 1} (3.12)
138
DEVS CLASICO
en consecuencia, el estado del sistema queda denido mediante el valor de las tres variables siguientes: (f ase, , cuenta). El comportamiento del sistema es el siguiente. Cuando recibe una entrada de valor uno y con ella el n umero de unos recibidos hasta ese momento es par, entonces entra en una fase transitoria, activo, para generar inmediatamente (se asigna el valor cero a ) la salida, de valor uno. La salida es generada por la funci on de salida justo antes de que se produzca la transici on interna. El comportamiento del sistema puede describirse de la manera siguiente: DEVS = X, S, Y, int , ext , , ta donde: (3.13)
X Y S
= {0, 1} = {1} = {pasivo, activo} R+ 0 {0, 1} (pasivo, e, cuenta + x) si cuenta + x < 2 ext (pasivo, , cuenta, e, x) = (activo, 0, 0) en cualquier otro caso int (f ase, , cuenta) = (pasivo, , cuenta) (activo, , cuenta) = 1 ta (f ase, , cuenta) = (3.14)
3.2.5.
Modelo de un proceso
En la Secci on 2.4.2 se describi o el modelo de una ocina de atenci on al cliente atendida por un empleado. Este modelo tiene un proceso, la ocina, el cual a su vez tiene un recurso: el empleado que trabaja en ella. En esta secci on, veremos c omo formular el modelo de un proceso con un u nico recurso, empleando la metodolog a DEVS cl asico. Una vez hayamos desarrollado el modelo DEVS del proceso, ser a posible componer el modelo de la ocina, sin la cola FIFO, simplemente conectando el modelo DEVS del generador al modelo DEVS del proceso. Las salidas del generador ser an las entidades (en el caso de la ocina, los clientes). Un evento de salida del generador se interpreta como la llegada de un nuevo cliente a la ocina.
139
El conjunto de posibles valores del estado es el producto cartesiano de los posibles valores de las tres variables de estado siguientes: La fase del sistema puede ser pasivo (el empleado no est a atendiendo a ning un cliente) o activo (est a atendiendo a un cliente). La variable . La variable entidad almacena un valor real, que es un atributo caracter stico de la entidad que tiene capturado en ese instante el recurso. Este atributo puede tomar valor en el conjunto de los n umeros reales. El conjunto de posibles valores del estado es: S = {pasivo, activo} R+ 0 R (3.15)
y, en consecuencia, el estado queda denido por el valor de las tres variables siguientes: (f ase, , entidad). El funcionamiento del sistema es el siguiente. Mientras el recurso est a en la fase pasivo, el empleado no est a atendiendo a ning un cliente. Si se produce un evento externo (la llegada de un cliente), entonces el recurso pasa a la fase activo, es decir, el empleado comienza a atender al cliente. El tiempo que tarda en procesar la entidad (en atender al cliente) es un par ametro, denominado tiempo de proceso, que representamos como . Mientras el recurso est a en la fase activo ignora los eventos de entrada. Esto es equivalente a suponer que si cuando llega un cliente el empleado est a ocupado, entonces el cliente que llega debe marcharse sin ser atendido. El valor de cada evento de entrada es un n umero real caracter stico de la entidad. Mientras la entidad tiene capturado el recurso, este n umero se almacena en una variable de estado del proceso, que llamaremos entidad. Cuando naliza el tiempo de proceso y la entidad libera el recurso, el proceso genera un evento de salida, cuyo valor es el n umero de la entidad, es decir, el valor almacenado en la variable de estado entidad. El modelo DEVS del proceso con un recurso y sin cola puede describirse de la forma siguiente: DEVS = X, S, Y, int , ext , , ta (3.16)
140
DEVS CLASICO
donde:
= R = R = {pasivo, activo} R+ 0 R (activo, , x) si f ase = pasivo ext (f ase, , entidad, e, x) = (activo, e, entidad) si f ase = activo int (f ase, , entidad) = (pasivo, , ) (activo, , entidad) = entidad ta (f ase, , entidad) = (3.17) Ejemplo 3.2.5. En la Figura 3.6 se muestra un ejemplo del comportamiento din amico del DEVS que modela un proceso con un recurso.
X Y S
>
= # $%& = !" = # $%& = !" = '()*+,+ = ./01232 = 4- '()*+,+ = 6789:;: = <5 '()*+,+ = = = = = = = = + +
Figura 3.6: Comportamiento del DEVS de un proceso con un recurso.
En el instante t0 se produce un evento de entrada de valor x0 . El nuevo estado se calcula de la funci on de transici on externa, teniendo en cuenta que el estado antes del evento es : (pasivo, , ). El nuevo estado es: (activo, , x0 ). El tiempo que el sistema permanecer a en ese estado viene dado por la funci on ta y vale .
141
En el instante t1 se produce un evento externo, de valor x1 . El nuevo estado, que se calcula de la funci on de transici on externa, es (activo, e, x0 ), donde e es el tiempo transcurrido desde la u ltima transici on, es decir, e = t2 t1 . El tiempo que el sistema permanecer a en este estado viene dado por la funci on ta y vale e. En el instante t0 + se produce una transici on interna, gener andose un evento de salida cuyo valor viene dado por la funci on de salida, , y es igual al valor almacenado en la variable de estado entidad, es decir, x0 . El nuevo estado es (pasivo, , ). En este estado permanecer a un tiempo igual a , es decir, innito. En el instante t2 se produce un evento externo de valor x2 . El nuevo estado, obtenido de la funci on de transici on externa es (activo, , x2 ) y el tiempo que permanecer a en el, en ausencia de eventos externos, es , es decir, . Trascurrido el tiempo , es decir, en el instante t2 + , se produce una transici on interna, gener andose un evento de salida de valor x2 y un cambio al estado (pasivo, , ).
3.3.
MODELOS DEVS ATOMICOS MIMO
La posibilidad de denir modelos DEVS con varios puertos de entrada y de salida simplica considerablemente la tarea de modelado. Por ejemplo, la denici on del modelo DEVS del componente acumulador descrito en la Secci on 3.2.2 se simplica si se denen dos puertos: uno para introducir los valores que deben almacenarse y otro para solicitar que el sistema genere un evento de salida con el valor almacenado. La restricci on que impone el formalismo DEVS cl asico es que en cada instante de tiempo s olo uno de los puertos puede recibir un evento de entrada. Es decir, no est a permitido que varios puertos reciban eventos de entrada en un mismo instante de tiempo. Como veremos, esta restricci on no aplica en el formalismo DEVS paralelo. La especicaci on de un modelo DEVS con varios puertos es la tupla siguiente: DEVS = X, S, Y, int , ext , , ta donde: (3.18)
142
DEVS CLASICO
X = { (p, v ) | p InP orts, v Xp }
Se denomina InP orts al conjunto de puertos de entrada del sistema. Para un puerto p, perteneciente a InP orts, se llama Xp al conjunto de posibles valores de los eventos de entrada en el puerto p. El conjunto de entrada X est a compuesto por las parejas (p, v ), donde p en el nombre del puerto de entrada y v es el valor del evento. Este valor pertenecer a al conjunto de valores admisibles Xp .
S Y = { (p, v ) | p OutP orts, v Yp }
Conjunto de posibles estados secuenciales del sistema. An alogamente al conjunto de entrada, el conjunto de salida est a compuesto por las parejas (puerto de salida, valor del evento).
int : S S ext : Q X S
Funci on de transici on interna. Funci on de transici on externa. Q = { (s, e) | s S, 0 e ta(s) } es el estado total y e es el tiempo transcurrido desde la anterior transici on.
:SY ta : S R+ 0,
Funci on de salida. Funci on de avance de tiempo.
Puede comprobarse que la denici on del modelo DEVS con varios puertos es similar a la del modelo DEVS SISO, con la excepci on de la especicaci on de los conjuntos de entrada (X ) y salida (Y ).
3.3.1.
Modelo de un conmutador
En la Figura 3.7 se muestra la interfaz del modelo de un conmutador. Tiene dos puertos de entrada, InP orts = {in, in1}, y dos puertos de salida, OutP orts = {out, out1}.
143
in in1
out
conmutador
out1
Figura 3.7: Modelo DEVS de un conmutador.
El comportamiento del conmutador est a caracterizado por el valor de la variable de estado Sw , que puede ser {true, f alse}. Cada vez que se produce un evento de entrada, cambia el valor de la variable Sw , el cual determina el funcionamiento del conmutador: Mientras Sw = true, las entidades que llegan al puerto in son enviadas al puerto out. Similarmente, las entidades que llegan al puerto in1 son enviadas al puerto out1. Mientras Sw = f alse, las entidades que llegan al puerto in son enviadas al puerto out1 y las que llegan al puerto in1 son enviadas al puerto out. En ambos casos se produce un retardo desde la llegada del evento de entrada y la generaci on del evento de salida. Este tiempo de proceso es un par ametro del modelo, que llamaremos . Durante este tiempo de proceso, el sistema no responde a los eventos de entrada. El estado del sistema est a caracterizado por las cinco variables de estado siguientes: La variable fase, que puede valer {pasivo, ocupado}. La variable , que puede tomar valores pertenecientes al conjunto R+ 0. La variable inport almacena el puerto de entrada en el cual se produjo el evento de entrada. Tiene dos posibles valores: {in, in1}. La variable almacena guarda en valor del evento de entrada. Puede tomar valores reales. La variable Sw , que puede tomar valores {true, f alse}. As pues, el estado del sistema est a caracterizado por las siguientes cinco variables: (f ase, , inport, almacena, Sw ). El conjunto de posibles estados viene denido
144
DEVS CLASICO
por el producto cartesiano de los posibles valores de cada una de estas variables: S = {pasivo, activo} R+ on del 0 {in, in1} R {true, f alse}. La descripci sistema es la siguiente: DEVS = X, S, Y, int , ext , , ta donde los conjuntos de entrada y salida son los siguientes: (3.19)
X = { (p, v ) | p InP orts = {in, in1}, v Xp } , Y = { (p, v ) | p OutP orts = {out, out1}, v Yp } , Las funciones de transici on son:
con Xin = Xin1 = R con Yout = Yout1 = R (3.20)
ext (S, e, (p, v )) = int (S )
(activo, , p, v, !Sw ) (f ase, e, inport, almacena, Sw )
si f ase = pasivo en caso contrario (3.21)
= (pasivo, , inport, almacena, Sw )
La funci on de salida es:
(out, almacena) (out1, almacena) (S ) = (out1, almacena) (out, almacena)
si si si si
f ase = activo f ase = activo f ase = activo f ase = activo
y y y y
Sw Sw Sw Sw
= true = true = f alse = f alse
e e e e
inport = in inport = in1 inport = in inport = in1 (3.22)
Finalmente, la funci on de avance del tiempo es: ta (S ) = (3.23)
3.4.
MODELOS DEVS ACOPLADOS MODULARMENTE
El formalismo DEVS permite denir modelos compuestos. Est an formados por otros modelos DEVS (at omicos o compuestos), acoplados entre s mediante la cone-
145
xi on de sus puertos. La especicaci on de los modelos DEVS compuestos es la tupla siguiente: N = X, Y, D, {Md | d D }, EIC, EOC, IC, select donde: Los conjuntos de entrada y salida, X e Y , denen la interfaz del modelo compuesto. D y Md denen los componentes. EIC , EOC , IC denen la conexi on entre los componentes y tambi en la conexi on de estos con la interfaz del modelo compuesto. La funci on select establece la prioridad en caso de que varios componentes tengan planicada una transici on interna para el mismo instante. De forma m as rigurosa, esto mismo puede expresarse como sigue: X = { (p, v ) | p InP orts, v Xp } Y = { (p, v ) | p OutP orts, v Yp } D
Conjunto de entrada del modelo compuesto. Conjunto de salida del modelo compuesto. Conjunto de nombres de los componentes.
(3.24)
Los componentes son modelos DEVS. Para cada d D se verica: Md = Xd , S, Yd , int , ext , , ta
Es un modelo DEVS cl asico, que en general tendr a varios puertos de entrada y salida. Xd = { (p, v ) | p InP ortsd, v Xp } Yd = { (p, v ) | p OutP ortsd, v Yp }
Se distinguen tres tipos de conexi on entre puertos, que se denominan EIC, EOC e IC. Como ejemplo ilustrativo de los tres tipos de conexi on, en la Figura 3.8 se muestran dos componentes, D1 y D2 , que est an conectados entre s y conectados a la interfaz del modelo compuesto que los engloba. Cada uno de los componentes, as
146
DEVS CLASICO
como el modelo compuesto, tiene un puerto de entrada y un puerto de salida. En este ejemplo, los puertos de los componentes se representan mediante tri angulos de color azul y los puertos de modelo compuesto mediante tri angulos de color negro.
EIC
IC
EOC
Figura 3.8: Tipos de conexi on entre modelos DEVS con puertos.
1. Entrada externa - Entrada de un componente. Una de las entradas al modelo compuesto se conecta a una de las entradas de los componentes que lo forman. Este tipo de conexi on, que se denomina EIC (External Input Coupling), puede denirse de la forma siguiente:
EIC { ( (N, ipN ), (d, ipd ) ) | ipN InP orts, d D, ipd InP ortsd } donde
(N, ipN ) (d, ipd ) ( (N, ipN ), (d, ipd ) )
representa el puerto de entrada ipN del modelo compuesto representa el puerto de entrada ipd del componente d representa la conexi on entre ambos puertos
2. Salida de un componente - Salida externa. Una de las salidas de los componentes se conecta a una de las salidas del modelo compuesto. Este tipo de conexi on se llama EOC (External Output Coupling) y puede denirse de la forma siguiente:
EOC { ( (d, opd ), (N, opN ) ) | opN OutP orts, d D, opd OutP ortsd } donde
(d, opd ) representa el puerto de salida opd del componente d (N, opN ) representa el puerto de salida opN del modelo compuesto ( (d, opd), (N, opN ) ) representa la conexi on entre ambos puertos
147
3. Salida de un componente - Entrada de un componente. Una de las salidas de un componente se conecta a una de las entradas de otro componente diferente. Este tipo de conexi on se llama IC (Internal Coupling) y puede denirse de la forma siguiente:
IC { ( (a, opa ), (b, ipb ) ) | a, b D con a = b, opa OutP ortsa, ipb InP ortsb } donde (a, opa ) representa el puerto de salida opa del componente a (b, ipb ) representa el puerto de entrada ipb del componente b ( (a, opa ), (b, ipb ) ) representa la conexi on entre ambos puertos La condici on a, b D con a = b indica que en el formalismo DEVS no est a permitido conectar una salida de un componente con una entrada del mismo componente. Por ello, en la denici on anterior de la conexi on interna se impone que los componentes a y b no sean el mismo: a = b. Finalmente, select es una funci on del tipo: select : 2D D
Funci on select, que establece la prioridad en caso de que varios componentes tengan un evento interno planicado para el mismo instante.
Cuando dos o m as componentes tienen prevista una transici on interna para el mismo instante de tiempo, el funcionamiento global del sistema puede variar dependiendo del orden en que se disparen estas transiciones internas, ya que las transiciones internas provocan eventos de salida, que a su vez provocan eventos externos en otros componentes. La funci on select establece prioridades para las transiciones internas de diferentes componentes. Cuando un grupo de componentes tiene planicada para un determinado instante una transici on interna, la funci on select aplicada a dicho subconjunto devuelve aquel componente del subconjunto que realizar a la transici on en primer lugar.
148
DEVS CLASICO
3.4.1.
Modelo de una secuencia de etapas
Supongamos una secuencia de unidades funcionales (tambi en denominadas etapas) que realizan una tarea en varios pasos, como por ejemplo, una l nea de ensamblaje en una f abrica. En concreto, supongamos que la l nea o pipeline consta de tres etapas, tal como se muestra en la Figura 3.9, cada una de las cuales es un proceso realizado por un recurso.
pipeline
Figura 3.9: Pipeline compuesta por tres etapas.
La conexi on en serie de los componentes se realiza conectando: El puerto de salida del primer proceso (p0 ) con el puerto de entrada del segundo proceso (p1 ). El puerto de salida del segundo proceso (p1 ) con el puerto de entrada del tercer proceso (p2 ). Este tipo de conexi on entre componentes al mismo nivel jer arquico se denomina conexi on interna o acoplamiento interno (IC), y se realiza siempre entre un puerto de salida y un puerto de entrada. Puesto que los modelos compuestos pueden usarse a su vez como componentes para construir otros modelos de un nivel jer arquico superior, los modelos compuestos tienen tambi en puertos de entrada y de salida. Por ejemplo, la pipeline mostrada en la Figura 3.9 tiene dos puertos, se nalados mediante tri angulos de color negro, uno de entrada, que est a conectado al puerto de entrada del primer componente, y otro de salida, que est a conectado al puerto de salida del tercer componente. En este caso, la conexi on se realiza entre un puerto de un modelo de nivel jer arquico superior (el modelo compuesto) y el puerto de uno de sus componentes, estableci endose siempre, o bien entre dos puertos de entrada (EIC), o bien entre dos puertos de salida (EOC). La especicaci on del modelo DEVS compuesto mostrado en la Figura 3.9 es la siguiente:
149
N = X, Y, D, {Md | d D }, EIC, EOC, IC, select donde: InP orts = {in} Xin = R X = { (in, v ) | v R }
(3.25)
Puerto de entrada del modelo compuesto. Posibles valores de los eventos en el puerto in del modelo compuesto. Puerto de entrada del modelo compuesto y posibles valores de los eventos en ese puerto.
OutP orts = {out} Yout = R Y = { (out, v ) | v R }
Puerto de salida del modelo compuesto. Posibles valores de los eventos en el puerto out del modelo compuesto. Puerto de salida del modelo compuesto y posibles valores de los eventos en ese puerto.
D = { p0 , p1 , p2 } Mp0 = Mp1 = Mp2 = Mrecurso
Conjunto de nombres de los componentes. Cada componente es un modelo DEVS del tipo recurso, como los descritos en la Secci on 3.2.5.
EIC = { ((N, in), (p0 , in)) }
Conexi on del puerto de entrada del modelo compuesto, N , al puerto de entrada del componente p0 .
EOC = { ((p2 , out), (N, out)) }
Conexi on del puerto de salida del componente p2 al puerto de salida del modelo compuesto.
IC = { ((p0 , out), (p1 , in)) , ((p1 , out), (p2, in)) } select(D ) = proceso con mayor ndice
Conexiones internas.
Funci on select, que dado un conjunto de componentes devuelve aquel cuyo ndice es mayor.
150
DEVS CLASICO
Las conexiones transmiten instant aneamente los eventos entre los puertos. Es decir: Si un evento externo llega al puerto de entrada del modelo compuesto, este es transmitido instant aneamente al puerto de entrada del componente p0 . Si el componente p0 genera un evento de salida, este es transmitido instant aneamente al puerto de entrada del componente p1 . An alogamente, si el componente p1 genera un evento de salida, este es transmitido instant aneamente al puerto de entrada del componente p2 . Si el componente p2 genera un evento de salida, este es transmitido instant aneamente al puerto de salida del modelo compuesto. El siguiente ejemplo muestra la aplicaci on de la funci on select al establecimiento del orden de disparo en caso de que varios eventos est en programados para el mismo instante. Ejemplo 3.4.1. Supongamos que el intervalo de tiempo que transcurre entre la llegada de eventos sucesivos al modelo compuesto es igual al tiempo de proceso de los tres componentes, . En este caso, las salidas de los componentes p0 y p1 est an planicadas para el mismo instante, apareciendo adem as la salida de p0 como entrada a p1 , con lo cual el componente p1 tiene planicadas para el mismo instante una transici on externa, debida al evento de entrada, y una transici on interna, en la cual genera un evento de salida. El dise nador del modelo debe decidir qu e hacer respecto al orden en que se disparan estos dos eventos: 1. Si se dispara primero el evento interno, el componente p1 pasa de activo a pasivo, con lo cual, cuando a continuaci on se dispare el evento externo, est a en disposici on de aceptar la entidad proveniente de p0 . 2. Si se dispara primero el evento externo, la entidad que llega a p1 encuentra que este est a en la fase activo, con lo cual el evento de entrada es ignorado. A continuaci on, se dispara el evento interno de p1 , pasando este componente de activo a pasivo y quedando, por tanto, en la fase pasivo. La funci on select especica que si hay dos eventos planicados para el mismo instante en los componentes p0 y p1 , entonces el evento asociado al componente de mayor ndice, que en este caso es p1 , se dispara en primer lugar. As pues, se vericar a la primera de las dos opciones anteriores.
151
3.4.2.
Modelo de una red de conmutaci on
En el modelo compuesto mostrado en la Figura 3.10, un conmutador (s0 ) env a entidades a dos procesos (p0 , p1 ). Obs ervese que la salida de cada proceso est a conectada a la salida del modelo compuesto, con lo cual los eventos generados por ambos procesos aparecen en la salida del modelo compuesto.
Figura 3.10: Red de conmutaci on.
El modelo compuesto puede especicarse siguiendo el formalismo DEVS de la forma siguiente: N = X, Y, D, {Md | d D }, EIC, EOC, IC, select donde: InP orts = {in} Xin = R X = { (in, v ) | v R }
Puerto de entrada del modelo compuesto. Posibles valores de los eventos en el puerto in del modelo compuesto. Puerto de entrada del modelo compuesto y posibles valores de los eventos en ese puerto.
(3.26)
OutP orts = {out} Yout = R Y = { (out, v ) | v R }
Puerto de salida del modelo compuesto. Posibles valores de los eventos en el puerto out del modelo compuesto. Puerto de salida del modelo compuesto y posibles valores de los eventos en ese puerto.
152
DEVS CLASICO
D = { s0 , p0 , p1 } Ms0 = Mconmutador Mp0 = Mp1 = Mrecurso EIC = { ((N, in), (s0 , in)) } EOC = { ((p0 , out), (N, out)) , ((p1 , out), (N, out)) } IC = { ((s0 , out), (p0 , in)) , ((s0 , out1), (p1 , in)) }
Conjunto de nombres de los componentes. Tipo de los componentes.
Conexi on externa de entrada. Conexiones externas de salida.
3.5.
SIMULADOR ABSTRACTO PARA DEVS
Como vimos en la Secci on 1.8, la simulaci on es una transformaci on desde un nivel superior en la descripci on del sistema, a la descripci on de entrada/salida. T picamente, dada una especicaci on del sistema, por ejemplo, siguiendo la metodolog a DEVS, y dados tambi en el valor inicial de todas las variables de estado del modelo y las trayectorias de entrada, la tarea del simulador es obtener la trayectoria del estado (evoluci on de las variables de estado) y las trayectorias de salida. En esta secci on va a describirse un procedimiento para la simulaci on de modelos DEVS, en el cual se establece de manera sistem atica una relaci on entre los componentes at omicos y acoplados de cualquier modelo DEVS, y los algoritmos para su simulaci on (Zeigler et al. 2000).
3.5.1.
Estructura del simulador abstracto
La estructura jer arquica del modelo DEVS es reproducida por una estructura jer arquica de simuladores abstractos que, funcionando de manera cooperativa, realiza la simulaci on del modelo DEVS. La estructura del simulador se obtiene a partir de la estructura del modelo de la forma siguiente: Se asocia, a cada modelo at omico DEVS, un algoritmo llamado Devs-simulator, que realiza la simulaci on del modelo DEVS at omico. Se asocia, a cada modelo DEVS acoplado, un algoritmo llamado Devs-coordinator, que realiza la simulaci on del modelo DEVS acoplado.
153
En la parte superior de la jerarqu a del simulador abstracto se sit ua un algoritmo denominado Devs-root-coordinator. Ejemplo 3.5.1. Para ilustrar la construcci on del simulador abstracto, en la Figura 3.11 se muestra la correspondencia entre un modelo DEVS compuesto, con varios niveles jer arquicos, y su simulador abstracto. Los algoritmos Devs-simulator est an asociados con las hojas del arbol del modelo: los modelos DEVS at omicos. Los algoritmos Devs-coordinator est an asociados con los modelos DEVS acoplados, que est an situados en los nodos internos de la jerarqu a del modelo DEVS.

Figura 3.11: Correspondencia entre un modelo DEVS compuesto y jer arquico (izquierda), y su simulador abstracto (derecha).
!" ( ) ( $ #% ) ( ) ( & #% ) !" ( ) ( $ #% ) ( ) ( & #% )

Figura 3.12: Protocolo de comunicaci on.
Los algoritmos Devs-simulator y Devs-coordinator son simuladores abstractos, por ese motivo en ocasiones se emplear a el t ermino simulador para referirse indistintamente a cualquiera de los dos algoritmos.
154
DEVS CLASICO
3.5.2.
Intercambio de mensajes
Los algoritmos Devs-simulator y Devs-coordinator siguen un determinado protocolo de intercambio de mensajes, que les permite coordinarse entre s durante la simulaci on y mantener el calendario de eventos. En la Secci on 2.4 se explic o que en la simulaci on de eventos discretos se mantiene una lista de eventos, denominada calendario de eventos, que est a ordenada atendiendo a la proximidad del instante en que est a planicado el disparo de cada evento. Los eventos son ejecutados extray endolos en orden del calendario de eventos y realizando las correspondientes transiciones en el estado, es decir, los correspondientes cambios en el valor de las variables de estado del modelo. La ejecuci on de los eventos resulta en la planicaci on de nuevos eventos, que son insertados en el calendario de eventos, as como en la cancelaci on de algunos eventos previamente planicados, que son eliminados del calendario de eventos. Como veremos, el calendario de eventos del simulador abstracto se construye mediante paso de mensajes a trav es de la estructura jer arquica del simulador. La comunicaci on de los algoritmos Devs-coordinator entre s y con los algoritmos Devs-simulator se realiza mediante cuatro tipos de mensaje (v ease la Figura 3.12): (i, t), (x, t), (, t) y (y, t). Un simulador env a a sus hijos (los simuladores de inferior nivel jer arquico que est an directamente en comunicaci on con el) tres tipos de mensaje, mediante los cuales puede inicializar el hijo, planicar un evento interno en el hijo y producir un evento de entrada en el hijo. Los tres tipos de mensaje son los siguientes: (i, t) El mensaje (i, t), llamado mensaje-i, inicializa el hijo, es decir, fuerza que determinadas variables internas del algoritmo hijo adquieran un valor inicial. (x, t) El mensaje (x, t), llamado mensaje-x, dispara la ejecuci on de un evento de entrada de valor v , en el puerto de entrada p del hijo, en el instante t. Se verica: x = (p, v ). (, t) El mensaje (, t), llamado mensaje-*, dispara la ejecuci on de un evento interno en el hijo, en el instante t. Asimismo, un simulador env a a su padre (el algoritmo de superior nivel jer arquico con el que se comunica) un u nico tipo de mensaje:
155
(y, t) El mensaje (y, t), llamado mensaje-y, tiene la nalidad de noticar al padre que se ha producido un evento de salida de valor v , por el puerto de salida p del simulador, en el instante t. Se verica: y = (p, v ). En los cuatro tipos de mensaje, el valor de t en el mensaje es igual al valor del reloj de la simulaci on en el instante en que se produce la comunicaci on del mensaje.
3.5.3.
Devs-simulator
El algoritmo Devs-simulator es un simulador abstracto de un modelo DEVS at omico. El algoritmo emplea las tres variables siguientes, que tienen unidades de tiempo: t tl tn Reloj de la simulaci on: almacena el tiempo simulado actual. Almacena el instante en que ocurri o el u ltimo evento (l proviene de la palabra inglesa last). Almacena el instante de tiempo para el cual est a planicado el pr oximo evento (n proviene de a palabra inglesa next).
De la denici on de la funci on de avance en el tiempo, ta, se verica la relaci on siguiente, que permite calcular tn: tn = tl + ta(s) (3.27)
Conocidos t, tl y tn, pueden calcularse las variables e y , las cuales intervienen en la denici on del modelo DEVS: El tiempo transcurrido desde el u ltimo evento, e, puede calcularse de la expresi on siguiente: e = t tl (3.28) El tiempo que falta hasta el pr oximo evento, , puede calcularse de la expresi on siguiente: = tn t = ta(s) e (3.29) A continuaci on, se muestra el algoritmo del simulador abstracto Devs-simulator, que realiza la simulaci on de un modelo DEVS at omico:
Devs-simulator
156
DEVS CLASICO
Variables: parent // Padre de este algoritmo Devs-simulator tl // Instante de tiempo en que se produjo el u ltimo evento tn // Instante de tiempo en que est a planificado el siguiente evento (s,e) // Estado total del modelo DEVS asociado a este Devs-simulator y // y = (p,v), evento de valor v en el puerto de salida p del modelo x // x = (p,v), evento de valor v en el puerto de entrada p del modelo when ( recibe mensaje-i (i,t) en el instante t ) { tl = t - e tn = tl + ta(s) env a {tl,tn} a parent } when ( recibe mensaje-* (*,t) en el instante t ) { if t != tn then error: mala sincronizaci on y = lambda(s) envia mensaje-y (y,t) a parent s = delta_int(s) tl = t tn = tl + ta(s) env a tn a parent } when ( recibe mensaje-x (x,t) en el instante t ) { if not ( tl <= t <= tn ) then error: mala sincronizaci on e = t - tl s = delta_ext(s,e,x) tl = t tn = tl + ta(s) env a tn a parent } end Devs-simulator
Obs ervese que el algoritmo del simulador abstracto Devs-simulator est a compuesto por la declaraci on de las variables y tres cl ausulas when. La sintaxis de una cl ausula when es la siguiente:
when ( evento_condici on ) { sentencias }
donde las sentencias del cuerpo de la cl ausula when se ejecutan cuando se produce el evento descrito en la condici on de la cl ausula. A continuaci on, se describen con detalle las tres cl ausulas when del algoritmo Devs-simulator.
157
Mensaje de inicializaci on En el instante inicial ti el modelo DEVS at omico se encuentra en el estado s, en el cual ha estado durante e unidades de tiempo. El estado total del modelo, (s, e), en el instante inicial ti , se supone conocido. En ese instante inicial, ti , el algoritmo Devs-simulator debe recibir un mensaje-i, (i, t), que har a que el algoritmo se inicialice correctamente. Debe recibir el mensaje de inicializaci on al comienzo de cada r eplica de la simulaci on, y antes de recibir ning un otro tipo de mensaje. La cl ausula when de inicializaci on es la siguiente:
when ( recibe mensaje-i (i,t) en el instante t ) { tl = t - e tn = tl + ta(s) env a {tl,tn} a parent }
es decir, cuando se recibe el mensaje (i, t): 1. El algoritmo asigna valor al instante de tiempo desde el evento anterior, tl, restando el tiempo transcurrido, e, del valor del reloj de la simulaci on, t, recibido en el mensaje. Es decir: tl = t e. 2. Calcula el instante de tiempo en que se planica el disparo del siguiente evento interno, tn. Para ello, suma el resultado de evaluar la funci on de avance en el tiempo, ta(s), con el instante en que se produjo el u ltimo evento, tl, que ha sido calculado previamente. 3. El valor de tn calculado se env a al coordinador padre (parent), para indicarle en qu e instante est a planicado el primer evento interno en este algoritmo Devs-simulator. Tambi en se env a el valor de tl.
Mensaje de evento interno Cuando el algoritmo Devs-simulator recibe un mensaje de transici on interna (mensaje-*), se dispara la ejecuci on en el algoritmo de un evento interno. El c odigo de la cl ausula when asociada a la recepci on de este tipo de mensaje es el siguiente:
158
DEVS CLASICO
when ( recibe mensaje-* (*,t) en el instante t ) { if t != tn then error: mala sincronizaci on y = lambda(s) envia mensaje-y (y,t) a parent s = delta_int(s) tl = t tn = tl + ta(s) env a tn a parent }
donde las acciones de la cl ausula when son la siguientes: 1. Se comprueba si el instante en que se recibe el mensaje coincide con el instante en que estaba planicada la transici on interna. Si no coincide, se ha producido un error de sincronizaci on. 2. Se calcula el valor del evento de salida, v , y el puerto en el que se produce, p. Para ello, se aplica la funci on de transici on interna, y = (s), donde y = (p, v ). 3. Se env a un mensaje (y, t) al simulador padre. En el mensaje-y se especica y , es decir, el valor calculado del evento de salida (v ) y el puerto de salida (p), y el valor actual del reloj de la simulaci on, t. 4. Se calcula el nuevo estado aplicando la funci on de transici on interna: s = int (s). 5. Se actualiza el instante del u ltimo evento al valor actual del reloj de la simulaci on: tl = t. 6. Se calcula el instante para el cual se planica el disparo del siguiente evento interno, sum andole al valor actual del reloj de la simulaci on el tiempo durante el cual el sistema permanecer a en el estado actual en ausencia de eventos externos. Es decir, se calcula tn de la expresi on siguiente: tn = tl + ta(s). 7. El valor de tn calculado se env a al coordinador padre (parent), para indicarle en qu e instante est a planicado el siguiente evento interno en este objeto Devssimulator.
Mensaje de evento externo Cuando el algoritmo Devs-simulator recibe un mensaje de transici on externa, (x, t), el algoritmo ejecuta un evento de valor v , en el puerto de entrada p, en el
159
instante de tiempo actual, t. Se verica: x = (p, v ). El c odigo de la cl ausula when es el siguiente:

when ( recibe mensaje-x (x,t) en el instante t ) { if not ( tl <= t <= tn ) then error: mala sincronizaci on e = t - tl s = delta_ext(s,e,x) tl = t tn = tl + ta(s) env a tn a parent }
donde la cl ausula when contiene las sentencias siguientes: 1. Se comprueba que el mensaje (x, t) ha llegado en un instante de tiempo anterior o igual al instante en que est a planicado el pr oximo evento interno. Es decir, se comprueba que el valor de t recibido en el mensaje verica tl <= t <= tn. Si no es as , se ha producido un error de sincronizaci on entre los algoritmos simuladores. 2. Se calcula el tiempo transcurrido desde la anterior transici on: e = t tl. 3. Se calcula el nuevo estado, evaluando para ello la funci on de transici on externa, pas andole como argumentos el estado total (s, e), que es una variable local del objeto Devs-simulator, y el valor de x recibido en el mensaje: s = ext (s, e, x). 4. Se actualiza el tiempo del u ltimo evento al valor actual del reloj de la simulaci on: tl = t. 5. Se calcula el instante de tiempo en que se producir a la siguiente transici on interna (en ausencia de eventos externos): tn = tl + ta(s). 6. El valor de tn calculado se env a al coordinador padre (parent), para indicarle en qu e instante est a planicado el siguiente evento interno en este objeto Devssimulator.
3.5.4.
Devs-coordinator
Como se ha explicado anteriormente, para simular un modelo DEVS modular y jer arquico se asocia un algoritmo Devs-simulator a cada modelo DEVS at omico y
160
DEVS CLASICO
un algoritmo Devs-coordinator a cada modelo acoplado. Con cada algoritmo Devscoordinator se comunican, desde un nivel jer arquico inmediatamente inferior, sus simuladores hijos: uno por cada componente del modelo acoplado. Estos simuladores son algoritmos Devs-simulator o Devs-coordinator, dependiendo de si el componente es at omico o compuesto, respectivamente. Cada simulador Devs-coordinator es responsable de la correcta sincronizaci on de sus simuladores hijos, ya sean simuladores Devs-simulator u otros simuladores Devscoordinator. Para ello, el simulador Devs-coordinator intercambia mensajes con sus hijos y con su padre, y gestiona una lista ordenada de eventos, en la que va almacenando el instante en el que est a planicado el pr oximo evento interno en cada uno de sus simuladores hijo. Esta lista de eventos est a ordenada en funci on de los valores de tn. Cuando hay varios valores de tn iguales, los eventos se ordenan empleando la funci on select del componente acoplado al que est a asociado el simulador Devscoordinator. El primer evento de la lista de eventos es aquel cuyo instante de disparo est a m as cercano en el tiempo. Si se llama D al conjunto de hijos del algoritmo, el primer evento de la lista puede calcularse de la expresi on siguiente: tn = m n { tnd | d D } (3.30)
Asimismo, el algoritmo Devs-coordinator calcula el instante de tiempo en que se produjo el u ltimo evento. Este c alculo se realiza a partir de los instantes de tiempo en que se produjo el u ltimo evento en cada uno de sus simuladores hijo: tl = m ax { tld | d D } (3.31)
Adicionalmente, el algoritmo Devs-coordinator debe gestionar los eventos de entrada que llegan a la interfaz del modelo DEVS acoplado que simula. El algoritmo del simulador abstracto Devs-coordinator es el siguiente:
Devs-coordinator variables: parent // Simulador coordinador padre tl // Instante de tiempo del u ltimo evento ejecutado tn // Instante de tiempo del pr oximo evento planificado event-list // Lista de eventos, (d,tn_d), ordenada por tn_d y select d* // Hijo con evento interno planificado m as pr oximo when ( recibe mensaje-i (i,t) en el instante t ) { env a mensaje-i (i,t) a cada uno de los simuladores hijo d
161
recibe {tn_d, tl_d} de cada hijo d ordena la lista de eventos tl = max{ tl_d | d en D } tn = min{ tn_d | d en D } env a {tn,tl} a parent } when ( recibe mensaje-* (*,t) en el instante t ) { if t != tn then error: mala sincronizaci on d* = primer elemento en la lista de eventos envia mensaje-* (*,t) a d* recibe tn_d* de d* actualiza la lista de eventos tl = t tn = min{ tn_d | d en D } env a tn a parent } when ( recibe mensaje-x (x,t) en el instante t ) { if not ( tl <= t <= tn ) then error: mala sincronizaci on para cada conexi on [ (N,p) , (d*,p_d*) ] { env a el mensaje-x ((p_d*,v),t) a d* recibe tn_d* de d* } actualiza la lista de eventos tl = t tn = min{ tn_d | d en D } env a tn a parent } when ( recibe mensaje-y ((p_d*,v_d*),t) en el instante t de d* ) { para cada conexi on [ (d*,p_d*) , (N,q) ] { env a el mensaje-y ((q,v_d*),t) a parent } para cada conexi on [ (d*,p_d*) , (d,p_d) ] { env a un mensaje-x ((p_d,v_d*),t) al hijo d recibe tn_d del hijo d } actualiza la lista de eventos tl = t tn = min{ tn_d | d en D } env a tn a parent } end Devs-coordinator
Como se mencion o anteriormente, el algoritmo Devs-coordinator env a y recibe el mismo tipo de mensajes que el algoritmo Devs-simulator. Puede recibir, desde su simulador padre, los siguientes mensajes:
162
DEVS CLASICO
Un mensaje-i de inicializaci on, (i, t), Mensajes-* de transici on interna, (, t) que disparan la ejecuci on de eventos internos. Mensajes-x de transici on externa, (x, t), correspondientes a eventos externos de entrada al modelo DEVS acoplado, que disparan la ejecuci on de eventos externos. El simulador Devs-coordinator env a a su simulador padre mensajes-y, ((v,p),t), que indican que el modelo DEVS compuesto ha generado un evento de salida de valor v , en el puerto p, en el instante t. Finalmente, el simulador Devs-coordinator gestiona los mensajes-y recibidos desde sus simuladores hijo. Un evento de salida de un simulador hijo puede suponer un evento de entrada para otro simulador hijo y tambi en un evento externo de salida del modelo DEVS acoplado. Por ejemplo, en el modelo acoplado mostrado en la Figura 3.9, un evento de salida del componente p1 supone un evento de entrada en el componente p2 . Asimismo, un evento de salida en el componente p2 supone un evento externo de salida del modelo DEVS acoplado pipeline. A continuaci on, se explican detalladamente las acciones que realiza el Devscoordinator cuando recibe cada tipo de mensaje.
Mensaje de inicializaci on Se supone que se conoce el estado total de cada componente en el instante inicial ti . En otras palabras, se supone que se conoce (sd , ed ), para todo d D . Esto implica que el componente d ha permanecido en el estado sd durante un tiempo ed , es decir, desde el instante ti ed hasta el instante inicial ti . Para garantizar el correcto funcionamiento del simulador jer arquico, el mensaje de inicializaci on debe llegar a cada algoritmo Devs-coordinator y Devs-simulator antes que ning un otro tipo de mensaje. El algoritmo Devs-coordinator contiene una cl ausula when con las acciones a ejecutar cuando recibe un mensaje-i de su simulador padre. Esta cl ausula when es la siguiente:
when ( recibe mensaje-i (i,t) en el instante t ) { env a mensaje-i (i,t) a cada uno de los simuladores hijo d
163
recibe {tn_d, tl_d} de cada hijo d ordena la lista de eventos tl = max{ tl_d | d en D } tn = min{ tn_d | d en D } env a {tn,tl} a parent }
Como puede verse en el c odigo anterior, la acciones que realiza cuando recibe el mensaje-i son las siguientes: 1. Reenv a a sus simuladores hijo el mensaje-i. 2. Cada uno de los simuladores hijo procesa el mensaje-i y, una vez hecho esto, cada uno de ellos devuelve una pareja de valores {tnd , tld } al Devs-coordinator. As pues, el Devs-coordinator recibe parejas de valores {tnd , tld } para todo d D , donde D es el conjunto de simuladores hijo de este Devs-coordinator. 3. Los instantes en que est an planicados los eventos internos de los hijos se ordenan cronol ogicamente, de m as pr oximo a m as lejano en el tiempo, en una lista o el calendario de eventos. En caso de coincidencia en el instante de disparo del evento interno de varios hijos, se usa la funci on Select del modelo DEVS acoplado para decidir c omo deben ordenarse. 4. Se escoge el mayor valor de tld y se asigna a tl. 5. Se escoge el menor valor de tnd y se asigna a tn. As pues, tn contiene el m as reciente de los eventos internos planicados en los simuladores hijo. 6. Finalmente, el Devs-coordinator env a los valores de tn y tl obtenidos anteriormente a su simulador padre.
Mensaje de evento interno La siguiente cl ausula when realiza las acciones que se ejecutan cuando el Devscoordinator recibe un mensaje-* de su simulador padre. La cl ausula when es la siguiente:
when ( recibe mensaje-* (*,t) en el instante t ) { if t != tn then error: mala sincronizaci on d* = primer elemento en la lista de eventos envia mensaje-* (*,t) a d*
164
DEVS CLASICO
recibe tn_d* de d* actualiza la lista de eventos tl = t tn = min{ tn_d | d en D } env a tn a parent }
Las acciones que se realizan son las siguientes: 1. En primer lugar, se comprueba que el valor de la variable tiempo del mensaje recibido, t, coincide con el instante en que est a planicado el evento interno m as pr oximo. Si no coincidiera, se ha producido un error de coordinaci on. 2. El simulador Devs-coordinator sabe a cual de sus simuladores hijo corresponde el evento interno del mensaje: a aquel que ocupa el primer puesto en la lista de eventos. Llamemos d al simulador hijo que ocupa el primer puesto en la lista de eventos. 3. El simulador Devs-coordinator env a el mensaje-* al simulador hijo d . 4. El simulador d ejecuta la transici on interna de su estado y, si como resultado de la transici on interna genera un evento de salida, adem as env a un mensajey, (yd , t), a su simulador padre, es decir, al simulador Devs-coordinator. La recepci on de este mensaje-y proveniente del simulador hijo d desencadena una serie de acciones, como veremos en el siguiente ep grafe. 5. Una vez el simulador d ha ejecutado el evento interno, env a el valor tnd al simulador Devs-coordinator, en el que le indica el instante para el cual est a planicado su siguiente evento interno. 6. El simulador Devs-coordinator elimina de la lista de eventos el evento que acaba de pasar a su simulador hijo d , e inserta en la lista de eventos el pr oximo evento planicado en este simulador hijo. 7. El simulador Devs-coordinator actualiza el valor de sus variables tn y tl. Asigna a tl el valor actual del reloj de la simulaci on, tl = t, y asigna a tn el instante de tiempo del primer evento de la lista de eventos: tn = m n{tnd |d D }. 8. Finalmente, env a el valor de tn a su simulador padre (parent).
165
Mensaje de salida de un simulador hijo Cuando el simulador Devs-coordinator recibe un mensaje-y del tipo (yd , t), signica que en el instante t, el simulador hijo d ha generado un evento de salida de valor vd a trav es de su puerto de salida pd . Se verica que: yd = (pd , vd ). Por ello, en el algoritmo el mensaje-y se escribe de la forma siguiente: ((pd , vd ), t). La siguiente cl ausula when describe las acciones asociadas a la recepci on de dicho mensaje:
when ( recibe mensaje-y ((p_d*,v_d*),t) en el instante t de d* ) { para cada conexi on [ (d*,p_d*) , (N,q) ] { env a el mensaje-y ((q,v_d*),t) a parent } para cada conexi on [ (d*,p_d*) , (d,p_d) ] { env a un mensaje-x ((p_d,v_d*),t) al hijo d recibe tn_d del hijo d } actualiza la lista de eventos tl = t tn = min{ tn_d | d en D } env a tn a parent }
Las acciones ejecutadas como consecuencia de recibir el mensaje (yd , t) son las siguientes: 1. El simulador Devs-coordinator inspecciona las conexiones entre el puerto de salida pd y los puertos de salida del modelo acoplado. Representamos mediante [(d , pd ), (N, q )] este tipo de conexiones, donde N representa el modelo DEVS acoplado y q el puerto de salida del modelo DEVS acoplado al cual est a conectado el puerto de salida pd del componente d . Para cada una de estas conexiones, se env a el siguiente mensaje-y a parent (el simulador padre de Devs-coordinator): ((q, vd ), t), que indica que se ha generado un evento de salida de valor vd en el puerto de salida q del DEVS acoplado, en el instante t. 2. El simulador Devs-coordinator inspecciona las conexiones entre el puerto de salida pd de d y los puertos de entrada de los dem as componentes d, con d D . Este tipo de conexiones se representan de la forma siguiente: [(d , pd ), (d, pd)]. Para cada una de estas conexiones entre d y un componente d, Devs-coordinator env a el siguiente mensaje-x al componente d: ((pd , vd ), t). Este mensaje dis-
166
DEVS CLASICO
para la ejecuci on de un evento externo de valor vd , en el puerto de entrada pd , en el instante t. Una vez ejecutadas las transiciones externas, los componentes d env an al Devs-coordinator los instantes para los que est an planicadas sus pr oximas transiciones internas, tnd . 3. El Devs-coordinator elimina de la lista los eventos que estaban programados para estos componentes, que ya no llegar an a producirse debido a la transiciones externas que acaban de ejecutarse, e inserta la nueva planicaci on de eventos internos que acaba de recibir. 4. Finalmente, el algoritmo Devs-coordinator actualiza los valores de sus variables tl y tn, y env a el valor de tn a parent.
Mensaje de evento externo Un mensaje-x, (x, t), enviado al algoritmo Devs-coordinator desde su padre, produce el disparo de un evento externo de valor v , en el puerto de entrada p del modelo DEVS acoplado asociado al Devs-coordinator, en el instante t. Obs ervese que el valor del evento externo, v , y el puerto de entrada, p, son transmitidos en el mensaje, ya que x es la pareja de valores (p, v ). Es decir: x = (p, v ). Cuando el algoritmo Devs-coordinator recibe un mensaje-x de su padre, entonces ejecuta las acciones descritas en la cl ausula when siguiente:
when ( recibe mensaje-x (x,t) en el instante t ) { if not ( tl <= t <= tn ) then error: mala sincronizaci on para cada conexi on [ (N,p) , (d*,p_d*) ] { env a el mensaje-x ((p_d*,v),t) a d* recibe tn_d* de d* actualiza la lista de eventos } tl = t tn = min{ tn_d | d en D } env a tn a parent }
El simulador Devs-coordinator ejecuta las acciones siguientes cuando recibe un mensaje (x, t) de su padre: 1. En primer lugar, comprueba que el evento externo no se ha recibido posteriormente al instante en que est a planicado el siguiente evento interno, tn. Si
167
no se satisface la condici on tl t tn, entonces se ha producido un error de sincronizaci on entre los algoritmos. 2. El algoritmo Devs-coordinator analiza las conexiones entre los componentes, con el n de identicar qu e puertos de entrada de los componentes est an directamente conectados al puerto p del modelo compuesto, que es donde se ha producido el evento externo de entrada. Este tipo de conexiones, entre el puerto de entrada p del modelo compuesto N y el puerto de entrada pd del componente d , se representan de la forma siguiente: [(N, p), (d , pd )]. 3. Para cada una de las conexiones anteriores entre el modelo compuesto y uno de los submodelos, que llamamos d , el algoritmo Devs-coordinator env a un mensaje-x al submodelo d . El mensaje-x fuerza el disparo de un evento de entrada de valor v , en el puerto de entrada pd del componente d, en el instante t. Tras ejecutar su evento externo de entrada, cada uno de los componentes d env a al algoritmo Devs-coordinator el instante en el cual tiene planicado su siguiente evento interno, tnd . El algoritmo Devs-coordinator actualiza su lista de eventos, eliminando el evento interno que estaba planicado para cada componente d e insertando en la lista de eventos los nuevos instantes de disparo tnd , para todos los componentes d . 4. Finalmente, el algoritmo Devs-coordinator recalcula el valor de sus variables tl y tn, y env a el valor calculado de tn a su simulador padre.
3.5.5.
Devs-root-coordinator
El algoritmo Devs-root-coordinator, situado en el nivel jer arquico superior del simulador abstracto (v ease, por ejemplo, la Figura 3.11), gestiona el avance del reloj de la simulaci on, t. Realiza su tarea enviando mensajes al algoritmo del nivel jer arquico inmediatamente inferior, que es el simulador asociado al modelo DEVS completo. Si el modelo DEVS completo es acoplado, el algoritmo hijo de Devs-root-coordinator ser a un algoritmo Devs-coordinator. Si el modelo DEVS completo es at omico, el algoritmo hijo ser a Devs-simulator. En cualquier caso, Devs-root-coordinator tiene un u nico simulador hijo. El algoritmo Devs-root-coordinator es el siguiente:
Devs-root-coordinator variables:
168
DEVS CLASICO
t // Reloj de la simulaci on hijo // Algoritmo de nivel jer arquico inmediatamente inferior t = t0 env a mensaje-i (i,t) a hijo recibe tn de hijo t = tn loop env a mensaje-* (*,t) a hijo recibe tn de hijo t = tn until final de simulaci on end Devs-root-coordinator
Como puede verse en el c odigo anterior, las acciones que realiza el algoritmo son las siguientes: 1. Inicialmente, Devs-root-coordinator env a un mensaje-i a su simulador hijo, que es propagado a trav es de todo el arbol jer arquico del simulador abstracto, inicializando todos los simuladores. En respuesta, el algoritmo hijo responde enviando a Devs-root-coordinator el instante de tiempo para el que est a planicada la pr oxima transici on interna, tn. 2. El algoritmo Devs-root-coordinator avanza el reloj de la simulaci on, t, hasta el valor tn que ha recibido de su hijo. Es decir, asigna: t = tn. 3. El algoritmo Devs-root-coordinator env a a su hijo un mensaje-*, (, t), que fuerza la ejecuci on del evento interno m as reciente. En respuesta el hijo env a a Devs-root-coordinator el instante para el cual est a planicado el siguiente evento interno, tn. 4. El algoritmo Devs-root-coordinator avanza el reloj de la simulaci on, t, hasta el valor tn que ha recibido de su hijo. 5. Devs-root-coordinator comprueba si se satisface la condici on de nalizaci on de la simulaci on. En caso armativo, naliza la simulaci on. En caso contrario, vuelve al Paso 3.
3.6.
MODELOS DEVS ACOPLADOS NO MODULARMENTE
En la Secci on 3.4 se describi o la construcci on modular de modelos de eventos discretos. Los modelos DEVS con acoplamiento modular est an formados de compo-
169
nentes, que son sistemas DEVS, que interact uan s olo a trav es de la conexi on entre los puertos de sus interfaces. En los modelos DEVS con acoplamiento no modular, los componentes inuyen sobre los otros componentes a trav es de la funci on de transici on de estados. Los eventos que ocurren en un componente pueden producir cambios en el estado, as como planicaci on o cancelaci on de eventos en otros componentes. Este tipo de modelos acoplados no modularmente, en los cuales los componentes son modelos DEVS, se denominan DEVS multicomponente.
3.6.1.
DEVS multicomponente
Un modelo DEVS multicomponente es la tupla siguiente: multiDEVS = X, Y, D, {Md }, Select donde: X Y D Select : 2D D
Conjunto de eventos de entrada. Conjunto de eventos de salida. Conjunto de referencias a los componentes. Funci on select. Establece la prioridad en caso de que varios componentes tengan planicado un evento interno para el mismo instante.
(3.32)
adem as, cada componente d D se dene de la forma siguiente: Md = Sd , Id , Ed , ext,d , int,d , d , tad donde Sd
Conjunto de estados secuenciales de d.
(3.33)
170
DEVS CLASICO
Qd = { (sd , ed ) | sd Sd , ed R+ 0 }
Estados totales de d. El estado total es el estado del sistema, sd , y el tiempo transcurrido ed desde la u ltima transici on (interna o externa) del estado de d.
Id D Ed D ext,d : Qi X Qj
iId j Ed
Conjunto de componentes cuyo estado inuye en el estado de d. Conjunto de componentes cuyo estado es inuido por el estado de d. Funci on de transici on externa del estado. Los argumentos de entrada de la funci on son el estado total de cada uno de los componentes que inuyen sobre d y el evento de entrada (X ). Se representa
iId
Qi el producto cartesiano del esta-
do total de todos los componentes que inuyen sobre d. La funci on devuelve el estado total de todos los componentes que son inuenciados por d. An alogamente,
j Ed
Qj representa el producto cartesiano
del estado total de todos los componentes que son inuenciados por d.
int,d : Qi Qj
iId j Ed
Funci on de transici on interna del estado. Los argumentos de entrada de la funci on son el estado total de cada uno de los componentes que inuyen sobre d. La funci on devuelve el estado total de todos los componentes que son inuenciados por d.
d : Qi Y
iId
Funci on de salida. Los argumentos de la funci on son el estado total de todos los componentes que inuyen en d. La funci on devuelve un elemento del conjunto de salida del multiDEVS.
171
tad : Qi R+ 0,
iId
Funci on de avance en el tiempo. Los argumentos de entrada a la funci on son el estado total de todos los componentes que inuyen en d. Devuelve un valor real positivo, incluyendo el cero y el innito.
El funcionamiento de un modelo DEVS multicomponente, tambi en llamado multiDEVS, es el siguiente. Los eventos internos de cada componente son planicados individualmente por cada componente d D , empleando para ello su funci on de avance en el tiempo tad . Cuando se dispara un evento interno en uno de los componentes d D , el evento es ejecutado, resultando en: Cambios en el estado, que vienen dados por la funci on de transici on interna int,d . A partir del estado total de todos los componentes que inuyen sobre d, la funci on de transici on interna calcula el nuevo estado total de todos los componentes que son inuidos por d. La generaci on de eventos de salida en el multiDEVS, que viene dada por la funci on de salida d , pasando como argumentos a la funci on el estado total de todos los componentes que inuyen en d. Cuando est an planicados para un mismo instante eventos internos en diferentes componentes, se emplea la funci on Select para decidir cu al de ellos es ejecutado. Cuando se produce un evento externo en la interfaz de entrada del multiDEVS, entonces reaccionan ante el los componentes d que tienen denida una funci on de transici on externa ext,d . No reaccionan ante los eventos externos aquellos componentes que no tienen denida la funci on de transici on externa.
3.6.2.
MultiDEVS denido como DEVS
Tal como se describe a continuaci on, un modelo multiDEVS puede interpretarse como un modelo DEVS. Sea el modelo DEVS: DEVS = X, Y, S, ext , int , , ta (3.34)
172
DEVS CLASICO
El conjunto de estados s ncronos del modelo DEVS, S , es el producto cartesiano de los conjuntos de posibles estados totales de los componentes del multiDEVS. S = Qd
dD
(3.35)
La expresi on anterior indica que el estado del modelo DEVS queda denido si se conoce el estado total de cada uno de los componentes del modelo multiDEVS. El tiempo hasta el siguiente evento interno en el modelo DEVS se calcula de la forma siguiente: ta(s) = m n{ d | d D } (3.36)
donde d es el tiempo hasta el siguiente evento interno planicado en el componente d del modelo multiDEVS. El valor de d puede calcularse evaluando tad y restando ed al valor obtenido. Es decir: d = tad (. . . , qi , . . . ) ed con i Id (3.37)
donde la notaci on tad (. . . , qi , . . . ) con i Id representa que la funci on de avance en el tiempo del componente d tiene como argumentos el estado total de todos los componentes que inuyen sobre d. El modelo d del multiDEVS que sufre la siguiente transici on en el estado es aquel que tiene el menor valor d . En caso de que este valor coincida para varios modelos del multiDEVS, entonces se usa la funci on Select del multiDEVS para decidir cu al de ellos sufre la transici on interna. Llamemos d al modelo del multiDEVS que sufrir a la siguiente transici on interna. La funci on de transici on interna del modelo DEVS puede denirse de la forma siguiente: int ((s1 , e1 ), . . . , (sn , en )) = ((s1 , e1 ), . . . , (sn , en )) donde: (3.38)
(sj , ej ) =
(sj , ej + ta(s)) int,d (. . . , (si , ei + ta(s)), . . . )
si j / Ed si j Ed , con i Id
(3.39)
173
es decir, la funci on de transici on interna del modelo DEVS est a denida por la funci on de transici on interna del componente d del multiDEVS. Igualmente, la salida del modelo DEVS est a denida por la funci on de salida del componente d del multiDEVS: (s) = d (. . . , qi , . . . ) con i Id (3.40)
An alogamente, la funci on de transici on externa del modelo DEVS se dene, para un evento externo x, como el resultado de la ejecuci on de las funciones de transici on externa de todos los componentes del multiDEVS.
3.6.3.
Modelo multiDEVS del Juego de la Vida
El aut omata celular del Juego de la Vida, descrito en la Secci on 2.4.1, puede modelarse como un multiDEVS de componentes id enticos, distribuidos uniformemente y con acoplos entre ellos uniformes. El modelo multiDEVS de este aut omata celular tiene las caracter sticas siguientes: El conjunto de componentes que inuyen al componente (i, j ), Ii,j , as como el conjunto de componentes que son inuidos por el, Ei,j , son la propia c elula (i, j ) m as las c elulas vecinas. La funci on de avance en el tiempo de cada c elula debe describir su nacimiento y muerte, bas andose para ello en su valor actual del factor ambiental y en el estado de las c elulas vecinas. La funci on de avance toma el valor innito en caso de que no se planique ning un evento. Un evento en el estado en una c elula puede modicar los eventos planicados en sus c elulas vecinas. El estado de la c elula Mi,j puede denirse de la forma siguiente: Si,j = {f asei,j , f actorAmbientali,j } (3.41)
donde la variable de estado f ase puede tomar los valores {viva, muerta} y la variable de estado f actorAmbiental representa el valor actual del factor ambiental de la c elula.
174
DEVS CLASICO
El tiempo hasta la siguiente transici on interna de la c elula (i, j ) depende de su estado, del estado de las c elulas vecinas y del valor actual de su factor ambiental. Llamando vecV ivasi,j al n umero de c elulas vecinas de (i, j ) que est an vivas, puede denirse la variable coefi,j , que representa el aumento o reducci on del factor ambiental de la c elula (i, j ), de la forma siguiente:
coefi,j
1 = 1 0
si vecV ivasi,j = 3 si f asei,j = viva and (vecV ivasi,j < 2 or vecV ivasi,j > 3) en cualquier otro caso (3.42)
Esto signica que cuando el n umero de c elulas vecinas vivas es igual a 3, el factor ambiental aumenta con pendiente 1. Cuando la c elula est a viva y el n umero de c elulas vecinas es menor que 2 o mayor que 3, entonces el factor ambiental aumenta con pendiente -1, es decir, decrece. Obs ervese que s olo han de planicarse eventos en los dos casos siguientes: Cuando la c elula (i, j ) est a muerta y coefi,j = 1, en cuyo caso debe planicarse el nacimiento. Sabiendo que el factor ambiental de una c elula muerta es 2 y que la pendiente con que aumenta el factor ambiental es 1, el evento nacimiento se planica para dentro de 2 unidades de tiempo. Cuando la c elula (i, j ) est a viva y coefi,j = 1, en cuyo caso debe planicarse el evento de la muerte de la c elula. Conocido el valor actual del factor ambiental y el hecho de que este evoluciona con pendiente 1, puede calcularse f acilmente el tiempo hasta el evento. La funci on de transici on interna de la c elula (i, j ) debe describir el nacimiento o muerte de dicha c elula. Asimismo, debe recalcular la variable coef de las c elulas vecinas y el instante en que se producir a el siguiente evento en cada una de ellas.
3.6.4.
Modularizaci on
En los sistemas multicomponente con acoplamiento no modular, los componentes pueden acceder y escribir directamente en las variables de estado de los dem as componentes. Desde el punto de vista del acoplamiento modular, esto supone una violaci on del principio de modularidad, seg un el cual la interacci on entre los componentes debe producirse u nicamente a trav es de sus interfaces.
175
A continuaci on, se describe un procedimiento para traducir el acoplamiento no modular en acoplamiento modular, demostr andose asimismo que esta transformaci on siempre puede realizarse. El procedimiento consiste en identicar la dependencia entre los componentes y, en funci on de dicha dependencia, denir las interfaces y la conexi on entre ellas. Este proceso de introducci on de interfaces para describir el acoplamiento se denomina modularizaci on. Pueden distinguirse dos tipos de acoplamiento no modular, que deben ser tratados de manera diferente: 1. Un componente A tiene acceso para escribir en una variable v de un componente B . Esta comunicaci on debe transformarse en una conexi on entre las interfaces de A y B : se dene un puerto de salida en A, vout, un puerto de entrada en B , vin, y se conectan ambos. Cada vez que A quiera escribir en la variable v de B , en la versi on modular A debe generar un evento de salida, a trav es del puerto vout, cuyo valor sea igual al que se desea escribir en v . A trav es de la conexi on, esto resulta en un evento de entrada en el puerto vin de B . La funci on de transici on externa de B debe reaccionar escribiendo el valor recibido en la variable v . En la Figura 3.13 se representa esquem aticamente el proceso de modularizaci on.
A

( )
B

A
()

B
( )

=
=
Figura 3.13: El componente A tiene acceso para escribir en la variable v del componente B .
2. Un componente B tiene acceso de lectura a la variable u del componente A. Esta situaci on es m as complicada, puesto que B debe tener acceso en todo momento al valor actual de la variable. Para resolver la situaci on, B guarda una copia del valor de la variable u en su propia memoria. Denominaremos a esta copia ucopy . Ahora bien, cada vez que A cambia el valor de u, B debe ser informado del cambio. Esto se consigue conectando los puertos uout y uin, de A y B respectivamente, de manera simular a como se hizo en el caso anterior. La funci on de transici on externa de B debe actualizar el valor de ucopy . En la Figura 3.14 se representa esquem aticamente el proceso de modularizaci on.
176
DEVS CLASICO
A

B

( )
=
A

() ()(*
=(
(

)
= ( ) ! = " #$%&'
Figura 3.14: El componente B tiene acceso para leer la variable u del componente A.
177
3.7.
Ejercicio 3.1 Dibuje, para una trayectoria de entrada de su elecci on, el estado y la trayectoria de salida del modelo DEVS del contador binario.
Ejercicio 3.2 Dena un contador DEVS SISO que cuente el n umero de entradas con valor diferente de cero que ha recibido desde su inicializaci on y que devuelva este valor cuando reciba una entrada de valor cero.
Ejercicio 3.3 Describa el modelo de un sistema, empleando el formalismo DEVS, cuyo comportamiento es el siguiente. Cuando el sistema recibe un evento de entrada de valor real positivo x, genera, tras x unidades de tiempo, una salida de valor x/2. Durante este tiempo de proceso de duraci on x, el sistema ignora los eventos de entrada. Adem as, represente gr acamente una secuencia de eventos de entrada de su elecci on y la correspondiente evoluci on del estado y de la trayectoria de salida.
Ejercicio 3.4 Consideremos un multiplexor 2:1 que tiene dos entradas de datos (X0 , X1 ), una entrada de selecci on (S ) y una salida (Y ). Las se nales de entrada y salida son binarias, pudiendo tomar dos posibles valores: {0, 1}. Es posible realizar dos tipos de modelo de este circuito: un modelo de tiempo continuo y un modelo de eventos discretos. En el modelo de tiempo continuo, las trayectorias de entrada y salida son se nales constantes a tramos. En la Figura 3.15a se muestra un ejemplo del comportamiento de tiempo continuo del multiplexor. Mientras S vale 0, la salida Y es igual al valor de la entrada X0 . Asimismo, mientras S vale 1, la salida Y es igual al valor de la
178
DEVS CLASICO
entrada X1 . En la Figura 3.15a se ha se nalado en color rojo los segmentos de las trayectorias de entrada de datos (X0 , X1 ) que el circuito transmite a la salida. En el modelo de eventos discretos del multiplexor las trayectorias de entrada y salida son eventos, los cuales pueden tomar dos valores: {0, 1}. La descripci on de eventos discretos de una se nal binaria consiste en una secuencia de eventos, que se producen en el instante en que la se nal cambia de valor. El valor del evento es igual al nuevo valor que toma la se nal. Es decir, el instante en que la se nal cambia de 0 a 1 est a denido por un evento de valor 1. An alogamente, el instante en que la se nal cambia de 1 a 0 est a denido por un evento de valor 0. En la Figura 3.15b se muestra un ejemplo del comportamiento de eventos discretos del multiplexor. Los eventos de entrada se nalan los cambios en las se nales de entrada. S olo se producen eventos de salida cuando cambia el valor de la se nal de salida. Describa, empleando el formalismo DEVS cl asico, el modelo de eventos discretos del multiplexor 2:1.
Figura 3.15: MUX 2:1. Ejemplo de comportamiento: a) del modelo de tiempo continuo; y b) del modelo eventos discretos.
179
Ejercicio 3.5 Describa, empleando el formalismo DEVS cl asico, el modelo de un sistema que introduce un retardo aleatorio a las entidades. El sistema tiene una entrada y una salida. Las entidades llegan de una en una al sistema. Cada entidad tiene un n umero que la identica de forma un voca. La llegada de una entidad corresponde con un evento de entrada cuyo valor es igual al n umero identicativo de la entidad recibida. Cuando llega una entidad, en el sistema se obtiene una observaci on aleatoria de la distribuci on U(1,2) minutos, que es el tiempo durante el cual la entidad permanecer a en el sistema. Transcurrido ese tiempo, la entidad abandona el sistema: se genera un evento de salida cuyo valor es el n umero identicativo de la entidad. Obs ervese que puesto que el tiempo que permanece cada entidad en el sistema es aleatorio, puede suceder que haya varias entidades esperando en el sistema y que las entidades no abandonen el sistema en el mismo orden en que han llegado.
Ejercicio 3.6 Describa el modelo DEVS multicomponente del aut omata celular unidimensional descrito a continuaci on. Consideremos un objeto que se mueve a lo largo de una l nea recta. La velocidad con la que se mueve el objeto se modica instant aneamente mediante eventos externos, cuyo valor representa el nuevo valor de la velocidad del objeto. Cuando la velocidad es positiva, el objeto de mueve hacia la derecha. Cuando es negativa, el objeto de mueve hacia la izquierda. Cuando la velocidad es cero, el objeto se queda parado. Suponga que la longitud de la recta, que es igual a 20 metros, se divide en 20 c elulas de 1 metro de longitud cada una, y que la primera y la u ltima c elulas se encuentran unidas entre s . El modelo debe describir el movimiento del objeto en el espacio celular. Cada una de las c elulas puede estar en dos estados, {0, 1}, dependiendo de que el objeto se encuentre (estado=1) o no (estado=0) en ella. Tenga en cuenta que el tiempo que transcurre desde que el objeto entra en una c elula, hasta que la abandona para entrar en la siguiente, depende de la velocidad del objeto.
180
DEVS CLASICO
Ejercicio 3.7 Describa el modelo de un sistema de bifurcaci on aleatoria de las entidades (denominado com unmente bloque de decisi on), empleando el formalismo DEVS cl asico. El sistema tiene una u nica entrada, a trav es de la cual las entidades llegan de una en una. Cada entidad tiene asociado un n umero que la caracteriza de forma un voca. La llegada de una entidad corresponde con un evento de entrada, cuyo valor coincide con el n umero identicativo de la entidad. El sistema tiene dos salidas. Un par ametro del sistema, p, dene la probabilidad de que la entidad abandone el sistema por la salida 1. Si la entidad no abandona el sistema por la salida 1, lo abandona por la salida 2. As pues, cuando llega una entidad, se genera una observaci on, u, de la distribuci on U (0, 1). Si u < p, entonces la entidad abandona el sistema por la salida 1. En caso contrario, lo abandona por la salida 2. En cualquier caso, el tiempo de residencia de la entidad es el sistema es cero.
entrada
p
salida 2
salida 1
Figura 3.16: Bloque de decisi on.
Ejercicio 3.8 Describa el modelo compuesto mostrado en la Figura 3.17 mediante el formalismo DEVS cl asico.
in out1 out2
P0
P 1 P2
Figura 3.17: Modelo compuesto.
181
Ejercicio 3.9 Empleando el formalismo DEVS cl asico, describa el modelo de un biestable tipo ). D con dos entradas (D y Ck ) y dos salidas (Q y Q
182
DEVS CLASICO
3.8.
Soluci on al Ejercicio 3.1 El funcionamiento del contador binario est a descrito en el Tema 3 del texto de teor a. Los eventos de entrada pueden tomar valor cero o uno. Los eventos de salida toman valor uno. Se genera un evento de salida cada dos eventos de entrada de valor uno. Para ello, el sistema contiene un contador m odulo 2 del n umero de eventos de entrada de valor uno recibidos hasta el momento. Este contador es la variable de estado cuenta. En la Figura 3.18 se muestra la trayectoria de salida y la evoluci on de la variable de estado cuenta para una determinada trayectoria de entrada.
Figura 3.18: Trayectoria de salida y evoluci on del estado del contador binario para una trayectoria de entrada.
Soluci on al Ejercicio 3.2 El estado del contador est a compuesto por tres variables de estado, (f ase, , cuenta). Los valores posibles del estado son: S = {pasivo, activo} R+ 0 N El comportamiento del sistema puede describirse de la manera siguiente: (3.43)
183
DEVS = X, S, Y, int , ext , , ta donde:
(3.44)
= R = N = {pasivo, activo} R+ 0 N (pasivo, e, cuenta + 1) ext (pasivo, , cuenta, e, x) = (activo, 0, cuenta) int (f ase, , cuenta) (activo, , cuenta) ta (f ase, , cuenta) = (pasivo, , cuenta) = cuenta =
X Y S
si x = 0 si x = 0
(3.45) La inicializaci on del modelo consistir a en asignar el siguiente valor al estado: (f ase, , cuenta) = (pasivo, , 0) (3.46)
Para ilustrar el comportamiento del modelo, en la Figura 3.19 se muestra la evoluci on del estado y la trayectoria de salida del contador, para una determinada trayectoria de entrada. Obs ervese que en los instantes t1 y t4 se producen sendos eventos de entrada de valor cero. Al ejecutar la funci on de transici on externa, el sistema pasa al estado transitorio (activo, 0, cuenta). Puesto que en este estado = 0, a continuaci on, en el mismo instante de tiempo, tiene lugar una transici on interna. Se genera un evento de salida de valor igual al valor que ese instante tiene cuenta y se produce una transici on de estado, denida por la funci on de transici on interna. El estado resultante de la transici on interna es (pasivo, , cuenta).
Soluci on al Ejercicio 3.3 El estado del sistema est a compuesto por las tres variables de estado siguientes: (f ase, , almacena).
184
DEVS CLASICO
42 3
6 5
67 5

$ ( !"# %& ' '()

) - ) ( *+, ./ 0 01)
9: = 9 ( ;< >? @ @A)
( )

8

Figura 3.19: Ejemplo de evoluci on del contador SISO.
La variable de estado f ase puede tomar los valores {pasivo, responde}. Se guarda en la variable almacena el valor del evento de entrada almacenado en el sistema. Este valor puede ser cualquier n umero real. El comportamiento del sistema puede describirse de la manera siguiente: DEVS = X, S, Y, int , ext , , ta donde: (3.47)
= R+ 0 = R+ 0 = {pasivo, responde} R+ 0 R (responde, x, x) ext (S, e, x) = (responde, e, almacena) int (S ) = (pasivo, , almacena) (S ) = almacena/2 ta (S ) = X Y S
si f ase = pasivo si f ase = responde
(3.48)
185
La inicializaci on del modelo podr a consistir en asignar el siguiente valor al estado: (f ase, , almacena) = (pasivo, , 0) (3.49)
Soluci on al Ejercicio 3.4 Obs ervese que el multiplexor s olo genera un evento de salida cuando se produce un evento de entrada y el valor de la salida correspondiente es diferente del anterior evento de salida. Esto es equivalente a decir que los eventos de salida se producen u nicamente en los instantes en que la se nal de salida cambia su valor. El multiplexor de tiempo continuo es un sistema sin memoria: un circuito combi + X1 S . Por el contrario, el multiplexor nacional cuya funci on l ogica es Y = X0 S de tiempo discreto es un sistema con memoria. Cuando llega un evento de entrada a alguno de sus puertos, el sistema debe recordar el valor de los u ltimos eventos que se produjeron en los otros puertos, con el n de evaluar la nueva salida, y debe comparar esta nueva salida con el valor del u ltimo evento de salida, para decidir si debe o no generarse un evento de salida. El sistema s olo genera un evento de salida cuando cambia el valor de la se nal de salida. Una forma de modelar este comportamiento es denir tres variables de estado, que almacenen el valor de las entradas. Llamaremos sX 0 , sX 1 y sS a estas tres variables de estado, cada una de las cuales puede tomar los valores {0, 1}. Aunque esto no es necesario, deniremos otra variable de estado, sY , que almacene el u ltimo valor del evento de salida. De esta forma, cuando se produzca un evento de entrada, puede compararse el nuevo valor de la salida con el valor de sY , gener andose un evento de salida s olo en el caso de que ambos valores sean diferentes. As pues, el estado del sistema est a compuesto por las variables de estado siguientes: (f ase, , sX 0 , sX 1 , sS , sY ). En el enunciado se indica que el sistema tiene 3 entradas (X0 , X1 , S ) y una salida (Y ). Llamaremos a estos puertos: pX 0 , pX 1 , pS y pY . Para simplicar la descripci on del sistema, interpretaremos los valores {0, 1} como 0 l ogico y 1 l ogico, o equivalentemente, como f alse y true, respectivamente. Llamaremos vX 0 , vX 1 , vS y vY al valor de los eventos producidos en cada uno de los puertos. El comportamiento del sistema puede describirse de la manera siguiente:
186
DEVS CLASICO
DEVS = X, S, Y, int , ext , , ta donde:
(3.50)
X = { (p X 0 , { 0 , 1 } ), (p X 1 , { 0 , 1 } ), (p S , { 0 , 1 } )} Y = { (p Y , { 0 , 1 } )} S = {pasivo, activo} R+ 0 {0, 1} {0, 1} {0, 1} {0, 1}
(3.51)
ext (S, e, (p, v )) =
int (S ) (S ) ta (S )
= = =
(activo, 0, vX 0 , sX 1 , sS , (vX 0 s S + sX 1 sS )) si (p = pX 0 ) and (vX 0 s S + sX 1 sS = sY ) (activo, 0, sX 0, vX 1 , sS , (sX 0 s S + vX 1 sS )) si (p = pX 1 ) and (sX 0 s S + vX 1 sS = sY ) (activo, 0, sX 0, sX 1 , vS , (sX 0 v S + sX 1 vS )) si (p = pS ) and (sX 0 v S + sX 1 vS = sY ) (pasivo, e, sX 0 , sX 1 , sS , sY ) en cualquier otro caso (pasivo, , sX 0 , sX 1 , sS , sY ) sY (3.52)
Soluci on al Ejercicio 3.5 El comportamiento del sistema puede describirse de la forma siguiente. Una de las variables de estado del sistema (q ) es una cola donde se guarda ordenadamente la informaci on de las entidades que esperan en el sistema. La informaci on de cada entidad es el n umero que la identica y el instante de tiempo en que dicha entidad abandonar a el sistema. Las entidades est an dispuestas en la cola siguiendo el orden en que deber an abandonar el sistema, siendo la primera entidad de la cola la primera en abandonar el sistema. Cuando llega una nueva entidad, la funci on de transici on externa inserta la nueva entidad en la posici on correspondiente de la cola. La transici on interna debe producirse en el instante en que la primera entidad de la cola debe abandonar el sistema. La funci on de salida genera un evento cuyo valor
187
coincide con el n umero que identica a la primera entidad de la cola y la funci on de transici on interna extrae la primera entidad de la cola. Una vez descrito a grandes rasgos el comportamiento del modelo, veamos c omo puede denirse cada uno de los elementos de la tupla del modelo DEVS cl asico de este sistema SISO: DEVS = X, S, Y, int , ext , , ta (3.53)
El conjunto de valores posibles de los eventos de entrada y de salida son los n umeros reales: X=Y =R (3.54)
El estado del sistema puede ser descrito mediante las variables de estado siguientes: fase puede tomar dos valores: activo y pasivo. El sistema se encuentra en la fase activo cuando hay alguna entidad esperando dentro de el. Se encuentra en la fase pasivo cuando no hay ninguna entidad esperando dentro de el. puede tomar valores reales incluido el cero (R+ 0 ). Su valor representa el tiempo durante el cual el sistema permanecer a en el estado actual en ausencia de eventos externos. q = {(t1 , x1 ), . . . , (tn , xn )} es la cola de entidades que esperan en el sistema. La cola se encuentra ordenada de modo que se satisface t1 t2 tn . Cada pareja de valores corresponde con una entidad que est a esperando en el sistema. En el caso de la entidad i- esima de la cola, el valor ti es el instante de tiempo en el cual la entidad debe abandonar el sistema y el valor xi es el n umero que identica a la entidad de forma un voca. tlast almacena el instante de tiempo en el cual se produjo el u ltimo evento. El valor inicial de esta variable es cero. El conjunto de valores que puede tomar es R+ 0 . Esta variable de estado se emplea para calcular el valor del reloj de la simulaci on en los instantes en que se producen las transiciones internas y externas. La funci on de transici on externa, cada vez que es invocada, obtiene una observaci on independiente de la distribuci on de probabilidad U(1,2), que llamaremos ,
188
DEVS CLASICO
y que representa el tiempo durante el cual la entidad que acaba de llegar permanecer a en el sistema. El instante de tiempo en el cual la entidad reci en llegada abandonar a el sistema se obtiene sumando al valor que tenga el reloj de la simulaci on en el instante en que se produce la llegada. Este valor es tlast + e. Es decir, la suma del instante de tiempo en que se produjo el u ltimo evento (tlast ) m as el tiempo transcurrido (e) desde ese instante hasta el instante actual. El cambio en el estado producido por la funci on de transici on externa puede interpretarse de la forma siguiente: Si cuando se produce el evento externo fase vale pasivo, signica que no hay ninguna entidad esperando en el sistema y, por tanto, q no tiene ning un elemento (q = ). La variable de estado fase pasar a a valer activo, ya que la entidad reci en llegada se quedar a esperando en el sistema. La variable de estado pasar a a valer . Se a nade la entidad reci en llegada a la cola q , que estaba vac a. El nuevo valor de la cola, que contiene un u nico elemento, es: q = {(tlast + e + , x)}. Si cuando se produce el evento externo fase vale activo, signica que hay n 1 entidades esperando en el sistema. Con la llegada de una nueva entidad, fase sigue valiendo activo. El nuevo valor de la cola se obtiene insertando (tlast + e + , x) en la posici on correspondiente de la cola, de modo que las parejas queden ordenadas por orden creciente de instante en el cual deben abandonar el sistema. Llamando I a la funci on que inserta la entidad reci en llegada en la cola, el nuevo valor de la cola es: q = I ((tlast + e + , x), q ). El tiempo restante hasta el instante en que se produce la pr oxima transici on interna es el menor de dos valores: ( e) y . Es decir, se comprueba cu al de las dos entidades siguientes abandona antes el sistema: la entidad que se encontraba primera en la cola o la entidad que acaba de llegar. En ambos casos, el nuevo valor de tlast es tlast + e. Es decir, el nuevo valor es igual a su valor anterior m as el tiempo transcurrido desde que se produjo el anterior evento (e). Formalmente, la funci on de transici on externa puede escribirse de la forma siguiente:
189
ext =
(activo, , {(tlast + e + , x)}, tlast + e) (activo, m n( e, ), I ((tlast + e + , x), q ), tlast + e)
si f ase = pasivo si f ase = activo (3.55)
La funci on de transici on interna describe el cambio en el estado del sistema cuando la entidad que est a en la primera posici on de la cola abandona el sistema. El nuevo estado del sistema depende del n umero de entidades que se encuentren en la cola una vez extra da de la cola la primera entidad. Si la cola se representa como q = (t1 , x1 ) q , donde (t1 , x1 ) es el primer elemento de la cola y q es la cola una vez extra do el primer elemento, entonces pueden distinguirse la dos situaciones siguientes: Si q s olo tiene una entidad, entonces q es el conjunto vac o. En este caso, el nuevo estado ser a: f ase=pasivo, = , q = , tlast = tlast + e. Si q tiene m as de una entidad, entonces q = {(t2 , x2 ), }. El nuevo estado del sistema ser a: f ase=activo, = t2 (tlast + e), q = q , tlast = tlast + e. El nuevo estado puede representarse de la forma siguiente:
int (f ase, , (t1 , x1 ) q , tlast ) =
(pasivo, , q , tlast + e) (activo, t2 (tlast + e), q , tlast + e)
si q = si q = (3.56)
La funci on de salida devuelve el valor x1 . Es decir, el n umero que identica a la primera entidad de la cola. (f ase, , q = {(t1 , x1 ), }, tlast ) = x1 La funci on de avance en el tiempo vale: ta = . (3.57)
Soluci on al Ejercicio 3.6 Un modelo DEVS multicomponente es la tupla siguiente: multiDEVS = X, Y, D, {Md }, Select (3.58)
190
DEVS CLASICO
Los eventos de entrada pueden tomar cualquier valor real: X = R. La llegada del evento de entrada indica el instante en el que se produce un cambio en la velocidad del objeto y el valor del evento representa este nuevo valor de la velocidad. En el enunciado no se indica que el sistema genere ning un evento de salida, por tanto: Y = . Si el sistema est a formado por N componentes, estos se referenciar an numer andolos consecutivamente: D = {1, . . . , N }. Cada componente, d, tiene un componente situado a la izquierda y otro a la derecha. Dado que la primera y la u ltima c elulas est an unidas entre s , la c elula N est a situada a la izquierda de la c elula 1. Puesto que el objeto s olo puede estar en una de las c elulas y los eventos internos se producen cuando el objeto pasa de una c elula a la contigua, en este sistema no es posible que varios componentes tengan planicadas transiciones internas para el mismo instante, por ello no es preciso denir la funci on Select. Cada uno de los componentes, d D , se dene de la forma siguiente: Md = Sd , Id , Ed , ext,d , int,d , d , tad (3.59)
El estado del componente d, Sd , puede representarse mediante las cuatro variables de estado siguientes: (f ase, , posicion, velocidad). La variable fase puede tomar dos valores, {ocupado, libre}, dependiendo de que el objeto se encuentre o no en el componente. La variable almacena el tiempo hasta la siguiente transici on interna en ausencia de eventos externos. Las variables posici on y velocidad almacenan la posici on y velocidad del objeto en el instante en que se produjo el u ltimo evento. Si el objeto no se encuentra en el componente, tienen el valor cero. Llamando L a la longitud de una de las c elulas (en este caso, L = 1 m), la variable posicion puede tomar valores entre 0 y L. El valor 0 representa el extremo izquierdo de la c elula y el valor L el extremo derecho. Cada c elula inuye sobre sus c elulas adyacentes y es inuenciada por estas. Supongamos que el objeto se encuentra en la c elula i. En el instante en que el objeto sale de la c elula i, se produce un evento interno. La funci on de transici on interna de la c elula i modica el estado de la c elula i y de una de las adyacentes
191
(aquella en la cual entra el objeto). El nuevo estado de la c elula i es: ( fase = libre, , 0, 0). Adem as: Si velocidad >0, entonces el objeto entra en la c elula situada a la derecha de i. El nuevo estado de la c elula situada a la derecha de i es: ( fase = ocupado, L/velocidad, 0, velocidad). Obs ervese que L/velocidad es el tiempo que tardar a el objeto en atravesar la c elula si no hay cambios en su velocidad (es decir, en ausencia de eventos externos). Si velocidad <0, entonces el objeto entra en la c elula situada a la izquierda de i. El nuevo estado de la c elula situada a la izquierda de i es: ( fase = ocupado, L/velocidad, L, velocidad). El signo menos en L/velocidad es debido a que en este caso la velocidad tiene signo negativo. La posici on del objeto es L, ya que el objeto entra por la parte derecha de la c elula. Los eventos externos producen cambios en la velocidad del objeto. El cambio en el estado de las c elulas viene denido por la funci on de transici on externa. El estado de las c elulas en las que no se encuentra el objeto no se ve alterado por el evento externo. Suponiendo que el objeto se encuentre en la c elula i, el nuevo valor del estado de la c elula i al producirse un evento de valor x es el siguiente: Si x = 0: ( ocupado, , posicion + velocidad e, 0) Si x > 0: ( ocupado,
L(posicion+velocidade) , x
posicion + velocidad e, x)
velocidade Si x < 0: ( ocupado, posicion+x , posicion + velocidad e, x)
donde e es el tiempo transcurrido desde que se produjo la anterior transici on. La funci on de avance en el tiempo de cada c elula devolver a el valor de la variable de estado de la c elula.
Soluci on al Ejercicio 3.7 El estado del sistema puede denirse mediante cuatro variables de estado: (fase, , entidad, u). La variable fase indica si el sistema se encuentra activo (respondiendo a un evento de entrada) o pasivo.
192
DEVS CLASICO
La variable almacena el tiempo que transcurrir a hasta la siguiente transici on interna en ausencia de eventos externos. La variable entidad almacena el n umero identicativo de la entidad. La variable u almacena la observaci on de la distribuci on U(0,1) generada en la u ltima transici on externa. El comportamiento del sistema puede describirse de la manera siguiente: DEVSp = X, S, Y, int , ext , , ta donde: (3.60)
X Y S ext (S, e, (entrada, x)) int (S ) (S ) ta (S )
= = = = =
{(entrada, R)} {(salida1, R), (salida2, R)} {pasivo, activo} R+ 0 R [0, 1] (activo, 0, x, genera observaci on U(0,1)) (pasivo, , entidad, u) (salida1, entidad) si u < p = (salida2, entidad) en caso contrario =
(3.61)
Soluci on al Ejercicio 3.8 La especicaci on del modelo DEVS compuesto mostrado en la Figura 3.17 es la siguiente: N = X, Y, D, {Md | d D }, EIC, EOC, IC, select donde: X = {(in, R)} Y = { (out1, R), (out2, R)}
Puerto de entrada del modelo compuesto y posibles valores de los eventos. Puerto de salida del modelo compuesto y posibles valores de los eventos.
(3.62)
193
D = {P0 , D, P1, P2 } MP0 , MP1 , MP2 , D EIC = { ((N, in), (P0 , in)) }
Conjunto de nombres de los componentes. Cada componente es un modelo DEVS. Conexi on del puerto de entrada del modelo compuesto, N , al puerto de entrada del componente P0 .
EOC =
((P1 , out), (N, out1)) , ((P2 , out), (N, out2))
Conexi on del puerto de salida de los componentes P1 y P2 a los puertos de salida del modelo compuesto.
((P0 , out), (D, in)) , IC = ((D, out1), (P1 , in)) , ((D, out2), (P , in)) 2 select()
Deber a establecerse atendiendo al funcionamiento del sistema, que no se especica en el enunciado.
Soluci on al Ejercicio 3.9 Los eventos en el puerto de entrada D , y en los puertos de salida Q y notQ pueden tomar los valores {0,1}. Los eventos en el puerto de entrada Ck s olo pueden tomar un valor: {1}. Al realizar el modelo, suponemos que en este sistema no pueden producirse dos eventos de entrada simult aneos. El funcionamiento del sistema es el siguiente. Cada vez que se produce un evento de entrada en el puerto Ck , se producen dos eventos de salida: Un evento en el puerto Q, cuyo valor es igual al del u ltimo evento recibido en el puerto de entrada D . Un evento en el puerto notQ, cuyo valor es igual al complementario del valor del u ltimo evento recibido en el puerto de entrada D . El modelo debe almacenar el valor del u ltimo evento recibido en el puerto de entrada D . Este valor se almacena en la variable de estado sD , que puede tomar los valores {0,1}. El estado del sistema es: (f ase, , sD ). La variable de estado f ase puede tomar dos valores: {pasivo, respuesta}.
194
DEVS CLASICO
El comportamiento del sistema puede describirse de la manera siguiente: X Y S ext (S, e, (p, v )) = {(D, {0, 1}), (Ck, {1})} = {(Q, {0, 1}), (notQ, {0, 1})} = {pasivo, respuesta} R+ 0 {0, 1} = (3.63)
(pasivo, e, v ) si p = D (respuesta, 0, sD ) si p = Ck int (f ase, , sY ) = (pasivo, , sD ) (f ase, , sY ) = {(Q, {sD }) , (notQ, {s D } )} ta (f ase, , sY ) =
Mediante s on de la funci on de salida, se representa el D , empleado en la denici valor complementario del almacenado en sD .
195
TEMA 4 DEVS PARALELO
4.1. Introducci on 4.2. Modelos at omicos 4.3. Modelos compuestos 4.4. Ejercicios de autocomprobaci on 4.5. Soluciones a los ejercicios
DEVS PARALELO
OBJETIVOS DOCENTES Una vez estudiado el contenido del tema deber a saber: Aplicar el formalismo DEVS paralelo a la descripci on de modelos at omicos y compuestos de eventos discretos. Discutir las diferencias entre DEVS paralelo y DEVS cl asico.
199
DEVS PARALELO
4.1.
INTRODUCCION
El formalismo DEVS paralelo diere del formalismo DEVS cl asico en que DEVS paralelo permite el disparo simult aneo de eventos en diferentes componentes del modelo y la generaci on simult anea de las correspondientes salidas. Asimismo, el formalismo DEVS paralelo permite la llegada simult anea de varios eventos a un mismo puerto de entrada y la generaci on simult anea de varios eventos en un mismo puerto de salida. En todos los casos, los componentes receptores de estos eventos son los encargados de examinar el evento de entrada y de procesarlo adecuadamente.
4.2.
MODELOS ATOMICOS
Un modelo at omico DEVS paralelo, que en general tendr a varios puertos de entrada y varios puertos de salida, se dene mediante la tupla siguiente: DEVS = XM , S, YM , int , ext , con , , ta donde: XM = { (p, v ) | p InP orts, v Xp } S YM = { (p, v ) | p OutP orts, v Yp } int : S S b ext : Q XM S b con : Q XM S :S Yb ta : S R+ 0, Q = { (s, e) | s S, 0 e ta(s) }
Puertos de entrada y valores. Conjunto de estados secuenciales. Puertos de salida y valores. Funci on de transici on interna. Funci on de transici on externa. Funci on de transici on conuyente. Funci on de salida. Funci on de avance de tiempo. Estado total.
(4.1)
Obs ervese que el formalismo DEVS paralelo presenta dos diferencias fundamentales respecto al DEVS cl asico: 1. DEVS paralelo permite que varios eventos se produzcan simult aneamente en uno o varios puertos de entrada y de salida. Por ello, la funci on de transici on externa y la funci on de salida de DEVS paralelo son denidas haciendo uso del concepto de bolsa de eventos. El super ndice b representa la palabra inglesa bag.
201
Se denomina bolsa a un conjunto de elementos, en el cual es posible que algunos de los elementos est en repetidos. Por ejemplo, {a, b, a, c, b, b} es una bolsa. Al igual que sucede en los conjuntos, los elementos de una bolsa no est an ordenados.
b En la denici on de la funci on de transici on externa de DEVS paralelo, XM representa una bolsa de parejas (puerto, evento). Al usar bolsas para agrupar los eventos de entrada estamos reconociendo el hecho de que las entradas pueden llegar simult aneamente a un mismo puerto de entrada, en un orden indeterminado, o a varios puertos de entrada.
Igualmente, la funci on de salida de DEVS paralelo genera una bolsa de eventos de salida, Y b . Es decir, el sistema puede generar simult aneamente varios eventos en uno o en varios de sus puertos de salida. 2. Una segunda diferencia respecto a DEVS cl asico es que la especicaci on DEVS paralelo contiene una funci on adicional: la funci on de transici on conuyente, con . La nalidad de esta funci on es denir el nuevo estado del sistema cuando en un mismo instante llega una bolsa de eventos de entrada y est a planicada una transici on interna del estado. Obs ervese que en este caso no se trata de decidir si se ejecuta antes la transici on interna o la externa, sino que la funci on de transici on conuyente permite especicar directamente cu al es el nuevo estado cuando se produce la conuencia de una transici on interna y una externa.
b Mediante la notaci on con : Q XM S se representa el tipo de argumentos de la funci on y el tipo de resultado que devuelve. Los argumentos de entrada a la funci on son el estado total del sistema (Q) y la bolsa de eventos de entrada b (XM ). La funci on devuelve el nuevo estado del sistema.
Ejemplo 4.2.1. En la Figura 4.1 se muestra un ejemplo del comportamiento de un modelo DEVS paralelo con una entrada (X ) y una salida (Y ). Para simplicar las explicaciones, los eventos llegan al puerto de entrada de uno en uno (x2 en el instante t2 , x4 en t4 , etc.), y la funci on de salida genera cada vez un u nico evento, que es enviado a trav es del puerto de salida (y1 en el instante t1 , y2 en t2 , etc.) En los instantes t2 y t5 , la llegada de un evento externo coincide con el instante en que est a planicada una transici on interna. En estos instantes se ejecuta la funci on de salida, gener andose un evento de salida. A continuaci on, se calcula el nuevo estado, empleando la funci on de transici on conuyente.
202
DEVS PARALELO
X
x2 t2 x4 x5
x6
t4
s3 = con
t5
s5 = ext
t6
s7 = ext s6 = con
s1
s2 = int s4 = int
s8 = int
t
Y
y1 y2 y5 y3 y7
t
ta ( s1 ) ta ( s2 ) ta ( s3 ) e4 ta ( s5 ) e6
ta ( s7 )
Figura 4.1: Comportamiento de un modelo DEVS paralelo.
4.2.1.
Modelo de un proceso con una cola
En la Secci on 3.2.5 se describi o en modelo DEVS cl asico de un proceso con un recurso. En aquel caso, el proceso no dispon a de una cola en la cual pudieran esperar las entidades. Consecuentemente, si cuando llegaba una entidad el recurso se encontraba ocupado, dicha entidad era ignorada. En esta secci on complicaremos un poco el modelo descrito en la Secci on 3.2.5, suponiendo que el proceso dispone de una cola con disciplina FIFO en la cual pueden esperar las entidades a que llegue su turno. La especicaci on DEVS paralelo de este sistema es la siguiente: DEVS = XM , S, YM , int , ext , con , , ta A continuaci on se describe cada uno de los elementos de la tupla. (4.2)
203
Conjuntos de entrada y salida El modelo tiene un u nico puerto de entrada, llamado In. Los eventos de entrada a trav es de ese puerto pueden tomar valores de entre un conjunto de valores posibles, que representamos mediante V . Por ejemplo, V podr a ser el conjunto de los n umeros reales. El valor de cada evento de entrada corresponde con un atributo o identicador, que caracteriza la entidad que llega al proceso. As pues: XM = { (p, v ) | p InP orts, v Xp } InP orts = {In} Xin = V
(4.3)
El modelo tiene un u nico puerto de salida, llamado Out. El conjunto de valores que pueden tomar los eventos de salida es tambi en V. As pues: YM = { (p, v ) | p OutP orts, v Yp } OutP orts = {Out} Yout = V
(4.4)
Estado secuencial El estado del modelo, S , est a denido mediante las tres variables de estado siguientes: La variable fase, que puede valer pasivo o activo. La variable , que almacena el tiempo hasta el instante en que est a planicada la siguiente transici on interna. Puede tomar valores reales positivos, incluyendo + el cero: R0 . La variable q , que almacena la informaci on sobre la secuencia de entidades que se encuentran en cola y la entidad que se encuentra en proceso. Puesto que cada entidad est a caracterizada por un valor perteneciente al conjunto V , la variable q almacena una secuencia nita de valores pertenecientes al conjunto V . Dicha secuencia nita de valores se representa mediante V + . En consecuencia, el conjunto de los posibles valores del estado secuencial del sistema es el producto cartesiano de los posibles valores de estas tres variables:
204
DEVS PARALELO
+ S = {pasivo, activo} R+ 0 V
(4.5)
Consecuentemente, el estado del sistema queda denido especicando el valor de las tres variables de estado: (f ase, , q ).
Funci on de transici on externa En el modelo DEVS paralelo pueden producirse varios eventos de entrada simult aneamente en un puerto, lo que equivaldr a a la llegada simult anea de varias entidades al proceso. Cuando se produce esta situaci on, el modelo debe situar las entidades ordenadamente en la cola y, en caso de que el proceso se encuentre en la fase pasivo, comenzar a trabajar con la entidad que se encuentre situada en primer lugar. Obs ervese que las bolsas son conjuntos no ordenados de elementos. Por tanto, en la bolsa de eventos de entrada los elementos (eventos de entrada) no est an ordenados. La funci on de transici on externa es la siguiente: ext (f ase, , q, e, ((In, x1), (In, x2), . . . , (In, xn))) = (activo, , {x1, x2, . . . , xn}) (activo, e, q {x1, x2, . . . , xn}) si f ase = pasivo si f ase = activo (4.6)
Obs ervese que los argumentos de entrada de la funci on son el estado total del sistema, {f ase, , q, e}, y la bolsa de los eventos de entrada, que est a compuesta por pares (puerto, evento de entrada). En este caso, hay un u nico puerto de entrada, In, al cual se supone que llegan n eventos simult aneamente, de valor x1, . . . , xn. En consecuencia, la bolsa de eventos de entrada se representa:
b XM = ((In, x1), (In, x2), . . . , (In, xn))
(4.7)
El nuevo estado tras la transici on externa depende del valor que tuviera fase en el instante de llegada de los n eventos externos simult aneos: Si el proceso se encuentra en la fase pasivo, entonces no hay ninguna entidad en q , ya que q almacena la entidad en proceso y las entidades en cola. En la Figura 4.2a se representa el sistema en la fase pasivo. La circunferencia representa el recurso. El elemento de q que est a dentro de la circunferencia
205
representa la entidad que ha capturado el recurso, es decir, la entidad que est a siendo procesada. Al llegar las n nuevas entidades, estas se almacenan en q . El nuevo valor de q es entonces {x1, x2, . . . , xn}. Se supone que el primer elemento de q (en este caso, x1) es el que captura el recurso, el cual pasa a la fase activo (v ease la Figura 4.2b). Se asigna el valor a la variable , que almacena el tiempo hasta la pr oxima transici on interna en ausencia de eventos externos.

Figura 4.2: Entidades en el proceso: a) antes; y b) despu es de la llegada de los eventos x1, . . . , xn.
Si el proceso se encuentra en la fase activo, entonces q contiene al menos un elemento: la entidad que tiene el recurso capturado. Adem as, contendr a las entidades que se encuentran esperando en la cola. En la Figura 4.3a se muestra un ejemplo de esta situaci on, en el cual q contiene los elementos {y 1, . . . , ym}, y la entidad y 1 tiene el recurso capturado. Las nuevas entidades, {x1, x2, . . . , xn}, deben a nadirse al nal de la cola (v ease la Figura 4.3b). Esta concatenaci on de los nuevos elementos tras los ya existentes en q se representa: q {x1, x2, . . . , xn}. El s mbolo representa la concatenaci on.
%& % $ !" #" %& % $
Figura 4.3: Entidades en el proceso: a) antes; y b) despu es de la llegada de los eventos x1, . . . , xn.
206
DEVS PARALELO
Funci on de transici on interna La funci on de transici on interna es invocada cuando se termina de procesar una entidad. Se dene de la forma siguiente: (pasivo, , ) (activo, , q ) si q = si q =
int (activo, , v q ) =
(4.8)
donde se supone que la variable de estado q , que se pasa como argumento a la funci on int , est a compuesta por la concatenaci on del elemento v , que es aquel cuyo proceso acaba de nalizar, y de la cola q . Es decir, q = v q . El estado del sistema tras la transici on interna depende de si q contiene o no elementos, es decir, de si hay o no otras entidades en el proceso aparte de la que tiene el recurso capturado (que es v ). Si q no contiene ning un elemento, signica que el proceso s olo contiene una entidad: aquella que acaba de terminar de ser procesada. Esta entidad abandona el proceso, con lo cual el proceso queda vac o de entidades: q = . El recurso queda tras la transici on interna en la fase pasivo y el tiempo hasta la siguiente transici on interna, en ausencia de eventos externos, es innito: = . En este caso, el nuevo estado es: (pasivo, , ). Si q contiene alg un elemento, signica que hay entidades en la cola del proceso esperando a que el recurso quede libre para capturarlo. En este caso, la entidad que ten a el recurso capturado lo libera y abandona el proceso: q pasa de valer v q a valer q , es decir, la entidad v abandona el proceso. La primera entidad de la cola captura el recurso, que sigue en la fase activo. El tiempo hasta la siguiente transici on interna, en ausencia de eventos externos, es igual al tiempo de proceso: = . En consecuencia, el nuevo estado es: (activo, , q ).
Funci on de transici on conuyente La funci on de transici on conuyente es la siguiente: con s, xb = ext int (s), 0, xb (4.9)
207
la cual indica que en caso de que llegue una bolsa de eventos externos en el preciso instante en que est a planicada una transici on interna, entonces en primer lugar se ejecutar a el evento interno y a continuaci on se ejecutar an los eventos externos. Para evaluar la funci on con se procede de la forma siguiente: 1. En primer lugar, se calcula el estado resultante del evento interno, que viene dado por int (s). Este estado es transitorio, ya que sobre el se produce en ese mismo instante la transici on externa. 2. El estado resultante del evento externo se calcula pasando como par ametros a la funci on ext : El estado transitorio calculado anteriormente, int (s). El tiempo desde la anterior transici on, que es igual a cero, ya que acaba de producirse la transici on interna. La bolsa de eventos externos, xb . Otra posibilidad ser a que se ejecutara primero el evento externo y a continuaci on el interno. En este caso, la funci on de transici on conuyente ser a: con s, ta(s), xb = int ext s, ta(s), xb (4.10)
En general, no es necesario expresar con en t erminos de las funciones de transici on interna o externa. Puede denirse con independientemente de aquellas dos funciones, de modo que exprese circunstancias especiales que ocurren cuando est an planicadas para el mismo instante de tiempo una transici on interna y una externa.
Funci on de salida La funci on de salida es la siguiente: (activo, , v q ) = v (4.11)
donde nuevamente se supone que la variable de estado q est a compuesta por la concatenaci on del elemento v , que es aquel cuyo proceso acaba de nalizar, y de la cola q . Es decir, q = v q . El valor del evento de salida es v . Todo esto es equivalente a decir que el valor del evento de salida es igual al primer componente almacenado en q .
208
DEVS PARALELO
Funci on de avance del tiempo La funci on de avance del tiempo es la siguiente: ta (f ase, , q ) = (4.12)
4.3.
MODELOS COMPUESTOS
Los modelos acoplados DEVS paralelo se especican de la misma forma que los modelos DEVS cl asico, con la diferencia de que en el formalismo DEVS paralelo la funci on select se omite. Recu erdese que en el formalismo DEVS cl asico la funci on select establece la prioridad de ejecuci on de los eventos cuando varios componentes tienen planicados eventos internos en un mismo instante de tiempo. En DEVS cl asico, cuando varios eventos est an planicados para el mismo instante, se escoge uno de ellos para su ejecuci on. En contraste, en DEVS paralelo no se decide qu e evento ejecutar en primer lugar, sino que todos los eventos internos planicados para un mismo instante son ejecutados simult aneamente. Para poder entender correctamente el tratamiento de los eventos, recu erdese que la ejecuci on de un evento interno, suponiendo que el sistema se encuentra en el estado s1 , consta de los tres pasos descritos a continuaci on: Paso 1 Se asigna el tiempo transcurrido desde la u ltima transici on: e = ta(s1 ). Paso 2 Se genera un evento de salida, cuyo valor viene dado por (s1 ). Paso 3 Se realiza la transici on interna del estado. El estado del sistema pasa de ser s1 a ser s2 = int (s1 ). Teniendo presente lo anterior, supongamos que los eventos internos de varios componentes est an planicados para un mismo instante de tiempo. El procedimiento de ejecuci on en DEVS paralelo es el siguiente: 1. En cada componente que tiene planicado un evento interno, se realiza el Paso 1 y el Paso 2 del tratamiento del evento. En particular, en el Paso 2 se genera el correspondiente evento de salida. Por el momento no se ejecuta el Paso 3, que es la transici on interna del estado, sino que se mantiene la planicaci on, para este mismo instante, de la transici on interna.
209
2. Estos eventos de salida se propagan a trav es de las conexiones entre componentes, convirti endose en eventos de entrada. 3. En cada componente al que llega un evento de entrada, se planica una transici on externa del estado para ese mismo instante. 4. En los componentes que tienen una u nica transici on planicada, ya sea interna o externa, no existe ambig uedad respecto al orden en el cual realizar las transiciones, ya que s olo hay una. En los componentes en los cuales hay planicada una transici on interna del estado y una externa, se usa la funci on de transici on conuyente del componente para decidir cu al de ellos se realiza antes. Ejemplo 4.3.1. Para ilustrar la diferencia entre el tratamiento de los eventos realizado en DEVS cl asico y en DEVS paralelo, vamos a retomar el Ejemplo 3.4.1. En dicho ejemplo se analizaba, desde la perspectiva de DEVS cl asico, el establecimiento de prioridades para la ejecuci on de los eventos cuando hay varios eventos internos planicados para un mismo instante. El sistema bajo estudio era la conexi on en cadena de tres procesos mostrada en la Figura 4.4.
pipeline
Figura 4.4: Pipeline compuesta por tres etapas, descrita en la Secci on 3.4.1.
Supongamos que los componentes p0 y p1 tienen planicados sendos eventos internos para un mismo instante de tiempo. El evento interno de p0 genera un evento de salida de p0 , que es un evento de entrada para p1 . En DEVS cl asico, el dise nador del modelo debe decidir qu e hacer respecto al orden en que se disparan estos dos eventos internos: 1. Si se ejecuta primero el evento interno de p1 , el componente p1 pasa de activo a pasivo, con lo cual, cuando a continuaci on se ejecute el evento externo, p1 est a en disposici on de aceptar la entidad proveniente de p0 . 2. Si se dispara primero el evento interno de p0 y el evento externo de p1 , la entidad que llega a p1 encuentra que este est a en la fase activo, con lo cual el evento de entrada es ignorado. A continuaci on, se dispara el evento interno
210
DEVS PARALELO
de p1 , pasando este componente de activo a pasivo y quedando, por tanto, en la fase pasivo. En DEVS cl asico, aplicando la funci on select se determina el orden en que deben ejecutarse los eventos internos simult aneos. En el Ejemplo 3.4.1 la funci on select establec a que si hay dos eventos planicados para el mismo instante en los componentes p0 y p1 , entonces el evento asociado al componente de mayor ndice, que en este caso es p1 , se dispara en primer lugar. As pues, se vericar a la primera de las dos opciones anteriores. Obs ervese que en DEVS cl asico, cuando varios eventos est an planicados para el mismo instante, s olo uno de ellos es escogido para su ejecuci on. En contraste, en DEVS paralelo todos los eventos internos planicados para un mismo instante son ejecutados simult aneamente: 1. Se generan los eventos de salida de los componentes p0 y p1 . 2. El evento de salida de p0 es un evento de entrada de p1 . 3. El componente p0 tiene planicada una transici on interna del estado, que puede realizarse sin ambig uedades. El componente p1 tiene planicada una transici on interna y una externa. Se usa la funci on de transici on conuyente del componente p1 para decidir cu al de las dos transiciones del estado se ejecuta en primer lugar. Si esta funci on realiza primero la transici on interna y a continuaci on la externa, entonces en primer lugar la entidad cuyo proceso ha nalizado libera el recurso, el cual queda en fase pasivo y puede ser capturado por la nueva entidad.
211
4.4.
Ejercicio 4.1 Modique el modelo DEVS paralelo del proceso con una cola FIFO, de modo que la cola tenga una capacidad m axima, Nmax . Mientras la cola tiene su tama no m aximo, las entidades que llegan no se a naden al nal de la cola, sino que abandonan inmediatamente el sistema.
Ejercicio 4.2 En la Secci on 3.2.2 se describi o el modelo DEVS cl asico de un sistema acumulador SISO. Ahora se propone modicar este modelo, de manera que tenga dos puertos de entrada, llamados Input y Read, a trav es de los cuales el sistema acepta los valores a almacenar y las solicitudes de generaci on de eventos, respectivamente. Las salidas se producen a trav es del puerto llamado Output. Describa el modelo empleando el formalismo DEVS paralelo. Debe tenerse en cuenta la posibilidad de que el sistema reciba eventos simult aneos en uno o en los dos puertos de entrada. Escoja el criterio que desee para resolver la colisi on entre las transiciones internas y externas.
Ejercicio 4.3 En la Secci on 3.2.3 se describi o un sistema generador de eventos. Suponga que este sistema se modica, de manera que tenga dos puertos de entrada: uno para iniciar la generaci on (puerto Start) y otro para suspenderla (puertoStop). Escriba el modelo DEVS paralelo de este sistema modicado. Tome las decisiones de dise no que considere convenientes, justicando los motivos por los cu ales las ha adoptado.
Ejercicio 4.4 En la Figura 4.5 se muestra una red de conmutaci on. Uno de los componentes de la red de conmutaci on, llamado s0 , es un conmutador. Escriba un modelo DEVS paralelo del conmutador, de modo que pueda aceptar eventos simult aneos en am-
212
DEVS PARALELO
bos puertos de entrada. Asimismo, describa un modelo DEVS paralelo del modelo compuesto de la red de conmutaci on.
213
4.5.
Soluci on al Ejercicio 4.1 El n umero de entidades que se encuentran en el sistema es igual al n umero de entidades que almacena la variable q . Llamaremos length(q ) a dicho n umero, que es la suma de la entidad que est a en proceso m as las entidades que esperan en la cola. El valor length(q ) no puede superar el valor Nmax . Supongamos que en un determinado instante de tiempo se produce un evento en el puerto In, en el cual se produce la llegada de las entidades x1 , , xn . Hay dos posibilidades: 1. Si length(q )+ n Nmax , entonces todas las entidades que llegan son admitidas en el sistema y el n umero de entidades pasar a a ser length(q ) + n. 2. Si length(q ) + n > Nmax , entonces de las n entidades que han llegado, Nmax length(q ) son admitidas en el sistema y las restantes length(q ) + n Nmax abandonan inmediatamente el sistema. En determinadas aplicaciones es necesario distinguir entre las entidades que abandonan el sistema nada m as llegar y las que abandonan el sistema tras ser procesadas normalmente. Por ello, denimos dos puertos de salida (v ease la Figura 4.6): Out: entidades que abandonan el sistema tras ser procesadas. Balk: entidades que no pueden ser aceptadas en el sistema por haberse superado la capacidad m axima del mismo.
In
Out Balk
Figura 4.6: Diagrama del modelo.
Los puertos de entrada y salida, y los posibles valores de los eventos en estos puertos son los siguientes: XM = { (In, R)} YM = { (Out, R), (Balk , R) }
(4.13)
214
DEVS PARALELO
El modelo tiene cinco variables de estado. Tres de ellas son las ya descritas en la versi on anterior del modelo: f ase, , y la variable q , que almacena las entidades que se encuentran en el sistema. En este caso, la variable de estado f ase puede tomar tres valores: pasivo, activo y balking. Las otras dos variables de estado son las siguientes: La variable de estado p almacena el tiempo que debe transcurrir hasta que termine de ser procesada la entidad que se encuentra en proceso. La variable de estado qbalking almacena las entidades que deben abandonar el sistema por haberse superado su capacidad m axima. La utilidad de denir la f ase balking, y las variables de estado p y qbalking se explicar a al describir la funci on de transici on externa. Las cinco variables de estado son (f ase, , q, p , qbalking ). El conjunto de estados secuenciales es:
S = {pasivo, activo, balking } R+ 0 {secuencia nita de valores R} R+ 0 {secuencia nita de valores R} Cuando se produce un evento de entrada, en el cual llegan n entidades al sistema (x1 , , xn ), puede darse una de las cuatro situaciones siguientes: 1. El sistema est a en la f ase pasivo, con lo cual no hay ninguna entidad en el sistema (q = ), y adem as el n umero de entidades que llega (n) es menor o igual que la capacidad m axima (Nmax ). En este caso, f ase pasa a valer activo, las n entidades se almacenan en la variable q , y se programa una transici on interna, que suceder a transcurridas unidades de tiempo. Para ello, el valor de pasa a ser . Este es el tiempo que se tarda en procesar una de las entidades reci en llegadas. Ninguna de las entidades que han llegado debe ser expulsada inmediatamente, con lo cual qbalking = . El nuevo estado es: (activo, , {x1 , . . . , xn }, , ) 2. El sistema est a en la f ase pasivo y adem as el n umero de entidades que llega (n) es mayor que Nmax .
215
En este caso, las n entidades que han llegado se dividen en dos grupos. El primer grupo, compuesto por Nmax entidades, se almacena en la variable q . El segundo grupo, compuesto por n Nmax entidades, deben abandonar inmediatamente el sistema, con lo cual se almacena en la variable qbalking . La forma de que estas entidades abandonen el sistema es forzar inmediatamente una transici on interna. Para ello, se asigna a la variable de estado el valor cero. Esta fase transitoria del sistema, intermedia entre la llegada de entidades y la salida de las que exceden de la capacidad m axima, est a denida mediante el valor balking de la variable de estado f ase. Puesto que cuando se produce el evento de entrada no hay ninguna entidad en proceso, el tiempo que tardar a en procesarse la entidad es . En consecuencia, el estado resultante de la transici on externa es: (balking , 0, {x1 , . . . , xNmax }, , {xNmax +1 , . . . , xn }) 3. El sistema est a en la f ase activo (equivalentemente, q = ) y adem as el n umero de entidades que llega es menor o igual que Nmax length(q ). Es decir, el n umero de entidades que se encuentran en el sistema (length(q )), m as el n umero de entidades que llegan (n), no superan la capacidad m axima del sistema (Nmax ). En este caso, la fase del sistema no cambia: sigue siendo activo. Las entidades reci en llegadas se a naden a q , que pasa a valer: q {x1 , , xn }. Ninguna de las entidades reci en llegadas debe ser expulsada del sistema: qbalking = . El tiempo restante hasta que nalice el proceso de la entidad que se encuentra actualmente en proceso es: e. El estado resultante de la transici on externa es: (activo, e, q {x1 , . . . , xn }, e, ) 4. El sistema est a en la f ase activo y adem as el n umero de entidades que llega es mayor que Nmax length(q ). En este caso, parte de las entidades se a naden a q , de modo que el sistema alcance su capacidad m axima, y el resto de entidades debe abandonar el sistema.
216
DEVS PARALELO
Este caso es el que justica la introducci on de la variable de estado p , en la cual se almacena el tiempo que queda para completar el proceso de la entidad que actualmente se encuentra en proceso: p = e. Puesto que algunas de las entidades reci en llegadas deben abandonar el sistema, el modelo pasa a la f ase balking y pasa a valer cero. El estado resultante de la transici on externa es: (balking , 0, q {x1 , . . . , xNmax length(q) }, e, {xNmax length(q)+1 , . . . , xn }) La denici on formal de la funci on de transici on externa, en la que se contemplan las cuatro posibles situaciones descritas anteriormente, es la siguiente:
Cuando se produce una transici on interna, se realiza una llamada a la funci on de salida. En este modelo, pueden darse dos situaciones, en funci on del valor de la variable de estado fase. 1. Si f ase = activo, la transici on interna implica que ha nalizado el proceso de una entidad y esta debe abandonar el sistema por el puerto Out. En este caso, llamando v al primer elemento de q , la funci on de salida devuelve el valor (Out, v ). 2. Si f ase = balking, la transici on interna corresponde a que parte de las entidades que acaban de llegar al sistema deben abandonarlo, puesto que se ha alcanzado la capacidad m axima del sistema. La variable de estado qbalking almacena las entidades que deben abandonar el sistema. El puerto de salida es Balk. En consecuencia, el valor que devuelve la funci on de salida es: (Out, qbalking ).
ext (f ase, , q, p , qbalking , e, ((In, x1 ), (In, x2 ), . . . , (In, xn ))) = (activo, , {x1 , . . . , xn }, , ) si f ase = pasivo y n Nmax (balking , 0, {x1 , . . . , xNmax }, , {xNmax +1 , . . . , xn }) si f ase = pasivo y n > Nmax (activo, e, q {x1 , . . . , xn }, e, ) si f ase = activo y n (Nmax length(q )) (balking , 0, q {x1 , . . . , xNmax length(q) }, e, {xNmax length(q)+1 , . . . , xn }) si f ase = activo y n > (Nmax length(q ))
217
En consecuencia, la funci on de salida puede describirse de la forma siguiente:
(f ase, , v q , p , qbalking ) =
(Out, v ) (Balk , qbalking )
si f ase = activo si f ase = balking
La funci on de transici on interna determina el cambio en el estado del modelo que se produce en la transici on interna. Al igual que en el caso de la funci on de salida, hay que distinguir dos situaciones: f ase = activo y f ase = balking. El nuevo estado, en cada uno de estos casos, es el siguiente: 1. Si f ase = activo, la transici on interna implica que ha nalizado el proceso de una entidad y esta debe abandonar el sistema. El nuevo estado del sistema depende de si el sistema queda vac o o si, por el contrario, debe comenzar el proceso de otra entidad. Si q = , el sistema queda vac o. El nuevo estado es: (pasivo, , , , ) Si q = , quedan entidades en el sistema, con lo cual una de ellas debe comenzar a ser procesada. El nuevo estado es: (activo, , q , , ) 2. Si f ase = balking, la transici on interna corresponde a que parte de las entidades que acaban de llegar al sistema deben abandonarlo. El nuevo estado es: (activo, p , q, p , ) Obs ervese que se asigna a el valor del tiempo de proceso restante de la entidad que est a actualmente en proceso (p ). Teniendo en cuenta las tres posibles situaciones anteriores, la funci on de transici on interna puede denirse de la forma siguiente:
218
DEVS PARALELO
La funci on de avance en el tiempo devuelve el valor : ta (f ase, , q, p , qbalking ) =
(pasivo, , , , ) si f ase = activo y q = (activo, , q , , ) int (f ase, , v q , p , qbalking ) = si f ase = activo y q = (activo, p , v q , p , ) si f ase = balking
Finalmente, la funci on de transici on conuyente ser a la siguiente. con s, xb = ext int (s), 0, xb (4.14)
Soluci on al Ejercicio 4.2 Tal como se indica en el enunciado del problema, el modelo tiene tres puertos: dos de entrada, llamados Input y Read, y uno de salida, llamado Output. El modelo, descrito mediante el formalismo DEVS paralelo, debe considerar la posibilidad de que lleguen varios eventos simult aneamente a uno o a los dos puertos de entrada. El comportamiento del sistema es el siguiente: Supongamos que el sistema est a en la fase pasivo y llegan simult aneamente n eventos al puerto Input: ( (Input, x1 ), . . . , (Input, xn ) ) Los valores de estos n eventos de entrada son almacenados en una variable de estado llamada almacena: almacena = {x1 , . . . , xn } elimin andose los valores anteriores que pudiera estar almacenando dicha variable de estado.
219
Si el sistema est a en la fase pasivo y llega uno o varios eventos al puerto Read, entonces el sistema cambia a la fase responde. Transcurrido un tiempo , el sistema genera length(almacena) eventos de salida en el puerto Output, correspondientes a los valores almacenados en la variable almacena. Dichos eventos de salida se representan de la forma siguiente: (Output, almacena). Si el sistema est a en la fase pasivo y llegan n eventos al puerto Input ( (Input, x1 ), . . . , (Input, xn ) ) y simult aneamente uno o varios eventos al puerto Read, entonces se guardan los valores de los n eventos del puerto Input en almacena almacena = {x1 , . . . , xn } elimin andose los valores anteriores que pudiera estar almacenando dicha variable de estado. Adem as el sistema cambia a la fase responde. Transcurrido un tiempo , el sistema genera n eventos de salida en el puerto Output, correspondientes a los n valores que contiene la variable almacena. Si el sistema est a en la fase responde y llega uno o varios eventos a cualquiera de los puertos de entrada, dichos eventos son ignorados por el sistema. Los puertos de entrada y salida, y los posibles valores de los eventos en estos puertos son los siguientes: XM = { (Input, R), (Read, R) } YM = { (Output, R) }
(4.15)
El modelo tiene tres variables de estado: f ase, , y almacena. La variable de estado f ase puede tomar dos valores: pasivo y responde. El conjunto de estados secuenciales es:
S = {pasivo, responde} R+ 0 { secuencia nita de valores R } La funci on de transici on externa es:
220
DEVS PARALELO
La funci on de salida, la funci on de transici on interna y la funci on de avance en el tiempo son las siguientes:
ext (f ase, , almacena, e, ((Input, x1 ), . . . , (Input, xn ), (Read, r1), . . . , (Read, rm ))) = (pasivo, e, {x1 , . . . , xn }) si f ase = pasivo y p = Input (responde, , almacena) si f ase = pasivo y p = Read (responde, , {x1 , . . . , xn }) si f ase = pasivo y p = {Input, Read} (responde, e, almacena) si f ase = responde
int (f ase, , almacena) = (pasivo, , almacena) (f ase, , almacena) = (Output, almacena) ta (f ase, , almacena) = Cuando coincide la llegada de eventos externos con el instante en que est a planicada una transici on interna, en este modelo es conveniente que se produzca en primer lugar la transici on interna y a continuaci on se atiendan los eventos de entrada, produciendo la correspondiente transici on externa. De esa forma, en primer lugar se atiende la solicitud de lectura del valor almacenado y a continuaci on se almacenan los eventos de entrada.
con (f ase, , almacena, e, ((Input, x1 ), . . . , (Input, xn ), (Read, r1), . . . , (Read, rm))) = ext (int (f ase, , almacena) , 0, ((Input, x1 ), . . . , (Input, xn ), (Read, r1), . . . , (Read, rm )))
Soluci on al Ejercicio 4.3 Seg un se indica en el enunciado, el modelo tiene dos puertos de entrada (Start y Stop) y uno de salida (Output). Los valores posibles de los eventos en estos puertos son:
221
XM = { (Start, R), (Stop, R) } YM = { (Output, {1}) } Se realizan las hip otesis siguientes acerca del funcionamiento del sistema:
(4.16)
1. La llegada simult anea de varios eventos a un mismo puerto tiene el mismo efecto que si llegara un u nico evento a ese puerto. Es decir, si llega uno o varios eventos al puerto Start, el sistema comienza a generar eventos. Si llega uno o varios eventos al puerto Stop, el sistema deja de generar eventos. 2. La acci on de parada tiene prioridad sobre la acci on de inicio. Es decir, si llegan simult aneamente uno o varios eventos a los dos puertos de entrada, entonces el sistema se comporta como si hubieran llegado eventos u nicamente al puerto Stop. 3. Si en el instante en que est a planicada una transici on interna se recibe uno o varios eventos de entrada, entonces primero se genera el evento de salida y a continuaci on se realiza la acci on (parada o inicio) asociada a los eventos externos. El modelo tiene dos variables de estado: f ase y . La variable de estado f ase puede tomar dos valores: {pasivo, activo}. El conjunto de estados secuenciales es: S = {pasivo, activo} R+ 0 El comportamiento del sistema est a descrito por las siguientes funciones de transici on, de salida y de avance en el tiempo:
b ext f ase, , e, XM
(pasivo, ) (activo, 0)
si p = Stop, o bien p = {Start, Stop} si p = Start
int (f ase, ) = (activo, periodo)

b con f ase, , e, XM
(pasivo, ) si p = Stop, o bien p = {Start, Stop} (activo, periodo) si p = Start
(f ase, ) = 1 ta (f ase, ) =
222
DEVS PARALELO
Supongamos ahora que modicamos la tercera hip otesis que hemos realizado acerca del funcionamiento del sistema, de manera que, cuando se produce conuencia entre la transici on interna y la externa, s olo se genera un evento de salida si la acci on externa es inicio. Si la acci on externa es parar, entonces no se genera el evento de salida. En este caso, el modelo puede denirse empleando tres variables de estado: f ase, puede tomar tres valores: {pasivo, activo, transitorio}. , puede tomar valores reales positivos, incluyendo el cero. enable, puede tomar los valores: {f alse, true}. El conjunto de estados secuenciales es: S = {pasivo, activo, transitorio} R+ 0 {f alse, true} El comportamiento del sistema est a descrito por las siguientes funciones de transici on, de salida y de avance en el tiempo:
b ext S, e, XM
(pasivo, , f alse) si p = Stop o p = {Start, Stop} (transitorio, 0, true) si p = Start (transitorio, 0, true) (activo, periodo, f alse) si f ase = activo si f ase = transitorio
int (S ) =
b con S, e, XM
(pasivo, , f alse) si p = Stop, o p = {Start, Stop} (transitorio, 0, true) si p = Start 1 si enable = true si enable = f alse
(S ) = ta (S ) =
El estado inicial de este modelo ser a: {pasivo, , f alse}.
Soluci on al Ejercicio 4.4 En la Figura 4.7 se muestra la interfaz del modelo de un conmutador. Tiene dos puertos de entrada, InP orts = {in, in1}, y dos puertos de salida, OutP orts =
223
{out, out1}. Obs ervese que puede producirse la llegada simult anea de varios eventos a los puertos de entrada y la generaci on de varios eventos simult aneos en los puertos de salida.
in in1 out
conmutador
out1
Figura 4.7: Modelo DEVS de un conmutador.
El comportamiento del conmutador est a caracterizado por el valor de la variable de estado Sw , que puede ser {true, f alse}. Cada vez que se produce uno o varios eventos simult aneos de entrada, cambia el valor de la variable Sw , el cual determina el funcionamiento del conmutador: Mientras Sw = true, las entidades que llegan al puerto in son enviadas al puerto out. Similarmente, las entidades que llegan al puerto in1 son enviadas al puerto out1. Mientras Sw = f alse, las entidades que llegan al puerto in son enviadas al puerto out1 y las que llegan al puerto in1 son enviadas al puerto out. En ambos casos, se produce un retardo desde la llegada del evento o eventos simult aneos de entrada, y la generaci on del evento o eventos de salida. Este tiempo de proceso es un par ametro del modelo, que llamaremos . Durante este tiempo de proceso, el sistema no responde a los eventos de entrada. El estado del sistema est a caracterizado por las cinco variables de estado siguientes: La variable fase, que puede valer {pasivo, ocupado}. La variable , que puede tomar valores pertenecientes al conjunto R+ 0. Las variables almacena y almacena1 guardan los valores de los eventos de entrada llegados al puerto in y in1, respectivamente. Cada una de estas variables almacena una secuencia nita de valores reales. La variable Sw , que puede tomar valores {true, f alse}.
224
DEVS PARALELO
As pues, el estado del sistema est a caracterizado por las siguientes cinco variables: (f ase, , almacena, almacena1, Sw ). El conjunto de posibles estados viene denido por el producto cartesiano de los posibles valores de cada una de estas variables: S = {pasivo, activo} R+ 0 {Secuencia nita de valores R} {Secuencia nita de valores R} {true, f alse}. La descripci on del sistema es la siguiente: DEVS = X, S, Y, int , ext , , ta donde los conjuntos de entrada y salida son los siguientes: (4.17)
XM = { (p, v ) | p InP orts = {in, in1}, v Xp } , YM = { (p, v ) | p OutP orts = {out, out1}, v Yp } ,
con Xin = Xin1 = R con Yout = Yout1 = R (4.18)
Supongamos que simult aneamente se reciben eventos en los dos puertos de enb b trada. Llamemos Xin a la bolsa de eventos recibida en el puerto in y Xin 1 a la recibida en el puerto in1. Si en alguno de estos puertos no se recibieran eventos, la correspondiente bolsa ser a igual al conjunto vac o. Las funciones de transici on son:
b ext S, e, XM
int (S ) b con S, e, XM
b b activo, , Xin , Xin 1 , !Sw = (f ase, e, almacena, almacena1, Sw ) = (pasivo, , almacena, almacena1, Sw ) b = ext int (S ) , 0, XM
si f ase = pasivo en caso contrario
(4.19) La funci on de salida es:
(S ) =
(out, almacena) , (out1, almacena1) si Sw = true (out, almacena1) , (out1, almacena) si Sw = f alse
(4.20)
Si la bolsa de eventos asociada a un puerto est a vac a, no se produce ning un evento de salida por el correspondiente puerto. Finalmente, la funci on de avance del tiempo es: ta (S ) = (4.21)
225
El modelo de la red de conmutaci on mostrada en la Figura 4.5 es el siguiente. N = X, Y, D, {Md | d D }, EIC, EOC, IC donde: InP orts = {in, in1} Xin = Xin1 = R OutP orts = {out} Yout = R D = { s0 , p0 , p1 } Ms0 = Mconmutador Mp0 = Mp1 = Mrecurso EIC = { ((N, in), (s0 , in)) , ((N, in1), (s0 , in1)) } EOC = { ((p0 , out), (N, out)) , ((p1 , out), (N, out)) } IC = { ((s0 , out), (p0 , in)) , ((s0 , out1), (p1 , in)) }
Puerto de entrada del modelo compuesto. Posibles valores de los eventos en los puertos in e in1 del modelo compuesto. Puerto de salida del modelo compuesto. Posibles valores de los eventos en el puerto out del modelo compuesto. Conjunto de nombres de los componentes. Tipo de los componentes.
(4.22)
Conexiones externas de entrada.
Conexiones externas de salida.
226
TEMA 5 MODELADO H IBRIDO EN DEVS
5.1. Introducci on 5.2. Formalismo DEV&DESS 5.3. Formalismos b asicos y DEV&DESS 5.4. Modelado multiformalismo 5.5. Tratamiento de los eventos en el estado 5.6. Simulador para modelos DESS 5.7. Ejercicios de autocomprobaci on 5.8. Soluciones a los ejercicios
MODELADO H IBRIDO EN DEVS
OBJETIVOS DOCENTES Una vez estudiado el contenido del tema deber a saber: Describir modelos h bridos empleando el formalismo DEV&DESS. Discutir c omo los formalismos b asicos DESS, DTSS y DEVS cl asico pueden ser interpretados como tipos especiales de DEV&DESS. Interpretar la conexi on de componentes de diferentes formalismos. Discutir el algoritmo de la simulaci on de modelos h bridos y DESS.
229
5.1.
INTRODUCCION
Los modelos h bridos son aquellos que tienen una parte de tiempo continuo, y otra parte de eventos discretos y/o tiempo discreto. Una forma de describir este tipo de modelos es mediante la denici on de un nuevo formalismo1 , que combine la especicaci on de modelos de eventos discretos (DEVS cl asico) y la especicaci on de modelos mediante ecuaciones diferenciales (DESS). Este nuevo formalismo, que engloba los dos formalismos originales (DEVS y DESS), recibe el nombre de DEV&DESS (Zeigler et al. 2000). En este tema se describe el modelado empleando dicho formalismo y algunos conceptos de la simulaci on de este tipo de modelos.
5.2.
FORMALISMO DEV&DESS
Como se ha indicado anteriormente, el formalismo DEV&DESS (Discrete Event and Dierential Equation System Specication) permite describir modelos h bridos, combinando para ello los formalismos DEVS cl asico y DESS. En la Figura 5.1 se ilustra el concepto de modelado desarrollado en DEV&DESS.

DEVS

DESS

Figura 5.1: Modelo combinando los formalismos DEVS y DESS.
Los puertos de entrada X discr aceptan eventos, mientras que los puertos de entrada X cont aceptan segmentos continuos a tramos y constantes. Estos u ltimos inuyen sobre la parte continua y discreta del modelo, mientras que los eventos de
1
Abreviaturas usadas para designar los formalismos:
DESS Dierential Equation System Specication DEVS Discrete Event System Specication DTSS Discrete Time System Specication DEV&DESS Discrete Event and Dierential Equation System Specication
231
entrada s olo afectan a la parte discreta del modelo. Cada parte del modelo produce su propia trayectoria de salida: Y discr la parte discreta e Y cont la parte continua. Asimismo, cada una de las partes puede inuir sobre el estado de la otra parte. Se representa S discr y S cont el estado de la parte discreta y continua, respectivamente.
5.2.1.
Detecci on de los eventos en el estado
Un concepto fundamental del modelado h brido es c omo la parte discreta es afectada por la parte continua. Es decir, c omo la parte DESS del modelo puede disparar la ejecuci on de eventos. En la Figura 5.2 se ilustra la forma en que esto se produce. Se asocia a cada tipo de evento una funci on l ogica, denominada condici on de evento, que tiene en general la forma siguiente: expresion > 0. El evento se dispara en el instante preciso en que la condici on de evento asociada pasa de valer false a valer true.

Figura 5.2: Evento en el estado.
En el ejemplo mostrado en la Figura 5.2, la condici on de disparo del evento es que el valor de la variable de tiempo continuo scont alcance determinado valor umbral. La condici on de evento es: scont umbral > 0. En el algoritmo de la simulaci on del modelo, cada condici on de evento es sustituida por una funci on detectora de cruce por cero, de modo que el evento se dispara cuando la funci on pasa de tomar un valor distinto de cero a valer cero, o cuando cruza por cero. Por ejemplo, la condici on de evento scont umbral > 0, es sustituida por la funci on detectora de cruce por cero es: z = scont umbral. Un evento cuya condici on de disparo viene expresada en t erminos de variables de tiempo continuo se denomina evento en el estado. Los eventos de la parte DEVS del modelo, cuya condici on de disparo es que el reloj de la simulaci on alcance determinado valor, se denominan eventos en el tiempo.
232
5.2.2.
Modelos at omicos
En esta secci on se muestra la forma en que se describe un modelo at omico h brido empleando el formalismo DEV&DESS. Por simplicidad, se dene el formalismo sin distinguir entre los eventos en el tiempo y los eventos en el estado. Todos los eventos son tratados como si fueran eventos en el estado. Por ejemplo, pueden planicarse las transiciones internas de la parte DEVS del modelo asociando al evento interno la condici on de evento: e ta(s) > 0, donde e es el tiempo transcurrido desde el u ltimo evento. La funci on de cruce asociada es: z = e ta(s). Si bien esto simplica las explicaciones, no es eciente desde el punto de vista computacional, ya que el simulador debe ir calculando las funciones de cruce durante la integraci on de la parte continua del modelo. Podr a extenderse el formalismo de manera sencilla con el n de considerar los eventos en el tiempo, siguiendo para ello una estrategia para la planicaci on de eventos en el tiempo similar a la que se sigue en DEVS. De acuerdo con el formalismo DEV&DESS, el modelo h brido est a formado por los componentes de la tupla siguiente:
DEV&DESS = X discr , X cont , Y discr , Y cont , S discr , S cont , ext , Cint , int , discr , f, cont (5.1) donde: X discr , Y discr
Conjunto de pares puertovalor, de entrada y salida, del modelo DEVS.
cont X cont = {(xcont , xcont , . . . ) | xcont X1 , . . . } Conjunto de variables de en1 2 1
trada del modelo continuo.

cont cont cont Y cont = {(y1 , y2 , . . . ) | y1 Y1cont , . . . } Conjunto de variables de sali-
da del modelo continuo.
S = S discr S cont
Estado del sistema h brido: producto cartesiano del estado discreto y del estado continuo.
233
ext = Q X cont X discr S
Funci on de transici on externa. Los argumentos de la funci on son las entradas continuas, los eventos de entrada y el estado total del sistema h brido. La funci on devuelve el nuevo estado del sistema h brido.
Q = (sdiscr , scont , e) | sdiscr S discr , scont S cont , e R+ 0
Estado total, donde e es el tiempo transcurrido desde el u ltimo evento.
int :
Q X cont S
Funci on de transici on interna. Funci on de salida de la parte discreta.
discr : Q X cont Y discr cont : Q X cont Y cont f: Q X cont S cont
Funci on de salida de la parte continua. Funci on para el c alculo de la derivada de las variables de estado.
Cint :
Q X cont Boolean
Condiciones de evento.
5.2.3.
Simulaci on de modelos at omicos
Empleando la sem antica del modelo DEV&DESS, puede describirse de manera informal c omo realizar la simulaci on del modelo h brido: 1. Intervalos (t1 , t2 ) sin eventos. Durante los intervalos de tiempo en que no se producen eventos, u nicamente cambia el valor de las variables de estado de cont tiempo continuo, S , el valor de las variables de salida de tiempo continuo, Y cont , y el tiempo transcurrido desde el u ltimo evento, e. El comportamiento continuo del modelo est a especicado por la funci on para el c alculo de las derivadas, f , y por la funci on para el c alculo de las salidas de tiempo continuo, cont .
234
El valor al nal del intervalo (instante t2 ) de las variables de estado continuas se calcula como la suma de su valor al comienzo del intervalo (instante t1 ) m as la integral de la funci on f a lo largo del intervalo. El valor que tiene el tiempo transcurrido, e, al nal del intervalo se calcula incrementando en t2 t1 el valor que tiene e al comienzo del intervalo. 2. Evento en el estado en el instante t del intervalo (t1 , t2 ). Supongamos que en el intervalo (t1 , t) no se produce ning un evento, y que en el instante t, con t1 < t < t2 , la condici on de evento Cint pasa de valer false a valer true. Esto signica que en el instante t se verican las condiciones de disparo de un evento en el estado. Las acciones asociadas son: a ) Se calcula el valor que tienen las variables de estado de la parte continua del modelo en el instante t, justo antes de la ejecuci on del evento. Para ello, se suma el valor que tienen en t1 al valor de la integral sobre (t1 , t) de la funci on derivada, f . Asimismo, se genera la salida continua hasta el instante t, evaluando para ello la funci on cont . b ) Se calcula el valor de e, incrementando en t t1 el valor que tuviera e al comienzo del intervalo. c ) Se ejecuta la funci on de salida de la parte discreta, discr , para generar el evento de salida en el instante t. d ) Se ejecuta la funci on de transici on interna, int (s, e, xcont ), para calcular el nuevo valor de las variables de estado continuas y discretas. e ) Se asigna el valor cero al tiempo transcurrido: e = 0. 3. Evento externo en un puerto de entrada, en el instante t del intervalo (t1 , t2 ). Supongamos que en el intervalo (t1 , t) no se produce ning un evento, y que en el instante t, con t1 < t < t2 , se produce un evento externo en un puerto de entrada de la parte discreta del modelo. Las acciones asociadas son: a ) Se calcula el valor que tienen las variables de estado de la parte continua del modelo en el instante t, justo antes de la ejecuci on del evento. Para ello, se suma el valor que tienen en t1 al valor de la integral sobre (t1 , t) de la funci on derivada, f . Asimismo, se genera la salida de la parte continua del modelo hasta el instante t. b ) Se calcula el valor de e, incrementando en t t1 el valor que tuviera e al comienzo del intervalo. c ) Se ejecuta la funci on de transici on externa, ext , para calcular el nuevo estado en el instante t.
235
d ) Se asigna el valor cero al tiempo transcurrido: e = 0.
5.2.4.
Modelos compuestos
La especicaci on formal de un sistema DEV&DESS compuesto es an aloga a la descrita en la Secci on 3.4 para los modelos acoplados seg un el formalismo DEVS cl asico. Por consiguiente, consiste en la tupla siguiente: N = (X, Y, D, {Md | d D }, EIC, EOC, IC, select) (5.2)
5.2.5.
Proceso de llenado de barriles
En esta secci on se muestra un ejemplo de modelado, empleando el formalismo DEV&DESS, de un proceso de llenado de barriles.
Descripci on informal del funcionamiento del sistema El llenado con l quido de un barril es un proceso continuo, sin embargo, el control del proceso puede modelarse de manera discreta. El control incluye posicionar el barril bajo el grifo, abrir la v alvula en el momento en que debe iniciarse el vertido del l quido y, nalmente, cerrar la v alvula cuando el l quido dentro del barril alcanza un determinado nivel. En la Figura 5.3 se muestra la interfaz y las variables de estado del modelo.
on/off flujoIn

barril cout
Figura 5.3: Modelo del proceso de llenado de barriles.
El modelo tiene un puerto de entrada continuo (ujoIn) y un puerto de entrada discreto (on/o). Tiene un puerto de salida discreto (barril) y un puerto de salida continuo (cout). Asimismo, tiene dos variables de estado:
236
Una continua, llamada (contenido), que representa el volumen de l quido actual del barril. Una discreta, llamada (valvula), que representa el estado de la v alvula y puede tomar los dos valores siguientes: {abierta, cerrada}. La variable de entrada ujoIn representa el ujo volum etrico de l quido que se emplea para llenar el barril. La relaci on que hay entre la variable de entrada ujoIn y la variable de estado contenido es la siguiente: la derivada de la variable de estado contenido es igual a la variable de entrada ujoIn cuando la v alvula est a abierta (valvula = abierta), e igual a cero cuando la v alvula est a cerrada (valvula = cerrada). Es decir: dcontenido = dt f lujoIn 0 si valvula = abierta si valvula = cerrada
(5.3)
La entrada discreta on/o, que s olo puede tomar los valores {on, o}, hace que el modelo conmute entre dos fases: v alvula abierta (valvula = abierta) y v alvula cerrada (valvula = cerrada). El modelo tiene las dos salidas siguientes: La salida cout es una variable de tiempo continuo, cuyo valor coincide con el volumen actual de llenado del barril. El modelo genera un evento de salida de valor barrilDe10litros, a trav es del puerto de salida barril, cada vez que se completa el llenado de un barril. El modelo genera un evento en el puerto de salida barril cada vez que un barril alcanza su nivel m aximo de llenado, es decir, cuando la variable de estado de tiempo continuo contenido alcanza el valor 10 litros. Se trata, por tanto, de un evento en el estado. Cuando un barril se llena, se supone que es reemplazado por otro vac o. Consecuentemente, la variable contenido es puesta a cero. En la Figura 5.4 se muestra el comportamiento del sistema frente a una determinada trayectoria de entrada. Se observa que la entrada on/o condiciona el valor de la variable valvula, la cual, a su vez, determina el comportamiento de la variable contenido: Mientras la v alvula est a abierta, el ujo de entrada llena los barriles (la derivada de contenido es igual a ujoIn).
237
Mientras est a cerrada, el contenido del barril permanece constante (la derivada de contenido es cero). Cuando el contenido del barril alcanza los 10 litros, se genera un evento de salida por el puerto barril y se pone a cero la variable contenido. En todo momento, la variable de salida cout es igual a la variable contenido.

Figura 5.4: Trayectorias del modelo del proceso de llenado de barriles.
Descripci on formal La descripci on formal del modelo es la siguiente:
238
LlenadoBarriles = X discr , X cont , Y discr , Y cont , S discr , S cont , ext , Cint , int , discr , f, cont (5.4) donde la interfaz del modelo est a denida por los siguientes elementos de la tupla:
X cont = {f lujoIn | f lujoIn R} X discr = {on/of f | on/of f {on, o}} Y cont = {cout | cout R} Y
discr
(5.5) (5.6) (5.7) (5.8)
= {barril | barril {barrilDe10litros}}
El estado del sistema est a denido mediante los dos siguientes elementos de la tupla:
S cont = {contenido | contenido R} S

discr
(5.9) (5.10) modelo en eventos de funci on de en funci on
= {valvula | valvula {abierta, cerrada}}
La funci on de transici on externa dene c omo cambia el estado del funci on de las entradas al modelo, tanto las de tiempo discreto (los entrada) como las entradas de tiempo continuo. En este modelo, la transici on externa determina el valor de la variable de estado valvula del valor del evento de entrada recibido a trav es del puerto on/o: ext ((contenido, valvula), e, f lujoIn, on/of f ) : if on/of f = on then valvula := abierta if on/of f = o then valvula := cerrada
(5.11)
La condici on que determina el disparo del evento en el estado es que el volumen de l quido en el barril alcance el valor 10 litros. La condici on de evento es: Cint ((contenido, valvula), e, f lujoIn) : contenido > 10
(5.12)
239
Cuando se dispara un evento en el estado, se eval ua la funci on de transici on interna con el n de calcular el nuevo estado. En este modelo, el evento pone a cero la variable contenido (el barril lleno es reemplazado por otro vac o) y no modica el valor de la variable valvula. int ((contenido, valvula), e, f lujoIn) : contenido = 0
(5.13)
Como parte de las acciones asociadas a una transici on interna, se eval ua la funci on discr de salida discreta, , con el n de calcular el valor del evento de salida. En este modelo, cuando se produce el evento en el estado, se genera un evento en el puerto de salida barril cuyo valor es siempre el mismo: barrilDe10litros. La funci on de salida de la parte discreta del modelo es:
discr ((contenido, valvula), e, f lujoIn) : Genera evento de valor barrilDe10litros en el puerto barril
(5.14)
La funci on f , de c alculo de las derivadas de las variables de estado de tiempo continuo, es la siguiente: f ((contenido, valvula), e, f lujoIn) : = f lujoIn if valvula = abierta then dcontenido dt dcontenido =0 if valvula = cerrada then dt
(5.15)
Finalmente, la funci on de salida de la parte continua del modelo, cont , permite calcular la variable de salida cout, cuyo valor es igual en todo momento al valor de la variable de estado contenido: cont ((contenido, valvula), e, f lujoIn) : cout = contenido
(5.16)
5.3.
FORMALISMOS BASICOS Y DEV&DESS
En esta secci on veremos c omo los formalismos b asicos DESS, DTSS y DEVS cl asico pueden ser interpretados como tipos especiales de DEV&DESS. Esta in-
240
terpretaci on nos permitir a, cuando en la pr oxima secci on denamos los modelos DEV&DESS modulares y jer arquicos, realizar modelos acoplados multiformalismo.
5.3.1.
Formalismo DESS
Es posible especicar un modelo DESS (Dierential Equation System Specication) mediante el formalismo DEV&DESS. Para ello, basta con omitir toda la parte relativa a eventos del formalismo DEV&DESS. Con el n de justicar la armaci on anterior, en primer lugar analizaremos cu al es la denici on formal de un modelo de acuerdo al formalismo DESS. Un modelo descrito mediante el formalismo DESS es la tupla siguiente: DESS = (Xdess , Ydess , Qdess , fdess , dess ) donde: Xdess Ydess Qdess fdess : Qdess Xdess Qdess dess : Qdess Ydess dess : Qdess Xdess Ydess
Conjunto de entradas. Conjunto de salidas. Conjunto de estados. Funciones para el c alculo de las derivadas.
dq dt
(5.17)
= fdess (q, x)
Funci on de salida tipo Moore. La salida es funci on del tiempo y del estado: dess (q ). Funci on de salida tipo Mealy. La salida es funci on del tiempo, del estado y de la entrada: dess (q, x).
Las entradas, salidas y variables de estado son variables reales de tiempo continuo. As pues, Xdess , Ydess y Qdess son los espacios vectoriales Rm , Rp y Rn respectivamente. La funci on de salida puede ser o bien de tipo Moore, o bien de tipo Mealy. El modelo DESS descrito anteriormente constituye un tipo especial de modelo DEV&DESS,
241
DEV&DESS = X discr , X cont , Y discr , Y cont , S discr , S cont , ext , Cint , int , discr , f, cont (5.18) donde:
X cont = Xdess Y cont = Ydess S cont = Qdess f = fdess cont = dess y toda la parte relativa a los eventos es omitida:
(5.19) (5.20) (5.21) (5.22) (5.23)
X discr = {} Y discr = {} S discr = {} int ((s, e), x ext ((s, e), x discr ((s, e), x
cont cont
(5.24) (5.25) (5.26) (5.27) (5.28) (5.29) (5.30)
) = s ) = s ) =
cont
Cint ((s, e), xcont ) = f alse
5.3.2.
Formalismo DTSS
Puede obtenerse un modelo DEV&DESS que es equivalente a un modelo DTSS empleando la variable e, que representa el tiempo transcurrido desde el u ltimo evento, para planicar las transiciones en el estado a intervalos de tiempo constantes h. Cuando el tiempo transcurrido desde el u ltimo evento alcanza el valor h, entonces la condici on de evento del modelo DEV&DESS, denida como Cint : e h, pasa de valer false a valer true, y se dispara un evento interno. La funci on de transici on interna del modelo DEV&DESS debe describirse de tal manera que el estado resultante sea el especicado en el modelo DTSS equivalente. Recu erdese que el valor de
242
e se pone a cero en el modelo DEV&DESS como parte de las acciones asociadas a una transici on interna. Las ideas anteriores pueden expresarse de manera formal. Para hacerlo, en primer lugar analizaremos cu al es la denici on formal de un modelo DTSS. Un modelo DTSS est a compuesto por la tupla siguiente: DTSS = (Xdtss , Ydtss , Qdtss , dtss , dtss , hdtss ) donde: Xdtss Ydtss Qdtss : Qdtss Xdtss Qdtss dtss : Qdtss Ydtss dtss : Qdtss Xdtss Ydtss
Conjunto de entradas. Conjunto de salidas. Conjunto de estados. Funci on de transici on de estados. Funci on de salida tipo Moore. La salida es funci on del tiempo y del estado: dess (q ). Funci on de salida tipo Mealy. La salida es funci on del tiempo, del estado y de la entrada: dess (q, x).
(5.31)
hdtss
Paso de avance en el tiempo.
El modelo DTSS descrito anteriormente constituye un tipo especial de modelo DEV&DESS,
DEV&DESS = X discr , X cont , Y discr , Y cont , S discr , S cont , ext , Cint , int , discr , f, cont (5.32) donde: X discr = Xdtss Y discr = Ydtss S discr = Qdtss {hdtss } X cont = {} Y cont = {} S cont = {}
(5.33)
La condici on de evento se dene de la forma siguiente: Cint ((qdtss , h), e, xcont ) : eh (5.34)
243
La funci on de transici on interna del modelo DEV&DESS se construye, a partir de la funci on de transici on interna del modelo DTSS, de la forma siguiente: int ((qdtss , h), e, xcont ) = (dtss (qdtss , xdtss ), h) La funci on de salida discreta se construye de la forma siguiente: (5.35)
discr ((qdtss , h), e, xcont ) =
dtss (qdtss , xdtss ) dtss (qdtss )
para sistemas de tipo Mealy para sistemas de tipo Moore (5.36)
La funci on para el c alculo de las derivadas, f , y la funci on de salida continua, , son omitidas:
cont
f : Q X cont {} cont : Q X cont {}
(5.37) (5.38)
5.3.3.
Formalismo DEVS cl asico
De forma similar a como se ha hecho con el formalismo DTSS, a continuaci on describimos un procedimiento para describir un modelo DEVS cl asico empleando el formalismo DEV&DESS. En particular, empleamos la variable e, que es el tiempo transcurrido desde el u ltimo evento y la condici on de evento, que dene la condici on de disparo de los eventos en el estado, para planicar los eventos internos. La condici on de evento pasa de valer false a valer true en el instante en que el reloj de la simulaci on alcanza el instante en que est a planicado el siguiente evento interno del modelo DEVS. El modelo DEVS DEVS = Xdevs , Sdevs , Ydevs , int,devs , ext,devs , devs , tadevs puede expresarse empleando el modelo DEV&DESS siguiente (5.39)
244
DEV&DESS = X discr , X cont , Y discr , Y cont , S discr , S cont , ext , Cint , int , discr , f, cont (5.40) de la forma siguiente: X discr = Xdevs Y discr = Ydevs S discr = Qdevs X cont = {} Y cont = {} S cont = {}
(5.41)
La condici on de evento, Cint , del modelo DEV&DESS se dene de la forma siguiente: Cint (sdevs , e) : e tadevs (sdevs ) (5.42)
La funci on de transici on interna del modelo DEV&DESS, int : Q X cont S , se construye a partir de la funci on de transici on interna del modelo DEVS: int ((sdevs , e)) = int,devs (sdevs ) (5.43)
La funci on para el c alculo de las derivadas, f , y la funci on de salida continua, , son omitidas:
cont
f : Q X cont {} cont : Q X cont {}
(5.44) (5.45)
5.4.
MODELADO MULTIFORMALISMO
Como hemos visto en la secci on anterior, los modelos DESS son un caso especial de modelo DEV&DESS. Tambi en hemos visto c omo embeber DEVS o DTSS en DEV&DESS. Por tanto, podemos usar un formalismo b asico (DESS, DEVS y DTSS) all donde usemos el formalismo DEV&DESS y, sacando partido de esta capacidad, si somos capaces de construir modelos compuestos DEV&DESS, podemos construir modelos compuestos multiformalismo, cuyos componentes representen modelos de tiempo continuo, de tiempo discreto y de eventos discretos.
245
En esta secci on se analizar a c omo se interpreta la conexi on entre componentes de diferente formalismo. Para ello, es fundamental la interpretaci on del acoplo entre las salidas de tiempo discreto (eventos) y las entradas de tiempo continuo (variables de tiempo continuo), y viceversa. En la Figura 5.5 se muestran las trayectorias t picas de salida a las que da lugar cada uno de los tres formalismos b asicos. Obs ervese que una trayectoria de salida constante a tramos (v ease la Figura 5.5a) es un caso particular de salida de tiempo continuo (v ease la Figura 5.5b) del formalismo DESS. Las trayectorias E/S de los formalismos DEVS y DTSS son eventos (v eanse las Figuras 5.5c & 5.5d). En el caso del formalismo DTSS, el intervalo de tiempo entre eventos consecutivos es un par ametro h caracter stico del modelo.
DESS

DESS

DTSS

DEVS

Figura 5.5: Trayectorias de salida de los formalismos b asicos.
Puesto que las trayectorias de eventos pueden ser traducidas a trayectorias constantes a tramos y viceversa, tenemos una forma de interpretar la conexi on entre salidas discretas y entradas continuas, y tambi en la conexi on entre salidas continuas constantes a tramos y entradas discretas. A continuaci on, vamos a analizar los diferentes tipos de conexi on entre componentes de diferente formalismo. DTSS DEVS. Al conectar un puerto de salida de un modelo DTSS con un puerto de entrada de un modelo DEVS, los eventos de salida del modelo DTSS, generados a intervalos regulares de tiempo, son interpretados como eventos de
246
entrada por el modelo DEVS. En la Figura 5.6 se muestra una trayectoria t pica de salida del modelo DTSS, la cual puede ser interpretada tal cual por el modelo DEVS.
DTSS

DEVS
Figura 5.6: Conexi on DTSS DEVS.
DEVS DTSS. En general, los eventos de salida del modelo DEVS no se producen de manera peri odica. La forma de traducir estos eventos de salida a una secuencia de entrada eventos equiespaciados en el tiempo es la siguiente: el evento de entrada se construye a partir del u ltimo evento de salida. En la Figura 5.7 se han dibujado de color rojo los eventos de salida del modelo DEVS y en color azul los eventos de entrada correspondientes del modelo DTSS.
DEVS

DTSS
Figura 5.7: Conexi on DEVS DTSS.
DEVS DESS. Se considera que los eventos de salida del modelo DEVS denen los cambios en la trayectoria de entrada, constante a tramos, del modelo DESS. En la Figura 5.8 se muestra un ejemplo. En rojo est an dibujados los eventos de salida y en azul la correspondiente trayectoria de tiempo continuo de entrada.
DEVS
DESS
Figura 5.8: Conexi on DEVS DESS.
247
DESS DEVS. La salida del modelo DESS es una trayectoria de tiempo continuo constante a tramos. Los cambios en los valores constantes de la trayectoria se interpretan como eventos de entrada al modelo DEVS. En la Figura 5.9 se muestra la trayectoria constante a tramos de salida en color azul y la correspondiente trayectoria de eventos en rojo.
DESS
DEVS
Figura 5.9: Conexi on DESS DEVS.
DTSS DESS. Los eventos equiespaciados en el tiempo que constituyen la trayectoria de salida del modelo DTSS son interpretados como una trayectoria constante a tramos por el modelo DESS. El valor del tramo constante de la trayectoria de entrada es igual al del u ltimo evento de salida. Se muestra un ejemplo en la Figura 5.10, donde los eventos son representados en rojo y la trayectoria de tiempo continuo en azul.
DTSS

DESS
Figura 5.10: Conexi on DTSS DESS.
DESS DTSS. La trayectoria de salida de tiempo continuo del modelo DESS es muestreada, con periodo h, a n de convertirla en una trayectoria de eventos equiespaciados en el tiempo. En la Figura 5.11 se muestra la trayectoria de salida de tiempo continuo, dibujada en azul, y los eventos, dibujados en rojo, que son obtenidos de muestrear la trayectoria continua con periodo h.
248
DESS

DTSS
Figura 5.11: Conexi on DESS DTSS.
5.5.
TRATAMIENTO DE LOS EVENTOS EN EL ESTADO
El estado de un sistema h brido evoluciona mediante el cambio continuo de sus estados continuos o mediante cambios instant aneos en su estado total, continuo y discreto, llamados eventos. Durante la ejecuci on de la simulaci on de un modelo h brido se realiza, o bien una simulaci on enteramente de eventos discretos o bien una simulaci on enteramente continua, ya que la ejecuci on de una simulaci on simult aneamente continua y discreta no existe. Por ello, el simulador de modelos h bridos debe estar compuesto de un simulador de eventos discretos, un simulador de sistemas continuos, y algoritmos describiendo las actividades a realizar cuando se pasa de la simulaci on de eventos discretos a la de sistemas continuos y viceversa. La principal extensi on necesaria para simular modelos h bridos es el tratamiento de los eventos en el estado, que incluye: 1. La detecci on de los eventos en el estado. Se realiza vigilando, durante la simulaci on de la parte continua del modelo, las funciones de cruce por cero asociadas a los eventos en el estado. Cuando una funci on de cruce pasa a valer cero o corta el cero, se suspende la soluci on del problema continuo y se realiza el tratamiento del evento correspondiente. En la Figura 5.12 se muestra la evoluci on temporal de una funci on de cruce por cero. La parte continua del modelo se calcula en el instante ti , incluyendo la evaluaci on de la funci on de cruce, cuyo valor positivo indica que no se satisfacen las condiciones para el disparo del evento. A continuaci on, se avanza un paso de tiempo, cuya longitud ti+1 ti est a determinada por el algoritmo de integraci on. Se eval ua la parte continua del modelo en el instante ti+1 , obteni endose que la funci on de cruce tiene un valor negativo. Esto signica que en alg un instante entre ti y ti+1 se ha satisfecho la condici on de disparo del evento, es decir, la funci on de cruce se ha hecho cero.
249

+ !"#$ % & $ +

Figura 5.12: Detecci on de evento en el estado mediante funci on de cruce.
2. Se determina, con una precisi on inferior a una determinada, el instante de disparo del evento, que es aquel en el cual la funci on de cruce pasa a valer cero o corta el cero. Para ello, pueden usarse varios m etodos, entre los cuales se encuentra el de la bisecci on. Este m etodo consiste en ir dividiendo el intervalo por la mitad y determinando en cu al de las dos mitades se produce el cruce por cero. La mitad en la que se produce el cruce se divide a su vez por la mitad y se determina en cu al de las dos mitades se produce el cruce, y as sucesivamente. 3. Se planican los eventos para su ejecuci on. 4. La ejecuci on de los eventos es id entica a la ejecuci on de los eventos internos en DEVS.
5.6.
SIMULADOR PARA MODELOS DESS
El problema fundamental de la simulaci on de modelos de tiempo continuo es c omo calcular un comportamiento de tiempo continuo mediante pasos de tiempo discretos. La principal forma de realizarlo es mediante el empleo de los m etodos de integraci on num erica. Los m etodos de integraci on num erica pueden clasicarse en dos grupos: causales y no causales.
5.6.1.
M etodos num ericos de integraci on causales
Los m etodos causales usan el valor de los estados en el pasado y en el presente para calcular el valor del estado en el instante de tiempo futuro. Normalmente, los
250
m etodos de integraci on causales calculan el valor del estado en el instante ti+1 como una combinaci on lineal de los valores del estado y de la derivada en m instantes de tiempo anteriores, tim , tim+1 , . . . , ti . Los coecientes de la combinaci on lineal son escogidos de tal manera que se minimice el error en la estimaci on. Un ejemplo de m etodo causal es el m etodo de integraci on de Euler expl cito, descrito en la Secci on 2.3.4. La forma general de un m etodo causal que usa m valores pasados de la derivada y del estado para calcular el estado en el instante de tiempo ti+1 es la siguiente: q (ti+1 ) = M etodoCausal( q (tim ), . . . , q (ti ), r (tim ), . . . , r (ti ), x(tim ), . . . , x(ti ), t)
(5.46)
donde q representa las variables de estado, r las derivadas de las variables de estado, x las entradas y t el tama no del paso de integraci on (ti+1 = ti + t). Un problema general en los m etodos de integraci on causales es el arranque. Consiste en la determinaci on de la derivada y el estado en los instantes de tiempo tm , tm+1 , . . . , t0 , que deben conocerse para poder calcular q (t1 ). Una soluci on al problema del arranque es usar m etodos causales de menor orden en el arranque. Es decir, en el primer paso de integraci on, s olo se dispone del valor inicial, con lo cual se usa un m etodo de orden uno. En los siguientes pasos de integraci on, el orden del m etodo va aument andose hasta alcanzar el orden m. Otra soluci on al problema del arranque es emplear un m etodo de integraci on diferente durante la fase de arranque, por ejemplo, un m etodo no causal como los descritos en la Secci on 5.6.2. Un algoritmo para la simulaci on de modelos DESS at omicos, empleando un m etodo de integraci on causal, es el siguiente:
Dess-causal-simulator variables: DESS = (X, Y, Q, f, lambda) // Modelo asociado [q(t_{i-m}), ..., q(t_{i})] // Vector de valores pasados del estado [r(t_{i-m}), ..., r(t_{i})] // Vector de valores pasados de la derivada [x(t_{i-m}), ..., x(t_{i})] // Vector de valores pasados de la entrada h // Paso de integraci on when recibe mensaje-i (i,t_{i}) en el instante t_{i} { inicializa [q(t_{i-m}), ..., q(t_{i})], [r(t_{i-m}), ..., r(t_{i})], [x(t_{i-m}), ..., x(t_{i})]
251
mediante el procedimiento del m etodo de integraci on } when recibe mensaje-* (*,t_{i}) en el instante t_{i} { y = lambda( q(t_{i}) ) envia mensaje-y (y,t_{i}) a parent } when recibe mensaje-x (x, t_{i}) con valor en entrada x { x(t_{i}) = x q(t_{i+1}) = M etodoCausal ( q(t_{i-m}), ..., q(t_{i}), r(t_{i-m}), ..., r(t_{i}), x(t_{i-m}), ..., x(t_{i}), h ) } end Dess-causal-simulator
Cuando el algoritmo recibe un mensaje de inicializaci on en el instante ti , el algoritmo resuelve el problema del arranque, es decir, calcula el valor de los vectores [q (tim ), . . . , q (ti )], [r (tim ), . . . , r (ti )] y [x(tim ), . . . , x(ti )]. El m etodo empleado para ello depende del algoritmo de integraci on. Obs ervese que, una vez calculados estos tres vectores, se dispone de los datos necesarios para calcular q (ti+1 ) empleando el m etodo de integraci on. Los sucesivos instantes de tiempo en que se eval ua el modelo vienen determinados por el valor inicial del tiempo y por el tama no del paso de integraci on. En cada instante de evaluaci on, ti , el algoritmo recibe dos mensajes: 1. Un mensaje-*. En respuesta a este mensaje, el algoritmo calcula el valor de la salida en el instante ti . Es decir: yi = (q (ti )). 2. Un mensaje-x, en el cual recibe el valor de la entrada en el instante ti , es decir, x(ti ). En respuesta a este mensaje, el algoritmo calcula el estado en el instante ti+1 , es decir, q (ti+1 ).
5.6.2.
M etodos num ericos de integraci on no causales
Para calcular el estado en el instante de tiempo futuro, ti+1 , los m etodos no causales usan, adem as de valores de los estados y de las derivadas en el pasado y en el presente, tambi en estimaciones del valor del estado, las derivadas y las entradas en instantes de tiempo posteriores al actual, ti . Los m etodos de Euler-Richardson, de RK-4 y RKF-4,5 descritos en la Secci on 2.3.4 son ejemplos de m etodos no causales.
252
Los m etodos no causales tienen dos fases. En la fase predictor, se realiza una estimaci on de los valores futuros. En la fase corrector, nalmente se determina el valor del estado en el instante de tiempo futuro. Al igual que en los m etodos causales, para aplicar un m etodo no causal deben almacenarse los m valores pasados del estado (q (tim ), . . . , q (ti )), de las derivadas (r (tim ), . . . , r (ti )) y de las entradas (x(tim ), . . . , x(ti )). Adem as, debe almacenarse el conjunto de valores predichos calculados en la fase predictor, q (1), . . . , q (n). En la fase predictor se calcula el valor del estado en n instantes futuros:
q (k + 1) = k- esimoPredictor( q (tim ), . . . , q (ti ), q (1), . . . , q (k ), r (tim ), . . . , r (ti ), r (1), . . . , r (k ), x(tim ), . . . , x(ti ), x (1), . . . , x (k ), t)
(5.47)
para k : 0, . . . , n 1. Los valores calculados en la fase predictor se usan en la fase corrector para calcular el valor del estado en el instante ti+1 . q (ti+1 ) = Corrector( q (tim ), . . . , q (ti ), q (1), . . . , q (n), r (tim ), . . . , r (ti), r (1), . . . , r (n), x(tim ), . . . , x(ti ), x (1), . . . , x (n), t)
(5.48)
A continuaci on, se muestra un algoritmo para la simulaci on de modelos DESS at omicos, empleando un m etodo de integraci on no causal.
Dess-no-causal-simulator variables: DESS = (X, Y, Q, f, lambda) // Modelo asociado [q(t_{i-m}), ..., q(t_{i})] // Vector de valores pasados del estado [r(t_{i-m}), ..., r(t_{i})] // Vector de valores pasados de la derivada [x(t_{i-m}), ..., x(t_{i})] // Vector de valores pasados de la entrada [q(1), ..., q(n)] // Vector de valores predichos del estado [r(1), ..., r(n)] // Vector de valores predichos de la derivada [x(1), ..., x(n)] // Vector de valores predichos de la entrada h // Paso de integraci on k // Indicador de la fase del integrador when recibe mensaje-i (i,t_{i}) en el instante t_{i} { inicializa [q(t_{i-m}), ..., q(t_{i})], [r(t_{i-m}), ..., r(t_{i})], [x(t_{i-m}), ..., x(t_{i})]
253
mediante el procedimiento del m etodo de integraci on k = 0 } when recibe mensaje-* (*,t_{i}) en el instante t_{i} { if k = 0 then y = lambda( q(t_{i}) ) else y = lambda( q(k) ) envia mensaje-y (y,t_{i}) a parent } when recibe mensaje-x (x, t_{i}) con valor en entrada x { if k = 0 then x(t_{i}) = x else x(k) = x k = (k + 1) mod (n+1) // k: 0,1,...,n,0,1,...,n,0,1, etc. if k > 0 then q(k) =k- esimoPredictor( q(t_{i-m}), ..., q(t_i), q(1), ..., r(t_{i-m}), ..., r(t_i), r(1), ..., x(t_{i-m}), ..., x(t_i), x(1), ..., h ) else q(t_{i+1}) = Corrector( q(t_{i-m}), ..., q(t_i), q(1), ..., r(t_{i-m}), ..., r(t_i), r(1), ..., x(t_{i-m}), ..., x(t_i), x(1), ..., h ) } end Dess-no-causal-simulator
q(k-1), r(k-1), x(k-1),
q(n), r(n), x(n),
El algoritmo recibe, en cada instante de evaluaci on, n + 1 mensajes-* y n + 1 mensajes-x. En el algoritmo se emplea el contador k para distinguir entre las fases del predictor y el corrector. En funci on del valor del contador k : La salida se calcula empleando el estado actual o el estado estimado. Cuando k = 0, se calcula la salida correspondiente al estado actual: yi = (q (ti )). Para valores k = 0, se calcula la salida correspondiente a la estimaci on k - esima q (k ) del estado futuro: y = (q (k )). Una entrada recibida en un mensaje-x se interpreta como la k - esima estimaci on o como el valor actual de la entrada. Si se recibe un mensaje-x y k = 0, entonces el valor de x corresponde con el valor actual de la entrada, x(ti ). En caso contrario, la entrada representa una estimaci on y su valor se almacena en x (k ). Se decide si debe realizarse la k - esima predicci on o la correcci on nal.
254
5.7.
Ejercicio 5.1 Modique el modelo del proceso de llenado de barriles descrito en el Tema 5 del texto base de teor a, de modo que el modelo detecte cu ando el valor del ujo de l quido ujoIn es inferior a un determinado valor umbral y detenga el proceso de llenado, generando un evento de salida que alerte de dicha situaci on. Puede realizar todas las hip otesis de modelado adicionales que desee.
Ejercicio 5.2 Indiqu e como podr a realizarse la conexi on entre dos modelos DTSS con diferente tama no del paso, h. Considere el uso de una funci on promediadora en el caso de la conexi on entre una salida r apida (h peque no) y una entrada lenta (h grande).
Ejercicio 5.3 Escriba el modelo del sistema descrito a continuaci on, aplicando el formalismo DEV&DESS. El sistema consta de un dep osito para el almacenamiento de l quido, una bomba y dos v alvulas (v ease la Figura 5.13). Adem as tiene un sensor/actuador, que manipula la v alvula 2, y un sensor de nivel. La funci on de la bomba es introducir l quido en el dep osito. El voltaje de entrada a la bomba es una variable de tiempo continuo, vbomba . El ujo de l quido que sale de la bomba y entra en el dep osito (Fbomba ) es proporcional al voltaje aplicado a la bomba (vbomba ). La constante de proporcionalidad (Kbomba ) es un par ametro. Fbomba = Kbomba vbomba (5.49)
El sistema tiene dos v alvulas. Cada una de las v alvulas puede encontrarse en uno de dos modos de funcionamiento: {abierta, cerrada}. La apertura y cierre de la v alvula 1 es accionada a trav es de una de las entradas del sistema: la entrada de eventos discretos On/O. Los eventos que llegan a esa entrada s olo pueden tomar dos valores: {0, 1}. Cuando se recibe un evento de valor 0, la v alvula se cierra: Fout1 = 0. Por el contrario, cuando se recibe un
255
"#$"%% ! ! &

Figura 5.13: Representaci on esquem atica del sistema.

evento de valor 1, la v alvula se abre y el ujo a su trav es es: Fout1 = K1 h, donde K1 es un par ametro y h es la altura del l quido contenido en el dep osito. La apertura de la v alvula 2 es accionada mediante un actuador, que est a conectado a un sensor que detecta la presencia de l quido. Tanto el sensor como el actuador son parte del sistema. Esta v alvula hace las funciones de v alvula de seguridad, abri endose cuando el nivel de l quido en el dep osito supera un cierto valor umbral (hmax ). As pues, cuando el nivel de l quido h es mayor que un cierto valor umbral hmax , la v alvula 2 se abre y el ujo a su trav es es: Fout2 = K2 (h hmax ), donde K2 es un par ametro. Mientras el nivel de l quido sea menor o igual que hmax , la v alvula 2 est a cerrada: Fout2 = 0. La variaci on en el nivel del l quido contenido en el dep osito, h, depende de los ujos de entrada y salida. La constante de proporcionalidad C es un par ametro del modelo. C dh = Fbomba Fout1 Fout2 dt (5.50)
En la base del dep osito est a conectado un sensor de nivel, que proporciona el valor actual del nivel del l quido contenido en el dep osito (h).
256
El modelo tiene tres variables de salida de tiempo continuo: la altura del l quido (h), el ujo a trav es de la v alvula 1 (Fout1 ) y el ujo a trav es de la v alvula 2 (Fout2 ).
Ejercicio 5.4 Escriba el modelo del controlador descrito a continuaci on, aplicando el formalismo DEV&DESS. En la Figura 5.14 se muestra un esquema de la interfaz del controlador. Tiene dos entradas, una de tiempo continuo (h) y otra de eventos discretos (href ), y dos salidas, una de tiempo continuo (vbomba ) y otra de eventos discretos (On/O).
h h
On/Off
Figura 5.14: Representaci on esquem atica de la interfaz del controlador.
La nalidad del controlador es conseguir, una vez conectado al sistema descrito en el ejercicio anterior, que la altura de l quido en el dep osito (h) sea igual a su valor ref de consigna (h ). Para ello, el controlador manipula el valor del voltaje aplicado a la (vbomba ) y la apertura/cierre de la v alvula 1 (On/O). Los eventos recibidos en la entrada href pueden tomar valor real positivo y representan el valor que se desea que tenga la altura de l quido (valor de referencia o de consigna). La generaci on de eventos en la salida On/O se realiza de la forma siguiente: Cuando el valor actual de la altura (h) se hace mayor que el valor de referencia (href ), entonces se genera un evento de valor 1 en la salida On/O. Con ello se abre la v alvula 1, lo cual hace que comience a vaciarse el dep osito. Cuando el valor actual de la altura se hace menor que el valor de consigna, se genera un evento de valor cero en la salida On/O, cuyo efecto es cerrar la v alvula 1. La salida de tiempo continuo vbomba se calcula de la forma siguiente:
257
vbomba =
0 KC href h
si h href en caso contrario
(5.51)
Es decir, mientras el nivel de l quido es menor que el nivel de referencia (h < href ), el voltaje aplicado a la bomba ser a proporcional a la diferencia href h. Con ello se consigue introducir l quido en el dep osito y reducir la diferencia entre el nivel actual y el deseado. Por el contrario, mientras el nivel actual sea mayor o igual al deseado (h href ), se aplica un voltaje nulo a la bomba, con lo cual no se introduce l quido en el dep osito.
Ejercicio 5.5 Describa el modelo compuesto mostrado en la Figura 5.15, formado por la conexi on del sistema del Ejercicio 5.3 y el controlador del Ejercicio 5.4, aplicando el formalismo DEV&DESS.
v h On/Off
On/Off
#$% $& +$% $& 567588 .94./0 ,- -- :;<=>
? @A@B = # 40 23./01 %'(* ,- ! " # %'()
F F
h
Figura 5.15: Representaci on esquem atica del sistema controlado.
258
5.8.
Soluci on al Ejercicio 5.1 Existen varias formas de modicar el modelo del proceso de llenado de barriles. Una posibilidad es denir un nuevo puerto de salida discreto, que llamaremos valorFlujo (v ease la Figura 5.16). Los eventos generados a trav es de este puerto pueden tomar dos valores: {ujoBajo, ujoNormal}. Cuando ujoIn es mayor o igual que el valor umbral y pasa a ser menor que el valor umbral, entonces se genera un evento de valor ujoBajo. Cuando ujoIn es menor o igual que el valor umbral y pasa a ser mayor, entonces se genera un evento de valor ujoNormal.
on/off flujoIn
barril cout valorFlujo
contenido valvula flujo
Figura 5.16: Modelo del proceso de llenado de barriles.
La interfaz del modelo est a denida por los siguientes elementos de la tupla:
X cont = {f lujoIn | f lujoIn R} X discr = {on/of f | on/of f {on, o}} Y cont = {cout | cout R} Y discr = {barril | barril {barrilDe10litros}, valorF lujo | valorF lujo {ujoBajo, ujoNormal}} El estado del sistema es descrito por tres variables de estado: contenido, valvula y ujo. La variable de estado ujo puede tomar dos valores: {bajo,normal}. Describe el modo en el cual se encuentra el sistema: ujo de entrada (ujoIn) por debajo del valor umbral o ujo normal.
259
S cont = {contenido | contenido R} S discr = {valvula | valvula {abierta, cerrada}, f lujo | f lujo {bajo, normal}} El modelo tiene las tres condiciones de evento siguientes: El volumen de l quido en el barril alcanza el valor 10 litros. Cint,1 ((contenido, valvula, f lujo), e, f lujoIn) : contenido > 10 El ujo de l quido pasa a ser menor que el valor umbral. Cint,2 ((contenido, valvula, f lujo), e, f lujoIn) : f lujo = normal y f lujoIn < umbral El ujo de l quido pasa a ser mayor o igual que el valor umbral. Cint,3 ((contenido, valvula, f lujo), e, f lujoIn) : f lujo = bajo y f lujoIn umbral Cuando se dispara una o varias de las condiciones de evento, se eval ua la funci on de transici on interna con el n de calcular el nuevo estado. Cada condici on de evento tiene asociado el siguiente cambio en las variables de estado: int ((contenido, valvula, f lujo), e, f lujoIn) : contenido = 0 si Cint,1 f lujo = bajo si Cint,2 f lujo = normal si Cint,3 Como parte de las acciones asociadas a una transici on interna, se eval ua la funci on discr de salida discreta, , con el n de calcular el valor del evento de salida. El valor del evento y del puerto de salida depende de la condici on de evento o las condiciones de evento que se hayan activado. La funci on de salida de la parte discreta del modelo es la siguiente:
260
discr ((contenido, valvula, f lujo), e, f lujoIn) : Si Cint,1 , genera evento de valor barrilDe10litros Si Cint,2 , genera evento de valor ujoBajo Si Cint,3 , genera evento de valor ujoNormal
en el puerto barril en el puerto valorF lujo en el puerto valorF lujo
La funci on f , de c alculo de las derivadas de las variables de estado de tiempo continuo, es la siguiente:
f ((contenido, valvula, f lujo), e, f lujoIn) : 0 Si valvula = cerrada o f lujo = bajo dcontenido = dt f lujoIn En caso contrario La funci on de salida de la parte continua, cont , es la misma que la del modelo explicado en el texto base de teor a: permite calcular la variable de salida cout, cuyo valor es igual en todo momento al valor de la variable de estado contenido.
Soluci on al Ejercicio 5.2 La trayectoria de entrada o salida de un modelo DTSS es un conjunto de eventos equiespaciados en el tiempo. Sea h el intervalo de tiempo entre dos eventos consecutivos. Cuando se conecta un modelo DTSS con salida r apida (h1 peque no) a otro modelo DTSS con entrada lenta (h2 grande), puede construirse el valor del evento de entrada promediando los eventos de salida que se han producido durante el intervalo h2 . En el caso contrario, salida lenta (h1 grande) y entrada r apida (h2 peque na), la conexi on ser a similar al caso DEVS DTSS, donde el evento de entrada se construye a partir del u ltimo evento de salida.
Soluci on al Ejercicio 5.3 La interfaz del modelo est a compuesta por dos entradas, una de tiempo continuo y otra de eventos discretos, y por tres salidas de tiempo continuo. Est a denida por los siguientes elementos de la tupla:
261
X cont = {vBomba | vBomba R} X discr = {on/of f | on/of f {0, 1}} Y cont = {F out1, F out2, h | F out1, F out2, h R} El estado del sistema est a denido por tres variables de estado: la altura del l quido dentro del dep osito (altura), que es una variable de tiempo continuo, y el modo de cada una de las dos v alvulas (valvula1, valvula2). Estas dos variables de tiempo discreto pueden tomar dos posible valores: 0 (cerrada), 1 (abierta). As pues, los elementos de la tupla que representan el estado son los siguientes:
S cont = {altura | altura R} S discr = {valvula1, valvula2 | valvula1, valvula2 {0, 1}} La funci on de transici on externa dene c omo cambia el estado del modelo en funci on de los eventos de entrada. Los eventos de entrada en el puerto on/o determinan el modo de la v alvula 1, es decir, el valor de la variable de estado valvula1. ext ((altura, valvula1, valvula2), e, vBomba, on/of f ) : valvula1 = on/of f El modelo tiene dos condiciones de evento, las cuales determinan el modo de la v alvula 2. Las condiciones de evento son las siguientes: El volumen de l quido pasa a ser mayor que hmax . Cint,1 ((altura, valvula1, valvula2), e, vBomba) : valvula2 = 0 y altura > hmax El volumen de l quido se hace menor que hmax . Cint,2 ((altura, valvula1, valvula2), e, vBomba) : valvula2 = 1 y altura < hmax Cuando se dispara una de las condiciones de evento, se eval ua la funci on de transici on interna con el n de calcular el nuevo estado. Cada condici on de evento tiene asociado el siguiente cambio en la variable de estado valvula2:
262
int ((altura, valvula1, valvula2), e, vBomba) : valvula2 = 1 si Cint,1 valvula2 = 0 si Cint,2 El modelo no tiene puertos de eventos discretos, con lo cual no es preciso denir la funci on de salida discreta, discr . La funci on f , de c alculo de las derivadas de las variables de estado de tiempo continuo, es la siguiente:
f ((altura, valvula1, valvula2), e, vBomba) : C d altura = Kbomba vBomba valvula1 K1 h valvula2 K2 (altura hmax ) dt La funci on de salida de la parte continua, cont , calcula las variables de salida de tiempo continuo. cont ((altura, valvula1, valvula2), e, vBomba) : F out1 = valvula1 K1 h F out2 = valvula2 K2 (h hmax ) h = altura
(5.52)
Soluci on al Ejercicio 5.4 La interfaz del modelo est a compuesta por dos entradas, una de tiempo continuo (h) y una de eventos discretos (href ), y por dos salidas, una de tiempo continuo (vBomba) y una de eventos discretos (On/O). As pues, la interfaz est a denida por los siguientes elementos de la tupla:
X cont = {h | h R} X discr = {href | href R} Y cont = {vBomba | vBomba R} Y discr = {on/of f | on/of f {0, 1}} El estado del sistema est a denido por dos variables de estado:
263
h mayorQue href, con dos posibles valores: {0,1}. Si la altura de l quido es mayor que el valor de referencia, entonces h mayorQue href vale 1. En caso contrario, vale 0. alturaRef, que almacena el valor de referencia para la altura de l quido. Este valor, de tipo real, coincide con el valor del u ltimo evento recibido en el puerto href. As pues, los elementos de la tupla que representan el estado son los siguientes:
S cont = S discr = {h mayorQue href | h mayorQue href {0, 1}, alturaRef | alturaRef R} La funci on de transici on externa dene c omo cambia el estado cuando llegan eventos al puerto de entrada href. El valor del evento recibido se asigna a la variable de estado alturaRef. ext ((h mayorQue href, alturaRef), e, href, h) : alturaRef = href El modelo tiene dos condiciones de evento, las cuales determinan cu ando el nivel de l quido pasa a ser mayor que el valor de referencia, o bien cuando pasa a ser igual o menor. El volumen de l quido pasa a ser mayor que el valor de referencia. Cint,1 ((h mayorQue href, alturaRef), e, h) : h mayorQue href = 0 y h > alturaRef El volumen de l quido se hace menor o igual que el valor de referencia. Cint,2 ((h mayorQue href, alturaRef), e, h) : h mayorQue href = 1 y h alturaRef Cuando se dispara una de las condiciones de evento, se eval ua la funci on de transici on interna con el n de calcular el nuevo estado. Cada condici on de evento tiene asociado el siguiente cambio en la variable de estado h mayorQue href:
264
int ((h mayorQue href, alturaRef), e, h) : h mayorQue href = 1 si Cint,1 h mayorQue href = 0 si Cint,2 La funci on de salida discreta, discr , determina qu e eventos de salida se generan cuando se producen transiciones internas. discr ((h mayorQue href, alturaRef), e, h) : Evento de valor 1 en el puerto On/O si Cint,1 Evento de valor 0 en el puerto On/O si Cint,2 Dado que el modelo no tiene variables de estado de tiempo continuo, no se dene la funci on f . La funci on de salida de la parte continua, cont , calcula la variable de salida de tiempo continuo. cont ((h mayorQue href, alturaRef), e, h) : vBomba = (1 h mayorQue href) KC (alturaRef h)
Soluci on al Ejercicio 5.5 El modelo compuesto mostrado en la Figura 5.15 puede representarse mediante la tupla siguiente: N = X, Y, D, {Md | d D }, EIC, EOC, IC, select donde: InP orts = {href} Xhref = R OutP orts = {Fout1, Fout2} YFout1 = YFout2 = R
Puerto de entrada del modelo compuesto. Posibles valores de los eventos en el puerto href del modelo compuesto. Puerto de salida del modelo compuesto. Posibles valores de los eventos en el puerto Fout1 y Fout2 del modelo compuesto.
265
D = {C, DV }
Conjunto de nombres de los componentes: controlador (C ), dep osito y v alvulas (DV ).
MC = Mcontrolador MDV = Mdeposito y valvulas EIC = {(N, href), (C, href)} EOC = { ((DV, Fout1), (N, Fout1)) , ((DV, Fout2), (N, Fout2)) }
Tipo de los componentes.
Conexiones externas de entrada. Conexiones externas de salida.
IC = Conexiones internas. { ((DV, h), (C, h)) , ((C, vBomba), (DV, vBomba)), ((C, On/O), (DV, On/O)) } La funci on select establece la prioridad en caso de que los dos componentes tengan en el mismo instante una transici on interna.
266
TEMA 6 DEVSJAVA
6.1. Introducci on 6.2. Paquetes en DEVSJAVA 3.0 6.3. Modelos SISO en DEVS cl asico 6.4. Clases y m etodos en DEVSJAVA 6.5. Modelos DEVS at omicos 6.6. Modelos DEVS compuestos y jer arquicos 6.7. SimView 6.8. Ejercicios de autocomprobaci on 6.9. Soluciones a los ejercicios
DEVSJAVA
OBJETIVOS DOCENTES Una vez estudiado el contenido del tema deber a saber: Emplear las clases de DEVSJAVA para describir modelos at omicos y modulares sencillos, aplicando el formalismo DEVS cl asico y paralelo.
269
DEVSJAVA
6.1.
INTRODUCCION
En este tema se presenta un entorno en Java, denominado DEVSJAVA (Zeigler & Sarjoughian 2005), para el modelado y simulaci on de modelos DEVS. DEVSJAVA, que ha sido desarrollado en la Universidad de Arizona, es una propiedad intelectual de los Regents of the State of Arizona. Puesto que DEVS es un formalismo p ublico, existen otras implementaciones de estos conceptos, y cualquiera es libre de desarrollar su propio software bas andose en la literatura de dominio p ublico sobre el tema. Por ejemplo, dos entornos de simulaci on gratuitos basados en DEVS son JDEVS1 y CD++2 , que han sido desarrollados en la Universidad de C orcega y Carleton, respectivamente. Estos entornos no emplean DEVSJAVA, sino sus propias implementaciones de DEVS.
6.2.
PAQUETES EN DEVSJAVA 3.0
DEVSJAVA 3.0 es un entorno de simulaci on programado en lenguaje Java, que est a especialmente dise nado para la descripci on de modelos siguiendo el formalismo DEVS. DEVSJAVA 3.0 se distribuye en un u nico chero de tipo jar llamado coreDEVS.jar, en el cual no se proporciona el c odigo fuente de las clases. Se recomienda usar JDK 1.4 con DEVSJAVA 3.0. Contiene los paquetes mostrados en la Figura 6.1:
GenCol Contiene los servicios b asicos para manipular conjuntos de entidades: contenedor, bolsa, conjunto, relaci on, funci on, listas ordenadas, etc. genDevs Contiene a su vez los paquetes modeling, simulation y plots, en los cuales pueden encontrarse clases para la descripci on del modelo, la simulaci on y la representaci on de los resultados de la simulaci on. El paquete modeling contiene clases para la descripci on de varios tipos de modelos, incluyendo DEVS at omico, acoplado y celular. Usando estos modelos predenidos, pueden construirse modelos complejos de manera jer arquica y modular.
1 2
Sitio web de JDEVS: http://spe.univ-corse.fr/lippiweb/appli/index.html Sitio web de CD++: http://www.sce.carleton.ca/faculty/wainer/wbgraf/
271
Figura 6.1: Paquetes de DEVSJAVA 3.0.
simView
Contiene una herramienta para la visualizaci on de la estructura modular de los modelos y para el control de la ejecuci on de la simulaci on. Dentro de este paquete se encuentra la clase SimView, que contiene un m etodo main que hay que ejecutar para arrancar la herramienta de visualizaci on.
statistics util
Contiene clases u tiles para realizar an alisis estad sticos. Contiene clases de uso general.
Adem as del chero coreDEVS.jar, la distribuci on de DEVSJAVA contiene un segundo chero, llamado IllustrationCode.zip, que contiene una serie de ejemplos ilustrativos de los conceptos DEVS. Cada paquete est a dedicado a una categor a diferente de modelos DEVS:
SimpArc oneDCellSpace, twoDCellSpace Contienen modelos de espacios celulares unidimensionales y bidimensionales respectivamente. Continuity variableStructure pulseModels, pulseExpFrames Contienen modelos y marcos experimentales respectivamente de sistemas de pulsos. Contiene modelos de sistemas continuos. Contiene ejemplos de modelos con estructura variable. Contiene ejemplos b asicos de modelos DEVS.
272
DEVSJAVA
Random
Contiene ejemplos de modelos en los que se usan n umeros aleatorios.
Quantization
Contiene modelos de sistemas cuantizados.
Se recomienda al alumno que en este punto cargue los cheros coreDEVS.jar y IllustrationCode.zip en el entorno de desarrollo Java que habitualmente use y que inspeccione el contenido de ambos cheros.
6.3.
MODELOS SISO EN DEVS CLASICO
Por motivos did acticos, en esta primera secci on dedicada al uso de DEVSJAVA se comienza explicando la descripci on de los modelos DEVS cl asico m as sencillos, que son aquellos que tienen un u nico puerto de entrada y un u nico puerto de salida (modelos SISO), y en los cuales los eventos de entrada y salida toman valores reales. Estos modelos fueron explicados en la Secci on 3.2. El c odigo Java de todos los modelos explicados en esta secci on se encuentra en el paquete SimpArc, que est a contenido en el chero IllustrationCode.zip. Como se ir a viendo, todos estos modelos DEVS SISO heredan de la clase siso.
6.3.1.
Sistema pasivo
En la Secci on 3.2.1 se describi o el modelo de un sistema pasivo. Esto es, de un sistema que no responde con salidas a ninguna trayectoria de entrada y que se encuentra siempre en su u nico estado, que denominamos passive (pasivo). A continuaci on, se muestra el c odigo de la clase passive, que describe el modelo DEVS pasivo.
package SimpArc; public class passive extends siso { public passive() { public passive(String name) { public void initialize(){ phase = "passive"; sigma = INFINITY; super.initialize(); } super("passive"); } super(name); }
273
public void public void
Deltext(double e,double input) { passivate(); } deltint() { passivate(); } { return 0; }
public double sisoOut() public void }
showState() { super.showState(); }
Puede observarse que el comportamiento del modelo se describe mediante la denici on de los m etodos siguientes:
deltint Deltext sisoOut Dene la funci on de transici on interna. Dene la funci on de transici on externa. Dene la funci on de salida, que genera un evento de salida de valor real justo antes de que se produzca la transici on interna del estado.
En los m etodos que denen las funciones de transici on interna y externa, se hace una llamada al m etodo passivate, que ya se encuentra predenido y es empleado frecuentemente en la descripci on de los modelos.
passivate Asigna al String phase el valor passive y al double sigma el valor INFINITY.
public void passivate() { passivateIn("passive"); } public void passivateIn(String phase) { holdIn(phase, INFINITY); } public void holdIn(String phase, double sigma) { this.phase = phase; this.sigma = sigma;; }
Obs ervese que hay dos variables (ya declaradas en las clases base, tales como siso, de DEVSJAVA) que se emplean como variables de estado en casi todos los modelos DEVS:
274
DEVSJAVA
sigma phase
De tipo double, representa el tiempo que permanecer a el sistema en el estado actual en ausencia de eventos externos. De tipo String, almacena las diferentes fases del sistema.
6.3.2.
Sistema acumulador
En la Secci on 3.2.2 se describi o el modelo de un sistema acumulador. El modelo tiene tres variables de estado: 1. phase, con valores {passive,respond}. 2. sigma, que puede tomar valores reales positivos. 3. store, que puede tomar valores reales diferentes de cero. La fase respond es necesaria para indicar que una salida se encuentra en camino. El par ametro del modelo se llama response time y corresponde con el tiempo de respuesta () descrito en la Secci on 3.2.2. A continuaci on, se muestra la parte m as relevante del c odigo Java de la clase storage. Obs ervese que las variables de estado phase y sigma ya han sido declaradas en la clase siso, con lo cual al denir la clase storage s olo es preciso declarar la variable de estado store y el par ametro response time.
package SimpArc; public class storage extends siso { protected double store; protected double response_time; public storage(String name,double Response_time){ super(name); response_time = Response_time; } public void initialize(){ phase = "passive"; sigma = INFINITY; store = 0; response_time = 10; super.initialize(); }
275
public void Deltext(double e,double input){ Continue(e); if (input != 0) store = input; else holdIn("respond", response_time); } public void deltint( ){ passivate(); } public double sisoOut(){ if (phaseIs("respond")) return store; else return 0; } public void showState(){ super.showState(); System.out.println("store: " + store); } }
En la programaci on de esta clase se han invocado dos m etodos ya predenidos en la clase siso:
continue Reduce sigma en e, donde e es el tiempo que ha transcurrido desde el anterior evento.
public void Continue(double e) { if (sigma < INFINITY) sigma = sigma - e; }
phaseIs
Devuelve true o false dependiendo de que el valor actual de phase coincida o no con el valor que se pasa como argumento al m etodo.
public boolean phaseIs(String phase){ return this.phase.equals(phase); }
276
DEVSJAVA
6.3.3.
Generador de eventos
En la Secci on 3.2.3 se describi o el modelo de un generador de eventos. A continuaci on, se muestra su programaci on en DEVSJAVA.
package SimpArc; public class generator extends siso { protected double period; public generator(String name,double Period){ super(name); period = Period; } public void initialize(){ phase = "active"; sigma = period; super.initialize(); } public void deltint( ){ holdIn("active",period); showState(); } public double sisoOut(){ return 1; } public void showState(){ super.showState(); System.out.println("period: " + period); } }
Es posible visualizar la ejecuci on de este modelo empleando simView. Para arrancar simView debe ejecutarse (el m etodo main de) la clase SimView, que se encuentra dentro del paquete simView de coreDEVS.jar. En la GUI de simView hay un bot on, congure, que debemos pulsar para introducir el path y el nombre de los paquetes con las clases de los modelos. En la Figura 6.2 se muestra el men u de conguraci on, en el que se indica el path del paquete (en el caso mostrado es ., pero depende de d onde se hayan grabado los paquetes que contiene el chero IllustrationCode.zip) y su nombre (SimpArc).
277
Figura 6.2: Men u de conguraci on de SimView.
Figura 6.3: GUI de SimView con el modelo SimpArc.generator cargado.
278
DEVSJAVA
A continuaci on, pulsando el bot on Select a package de la GUI de SimView, puede escogerse entre los paquetes que se han especicado en la ventana anterior de conguraci on. Si se selecciona el paquete SimpArc y, dentro de este, el modelo generator, entonces el modelo se carga en SimView (v ease la Figura 6.3), pudiendo ser ejecutado.
6.3.4.
Contador binario
En la Secci on 3.2.4 se describi o el modelo de un contador binario. El sistema genera un evento de valor uno por cada dos eventos de entrada de valor uno que recibe. En c odigo en DEVSJAVA que describe ese modelo es el siguiente.
package SimpArc; public class binaryCounter extends siso { double count; public binaryCounter(String name) { super(name); } public void initialize(){ count = 0; super.initialize(); } public void Deltext(double e, double input){ Continue(e); count = count + (int)input; if (count >= 2){ count = 0; holdIn("active",10); } } public void deltint( ) { passivate(); }
public double sisoOut() { if (phaseIs("active")) return 1; else return 0; } public void showState() { super.showState(); System.out.println("count: " + count); } }
279
6.4.
CLASES Y METODOS EN DEVSJAVA
En esta secci on se describen algunas de las clases b asicas de DEVSJAVA, que es preciso conocer para poder describir los modelos.
6.4.1.
Clases contenedor
Las clases contenedor, que se encuentran en el paquete GenCol, se emplean para alojar instancias de objetos. En la Figura 6.4 se muestran algunas de estas clases, sus campos, algunos de sus m etodos y su jerarqu a. Se recomienda al alumno que inspeccione por s mismo el contenido del paquete GenCol.
entity Pair Relation Bag Function Queue intEnt, doubleEnt Entidades que contienen un n umero entero y real respectivamente. Es la clase base de todas las clases de objetos que pueden alojarse en contenedores. Almacena una pareja de entidades, llamadas key y value. Es un conjunto de parejas key-value, que t picamente es usado a modo de diccionario. Bolsa de entidades. Es una relaci on en la cual no puede haber dos parejas key-value con el mismo valor de key. Mantiene los objetos ordenados de forma FIFO.
6.4.2.
Clases DEVS
Las clases para el modelado de sistemas est an en el paquete genDevs.Modeling, y emplean las clases contenedor denidas en el paquete GenCol. En la Figura 6.5 se muestra una versi on simplicada del arbol de herencia. Las clases atomic y digraph son subclases de devs, que a su vez es subclase de GenCol.entity. Estas dos clases se emplean para el modelado de DEVS at omicos y compuestos, respectivamente.
280
DEVSJAVA
protected java.lang.String name; entity(java.lang.String nm); boolean eq(java.lang.String nm); boolean equals(java.lang.Object o); java.lang.String getName(); java.lang.String toString(); void print();

extends entity
extends entity
extends entity
extends entity
public java.util.Hashtable h; protected int size; Relation(); boolean isEmpty(); int size(); java.util.Set getSet(java.lang.Object key); java.lang.Object put(java.lang.Object key, java.lang.Object value); java.lang.Object remove(java.lang.Object key, java.lang.Object value); void removeAll(java.lang.Object key); java.lang.Object get(java.lang.Object key); boolean contains(java.lang.Object key, java.lang.Object value); java.util.Set keySet(); java.util.Set valueSet(); java.lang.String toString(); boolean equals(java.lang.Object o);
public java.lang.Object key; public java.lang.Object value; Pair(java.lang.Object Key, java.lang.Object value); java.lang.String toString(); Boolean equals(java.lang.Object o); java.lang.Object getKey(); java.lang.Object getValue();
extends Relation
extends Relation
Bag(); int numberOf(); boolean add(java.lang.Object o); boolean remove(java.lang.Object o); void clear(); java.util.Set bag2Set(); boolean contains(java.lang.Object key); java.util.Iterator iterator(); java.lang.String toString(); static GenCol.Bag List2Bag(java.util.List li);
ZRelation(java.lang.String name); java.lang.String getName(); boolean empty(); int getLength(); java.util.Set assocAll(java.lang.Object key); java.lang.Object assoc(java.lang.Object key); boolean isIn(java.lang.Object key, java.lang.Object value); java.util.Set domainObjects(); java.util.Set rangeObjects(); void add(java.lang.Object key, java.lang.Object value); void Remove(java.lang.Object key, java.lang.Object value);

extends Bag
ensembleBag(); ...

extends java.util.Hashtable
Function(); boolean contains(java.lang.Object key, java.lang.Object value); java.util.Set valueSet(); void replace(java.lang.Object key, java.lang.Object value); java.lang.Object assoc(java.lang.String name); void print();

extends Function
ZFunction(); boolean empty(); int getLength(); void replace(java.lang.Object key, java.lang.Object value); java.lang.Object assoc(java.lang.Object key); boolean keyIsIn(java.lang.Object key); boolean valueIsIn(java.lang.Object value); boolean isIn(java.lang.Object key, java.lang.Object value); java.util.Set domainObjects(); java.util.Set rangeObjects(); void add(java.lang.Object key, java.lang.Object value); void Remove(java.lang.Object key); void replace(java.lang.Object key, java.lang.Object value);
Figura 6.4: Algunas clases contenedor del paquete GenCol.

"$%&'(
!"
#
$""'(
'$#
()'*+
Figura 6.5: Algunas clases para la descripci on de los modelos DEVS. 281
La clase message es una subclase de GenCol.ensembleBag y representa los mensajes que son transmitidos entre los componentes de un modelo compuesto. El mensaje aloja instancias de la clase content. A continuaci on se describen algunas de las caracter sticas de estas clases que son m as relevantes a la hora de usarlas para la construcci on de modelos.
Clase devs La clase devs es la superclase de las dos clases para la descripci on de los modelos, que son atomic y digraph. A continuaci on, se muestra parte del c odigo de la clase devs.
public abstract class genDevs.modeling.devs extends GenCol.entity implements genDevs.modeling.IODevs { protected double tL, tN; public final double INFINITY = Double.POSITIVE_INFINITE; public devs(String name) { super(name); ... } public void initialize() { tL = 0; tN = tL + ta(); output = null; } public void inject(String p, entity val, double e) { mensaje in = new message(); content co = makeContent(p, val); in.add(co); } public content makeContent(String p, entity value) { return new content(p, value); } public boolean messageOnPort(message x, String p, int i) { if (inports.is_in_name(p)) System.out.println("Warning: model: " + name + " inport: " + p + "has not been declared");
282
DEVSJAVA
return x.on_port(p, i); } }
Clase message La clase message es una subclase de GenCol.ensembleBag y almacena instancias de la clase content, la cual a su vez almacena el puerto, p, y el valor, val (una instancia de la clase entity).
public class genDevs.modeling.message extends GenCol.ensembleBag implements genDevs.modeling.MessageInterface, GenCol.EntityInterface { public message() { super(); } public content read(int i) { // Devuelve el contenido i- esimo almacenado en el mensaje } public boolean on_port(String portName, int i) { content con = read(i); return portName.equals(con.p); } public entity getValOnPort(String portName, int i) { if ( on_port(portName,i) ) return read(i).val; return null; } }
Clase atomic La clase atomic describe modelos DEVS at omicos. Contiene elementos que se corresponden con las diferentes partes del formalismo. Por ejemplo, tiene m etodos para describir la funci on de transici on interna, la funci on de transici on externa, la funci on de salida y la funci on de avance en el tiempo. Estos m etodos se aplican a las variables de la instancia, que caracterizan el estado del modelo.
public class genDevs.modeling.atomic extends genDevs.modeling.devs
283
implements genDevs.modeling.AtomicInterface, genDevs.modeling.variableStructureInterface { public atomic(String name) { super(name); phases = new set(); lastOutput = new message(); addInport("in"); addOutport("out"); phases.add("passive"); passivate(); } public void passivate() { phase = "passive"; sigma = INFINITY; } public holdIn(String p, double s) { phase = p; sigma = s; } public void passivateIn(String phase) { holdIn(phase, INFINITY); } public boolean phaseIs(String Phase) { if ( !(phases.is_in_name(Phase)) ) System.out.println("Warning: model: " + getName() + " phase: " + Phase + " has not been declared" ); return phase.equals(Phase); } public void deltint() { } public void deltext(double e, message x) { } public void deltcon(double e, message x) { // Transici on externa seguida por transici on interna // deltext(e,x); // deltint(); // Transici on interna seguida por transici on externa deltint(); deltext(0,x); }
284
DEVSJAVA
Clase digraph La clase digraph permite denir modelos DEVS compuestos. Adem as de los componentes, permite especicar las conexiones entre los componentes (acoplo interno), y las conexiones de los componentes con los puertos de entrada y de salida del modelo compuesto.
public class genDevs.modeling.digraph extends genDevs.modeling.devs implements genDevs.modeling.Coupled { protected genDevs.modeling.couprel Coupling; public digraph(String nm) { super(nm); Coupling = new couprel(); addInport("in"); addOutport("out"); } public void add(genDevs.modeling.IODevs iod) { ... } public void addCoupling(genDevs.modeling.IODevs src, String p1, genDevs.modeling.IODevs dest, String p2) { port port1 = new port(p1); port port2 = new port(p2); Coupling.add(src, p1, dest, p2); } }
6.4.3.
Clases DEVS SISO
DEVSJAVA permite que los modelos at omicos tengan eventos simult aneos, de valor arbitrario, en sus puertos de entrada. Esta capacidad puede ser limitada, de tal modo que s olo se permita la llegada de un evento en cada instante de tiempo (como en DEVS cl asico). El u nico motivo de hacer esto es facilitar el aprendizaje de DEVSJAVA a aquellas personas con escasa experiencia en programaci on con Java.
285
A continuaci on, se describen las clases classic y siso, contenidas en el paquete SimpArc. La clase siso es una subclase de classic, que a su vez es una subclase de atomic.
Clase classic En la clase classic se dene una nueva funci on de transici on externa, Deltext, que restringe el m etodo deltext heredado de atomic a un u nico content. Cuando se usa la clase classic, debe denirse la funci on de transici on externa deniendo el m etodo Deltext. Se emplea como superclase ViewableAtomic en lugar de atomic ya que ViewableAtomic permite la visualizaci on empleando simView.
package SimpArc; import simView.*; import genDevs.modeling.*; import GenCol.*; public class classic extends ViewableAtomic { public classic(String name){ super(name); } public content get_content(message x){ entity ent = x.read(0); return (content)ent; } public void Deltext(double e, content con) { } //virtual for single input at a time public void deltext(double e,message x) { Deltext(e, get_content(x)); } }
286
DEVSJAVA
Clase siso La clase siso restringe Deltext de modo que espere un u nico evento de entrada en cada instante. La funci on de transici on externa debe ser escrita por el usuario de la clase empleando el m etodo Deltext(double e, double input).
package SimpArc; import genDevs.modeling.*; import GenCol.*; public class siso extends classic { public void AddTestPortValue(double input){ addTestInput("in",new doubleEnt((double)input)); } public siso(String name){ super(name); AddTestPortValue(0); } public void Deltext(double e, double input) { } // Funci on de transici on externa de la clase siso public void Deltext(double e, content con) { // Funci on de transici on externa que espera la clase classic doubleEnt fe = (doubleEnt)con.getValue(); Deltext(e,fe.getv()); } public double sisoOut(){ // Un evento de salida en cada instante. Evento de valor real return 0; } public message out() { message m = new message(); content con = makeContent("out",new doubleEnt(sisoOut())); m.add(con); return m; } }
287
Obs ervese que en los m etodos Deltext y out se emplea la clase doubleEnt para recibir y transmitir valores reales por los puertos. An alogamente, se usar a la clase intEnt para recibir o transmitir valores enteros. Ambas clases se encuentran en el paquete GenCol. A continuaci on, se muestra un ejemplo de env o de mensajes de valor real a trav es de un puerto. En particular, a trav es del puerto out1.
public message out() { double store = 5.5; message m = new message(); content con = makeContent("out1", new doubleEnt(store)); m.add(con); return m; }
An alogamente, el siguiente es un ejemplo de recepci on de eventos de valor real en el puerto in1.

public void deltext(double e, message x) { for (int i=0; i < x.getLength(); i++) if (messageOnPort(x,"in1",i)) { entity val = x.getValOnPort("in1",i); doubleEnt d = (doubleEnt)val; double store = d.getv(); } }
6.5.
MODELOS DEVS ATOMICOS
En esta secci on se describe la programaci on de varios modelos DEVS empleando DEVSJAVA.
6.5.1.
Modelo de un recurso
En la Secci on 3.2.5 se describi o el modelo de un proceso con un recurso y sin cola. La clase proc est a contenida en el paquete SimpArc. A continuaci on, se muestra parte del c odigo de la clase.
288
DEVSJAVA
Obs ervese que hay dos variables de estado especiales que son heredadas de atomic: phase y sigma. La variable phase permite controlar la fase en que se encuentra el modelo. En este caso, puede estar en dos fases: busy (activo) y passive (pasivo).
package SimpArc; import genDevs.modeling.*; import GenCol.*; import simView.*; public class proc extends ViewableAtomic { protected entity job; protected double processing_time; public proc(String name, double Processing_time) { super(name); addInport("in"); addOutport("out"); phases.add("busy"); processing_time = Processing_time; } public void initialize(){ phase = "passive"; sigma = INFINITY; job = new entity("job"); super.initialize(); } public void deltext(double e, message x) { Continue(e); if (phaseIs("passive")) for (int i=0; i< x.getLength();i++) if (messageOnPort(x,"in",i)) { job = x.getValOnPort("in",i); holdIn("busy",processing_time); } } public void deltint() { passivate(); job = new entity("none"); } public void deltcon(double e, message x) {
289
deltint(); deltext(0,x); } public message out() { message m = new message(); if (phaseIs("busy")) m.add(makeContent("out",job)); return m; } }
Examinemos los campos y los m etodos constructor y de inicializaci on de la clase. Las declaraciones
protected entity job; protected double processing_time;
denen la instancia que almacena la entidad que est a siendo procesada y el par ametro tiempo de proceso, respectivamente. El constructor
public proc(String name, double Processing_time) { super(name); addInport("in"); addOutport("out"); phases.add("busy"); processing_time = Processing_time; }
declara los puertos: el puerto de entrada in y el puerto de salida out. Tambi en, asigna valor al nombre de la instancia de la clase proc y al par ametro processing time. Finalmente, indica que aparte de la phase passive, que es denida en la clase atomic, la clase proc tiene una segunda fase: busy. El m etodo de inicializaci on asigna valor inicial a todas las variables de estado. Siempre es necesario inicializar las variables sigma y phase, que son heredadas. La referencia job se asigna a un objeto de la clase entity, al que se asigna el nombre job.
public void initialize(){ phase = "passive"; sigma = INFINITY; job = new entity("job"); super.initialize(); }
290
DEVSJAVA
Con super.initialize() se ejecuta el m etodo initialize de la superclase, en el cual se asigna valor a tL y tN :

tL = 0; tN = tL + ta();
6.5.2.
Modelo de un proceso con una cola
En la Secci on 4.2.1 se explic o el modelo DEVS paralelo de un proceso con una cola FIFO. La clase procQ, que est a contenida en el paquete SimpArc, es la descripci on de este modelo en DEVSJAVA. A continuaci on, se muestra parte del c odigo de esta clase.
package SimpArc; import genDevs.modeling.*; import GenCol.*; public class procQ extends proc { protected Queue q; public procQ(String name, double Processing_time) { super(name, Processing_time); q = new Queue(); } public void initialize() { q = new Queue(); super.initialize(); } public void deltext(double e, message x) { Continue(e); if (phaseIs("passive")){ for (int i=0; i < x.size(); i++) if (messageOnPort(x, "in", i)) q.add(x.getValOnPort("in", i)); holdIn("busy", processing_time); job = (entity)q.first(); // Se procesa la primera entidad de la cola } else if (phaseIs("busy")) { for (int i=0; i< x.size();i++) if (messageOnPort(x, "in", i)) { entity jb = x.getValOnPort("in", i);
291
q.add(jb); } } } public void deltint() { q.remove(); if(!q.isEmpty()){ job = (entity)q.first(); holdIn("busy", processing_time); } else passivate(); } }
El modelo anterior puede hacerse m as realista si se considera que el tiempo de proceso en lugar de ser constante obedece una determinada distribuci on de probabilidad. Esto puede modelarse de manera sencilla modicando la funci on de transici on externa. Por ejemplo, de la forma siguiente:
holdIn("busy", randExpon(100,2));
El paquete statistics de DEVSJAVA contiene algunas clases para la generaci on de observaciones aleatorias.
6.5.3.
Modelo de un conmutador
En la Secci on 3.3.1 se describi o el modelo de un conmutador. A continuaci on se muestra parte del c odigo de la correspondiente clase, llamada Switch, que se encuentra en el paquete SimpArc.
package SimpArc; import simView.*; import genDevs.modeling.*; import GenCol.*; public class Switch extends ViewableAtomic { protected protected protected protected entity double boolean String job; processing_time; sw; input;
292
DEVSJAVA
public Switch(String name, double Processing_time) { super(name); addInport("in"); addOutport("out"); addInport("in1"); addOutport("out1"); processing_time = Processing_time; phases.add("busy"); } public void initialize() { phase = "passive"; sigma = INFINITY; job = new entity("job"); sw = false; input = new String("in"); super.initialize(); } public void deltext(double e, message x) { Continue(e); if (phaseIs("passive")) { for (int i=0; i< x.getLength();i++) if (messageOnPort(x,"in",i)) { job = x.getValOnPort("in",i); input = "in"; holdIn("busy",processing_time); } for (int i=0; i< x.getLength();i++) if (messageOnPort(x,"in1",i)) { job = x.getValOnPort("in1",i); input = "in1"; holdIn("busy",processing_time); } } sw = !sw; } public void deltint() { passivate(); } public message out() { message m = new message(); if (phaseIs("busy")) { content con;
293
if (!sw && input.equals("in")) else if (!sw && input.equals("in1")) else if (sw && input.equals("in")) else m.add(con); } return m; } }
con con con con
= = = =
makeContent("out", job); makeContent("out1",job); makeContent("out1",job); makeContent("out", job);
6.5.4.
Modelo de un generador
A continuaci on se muestra el modelo DEVSJAVA de un generador de eventos con dos puertos de entrada, start y stop, que controlan el comienzo y la nalizaci on de la generaci on de eventos. Mientras el generador se encuentra en la fase active, genera eventos de salida cada interArrivalTime unidades de tiempo. La clase genr se encuentra en el paquete SimpArc.
package SimpArc; import simView.*; import genDevs.modeling.*; import GenCol.*; public class genr extends ViewableAtomic { protected double interArrivalTime; protected int count; public genr(String name, double interArrivalTime) { super(name); addInport("in"); addOutport("out"); addInport("stop"); addInport("start"); this.interArrivalTime = interArrivalTime ; } public void initialize() { holdIn("active", interArrivalTime); count = 0; super.initialize(); }
294
DEVSJAVA
public void deltext(double e, message x) { Continue(e); if (phaseIs("passive") && somethingOnPort(x,"start")) holdIn("active",interArrivalTime); if (phaseIs("active") && somethingOnPort(x,"stop")) phase = "finishing"; } public void deltint() { count = count + 1; if (phaseIs("active")) holdIn("active",interArrivalTime); else passivate(); } public message out() { return outputNameOnPort("job" + name + count,"out"); } }
Los m etodos somethingOnPort y outputNameOnPort est an denidos en una de las superclases de ViewableAtomic, llamada friendlyAtomic, que est a en el paquete genDevs.modeling. Las declaraciones de los m etodos son las siguientes:
public boolean somethingOnPort(message x, String port); public message outputNameOnPort(String nm, String port);
6.5.5.
Modelo de un generador aleatorio
Puede modicarse el modelo descrito en la Secci on 6.5.4 de modo que el intervalo de tiempo entre sucesivas generaciones de eventos est e distribuido aleatoriamente. La clase genrRand est a en el paquete SimpArc.
package SimpArc; import import import import simView.*; genDevs.modeling.*; GenCol.*; statistics.*;
public class genrRand extends ViewableAtomic {
295
protected protected protected protected
double int rand long
interArrivalTime; count; r; seed;
public genrRand(String name, double InterArrivalTime, long seed) { super(name); this.seed = seed; addInport("stop"); addInport("start"); addOutport("out"); interArrivalTime = InterArrivalTime ; r = new rand(seed); } public void initialize(){ r = new rand(seed); holdIn("active",r.expon(interArrivalTime)); count = 0; super.initialize(); } public void deltext(double e, message x) { Continue(e); if (phaseIs("passive") && somethingOnPort(x,"start")) { holdIn("active",r.uniform(interArrivalTime)); // holdIn("active",r.expon(interArrivalTime)); } if (phaseIs("active") && somethingOnPort(x,"stop")) phase = "finishing"; } public void deltint() { if(phaseIs("active")) { count = count + 1; holdIn("active",r.expon(interArrivalTime)); // holdIn("active",r.uniform(interArrivalTime)); // holdIn("active",r.normal(interArrivalTime,1.0)); } else passivate(); } public message out() { message m = new message(); content con = makeContent("out",new job("job"+name+count,r.expon(1000))); m.add(con);
296
DEVSJAVA
return m; } }
6.5.6.
Modelo de un transductor
El transductor est a dise nado para medir las dos magnitudes siguientes, indicativas del funcionamiento de un proceso: Throughput. Es el n umero medio de entidades que son procesadas por unidad de tiempo. Se calcula como el n umero de entidades procesadas durante el tiempo que dura la simulaci on, dividido por el tiempo que ha durado la simulaci on. Tiempo de ciclo (turnaround time). Es el promedio del tiempo que transcurre entre que una entidad llega al proceso y lo abandona. En un proceso sin cola y con un u nico recurso, el ciclo de vida es igual al tiempo medio de proceso del recurso. El transductor realiza los c alculos necesarios para estimar estas dos medidas del comportamiento. Para ello, mantiene una lista, arrived, en la que almacena el jobid (etiqueta identicativa de la entidad) y el instante de llegada de cada una de la entidades que ha llegado al puerto de entrada ariv del transductor. Cuando la entidad llega al transductor a trav es de su puerto de entrada solved, entonces se a nade la entidad a la lista solved y se calcula su ciclo de vida, es decir, el tiempo transcurrido entre su llegada y su marcha. Las listas arrived y solved son instancias de la clase Function.

Transductor
Figura 6.6: Modelo del transductor.
El transductor mantiene su propio reloj (variable clock) para poder obtener el instante de llegada y de marcha de las entidades. El formalismo DEVS no proporciona a los componentes acceso al reloj de la simulaci on. Por ello, si los modelos
297
necesitan conocer el valor del tiempo, deben gestionar su propio reloj. Esto puede hacerse de manera sencilla a partir de la informaci on del tiempo transcurrido, que est a disponible en las variables y e. Obs ervese que el comportamiento del transductor est a dictado esencialmente por su funci on de transici on externa. En el modelo del transductor u nicamente se usa una transici on interna para producir una salida al nal del intervalo de observaci on durante el cual se est an calculando el throughput y el tiempo de ciclo. A continuaci on, se muestra parte del c odigo de la clase transd, que est a situada en el paquete SimpArc. Obs ervese que cualquier modelo at omico puede escribir en la consola o en un chero, por ejemplo, con la nalidad de registrar los instantes en que se producen los eventos. V ease el m etodo show state de la clase transd.
package SimpArc; import simView.*; import genDevs.modeling.*; import GenCol.*; public class transd extends ViewableAtomic { protected Function arrived, solved; protected double clock, total_ta, observation_time; public transd(String name, double Observation_time) { super(name); addOutport("out"); addInport("ariv"); addInport("solved"); arrived = new Function(); solved = new Function(); observation_time = Observation_time; } public void phase sigma clock total_ta arrived solved } initialize() { = "active"; = observation_time; = 0; = 0; = new Function(); = new Function();
public void deltext(double e, message x) { clock = clock + e; Continue(e);
298
DEVSJAVA
entity val; for (int i=0; i < x.size(); i++) { if (messageOnPort(x,"ariv",i)) { val = x.getValOnPort("ariv",i); arrived.put(val.getName(), new doubleEnt(clock)); } if (messageOnPort(x,"solved",i)) { val = x.getValOnPort("solved",i); if (arrived.containsKey(val.getName())) { entity ent = (entity)arrived.assoc(val.getName()); doubleEnt num = (doubleEnt)ent; double arrival_time = num.getv(); double turn_around_time = clock - arrival_time; total_ta = total_ta + turn_around_time; solved.put(val, new doubleEnt(clock)); } } } // final del bucle for show_state(); } public void deltint() { clock = clock + sigma; passivate(); show_state(); } public message out() { message m = new message(); content con = makeContent("out", new entity("TA: "+compute_TA())); m.add(con); return m; } public double compute_TA() { double avg_ta_time = 0; if (!solved.isEmpty()) avg_ta_time = ((double)total_ta)/solved.size(); return avg_ta_time; } public double compute_Thru() { double thruput = 0; if(clock > 0) thruput = solved.size()/(double)clock; return thruput; }
299
public void show_state() { System.out.println("state of " + name + ": "); System.out.println("phase, sigma : " + phase + " " + sigma + " "); if (arrived != null && solved != null) { System.out.println(" jobs arrived :"); // arrived.print_all(); System.out.println("total :" + arrived.size()); System.out.println("jobs solved :"); // solved.print_all(); System.out.println("total :" + solved.size()); System.out.println("AVG TA = " + compute_TA()); System.out.println("THRUPUT = " + compute_Thru()); } } }
6.6.
MODELOS DEVS COMPUESTOS Y JERARQUICOS
En esta secci on se muestran varios ejemplos que ilustran la descripci on de modelos compuestos usando DEVSJAVA.
6.6.1.
Modelo de una secuencia de etapas
En la Secci on 3.4.1 se describi o el modelo compuesto por tres etapas en serie, que es mostrado en la Figura 6.7.
pipeline
Figura 6.7: Pipeline compuesta por tres etapas.
A continuaci on, se muestra parte de la descripci on de este modelo compuesto usando DEVSJAVA. La clase pipeSimple se encuentra en el paquete SimpArc.
package SimpArc; import java.awt.*; import simView.*;
300
DEVSJAVA
import GenCol.*; public class pipeSimple extends ViewableDigraph { public pipeSimple(String name, double proc_time) { super(name); make(proc_time); addInport("in"); addOutport("out"); } private void make (double proc_time) { ViewableAtomic p0 = new proc("proc0", proc_time/3); ViewableAtomic p1 = new proc("proc1", proc_time/3); ViewableAtomic p2 = new proc("proc2", proc_time/3); add(p0); add(p1); add(p2); addCoupling(this, "in", p0, "in"); addCoupling(p0, "out", p1, "in"); addCoupling(p1, "out", p2, "in"); addCoupling(p2, "out", this, "out"); initialize(); } }
6.6.2.
Marco experimental
En la Secci on 1.8.3 se introdujo el concepto de marco experimental. Se explic o que el marco experimental puede interpretarse como un sistema que interact ua con el sistema de inter es para obtener observaciones, bajo determinadas condiciones experimentales, estando t picamente compuesto por los tres elementos mostrados en la Figura 1.7): Generador Receptor Genera las secuencias de entrada al sistema. Monitoriza el experimento, para comprobar que se satisfacen las condiciones experimentales requeridas.
301
Transductor
Observa y analiza las secuencias de salida del sistema, calculando medidas del comportamiento del mismo, tales como el throughput y el tiempo de ciclo, que eran de inter es en el modelo de la Secci on 6.5.6, o la utilizaci on de los recursos, la ocurrencia de ciertos eventos como fallos o bloqueos, el valor m aximo o m nimo de ciertas magnitudes, etc.
Pueden conectarse entre s instancias de las clases genr y transd, descritas en las Secciones 6.5.4 y 6.5.6, con el n de modelar un marco experimental (experimental frame), tal como se muestra en la Figura 6.8.
ef
Generador
Transductor
Figura 6.8: Marco experimental y sus componentes.
El marco experimental tiene los tres puertos de entrada siguientes:

in start, stop Recibe las entidades ya procesadas, que son enviadas al puerto solved del transductor. Controlan el comienzo y nalizaci on de la generaci on de entidades en el generador.
y los dos puertos de salida siguientes:

out result Transmite los identicadores de las entidades creadas por el generador. Transmite las medidas del comportamiento calculadas por el transductor.
El marco experimental contiene dos conexiones internas:
302
DEVSJAVA
El puerto de salida del generador env a los identicadores de las entidades al puerto ariv del transductor. El puerto out del transductor env a las medidas calculadas del comportamiento al puerto stop del generador. Obs ervese que cuando el generador genera una entidad, en el mismo instante de tiempo esta llega al puerto ariv del transductor y a los puertos de entrada de los componentes externos conectados al puerto out del marco experimental. Igualmente, pueden conectarse varios puertos de salida a un mismo puerto de entrada. Esto no es un problema en DEVS paralelo, ya que las bolsas pueden alojar varios eventos que llegan simult aneamente a un puerto de entrada. A continuaci on, se muestra parte del c odigo de la clase ef, que est a situada en el paquete SimpArc.
package SimpArc; import simView.*; import java.awt.*; import GenCol.*; public class ef extends ViewableDigraph { public ef(String nm, double int_arr_t, double observe_t) { super(nm); efConstruct(int_arr_t, observe_t); } public void efConstruct(double int_arr_t, double observe_t) { addInport("in"); addOutport("out"); addOutport("result"); ViewableAtomic g = new genr("g", int_arr_t); ViewableAtomic t = new transd("t", observe_t); add(g); add(t); addTestInput("start", new entity()); addTestInput("stop", new entity()); addTestInput("in", new entity("jobg0")); addTestInput("in", new entity("job0")); addTestInput("in", new entity("job1")); initialize(); addCoupling( g, "out", t, "ariv" ); addCoupling( this, "in", t, "solved" ); addCoupling( t, "out", g, "stop" );
303
addCoupling( addCoupling( addCoupling( addCoupling( } }
this, this, g, t,
"start", "stop", "out", "out",
g, g, this, this,
"start" "stop" "out" "result"
); ); ); );
6.6.3.
Modelo de una red de conmutaci on
En la Secci on 3.4.2 se describi o el modelo de la red de conmutaci on mostrada en la Figura 6.9. La clase netSwitch, que se encuentra en el paquete SimpArc, representa dicha red de conmutaci on y su marco experimental. Puede emplearse simView para visualizar el diagrama de la clase (v ease la Figura 6.10) y para ejecutar la simulaci on.
package SimpArc; import java.awt.*; import simView.*; import GenCol.*; public class netSwitch extends ViewableDigraph { public netSwitch() { super("netSwitch"); addInport("in"); addOutport("out"); ViewableDigraph ef = new ef("ef", 20, 500); ViewableAtomic s0 = new Switch("switch0", 2.5); ViewableAtomic p0 = new proc("proc0", 5); ViewableAtomic p1 = new proc("proc1", 10); add(ef); add(s0); add(p0); add(p1); initialize(); showState(); addCoupling(this, "in", s0, "in"); addCoupling(ef, "out", s0, "in"); addCoupling(p0, "out", this, "out"); addCoupling(p1, "out", this, "out"); addCoupling(s0, "out", p0, "in"); addCoupling(s0, "out1", p1, "in"); addCoupling(p0, "out", ef, "in"); addCoupling(p1, "out", ef, "in"); } }
304
DEVSJAVA
Figura 6.10: Diagrama de la clase netSwitch.
305
6.7.
SIMVIEW
SimView (DEVSJAVA Simulation Viewer) es una aplicaci on, escrita por J. Mather (Mather 2003), que extiende DEVSJAVA con objeto de permitir visualizar la estructura y el comportamiento de los modelos DEVS. Se distribuye en el paquete simView del chero coreDEVS.jar. La clase SimView contiene el m etodo main que debe ejecutarse para arrancar la aplicaci on. A continuaci on se describen algunas de las capacidades para la visualizaci on y simulaci on del modelo que ofrece SimView.
Representaci on modular y jer arquica Muestra los componentes del modelo, de manera jer arquica, sus puertos y la conexi on entre los puertos. Obs ervese la Figura 6.10, en la cual est a representada la estructura modular de cada uno de los niveles jer arquicos del modelo. El recuadro externo representa la clase netSwitch, dentro del cual se sit uan tres componentes at omicos (switch0, proc0 y proc1), que son representados mediante rect angulos opacos, y un modelo compuesto (ef), que es representado mediante un recuadro, dentro del cual se muestran sus dos componentes at omicos (g y t), representados mediante rect angulos opacos. Los componentes compuestos pueden representarse o bien mostrando su estructura interna (blackbox=false) o bien como cajas negras (blackbox=true). El m etodo
void setBlackBox( boolean blackBox )
de la clase simView.ViewableDigraph permite especicar si debe o no mostrarse la estructura interna del componente. Por ejemplo, en el modelo de la red de conmutaci on puede hacerse que el marco experimental sea representado como una caja negra mediante: ef.setBlackBox(true). SimView permite cambiar la posici on de un componente pinchando sobre el y arrastrando.
Control de la simulaci on Permite, mediante los botones step y run, ejecutar la simulaci on paso a paso o en modo continuo.
306
DEVSJAVA
Mediante el deslizador real time factor, permite ejecutar la simulaci on jando la relaci on entre el reloj de la simulaci on y el tiempo f sico. En particular, permite realizar simulaciones en tiempo real. En este caso, el reloj de la simulaci on es sincronizado con el tiempo f sico, de modo que los eventos son planicados en base al tiempo f sico.
Animaci on Proporciona una animaci on visual de los mensajes que se transmiten a trav es de las conexiones entre los componentes, en cada paso de la simulaci on. En la Figura 6.11 se muestra el mensaje jobg0, generado en el puerto out del generador g, viajando a trav es de las conexiones a los componentes t y switch0.
Informaci on en tiempo de simulaci on Proporciona informaci on durante la simulaci on del estado actual de cada componente. Para cada componente at omico se muestra el valor actual de phase y sigma, y situando el cursor sobre el componente se muestra informaci on adicional. Por defecto, el valor de tL y tN. En el c odigo Java del componente puede especicarse qu e otra informaci on debe mostrarse. Para ello, debe usarse el m etodo getTooltipText, de la clase simView.ViewableAtomic. Por ejemplo, en la Figura 6.12 se muestra el cuadro informativo (tool-tip window) que aparece al situar el cursor sobre el componente proc0. Obs ervese que se muestra el String devuelto por el m etodo getTooltipText de la clase proc:
public String getTooltipText() { return super.getTooltipText() + "\n" + "job: " + job.getName(); }
Experimentaci on con el modelo Durante la simulaci on, permite inyectar eventos externos en los puertos de entrada. Haciendo clic sobre cualquiera de los puertos de entrada de un componente, aparece una lista con los eventos que pueden ser inyectados. En dicha lista, para cada evento se especica: el puerto de entrada, el valor y el tiempo e que debe esperarse, empezando a contar desde el instante actual, para inyectar el evento.
307
Figura 6.11: Visualizaci on de los mensajes transmitidos por las conexiones.
Figura 6.12: Visualizaci on del estado de los componentes.
308
DEVSJAVA
SimView muestra un mensaje de error si el usuario trata de inyectar un evento con un valor de e mayor que el tiempo que queda hasta el siguiente evento interno del componente. Por ejemplo, haciendo clic sobre cualquiera de los dos puertos de entrada del componente proc0 se abre la ventana mostrada en la Figura 6.13, en la que se muestran los valores puerto-valor-e. Para inyectar el evento in-job2-5.0, se selecciona este en la lista y se pulsa el bot on inject. Dentro de 5 unidades de tiempo, se producir a un evento de valor job2 en el puerto in del componente proc0. Los eventos que aparecen en la lista deben denirse en el c odigo del componente, empleando para ello el m etodo addTestInput. Por ejemplo, se ha realizado la denici on siguiente en la clase proc.
public proc(String name,double Processing_time){ super(name); addInport("in"); addOutport("out"); addInport("none"); // allows testing for null input // which should cause only "continue" processing_time = Processing_time; addTestInput("in", new entity("job1") ); addTestInput("in", new entity("job2"), 5); addTestInput("none", new entity("job"), 10); addTestInput("in", new entity("job"), 20); }
Visualizaci on de los resultados Pueden visualizarse los resultados de la simulaci on, por ejemplo, representando gr acamente la evoluci on de algunas variables del modelo, empleando la clase CellGridPlot, que se encuentra en el paquete genDevs.plots. En la Figura 6.14 se muestra un ejemplo de uso de esta clase. Las instancias de la clase CellGridPlot se emplean de la misma forma que cualquier otro componente DEVS. Tal como se muestra en la Figura 6.15, la clase tiene una serie de puertos, cada uno de los cuales espera recibir un determinado tipo de entidad y realiza un determinado tipo de representaci on gr aca de dichas entidades. Los puertos de entrada timePlot y pulsePlot aceptan entidades del tipo doubleEnt.
309
Figura 6.13: Lista de eventos que pueden ser inyectados en los puertos de entrada del componente proc0.
Figura 6.14: En la clase Continuity.missileSpace puede encontrarse un ejemplo de uso de genDevs.plots.CellGridPlot.
310
DEVSJAVA
CellGridPlot
Figura 6.15: Puertos de la clase CellGridPlot.
timePlot pulsePlot
Muestra trayectorias frente al tiempo. Dibuja l neas verticales desde el eje x cuya altura representa los datos representados.
Por defecto, las instancias de la clase CellGridPlot est an ocultas. Si se desea que una instancia sea visible, debe invocarse su m etodo setHidden(false). La representaci on gr aca se realiza durante la simulaci on. Puede controlarse el aspecto gr aco de los valores pasados. Por ejemplo, pueden ir borr andose (dibuj andolos de color blanco) o difumin andose (usando colores suaves). El argumento delay del constructor determina el tama no del intervalo de tiempo que no es difuminado. En la clase boxCar, que est a contenida en el paquete pulseModels, puede encontrarse un ejemplo de uso de la clase CellGridPlot:
311
6.8.
Los ejercicios propuestos a continuaci on est an basados en el contenido del art culo DEVS Component-Based M&S Framework: an Introduction Bernard P. Zeigler, Hessan S. Sarjoughian que puede encontrar en el chero lectura6a.pdf. Por favor, lea en primer lugar este art culo. A continuaci on, resuelva los ejercicios.
Ejercicio 6.1 Suponga que el comportamiento de una neurona que puede emitir un u nico impulso es el siguiente. Inicialmente la neurona se encuentra en el estado receptivo. Cuando llega un evento externo, la neurona pasa al estado disparo, en el cual permanece durante un cierto tiempo, que es un par ametro del modelo denominado tiempo de disparo. Trascurrido ese tiempo, la neurona emite un impulso y pasa al estado refractario, en el cual permanece indenidamente, y en el cual ignora cualquier evento de entrada. En la Figura 6.16 se muestra esquem aticamente el diagrama de estados de la neurona. Escriba la descripci on del modelo de la neurona empleando el formalismo DEVS cl asico.
#$% 3 4&5&678 &'()*+ (,* (-)+ &'()*+ .)*(-)+ &'()*+ /( 012./1
3
! "
Figura 6.16: Neurona de un u nico disparo.
312
DEVSJAVA
Ejercicio 6.2 En la Figura 6.17 se muestra una red compuesta por cuatro neuronas de un u nico disparo, como las descritas en el Ejercicio 6.1, y un generador. Describa este sistema compuesto empleando el formalismo DEVS. Explique c omo pueden aplicarse redes neuronales en la b usqueda del camino m as corto entre dos puntos (vea la explicaci on dada en el Apartado 2.4 de lectura6a.pdf).

Figura 6.17: Red neuronal.
Ejercicio 6.3 Inspeccione los modelos reOnceNeuron y reOnceNeuronNet contenidos en el paquete pulseModels, que est a en el chero IllustrationCode.zip. Discuta las similitudes y diferencias entre el comportamiento descrito en estos modelos y los descritos para la neurona y la red en los Ejercicios 6.1 y 6.2.
Ejercicio 6.4 Modique el modelo DEVS de la neurona que ha realizado en el Ejercicio 6.1, de modo que si llega un evento externo mientras la neurona est a en el estado disparo,
313
entonces se cancela el impulso de salida que estaba planicado y la neurona pasa inmediatamente al estado refractario. Modique la clase reOnceNeuron con el n de describir este comportamiento.
Ejercicio 6.5 Modique el modelo DEVS de la neurona que ha realizado en el Ejercicio 6.1 de modo que si llega un evento externo mientras la neurona est a en el estado disparo, entonces se cancela el impulso de salida que estaba planicado y se planica un nuevo impulso de salida para dentro de un tiempo determinado por el par ametro tiempo de disparo. Una vez generado el impulso, la neurona pasa al estado refractario. Modique la clase reOnceNeuron con el n de describir este comportamiento.
314
DEVSJAVA
6.9.
Soluci on al Ejercicio 6.1 El modelo de la neurona tiene un puerto de entrada y un puerto de salida, ambos de eventos discretos. Llamemos Input y Output a estos dos puertos. Los eventos en estos puertos tienen valor {pulse}. X = (Input, {pulse}) Y = (Output, {pulse}) El modelo tiene dos variables de estado: La variable f ase describe el modo de funcionamiento en que se encuentra la neurona: receptivo, disparo o refractario. As pues, tiene tres posibles valores: {receptivo, disparo, refractario }. La variable almacena el tiempo que queda hasta que se produzca, en ausencia de eventos externos, la siguiente transici on interna. Dado que la variable f ase puede tomar valores reales positivos, incluyendo el cero, el conjunto de estados secuenciales es: S = {receptivo, disparo, ref ractario} R+ 0 La funci on de transici on externa dene el nuevo estado de la neurona cuando llega un evento al puerto de entrada. Si la neurona est a en el estado receptivo y se recibe un evento, entonces pasa al estado disparo. Mientras a neurona est a en el estado disparo o refractario, ignora los eventos de entrada.
La funci on de salida, la funci on de transici on interna y la funci on de avance en el tiempo son las siguientes:
(disparo, tiempoDeDisparo) si f ase = receptivo ext ((f ase, ), e, x) = (disparo, e) si f ase = disparo (ref ractario, ) si f ase = ref ractario
315
(f ase, ) = (Output, {pulse}) int (f ase, ) = (ref ractario, ) ta (f ase, ) = Si bien no se pide en el enunciado, podr a realizarse la especicaci on DEVS paralelo de la neurona. Adem as de los elementos anteriores, la especicaci on deber a contener: La funci on de transici on conuyente, que especica el cambio en el estado que se produce cuando llega un evento externo en el mismo instante en que est a planicada una transici on interna. En este caso: con ((f ase, ), e, x) = int (f ase, ) Contemplar la posibilidad de que lleguen simult aneamente varios eventos al puerto de entrada. En este modelo el comportamiento no depende de que se reciba un u nico evento o varios simult aneamente.
Soluci on al Ejercicio 6.2 El modelo compuesto engloba los cinco componentes: el generador y las cuatro neuronas. La interfaz del modelo compuesto tiene u nicamente un puerto de salida, al cual est a conectado el puerto de salida de la neurona #4. Llamaremos pulseOut al puerto de salida del modelo compuesto. La descripci on formal DEVS paralelo del modelo compuesto es la siguiente. N = X, Y, D, {Md | d D }, EIC, EOC, IC donde: X= Y = (pulseOut, {pulse})
El modelo compuesto no tiene ning un puerto de entrada. Puerto de salida del modelo compuesto y valor de los eventos.
(6.1)
316
DEVSJAVA
D = {G, N1 , N2 , N3 , N4 } MG , MN1 , MN2 , MN3 , MN4 EIC = EOC = {(N4 , pulseOut), (N, pulseOut)}
Conjunto de nombres de los componentes. Cada componente es un modelo DEVS. No hay conexiones externas de entrada.
Conexi on del puerto de salida de N4 al puerto de salida del modelo compuesto.
Los modelos de redes de neuronas pueden emplearse para encontrar el camino m as corto a trav es de una red. Para ello, hay que transformar las distancias entre nodos en valores equivalente del tiempo. Este valor se asigna como tiempo de disparo de la neurona que representa el nodo de la red. Por ejemplo, en la red mostrada en la Figura 6.17, el impulso emitido por el generador recorre dos caminos concurrentemente hasta que llega a la neurona nal (la neurona #4). Dependiendo de la suma de retardos a lo largo de cada camino, el impulso proveniente de cada camino alcanzar a en un instante u otro la neurona nal. El instante en el cual la neurona nal emite su impulso de salida permite calcular el camino m as corto a trav es de la red. Con el n de poder reconstruir el camino, puede modicarse el modelo de la neurona de manera que desde cada neurona receptora sea posible identicar qu e neurona emisora ha disparado el impulso que ha llegado en primer lugar a dicha neurona receptora.
((G, pulseOut), (N1 , pulseIn)) , ((G, pulseOut), (N3 , pulseIn)) , IC = ((N1 , pulseOut), (N2 , pulseIn)) , ((N2 , pulseOut), (N4 , pulseIn)) , ((N3 , pulseOut), (N4 , pulseIn))
Soluci on al Ejercicio 6.3 El modelo tiene dos variables de estado, phase y sigma, que ya est an denidas en la superclase y por tanto no se denen en reOnceNeuron. Asimismo, la funci on de avance en el tiempo est a denida por defecto de manera que devuelve el valor sigma.
317
El comportamiento del modelo de la neurona est a denido mediante los m etodos mostrados a continuaci on: inicializaci on, funciones de transici on interna, externa y conuyente, y de salida.
public void initialize() { super.initialize(); passivateIn("receptive"); } public void deltext(double e,message x) { Continue(e); if ( phaseIs("receptive") && somethingOnPort(x,"in") ) holdIn("fire",fireDelay); } public void deltint() { if (phaseIs("fire")) passivateIn("refract"); } public void deltcon(double e,message x) { deltint(); } public message out() { if (phaseIs("fire")) return outputNameOnPort("pulse","out"); else return new message(); }
A continuaci on, se describen las acciones ejecutadas en cada uno de los m etodos. El m etodo initialize() asigna valor inicial a las variables de estado:
public void initialize() { super.initialize(); passivateIn("receptive"); }
El m etodo passivateIn("receptive") asigna el valor receptive a la variable de estado phase y asigna a la variable de estado sigma el valor INFINITY. La consecuencia de ello es que en ausencia de eventos externos el modelo permanece indenidamente en el modo receptive. El siguiente m etodo describe la funci on de transici on externa:
318
DEVSJAVA
public void deltext(double e,message x) { Continue(e); if ( phaseIs("receptive") && somethingOnPort(x,"in") ) holdIn("fire",fireDelay); }
Las acciones realizadas en la funci on son: 1. Se ejecuta el m etodo Continue(e), que est a denido de la manera siguiente:
public void Continue(double e) { if (sigma < INFINITY) sigma = sigma - e; }
Si sigma vale INFINITY, entonces no se modica su valor. En caso contrario, se reduce el valor de sigma en e. Es decir: sigma = sigma e. 2. Si el valor de la variable de estado phase es receptive, entonces se ejecuta holdIn("fire",fireDelay), cuyo efecto es asignar a phase el valor re y a sigma el valor reDelay (par ametro tiempo de disparo). Puede verse que estas acciones corresponden con la funci on de transici on externa denida al responder al Ejercicio 6.1.
(disparo, tiempoDeDisparo) si f ase = receptivo ext ((f ase, ), e, x) = (disparo, e) si f ase = disparo (ref ractario, ) si f ase = ref ractario El siguiente m etodo describe la funci on de transici on interna:
public void deltint() { if (phaseIs("fire")) passivateIn("refract"); }
La acci on realizada al ejecutar este m etodo es la siguiente: si phase tiene el valor re, entonces la variable de estado phase se pone al valor refract y sigma al valor INFINITY. Esta denici on concuerda con la dada al resolver el Ejercicio 6.1, donde se ha supuesto que la funci on s olo es invocada cuando el modelo se encuentra en la fase disparo.
319
int (f ase, ) = (ref ractario, ) La funci on de transici on conuyente es igual a la funci on de transici on interna (v ease el m etodo deltcon). El comportamiento de la funci on de salida es el siguiente (v ease el m etodo out): si phase vale re, entonces la funci on de salida env a un evento de valor pulse a trav es del puerto de salida out. A continuaci on, puede verse c omo en la clase reOnceNeuronNet se dene el puerto de salida, los componentes de la red de neuronas, y las conexiones entre ellos y con el puerto de salida.
addOutport("out"); /* New a pulseGenr object */ ViewableAtomic pg = new pulseGenr("pg",100); add(pg); /* New Fireonce Neuron object 1 */ ViewableAtomic fon1 = new fireOnceNeuron("fireonce-neuron1",f1_firedelay); add(fon1); /* New Fireonce Neuron object 2 */ ViewableAtomic fon2 = new fireOnceNeuron("fireonce-neuron2",f2_firedelay); add(fon2); /* New Fireonce Neuron object 3 */ ViewableAtomic fon3 = new fireOnceNeuron("fireonce-neuron3",f3_firedelay); add(fon3); /* New Fireonce Neuron object 4 */ ViewableAtomic fon4 = new fireOnceNeuron("fireonce-neuron4",f4_firedelay); add(fon4); /* ** pg: output ---> fon1:input ** pg: output ---> fon3:input ** fon1: output ---> fon2:input ** fon2: output ---> fon4:input ** fon3: output ---> fon4:input */ addCoupling(pg,"out",fon1,"in"); addCoupling(pg,"out",fon3,"in"); addCoupling(fon1,"out",fon2,"in"); addCoupling(fon2,"out",fon4,"in"); addCoupling(fon3,"out",fon4,"in"); addCoupling(fon4,"out",this,"out");
320
DEVSJAVA
Soluci on al Ejercicio 6.4 S olo ser a necesario modicar la funci on de transici on externa, que ser a la siguiente:
(disparo, tiempoDeDisparo) si f ase = receptivo ext ((f ase, ), e, x) = (ref ractario, ) si f ase = disparo (ref ractario, ) si f ase = ref ractario Esta funci on de transici on externa podr a codicarse de la forma siguiente:
public void deltext(double e,message x) { if ( phaseIs("receptive") && somethingOnPort(x,"in") ) holdIn("fire",fireDelay); else passivateIn("refract"); }
Soluci on al Ejercicio 6.5 Ser a necesario modicar u nicamente la funci on de transici on externa, que ser a la siguiente:
(disparo, tiempoDeDisparo) si f ase = receptivo ext ((f ase, ), e, x) = (disparo, tiempoDeDisparo) si f ase = disparo (ref ractario, ) si f ase = ref ractario Esta funci on de transici on externa podr a codicarse de la forma siguiente:
public void deltext(double e,message x) { if ( ( phaseIs("receptive") || phaseIs("fire") ) && somethingOnPort(x,"in") ) holdIn("fire",fireDelay); else passivateIn("refract"); }
321
Indice alfab etico
acoplamiento modular, 27 no modular, 27 acumulador estad stico, 93, 96 an alisis por reducci on, 26 atributo, 95 aut omata celular, 54 conmutado, 59 base de tiempo, 51 BD del conocimiento, 28, 29 biestable, 59 tipo D, 59 bolsa de elementos, 202 calendario de eventos, 90, 155 causalidad computacional, 71 asignaci on, 77, 78 CD++, 271 cierre bajo acoplamiento, 27 cola, 96 comportamiento E/S, 23 correcci on del simulador, 34 derivada, 63 DEVS cl asico, 125 multicomponente, 170 paralelo, 125, 201 DEVSJAVA clase atomic, 283 Bag, 280
binaryCounter, 279 classic, 286 contenedor, 280 devs, 282 digraph, 285 doubleEnt, 280 ef, 301 entity, 280 Function, 280, 297 generator, 277 genr, 294 genrRand, 295 intEnt, 280 message, 283 netSwitch, 304 Pair, 280 passive, 273 pipeSimple, 300 proc, 288 procQ, 291 Queue, 280 Relation, 280 SimView, 272, 277 siso, 273, 287 storage, 275 Switch, 292 transd, 297 chero coreDEVS.jar, 271 IllustrationCode.zip, 273 m etodo continue, 276
322
INDICE ALFABETICO
Deltext, 274, 287 deltint, 274 holdIn, 274 main, 272, 306 passivate, 274 passivateIn, 274 phaseIs, 276 sisoOut, 274 paquete Continuity, 272 GenCol, 271 genDevs, 271 genDevs.modeling, 271 genDevs.plots, 271 genDevs.simulation, 271 oneDCellSpace, 272 pulseExpFrames, 272 pulseModels, 272 Quantization, 273 Random, 273 SimpArc, 272 simView, 272 statistics, 272 twoDCellSpace, 272 util, 272 variable phase, 275 sigma, 275 discretizaci on temporal, 18 ecuaciones, 63 entidad, 93 instanciaci on, 93 realizaci on, 93 estado inicial, 24 pasivo, 127 transitorio, 127 estad stico
acumulador, 93 n umero entidades en cola, 91 tiempo espera en cola, 91 evento, 93, 96 bolsa, 202 calendario, 90 condici on de, 232 condici on de disparo, 97 en el estado, 90, 232 en el tiempo, 90, 232 externo, 86 ujo de acciones, 93, 97 interno, 86 planicaci on, 90 simult aneos, 89, 201 experimento, 12 factor ambiental, 85 factor de ganancia, 61 delidad, 33 ip-op, 59 formalismo, 19 funci on de salida, 53 de transici on de estado, 52 ingenier a inversa, 21 integraci on m etodo de Euler, 68, 81 m etodo de Euler-Richardson, 82 m etodo de Runge-Kutta, 83 m etodo de Runge-Kutta-Fehlberg, 83 tama no del paso, 68 integraci on num erica, 63 arranque, 251 m etodo causal, 250 m etodo no causal, 252 interfaz, 21 JDEVS, 271
323
Juego de la Vida, 55, 85, 174 Klir, G.J., 19 linealidad, 61 maquina secuencial de Mealy, 59 de Moore, 59 marco de observaci on, 22 marco experimental, 16, 28, 29, 301 generador, 30, 277 receptor, 30 transductor, 30, 31, 297 medidas de salida, 31 mensaje, 155 mensaje-*, 155 mensaje-i, 155 mensaje-x, 155 mensaje-y, 155 modelado eventos discretos orientado a eventos, 97 orientado a procesos, 98 modelo, 11, 28, 32 complejidad, 26, 34 de tiempo continuo, 18 de tiempo discreto, 18 determinista, 16 din amico, 17 estoc astico, 17 est atico, 17 f sico, 15 h brido, 18 jer arquico, 27 matem atico, 15, 16 mental, 14 modular, 27 parametrizar, 95 simplicado, 34 singular, 77
SISO, 125 verbal, 15 modularidad, 22, 27, 175 modularizaci on, 176 multiDEVS, 170 m etodo experimental, 13 n umero entidades en cola, 91 Ohm, ley de, 71 parametro, 64 partici on, 71 paso de integraci on, 68 periodo de muestreo, 51 precisi on, 33 puerto de la interfaz, 22, 23 recurso, 96 individual, 96 unidad de, 96 red de Moore, 60 registro de desplazamiento, 60 relaci on de modelado, 28, 33 de simulaci on, 28, 34 reloj de la simulaci on, 51, 90, 95, 297 representaci on matricial, 61 retardo, 61 simulaci on, 15 condici on de terminaci on, 68 de eventos discretos, 89 de tiempo continuo, 66 de tiempo discreto, 53 reloj, 90 tiempo real, 307 simulador, 28, 32 abstracto, 154 Devs-coordinator, 153 Devs-root-coordinator, 154
324
INDICE ALFABETICO
Devs-simulator, 153 SimView, 277, 304, 306 singularidad estructural, 77 sistema, 11 an alisis, 20 comportamiento externo, 26 conocimiento, 19 dise no, 20 especicaci on, 22 estructura interna, 26 experto, 15 fuente, 19 inferencia, 20 sistema fuente, 28 sumador, 61 tabla de transici on/salidas, 52 throughput, 297 tiempo de ciclo, 297 tiempo espera en cola, 91 transici on externa, 127 interna, 127 trayectoria, 22, 28 de entrada, 125 de estados, 53 de salida, 125 validez, 33 estructural, 33 predictiva, 33 replicativa, 33 variable, 95 algebraica, 64, 68, 74 clasicaci on, 64 conocida, 73 de estado, 63, 64, 66, 74 de salida, 31 desconocida, 74 par ametro, 66
rango, 22 variables, 63 Zeigler, B.P., 21
325
326
Bibliograf a
Cellier, F. C. (1991), Continuous System Modeling, Springer-Verlag. Chow, A. (1996), Parallel DEVS: A parallel, hierarchical, modular modeling formalism and its distributed simulator, Transactions of the Society for Computer Simulation International 13(2), 5568. Gardner, M. (1970), The fantastic combinations of John Conways new solitaire game of life, Scientic American 23(4), 120123. Kelton, W. D., Sadowski, R. P. & Sadowski, D. A. (2002), Simulation with Arena, McGraw-Hill. Klir, G. J. (1985), Architecture of Systems Complexity, Sauders, New York. Ljung, L. & Torkel, G. (1994), Modeling of Dynamic Systems, Prentice-Hall. Mather, J. (2003), The DEVSJAVA Visualization Viewer: a Modular GUI that Visualizes the Structure and Behavior of Hierarchical DEVS Models, Master Thesis, Dept. Electrical and Computer Engineering, The University of Arizona. Pedgen, C. D., Shannon, R. E. & Sadowsky, R. P. (1995), Introduction to Simulation Using SIMAN, McGraw-Hill. Urquia, A. (2003), Simulaci on - Texto Base de Teor a, Texto base de la asignatura er Simulaci on, de 3 curso de la Ingenier a T ecnica en Inform atica de Gesti on de la UNED. Wolfram, S. (1986), Theory and Application of Cellular Automata, World Scientic, Singapore. Zeigler, B. P. (1976), Theory of Modelling and Simulation, Wiley Interscience. Zeigler, B. P. (1990), Object-Oriented Simulation with Hierarchical, Modular Models, Academic Press.
327
Zeigler, B. P. (2003), DEVS today: recent advances in discrete event-based information technology, 11th IEEE/ACM International Symposium on Modeling, Analysis and Simulation of Computer Telecommunications Systems, MASCOTS 2003, pp. p ags. 148161. Zeigler, B. P., Praehofer, H. & Kim, T. G. (2000), Theory of Modeling and Simulation, Academic Press. Zeigler, B. P. & Sarjoughian, H. S. (2005), Introduction to DEVS modeling and simulation with JAVA: developing component-based simulation models, Disponible en: http://www.acims.arizona.edu/SOFTWARE/software.shtml.
328

Simulacion Textobase

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Simulacion Textobase

Caricato da

Copyright:

Formati disponibili

MODELADO DE SISTEMAS MEDIANTE DEVS

Texto base de la asignatura Modelado de Sistemas Discretos de la Ingeniera en Informtica de la UNED

1. Introducci on al modelado y la simulaci on

MODELADO DE SISTEMAS MEDIANTE DEVS

MODELADO DE SISTEMAS MEDIANTE DEVS

MODELADO DE SISTEMAS MEDIANTE DEVS

TEMA 1 AL MODELADO INTRODUCCION Y LA SIMULACION

AL MODELADO Y LA SIMULACION INTRODUCCION

AL MODELADO Y LA SIMULACION INTRODUCCION

SISTEMAS, MODELOS Y EXPERIMENTACION

Denici on de los t erminos modelo y sistema

MODELADO DE SISTEMAS MEDIANTE DEVS

Experimentaci on con el sistema real

AL MODELADO Y LA SIMULACION INTRODUCCION

Experimentaci on con el modelo

MODELADO DE SISTEMAS MEDIANTE DEVS

EXPERIMENTAR CON EL SISTEMA REAL

EXPERIMENTAR CON EL MODELO DEL SISTEMA

Figura 1.1: Formas de estudiar un sistema.

AL MODELADO Y LA SIMULACION INTRODUCCION

Modelos matem aticos

MODELADO DE SISTEMAS MEDIANTE DEVS

DE LOS MODELOS MATEMATICOS CLASIFICACION

Determinista o estoc astico

AL MODELADO Y LA SIMULACION INTRODUCCION

Est atico o din amico

MODELADO DE SISTEMAS MEDIANTE DEVS

Tiempo continuo o discreto

AL MODELADO Y LA SIMULACION INTRODUCCION

xK +1 xK = f (xK , uK , tK ) xK +1 = xK + t f (xK , uK , tK ) t 1.5. NIVELES EN EL CONOCIMIENTO DE LOS SISTEMAS

Niveles en el conocimiento de un sistema

MODELADO DE SISTEMAS MEDIANTE DEVS

An alisis, inferencia y dise no

AL MODELADO Y LA SIMULACION INTRODUCCION

DE SISTEMAS JERARQU IA EN LA ESPECIFICACION

MODELADO DE SISTEMAS MEDIANTE DEVS

Nivel 0 - Marco de observaci on

AL MODELADO Y LA SIMULACION INTRODUCCION

rayos lluvia viento

Nivel 1 - Comportamiento E/S

MODELADO DE SISTEMAS MEDIANTE DEVS

Nivel 2 - Funci on E/S

Nivel 3 - Transici on de estado

AL MODELADO Y LA SIMULACION INTRODUCCION

Figura 1.3: La especicaci on de Nivel 2 toma en consideraci on el estado inicial.

Figura 1.4: La especicaci on de Nivel 3 describe adem as la evoluci on el estado.

rayos lluvia viento

Figura 1.5: Especicaci on de Nivel 4 - Estructura del bosque.

MODELADO DE SISTEMAS MEDIANTE DEVS

Nivel 4 - Componentes acoplados

MODELADO MODULAR Y JERARQUICO

AL MODELADO Y LA SIMULACION INTRODUCCION

MODELADO DE SISTEMAS MEDIANTE DEVS

MARCO FORMAL PARA EL MODELADO Y LA SIMULACION

Relacin de simulacin Modelo

AL MODELADO Y LA SIMULACION INTRODUCCION

Base de datos del comportamiento

MODELADO DE SISTEMAS MEDIANTE DEVS

Figura 1.7: Marco experimental y sus componentes.

AL MODELADO Y LA SIMULACION INTRODUCCION

MODELADO DE SISTEMAS MEDIANTE DEVS

AL MODELADO Y LA SIMULACION INTRODUCCION

Relaci on de modelado: validez

x(t+t) = x(t) + derx(t) * t v(t+t) = v(t) + derv(t) * t