Universidad de Buenos AiresFacultad de Ciencias Exactas y Naturales

Departamento de Computacion

Traductor de formalismo SystemDynamics a DEVS para modelado y

simulacion de sistemas hıbridos

Tesis de Licenciatura en Ciencias de la Computacion

Pedro Rodrıguez y Hernan Modrow

Director: Rodrigo Castro

Buenos Aires, 2019

1

Resumen

El estudio moderno de sistemas complejos interdisciplinarios usando modelos de simu-lacion suele requerir irremediablemente expresar dinamicas hıbridas (continuas y discre-tas). Pocas herramientas ofrecen esta capacidad, ya que un tratamiento correcto y eficientede interacciones entre estas dinamicas no es trivial.

System Dynamics y DEVS (Discrete Events Specification System) son metodologıasbien establecidas para modelado y simulacion de sistemas complejos, aunque basadas enenfoques distintos.

System Dynamics fue desarrollado por Jay Forrester en los 50s y se utiliza princi-palmente para modelar sistemas no lineales de tiempo continuo. Provee un fuerte sesgohacia el modelado visual, donde una “metafora de la banera” induce a pensar variablesde un problema complejo como reservorios cuyo nivel de llenado crece o decrece segunla intensidad de flujos de entrada y de salida (regulados por unas “canillas”). Las leyesque modulan estos flujos representan relaciones entre variables del sistema. Su enfoquesencillo e intuitivo aleja al usuario de la formulacion de ecuaciones, y ha logrado granaceptacion en disciplinas como sociologıa, ecologıa, economıa, procesos industriales, admi-nistracion de negocios, etc. Matematicamente un modelo SystemDynamics pertenece a lacategorıa de sistemas de Ecuaciones Diferenciales Ordinarias (ODEs) no lineales, que sonmaterial de estudio riguroso en disciplinas duras como las ingenierıas o la fısica, en las queSystem Dynamics ha pasado mayormente desapercibido. Entre otras limitaciones, SystemDynamics no es capaz de expresar correctamente la presencia de eventos discretos.

Por su parte, DEVS es una formalismo para simulacion de sistemas dinamicos basadoen eventos discretos. Fue desarrollado en los 70s por Bernard Zeigler. El formalismo DEVSpermite simular cualquier sistema discreto (a tiempo discreto o a eventos discretos) yaproximar sistemas continuos con tanta precision como se desee. Una de sus caracterısticasmas fuertes es la capacidad de modelar sistemas hıbridos, es decir aquellos que combinanlos paradigmas de tiempo discreto, eventos discretos y continuo.

En el mundo de System Dynamics, pocas herramientas comerciales aducen proveerdicha capacidad, y restringen al usuario al uso de un producto cerrado que oculta losdetalles de la resolucion de las interacciones hıbridas. Con sus ventajas y desventajas, existeuna cantidad masiva de conocimiento multidisciplinar capturado en forma de modelosSystem Dynamics acumulado durante decadas. Esto lo hace una tecnica que no puedeignorarse en el abanico de opciones de modelado y simulacion.

Por ello, es de un gran interes contar con la capacidad de reutilizar modelos SystemDynamics para componer modelos hıbridos complejos, y con garantıas de correctitud a lahora de la composicion de dinamicas discretas con dinamicas continuas.

En esta tesis resolvemos este problema mediante una estrategia basada en traduccionentre formalismos.

DEVS es capaz de representar cualquier modelo System Dynamics (mientras que loopuesto no es necesariamente cierto). Luego, desarrollamos un traductor automatico deSystem Dynamics a DEVS valiendonos de las tecnologıas XMILE (XML Modeling Inter-change LanguagE) y DEVSML. Estos son estandares textuales para especificar SystemDynamics y DEVS (respectivamente) disenadas con el proposito de intercambiar modelosentre simuladores de uno u otro formalismo (por separado).

Primero planteamos equivalencias formales entre ambos formalismos y luego desarro-llamos un traductor de XMILE a una version simplificada de DEVSML. Luego validamos

2

empıricamente la correctitud de nuestro traductor para modelos tıpicos de la literatura,usando el simulador Stella para System Dynamics y CD++ para DEVS. Sin embargo,nuestra metodologıa es agnostica de cualquier herramienta especıfica de simulacion.

Asimismo, estudiamos casos especiales poniendo explıcitamente de manifiesto algunaslimitaciones de System Dynamics que presentan problemas para su correcta simulacion, yque luego de ser traducidos a DEVS producen los resultados esperados.

Finalmente, atacamos un caso complejo de modelado hıbrido interdisciplinario. Toma-mos un modelo de macroeconomıa (basado en ODEs) y otro modelo de intercambio deopinion entre votantes (basado en agentes y automatas celulares). Aplicando el nuevo tra-ductor interconectamos ambos modelos obteniendo un nuevo sistema hıbrido de maneratransparente. Completamos el estudio extendiendo el modelo para que el componente ma-croeconomico produzca shocks discretos de opinion sobre los agentes, afectado la tendenciade las preferencias de la poblacion a largo plazo.

Indice general

Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1. Motivacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2. Formulacion del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4. Metodologıa de trabajo y alcance . . . . . . . . . . . . . . . . . . . . . . . . 6

1.5. Estructura de la tesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Parte I Preliminares 9

2.. Simulacion de Sistemas Dinamicos . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.. El formalismo System Dynamics . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1. Formalismo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2. Simulacion de sistemas continuos . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2.1. Metodo de Euler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2.2. Metodos Runge-Kutta . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2.3. Comentarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.3. Representacion visual de sistemas SD: componentes basicas. . . . . . . . . . 20

3.3.1. Ejemplo sencillo 1: Modelo Presa-Depredador tipo Lotka-Volterra . . 21

3.4. Componentes SD Avanzadas . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.4.1. Ejemplo sencillo 2: Modelo Lotka-Volterra Modularizado . . . . . . . 22

3.5. Herramientas de simulacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.. El leguaje XMILE para intercambio de modelos System Dynamics . . . . . . . . 25

4.1. El Formato XMILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1.1. Estructura general . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1.2. Modelo raız . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.1.3. Modulos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.2. Funcionalidades del traductor y el estandar XMILE . . . . . . . . . . . . . 29

4.2.1. Componentes basicos . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.2.2. Metodos de integracion numerica . . . . . . . . . . . . . . . . . . . . 31

4.2.3. Funciones incluidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.2.4. Componentes opcionales . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.. El formalismo DEVS para modelado y simulacion de sistemas hıbridos . . . . . . 35

5.1. Definiciones de DEVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.1.1. Definicion formal: modelo DEVS atomico . . . . . . . . . . . . . . . 36

5.1.2. Definicion formal: modelo DEVS acoplado . . . . . . . . . . . . . . . 37

5.1.3. Definicion formal: Cell-DEVS para automatas celulares . . . . . . . 38

5.2. DEVS y Metodos de Integracion Numerica . . . . . . . . . . . . . . . . . . 41

5.2.1. Metodo QSS de primer orden (QSS1) . . . . . . . . . . . . . . . . . 42

3

4 Indice general

5.2.2. Relacion entre QSS y el formalismo DEVS . . . . . . . . . . . . . . . 43

5.2.3. QSS frente a otros metodos de integracion . . . . . . . . . . . . . . . 44

5.3. Herramientas de simulacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6.. Idea Motivadora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6.1. Ejemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.1.1. Lotka-Volterra Basico (modularizado) . . . . . . . . . . . . . . . . . 48

Parte II Aportes 51

7.. Definicion del lenguaje µDEVSML para intercambio de modelos DEVS . . . . . 53

7.1. El formato DEVSML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

7.2. El formato µDEVSML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

7.2.1. Componente atomico . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

7.2.2. Modelo atomico de ejemplo . . . . . . . . . . . . . . . . . . . . . . . 55

7.2.3. Ejemplos de modelos atomicos implementados en µDEVSML . . . . 56

7.3. Componentes Acoplados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

8.. Traductor: De XMILE a µDEVSML . . . . . . . . . . . . . . . . . . . . . . . . . 63

8.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

8.2. Paso 1: Lectura de archivo XMILE . . . . . . . . . . . . . . . . . . . . . . . 63

8.3. Paso 2: Transformacion a DEVS . . . . . . . . . . . . . . . . . . . . . . . . 63

8.3.1. Traduccion a componentes acoplados DEVS . . . . . . . . . . . . . . 65

8.3.2. Traduccion de elementos aux a atomicos DEVS . . . . . . . . . . . 68

8.4. Paso 3: Serializacion a archivo . . . . . . . . . . . . . . . . . . . . . . . . . . 71

8.5. De µDEVSML a CD++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

9.. Casos de Estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

9.1. Modelo Teacup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

9.2. Modelo SIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

9.3. Modelo de Supply-Demand . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

9.4. Modelo Lotka-Volterra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

9.5. Modelo STEP (problemas con SD) . . . . . . . . . . . . . . . . . . . . . . . 80

10..Aplicacion a un sistema hıbrido . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

10.1. Modelo de intercambio de opinion . . . . . . . . . . . . . . . . . . . . . . . 84

10.1.1. Shocks exogenos sobre la grilla de agentes . . . . . . . . . . . . . . . 87

10.1.2. Promedio de victorias por partidismo al finalizar la simulacion . . . 88

10.2. Modelo Goodwin-Keen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

10.3. Replicacion de resultados Modelo Goodwin-Keen . . . . . . . . . . . . . . . 92

10.4. Modelo hıbrido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

10.4.1. Criterios de shocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

10.4.2. Experimentacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

10.4.3. Conclusiones sobre la experiencia de modelado hıbrido . . . . . . . . 97

Indice general 1

11..Conclusiones y trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9911.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9911.2. Discusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9911.3. Trabajo Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Parte III Apendices 101

12..Modelo Teacup extendido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

13..Lotka-Volterra Extendido (modularizado) . . . . . . . . . . . . . . . . . . . . . . 10713.1. Modelo grafico SD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10713.2. Modelo grafico DEVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10913.3. Simulacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

13.3.1. Stella . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11113.3.2. Stella vs. CD++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

14..Parser XMILEpy: Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11514.1. Funcionalidades basicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11514.2. Funcionalidades avanzadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

14.2.1. Opcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11514.2.2. Builtins: Agregaciones sobre arrays . . . . . . . . . . . . . . . . . . . 11614.2.3. Builtins: Operadores y Funciones matematicas . . . . . . . . . . . . 11614.2.4. Builtins: Funciones estadısticas . . . . . . . . . . . . . . . . . . . . . 11614.2.5. Builtins: Funciones de delay . . . . . . . . . . . . . . . . . . . . . . . 11714.2.6. Builtins: Funciones de tiempo de simulacion . . . . . . . . . . . . . . 11714.2.7. Funciones Test Input . . . . . . . . . . . . . . . . . . . . . . . . . . . 11714.2.8. Structured Statements . . . . . . . . . . . . . . . . . . . . . . . . . . 11714.2.9. Otras limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Bibliografıa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

2 Indice general

1. INTRODUCCION

System Dynamics (SD) es una metodologıa de modelado desarrollada desde finalesde los anos 50 en la MIT School of Industrial Management por el ingeniero Jay WrightForrester (Forrester, 1961).

SD se desarrollo como una estrategia para el modelado inductivo, es decir, para mode-lar sistemas cuyos componentes principales son gobernados por meta-leyes desconocidas.Sistemas tıpicos que se describen con SD son aquellos cuya complejidad no permite unadescripcion general adecuada por medio de principios basados en el dominio del problema.Por ejemplo, en sistemas demograficos, biologicos, economicos, ambientales, de salud ysistemas de gestion. Ası, la estructura y el comportamiento de un sistema se construyenesencialmente a partir de observaciones empıricas. Algunos casos de estudio en la literatu-ra que vale la pena destacar son: en la simulacion de portfolios de negocios (Merten et al.,1987), construccion de autopistas en China (Honggang et al., 1998), proceso de desarro-llo de productos (Ford and Sterman, 1997) y el famoso modelo de lımites de crecimiento(Limits to growth) World3 (Meadows et al., 2004), entre otros.

De forma paralela se desarrollo otra metodologıa de simulacion, introducida por elmatematico Bernard Zeigler a partir de la creacion del formalismo DEVS (Zeigler et al.,1976). DEVS es mas flexible y poderoso que System Dynamics y puede ser utilizado comoformalismo universal para el modelado y simulacion de sistemas.

Sin embargo, si bien ha habido algunos intentos de combinar SD con simulacion deeventos discretos (DES) (ver Morgan et al., 2017) no se le ha dado demasiada importancia alograr la unificacion de la representacion de modelos SD y DES bajo un mismo formalismo.Por su capacidad de representar tanto dinamicas discretas como dinamicas continuas, elformalismo DEVS aparece como el candidato ideal para encarar dicho problema.

En este trabajo nos proponemos implementar un software traductor de modelos SD enmodelos DEVS que permita la combinacion de ambas metodologıas de modelado.

1.1. Motivacion

Existe una gran variedad de herramientas de simulacion basadas en el formalismoSystem Dynamics. Algunos ejemplos son: Dynamo (Pugh, 1963), Stella (isee systems),Vensim (Ventana Systems, Inc. of Harvard, Massachusetts), Simile (Simulistics Ltd), Po-werSim (Powersim Software AS). De igual manera, se pueden encontrar muchas herramien-tas de simulacion basadas en el formalismo DEVS: PowerDEVS (Bergero and Kofman,2011a), CD++ (Wainer, 2002), DEVSJAVA (Sarjoughian and Zeigler, 2014) o Python-DEVS (Van Tendeloo, 2014) entre otras. Sin embargo, creemos que en parte por razoneshistoricas y en parte por su estrategia de apartarse de los detalles de la matematica subya-cente y enfocarse en la sencillez visual de especificacion de modelos, SD alcanzo un nivel deadopcion mucho mas alto. Tambien existen nuevos softwares de simulacion multipardigmacomo AnyLogic, muy utilizados en la industria.

Hasta hace pocos anos los entornos de simulacion para sistemas SD eran incompatiblesentre sı. Es decir, no habıa un formato estandar para representar los modelos que estospermitıan simular, a pesar de que su paradigma visual sı lo era. Es decir, dado un modelode un mismo sistema, para simularlo con herramientas distintas era necesario reescribirlo

3

4 1. Introduccion

cada vez.Este estado de la situacion se modifica en el ano 2013 cuando la IEEE (Institute

of Electrical and Electronics Engineers) en conjunto con la empresa IBM, establecen unestandar para representar modelos SD utilizando XML denominado XMILE. El estandarpermite que los modelos puedan intercambiarse entre las distintas herramientas sin lanecesidad de una reescritura.

Historicamente tambien hubo esfuerzos por encontrar un formato estandar para la re-presentacion de modelos DEVS con el fin de poder intercambiar modelos entre las distintasherrramientas de simulacion. En esta tesis nos referiremos a los trabajos desarrollados enDEVSML (Mittal et al., 2007).

Dada la vasta disponibilidad de modelos SD desarrollados durante decadas, es relevantecontar con la posibilidad de reutilizar y hacer coexistir modelos SD en el universo desimulacion a eventos discretos, para el cual DEVS representa un formalismo universal.

En la literatura han habido esfuerzos por lograr la integracion entre SD y DES, a fin deenriquecer la variedad de modelos que se puedan simular. En esos tipos de integraciones(por ejemplo, ver Helal et al., 2007), las caracterısticas de DES se utilizan para representarelementos del sistema que no se capturan con el nivel de granularidad suficiente dentrodel modelo SD (Morgan et al., 2017).

La simulacion hıbrida (definida como el modelado que combina dos de los siguientesmetodos: SD, DES y simulacion basada en agentes) ha experimentado un crecimiento casiexponencial en popularidad de las ultimas dos decadas (Brailsford et al., 2018). Es poresta razon que este tipo integraciones se estan volviendo muy necesarias para el analisisde sistemas complejos, como es en el area de investigacion operativa.

Sin embargo al momento de realizar este tipo de integracion de los formalismos SD yDEVS se deben tener en cuenta por lo menos las siguientes consideraciones (Helal et al.,2007):

Elegir las partes del modelo SD que se desean pasar a modelos DES y generar dichosmodelos. Estos modelos se ejecutaran de manera independiente

Definir el particionamiento del tiempo (time bucket) a utilizar para sincronizar entreel modelo SD y los modelos DES. Lo cual es una decision que afecta a la precisiony eficiencia del modelo

Convertir los valores de la variables compartidas entre modelos, tanto de SD a DEScomo de DES a SD

Crear un mecanismo o proceso para el intercambio de las variables entre los modelosen tiempo de simulacion

Estas cuestiones no estarıan presentes si se utilizara un unico modelo que sea capazde integrar ambos formalismos. Una alternativa a la integracion entre SD y DES que noparece no estar siendo explorada, es la de lograr esto mediante la traduccion de los modelosSD a DES utilizando el formalismo DEVS, que los integra a ambos.

1.2. Formulacion del problema

Segun nuestro relevamiento al inicio del desarrollo de este trabajo, no existıa ninguntrabajo que presentara un algoritmo para traducir entre los estandares en formato XMLde SD (XMILE) y DEVS (DEVSML).

1.3. Objetivos 5

Dicho algoritmo permitirıa la reutilizacion de modelos en SD ya implementados y lainterconexion de estos con otros modelos DEVS mas avanzados. Ası, se podrıa obtenerlo mejor de ambos mundos para la creacion de modelos de sistemas dinamicos: por unlado, la comodidad de generacion de modulos (o partes) de un modelo en herramientasavanzadas que trabajen con System Dynamics y por el otro, contar con las todas lasventajas provistas por el formalismo integrador DEVS.

1.3. Objetivos

El objetivo de esta tesis sera la implementacion de un traductor que permita trans-formar un modelo SD utilizando el estandar XMILE en un modelo DEVS expresado enun formato derivado del formato DEVSML, al que llamaremos µDEVSML. El traductorfacilitara la reutilizacion de modelos preexistentes ya estudiados en la literatura y permi-tira su modificacion y adaptacion a modelos nuevos, aprovechando todas las ventajas deDEVS.

Un modelador especialista en SD podra exportar sus modelos de forma automaticaa DEVS, sin tener que aprender las bases de dicho formalismo, ni ninguna herramientaDEVS adicional. Se lograra ası la integracion de modelos desarrollados en herramientasque implementen System Dynamics con sistemas de eventos discretos generalizados (queson representables mediante el formalismo DEVS).

Fig. 1.1: Capacidades del traductor: generar archivos en la especificacion µDEVSML partiendode una representacion XMILE del modelo SD implementado originalmente en Stella. Laflecha azul mas gruesa representa la implementacion core de esta tesis, mientras que la ne-gra sin puntear representa nuestra implementacion de la transformacion de µDEVSML allenguaje de programacion de la herramienta CD++, necesaria para testear los resultadosde los modelos traducidos. En lınea negra punteada quedan representadas otras imple-mentaciones posibles, y en lınea azul punteada implementaciones ya existenes hechas porterceros.

El traductor debera ser capaz de cumplir con los siguientes requisitos:

1. Interpretar y traducir una variedad de modelos SD clasicos, posibilitando que lasimulacion del modelo traducido replique los resultados de la simulacion generadapara estos por simuladores comerciales utilizados por la comunidad SD

2. Ser facilmente extensible, permitiendo la traduccion de nuevas funcionalidades quepuedan agregarse a XMILE de forma rapida y sencilla

3. Permitir la interconexion de modelos preexistentes que no sean representables en SD(por ejemplo, modelos de automatas celulares) con modelos de ecuaciones diferen-ciales ordinarias que sı puedan ser expresados en SD

6 1. Introduccion

1.4. Metodologıa de trabajo y alcance

Para generar representaciones XMILE de modelos SD utilizaremos un software comer-cial para el que contamos con licencia academica: 1. Este software es uno de los pocosque a la fecha de inicio del trabajo permitıa la exportacion modelos a formato XMILE.Teniendo en cuenta los objetivos definidos y las limitaciones propuestas, encaramos laimplementacion del traductor siguiendo los siguientes pasos:

1. Busqueda de modelos SD clasicos simples, su implementacion y simulacion en Stella

2. Implementacion y testing de un traductor capaz de traducir estos modelos basicosy replicar los resultados obtenidos en su simulacion en Stella

3. Busqueda de modelos SD mas complejos, que utilicen una variedad de features pro-vistos por Stella mas amplia (como funciones matematicas especiales o componentesque exhiban un comportamiento especial, como la generacion de pulsos, simuladorde comportamiento de colas, u otros)

4. Realizacion de modificaciones que fueran necesarias para que el traductor soportela adicion de los nuevos features.

5. Analisis de la implementacion del traductor. Deberıa ser extensible, y garantizar laposibilidad de agregar una variedad mas amplia de features.

6. Interconexion de alguno de los modelos mas complejos que pudieramos traducir, conmodelos DEVS preexistentes. Experimentacion con estos modelos multinivel ydisponibilizar un framework de experimentacion que permita la interconexionde modelos producidos por nuestro traductor con otros modelos avanzados DEVS,para que lectores interesados en esta tesis puedan implementar rapidamente modeloshıbridos de este estilo.

Para la implementacion del traductor, optamos por el lenguaje Python. Es un lengua-je simple, lo que facilita el aprendizaje del funcionamiento del traductor, y eventualmentesu modificacion y mejora. Ademas, Python provee bibliotecas potentes de interpretacionde ecuaciones matematicas (algo muy utilizado por el parser de modelos para interpre-tar expresiones textuales de ecuaciones algebraicas que se encuentran en algunos modelosSystem Dynamics), ası como bibliotecas potentes y comodas para trabajar con templates,algo muy util a la hora de implementar la generacion automatica de archivos de texto.

1.5. Estructura de la tesis

El resto de la tesis se estructura de la siguiente manera:

Capıtulo 2: se hace una introduccion a clasificacion de sistemas dinamicos y simulacion.

Capıtulo 3: se explican los fundamentos del formalismo System Dynamics

Capıtulo 4: se explica como el formato XMILE logra representar modelos SD, y profundizaen el alcance que tiene nuestro parser

1 Stella Architect 1.5.1:https://www.iseesystems.com/store/products/stella-architect.aspx

1.5. Estructura de la tesis 7

Capıtulo 5: se explican los fundamentos del formalismo DEVS

Cappıtulo 6: se explica la idea teorica motivadora para la posibilidad de implementar untraductor de formalismos SD a DEVS

Capıtulo 7: se explica el formato DEVSML, y sus diferencias con nuestra adaptacion, elformato µDEVSML

Capıtulo 8: se profundiza en como fue la implementacion del traductor

Capıtulo 9: se muestran los casos de estudio considerados en esta tesis, y la comparacionde los resultados obtenidos para estos en SD en la traduccion a DEVS

Capıtulo 10: se muestra un ejemplo avanzado: desarrollamos un modelo hıbrido, a partirde un modelo de automatas celulares implementado en DEVS, y la interconexion deeste con otro modelo de tiempo continuo (implementado en SD)

Capıtulo 11: hacemos un resumen de lo hecho, sacamos conclusiones y proponemos algu-nas ideas de posible trabajo futuro

8 1. Introduccion

Parte I

PRELIMINARES

2.

La simulacion es una metodologıa para estudiar sistemas complejos. El proceso desimulacion comienza siempre con un problema que se quiere resolver o comprender. Enmuchos casos este proceso comienza con la observacion de un sistema real a partir delcual se identifican entidades y sus interacciones a partir de las cuales se construye unmodelo del mismo. Una vez que el modelo esta definido, se experimenta con el medianteun simulador, el cual lo ejecuta. Los resultados de la simulacion son comparados con losdatos que se tienen del sistema real a fin de validar el modelo. En la mayorıa de los casosno es posible crear un modelo que tenga en cuenta todos los aspectos del sistema real.Es por ello que se define un marco experimental, en el cual se delinean los objetivos delmodelado y el alcance del modelo. La figura 2.1 muestra la relacion entre estos conceptos.

Fig. 2.1: Relaciones de modelado y simulacion: Se cuenta con un Modelo, y con un Sistema origenencuadrado en un Marco Experimental, que tiene una relacion de modelado con el modelo.Por otro lado con un Simulador, que tiene un relacion de simulacion con el Modelo.

Formalmente podemos definir un sistema como una entidad real o artificial que re-presenta una parte de una realidad y esta restringida por un entorno. Puede decirse queun sistema es un conjunto ordenado de objetos logicamente relacionados que atraviesanactividades, interactuando para cumplir los objetivos propuestos (Wainer and Mosterman,2011). Por otro lado, un modelo es una representacion inteligible (abstracta y consistente)de un sistema. Se pueden distinguir dos grandes grupos de metodos para modelar siste-mas complejos a partir de un sistema real: los modelos analıticos y los modelos basadosen simulacion.

Los modelos analıticos estan basados en el razonamiento deductivo y permiten obtenersoluciones generales al problema. Un formalismo analıtico muy difundido para el modeladode problemas es el uso de ecuaciones diferenciales. Un problema de estos metodos es que alconsiderar sistemas complejos estos (con pocas excepciones) seran analıticamente intrata-bles y numericamente prohibitivos de evaluar. La utilizacion de estos metodos requiere dela simplificacion del modelo, alejandolo demasiado de lo que sucede en la realidad (Wainerand Mosterman, 2011).

Los modelos basados en simulacion suelen utilizarse en los casos en que no es posibleo conveniente modelar el sistema mediante metodos analıticos. En este tipo de modelos

11

12 2. Simulacion de Sistemas Dinamicos

no se intenta buscar una solucion general al problema, sino que se buscan solucionesparticulares. Algunos problemas con estse tipo de modelos son el tiempo que lleva sudesarrollo, la necesidad de validar los resultados y de recopilar datos para poder reproducirel comportamiento del sistema. Algunas ventajas de realizar simulaciones en lugar deexperimentacion directa sobre el sistema son (Wainer and Mosterman, 2011):

Repetitividad : Una simulacion puede ser realizada tantas veces como sea necesario.

Experimentacion Controlada : La simulacion de un sistema no afecta al sistema real.

Compresion del tiempo : En muchos casos una simulacion demanda menos tiempo en suejecucion que la realizacion de un experimento en el sistema real.

Analisis de sensibilidad : el modelador decide cual es el marco experimental (leyes querigen la simulacion) de cada experimento de simulacion.

Automatizacion : se puede automatizar la simulacion para hacer una experimentacionexhaustiva y ası encontrar los resultados deseados.

Como muestra la figura 2.2, los modelos pueden clasificarse basicamente en cuatrocategorıas, a partir de la observacion de su base de tiempo y el valor de sus variables.

Con respecto a la base de tiempo, pueden ser de:

Tiempo continuo, donde el tiempo evoluciona de forma continua

Tiempo discreto, donde el tiempo avanza por saltos de un valor entero a otro

Respecto a los conjuntos de valores de las variables descriptivas, pueden ser de:

Estados o eventos discretos, donde el valor de las variables pertenecen a conjuntosdiscretos

Continuos, las variables son numeros reales

Mixtos, variables tanto discretas como continuas

Fig. 2.2: Clasificacion de modelos segun su base de tiempo y el valor de sus variables (Wainer andMosterman, 2011)

13

Por ejemplo, los modelos descriptos con ecuaciones diferenciales se encuentran dentrodel cuadrante superior izquierdo, mientras que dentro del superior derecho se discretiza eltiempo obteniendo ecuaciones en diferencia, es decir, aproximaciones a tiempo discreto delas ecuaciones diferenciales. En el cuadrante inferior derecho (variables y tiempo discretos)se encuentran modelos como las maquinas de estados finitos, redes de Petri, automatas ce-lulares y otros. Finalmente en el inferior izquierdo se muestran los paradigmas de variablesdiscretas a tiempo continuo. Tales sistemas reciben el nombre de Sistemas Dinamicosde Eventos Discretos (DEDS – Discrete Events Dynamic Systems). En este trabajoutilizaremos dos formalismos matematicos que se encuadran dentro de esta categorizacionde la siguiente manera:

System Dynamics: es tıpicamente utilizado para modelar sistemas de ecuaciones diferen-ciales. Utiliza variables continuas y tiempo discreto

DEVS: es utilizado para modelar sistemas generales. Si bien podrıa categorizarse como unDEDS, DEVS tambien puede representar variables continuas. Diremos que utilizavariables discretas y continuas y tiempo continuo.

14 2. Simulacion de Sistemas Dinamicos

3. EL FORMALISMO SYSTEM DYNAMICS

3.1. Formalismo

System Dynamics es el nombre asignado a una metodologıa de modelado desarrolladapor Jay Wright Forrester (Forrester, 1961). Principalmente fue concebida como una estra-tegia para modelar sistemas cuyas leyes de comportamiento son desconocidas, por lo quelas mismas deben inferirse partiendo de observaciones (modelado inductivo). En SystemDynamics la dinamica de evolucion de un sistema se describe mediante la interconexionde componentes basicos: el componente level (o stock), representando variables de estado,y componentes rate (o flow), que representan la velocidad de cambio de los stocks. Unmodelo SD se construye basicamente como una interconexion de stocks y rates que seinfluencian unos a otros, definiendo ası un sistema de ecuaciones diferenciales ordinarias(en ingles ODEs) de orden n para n stocks. Es decir, System Dynamics produce objetosmatematicos cuya solucion numerica es materia de la simulacion de sistemas continuos.

Uno de los aspectos claves que llevo al exito de SD fue la eficiencia comunicacionalde la ”metafora de la banera”(o bathtub metaphor): el nivel de agua de la banera (stock)aumenta o disminuye de acuerdo al caudal de agua que vierten las canillas (inputs) y salepor los desagotes (outputs). Esta intuicion visual de contenedores que se vacıan y llenana velocidades determinadas por relaciones a ser identificadas fue prontamente adopta-da por modeladores en disciplinas que, por su tradicion, no se basan fuertemente en elanalisis matematico (por ejemplo ciencias sociales, naturales, de administracion). Por elmismo motivo, System Dynamics fue practicamente ignorado en disciplinas con fuerte raızmatematica como la fısica o las ingenierıas.

La estrategia de modelado utilizada por SD es identificar primero las variables deestado para el modelo (aquellas que definen los elementos stock) y luego identificar todaslas variables que actuan o inciden sobre estas (lista de variables influyentes). Estas ultimaspueden incluir parametros, funciones X-Y de tipo tabla entrada-salida, otras variables deestado y otras funciones. Todos ellos pueden combinarse para definir funciones arbitrariasque a su vez definan las leyes que gobiernan los flujos de entrada y salida (Sterman, 2000).

Fig. 3.1: Bathtub metaphor o ’metafora de la banadera’

Desde un punto de vista metodologico en la construccion de modelos de simulacion,podemos observar que System Dynamics presenta ciertas limitaciones:

Hay un alto nivel de acoplamiento entre especificacion del modelo y tecnica de si-mulacion: el modelador queda a cargo de especificar el paso fijo de tiempo DT1 quese utilizara por el metodo numerico para resolver el sistema de ODEs resultante.

1 por Delta Time en ingles

15

16 3. El formalismo System Dynamics

Como consecuencia, no es posible la utilizacion de integradores de paso adaptativo(el DT es fijo)

No hay forma de modelar correctamente eventos discretos que ocurran en instantesintermedios dentro de un intervalo abierto cualquiera (k.DT, (k+1).DT ) con k ∈ N.Veremos este caso en la Seccion 9.5

Cuando se permite la existencia de flujos bidireccionales, que permiten ”agregar” aun stock una ”cantidad negativa” de agua, la metafora visual de la banera pierdesu sentido. (Para ver mas sobre esta idea, recomendamos ver el apendice 12 luegode haber leıdo el ejemplo de la Seccion 9.1)

Durante ya casi 7 decadas se han desarrollado diversas herramientas comerciales desoftware que permiten modelar y simular sistemas de ecuaciones diferenciales basandose enSD. Podemos citar las mas populares actualmente y que condensan la mayor comunidadde usuarios como por ejemplo Vensim (Ventana Systems, Inc. of Harvard, Massachusetts)o Stella (isee systems). Estas herramientas son de codigo cerrado, con lo cual no se puedesaber que es lo que esta haciendo ”realmente” el simulador para determinar el valor decada variable en funcion del tiempo. Esto puede ser un riesgo, por ejemplo, en situacionesen las que se necesite controlar de manera detallada la cota superior de error cometidopor el metodo numerico subyacente, o bien tener acceso al codigo para depurar casos enlos que los resultados numericos sean a primera vista dudosos.

Dado que es evidente que la aproximacion numerica de ODEs es una pieza central enSD, a continuacion hacemos algunos comentarios breves sobre estas tecnicas para simula-cion de sistemas continuos.

3.2. Simulacion de sistemas continuos

En los sistemas continuos no se determina el proximo estado a traves de una funcionde transicion discreta, sino que se usa una funcion derivada para especificar la tasa decambio de las variables de estado. Para todo instante de tiempo, dado un estado y unvalor de entrada, solo se conoce la tasa de cambio del estado. Con esta informacion, debecalcularse el estado para cualquier instante futuro.

Consideremos el sistema dinamico elemental compuesto por un unico integrador (Fig. 3.2),y pensemos en su representacion mediante diagrama de bloques. Este integrador tiene unaunica ”variable de entrada”u(t) y una unica ”variable de salida”y(t). Lo que se coloqueen el deposito se acumula o se quita si el valor de entrada es positivo o negativo. La in-formacion de salida de nuestro deposito representa su contenido actual. Cuando queremosexpresar esto en forma de ecuacion diferencial necesitamos una variable que representeel contenido actual. Es la variable de estado z(t). La entrada u(t) representa la tasa decambio actual del contenido que se puede expresar con la Ecuacion 3.1 y la salida y(t) esigual al estado actual y(t) = z(t).

dz(t)

dt= u(t) (3.1)

3.2. Simulacion de sistemas continuos 17

Fig. 3.2: Funcion de integracion: Su representacion mediante diagrama de bloques (izquierda) yuna analogıa con un deposito de agua (derecha).

Los sistemas de tiempo continuo usualmente usan diversas variables de estado. Susderivadas son entonces funciones de algunas, o todas, las variables de estado del sistema.Si z1, z2, . . . , zn son las variables de estado y u1, u2, . . . , um son las variables de entrada,entonces el modelo de tiempo continuo esta formado por un conjunto z1(t), z2(t), . . . , zn(t)de ecuaciones diferenciales de primer orden de la forma:

zi(t) = fi(z1(t), z2(t), . . . , zn(t), u1(t), u2(t), . . . , um(t)) (3.2)

Este conjunto puede expresarse de manera mas compacta si se agrupa en vectores alas variables de estado, las variables de entrada y las ODEs, quedando expresado como:

z(t) = f(z(t), u(t)) (3.3)

Una explicacion mas detallada puedo encontrarse en (Zeigler et al., 2018, pags. 55-57).

La mayorıa de los modelos de tiempo continuo se escriben (o son convertidos) a laforma de la Ecuacion 3.3, la cual no provee un valor explıcito para la variable estado z(t)despues de un determinado tiempo. Por lo que para obtener las trayectorias del estadodebe resolverse la ODE. El problema es que obtener la solucion de la Ecuacion 3.3 es quemuy pocas tienen soluciones analıticas en terminos de funciones y expresiones conocidas.Es por ello que normalmente se utilizan metodos de integracion numerica que proveensoluciones aproximadas. Estas soluciones se obtienen a partir de un estado inicial conocidoz(t0) = z0 y aproximan la solucion en determinados instantes de tiempo t1, t2, . . . , tn. Engeneral los modelos de tiempo continuo no se expresan como en la Ecuacion 3.3, dadoque no es comodo (hasta incluso imposible) desde el punto de vista del modelador. Es porello que se utilizan herramientas graficas que implementan System Dynamics o lenguajesorientados a ecuaciones como Modelica2 para expresar los modelos. Luego las herramientasconvierten a estos en ODEs, las que pueden aproximarse mediante metodos numericos. Acontinuacion mencionamos alguno de ellos con fines ilustrativos.

3.2.1. Metodo de Euler

Es un procedimiento de integracion numerica para resolver ecuaciones diferencialesordinarias a partir de un valor inicial dado. Es el mas antiguo y mas simple para resolver

2 Ver https://openmodelica.org/

18 3. El formalismo System Dynamics

la Ecuacion 3.3, propuesto por Leonhard Euler en 1768. Las derivadas de la variable deestado se aproximan segun:

z(t) ≈ z(t+ h)− z(t)h

⇒ f(z(t), u(t)) ≈ z(t+ h)− z(t)h

(3.4)

De lo cual obtenemos que:

z(t+ h) ≈ z(t) + h · f(z(t), u(t)) (3.5)

Donde h es el paso de integracion.Definiendo tk = t0 + h · h para k ∈ N, el metodo de Euler hacia adelante se define con

la siguiente formula:

z(tk+1) = z(tk) + h · f(z(tk), u(tk)) (3.6)

La variante que se denomina Euler hacia atras se expresa de la siguiente manera:

z(tk+1) = z(tk) + h · f(z(tk+1), u(tk+1)) (3.7)

Esta es una formula implıcita, donde z(tk+t) es desconocida y esta a ambos lados de laecuacion. Teniendo en cuenta que la funcion f es usualmente no lineal, obtener el proximoestado con este metodo requiere resolver una ecuacion algebraica no lineal. Esto se lograusualmente mediante el metodo de Newton.

Si bien la utilizacion del metodo implıcito es mas costosa computacionalmente que elexplıcito puede verse que el metodo implıcito es mas estable numericamente (Zeigler et al.,2018, pags.70-72).

3.2.2. Metodos Runge-Kutta

Runge-Kutta es una importante familia de metodos iterativos, tanto implıcitos comoexplıcitos, para aproximar las soluciones de ecuaciones diferenciales ordinarias. Se llamanası por los matematicos Carl Runge y Martin Kutta alrededor del 1900.

Si para tk conocemos el valor del vector z, entonces podemos pensar calcular la solucionexacta de z(t) = f(z(t), u(t)) mediante la siguiente serie de Taylor:

z(tk+1) = z(tk) +∞∑i=1

hi

i!· d

iz

dti(tk) (3.8)

Si para el termino de la ecuacion h · dzdt (zt), que es el termino i = 1 de la sumatoria,remplazamos por f la derivada del estado respecto del tiempo, obtenemos:

z(tk+1) = z(tk) + h · f(z(tk), u(tk)) +∞∑i=2

hi

i!· d

iz

dti(tk) (3.9)

Como se puede ver, salvo por la sumatoria la ecuacion coincide con el metodo de Euler(Ecuacion 3.6). Por eso tambien se lo conoce como metodo de Runge-Kutta de primerorden.

Como estos metodos utilizan solo informacion del paso anterior, se los conoce tambiencomo metodos de un paso. Los metodos que utilizan la informacion de los pasos anteriores,es decir los valores z(tk−1, . . . , zt0), se los conoce como metodos multi-paso.

3.2. Simulacion de sistemas continuos 19

Los distintos metodos Runge-Kutta utilizan mas terminos de la serie de Taylor paraaproximar el valor de la ecuacion.

3.2.2.1. Metodo explıcito

Los metodos Runge-Kutta explıcitos realizan varias evaluaciones de la funcion f alre-dedor del punto (z(tk), tk) y luego calculan z(tk+1) usando promedio ponderado de esosvalores. El mas simple de estos algoritmos se conoce como metodo de Heun que utiliza lasiguiente formula:

z(tk+1) = z(tk) +h

2· (k1 + k2) (3.10)

donde

k1 =f(z(tk), u(tk))

k2 =f(z(tk) + h · k1, u(tk + h))

Este metodo realiza una segunda evaluacion de f , para calcular k2, con el finde demejorar los resultados respecto del metodo de Euler.

Uno de los metodos de integracion numerica mas utilizados es el metodo Runge-Kuttade cuarto orden (RK4).

z(tk+1) = z(tk) +h

6· (k1 + 2 · k2 + 2 · k3 + k4) (3.11)

donde

k1 =f(z(tk), u(tk))

k2 =f(z(tk) + h · k12, u(tk +

h

2))

k3 =f(z(tk) + h · k22, u(tk +

h

2))

k4 =f(z(tk) + h · k3, u(tk + h))

Este algoritmo realiza cuatro evaluaciones de la funcion f en cada paso, obteniendouna aproximacion de cuarto orden.

La eleccion del paso en estos metodos reduce el error cometido en la aproximacion. Asıcomo para un mismo paso (valor de h) el error global cometido por RK4 es menor al delmetodo de Heun y este es menor al cometido por el metodo de Eurler para dicho paso.

En la literatura puede encontrarse muchos algoritmos explıcitos de Runge Kutta, inclui-dos metodos mayores a orden 10. En la practica, los metodos Runge-Kutta mas utilizadosson los de orden 1 a 5.

3.2.2.2. Metodo implıcito

Se menciono que el metodo de Euler hacia atras preserva la estabilidad numerica paracualquier valor de h, aun cuando tiene la misma precision que Euler hacia adelante. Existenvarios metodos implıcitos de un paso de orden superior, que como el metodo de Euler hacia

20 3. El formalismo System Dynamics

atras, preservan estabilidad numerica. El mas utilizado es el conocido como la Regla delTrapecio:

z(tk+1) = z(tk) +h

2· [f(z(tk), u(tk)) + f(z(tk+1), u(tk+1))] (3.12)

Este metodo tiene precision de segundo orden y no solo preserva estabilidad, tambienpreserva estabilidad marginal. Es decir, que si se utiliza para simular un sistema conoscilaciones sin amortiguar, este metodo tambien exhibira oscilaciones sin amortiguar.Excepto por la regla del trapecio y algunos otros metodos, los metodos implıcitos de unsolo paso no son ampliamente utilizados en la practica. Se suele preferir la utilizacion demetodos implıcitos de multi-paso.

3.2.3. Comentarios

De las secciones precedentes sobre modelos continuos y sus metodos de aproximacionnumerica podemos sacar algunas conclusiones acerca de System Dynamics. Evidentementeel concepto de paso de tiempo h (o DT en la jerga de System Dynamics) es pertinenciaexclusiva del algoritmo de simulacion. Para un mismo modelo pueden elegirse diferentestamanos de paso h en funcion de diversos criterios de desempeno, precision, estabilidad,etc. Incluso ciertos metodos tienen la capacidad de adaptar h a conveniencia durante eltranscurso de una simulacion. Luego, en ningun caso durante la formulacion (modelado)del sistema continuo se toma en cuenta el paso discreto del tiempo, ya que si ese fuerael caso, se estarıa modelando un sistema a tiempo discreto (sistema tipo DTDS en laFig. 2.2), directamente como z(tk+1) = f(z(tk), u(tk)), donde tk = k.h con h ∈ R, k ∈ N.Sin embargo, System Dynamics exige que el modelador explicite DT en las ecuacionesdinamicas. Este es el punto que motiva nuestro comentario acerca de que System Dynamicsmezcla rıgidamente modelado y simulacion, lo cual puede traer numerosos problemas,alejandose de las buenas practicas conceptuales de separacion entre modelo y simulador(ver Fig. 2.1).

Estas consideraciones no han sido limitantes para el exito y amplia adopcion del for-malismo a nivel mundial, por lo cual es pertinente estudiarlo primero, para luego proponerlas estrategias de traduccion automatica que son la motivacion principal de este trabajo.

3.3. Representacion visual de sistemas SD: componentes basicas.

Los modelos SD pueden ser, y son principalmente, expresados de forma grafica. En suversion mas simple, todo modelo SD grafico debe contar con algun stock, que se representacon bloques rectangulares, y algun flow, que se representa con un sımbolo de valvula ocanilla colocadas sobre flechas cuyos destino y origen pueden ser, a su vez, otros elementosstock. Ademas, las flechas que transportan fluidos pueden tener orıgenes y destinos queno esten especificados en el sistema modelado y por lo tanto conforman los lımites desu representacion (indicando ası, por ejemplo, que la energıa que se le quita al stock se”pierde”, o mas estrictamente, se transfiere fuera de los lımites del sistema.)

Un modelo grafico SD tambien suele estar conformado por objetos auxiliares (los lla-maremos elementos aux), que se representan mediante cırculos y cuyo valor puede ser uti-lizado por elementos flow para modificar su apertura y modular ası el ingreso o egreso defluido para un stock. Tambien, los elementos aux suelen utilizarse como ”sumideros”paraextraer estadısticas o relaciones entre variables de un modelo. Veamos a continuacion estasideas en accion en un ejemplo sencillo.

3.3. Representacion visual de sistemas SD: componentes basicas. 21

3.3.1. Ejemplo sencillo 1: Modelo Presa-Depredador tipo Lotka-Volterra

En la literatura de simulacion de SD se puede encontrar una enorme cantidad y va-riedad de modelos de ODEs. Un modelo ampliamente conocido y citado como ejemplo ennumerosos textos introductorios es el celebre modelo ecologico de interaccion de especiesllamado Lotka-Volterra. Puede describirse matematicamente mediante el sistema en laEcuacion 3.13 y graficamente mediante el modelo SD de la Fig. 3.3.

Nota: En lo que resta del documento adoptaremos, para las ecuaciones, el estilo itali-co para denotar parametros, negrita para denotar variables dependientes del tiempo(variable = variable(t)) y el apostrofe para denotar derivada temporal (variable’ =ddtvariable(t)).

{Prey′ = preyBirthRate ∗Prey− preyDeathRate ∗Prey ∗PredatorPredator′ = predatorEfficiency ∗Predator ∗Prey− predatorDeathRate ∗Predator

(3.13)

Fig. 3.3: Representacion grafica en Stella del Modelo Lotka-Volterra. Los cırculos son elementosaux (correspondientes a variables auxiliares del modelo), los rectangulos son los stock ylas canillas son los flow.

En la Fig. 3.4 se muestra una simulacion para las variables de estado correspondientesal modelo Lotka-Volterra presentado en la Fig. 3.3. Se ve que es un modelo cıclico (masespecıficamente, este modelo entra en la categorıa de modelos marginalmente estables, quetienen varias propiedades interesantes).

22 3. El formalismo System Dynamics

Fig. 3.4: Ejemplo de la evolucion de variables Predator y Prey en una simulacion del modelo Lotka-Volterra

3.4. Componentes SD Avanzadas

Para desarrollar modelos SD mas avanzados, los software de simulacion suelen ampliarla variedad de objetos de modelado y operaciones matematicas disponibles. Por ejemplo,se proveen funciones que simulan colas, cintas transportadoras, matrices (para organizarlos datos de forma mas comoda), entre otras. Destacamos algunos:

Conveyor cumple la funcion de una cinta transportadora. En esta se colocan objetosque son transportados a cierta velocidad hacia el final de la cinta, en donde caen fuera deella. Opcionalmente, pueden tener perdidas y algunos de los objetos transportados puedencaerse antes de llegar al final

Queue cumple una funcion similar a los stock, pero permite el seguimiento de loslotes discretos que van llegando y saliendo.

Array puede ser pensado como un hipercubo de dimension N1×. . .×Nk. Permiteagrupar un conjunto de componentes en una unica componente. Mas detalle sobre estafuncionalidad en las siguientes secciones.

Submodelos permite agrupar de forma modular a los componentes, haciendo maslegible al modelo y permitiendo la reutilizacion de este componentes, en un mismo u otrosmodelos. En las proximas secciones detallaremos mas acerca de esta funcionalidad.

3.4.1. Ejemplo sencillo 2: Modelo Lotka-Volterra Modularizado

Para representar el clasico modelo Lotka-Volterra, Stella prove facilidades para poderordenar y visualizar la estructura del modelo mas comodamente mediante la modulari-zacion de los objetos graficos. Ver figuras 3.5 y 3.6, donde puede verse la separacion enmodulos de las presas y los depredadores, con respecto al modelo la Fig. 3.3 donde estanjuntos al mismo nivel.

3.4. Componentes SD Avanzadas 23

Fig. 3.5: Modelo Lotka-Volterra modularizado

(a) Modulo PredatorModel (b) Modulo PreyModel

Fig. 3.6: Modulos del modelo Lotka-Volterra

En la Fig. 3.5 las flechas modeloA → modeloB indican que el estado del modelo Aes utilizado por el modelo B para determinar su estado en cada instante de tiempo t. Eneste caso, ambos modelos se afectan mutuamente, lo cual posibilita un comportamientocıclico producto de esta realimentacion.

En las figuras 3.6a y 3.6b se muestra el interior de los modulos PredatorModel yPreyModel respectivamente. Es interesante notar algunos detalles de esta representaciongrafica propuesta por el software Stella:

1. Los cuadrados con bordes redondeados representan que el stock correspondienteesta ubicada adentro de otro modulo del modelo.

2. Las dos rayas verticales en la parte derecha inferior de los cuadrados con bordesrectos: significa que el stock es no negativo, y que su valor satura en cero.

3. La flecha punteada o completa de los flow define si es un biflow o uniflow. Esdecir, si ese flujo le puede .agregar de manera negativa”(quitar) al stock al queafecta, entonces es un biflow, caso contrario es un uniflow.

4. Las doble flechas son de borde simple o punteado, dependiendo de si el flujo es uninflow o un outflow respecto al stock sobre el cual impacta la flecha.

5. Los cırculos punteados son elementos aux que vienen de otro modulo del modelo.

6. El borde de doble lınea de los stock indica que dicha variable es leıda por algunagente externo al modulo en el cual dicho stock se encuentra ubicado (lo mismosucede con los elementos aux).

24 3. El formalismo System Dynamics

Para ver una version extendida del modelo SD aquı presentado ver Capıtulo 13, enel cual extendemos el modelo Lotka-Volterra anadiendo varias componentes y funciona-lidades extra que complejizan el modelo y que sirven de excusa para detallar de formamas pormenorizada el funcionamiento y caracterısticas de SD, DEVS y del traductorimplementado.

3.5. Herramientas de simulacion

Como ya mencionamos, existen varios programas que permiten la simulacion de mo-delos System Dynamics. Aquı mencionaremos los que consideramos mas destacables:

1. Stella: es el programa que elegimos para realizar los experimentos en este trabajo.Fue el unico al que al inicio del trabajo tuvimos acceso a un precio razonable y contodas las funcionalidades que necesitabamos (exportar modelos en formato XMILE,entorno de simulacion amigable, implementacion de funcionalidades avanzadas.)

2. Vensim: Presenta algunas ventajas que lo posicionaban como una buena opcionpara esta tesis: tiene una version gratuita con muchısimos ejemplos y una ampliacomunidad que lo utiliza (la primer version salio en 1985). Sin embargo, no proveıala funcionalidad de exportar a XMILE.

3. AnyLogic: Es el mas completo de todos. No solo permite la simulacion de modelosSystem Dynamics, sino tambien de eventos discretos, basados en agentes, e hıbridos.Sin embargo, al momento de comenzar esta tesis, aun no proveıa la capacidad deexportar modelos a XMILE ademas de tener un costo de licencia elevado.

4. EL LEGUAJE XMILE PARA INTERCAMBIO DE MODELOSSYSTEM DYNAMICS

XMILE (XML Modeling Interchange LanguagE) es un formato de archivos XML di-senado para representar modelos de System Dynamics. Este formato como estandar cons-tituye una gran contribucion al area de modelado y simulacion de sistemas en SD, puestoque permite que aquellos que utilicen herramientas que adhieran a dicho estandar puedanintercambiar modelos entre sı sin la necesidad de reimplementarlos, ni estar atados a unaherramienta en la particular. En las palabras uno de los creadores del formato:

”The lack of a cross-platform standard implies a community of ‘provincial’vendors’. In contrast, XMILE provides much more expansion and flexibility,for example if a vendor goes out of business, is acquired, etc. XMILE is a greatstep forward!” - Ed Gallaher psdorg:xmile

Para cumplir con el estandar del formato XMILE, el archivo XML debe cumplir conuna serie de reglas y condiciones muy precisas especificadas en (OASIS XML InterchangeLanguage (XMILE) for System Dynamics TC, seccion 7.2). Aquı haremos un breve resu-men y mostraremos un ejemplo, para que el lector capture lo fundamental del formato.

4.1. El Formato XMILE

4.1.1. Estructura general

En la Fig. 4.1 se presenta la estructura general de un modelo SD en el formato XMI-LE. Continuaremos usando de excusa al ejemplo motiador Lotka-Volterra. En la figurapodemos destacar:

El tag raız que indica que es un archivo de tipo XMILE version 1.0

El nombre del modelo es ’Lotka-Volterra’

La herramienta usada para la creacion del modelo es Stella Architect 1.5

Vendedor de la herramienta es isee systems, inc.

El metodo de integracion que utilizado por el modelo es Runge-Kutta 4

La unidad de tiempo es en dıas

El paso de tiempo (DT) es 0.01 (dıas)

El tiempo de inicio es 0 (dıas)

El tiempo de fin es 300 (dıas)

Como se ve en el ejemplo, para cumplir con el formato se deben utilizar ciertos tagsXML, algunos de estos son obligatorios y otros opcionales. De acuerdo al estandar estosson:

25

26 4. El leguaje XMILE para intercambio de modelos System Dynamics

1<?xml v e r s i o n=” 1 .0 ” encoding=” utf −8”?>2<xmile v e r s i on=” 1 .0 ” xmlns=” h t tp : // docs . oa s i s−open . org / xmile /ns/XMILE/v1

. 0 ” x m l n s : i s e e=” ht t p : // i s e e sy s t e ms . com/XMILE”>3 <header>4 <name>Lotka−Vol te r ra</name>5 <uuid>193868 c2−0b04−4d3d−b865−0cb31a83d64a</ uuid>6 <vendor> i s e e systems , inc .</ vendor>7 <product v e r s i on=” 1 .5 ” i s e e :bu i l d number=”1277” i s e e : s a v e d b y v 1=

” true ” lang=”en”>S t e l l a Arch i t e c t</ product>8 </ header>9 <s im spec s method=”RK4” t im e un i t s=”Days” >

10 <s t a r t>0</ s t a r t>11 <stop>300</ stop>12 <dt>0 .01</dt>13 </ s im spec s>14 <mode l un i t s>15 <uni t name=”Days”>16 <eqn/>17 <a l i a s>day</ a l i a s>18 </ un i t>19 </ mode l un i t s>20 <model>21 <v a r i a b l e s> . . . </ v a r i a b l e s>22 <views> . . . </ views>23 </model>24 . . .25</ xmile>

Fig. 4.1: Representacion XMILE de Lotka-Volterra. Estructura general del archivo.

xmile: este es el tag raız del XML, debe incluir como atributos la version (1.0 en el ejemplo)y el namespace en el cual se definen los tags y atributos

header: contiene los detalles acerca del software con el cual se genero el archivo, ası comolas opciones XMILE que se incluyen en el archivo, como por ejemplo el uso desubmodelos, macros y arreglos. Tambien puede contener informacion sobre el nombredel modelo, su creador y version, ası como los archivos externos que deben incluirse

sim specs: tag opcional que contiene informacion especıfica de la simulacion. Para ejecutarla simulacion de un modelo en SD es necesario definir un tiempo de inicio (start),finalizacion (stop) y un DT que determine el intervalo de tiempo mınimo a ser uti-lizado por los metodos de integracion. El resto de los parametros de simulacion sonmethod (define que metodo de integracion numerica utilizar) y time units (indicala unidad basica de medicion de la variable tiempo)

model units: tag opcional para el caso que el modelo tenga variables para las cuales setengan que definir unidades de medida especıficas. En Fig. 4.1, se ve en las lıneas16-19 la declaracion de la unidad Days

dimensions : tag opcional en cual se definen las dimensiones de los arreglos utilizados enel modelo

behavior: tag opcional en el cual se puede definir el comportamiento por defecto de losdistintos componentes en distintos niveles: por componente especıfico, componentes

4.1. El Formato XMILE 27

dentro de un modelo especıfico, todos lo modelos. Por ejemplo, se puede definir quetodos los elementos stock sean no negativos (non negative)

style: tag opcional que definen los estilos a aplicar en los componentes para su visualizacion

data: tag opcional para definir fuentes de datos a utilizar por los modelos, ası como re-cursos para guardar los datos que genere su ejecucion

model: cada modelo se define matematicamente a partir de la estructura de elementosque se enceuntro dentro del tag variables. Tambien, se utiliza lo contenido dentrodel tag views para definir de forma precisa la ubicacion espacial de cada uno delos elementos graficos del modelo en la pantalla de la herramienta de simulacioncorrespondiente

macro: tag utilizado para definir macros que pueden utilizarse en las ecuaciones de loscomponentes de los modelo

4.1.2. Modelo raız

En XMILE el modelo de nivel superior de un modelo es el modelo raız (root model).En XMILE este modelo no lleva nombre. En la Fig. 4.2 se muestra un extracto de larepresentacion XMILE de las partes que conforman el modelo raız presentado en la Fig. 3.5.

Si se observan los nombres asociados a los tags, atributo XML name, puede verse quelos tags module y model se corresponden con los rectangulos del diagrama de la Fig. 3.5 ylos aux se corresponde a los cırculos. El atributo XML ´para el nombre en estos tres tagsrequiere que tenga un valor definido.

Es decir, el modelo raız esta conformado por los modulos PreyModel (lınea 3) y Pre-datorModel (lınea 9) que interactuan entre sı, como puede verse en la lınea 4 se define unaconexion desde la variable de salida Predator del modelo PredatorModel hacia la variablede entrada Predator del modelo PreyModel. Y tambien los modulos del modelo puedeestar relacionados con otros elementos externos a ellos que forman parte del modelo. Porejemplo, en la lınea 5 se indica que la variable preyDeathRate del modelo raız se conecta ala variable de entrada preyDeathRate del modulo PreyModel y en la lınea 7 se indica queel stock Prey del modulo PreyModel tiene una conexion hacia la variable Prey del modeloraız.

En las lıneas 21, 24, 27 y 30 puede verse la definicion de los aux que estan contenidosen el modelo raız.

4.1.3. Modulos

En la Fig. 4.3 puede observarse un extracto del modulo PreyModel representado en elformato XMILE. Este se corresponde con la representacion grafica de la 3.6b.

Tanto para las variables auxiliares (aux) como para las variables de estado (stock) sedebe especificar un nombre. Si es necesario tener acceso al valor de una variable externaal modelo se debe indicar access=’input’ (ver lıneas 13,16,19). Y, si su valor se utilizaen algun elemento externo al modelo, se debe indicar access=’output’ (ver lınea 2). Enestos casos el modelo tambien debe ser un modulo del modelo inmediato superior.

Tambien estas variables deben contener un elemento eqn, dentro del cual se indicauna ecuacion. Esta ecuacion es utilizada para computar el valor de la variable en t0 de la

28 4. El leguaje XMILE para intercambio de modelos System Dynamics

1 . . .2<v a r i a b l e s>3 <module name=”PreyModel”>4 <connect to=”PreyModel . Predator ” from=” PredatorModel . Predator ”/>5 <connect to=”PreyModel . preyDeathRate” from=” . preyDeathRate”/>6 <connect to=”PreyModel . preyBirthRate ” from=” . preyBirthRate ”/>7 <connect to=” . Prey” from=”PreyModel . Prey”/>8 </module>9 <module name=” PredatorModel ”>

10 <connect to=” PredatorModel . Prey” from=”PreyModel . Prey”/>11 <connect to=” PredatorModel . p r e d a t o r E f f i c i e n c y ” from=” .

p r e d a t o r E f f i c i e n c y ”/>12 <connect to=” PredatorModel . predatorDeathRate ” from=” .

predatorDeathRate ”/>13 <connect to=” . Predator ” from=” PredatorModel . Predator ”/>14 </module>15 <model name=” PredatorModel ”>16 . . .17 </model>18 <model name=”PreyModel”>19 . . .20 </model>21 <aux name=”preyDeathRate”>22 <eqn>0 .02</eqn>23 </aux>24 <aux name=” preyBirthRate ”>25 <eqn>0 .1</eqn>26 </aux>27 <aux name=” predatorDeathRate ”>28 <eqn>0 .3</eqn>29 </aux>30 <aux name=” p r e d a t o r E f f i c i e n c y ”>31 <eqn>0 .01</eqn>32 </aux>33 . . .34</ v a r i a b l e s>35 . . .

Fig. 4.2: Representacion XMILE de Lotka-Volterra: estructura del modelo raız

simulacion. Opcionalmente, un stock puede tambien contener elementos inflow y outflowpara indicar los nombres de los elementos flow que lo afectan. En este caso, la variable deestado Prey tiene un valor inicial de 100, y su valor esta afectado por los flujos de entraday salida PlusPrey y MinusPrey respectivamente(lıneas 2-6).

La ecuacion necesaria para computar el valor de cada flujo se define en los elementosflow. Cada uno de estos se debe corresponder con un inflow y/o un outflow de algunstock del modelo. Por ejemplo, el inflow PlusPrey del stock Prey, computa su valor apartir de la ecuacion Prey ∗ preyBirthRate, contenida en el eqn del flow PlusPrey (verlıneas 4, 7-9 y 23-27).

Por otra parte, en la Fig. 4.4 se muestra un extracto completo de las variables delmodulo PredatorModel. Se corresponde con la representacion grafica presentada en laFig. 3.6a.

La variable Predator (de tipo stock) tiene el atributo access=output (lınea 4). De for-

4.2. Funcionalidades del traductor y el estandar XMILE 29

1<model name=”PreyModel”>2<s tock name=”Prey” a c c e s s=” output ”>3 <eqn>100</eqn>4 <i n f l ow>PlusPrey</ in f l ow>5 <out f low>MinusPrey</ out f low>6</ stock>7<f low name=” PlusPrey ”>8 <eqn>preyBirthRate ∗ Prey</eqn>9</ f low>

10<f low name=”MinusPrey”>11 <eqn>Prey ∗ preyDeathRate ∗ Predator</eqn>12</ f low>13<aux name=”preyDeathRate” a c c e s s=” input ”>14 <eqn>0 .02</eqn>15</aux>16<aux name=” preyBirthRate ” a c c e s s=” input ”>17 <eqn>0 .1</eqn>18</aux>19<s tock name=” Predator ” a c c e s s=” input ”>20 <eqn>5</eqn>21</ stock>22 . . .23< i s e e : d e p e n d e n c i e s>24 <var name=” PlusPrey ”>25 <in>Prey</ in>26 <in>preyBirthRate</ in>27 </ var>28 . . .29</ i s e e : d e p e n d e n c i e s>30</model>

Fig. 4.3: Representacion XMILE de Lotka-Volterra: extracto del modulo PreyModel

ma similar a lo visto en Fig. 4.3, se puede observar que cuando una variable conecta dos mo-delos diferentes, esta debe ser declarada con access=input de un lado, y access=outputdel otro.

4.2. Funcionalidades del traductor y el estandar XMILE

El traductor permite interpretar y traducir de forma total y/o parcial una cantidadconsiderable de funcionalidades (o componentes) que Stella implementa de XMILE.

Para ver un detalle a que nivel de completitud se llego a implementar cada una referirseal Capıtulo 14.

4.2.1. Componentes basicos

A continuacion se detallan los componentes basicos que prescribe el estandar XMILE.

Los componentes stock, flow y aux cuentan con los atributos eqn y units. El valorde eqn puede ser una constante o una ecuacion (compuesta por variables, operadoresmatematicos, funciones y macros). Por otro lado, el atributo units define en que unidadse asume que deberıa estar representada dicha variable.

30 4. El leguaje XMILE para intercambio de modelos System Dynamics

1 . . .2<model name=” PredatorModel ”>3 <v a r i a b l e s>4 <s tock name=” Predator ” a c c e s s=” output ” i s e e : a u t o c r e a t e d=” true ”>5 <eqn>5</eqn>6 <i n f l ow>PlusPredator</ in f l ow>7 <out f low>MinusPredator</ out f low>8 </ stock>9 <f low name=” PlusPredator ”>

10 <eqn>p r e d a t o r E f f i c i e n c y ∗ Predator ∗ Prey</eqn>11 </ f low>12 <f low name=” MinusPredator ”>13 <eqn>Predator ∗ predatorDeathRate</eqn>14 </ f low>15 <aux name=” p r e d a t o r E f f i c i e n c y ” a c c e s s=” input ”>16 <eqn>0 .01</eqn>17 </aux>18 <s tock name=”Prey” a c c e s s=” input ”>19 <eqn>100</eqn>20 </ stock>21 <aux name=” predatorDeathRate ” a c c e s s=” input ”>22 <eqn>0 .3</eqn>23 </aux>24 < i s e e : d e p e n d e n c i e s>25 <var name=” PlusPredator ”>26 <in>Predator</ in>27 <in>p r e d a t o r E f f i c i e n c y</ in>28 <in>Prey</ in>29 </ var>30 <var name=” MinusPredator ”>31 <in>Predator</ in>32 <in>predatorDeathRate</ in>33 </ var>34 </ i s e e : d e p e n d e n c i e s>35 </ v a r i a b l e s>36 . . .37</model>38 . . .

Fig. 4.4: Representacion XMILE de Lotka-Volterra: extracto del modulo PredatorModel

4.2.1.1. Stock

Tag: stock. Se representa graficamente con un cuadrado. Cada uno de estos puedecontener un conjunto de elementos inflow, utilizados para enumerar las variables de tipoflow que aportan a la parte positiva de la derivada del stock en cada DT. De igual forma,puede contener un conjunto de elementos outflow, haciendo referencia a elementos flowque aportan a la parte negativa de la derivada. El atributo eqn solo se utiliza una vezpara computar el valor inicial del stock. Opcionalmente, se puede indicar como restriccionadicional que el stock no pueda tomar valores negativos con el tag non negative. Estasopciones son mutuamente excluyentes.

4.2. Funcionalidades del traductor y el estandar XMILE 31

4.2.1.2. Flow

Tag: flow. Se representa graficamente con una flecha simple o doble con la cola pun-teada y con una canilla en el medio. El valor de la ecuacion de eqn se computa en cadaDT , de acuerdo al valor actualizado de cada variable de input en tiempo t. El resultadode la ecuacion se utiliza tıpicamente (para el caso UNIFLOW) para incrementar el stockdestino de la flecha y decrementar el valor del stock origen. Sin embargo, a los flow tam-bien se los puede declarar como BIFLOW (graficamente se utiliza una doble flecha), locual se permite que se incremente el stock origen y se decremente el stock destino. Encaso que el flow sea UNIFLOW, hay que agregar el tag non negative. Otros parametrosopciones son desbordamiento de cola (queue overflow) y fraccion de fuga del transportador(conveyor leakage fraction).

4.2.1.3. Auxiliary

Tag: aux. Se representa graficamente con un cırculo. La ecuacion eqn se computa encada DT, utilizando el valor de cada variable de input a tiempo t. El resultado de estaecuacion se propaga a todas las variables que incluyan este elemento en su tag eqn.

4.2.1.4. Graphical Function

Muchas veces, el modelador no tiene a su disposicion una ecuacion matematica querepresente la relacion entre dos variables. Suele suceder, sin embargo, que el modeladortenga una idea (posiblemente vaga) de como es esta relacion, y que sea capaz de dibujarlaa mano alzada en un plano x-y.

Para resolver esta cuestion, XMILE permite la creacion de funciones graficas, quepueden ser representadas bajo el tag gf. Asume que la interfaz de la herramienta desimulacion que implementa XMILE (en nuestro caso Stella) permite al modelador dibujara mano la relacion entre una variable de entrada y una de salida de un aux.

Para representar este dibujo en XMILE, es necesaria la introduccion de algunos ele-mentos extra:

xpts: el dominio de la funcion.

xscale: define escala mınima y maxima de la variable independiente

ypts: la imagen de la funcion

yscale: la escala mınima y maxima de la variable dependiente

4.2.2. Metodos de integracion numerica

El metodo de integracion usado en un modelo expresado en XMILE, si no se indica,es por defecto Euler. Otros metodos, pueden estar soportados por los simuladores queimplementen XMILE. Estos son:

Euler (por defecto)

Runge-Kutta 4

Runge-Kutta 2 (Opcional, de no estar implementado se utiliza RK4)

32 4. El leguaje XMILE para intercambio de modelos System Dynamics

Runge-Kutta mixto 4to-5to orden (Opcional)

Algoritmo de Gear (Opcional)

4.2.3. Funciones incluidas

El estandar incluye un conjunto de funciones que es posible utilizar dentro de losmodelos y que los que implementen simuladores que utilicen el formato XMILE debenimplementar. Estas son:

4.2.3.1. Operadores y funciones matematicas

El conjunto de operadores y funciones matematicas que se indica en XMILE es amplio(ver apendice). En este trabajo utilizamos un subconjunto de estos (suma, resta, division,multiplicacion, MIN, MAX) que son suficientes para implementar un amplio numero demodelos de distintas complejidades y satisfacen el proposito de demostrar la utilidad dela estrategia de traduccion.

4.2.3.2. Funciones estadısticas

Ası se llaman en XMILE a elementos generadores de flujo de datos en el tiempo. Lasdiferentes funciones pueden generar flujos con diferentes distribucion, como la uniforme,exponencial, normal, poisson y logarıtmica entre otras.

4.2.3.3. Funciones de Test Input

Las funciones llamadas Test Input son tres: PULSE, STEP y RAMP. Al igual que lasfunciones estadısticas, son generadores de datos, en este caso trayectorias continuas. Envarios de los ejemplos utilizados en esta tesis utilizaremos las funciones STEP y PULSEpara ejemplificar el funcionamiento de SD y del traductor.

4.2.3.4. Funciones de delay

Las funciones de DELAY retrasan senales manipulando el avance de tiempo. Se utilizapor ejemplo en modelos de de sistemas de gestion, para simular el retraso de la propaga-cion del estado de una componente del sistema al resto del mismo (por ejemplo entre laconfeccion de una orden de pedido de un producto hasta que la misma es procesada endestino). Es una clase de funciones con la cual no experimentaremos pero es perfectamen-te posible implementarlas en DEVS con QSS (por ejemplo con los metodos DQSS, ver(Castro et al., 2011))

4.2.3.5. Funciones de tiempo

Estas funciones son en realidad propiedades globales de la simulacion. Estas son:

DT: indica la unidad mınima de particion de la evolucion temporal

STARTTIME: es el instante de tiempo virtual de inicio de la simulacion

STOPTIME: es el instante de tiempo virtual de finalizacion de la simulacion

4.2. Funcionalidades del traductor y el estandar XMILE 33

TIME(t): indica el instante de tiempo virtual actual de la simulacion. Para todo instantede tiempo t devuelve t.

4.2.4. Componentes opcionales

Los siguientes componentes se sugieren como extensiones del lenguaje XMILE y portanto son opcionales a ser implementadas por aquellas herramientas que quieran hacer usodel estandar. Listamos algunas de las que estan implementadas en Stella:

4.2.4.1. Submodelo

Los modelos SD suelen pasar con facilidad de ser visualmente simples y comprensiblesen una unica pantalla a ser una marana incomprensible de elementos stock, flow y aux.Es por esto que muchas veces es conveniente modularizar el modelo en varias partes,generando componentes interactuantes que, en lo posible, sean independientes y puedanser interpretados como una unidad.

Para esto, XMILE permite representar el modelo raız como la interconexion de sub-modelos (que llama modulos), y que a su vez pueden conectarse con los elementos stock,flow y aux del modelo raız. Un ejemplo de esto es el modelo Lotka-Volterra modularizadovisto en secciones anteriores.

4.2.4.2. Array

El elemento array puede ser pensado como un hipercubo de elementos aux de dimen-sion N1×. . .×Nk. Permite ordenar un conjunto de componentes en una nueva estructuraque las contenga a todas, facilitando su procesamiento, particionamiento (slicing) y agre-gacion. Tanto los stock como los flow y los aux pueden ser ordenados en un array.

El elemento array actua de forma similar a un aux: para determinar su estado internodebe calcular su valor de acuerdo a su ecuacion, indicado en el tag eqn, y este puede a suvez ser referenciado por otros.

El ordenamiento de un conjunto de aux en un unico aux (el array) puede ser muy utilprincipalmente para mejorar la legibilidad del modelo, y facilitar la escritura de modelosque requieren de la creacion de muchos los elementos stock, flow o aux.

4.2.4.3. Agregacion sobre array

Hay una infinidad de operaciones de agregacion que se podrıan realizar sobre arrays (osubarrays). El formato XMILE propone que se implementen las siguientes: SUM (calculala suma total del subarray), MIN (el mınimo valor del subarray), MAX (el maximo valor),MEAN (el valor medio), SIZE (indica la cantidad de componentes que conforman el array),STDDEV (calcula la desviacion estandar del subarray elegido a tiempo t).

4.2.4.4. Macros

El estandar permite la definicion de Macros. Esto permite a modeladores y fabricantesdesarrollar nuevas funciones propias, extendiendo ası el repertorio de funciones disponiblespara ser utilizadas cualquier modelos.

34 4. El leguaje XMILE para intercambio de modelos System Dynamics

5. EL FORMALISMO DEVS PARA MODELADO Y SIMULACIONDE SISTEMAS HIBRIDOS

5.1. Definiciones de DEVS

En 1976 el matematico Bernard Zeigler (Zeigler et al., 1976, 2018) propuso un forma-lismo conocido como DEVS (Discrete EVents Systems specifications).

DEVS provee una forma de especificar cualquier sistema cuyas entradas, salidas yestados son constantes a intervalos, y cuyas transiciones instantaneas de un estado alsiguiente se identifican como eventos discretos. El formalismo define como generar nuevosvalores para las variables de estado y el manejo de los instantes en los que estos valoresdeben cambiar. Los intervalos de tiempo entre ocurrencias de eventos pueden ser variables,lo que otorga flexibilidad extra con respecto a formalismos de tiempo discreto (Zeigleret al., 2018).

DEVS hace una clara y esticta separacion entre los conceptos de modelado, simula-cion y ejecucion. El formalismo es independiente de cualquier lenguaje de programacion.Por un lado, permite describir los modelos en forma modular, lo que facilita la reutilizacionde funcionalidades en distintos modelos reduciendo los tiempos de desarrollo y prueba. Porotro lado, DEVS ataca la complejidad de los modelos permitiendo un modelado en formajerarquica (submodelos que a su vez contienen submodelos, etc.) Ademas de un mediode construir modelos simulables, provee una representacion formal para manipular ma-tematicamente sistemas de eventos discretos. Para la ejecucion de las simulaciones, estaaproximacion se integro posteriormente con nociones de programacion orientada a objetos(ver Zeigler, 1984, 1990, 2000).

En cuanto a la construccion de modelos DEVS podemos encontrar dos tipos de mode-los: los modelos atomicos (de comportamiento) y los modelos acoplados (de estruc-tura). Los modelos acoplados se construyen por la interconexion de modelos atomicos yotros modelos acoplados, lo que da forma a una estructura de modelos jerarquica y mo-dular como se esquematiza en la Fig. 5.1. Cada modelo atomico define el comportamientobasico de una parte del sistema, mientras que los modelos acoplados especifican como seconectan las entradas y salidas de sus componentes para formar estructuras de mas altonivel.

35

36 5. El formalismo DEVS para modelado y simulacion de sistemas hıbridos

Fig. 5.1: Ejemplo de acoplamiento jerarquico y modular en DEVS. El modelo DEVS acoplado demas alto nivel es C1, compuesto por modelos atomicos (M1, M2, M3, M3) y por un modeloacoplado (C2). C2 es tratado como si fuera un modelo atomico mas, interactuando conC1 a traves de sus puertos de entrada y salida de la misma forma que lo hacen M1, M2,M3 y M4. Se puede ver aquı que DEVS permite reaprovechar modelos para componermodelos mas complejos: M1 y M3 son modelos atomicos utilizados tanto por C1 comopor C2 de forma independiente.

5.1.1. Definicion formal: modelo DEVS atomico

Un Modelo Atomico DEVS se representa formalmente mediante la siguiente estructura:

M = (X,Y, S, δint, δext, λ, ta) (5.1)

en donde cada elemento representa lo siguiente:X Es el conjunto de eventos externos de en-

tradaY Es el conjunto de eventos externos gene-

rados por la salidaS Es el conjunto de estados secuencialesδext : Q×X → S Es la funcion de transicion externa.

Define los cambios de estado causados poreventos externos. Q = {

(s, e)s ∈ S, e ∈[

0, ta(s)]}

δint : S → S Es la funcion de transicion interna.Define los cambios de estado causados poreventos internos

λ : S → Y Es la funcion de salidata : S → R+

0

⋃∞ Es la funcion de duracion de un esta-

do. ta(s): el tiempo que el modelo perma-nece en el estado s si no ocurre un eventoexterno

Para especificar modelos DEVS, es conveniente considerar que el modelo tiene unainterfaz consistente de puertos de entrada y salida que interactuan con el entorno. Lafuncion δext procesa mensajes que llegan vıa puertos de entrada, mientras que λ envıamensajes hacia puertos de salida.

Esta interfaz de puertos puede definirse como:

I =< PX , P Y > donde:

∀i ∈ {X,Y }, P ij es una definicion de un puerto (de entrada o salida respectivamente),

donde j ∈ N, j ∈[1, µ],(µ ∈ N,µ) y

5.1. Definiciones de DEVS 37

P ij = {

(N i

j , Tij )N i

j ∈[i1, iN

](Nombre del puerto) y T i

j =Tipo del puerto }Un modelo atomico DEVS siempre se encuentra en un estado s ∈ S y cambia su estado

solo a traves de las funciones de transicion: δint y δext. Si no ocurre ningun evento externo,el modelo permanece en el estado s durante el tiempo adjudicado al estado por la funcionta(s). Una vez transcurrido el tiempo ta(s), el modelo primero genera un evento de salida,ejecutando la funcion de salida (λ(s)), y luego cambia su estado al estado indicado porδint(s). En el caso de que llegue un evento externo x ∈ X, el modelo cambia su estadoal estado indicado por la funcion de transicion externa δext(s, e, x), donde la s indica elestado actual del modelo y la e indica el tiempo transcurrido desde la ultima transicion(notar que siempre se cumple e < ta(s)).

En la figura 5.2 se muestra una figura esquematica de la dinamica del comportamientode los modelos atomicos DEVS:

Fig. 5.2: Comportamiento de un Modelo Atomico DEVS. Las flechitas roja y azul denotan el”disparo”de un evento, externo o interno, respectivamente.

5.1.2. Definicion formal: modelo DEVS acoplado

Como mencionamos antes, modelos DEVS pueden componerse con otros modelosDEVS para formar un nuevo modelo mas complejo que se denomina modelo acoplado.Una propiedad muy importante de los modelos DEVS es la de clausura bajo acoplamien-to (Zeigler et al., 2018), que garantiza que dada la definicion de un modelo acoplado yde todos sus modelos componentes, existe un modelo atomico equivalente que reproduceexactamente el mismo comportamiento. Esto permite la existencia de un simulador abs-tracto compacto y universal capaz de darle compotamiento (simular) cualquier modeloDEVS. Dado que todo modelo acoplado es un modelo DEVS, estos tambien pueden for-mar parte de otros modelos acoplados. A los modelos que componen un modelo acopladolos llamaremos submodelos. Un modelo acoplado DEVS se define como:

CM = (Xself , Yself , D, {Mi}, {Ii}, {Zij}, select) (5.2)

en donde cada elemento representa:

38 5. El formalismo DEVS para modelado y simulacion de sistemas hıbridos

Xself El conjunto de eventos externos de en-trada

Yself El conjunto de eventos externos genera-dos por la salida

D.D ∈ N <∞ El conjunto de ındices de modeloscomponentes

Mi Un modelo componente basico corres-pondiente al componente i (modelo DEVSatomico o acoplado), definido como M =<Xi, Yi, Si, δint,i, δext,i, λi, tai > .i ∈ D

Ii El conjunto de modelos influenciadospor el modelo i (modelos que pueden serinfluenciados por salidas del modelo i)

Zij : Yi → Xj La funcion de traduccion de la influen-cia i en j

Select La funcion de prioridad o secuencializa-cion

5.1.3. Definicion formal: Cell-DEVS para automatas celulares

El formalismo DEVS puede ser extendido para permitir la representacion de dominiosde estudio especıficos (por ejemplo Redes de Petri, Maquinas de Estados Finitos, LogicaDifusa y otros). Un caso particular de nuestro interes es la representacion de espacioscelulares a partir de la replicacion sistematica del comportamiento de un modelo DEVSatomico. En Wainer (2009) se explica en detalle como puede definirse esta extension, dandolugar al formalismo Cell-DEVS.

Cell-DEVS permite definir comportamientos celulares a partir de reglas de comporta-miento simples y construir espacios celulares n-dimensionales para representar modelos deeventos discretos complejos. Una version 2-dimensional de Cell-DEVS sera utilizada sobreel final de esta Tesis para modelar un sistema hıbrido combinando System Dynamics conDEVS y Cell-DEVS.

5.1. Definiciones de DEVS 39

Fig. 5.3: (a) Una celda, su vecindario y la lista de vecinos; (b) Conexion de los puertos de salidade la celda i,j (usando la lista de vecinos); (c) conexion de los puertos de entrada de lacelda i,j (utilizando la inversa de la lista de vecinos)

Por ejemplo, uno querrıa poder definir modelos celulares 2-dimensionales como el quese ve en la Fig. 5.3 (Wainer, 2009). Al ser una extension al modelo DEVS basico, estosmodelos celulares podrıan formar parte del mismo modelo formal determinado por otrosmodelos acoplados DEVS, como se muestra en la Fig. 5.4.

La implementacion del formalismo Cell-DEVS abre las puertas a la modelizacion de unsinfın de modelos complejos y con enorme aplicacion en campos de estudio muy variados.

Fig. 5.4: Un modelo acoplado, conformado por la interconexion de modulos DEVS y Cell-DEVS.

Formalmente, un modelo Cell-DEVS puede definirse como una tupla:

TDC = (X,Y, I, S,Θ, E, delay, d, δint, δext, λ, ta, τ) (5.3)

donde:

40 5. El formalismo DEVS para modelado y simulacion de sistemas hıbridos

X Es el conjunto de eventos externos de en-trada

Y Es el conjunto de eventos externos gene-rados por la salida

I Representa la interfaz modular del sistemaS Es el conjunto de estadosΘ Es el conjunto de variables de estado de

cada celdaE Es el conjunto de estados para que los

eventos de entrada calculen el proximo es-tado

delay Es el tipo de tiempo de demora que uti-liza una celda para enviar su valor a losvecinos. Por ejemplo: transport (una colaordenada segun tiempo de output), iner-cial (cada nuevo valor de output desalojaal que estaba encolado previamente)

d ∈ R+0 Es el valor del tiempo de demora de cada

celdaδint : S → S Es la funcion de transicion interna.δext : Q×X → S Es la funcion de transicion externa.λ : S → Y Es la funcion de salidata : S → R+

0

⋃∞ Es la funcion de duracion de un esta-

doτ Es la funcion de computo local (para cal-

cular cual debe ser el proximo estado)

Una vez definido el comportamiento de una celda, es necesario formar un espacio deceldas como un modelo DEVS acoplado:

CellDEV SCM = (Xlist, Y list, I,X, Y, n, {t1 . . . tn}, N,C,B,Z, Select) (5.4)

Donde:

5.2. DEVS y Metodos de Integracion Numerica 41

Xlist = {(k, l)k ∈ [0,m], l ∈ [0, n]} Es la lista de acoplamiento de entradaY list = {(k, l)k ∈ [0,m], l ∈ [0, n]} Es la lista de acoplamiento de salidaI Representa la definicion de la interfaz para

el modelo modularX Es el conjunto de eventos externos de en-

tradaY Es el conjunto de eventos externos gene-

rados por la salidan Es la dimension del espacio celular{t1 . . . tn} Es el numero de celdas que hay en cada

dimensionN Es el conjunto vecindad. Define las co-

nexiones entre celdasC Es el espacio celular. Debe ser un con-

junto finitoB Es el conjunto de celdas borde. Estas cel-

das pueden tener vecinos que no pertenez-can al espacio celular (unwrapped) o quesı pertenezcan (wrapped)

Z Es la funcion de traduccion entre aco-plamiento interno y externo de celdas

Select Es la funcion de prioridad o secuencia-lizacion

5.2. DEVS y Metodos de Integracion Numerica

Los sistemas dinamicos se pueden dividir en tres categorıas de acuerdo a la formaen que sus variables evolucionan en el tiempo: Sistemas de Tiempo Continuo (cambiancontinuamente con el tiempo), de Tiempo Discreto (cambian en instantes determinadosde tiempo) y de Eventos Discretos (pueden cambiar en cualquier instante).

Mientras los sistemas discretos se pueden simular de manera directa, los sistemas detiempo continuo requieren de la utilizacion de metodos de integracion numerica. Estosmetodos generalmente aproximan las ecuaciones diferenciales mediante ecuaciones en di-ferencias, discretizando la variable independiente (el tiempo).

Muchos sistemas de la ingenierıa combinan caracterısticas continuas y discretas. Estossistemas se denominan hıbridos y sus modelos matematicos contienen ecuaciones diferen-ciales cuyas variables interactuan con otras variables de evolucion discreta. La interaccionentre las variables continuas y discretas de los sistemas hıbridos provoca discontinuida-des en las ecuaciones diferenciales. Estas discontinuidades causan muchas dificultades alos algoritmos de integracion numerica ya que los mismos deben detectar exactamentelos instantes en los que estos se producen y reiniciar la simulacion desde ese momento(Cellier and Kofman, 2006), lo que conlleva un aumento muy importante de los costoscomputacionales.

Un enfoque esencialmente distinto al de los metodos clasicos de integracion reemplazala discretizacion temporal por la cuantificacion de las variables de estado, dando lugara los llamados metodos de integracion por cuantificacion de estados. Estos metodos sebasan en una idea original de Bernard Zeigler, quien propuso que los sistemas continuos

42 5. El formalismo DEVS para modelado y simulacion de sistemas hıbridos

podrıan aproximarse por sistemas de eventos discretos bajo el formalismo DEVS (Zeigler,2000). Posteriormente, en Kofman and Junco (2001) se demostro que la cuantificaciondebıa realizarse con el agregado de histeresis y con esa idea se formalizo el primer metodode integracion por cuantificacion llamado QSS. Actualmente existen varios metodos deintegracion por cuantificacion: QSS1, QSS2 (Kofman, 2002; Cellier and Kofman, 2006) yQSS3 (Kofman, 2006).

Los QSS tienen propiedades teoricas muy fuertes: convergencia, estabilidad (Cellierand Kofman, 2006; Kofman and Junco, 2001) y una propiedad notable de existencia decota de error global calculable (Kofman, 2002; Cellier and Kofman, 2006). La caracterısti-ca asıncrona de los metodos QSS los hace particularmente eficientes para la integracionnumerica de sistemas con discontinuidades (Kofman, 2004), donde pueden reducir en masde un orden de magnitud los costos computacionales respecto de los metodos clasicos.Dado un sistema continuo (o hıbrido), cualquiera de los metodos QSS lo puede aproxi-mar (con una cota de error tan pequena como se desee) mediante un sistema de eventosdiscretos DEVS.

5.2.1. Metodo QSS de primer orden (QSS1)

Considerese un conjunto de ODEs invariantes en el tiempo representado en forma deespacio de estados:

x’(t) = f(x(t),u(t)) (5.5)

donde x(t) ∈ Rn es el vector de estados y u(t) ∈ Rw es un vector de trayectorias deentrada, conocidas constantes a tramos.

El metodo QSS de primer orden (QSS1) simula una version aproximada de la Ecua-cion 5.5 y se lo denomina Quantized State System (QSS):

x’(t) = f(q(t),u(t)) (5.6)

donde q(t) es un vector de estados cuantificados que resulta de la cuantificacion de lasvariables de estado xj(t).

Cada componente de q(t) sigue una trayectoria constante a tramos, relacionada con sucorrespondiente componente x(t) por una funcion de cuantificacion con histeresis definidapor:

qj(t) =

{xj(t) if |qj(t−)− xj(t)| = ∆Qj

qj(t−) else

(5.7)

con qj(t0) = xj(t0) y siendo t− el lımite por izquierda del instante t. Luego, qj(t) resultaen una aproximacion constante a tramos de xj(t) que cambia su valor unicamente cuandoambas trayectorias difieren en ±∆Qj . La magnitud ∆Qj se denomina quantum. La relacionentre xj y qj se describe en la Fig. 5.5.

5.2. DEVS y Metodos de Integracion Numerica 43

Fig. 5.5: Funcion de cuantificacion de estado con histeresis (izquierda) y cuantificacion con anchode histeresis ε = ∆Q (derecha)

En la Fig. 5.5 se muestra un ejemplo de cuantificacion para una trayectoria arbitrariax(t) aplicando la relacion de la Ecuacion 5.6. La presencia de histeresis en QSS1 evitala presencia de oscilaciones de frecuencia infinita que impedirıan el avance del tiempo desimulacion (Cellier and Kofman, 2006).

El sistema QSS1 puede simular cualquier sistema con la estructura de la Ecuacion 5.5,manteniendo ademas las siguientes propiedades:

Preserva la estabilidad numerica (sin involucrar formulas implıcitas). La cuantifica-cion puede ser tratada como una perturbacion acotada de la ODE original, de modoque la estabilidad no lineal puede ser estudiada por medio de funciones de Lyapunov(Kofman and Junco, 2001).

Ofrece una cota de error global, que garantiza que la solucion numerica de un sistemalineal invariante en el tiempo analıticamente estable nunca diferira de su solucionanalıtica por una cantidad mayor a un valor finito y calculable (Cellier and Kofman,2006).

Es intrınsecamente asıncrono: cada variable de estado actualiza su valor en distintosinstantes, independientemente del resto de los estados. Esto ofrece una ventaja sig-nificativa en terminos de performance cuando se tratan sistemas con matrices ralas.Provee salida densa, una caracterıstica particularmente util para metodos asıncronos.

Es muy eficiente al simular a traves de discontinuidades fuertes, debido a la sim-plicidad de los procedimientos requeridos para resolver raıces de polinomios cuandose dispone de una salida densa. Asimismo, debido a las propiedades asıncronas delmetodo, cada discontinuidad puede manejarse eficientemente de forma aislada.

5.2.2. Relacion entre QSS y el formalismo DEVS

La Fig. 5.6 muestra un diagrama de bloques de la Ecuacion 5.6. En gris, la figuramuestra dos tipos de subsistemas: bloques tipo Fi (funciones estaticas) y bloques tipo HQI(integradores cuantificados con histeresis). Los bloques Fi corresponden a las funciones quecalculan la parte a la derecha de la Ecuacion 5.6, mientras que HQI se compone de unintegrador y una funcion de cuantificacion con histeresis.

44 5. El formalismo DEVS para modelado y simulacion de sistemas hıbridos

Fig. 5.6: Sistema de estados cuantizados

Fig. 5.7: Representacion de QSS mediante diagrama de bloques. Referencia de flechas: fina (senalsimple), gruesa (bus de multiples senales).

Cada bloque Fi tiene a su entrada trayectorias continuas a tramos qj y uj , y calculauna trayectoria de salida continua a tramos x′j . Similarmente, los bloques HQI recibenentradas continuas a tramos x′j , y calculan sus trayectorias de salida continuas a tramosqj .

Ya que las trayectorias continuas a tramos pueden representarse por secuencias deeventos, y recordando que los modelos atomicos DEVS pueden representar cualquier sis-tema que reciba y/o produzca este tipo de secuencias, cada bloque en la Fig. 5.6 puedeser representado por un modelo atomico DEVS.

Para las funciones estaticas Fi y los integradores cuantificados con histeresis HQI, losmodelos DEVS equivalentes resultan ser muy sencillos (cf.Cellier and Kofman, 2006).

Luego, puede obtenerse un modelo DEVS equivalente al de Ecuacion 5.6 mediante elacoplamiento de los modelos DEVS atomicos correspondientes a Fi y a HQI del modo quese muestra en el diagrama de bloques de la Fig. 5.6.

5.2.3. QSS frente a otros metodos de integracion

Los algoritmos de QSS tienen mejor performance frente a otros metodos clasicos detiempo discretos cuando las ODEs tienen ciertas caracterıticas (discontinuidades frecuen-tes, grandes modelos esparsos, etc.).

Los usos y ventajas de los algoritmos QSS en diferentes campos de aplicacion se hanreportado extensamente en la literatura, incluyendo redes nueronales de impulso (Grinblatet al., 2012), convertidores electronicos de potencia (Migoni et al., 2015), ecuaciones deadveccion difusion reaccion (Bergero et al., 2016), redes inteligentes (Migoni et al., 2016),simulacion de edificios (Manuel Soto Frances et al., 2014, 2015; Bergero et al., 2018) ytransporte de partıculas en fısica de altas energıas (Santi et al., 2017).

Otra aplicacion en la que los metodos QSS han demostrado notables beneficios es enla simulacion de circuitos integrados, donde estos metodos pueden ejecutarse mucho masrapido (50 veces) con un analisis de ruido mas preciso que los metodos convencionales(Jakobsson et al., 2015).

El problema de la paralelizacion y la simulacion distribuida tambien se estudio en elcontexto de la simulacion QSS. La naturaleza asıncrona de los algoritmos permite obtenerbuenas velocidades en las simulaciones realizadas en arquitecturas multinucleo (Bergero

5.3. Herramientas de simulacion 45

et al., 2013; Fernandez and Kofman, 2014). Un estudio de escorrenterıa de una cuenca degran escala usando un modelo celular espacial de alta resolucion mostro un aumento develocidad de mil veces en la computacion en plataformas paralelas masivas (Zeigler et al.,1997). Las celulas se modelaron con ecuaciones diferenciales ordinarias y la cuantificacionse comparo con un metodo numerico de tiempo discreto estandar.

5.3. Herramientas de simulacion

Al igual que en el caso de System Dynamics, tambien se han desarrollado muchosprogramas de simulacion para el formalismo DEVS. A continuacion, destacamos algunos:

CD++: es el que elegimos para este trabajo. Es un software desarrollado casi ıntegramenteen el Departamento de Computacion, por alumnos y docentes. Permite una muybuena performance en la simulacion de sistemas celulares, tematica que nos resultainteresante para su combinacion de forma hıbrida con modelos System Dynamics.

PowerDEVS: desarrollado en la Universidad Nacional de Rosario. Fue disenado inicial-mente para demostrar las capacidades de los metodos QSS. Esta optimizado paraser utilizado en tiempo real (Bergero and Kofman, 2011b)

PythonDEVS: pertenece a la familia de Parallel DEVS y fue implementado en 2014. Tienela ventaja de estar programado en Python, lo cual facilita su extension y combinacioncon muchos otros programas.

Para un relevamiento reciente de simuladores DEVS vigentes (incluyendo una compa-racion en terminos de desempeno) puede consultarse en Van Tendeloo and Vangheluwe(2017).

46 5. El formalismo DEVS para modelado y simulacion de sistemas hıbridos

6. RELACION ENTRE INTEGRADORES SD → DEVS: IDEAMOTIVADORA

Como ya vimos, la estructura elemental clave de SD consiste en un stock y sus flujos deentrada y salida controladas. Para concebir una representacion DEVS de esta estructura unprimer paso razonable es encontrar una unidad basica de comportamiento en DEVS que seaequivalente al submodelo de ”stock-and-flow”de SD. En terminos teoricos lo que se deseaes establecer un isomorfismo SD-a-DEVS en el nivel de Acoplamiento de Componentes1

En la Tabla 6.1 se puede ver un posible modelo basado en DEVS que es isomorfico conel submodelo de stock y flujo de SD. Se ven cuatro modelos atomicos DEVS: un integradordinamico (por ejemplo, usando QSS) y tres funciones sin memoria: una funcion derivada(F der), una funcion tasa de incremento (F incr) y una funcion de tasa de decremento(F decr).

Fig. 6.1: La estructura basica de elementos stock y flow. SD (arriba) y DEVS (abajo).

La correspondencia entre los componentes de los modelos SD y DEVS se resume en latabla de la Tabla 6.1.

Integrador QSS: La condicion inicial x0 es la misma que la del Stock en SD. El hecho deque la salida de QSS es q(t), mientras que la salida Stock en SD es x(t) no planteauna inconsistencia pues q(t) es la version cuantificada de x(t). La cuantizacion tieneun error e(t) = x(t)− q(t) que en sistemas lineales esta limitado globalmente por elparametro de precision de estado DeltaQ. Con respecto a la salida x(t) en el StockSD, tambien incluye el inevitable error de integracion producido por el parametrode paso de tiempo (DT en la jerga SD). En el modelo QSS x(t) esta disponible comouna variable de estado interno.

1 Nivel 4 en las categorıas de morfismos segun Klir, ver Morphism Relations Between Systems, (Zeigleret al., 2018), p.19

47

48 6. Idea Motivadora

ComponenteSD

ComponenteDEVS

(modeloatomico)

Parametros basicos RolExpression

(basado en puerto)Numero de

puertosRequerido

QSSCondicion inicial (x0),precision (DeltaQ)

Integracion basada enestados cuantificados

out1=QSS(in1)1 entrada,1 salida

Sı

StockF der

Calcular la derivada dela variable de estado

out1=in1 - in22 entrada,1 salida

Sı

Tasa deincremento

F incCalcular el terminoaditivo para F der

out1=F inc(in1,...,inM)M entrada,1 salida

No

Tasa dedecremento

F decrCalcular el terminosubstractivo para F der

out1=F decr(in1,...,inN)N entrada,1 salida

No

Tab. 6.1: Las caracterısticas de cada elemento grafico correspondiente a la figura 6.1

Funcion derivada (F der): Es una funcion estatica (es decir, actualiza su salida cada vezque un nuevo evento llega a cualquier puerto de entrada). Calcula el valor de laderivada de x(t) como una combinacion de un termino aditivo (in1) y un terminosustractivo (in2). Esta funcion se realiza implıcitamente en SD, porque el ”paradigmade la banera”visual asume que la tasa neta de cambio es la accion combinada de unatasa de incremento y una de decremento. Este enfoque se basa en el supuesto deque las tasas nunca asumen valores negativos. Es obvio que una tasa de incrementonegativa no contribuye de manera incremental a la accion, y el mismo razonamientose mantiene para un decremento negativo de la tasa (que en realidad contribuirıaincrementalmente). Esta es una caracterıstica incomoda del paradigma SD. De hecho,se ha agregado un “biflujo” (flujo bidireccional) a las herramientas SD para hacerfrente a esta limitacion. Aquı, la metafora de la banera se debilita y pierde la intuicionvisual que constituıa su atractivo. En el enfoque DEVS, F der siempre calcularadx(t)/dt = F incr(t) − F decr(t) sin ninguna consideracion particular sobre lossignos que sus senales de entrada puedan llevar.

Funcion de tasa de incremento (F incr) : Esta es una funcion sin memoria que calcula latasa de incremento, es decir, la porcion aditiva de F der. Implementa una funciongeneralizada de las senales de entrada 1 a M.

Funcion de tasa de decremento (F decr): De manera analoga, esta es una funcion sin me-moria que calcula la tasa de decremento, es decir, la porcion sustractiva de F der.Implementa una funcion generalizada del senales de entrada 1 a N.

6.1. Ejemplos

En esta seccion, mostramos el modelo Lotka-Volterra presentado en secciones ante-riores, pero esta vez representado graficamente en el formalismo DEVS. En gris se muestranlos modelos atomicos, y en rojo y azul los modelos acoplados.

6.1.1. Lotka-Volterra Basico (modularizado)

En la Fig. 6.2 se muestra como luce la traduccion a DEVS del modelo Lotka-Volterrapresentado en la figura 3.5 en System Dynamics. El modelo top (en rojo) es un modeloDEVS acoplado, que cuenta con cuatro modulos atomicos (predatorEfficiency, predator-DeathRate, preyDeathRate y preyBirthRate) y dos acoplados (PredatorModel y Prey-Model). Las flechas muestran las interconexiones entre los puertos de cada uno de losmodulos.

6.1. Ejemplos 49

Fig. 6.2: Modelo Lotka-Volterra basico (modularizado)

En la Fig. 6.3 se muestra en rojo el modulo acoplado PredatorModel, que en la fi-gura 6.2 esta en azul. Se puede observar tambien que en nuestra implementacion se repitela aparicion de los modulos atomicos PredatorDeathRate y PredatorEfficiency, correspon-dientes a los parametros del modelo. Esto fue una decision de diseno: como PredatorModelpodrıa ser tratado de forma independiente al resto del modelo, consideramos que generarun atomico aparte para dicho parametro podrıa ser interesante y util (por ejemplo, paraagregar alguna transformacion o factor de escalamiento a los valores crudos que le lleganal modulo por sus puertos de entrada), en lugar de forzar a que el valor recibido por inputsea el utilizado de forma directa.

Tambien se observa que el modulo PredatorModel esta compuesto por dos modu-los atomicos y uno acoplado (en azul, DEVS INTEGRATOR COUPLED Predator). Esteultimo es un ejemplo de modulo acoplado minimal que implementamos para traducir laestructura de elementos stock y flow de SD. En particular, este modulo se corresponderıaa un stock Predator junto con todos sus elementos flow de input y output, que en estecaso son solamente dos: Fminus Predator y Fplus Predator.

Es interesante destacar que hay una correspondencia uno a uno entre el modelo graficode la Fig. 6.3 y el modelo SD representado en la Fig. 3.6a.

Por ultimo, en la Fig. 6.4 se muestra la correspondencia entre el modelo grafico SDrepresentado en la Fig. 3.6b y el modelo grafico DEVS de su traduccion. La interpretacionde los modulos atomicos y acoplados y sus interconexiones es analoga a la que hicimospara el modulo PredatorModel.

50 6. Idea Motivadora

Fig. 6.3: Modelo PredatorModel

Fig. 6.4: Modelo PreyModel

Parte II

APORTES

7. DEFINICION DEL LENGUAJE µDEVSML PARAINTERCAMBIO DE MODELOS DEVS

En Mittal et al. (2007) se presenta un formato textual para especificar es intercam-biar modelos DEVS llamado DEVSML (DEVS-Modeling-Language) basado en el popularformato declarativo XML (Yergeau et al., 2008).

DEVSML presenta unas capacidades (y su complejidad asociada) que exceden lasnecesidades de este trabajo. Luego, inspirados en DEVSML, producimos un conjunto masacotado de declaraciones que llamamos µDEVSML (micro-DEVS-Modeling-Language) yque sera suficiente para nuestro propositos de traduccion de modelos SD.

7.1. El formato DEVSML

La idea detras de DEVSML es poder proveer interoperabilidad entre modelos alojadosen locaciones remotas utilizando el paradigma cliente-servidor, en donde la simulacion esejecutada del lado del servidor. Las definiciones de tipo de documento (en ingles DTDs)para los modelos atomicos y acoplados DEVS propuestos estan pensados para ser abiertosa la estandarizacion por parte de la comunidad para un exitosa colaboracion y distribucionde modelos por parte de la misma.

Dado que esta pensado para la interoperabilidad entre distintas implentaciones deDEVS alojadas en distintos servidores, se puede ver en DEVSML la definicion del tagservice y los atributos XML simulator y host en los DTDs para el componente atomico yacoplado DEVS.

DEVSML tuvo inicialmente como objetivo la posibilidad de ser utilizado facilmentecon DEVSJAVA, un simulador particular para DEVS, y por ello encontramos tags comojava-specific y java-source-program que a nuestro parecer son demasiado especıficos dedicha herramienta en particular.

En cuanto a los componentes atomicos en DEVSML estan, entre otros, los tags inputs,outputs, states, deltint , deltext , lambda, ta para definir X,Y ,S,δint,δext,λ, ta del compo-nente atomico. Pero de Mittal et al. (2007) no queda claro de que manera se describenestos valores (entendemos que queda a criterio de quien lo define, pensando en el simuladordonde se ejecutara el modelo).

Nuestro objetivo es obtener un formato de salida que nos permita describir modelosDEVS sin necesidad de describir el simulador con el cual este se deba ejecutar, ni describirel modelo en funcion de un simulador en particular, ni implementar una arquitecturacliente-servidor particular para la ejecucion de cada modelo. Es por estos motivos que eneste trabajo decidimos definir µDEVSML para describir los modelos DEVS.

7.2. El formato µDEVSML

Como se indico anteriormente, al momento de especificar un modelo DEVS uno seencuentra con la cuestion de que como especificar dentro del archivo XML dicho modelode manera que resulte clara y legible.

Dado que en la bibliografıa existente no hay un consenso sobre como realizar dichaespecificacion de un modelo DEVS, salvo que la misma sea entendible y no ambigua, la

53

54 7. Definicion del lenguaje µDEVSML para intercambio de modelos DEVS

pregunta es, ¿para quien estamos realizando la especificacion? Si es para otra persona,podrıa ser que el texto en un XML sea insuficiente o complicado para la especificacion delmodelo. Por ejemplo, quizas el uso de diagramas o figuras ayuden a su interpretacion.

Si es para que lo utilice un programa, ¿usamos algun lenguaje preexistente? ¿Definimosun nuevo lenguaje especıfico para tal fin? Pensamos que cualquiera de las dos decisionesdesalienta el uso del traductor de modelos SD, ya que es un lenguaje adicional que elmodelador o implementador del simulador tendra que traducir, en caso que decida imple-mentar un traductor de DEVSML al formato que utilice el simulador para describir losmodelos DEVS.

En el caso de CD++, que es el simulador que pensamos utilizar para simular losmodelos traducidos de SD a DEVS, el modelo a simular se especifica mediante un archivode texto en donde se indican sus puertos de entrada y salida, los componentes que loconforman y su interconexion. Este archivo es muy similar al archivo de DEVSML paradescribir un modelo acoplado, salvo que aquı no hay informacion referida al simulador oa los detalles del modelo atomico (como δint,δext,λ o ta). Del modelo atomico se indica elnombre del modelo, sus parametros, puertos e interconexiones, quedando los otros detallesdefinidos dentro del codigo que implementa las funciones dinamicas en C++.

Es por ello que, tomando de base las ideas de CD++, decidimos tratar los modelosatomicos en µDEVSML como cajas negras cuya especificacion esta definida en la descrip-cion del modelo. Ası, el archivo µDEVSML describe un modelo general, con sus componen-tes y cuyo detalle de los modelos atomicos no esta atado a un lenguaje o implementacionen particular.

Para lograr esto tanto para el componente atomico como el acoplado, agregamos el atri-buto XML model para indicar el nombre del modelo de cada componente, cuya definicionexacta queda fuera de la definicion del archivo XML.

7.2.1. Componente atomico

Para ayudarnos en la implementacion, para el componente atomico tambien definimosel atributo XML parent para el tag del tipo atomicRef que indica cual es el componentepadre en caso de composicion.

Para los tags del tipo port definimos el atributo type.

1 <!-- DEVS ATOMIC MODEL -->

2 <!ENTITY atomicRef (inputs , outputs , parameters)>

3 <!ATTLIST atomicRef

4 model CDATA #REQUIRED

5 name ID #REQUIRED

6 parent CDATA #REQUIRED >

7 <!ELEMENT inputs (port*)>

8 <!ELEMENT port EMPTY >

9 <!ATTLIST port

10 name CDATA #REQUIRED

11 type CDATA #IMPLIED >

12 <!ELEMENT outputs (port*)>

13 <!ELEMENT parameters (parameter *)>

14 <!ATTLIST parameter name CDATA #REQUIRED >

Fig. 7.1: DTD del modelo atomico en µDEVSML

7.2. El formato µDEVSML 55

El tag agrupador parameters agrupa tags del tipo parameter , los cuales permiten definirlos parametros utilizados por el componente y sus valores.

Los tags y atributos XML de DEVSML hacen a cuestiones de implementacion, y losremovimos ya que no nos eran de utilidad.

En la Fig. 7.1 mostramos la definicion del tipo de documento para los componentesatomicos. Se puede observar que:

el tag principal es atomicRef

los atributos antes mencionados name, para el nombre del componente, model paraidentificar el modelo del componente y parent para identificar el componente padre

dentro del tag principal estan definidas las estructuras para especificar los puertosde entrada (tag inputs) y de salida (tag inputs), ası como los parametros del modelo(tag parameters)

7.2.2. Modelo atomico de ejemplo

Para ejemplificar lo explicado anteriormente, definiremos un modelo DEVS y mostra-remos como este queda expresado en µDEVSML e implementado en CD++. A este modelolo llamaremos Sumador y en la figura Fig. 7.2 se muestra la definicion DEVS del mismo.

State variables: sigma =∞, phase = passive, x, yParameters: f : <2 → <|f(a, b) = a+ bX : a, bY : totalS : (sigma, phase, a, b)

function δext(s, e, x)if x.port == a then

a = x.valueelse if x.port == b then

b = x.valueend if

end function

function δint(s)if phase == busy then

phase = passivesigma =∞

end ifif phase == passive then

/* Never happens */end if

end function

function λ(s)send total = f(a, b) to output port

end function

Fig. 7.2: Sumador: definicion en DEVS

56 7. Definicion del lenguaje µDEVSML para intercambio de modelos DEVS

Este ha sido definido como un modelo DEVSAux (ver 8.3.2.1 DEVSAux) cuyo parame-tro es la funcion f(a, b) = a + b y que tiene a y b como puertos de entrada y total comopuerto de salida. De este ulitmo sale el valor de a+ b al llegar un nuevo valor de a o b (siambos valores estan definidos).

Si observamos la Fig. 7.3 veremos el valor del atributo model en el tag atomicRef(DEVSAux, lınea 1). Los puertos de entrada a y b estan definidos en las lıneas 3 y 4respectivamente. El puerto de salida total esta en la lınea 7. Y en la lınea 10 esta comoparametro del modelo la funcion a+ b.

1 <atomicRef model="DEVSAux" name="Sumador" parent="top">

2 <inputs >

3 <input name="x" type="in" />

4 <input name="y" type="in" />

5 </inputs >

6 <outputs >

7 <output name="total" type="out" />

8 </outputs >

9 <parameters >

10 <parameter name="equation">a+b</parameter >

11 </parameters >

12 </atomicRef >

Fig. 7.3: Sumador: definicion en µDEVSML

En el extracto de codigo de la Fig. 7.4 puede verse que al executarse externalFunction(deltaext del modelo DEVS, lıneas 6 a 10), si el mensaje ingresa por el puerto a se le asignasu valor a una variable interna a y lo mismo sucede con la variable b si el puerto de entradaes el b. Al ejecutarse la outputFunction (funcion λ en DEVS) se envıa por el puerto desalida el valor de a+ b (lıneas 17 a 19).

1 Model &Sumador :: initFunction (){

2 holdIn(AtomicState ::passive , VTime::Inf);

3 return *this;

4 }

5 Model &Sumador :: externalFunction(const ExternalMessage &msg){

6 double in_val = Tuple <Real >:: from_value(msg.value())[0]. value ();

7 if(msg.port() == in_port_a) {this ->a = in_val ;}

8 if(msg.port() == in_port_b) {this ->b = in_val ;}

9 holdIn(AtomicState ::active , VTime::Zero);

10 return *this;

11 }

12 Model &Sumador :: internalFunction(const InternalMessage &){

13 passivate ();

14 return *this ;

15 }

16 Model &Sumador :: outputFunction(const CollectMessage &msg){

17 Tuple <Real > out_value { a + b };

18 sendOutput(msg.time(), out_port_total , out_value);

19 return *this ;

20 }

Fig. 7.4: Sumador: extracto de codigo CD++

7.2.3. Ejemplos de modelos atomicos implementados en µDEVSML

A continuacion mostramos ejemplos de algunos de los modelos atomicos que imple-mentamos tal como quedan definidos en µDEVSML.

7.2. El formato µDEVSML 57

En la figura Fig. 7.5 puede verse un modelo DEVSConstant (ver 8.3.2.2 DEVSCons-tant). En este ejemplo, se envıa por el puerto de salida predatorDeathRate (lınea 3) elvalor 0,3, indicado su nombre usando el tag name (el nombre del parametro aquı es value,lınea 6).

1 <atomicRef model="DEVSConstant" name="predatorDeathRate" parent="top">

2 <outputs >

3 <output name="predatorDeathRate" type="out" />

4 </outputs >

5 <parameters >

6 <parameter name="value">0.3</parameter >

7 </parameters >

8 </atomicRef >

Fig. 7.5: µDEVSML: ejemplo de modelo DEVSConstant

Un ejemplo del modelo DEVSIntegrator se muestra en la Fig. 7.6. Este modelo imple-menta el metodo de integracion por cuantificacion QSS1 (mencionado en la Seccion 5.2),que requiere de los parametros x0, dQMin y dQRel (lıneas 11 a 13). El puerto TotPreda-tor es el puerto de entrada de los valores a integrar (lınea 3) y los puertos de entradaincrement y subtract permiten variar el valor de la funcion manera discreta (lıneas 4 y 5).El parametro non negative, puede permitir o bloquear la posibilidad de que la salida seamenor a 0 (lınea 14).

1 <atomicRef model="DEVSIntegrator" name="Predator" parent="

DEVS_INTEGRATOR_COUPLED_Predator">

2 <inputs >

3 <input name="TotPredator" type="in" />

4 <input name="increment" type="in" />

5 <input name="subtract" type="in" />

6 </inputs >

7 <outputs >

8 <output name="Predator" type="out" />

9 </outputs >

10 <parameters >

11 <parameter name="x0">5</parameter >

12 <parameter name="dQMin">0.001 </parameter >

13 <parameter name="dQRel">0.001 </parameter >

14 <parameter name="non_negative">0</parameter >

15 </parameters >

16 </atomicRef >

Fig. 7.6: µDEVSML: ejemplo de modelo DEVSIntegrator

En la Fig. 7.7 puede verse un ejemplo del modelo DEVS DEVSFplus. Este se corres-ponde con la funcion de incremento, F incr (mencionada en Capıtulo 6), la cual calculael valor de una funcion de acuerdo a los valores ingresados por su puertos de entrada. Lospuertos de entrada en este caso estan definidos en las lıneas 3 a 5 y son los parametros deentrada de la funcion del parametro de nombre equation (lınea 11).

El modelo de la Fig. 7.8 es un ejemplo del modelo DEVSPulse que es la traduccion aDEVS de la funcion PULSE definida en OASIS XML Interchange Language (XMILE) forSystem Dynamics TC, 3.5.4 Test Input Functions. Para mas detalles sobre este modelo

58 7. Definicion del lenguaje µDEVSML para intercambio de modelos DEVS

1 <atomicRef model="DEVSFplus" name="PlusPredator_Predator" parent="

DEVS_INTEGRATOR_COUPLED_Predator">

2 <inputs >

3 <input name="Predator" type="in" />

4 <input name="Prey" type="in" />

5 <input name="predatorEfficiency" type="in" />

6 </inputs >

7 <outputs >

8 <output name="PlusPredator_Predator" type="out" />

9 </outputs >

10 <parameters >

11 <parameter name="equation">predatorEfficiency*Predator*Prey</

parameter >

12 </parameters >

13 </atomicRef >

Fig. 7.7: µDEVSML: ejemplo de modelo DEVSFplus

ver 8.3.2.4 DEVSPulse.

1 <atomicRef model="DEVSPulse" name="PULSE_V_volume_I_interval_pulser" parent

="DEVS_COUPLED_top">

2 <inputs >

3 <input name="first" type="in" />

4 <input name="volume" type="in" />

5 <input name="interval" type="in" />

6 </inputs >

7 <outputs >

8 <output name="PULSE_V_volume_I_interval_pulser" type="out" />

9 </outputs >

10 <parameters >

11 <parameter name="equation">volume </parameter >

12 <parameter name="volume_input">volume </parameter >

13 <parameter name="firstPulse_input">first </parameter >

14 <parameter name="interval_input">interval </parameter >

15 <parameter name="dt">50</parameter >

16 </parameters >

17 </atomicRef >

Fig. 7.8: µDEVSML: ejemplo de modelo DEVSPulse

7.3. Componentes Acoplados

Para los componentes acoplados en µDEVSML el DTD asociado es el que se muestraen la Fig. 7.9.

Ademas de agregar el atributo XML model para poder indicar el modelo del compo-nente y el parent para indicar cual es el componente padre, agregamos el atributo typepara los tags del tipo port y del tipo connection.

Tambien puede verse en el DTD la recursion en la definicion del elemento components(lınea 13). Este esta conformado por cero o mas elementos del tipo atomicRef o coupledRef,los que permiten definir componentes atomicos y acoplados respectivamente.

7.3. Componentes Acoplados 59

Las conexiones, elementos del tipo connection, permiten definir las conexiones inter-nas (internal connections), externas de entrada (external input connections)y externas desalida (external output connections).

1 <!-- DEVS COUPLED MODEL -->

2 <!ELEMENT coupledRef (inputs ,outputs ,components ,internal_connections ,

external_input_connections ,external_output_connections >

3 <!ATTLIST coupledRef

4 model CDATA #REQUIRED

5 name ID #REQUIRED

6 parent CDATA #REQUIRED >

7 <!ELEMENT inputs (port*)>

8 <!ELEMENT port EMPTY >

9 <!ATTLIST port

10 name CDATA #REQUIRED

11 type CDATA #IMPLIED >

12 <!ELEMENT outputs (port*)>

13 <!ELEMENT components (coupledRef|atomicRef)*>

14 <!ELEMENT atomicRef (inputs , outputs , parameters)>

15 <!ATTLIST atomicRef

16 model CDATA #REQUIRED

17 name ID #REQUIRED

18 parent CDATA #REQUIRED >

19 <!ELEMENT internal_connections (connection *)>

20 <!ELEMENT external_input_connections (connection *)>

21 <!ELEMENT external_output_connections (connection *)>

22 <!ELEMENT connection EMPTY >

23 <!ATTLIST connection

24 component_from CDATA #REQUIRED

25 component_to CDATA #REQUIRED

26 port_from CDATA #REQUIRED

27 port_to CDATA #REQUIRED

28 type CDATA #IMPLIED >

Fig. 7.9: Modelo acoplado en µDEVSML

A continuacion mostramos algunos de los modelos acoplados que implementamos talcomo quedan definidos en µDEVSML: DEVSCoupledComponent y DEVSIntegratorCou-pledComponent. El primero se corresponde con un modelo acoplado DEVS generico, mien-tras que el segundo es un caso particular de un acoplado para el elemento que realiza laintegracion mediante QSS (ver mas detalle en 8.3.1.1 DEVSIntegratorCoupledComponent)

60 7. Definicion del lenguaje µDEVSML para intercambio de modelos DEVS

1 <coupledRef model="DEVSCoupledComponent" name="DEVS_COUPLED_PredatorModel"

parent="">

2 <inputs >

3 <input name="predatorEfficiency" type="in" />

4 <input name="predatorDeathRate" type="in" />

5 <input name="Prey" type="in" />

6 </inputs >

7 <outputs >

8 <output name="PlusPredator" type="out" />

9 <output name="MinusPredator" type="out" />

10 <output name="Predator" type="out" />

11 </outputs >

12 <components >

13 <atomicRef model="DEVSConstant" name="predatorEfficiency">

14 ...

15 </atomicRef >

16 <atomicRef model="DEVSConstant" name="predatorDeathRate" parent="

PredatorModel">

17 </atomicRef >

18 <coupledRef model="DEVSIntegratorCoupledComponent" name="

DEVS_INTEGRATOR_COUPLED_Predator" parent="">

19 ...

20 </coupledRef >

21 </components >

22 <internal_connections >

23 <connection component_from="predatorEfficiency" component_to="

DEVS_INTEGRATOR_COUPLED_Predator" port_from="predatorEfficiency

" port_to="predatorEfficiency" type="in" />

24 <connection component_from="predatorDeathRate" component_to="

DEVS_INTEGRATOR_COUPLED_Predator" port_from="predatorDeathRate"

port_to="predatorDeathRate" type="in" />

25 </internal_connections >

26 <external_input_connections >

27 <connection component_to="predatorEfficiency" port_from="

predatorEfficiency" port_to="predatorEfficiency" />

28 <connection component_to="predatorDeathRate" port_from="

predatorDeathRate" port_to="predatorDeathRate" />

29 <connection component_to="DEVS_INTEGRATOR_COUPLED_Predator"

port_from="Prey" port_to="Prey" />

30 </external_input_connections >

31 <external_output_connections >

32 <connection component_from="DEVS_INTEGRATOR_COUPLED_Predator"

port_from="Predator" port_to="Predator" />

33 <connection component_from="DEVS_INTEGRATOR_COUPLED_Predator"

port_from="PlusPredator" port_to="PlusPredator" />

34 <connection component_from="DEVS_INTEGRATOR_COUPLED_Predator"

port_from="MinusPredator" port_to="MinusPredator" />

35 </external_output_connections >

36 </coupledRef >

Fig. 7.10: µDEVSML ejemplo de DEVSCoupledComponent (Acoplado Generico)

7.3. Componentes Acoplados 61

1 <coupledRef model="DEVSIntegratorCoupledComponent" name="

DEVS_INTEGRATOR_COUPLED_Predator" parent="">

2 <inputs >

3 <input name="predatorEfficiency" type="in" />

4 <input name="Prey" type="in" />

5 <input name="predatorDeathRate" type="in" />

6 </inputs >

7 <outputs >

8 <output name="Predator" type="out" />

9 <output name="PlusPredator" type="out" />

10 <output name="MinusPredator" type="out" />

11 </outputs >

12 <components >

13 <atomicRef model="DEVSIntegrator" name="Predator" parent="

DEVS_INTEGRATOR_COUPLED_Predator">

14 ...

15 </atomicRef >

16 <atomicRef model="DEVSFtot" name="TotPredator" parent="

DEVS_INTEGRATOR_COUPLED_Predator">

17 ...

18 </atomicRef >

19 <atomicRef model="DEVSFplus" name="PlusPredator_Predator" parent="

DEVS_INTEGRATOR_COUPLED_Predator">

20 ...

21 </atomicRef >

22 <atomicRef model="DEVSFminus" name="MinusPredator_Predator" parent=

"DEVS_INTEGRATOR_COUPLED_Predator">

23 ...

24 </atomicRef >

25 </components >

26 <internal_connections >

27 <connection component_from="Predator" component_to="

PlusPredator_Predator" port_from="Predator" port_to="Predator"

type="in" />

28 ...

29 </internal_connections >

30 <external_input_connections >

31 <connection component_to="PlusPredator_Predator" port_from="

predatorEfficiency" port_to="predatorEfficiency" />

32 ...

33 </external_input_connections >

34 <external_output_connections >

35 <connection component_from="Predator" port_from="Predator" port_to=

"Predator" />

36 ...

37 </external_output_connections >

38 </coupledRef >

Fig. 7.11: µDEVSML ejemplo de DEVSIntegratorCoupledComponent (Acoplado de un Integrador)

62 7. Definicion del lenguaje µDEVSML para intercambio de modelos DEVS

8. TRADUCTOR: DE XMILE A µDEVSML

8.1. Introduccion

El proceso de traduccion de un archivo XMILE a µDEVSML consta de varios pasosque detallaremos a continuacion. Se asume que ya se tiene un modelo en formato XMILE.En nuestro caso, utilizamos Stella para la desarrollo de los modelos en SD y su posteriorexportacion a formato XMILE.

Los pasos de traduccion a alto nivel pueden listarse como:

Paso 1 : lectura del archivo XMILE, representacion de las distintas partes de nuestrointeres como modelos, elementos stock y flow y variables, con clases de objetos es-pecıficos en Python (Algoritmo 8.1)

Paso 2 : transformacion de los distintos objetos, que representan los componentes de unmodelo expresado en XMILE obtenidos en el paso anterior, a objetos que representancomponentes de µDEVSML

Paso 3 : serializacion a un archivo de los objetos que representan componentes de µDEVSML

8.2. Paso 1: Lectura de archivo XMILE

Dado que el archivo XMILE es simplemente un archivo XML que cumple con unaespecificacion de estructura, el programa lo lee como XML. Pudiendo ası transformar laestructura que encierran distintos tags (los cuales describen el modelo SD) en objetosdel lenguaje Python, facilitando el trabajo posterior de traduccion y serializacion. Para elalgoritmo, los tags relevantes para obtener el modelo SD son: model, module, stock, flow,aux.

El algoritmo correspondiente a este paso puede verse en 8.1. Se devuelve una lista detodos los modelos del archivo XMILE de acuerdo a la especificacion de XMILE, (OASISXML Interchange Language (XMILE) for System Dynamics TC, 1.1.1 Definitions). Elmodelo raız es el unico que no tiene nombre.

8.3. Paso 2: Transformacion a DEVS

Este paso constituye el corazon del traductor.

Se transforman los objetos que representan las partes del modelo SD tomados delarchivo XMILE en modelos atomicos y acoplados DEVS, de forma tal que el resultado dedicha transformacion sea un modelo DEVS equivalente al modelo SD original.

El algoritmo principal genera el modelo DEVS acoplado, que llamaremos root, al quese le van agregando las distintas partes que lo componen, es decir modelos atomicos yacoplados, puertos de entrada y salida, y conexiones entre componentes a traves de suspuertos de entrada y salida.

En los pasos donde se agregan los componentes atomicos y acoplados al modelo root

es donde ocurre la transformacion de los modelos SD a DEVS.

63

64 8. Traductor: De XMILE a µDEVSML

Algorithm 8.1 Lectura archivo XMILE para obtener modelos XMILE

1: function get xmile models(xmile filename)2: xmile file ← read xml(xmile filename)3: xmile models ⇐ new xmile model[]4: while model xml in xmile file do5: xmile model ← new xmile model6: for variable xml in model do7: if variable xml is a module xml then8: xmile module ← new xmile module(variable xml)9: xmile model.modules.add(xmile module)

10: end if11: if variable xml is a stock xml then12: xmile stock ← new xmile stock(variable xml)13: xmile model.stocks.add(xmile stock)14: end if15: if variable xml is a flow xml then16: xmile flow ← new xmile flow(variable xml)17: xmile model.flows.add(xmile stock)18: end if19: if variable xml is a aux xml then20: xmile aux← new xmile aux(variable xml)21: xmile model.auxs.add(xmile aux)22: end if23: end for24: xmile models.add(xmile model)25: end while26: return xmile models27: end function

8.3. Paso 2: Transformacion a DEVS 65

Algorithm 8.2 Transformacion modelo SD (XMILE) a modelo acoplado DEVS

1: function SD model 2 devs model(xmile models, sim specs del archivo xmile)2: root model ← Get Root Model(xmile models)3: top model←xmile model 2 devs coupled component(

xmile root model, models, sim specs, null)4: return top model5: end function6: function xmile model 2 devs coupled component(root model, xmile models,

sim specs, parent model)7: devs model ← new devs coupled component8: add atomics components(

top model, root model, xmile models, sim specs, parent model)9: add coupled components(

top model, root model, xmile models, sim specs, parent model)10: add output ports(

top model, root model, xmile models, sim specs, parent model)11: add external input connections(

top model, root model, xmile models, sim specs, parent model)12: add external output connections(

top model, root model, xmile models, sim specs, parent model)13: add internal connections(

top model, root model, xmile models, sim specs, parent model)14: return devs model15: end function

8.3.1. Traduccion a componentes acoplados DEVS

En este paso es donde se recorre recursivamente el modelo SD raız y los modelos que locomponen. Obviamente, en esta recursion se procesa de forma diferente a cada componentesegun sea un componente atomico o acoplado.

En 8.3 puede verse que los modelos acoplados dentro del modelo raız pueden ser:

Componentes acoplados derivados de modulos que son submodulos del modelo SD

Componentes acoplados basicos como los vistos en 6.1.1 6.3 y 6.4, formados a partirde los elementos stock del modelo raız

Componentes acoplados de tipo array formados a partir de los elementos aux delmodelo raız que tienen ecuaciones que utilizan arrays

8.3.1.1. DEVSIntegratorCoupledComponent

Este componente acoplado se obtiene de la transformacion de un stock y los elementosflow que tienen incidencia sobre el (sean de entrada o salida) en distintos componentesatomicos interrelacionados.

Como se explica en 6, el stock se convierte en un integrador QSS conectado a unatomico DEVSFtot que se ocupa de calcular la derivada (incrementa o decrementa suvalor de acuerdo a los valores que llegan de los distintos elementos flow, cada uno por unpuerto de entrada especıfico).

66 8. Traductor: De XMILE a µDEVSML

Algorithm 8.3 Traduccion de submodelos SD (XMILE) a componentes acoplados DEVS

1: function add coupled components(devs model, xmile model, xmile models,sim specs, parent model)

2: coupled ← Get Coupled Components(xmile model, xmile models, sim specs,parent model)

3: devs model.coupled components.add(coupled)4: end function5: function Get Coupled Components(xmile model, xmile models, sim specs)6: ccs ← new devs coupled component[]7: for model in xmile models do8: if model in xmile models.modules then9: coupled←xmile model 2 devs coupled component(

model, xmile models, sim specs, xmile model)10: ccs.add(coupled)11: end if12: end for13: for stock in xmile model.stocks do14: if stock.access is not input then flows ← xmile model.flows15: coupled←get devs integrator coupled component(

stock, flows, xmile models, sim specs)16: ccs.add(coupled)17: end if18: end for19: for aux in xmile model.auxiliaries do20: if aux has array behavior then21: devs array ← new devs array(aux, xmile model.name)22: ccs.add(devs array)23: end if24: end for25: return ccs26: end function

8.3. Paso 2: Transformacion a DEVS 67

Cada uno de estos elementos flow se traduce a un modelo atomico DEVSFpm, que seocupa de hacer el calculo de la ecuacion definida en el flow. El valor determinado por estaecuacion se calcula a partir de los valores de las variables de entrada, que llegan cada unapor un puerto especıfico.

En caso que la ecuacion tuviera un termino que utilice alguna funcion especial, comopor ejemplo PULSE , se genera un atomico especıfico que se comporta de forma acorde, ygenera un output que le es enviado al modelo DEVSFpm, en donde este input es tratadocomo si fuera una variable mas de entrada para la ecuacion.

El algoritmo descrito en 8.4 muestra como se obtiene un acoplado del tipo DEVSInte-gratorCoupledComponent a partir de un stock y sus elementos flow. Las conexiones entrecomponentes, sea con componentes externos o internos, se realiza haciendo corresponderlos nombres de los puertos. El modelo se construye de tal forma que los nombres coincidan.

Algorithm 8.4 Traduccion de stock y elementos flow de SD en DEVSIntegratorCoupled-Component

1: function get devs integrator coupled component(stock, flows)2: coupled ← new devs integrator coupled component(stock)3: integrator ← new devs integrator(stock, coupled)4: ftot ← new devs ftot(stock, coupled)5: ac ← [integrator, ftot]6: fpms ← new devs fpm[]7: for flow in flows do8: fpms.add(new dev fpm(stock, flows, coupled))9: end for

10: ac.add(fpms)11: special atomics ← get special atomics(fpms)12: ac.add(special atomics)13: coupled.atomic components.add(ac)14: input ports ← get input ports from(fpms, special atomics)15: coupled.input ports.add(input ports)16: ouput ports ← get output port from(fpms, stock)17: coupled.output ports.add(output ports)18: external input conns ← get external in conns(ac, coupled)19: coupled.external input connections.add(external input conns)20: integrators ← filter(a in ac where a.type == ’DEVSIntegrator’)21: external output conns ← get external out conns(integrators, fpms, coupled)22: coupled.external output connections.add(external output conns)23: internal conns← get internal conns(ac)24: coupled.internal connections.add(internal conns)25: return coupled26: end function

8.3.1.2. DEVSArray

El comportamiento de las variables de tipo arreglo (array) de SD y sus funcionesasociadas, se capturan a traves de los componentes DEVSArray, DEVSArrayAgregator yDEVSArrayCollector.

68 8. Traductor: De XMILE a µDEVSML

DEVSArray es un componente acoplado que engloba a los elementos de la matriz, loscuales se representan mediante un componente atomico de tipo DEVSAux. Cada elementode la matriz puede tener una ecuacion asociada y DEVSArrayCollector toma todos losvalores dichos elementos (que son DEVSAux), y los compone en una unica variable desalida del DEVSArray.

State variables: sigma =∞, phase = passive,A(matrix)Parameters: Ai,j,k... ∈ matrixX : AY : (sigma, phase,matrix)S :

function δext(s, e, x)/* x input port is i */Ai,j,k... = x

end function

function δint(s)if phase == busy then

phase = passivesigma =∞

end ifif phase == passive then

/* Never happens */end if

end function

function λ(s)send A to function name A port

end function

Fig. 8.1: Definicion DEVSArrayCollector

El comportamiento de la componente DEVSArrayAgregator es de agregacion de valoresde una matriz n-dimensional. Por ejemplo, podrıa calcular las funciones SUM, MEAN, MAX,

MIN u ocuparse de la seleccion de sub-regiones de la matriz.

8.3.2. Traduccion de elementos aux a atomicos DEVS

Los componentes atomicos resultados de add atomics components en 8.2 se obtienen apartir de los elementos aux del modelo SD representados mediante el tag aux. A partir deestos se pueden obtener los modelos atomicos de constantes, auxiliares, funciones graficasy otras funciones especiales, como PULSE.

8.3.2.1. DEVSAux

Atomico DEVS que devuelve el valor de una funcion f : <n → < por su puertode salida. Cada parametro de la funcion posee su propio puerto de entrada, cada vez quealguno de ellos cambia, ingresa un valor por el puerto correspondiente, se evalua la funcionpara los valores actuales de todos sus parametros. El valor resultante de la evaluacion dela funcion se envıa por el puerto de salida.

8.3. Paso 2: Transformacion a DEVS 69

Algorithm 8.5 Traduccion de Auxiliries de un modelo SD (XMILE) a atomicos DEVS

1: function add atomics components(devs model, xmile model, xmile models,sim specs)

2: atomics ← Get Atomic Components(xmile model, xmile models, sim specs)3: devs model.atomics components.add(atomics)4: end function5: function Get Atomic Components(xmile model, xmile models, sim specs)6: atomics ← new devs atomic component[]7: for aux in xmile model.auxiliaries do8: if aux got graphical function behavior then9: gf ← new devs graphical function(aux, xmile model)

10: atomics.add(gf)11: else if aux equation is a special function then12: da ← new devs aux(aux, xmile model)13: atomics.add(da)14: else if aux in xmile model.dependencies then15: da ← new devs aux(aux, xmile model)16: atomics.add(da)17: else if aux is not an array then18: cte ← new devs aux(aux, xmile model)19: atomics.add(cte)20: end if21: end for22: for atomic in atomics do23: if atomic equation is a special function then24: special function atomic←Get Special Function Atomic(atomic.equation)25: atomics.add(special function atomic)26: end if27: end for28: return atomics29: end function

70 8. Traductor: De XMILE a µDEVSML

Para facilitar la implementacion del traductor, el puerto de salida de este atomico sellama igual a la funcion que representan. De este manera es facil unir puertos de entraday salida, de los componentes (los componentes que esperan la entrada de uno de estosatomicos tienen un puerto de entrada que coincide con el nombre de este).

State variables: Statevariables : sigma =∞; phase = passive; variable1 . . . variablen;Parameters: Parameters : f : <n → <X : variable1 . . . variablenY : function nameS : (sigma, phase, variable1, . . . , variablen)

function δext(s, e, x)/* x input port is i */variablei = x

end function

function δint(s)if phase == busy then

phase = passivesigma =∞

end ifif phase == passive then

/* Never happens */end if

end function

function λ(s)send f(variable1, . . . , variablen) to function name output port

end function

Fig. 8.2: Definicion DEVSAux en DEVS

8.3.2.2. DEVSConstant

Atomico DEVS que devuelve de forma unıvoca un unico valor y ∈ < por su puertode salida. Adicionalmente (y esto es algo opcional, que se hizo para ampliar el abanicode posibilidades del simulador), el componente cuenta con un puerto de entrada con elnombre de la constante que permite cambiar el valor del mismo (por ejemplo medianteeventos disparados en instantes de tiempo predeterminados por el simulador).

Para facilitar la implementacion del traductor, el puerto de salida de este atomico sellama igual a la funcion que representa. De este manera es facil unir puertos de entraday salida, de los componentes (los componentes que esperan la entrada de uno de estosatomicos tiene un puerto de entrada que coincide en nombre).

8.3.2.3. DEVSGraphical

Las funciones graficas (graphical functions) se denominan alternativamente funcionesde busqueda y funciones de tabla. Se utilizan para describir una relacion arbitraria entreuna variable de entrada y una variable de salida. El dominio de estas funciones se denominaconsecuentemente x y el rango se denomina consecuentemente y (OASIS XML InterchangeLanguage (XMILE) for System Dynamics TC, 3.1.4 Graphical Functions).

8.4. Paso 3: Serializacion a archivo 71

State variables: sigma =∞; phase = passive; value;Parameters: ∅X : valueY : outputS : (sigma, phase, value)

function δext(s, e, x)value = x

end function

function δint(s)if phase == busy then

phase = passivesigma =∞

end ifif phase == passive then

Never happensend if

end function

function λ(s)send value to port output

end function

Fig. 8.3: Definicion DEVSConstant en DEVS

Esta funcionalidad se suele utilizar en los modelos SD cuando la definicion de lasfunciones se desconocen o son muy complejas y se disponen de algunos valores de lamisma. En Stella es posible incluso dibujarlas a mano con una herramienta grafica paradefinirlas.

Como en el caso de DEVSAux, el valor de la variable de entrada se puede determinarpor medio de una funcion que puede tener un numero arbitrario de parametros (f : <n →<).

8.3.2.4. DEVSPulse

De acuerdo a la especificacion XMILE, la funcion PULSE(magnitud, tiempo inicial[,

intervalo]) genera un pulso de 1 DT de ancho, con altura igual a magnitud/DT en elinstante tiempo inicial y opcionalmente con periodicidad igual a su intervalo (ver OA-SIS XML Interchange Language (XMILE) for System Dynamics TC, 3.5.4 Test InputFunctions).

El comportamiento de esta funcion puede replicarse mediante el siguiente modeloatomico DEVS, que llamaremos DEVSPulse.

8.4. Paso 3: Serializacion a archivo

Como ultimo paso, hay que serializar la estructura de objetos Python en un archivoformato XML, especıficamente a una representacion µDEVSML del componente (para masdetalles ver 7).

En la representacion de µDEVSML se asume a los distintos tipos de componentes tal

72 8. Traductor: De XMILE a µDEVSML

State variables: sigma =∞; phase=passive; variable1 . . . variablen;Parameters: f : <n → <; x range (< xmin, xmax >); y pointsX : xY : yS : (sigma, phase, value)

function δext(s, e, x)j = x.portvariablej = x.value

end function

function δint(s)if phase == busy then

phase = passivesigma =∞

end ifif phase == passive then

/* Never happens */end if

end function

function λ(s)value = f(variable1, . . . , variablen)interval = (xmax − xmin)/(#(y points)− 1)index = (value− xmin)/intervalif index >= 0 and index < #(y points) then

send y pointsindex to port xelse

ERROR!end if

end function

Fig. 8.4: Definicion DEVSGraphical en DEVS

como se describen en las secciones anteriores. Es decir, esta representacion no describe elcomportamiento interno del componente, sino aquella informacion que es necesaria parala instanciacion del componente dentro del modelo (sus parametros).

Para facilitar la implementacion de la serializacion y dado que la estructura de losdistintos componentes es fija, utilizamos la biblioteca de plantillas jinga2. Lo cual nospermitio generar facilmente la estructura de archivo µDEVSML.

8.5. De µDEVSML a CD++

Una vez que se tiene una representacion en µDEVSML del modelo, el paso siguientees ejecutar una simulacion del mismo para confirmar que la traduccion fue bien realizada.

Nuestro criterio es que nuestra traduccion XMILE → µDEVSML es correcta si lasimulacion del modelo con nuestra herramienta (CD++) presente resultados similares alos obtenidos con la herramienta comercial (Stella).

8.5. De µDEVSML a CD++ 73

State variables: sigma =∞; phase=passive; magnitude, initial time, interval timeParameters: DTX : in magnitude, in first pulse, in intervalY : outS : (sigma, phase,magnitude, initial time, interval)

function δext(s, e, x)if x.port == in magnitude then

magnitude = x.value/DTend ifif x.port == in first pulse then

initial time = x.valueend ifif x.port == in interval then

interval time = x.value−DTend ifif magnitude, interval and initial time are set then

time to first pulse = initial time− clockHoldIn INTERVAL time to first pulse

end ifend function

function δint(s)if phase == PULSE then

phase = INTERV ALsigma = interval time

else if phase == INTERV AL thenphase = PULSEsigma = DT

else if phase == passive then/* Never happens */

end ifend function

function λ(s)if phase == PULSE then

send magnitude to port outelse if phase == INTERV AL then

send 0 to port outelse

/* Nothing */end if

end function

Fig. 8.5: Definicion DEVSPulse en DEVS

74 8. Traductor: De XMILE a µDEVSML

9. CASOS DE ESTUDIO

9.1. Modelo Teacup

El modelo SD mas simple que se puede desarrollarse esta constituido por un unicostock y un unico flow.

El ejemplo mas conocido en la literatura es el modelo conocido como Modelo Teacup, elcual modela la interaccion de una taza de te caliente con su entorno (el aire, a temperaturaambiente), dinamica de interaccion que genera el enfriamiento de la taza de te.

En la Ecuacion 9.1 se muestra el sistema de ecuaciones que rige la dinamica de estemodelo, tal como la reporta Stella, y en la Fig. 9.1 se muestra su representacion graficaen Stella.

CharacteristicT ime = 0,8RoomTemperature = 27TemperatureV alue0 = 180

HeatLossToRoom =TemperatureV alue−RoomTemperature

CharacteristicT ime

TemperatureV alue(t) = TemperatureV alue(t− dt) + (−HeatLossToRoom) · dt(9.1)

Fig. 9.1: Representacion grafica del Modelo Teacup

La temperatura inicial del unico stock del sistema es de 180 ºC, el valor inicial deTemperatureValue, y la temperatura del ambiente es de 27 ºC, que se registra medianteen el aux RoomTemperature, y permanece constante a lo largo de toda la simulacion. Latemperatura del stock decrece con el paso del tiempo a un ritmo determinado por el flowHeatLossToRoom, cuyo valor esta determinado por el stock TemperatureValue y los auxCharacteristicTime, tiempo caracterıstico para el enfriamiento del te, y RoomTemperatu-re. Los aux del sistema se utilizan para describir en este caso sus constantes.

En la figura 9.2 se muestra en un mismo sistema de coordenadas la evolucion de lavariable TemperatureValue en el tiempo para el modelo simulado en Stella y en CD++.Se ve que la evolucion del stock TemperatureValue es identica en ambos casos. Podemosestar tranquilos que al menos para estos modelos extremadamente simples, el traductor

75

76 9. Casos de Estudio

Fig. 9.2: Evolucion en el tiempo del valor del stock TemperatureValue en el Modelo Teacup

cumple con el requisito basico de que la simulacion del modelo DEVS generado por latraduccion sea igual a la del modelo SD original.

En el Apendice del capıtulo 12 se estudia una extension a este modelo. El nuevo modeloes utilizado como excusa para mostrar algunas de las ventajas que aporta la posibilidad detener un traductor que genere un modelo DEVS equivalente a un modelo SD preexistente.

9.2. Modelo SIR

Otro de los modelos ampliamente conocidos en el mundo SD es el modelo de contagioModelo SIR. En la Fig. 9.3 se muestra una representacion grafica generada en Stella deun Modelo SIR (Susceptibles-Infected-Recovered).

Fig. 9.3: Modelo grafico del Modelo SIR generado en Stella

En la Fig. 9.3 pueden verse tres parametros (constantes) en el modelo, representadosmediante los aux: el total de la poblacion, TotalPopulation, la tasa de infeccion, Infec-tionRate, y la duracion de la infeccion, Duration. Los stock del sistema son: la cantidadde poblacion aun sana, Susceptibles(t), la cantidad de poblacion infectada, Infected(t),y la cantidad de poblacion recuperada Recovered(t). Hay dos flow: la tasa de contagio,Succumbing(t), y la tasa de recuperacion, Recovering. Segun este modelo, una vez que

9.2. Modelo SIR 77

alguien se recupera, ya no puede contagiarse otra vez.

En la figura 9.4 se observa la evolucion de las tres variables mas importantes del mo-delo (Susceptibles(t), Infected(t) y Recovered(t)), tanto para el modelo en SystemDynamics simulado en Stella y como para el modelo DEVS obtenido de la traduccion si-mulado en CD++ en el en el intervalo de tiempo

[0,14

]. Observandose igual comportamiento

y valores similares en ambos modelos.

Fig. 9.4: Evolucion de stocks del Modelo SIR para el modelo simulado en Stella y en CD++.

En la figura 9.5 hacemos un corte del intervalo de tiempo[1,3]

de la simulacion paramostrar la diferencia entre la forma de aproximar las curvas de cada una de los stockutilizando la herramienta Stella (discretiza el tiempo) y CD++ (discretiza el valor de lasvariables). En particular, se puede comparar las lıneas naranja (out port infected, CD++)y violeta (Infected, Stella). Y ver como para una misma variacion en el valor de dichavariable, en un caso se hacen dos saltos y en otro solamente uno.

Fig. 9.5: Evolucion de stocks del Modelo SIR en el intervalo de tiempo[1,3]

para el modelosimulado en Stella y en CD++.

78 9. Casos de Estudio

9.3. Modelo de Supply-Demand

A continuacion, en la figura 9.6 se observa un modelo dinamico clasico de la variacionde la oferta y demanda de un bien, y el efecto de esta relacion en el precio del mismo.

En la figura 9.6a, se muestra el modelo clasico.

En la figura 9.6b, se muestra el modelo clasico, con la adicion de el efecto de funcionavanzada de Stella. En particular, hacemos que la variable Price se vea afectada porun PULSE, que genera shocks de aumento de dicha variable.

(a) Supply-Demand (b) Supply-Demand + Pulse

Fig. 9.6: Modelo Supply-Demand

En la figura 9.7 se observa le evolucion en el tiempo de las tres variables del modeloclasico (sin la adicion de shocks). Se aprecia como la oferta y demanda convergen haciaunico valor, mientras que el precio va disminuyendo hasta, tambien, estabilizarse.

Fig. 9.7: Supply-demand

En la figura 9.8, se muestra la evolucion de las variables para el modelo clasico con laadicion de shocks de incremento en la variable Price. Como se puede ver, el comporta-miento del sistema cambia drasticamente.

9.4. Modelo Lotka-Volterra 79

Fig. 9.8: Supply-demand disturbed

A partir de este experimento, podemos concluir que la implementacion de la funcionavanzada PULSE es correcta: las tres variables se mueven exactamente de la misma forma,tanto en la simulacion de Stella como en la de CD++.

9.4. Modelo Lotka-Volterra

Por supuesto que no podıamos dejar de mostrar los resultados obtenidos para la simu-lacion en CD++ de la traducccion del modelo Lotka-Volterra modularizado, que usamosen los capıtulos previos a modo de ejemplo para explicar el funcionamiento del traductor.

En la Fig. 9.9 puede verse que las variables de estado (Predator y Prey) tienen el mismocomportamiento. Tambien si se mira con detalle, se va a observar un leve desfasaje sobreel final de la simulacion. Esto se debe a que el modelo LV es un modelo perteneciente ala categorıa de ODEs marginalmente estable. Se puede demostrar que cuando DT y DQconvergen a cero, ambas curvas convergeran al mismo valor.

Fig. 9.9: Modelo Lotka-Volterra: se muestra la evolucion en el tiempo de las variables mas impor-tante del clasico modelo presa-depredador. Se ve que la evolucion de las variables es cıclica,y que ambos simuladores dan como resultado exactamente el mismo comportamiento.

80 9. Casos de Estudio

9.5. Modelo STEP (problemas con SD)

Para entender mejor uno de los beneficios relevantes que ofrece DEVS en comparaciona SD, disenamos un nuevo modelo al que llamamos Modelo STEP. El objetivo es mostrarcomo DEVS maneja de manera eficiente y correcta la combinacion de dinamicas continuasy discretas. En Fig. 9.10 se puede ver el modelo grafico en Stella.

Fig. 9.10: Teacup + Step Function

Para el experimento, configuramos utilizamos los siguientes valores para los parame-tros: DQ = 0,01, DREL = 0,01 y DT = 0,01. De esta forma, se va a hacer evidente uncaso de no deteccion de los eventos STEP en Stella. En la Fig. 9.11 se muestra el instantede tiempo en que los generadores STEP accionan sobre el sistema.

Fig. 9.11: Funciones STEP. Stella no es capaz de detectar los instantes de tiempo exactos en quesuceden los eventos STEP1 y STEP2 (t = 1,276 y t = 1,286 minutos, marcados conlıneas verticales azul y roja punteadas respectivamente)

Por completitud, mostramos en la Ecuacion 9.2 el sistema de ecuaciones generado por

9.5. Modelo STEP (problemas con SD) 81

este sistema, tal como lo reporta Stella:

initialT ime = 1,276initialT ime2 = 1,286height = 5height2 = 10STEP1 = STEP (initialT ime, height)STEP2 = STEP (initialT ime2, height2)unStock0 = 1unStock(t) = unStock(t− dt) + unInflow ∗ dtunInflow = unStock + STEP1 + STEP2

(9.2)

En este ejemplo se hace evidente una debilidad importante de la simulacion de sistemasen SD: cuando se combina con la aparicion de eventos discretos no se puede saber a priorique valor configurarle a DT de modo tal de evitar errores.

Para distintos parametros de un mismo modelo podrıa ser necesario configurar valoresmuy distintos a DT para que la simulacion sea lo suficientemente precisa en los momentosde aparicion de los eventos. Ademas, no existe ningun calculo que provea un valor paraDT (solo se pueden usar heurısticas, que pueden ser en algunos contextos muy molesto orestrictivo de utilizar).

Fig. 9.12: Modelo STEP : se hace zoom en el intervalo t = [1,25, 1,29]. Puede observarse comoambas trayectorias evolucionan a la par hasta que en t=1.276 y t=1.286 la lınea azul(correspondiente a la simulacion de CD++) detecta los eventos STEP de manera exacta,mientras que esto no sucede en el caso de la lınea naranja (simulacion de Stella)

En la Fig. 9.12 se puede apreciar el desfasaje que se genera en las curvas de la variableunStock para el modelo simulado con CD++ (lınea azul) en comparacion con el simuladoen Stella (lınea naranja). Este desfasaje puede acumular error en el tiempo de manera nocontrolada, haciendo que la simulacion SD termine dando resultados inaceptablementeincorrectos.

82 9. Casos de Estudio

10. APLICACION A UN SISTEMA HIBRIDO

Como ultimo objetivo de este trabajo nos proponemos poner a prueba la utilidad delsistema de traduccion para un caso mas complejo que solamente traducir de SD a DEVS.Partiendo de dos modelos preexistentes sobre dinamicas socioeconoomicas, intentaremosobtener un nuevo sistema que vincule sus dinamicas utilizando interconexion de puertosde entrada/salida y definicion de nuevas dinamicas.

Uno de los modelos de partida describe la macroeconomıa de un paıs. El otro es unmodelo de opinion, que representa dinamicas de influencia mutua y cambio de preferenciaentre votantes de una sociedad.

El modelo de macroeconomıa tiene una formulacion basada en ecuaciones diferencialesy esta implementado originalmente en una herramienta para modelado macroeconomicollamada Minsky (Keen and Standish, 2011), la cual presenta una cercanıa conceptual conSystem Dynamics, pero no es una herramienta para SD ni es compatible con el estandarXMILE.

En cuanto al modelo de intercambio de opinion, tiene una formulacion basada enagentes y esta expresado mediante un automata celular usando el formalismo Cell-DEVS(ver Subseccion 5.1.3). Este modelo tiene la capacidad de expresar “shocks exogenos” queimpactan la dinamica endogena de intercambio de opinion (basada en la vecindad entreagentes).

Ambos modelos seran presentados en mayor detalle en las secciones subsiguientes. Laidea guıa y motivadora es poder estudiar la influencia de variables de macroeconomıa sobrelas preferencias de personas entre un partido gobernante y su frente opositor (la opinionfavorable hacia uno u otro, o la indecision). La estrategia sera traducir eventos relevantesque se manifiesten a nivel de macroeconomıa en impactos exogenos sobre la dinamica deintercambio de opinion.

Para el desarrollo del nuevo modelo hıbrido nos planteamos la siguiente hipotesis detrabajo.

Asumiendo que:

Es posible obtener una descripcion formal del modelo macroeconomico en forma deODEs.

Es posible utilizar la herramienta Stella para generar un modelo SD equivalente alexistente en la herramienta Minsky.

Es posible utilizar nuestro nuevo traductor para producir un modelo DEVS equiva-lente.

Al obtener un modelo DEVS es natural hacer la interconexion del modelo macro-economico con un modelo basado en Cell-DEVS (como es el caso de modelo deintercambio de opinion).

Entonces, nuestra hipotesis es que:

Es posible obtener un modelo hıbrido combinando SD con automatas celulares, enel cual la dinamica de un submodelo puede influir sobre la dinamica del otro.

83

84 10. Aplicacion a un sistema hıbrido

El esfuerzo de obtener dicha combinacion se concentra mayoritariamente en el disenoconceptual y modelado de las nuevas interacciones, ocultando toda problematicasubyacente referida a sincronizacion entre un modelo continuo a parametros con-centrados (como SD) y un modelo de agentes a eventos discretos y espacialmenteexplıcito (como Cell-DEVS).

Con estas ideas en mente propondremos un caso de prueba para nuestro nuevo modelohıbrido y analizaremos los resultados del mismo.

10.1. Modelo de intercambio de opinion

Este modelo fue tomado del trabajo Dima and Sosa (2016), el cual fue desarrolladocomo trabajo practico para el curso Simulacion de Eventos Discretos, Departamento deComputacion, Facultad de Ciencias Exactas y Naturales, UBA.

Su objetivo es el estudio del resultado final (asintotico) de una eleccion entre dospartidos, sometida a un libre intercambio de opiniones, y se inspira originalmente en eltrabajo ”The undecided have the key: interaction-driven opinion dynamics in a three statemodel”, ver Balenzuela et al. (2015).

Cada votante V que participa de la eleccion tiene una preferencia y cierto grado deconviccion C representada como un numero real en el intervalo

[-3,3

], la cual clasifica-

remos de la siguiente manera:[-3,-2.8

): Votante Influyente Negativo V −I[

-2.8,−1): Votante Pasivo Negativo V −P[

-1,1]: Votante Indeciso Vind(

1,2.8]: Votante Pasivo Positivo V +

P(2.8,3

]: Votante Influyente Positivo V +

I

Definimos que existe un partido oficialista y uno opositor y por lo tanto la conno-tacion de Negativo y Positivo se refiere a si un votante se opone o apoya al partidogobernante, respectivamente. El grado de conviccion C le da la caracterıstica de Pasivoo Influyente.

Los votantes se distribuyen espacialmente en una grilla regular de tamano N x N eintercambian opinion con sus vecinos pertenecientes a una vecindad de Von Neumann, lacual puede verse en Fig. 10.1b.

La dinamica del intercambio de opinion se da de a pares de votantes vecinos, a los quedenominamos genericamente votante A (vA) y votante B (vB). Cada cierto intervalo detiempo todo votante (vA) elije aleatoriamente a uno de sus vecinos al cual le ”observa“su estado en dicho instante de tiempo. A este vecino observado lo llamamos vB.

En funcion de la conviccion de vA (que llamaremos CA) y de la conviccion de vB (quellamaremos CB), y con un mismo delay definido a priori por el simulador para todos losvotantes, vA modificara su preferencia y conviccion en ti ·δ. El valor de δ que se configuraal inicio de la simulacion (y que en nuestros ejemplos tiene valor δ = 0,1). El valor de ti sedetermina dependiendo de si la interaccion es normal (ti = 1) o fuerte (ti = q), donde q seconfigura al inicio de la simulacion (y que en nuestros ejemplos tiene valor q = 2) acordea las siguientes reglas, ejemplificadas en la Fig. 10.1a:

10.1. Modelo de intercambio de opinion 85

(a) Posibles dinamicas de intercambio de opinionde cada agente al observar a su vecino.

(b) Vecindad de agentes en un modelo Cell-Devsmulticapa: en cada paso el agente observa lacelda ubicada encima suyo, y de acuerdo alvalor que esta tenga (dicho valor se actualizaen cada paso de la simulacion), el agente eli-je a que vecino observar. En este caso, debeobservar a su vecino numero 3.

Fig. 10.1: Modelo de intercambio de opinion

Si vA y vB son influyentes y de partidos opuestos, entonces CA aumenta δ.

Si vA es pasivo y vB es influyente y de partidos opuestos, entonces CA disminuyeq · δ.

Si vA y vB son pasivos y de partidos opuestos (esto implica que ninguno es indeciso),entonces hay chances equiprobables de que CA aumente o disminuya en δ.

Si vA es influyente o pasivo, y vB es indeciso, entonces CA disminuye en δ su valorabsoluto (se acerca a 0)

Si vA es indeciso y vB es influyente, entonces CA se acerca al partido de vB en q · δ

Si vA es indeciso y vB es pasivo, entonces CA se acerca al partido de vB en δ

Si vA y vB son indecisos, entonces CA se vuelve mas indeciso (se acerca mas a 0)

Si ambos son votantes del mismo partido, CA aumenta en δ solo si CA > CB y vAes pasivo, caso contrario CA no cambia.

En la implementacion Cell-DEVS de este modelo cada celda representa a un unicovotante y tiene un estado cuyo valor representa su grado de conviccion por uno u otropartido.

En las Fig. 10.2 y Fig. 10.3 se muestran, a modo ilustrativo, algunos resultados pro-ducidos por este modelo y algunos tipos de analisis ue pueden ser realizados.

En los experimentos se utiliza una grilla de 10×10, inicializada con la misma cantidadde votantes por cada partido, y se vario la proporcion inicial de influyentes de cada partido(Influyentesini) y de indecisos (P 0

ini). El valor de conviccion de los indecisos fue elegidode manera equiprobable en el intervalo [−1; 1], la de los los influyentes en valor absolutodentro del intervalo [2,8; 3] y la de los pasivos, tambien en valor absoluto, dentro del

86 10. Aplicacion a un sistema hıbrido

Fig. 10.2: Resultados Modelo de opinion: Promedio de individuos en cada estado

Fig. 10.3: Resultados Modelo de opinion: Promedio de victorias

intervalo (1; 2,8) . Los votantes pasivos se distribuyen equitativamente en su rango entrepositivos y negativos.

En la Fig. 10.2 se observa como disminuye la cantidad de votantes indecisos por accionde los votantes influyentes. En la Fig. 10.3 se puede ver que se alcanza el unipartidismo(un 70 % o mas de los votantes pertenecen a un mismo partido) en la zona que comprendeprincipalmente los escenarios en donde el porcentaje de indecisos va de 20 % al 40 %,mientras que los influyentes no superan al 50 %.

Esta region es particularmente sensible a las condiciones iniciales, por lo que la lıneadivisoria entre la victoria de un partido y el bipartidismo (donde ambos partidos tienencada uno 40 % o mas de votantes) es muy tenue.

Se debe remarcar que estos escenarios llegan asintoticamente a la estabilidad, es decir,eventualmente no se observan mas cambios significativos en el estado global. Una vezllegado a dicho estado final es que se realiza la observacion de para realizar las graficasde arriba. Sin embargo, en el modelo hıbrido que propondremos mas adelatne, esto no

10.1. Modelo de intercambio de opinion 87

(a) Modelo de opinion: los agentes son ubicados espacialmente en una grilla, en donde cada unointeractua con sus vecinos. Se utiliza un coloreo que va de rojo a azul para representar laopinion de cada agente (un valor numerico en el intervalo [−3, 3]).

(b) Escala de colores para representar la conviccion de opinion de cada agente.

Fig. 10.4: Visualizacion de grilla de agentes en Modelo de opinion.

sera posible dado que la introduccion de eventos exogenos no permitira que el escenarioconverja a un estado estable. En cambio, realizaremos un analisis de evolucion temporaldel sistema.

10.1.1. Shocks exogenos sobre la grilla de agentes

Implementamos en Cell-DEVS el modelo de opinion explicado en la seccion anteriorcon una topologıa tipo grilla regular como la que se muestra en la Fig. 10.4.

Para introducir la idea de shocks exogenos y estudiar su impacto mediante simulacion,conectamos cada celda de la grilla a un nuevo componente (Fig. 10.5), un modelo DEVSal que denominamos ”Shocker”.

Modelamos a Shocker para enviar diversos shocks de opinion a los agentes en la grilla.Estos shocks no son mas que senales enviadas cada cierto intervalo de tiempo con un men-saje indicando al agente receptor (el votante) de que tipo de shock se trata. Comenzamoscon un caso muy simple: solamente hay tres tipos de shock (positivo, indefinido o nega-tivo), que son enviados por un unico Shocker (es decir, en la Fig. 10.5 podrıamos estarrefiriendonos al Shocker ad hoc 1 ). Para cada uno de los tipos de shocks se envıa comomensaje valores aleatorios equiprobables en el intervalo [−3,−1) (negativo), en [−1, 1] (in-definido) o en (1, 3] (positivo). Todas las senales (shocks de diferentes tipos) son enviadasal unısono, como un vector de eventos que ocurren un mismo instante de tiempo.

Cada agente de la grilla debe tener modelado el comportamiento para reaccionar antecada posible nuevo shock tipo positivo, indefinido o negativo. En este primer experimentode juguete el modelo de opinion se programa para que un agente cambie su estado almismo valor numerico que le llega en el mensaje recibido.

En la Fig. 10.6 se muestra como el estado final del proceso de intercambio de opiniondel Modelo de opinion original (esquina superior izquierda, sin shocks) se ve afectado porel agregado de un Shocker (en cada caso variando la proporcion de la cantidad de shocks

88 10. Aplicacion a un sistema hıbrido

Fig. 10.5: Conexion de posibles Modelos Shocker con el Modelo de opinion. Podrıan implementarsemodelos de Shockers como los ad hoc 1 y 2 de este ejemplo, cada uno con diferentescriterios para su activacion. Estos podrıan actuar o no en simulataneo sobre el modelode opinion del nivel inferior.

de cada tipo positivo, indefinido, negativo que se disparan cada vez).

Con estas observaciones concluimos la descripcion de la inclusion de shocks en el modelode opinion y pasamos a estudiar el modelo macroeconomico, para luego concentrarnos enel modelo hıbrido.

10.1.2. Promedio de victorias por partidismo al finalizar la simulacion

10.2. Modelo Goodwin-Keen

Steve Keen es un economista australiano, profesor de economıa y director de la Schoolof Economics, History and Politics en Kingston University, Londres.

Su trabajo academico se ha concentrado en formular una crıtica a la interpretacionneoclasica de la macroeconomıa por carecer de fundamento empırico. Keen se especializaen inestabilidad financiera. En 1995 publico ”Finance and Economic Breakdown“. En 2008escribio ”en diciembre de 2005, casi dos anos antes de que golpeara la crisis, me di cuentaque se acercaba una seria crisis financiera. Estaba preocupado de la probable severidady de la falta de conocimiento sobre ella entre los actores polıticos, por lo que tome elriesgo (para un academico) de volverme muy publico sobre mis puntos de vista. Empece acomentar sobre polıtica economica en los medios, comence el DebtWatch Report, registreuna pagina web con el oportuno nombre de www.debtdeflation.com, y establecı el blogSteve Keen’s Oz Debtwatch.“ (Bezemer, 2009).

Segun Keen, la incapacidad de los economistas neoclasicos para reconocer los proble-mas que ha ocasionado la crisis financiera iniciada en 2007 y que desemboco en la Gran

10.2. Modelo Goodwin-Keen 89

Fig. 10.6: Cada box-plot muestra la cantidad de agentes con opinion positiva (+), indeciso (I) onegativa (-) tras dejar evolucionar el intercambio de opinion en la grilla cierto tiempo(definido arbitrariemente en este ejemplo de juguete), y con shocks esporadicos en 20repeticiones de un mismo experimento. En Shocker: Ninguno se muestra que sin la pre-sencia de ningun shock, en las 20 repeticiones del mismo experimento (con el mismoestado inicial de la grilla) hubo 6 casos en los que aproximadamente 50 agentes termi-naron indecisos, y en el resto de los casos no quedo ningun indeciso. En particular, en laprimera de las 20 repeticiones (el punto de mas a la izquierda en el grafico de la esquinasuperior izquierda), se detectaron 25 agentes con opinion positiva, 0 indecisos y 75 conopinion negativa. Shocker: 1+,3- debe ser interpretado de forma similar, pero en este ca-so con la presencia de un shocker que en proporcion envıa un shock de opinion positivacada tres shocks de opinion negativa, y no envıa ninguno indefinido. En este caso, y aligual que en Shocker: 5+, se ve claramente como la predominancia de un tipo de shockpor sobre otro afecta el estado de la grilla al final de la simulacion.

Depresion confirmarıa que los postulados de la economıa neoclasica son falsos.

Para dar sustento a sus argumentos decidio modelar de forma clara y reusable susmodelos economicos no ortodoxos y para ello desarrollo el software Minsky. Segun Keen,representar estos modelos mediante herramientas clasicas de System Dynamics es muycomplicado visualmente mientras que Minsky permite realizar estas representaciones deforma mas entendible (ver Fig. 10.7).

Su modelo mas conocido, en el cual segun Keen se baso para poder predecir la crisisfinanciera del 2008, es una extension al clasico Modelo Goodwin, que es un modelocıclico de crecimiento de la economıa (Keen, 2011).

Keen explica en profundidad la teorıa y como modelar y simular este modelo en Minskyen videos publicados en la web, como por ejemplo el titulado Modeling Financial Instabilityusing Minsky 1. Allı detalla como su modelo esta basado en ideas de Marx (1867), quienplanteaba el siguiente circuito macroeconomico:

Suba de salarios → Baja de inversion → Baja de crecimiento → Suba dedesempleo → Baja en demanda de aumento de salarios → Suba de ratio de

1 https://www.youtube.com/watch?v=zpbMd9QW7VM

90 10. Aplicacion a un sistema hıbrido

Fig. 10.7: Modelo Goodwin-Keen modelado y ejecutado en el software Minsky.

ganancias→ Suba de la inversion→ Suba de crecimiento→ Baja del desempleo→ Suba de salarios → . . .

A partir de esta concepcion, se puede hacer una analogıa con el Modelo Lotka-Volterra,en donde (curiosamente) los capitalistas serıan la presa y los trabajadores los depreda-dores: el aumento de depredadores depende negativamente en el numero de depredadoresy positivamente en las interacciones de este con la presa.

En la Fig. 10.8 se muestra una representacion del modelo en Minsky. Se puede apreciarclaramente el caracter realimentado a partir de las flechas causales que unen las diferentesvariables del modelo, que constituyen un sistema de ODEs.

En 10.1 pueden verse los parametros y valores iniciales 10.2 las ecuaciones del modelo.

piS = 10piZ = 0,04employmentRateZero = 0,6employmentRateStable = 10deltaKReal = 0,05rateInterestOnLoans = 0,04velocityOfMoney = 3Beta = 0,015Alpha = 0,025Capital(0) = 300Population(0) = 150Debt(0) = 0wageRate(0) = 0,8LaborProductivity(0) = 1

(10.1)

10.2. Modelo Goodwin-Keen 91

Fig. 10.8: Modelo Goodwin-Keen. Cada rectangulo rojo encierra a una variable. Los triangulospueden ser operadores (suma, resta, division, multiplicacion) o en algunos casos inte-gradores (por ejemplo el triangulo ubicado mas cerca de la esquina superior izquierda,en cuyos casos el operador deber estar unido unıvocamente a una variable). Se observapor ejemplo que la variable Output esta determinada por la division entre la variableCapital (lo que serıa un stock en SD) y la variable velocityOfMoney (lo que serıa unaux en SD).

92 10. Aplicacion a un sistema hıbrido

Interest = rateInterestOnLoans ·Debt

Output =Capital

velocityOfMoney

Labor =Output

LaborProductivityWages = wageRate · Labor

employmentRateValue =Labor

PopulationwageFunction = employmentRateStable · (employmentRateV alue− employmentRateZero)ProfitGrossReal = Output−Wages

omega =Wages

OutputProfitNet = ProfitGrossReal − Interest

piR =ProfitNet

CapitalInvestmentFunctionReal = (piR− piZ) · piSInvestmentGross = InvestmentFunctionReal ·OutputInvestmentNetReal = InvestmentGross− (Capital · deltaKReal)Capital′ = InvestmentNetRealDebt′ = InvestmentGrossLaborProductivity′ = Alpha · LaborProductivityPopulation′ = Population ·BetawageRate′ = wageFunction ·wageRate

(10.2)

10.3. Replicacion de resultados Modelo Goodwin-Keen

Sometimos el modelo Goodwin-Keen a un proceso de trasformaciones que involucra eluso del traductor desarrollado en esta tesis. El flujo de pasos fue el siguiente:

1. Modelo en Minsky a modelo en MATLAB

2. Modelo en MATLAB a modelo en XMILE

3. Modelo en XMILE a modelo en µDEVSML

4. Modelo en µDEVSML a modelo en CD++

Verificamos en cada paso que el modelo resultante fuera equivalente al original. En laFig. 10.9 mostramos a modo de ejemplo la evolucion de las variables Capital y Debt enel paso intermedio de SD (Stella) y en el modelo final en DEVS (CD++).

10.4. Modelo hıbrido

Ya estamos en condiciones de implementar un modelo multinivel como se muestra enla Fig. 10.10 que combina ambos modelos: se generan shocks de acuerdo a la evolucion delModelo Goodwin-Keen y la relacion entre sus variables accionando sobre el Modelode Opinion y modificando su dinamica.

10.4. Modelo hıbrido 93

Fig. 10.9: Evolucion de variables Debt y Capital en Stella y CD++

Como puede verse en la Fig. 10.10, en la capa superior se ubica el Modelo Goodwin-Keen, con su dinamica de evolucion interna. Sus variables de output son Employmen-tRate(t) y Wages(t). Estas son recibidas por el modelo intermedio Modelo de Shocks.

El Modelo de Shocks define los criterios de shocks en funcion de los valores que recibedel Modelo Goodwin-Keen. El Modelo Opinion puede recibir los shocks en cualquierinstante de tiempo t (tiempo continuo).

Para este nuevo modelo hıbrido definimos que el intervalo entre interacciones de apares de votantes es de 1 mes. En el Modelo Goodwin-Keen la unidad de tiempo es enanos. La simulacion del modelo utilizando los parametros que Keen propone en su artıculotiene una duracion total de 50 anos (hasta que el sistema se vuelve inestable, momento desupuesto colapso economico).

Esta claro que Modelo Opinion fue pensado originalmente para una situacion deballotage en un intervalo de tiempo corto, mientras que el Modelo Goodwin-Keenintenta modelar un comportamiento macro de la economıa a lo largo de perıodos muchomas amplios (en el orden de algunas decadas).

Creemos que el modelo combinado resultante podrıa aceptar interpretaciones realis-tas bajo ciertas suposiciones. Por ejemplo, considerando que los intercambios de opinionentre agentes en una sociedad se manifiestan mas fuertemente en forma mensual, bajo lahipotesis de que el debate se intensifica a partir de la publicacion mensual de estadısticase ındices (por ejemplo inflacion o tasa de desempleo).

10.4.1. Criterios de shocks

En 10.11a y 10.11b se muestra la evolucion de las variables EmploymentRate(t) yWages(t), simulado con Stella y luego con CD++ (es decir, luego de la traduccion).

El Shocker implementado maneja dos umbrales, uno para el valor del Employmen-tRate, al que denominaremos thresholdE y otro para el de WagesRate, al que denomi-naremos thresholdW . Utilizamos la palabra threshold para nombrar a las variables de losumbrales por consistencia con la denominacion en ingles de las variables del modelo deKeen.

Cuando EmploymentRate o WagesRate atraviesen sus umbrales el Shocker en-viara un shock de opinion que tendra las siguientes propiedades de acuerdo al valor de las

94 10. Aplicacion a un sistema hıbrido

Fig. 10.10: Modelo DEVS multinivel:

variables frente a sus umbrales:

EmploymentRate > umbralE y WagesRate > umbralW : a un 10 % de las celdasse les envıa un shock positivo, y a otro 5 % se les envıa otro shock positivo

EmploymentRate > umbralE y WagesRate < umbralW : a un 10 % de las celdasse les envıa un shock positivo, y a otro 15 % se les envıa un shock negativo

EmploymentRate < umbralE y WagesRate > umbralW : a un 10 % de las celdasse les envıa un shock negativo, y a otro 5 % se les envıa otro shock positivo

EmploymentRate< umbralE y WagesRate < umbralW : a un 5 % de las celdasse les envıa un shock negativo, y a otro 15 % se les envıa otro shock negativo

Los valores de los porcentajes son arbitrarios y se eligieron a tıtulo ilustrativo.La eleccion de las celdas a ser afectadas por el Shocker se realiza de manera aleatoria

uniforme al momento de enviar cada shock, y una misma celda no puede ser afectada almismo tiempo por dos tipos diferentes de shock.

10.4. Modelo hıbrido 95

(a) Evolucion del empleo a lo largo de 50 anos segun el modelo Goodwin-Keen.La lınea roja marca el umbral utilizado en el ejemplo de proximas secciones.

(b) Evolucion de los salarios a lo largo de 50 anos segun el modelo Goodwin-Keen. La lınea roja marca el umbral utilizado en el ejemplo de proximassecciones.

Fig. 10.11: Evolucion de dos de las variables crıticas del modelo Goodwin-Keen: empleo y salariosen funcion del tiempo para el modelo simulado en CD++ (azul) y en Stella (naranja).

Para definir el comportamiento de cada votante ante la recepcion de un shock utili-zamos la variable δ del Modelo Opinion, y agregamos una nueva variable qshock, que

96 10. Aplicacion a un sistema hıbrido

define en cuantos deltas modificara el shock la opinion del votante:

Shock positivo: opinion del votante se ve modificada en +qshock · δ

Shock negativo: opinion del votante se ve modificada en −qshock · δ

10.4.2. Experimentacion

En todos los escenarios el estado inicial de la grilla contiene:

10 % de votantes influyentes negativos V −I

10 % de votantes influyentes positivos V +I

5 % de votantes pasivos negativos V −P

5 % de votantes pasivos positivos V +P

70 % de votantes indefinidos Vind

Como se muestra en los ejemplos de la Fig. 10.12, la distribucion de los votantes sobrela grilla cambia de escenario a escenario, manteniendo constante la cantidad de votantespertenecientes a cada grupo, pero distribuyendolos espacialmente de diferente manera cadavez.

En la Fig. 10.12 los valores de la conviccion se varıa de escenario a escenario: en 10.12bhay un agente con opinion -3, pero no ası en 10.12a.

Por otra parte, en cada escenario se utilizan los siguientes umbrales para las variablesemploymentRate y WageRate:

umbralE = 0,6

umbralW = 0,9

Para la realizacion de estos graficos, se subdividio el intervalo de 60 anos en 100ventanas de igual longitud. Tanto para el modelo con shocks como sin shocks, para cadaagente, en cada una de dichas ventanas, se identifico cual era la opinion del agente alcomenzar ese intervalo de tiempo. Hecho esto, para cada intervalo se calcula el promediode la conviccion de todos los agentes de la grilla, y se grafico acorde se muestran las figuras10.13a y 10.13b.

Para cada escenario, desde un punto de vista global (a partir del calculo del promediodel nivel de opinion en toda la grilla), en un caso es claramente afectado por los shocksexternos y en el otro no.

La comparacion entre cada curva de un mismo color en una y otra figura muestra queel Modelo Goodwin-Keen puede cambiar cualitativamente los resultados a largo plazo delmodelos de opinion.

Por ejemplo para el Escenario 1 se llevo a la poblacion de un estado global indiferentehacia una preferencia sostenida por el partido que era oficialista al momento de comenzar elexperimento (ya la tendencia se hace notable a partir de los 20 anos). De observar el efectosobre varios escenarios, una conclusion parcial posible es que la distribucion espacial delos influyentes tiene efectos determinantes, lo cual es consistente con resultados conocidosen teorıa de grafos (influencia de la ubicacion de hubs dentro de un grafo).

10.4. Modelo hıbrido 97

(a) Configuracion inicial del Escenario 1 (b) Configuracion inicial del Escenario 2

(c) Escala de colores utilizada en 10.12a y 10.12b.

Fig. 10.12: Visualizacion de la configuracion inicial. Ejemplo para dos de los escenarios utilizados enla experimentacion. En ambos casos hay la misma proporcion de cada tipo de votante,pero distribuidos espacialmente de diferente manera en la grilla y no necesariamentecon exactamente los mismos valores absolutos de conviccion.

10.4.3. Conclusiones sobre la experiencia de modelado hıbrido

Vale la pena recordar el objetivo eminentemente metodologico de haber construidoeste ejemplo de juguete.

Buscamos poner de manifiesto la potencia que puede brindar un metodo sistematico detransformacion de modelos para la creacion de modelos hıbridos que combinan dominiosheterogeneos. Todo esto sin cargar sobre las espaldas del modelador una reimplementacioncompleta de un dominio en el otro, como suele suceder frecuentemente, o el desarrollo deprocesos ad-hoc para la integracion de los dominios (continuo y discreto). Creemos queesta es una barrera importante que dificulta el avance de la investigacion interdisciplinaria,al menos de aquella basada en modelado y simulacion, y la somete a la introduccioninvoluntaria de errores evitables.

En este ejercicio validamos que el esfuerzo invertido para el nuevo modelo hıbrido fuecasi exclusivamente dedicado al diseno de la dinamica de influencia (umbrales, intensidadde shocks, etc.)

Es decir, una vez que se aplico el sistema automatico de traduccion, y al haber llevadoel modelo SD al terreno de DEVS, las cuestiones tecnicas subyacentes relativas a manejode tiempo y espacio (entre el modelo SD y el modelo Cell-DEVS) quedaron totalmenteocultas para el modelador.

Esta es una consecuencia esperable de la capacidad de representacion de multiforma-lismos propia de DEVS.

98 10. Aplicacion a un sistema hıbrido

(a) Resultados sin shocks.

(b) Resultados con shocks

Fig. 10.13: Comparacion de evolucion con vs. sin shocks. Cada color representa un escenario di-ferente. Todos los escenarios parten del mismo estado inicial de proporciones entrevotantes positivos, negativos e indefinidos.

11. CONCLUSIONES Y TRABAJO FUTURO

11.1. Conclusiones

Implementamos un traductor de modelos System Dynamics a DEVS basandonos enel formato de especificacion XMILE para la descripcion de modelos System Dynamics.Luego de efectuar la traduccion del modelo, lo hemos descripto en un nuevo formatopropio µDEVSML para realizar su especificacion como modelo DEVS.

Los ejercicios realizados con algunos modelos clasicos del mundo de la simulacion enSD como Teacup, SIR, Lokta-Volterra y Supply Demand mostraron que las traduccionesson correctas en cuanto a que se obtienen los resultados esperados. Esto es, se replican losresultados de manera indistinguible simulando en una herramienta como Stella para SD ycomo CD++ para DEVS.

Implementamos extensiones de algunos de estos modelos clasicos: Supply DemandExtendido y Lotka-Volterra Extendido para demostrar el potencial del traductor usandofuncionalidades avanzadas como la modularizacion de modelos en varias componentes.

En particular fue relevante confirmar un resultado esperable en terminos de sistemashıbridos: al ser SD un formalismo intrınsecamente basado en tiempo discreto, presentaproblemas para lidiar con eventos discretos que ocurren en instantes arbitrarios de tiempo.Pudimos comprobar que mientras una herramienta para SD falla en el tratamiento delevento discreto, el modelo traducido a DEVS maneja correctamente el evento gracias alas propiedades asıncronas de los integradores tipo QSS (basados en DEVS) frente a losintegradores clasicos de SD que utilizan un valor fijo de DT .

Tambien mostramos que es posible traducir modelos de simulacion basados en ecua-ciones diferenciales ordinarias implementados originalmente en otros programas de simu-lacion, como el Modelo Goodwin-Keen en Minsky.

Mostramos que el traductor permite la implementacion de modelos DEVS hıbridos,a partir de la composicion de modelos previamente desarrollados en SD y en DEVS. Enparticular mostramos que es posible integrar modelos celulares Cell-DEVS con modelosSystem Dynamics. De esta forma mostramos que de forma directa y a traves de un unicoformalismo es posible integrar modelos SD y DES mediante el formalismo DEVS, en lugarde tener que recurrir a la comunicacion, sincronizacion e intercambio de mensajes entredistintos programas de simulacion.

11.2. Discusion

El traductor desarrollado en este trabajo puede verse como una prueba de conceptode las posibilidades que ofrece la traduccion de modelos SD a DEVS, este ultimo comoformalismo de modelos DES, a fin de tener un unico modelo a simular y descripto bajo unformalismo unificador. Esta estrategia difiere enormemente de los metodos que se puedenencontrar en la literatura para lograr la integracion entre modelos SD y DES, que se basanen adaptaciones ingeniosas de alguna herramienta de simulacion particular pero que no sebasan en una teorıa solida.

Hemos demostrado que es posible modelizar utilizando solamente el formalismo DEVSmodelos que hasta hoy se modelaban casi exclusivamente mediante System Dynamics

99

100 11. Conclusiones y trabajo futuro

pero con la ventaja que es posible seguir utilizando herramientas System Dynamics queexporten los modelos a XMILE. Pudiendo incluso componer estos modelos traducidos conotros modelos, abriendo un enorme abanico de posibilidades en cuanto a la creacion yanalisis de modelos.

Como detallamos en el Capıtulo 14 no todas los funcionalidades posibles de un modeloespecificado en XMILE son soportadas. Tanto de los aspectos obligatorios, como opcionalesdel estandar. Estas limitaciones tienen dos aspectos: la traduccion de SD a µDEVSML,es decir que el comportamiento o funcion se traduzca correctamente a DEVS, y luego latraduccion de µDEVSML a un simulador especıfico, en nuestro caso CD++.

En cuanto a lo primero, cabe destacar que no hemos implementado la posibilidad detener modelos XMILE que se compongan de otros modelos XMILE, ası como la implemen-tacion de algunas funciones como por ejemplo RAMP. En ambos casos son funcionalidadesrequeridas para los simuladores que conforman con el estandar XMILE y deberan ser desa-rrolladas en esfuerzos futuros.

En la traduccion a µDEVSML no hemos implementado ciertas funcionalidades op-cionales como por ejemplo el uso de macros, que permiten al usuario incorporar nuevasfunciones matematicas y que pueden compartirse entre distintos modelos. Tampoco hemosintentado traducir los comportamientos especiales de los modos queue y conveyor de loselementos stock. Sin embargo, estas son dinamicas triviales de representar en el dominiode DEVS por lo cual no presentan un desafıo relevante y podran ser implementadas entrabajos futuros.

Finalmente, creemos que este trabajo representa un avance notable para el estado delarte del area, construyendo un puente que permanecıa pendiente de ser realizado durantemas de 4 decadas de evolucion exitosa, pero independiente, entre SD y DEVS.

11.3. Trabajo Futuro

Dadas las limitaciones que hemos mencionado mas arriba, podemos indicar que uncamino posible para trabajo futuro es implementar la funcionalidad completa requeridapor el estandar XMILE, como ser la inclusion de archivos y las funciones basicas completas.Ası como tambien todas las funcionalidades opcionales para describir comportamientos demodelos como por ejemplo queues (filas) y conveyors (cintas transportadoras), la inclusionde macros, y funciones asociadas a arrays de elementos stock, flow y aux.

Otra lınea de trabajo posible es la reproduccion de trabajos existentes de modelos hıbri-dos SD-DES utilizando el traductor para traducir el modelo SD a DEVS y posiblementeenriquecer dichos modelos.

Asimismo, queda abierta la posibilidad de implementar traducciones automaticas desdeµDEVSML a modelos ejecutables en otros simuladores DEVS distintos de CD++, comoser PowerDEVS, DEVSJAVA o PythonDEVS.

Parte III

APENDICES

12. MODELO TEACUP EXTENDIDO

A modo de experimentacion, decidimos extender el Modelo Teacup original mediantela incorporacion de un ventilador que actue como un medio adicional de enfriamiento dela taza de te. En la Fig. 12.1a se puede observar la presencia de un nuevo flujo de salida(que llamamos ventilationFan) para el stock TemperatureValue.

Como ya se explico en secciones anteriores, las flechas simples indican que tanto elflow ventilationFan como el HeatLossToRoom son elementos UNIFLOW (es decir, nopermiten la circulacion de energıa en la direccion del stock TemperatureValue). Ademas,la no presencia del sımbolo ’±’ en el stock TemperatureValue indica que este no puedetomar valores negativos.

En este modelo, la potencia del flow ventilationFan es constante en el tiempo, mientrasque la de HeatLossToRoom es variable (depende del valor de la temperatura de la taza dete). Entonces, la intuicion que se tiene al observar el modelo grafico de la Fig. 12.1a es quela temperatura del stock deberıa tender a cero, puesto que hay un un flujo con potenciamayor o igual a cero variable (HeatLossToRoom) y otro con potencia siempre mayor acero constante (ventilationFan) que le quitan energıa al stock TemperatureValue. En laFig. 12.1b se ve que eso es exactamente lo que sucede.

(a) Modelo Teacup extendidocon medio de enfriamien-to adicional

(b) Evolucion de temperatura de la taza de te en el tiempo

Fig. 12.1: Modelo Teacup extendido con ventilacion extra

Ahora bien, nuestra curiosidad nos llevo a preguntarnos si serıa posible replicar losresultados obtenidos para el Modelo Teacup extendido de la Fig. 12.1a, pero utilizando ununico outflow, y haciendo que su potencia sea igual a la suma de los outflow HeatLoss-ToRoom y ventilationFan. En la Fig. 12.2 se muestra el modelo grafico ( Fig. 12.2a) y elresultado de la simulacion (Fig. 12.2b). Sorprendentemente, el comportamiento del modelocambio!

103

104 12. Modelo Teacup extendido

(a) Modelo Teacup Extendidov2 con medio de enfria-miento adicional

(b) Evolucion de temperatura de la taza de te en el tiempo

Fig. 12.2: Modelo Teacup extendido con ventilacion extra

Para entender que es lo que estaba generando este fenomeno, recurrimos a la funcio-nalidad Equation Viewer de Stella, que muestra el sistema de ecuaciones generado por elmodelo grafico. Para nuestra sorpresa, Stella representa a ambos modelos con el mismosistema de ecuaciones tal como puede verse en en la Ecuacion 12.1.

CharacteristicT ime = 0,8

RoomTemperature = 27

TemperatureV alue0 = 180

TemperatureV alue(t) = TemperatureV alue(t− dt) + (−HeatLossToRoom− ventilationFan) ∗ dtHeatLossToRoom = (TemperatureV alue−RoomTemperature)/CharacteristicT ime

ventilationFan = 5(12.1)

Para nuestra sorpresa, terminamos encontrando que el sistema de ecuaciones matemati-co que presenta Stella no es suficiente para explicar formalmente como es la dinamicadel sistema sino que tambien es necesario considerar el modelo grafico que genera dichasecuaciones. En la Fig. 12.2 se muestra un modelo grafico alternativo al presentado en elModelo Teacup extendido de la Fig. 12.1a que responde al mismo sistema de ecuaciones.

Encontramos que el problema es que en un caso, el valor de la derivada Temperature-Value’ es siempre mayor o igual al valor de ventilationFan, mientras que en el otro caso,es siempre mayor o igual al valor de ventilationFan+HeatLossToRoom, que podrıa llegara ser cero o negativo (porque HeatLossToRoom se permite que asuma valores negativos).

En este ejemplo se hace evidente la fragilidad de la metafora bathtub: la ınfima in-corporacion al Modelo Teacup de un medio de enfriamiento adicional genera confusion:la simulacion del sistema original con agregado de un nuevo outflow (ventilationFan) dadiferentes resultados, dependiendo de si el modelo original estaba modelado con un flowde tipo UNIFLOW o BIFLOW. Ademas, se pueden generar dos modelos graficos diferen-tes (ie. con comportamiento diferente) pero cuya representacion matematica (mediante elsistema de ecuaciones reportado por el Equation Viewer) es identica.

105

(a) Modelo Teacup Extendidov3 con ventilacion extra

(b) Evolucion de temperatura en el tiempo

Fig. 12.3: Modelo Teacup extendido con ventilacion extra

De todas formas, el traductor es consistente, y replica los mismos resultados paracada uno de los modelos. A continuacion, mostramos los resultados de la simulacion paralas variantes del experimento consideradas:

Fig. 12.4: Evolucion del Modelo Teacup Extendido v1 : Stella vs. CD++

Fig. 12.5: Evolucion del Modelo Teacup Extendido v2 y v3 : Stella vs. CD++

106 12. Modelo Teacup extendido

13. LOTKA-VOLTERRA EXTENDIDO (MODULARIZADO)

En este capıtulo presentamos una posible extension al modelo basico de Lotka-Volterrade secciones anteriores. La idea es mostrar y explicar algunas de las capacidades avanzadasde Stella, y tambien como el traductor implementado logra interpretar y traducir dichasfuncionalidades al formalismo DEVS y posteriormente al programa de simulacion CD++.

En la Fig. 13.1 se muestra la definicion matematica de la extension propuesta:

volume = 1first = 5interval = 10PULSER = PULSE(volume,first, interval)PULSEScalator = 0,05 ∗ PULSERDEFORESTATIONChangeRate = PULSEScalatorDEFORESTATION′ = DEFORESTATIONChangeRatepreyVar = PredatorpredatorVar = PreyARRAYCalculations[1][1] = predatorVarARRAYCalculations[1][2] = preyVar/DEFORESTATIONARRAYCalculations[2][1] = predatorVar/DEFORESTATIONARRAYCalculations[2][2] = preyVarAggregator = ARRAYCalculations[1][2] + ARRAYCalculations[2][1]GraphicalStatistics[1][1] = funcion grafica 1(Aggregator)

GraphicalStatistics[1][2] = funcion grafica 2(Aggregator)

GraphicalStatistics[2][1] = funcion grafica 3(Aggregator)

GraphicalStatistics[2][2] = funcion grafica 4(Aggregator)

Fig. 13.1: Sistema de ecuaciones parametrizado correspondiente al modelo Lotka Volterra exten-dido. Se utilizan las funcionalidades avanzadas de Stella PULSE, ARRAY, y funcionesgraficas.

13.1. Modelo grafico SD

El nuevo sistema de ecuaciones se representa en Stella de forma grafica. En la figura13.2 se observa el agregado un nuevo stock y flow al modelo de Lotka-Volterra origi-nal. La combinacion de los elementos stock PreyModel.Prey y PredatorModel.Predatory DEFORESTATION afectan el componente auxiliar (aux) ARRAYCalculations per-mitiendo la complejizacion del modelo origina. En este caso se agrega al modelo un factorexterno, independiente de la interaccion de las presas y depredadores.

El efecto de deforestacion pretende representar un caso posible de fenomeno ambientalque produzca impacto sobre la relacion entre dos especies, en este caso presas y depreda-dores.

107

108 13. Lotka-Volterra Extendido (modularizado)

Fig. 13.2: Extension al modelo grafico original, utilizando funciones avanzadas. Aquı se introduceel nuevo stock DEFORESTATION, cuyo valor aumenta de acuerdo a un DEFORES-TATIONChangeRate, determinado por un PULSER, que se podrıa interpretar generashocks en la tala de arboles del bosque en el cual conviven la presa y depredador delmodelo original. Como input la parte extendida del modelo se utilizan las variablesPredatorModel.Predator y PreyModel.Prey del modelo original. El nuevo aux ARRAY-Calculations, utiliza la cantidad de presas, depredadores, y el nivel de deforestacion parasacar una serie de estadısticas, que son ubicadas ordenadamente en un array. Los valoresde estas estadısticas son utilizados por un interprete de estadısticas (Aggregator) quehace operaciones con los valores de dicho array, y genera nuevas estadısticas, que mandacomo input a otro generador de estadısticas: GraphicalStatistics.

En la 13.2 se permite utilizar el estado de ambas dinamicas para calcular estadısticas:el ARRAYCalculations calcula el ratio entre el nivel de deforestacion y la cantidad dedepredadores y presas que hay a tiempo t (ver Fig 13.3a). Tambien, para el calculo deestadısticas adicionales se pueden usar arrays con funciones graficas en donde se puededefinir a mano el valor de cada estadıstico en funcion del valor de la variable de inputAggregator (ver Fig. 13.3b).

En la Fig. 13.4a se muestra como el aux Aggregator accede a las estadısticas cal-culadas en ArrayCalculations y efectua operaciones con sus valores. En este caso, sumalas posiciones (1, 2)y (2, 1) del array para sintetizar una nueva estadıstica, que enviara alcomponente GraphicalStatistics.

Finalmente, destacamos la funcion especial PULSE. En la Fig. 13.4b se muestra laforma de definir dicha funcion en la herramienta Stella. Este aux se encarga de enviarlepulsos (o shocks) al inflow del stock DEFORESTATION.

13.2. Modelo grafico DEVS 109

(a) Definicion de funcion avanzada:array de funciones matematicas(ARRAYCalculations)

(b) Definicion de funcion avanzada: array de fun-ciones graficas (GraphicalStatistics)

Fig. 13.3: Ejemplos de funcionalidades avanzadas en Stella: ARRAY

(a) Definicion de funcion avanzada: Agregacionsobre array (Aggregator)

(b) Definicion de funcion avanzada PULSE(PULSER)

Fig. 13.4: Ejemplos de funcionalidades avanzadas en Stella: ecuaciones especiales

13.2. Modelo grafico DEVS

En la Fig. 13.5 se muestra la representacion grafica DEVS de la extension propuesta,presentada en la figura 13.2.

El modulo array ArrayCalculations y el modulo array GraphicalStatistics se traducen

110 13. Lotka-Volterra Extendido (modularizado)

como un componentes DEVS acoplados: toman como input el conjunto de variables nece-sarias para que sus celdas internas hagan los calculos deseados, y redirigen los valores dedichas variables a las componentes que las utilicen.

En 13.5 se muestran los modelos atomicos que quedan incluidos en el acoplado Array-Calculations (un atomico para cada celda del array). Los valores de cada posicion del arrayson enviados al atomico Aggregator mediante un unico mensaje que contiene una n-tuplacon todos los valores.

Por ultimo, destacamos como la funcion especial DEVSPulse queda incluida dentro delacoplado DEVS BASIC COUPLED Deforestation. Esto es una decision de diseno: hacemosque todos los flujos de un stock y componentes que los afectan, queden acumulados enun mismo modelo DEVS acoplado.

Fig. 13.5: Modelo Lotka-Volterra Extension (modularizado). Se omiten los nombres de los puer-tos de E/S de todas las componentes, para que el diagrama se entienda mas claramente.Tambien se omite el zoom-in en GraphicalStatistics, por ser muy similar al de la compo-nente ArrayCalculations.

13.3. Simulacion

En las figuras 13.6 y 13.7 mostramos la evolucion de algunas de las variables introdu-cidas en esta extension.

13.3. Simulacion 111

(a) Evolucion variables de Modelo Lotka-VolterraExtendido (Stella)

(b) Evolucion variables de Modelo Lotka-VolterraExtendido (Stella)

Fig. 13.6: Simulacion de modelo extendido

Tambien es interesante observar en la figure 13.7 la evolucion de cada una de las celdasdel array grafico.

Fig. 13.7: Modelo Lotka-Volterra Extension (modularizado)

13.3.1. Stella

En la figura 13.8, vemos como serıa la evolucion de cada uno de los estadısticos definidospara el caso en que no se acoplan los modelos.

Por otro lado, en la figura 13.9 se ve la enorme diferencia cuando las dos variables deinput de la extension (predatorVar y preyVar) evolucionan de acuerdo al modelo L-Vbasico.

112 13. Lotka-Volterra Extendido (modularizado)

(a) Extension al modeloLotka-Volterra: en estecaso, la extension no leeninguna de las variablesdel modelo L-V. Porel contrario, se definecomo constantes la can-tidad de presas (100) ydepredadores (5).

(b) Extension al modelo Lotka-Volterra: se muestra como evolucio-narıan las variables statistic11 y statistic22 de la extension si sedefinieran como constantes los valores de predatorVar y preyVar.

Fig. 13.8: Simulacion de modelo extendido

(a) Extension al modeloLotka-Volterra: se leenlas variables Predator yPrey de dicho modelo,y se las utiliza en cadainstante de tiempo t paracalcular el valor de nue-vas variables estadısticasadicionales.

(b) Extension al modelo Lotka-Volterra: se muestra como evolucio-narıan las variables statistic11 y statistic22 de la extension si sedefinieran los valores de predatorVar y preyVar en funcion de losvalores de dichas variables en el modelo L-V para cada instantede tiempo t.

Fig. 13.9: Simulacion de modelo extendido

13.3.2. Stella vs. CD++

En la Fig. 13.10 se muestra la evolucion de las variables estadısticas resultantes enStella y en CD++ para la extension implementada.

Queda claro que se establecio una fuerte relacion entre el modelo original y la extension.Cuando los modelos se conectan, se altera fuertemente la dinamica de evolucion de lasvariables.

Tambien, se ve que la traduccion tiene el mismo comportamiento que el modelo original,fortaleciendo ası la confianza que se le puede tener al traductor implementado.

13.3. Simulacion 113

Fig. 13.10: Lotka-Volterra extendido: se muestra la comparacion de evolucion de variables estadısti-cas 11 y 22. Las curvas en azul y naranja se corresponden al modelo simulado en CD++y las verde y roja al modelo simulado en Stella.

114 13. Lotka-Volterra Extendido (modularizado)

14. PARSER XMILEPY: ALCANCE

En esta seccion especificamos a que nivel el parser es capaz de interpretar cada una delas funcionalidades que provee Stella en el formato XMILE.

Para mas informacion, ir a la web de Stella 1.

14.1. Funcionalidades basicas

Nivel de soporte

Funcionalidad SI SI (PARCIAL) NO

Stock XFlow XAuxiliary XGraphical Function X

14.2. Funcionalidades avanzadas

14.2.1. Opcionales

Nivel de soporte

Funcionalidad SI SI (PARCIAL) NO

Conveyor XQueue XArray XSubmodelos XMacros XEvent Poster XModel View XOutputs XInputs XAnnotations X

1 https://www.iseesystems.com/resources/help/v1-5

115

116 14. Parser XMILEpy: Alcance

14.2.2. Builtins: Agregaciones sobre arrays

Nivel de soporte

Funcionalidad SI SI (PARCIAL) NO

SUM XMIN XMAX XMEAN XRANK XSIZE XSTDDEV X

14.2.3. Builtins: Operadores y Funciones matematicas

Nivel de soporte

Operador SI SI (PARCIAL) NO

+ X* X/ X- Xˆ XAND XOR XMAX XMIN XABS XARCTAN XARCCOS XARCSIN XCOS XSIN XEXP XINT XLN XLOG10 XSQRT X

14.2.4. Builtins: Funciones estadısticas

Nivel de soporte

Funcion SI SI (PARCIAL) NO

UNIFORM XEXPRND XLOGNORMAL XNORMAL XPOISSON XRANDOM X

14.2. Funcionalidades avanzadas 117

14.2.5. Builtins: Funciones de delay

Nivel de soporte

Funcion SI SI (PARCIAL) NO

DELAY XDELAY1 XDELAY3 XDELAYN XFORCST XSMTH1 XSMTH3 XSMTHN XTREND X

14.2.6. Builtins: Funciones de tiempo de simulacion

Nivel de soporte

Funcion SI SI (PARCIAL) NO

DT XSTARTTIME XSTOPTIME XTIME X

14.2.7. Funciones Test Input

Nivel de soporte

Funcion SI SI (PARCIAL) NO

PULSE XRAMP XSTEP X

14.2.8. Structured Statements

Nivel de soporte

Funcion SI SI (PARCIAL) NO

IF (...) THEN (...) ELSE (...) X

14.2.9. Otras limitaciones

Referencias El algoritmo no soporta la referencia a otros archivos XMILE (include). Lareferencia esta definida como requerida dentro del formato XMILE, ver OASIS XMLInterchange Language (XMILE) for System Dynamics TC, 2.11 Includes

118 14. Parser XMILEpy: Alcance

Submodulos El algoritmo soporta la existencia de submodulos dentro del archivo XMILE.El soporte a submodulos es una extension opcional del formato XMILE, ver OASISXML Interchange Language (XMILE) for System Dynamics TC, 3.7.4 Submodels

Bibliografıa

Balenzuela, P., Pinasco, J. P., and Semeshenko, V. (2015). The undecided have the key:interaction-driven opinion dynamics in a three state model. PloS one, 10(10):e0139572.

Bergero, F., Fernandez, J., Kofman, E., and Portapila, M. (2016). Time discre-tization versus state quantization in the simulation of a one-dimensional advec-tion–diffusion–reaction equation. SIMULATION, 92(1):47–61.

Bergero, F. and Kofman, E. (2011a). Powerdevs: a tool for hybrid system modeling andreal-time simulation. SIMULATION, 87(1-2):113–132.

Bergero, F. and Kofman, E. (2011b). Powerdevs: a tool for hybrid system modeling andreal-time simulation. Simulation, 87(1-2):113–132.

Bergero, F., Kofman, E., and Cellier, F. (2013). A novel parallelization technique for devssimulation of continuous and hybrid systems. SIMULATION, 89(6):663–683.

Bergero, F. M., Casella, F., Kofman, E., and Fernandez, J. (2018). On the efficiency ofquantization-based integration methods for building simulation. Building Simulation,11(2):405–418.

Bezemer, D. (2009). No one saw this coming. understanding financial crisis through ac-counting models. Workingpaper, University of Groningen, SOM research school.

Brailsford, S. C., Eldabi, T., Kunc, M., Mustafee, N., and Osorio, A. F. (2018). Hybrid si-mulation modelling in operational research: A state-of-the-art review. European Journalof Operational Research.

Castro, R., Kofman, E., and Cellier, F. E. (2011). Quantization-based integration methodsfor delay-differential equations. Simulation Modelling Practice and Theory, 19(1):314–336.

Cellier, F. and Kofman, E. (2006). Continuous System Simulation. Springer, New York.

Dima, G. and Sosa, E. (2016). Dinamica de intercambio de opinion.

Fernandez, J. and Kofman, E. (2014). A stand-alone quantized state system solver forcontinuous system simulation. SIMULATION, 90:782–799.

Ford, D. N. and Sterman, J. (1997). Dynamic modeling of product development processes.System Dynamics Review.

Forrester, J. (1961). Industrial Dynamics. Pegasus Communications, Waltham, MA.

Grinblat, G. L., Ahumada, H., and Kofman, E. (2012). Quantized state simulation ofspiking neural networks. SIMULATION, 88(3):299–313.

Helal, M., Rabelo, L., Sepulveda, J., and Jones, A. (2007). A methodology for integratingand synchronizing the system dynamics and discrete event simulation paradigms.

119

120 BIBLIOGRAFIA

Honggang, X., Mashayekhi, A. N., and Saeed, K. (1998). Effectiveness of infrastructureservice delivery through earmarking: the case of highway construction in china. SystemDynamics Review.

isee systems. Stella Professional.

Jakobsson, A., Serban, A., and Gong, S. (2015). Implementation of quantized-state systemmodels for a pll loop filter using verilog-ams. IEEE Transactions on Circuits and SystemsI: Regular Papers, 62(3):680–688.

Keen, S. (2011). A monetary minsky model of the great moderation and the great recession.Journal of Economic Behavior & Organization, 86:221 – 235.

Keen, S. and Standish, R. (2011). Minsky.

Kofman, E. (2002). A second order approximation for devs simulation of continuoussystems.

Kofman, E. (2004). Discrete event simulation of hybrid systems.

Kofman, E. (2006). A third order discrete event simulation method for continuous systemsimulation.

Kofman, E. and Junco, S. (2001). Quantized state systems. a devs approach for continuoussystem simulation.

Manuel Soto Frances, V., Escriva, E. J., and Ojer, J. (2014). Discrete event heat transfersimulation of a room. International Journal of Thermal Sciences, 75:105–115.

Manuel Soto Frances, V., Escriva, E. J., and Ojer, J. (2015). Discrete event heat transfersimulation of a room using a quantized state system of order two, qss2 integrator.International Journal of Thermal Sciences, 97:82–93.

Meadows, D. H., Randers, J., and Meadows, D. L. (2004). Limits to Growth: The 30-YearUpdate. Chelsea Green.

Merten, P. P., Loffler, R., and Wiedmann, K. (1987). Portfolio simulation: A tool tosupport strategic management. System Dynamics Review, 3:81 – 101.

Migoni, G., Kofman, E., Bergero, F., and Fernandez, J. (2015). Quantization-based simu-lation of switched mode power supplies. SIMULATION, 91(4):320–336.

Migoni, G., Rullo, P., Bergero, F., and Kofman, E. (2016). Efficient simulation of hybridrenewable energy systems. International Journal of Hydrogen Energy.

Mittal, S., Risco-Martın, J. L., and Zeigler, B. P. (2007). Devsml: automating devs execu-tion over soa towards transparent simulators. SpringSim ’07 Proceedings of the 2007spring simulation multiconference, 2:287 – 295.

Morgan, J. S., Howick, S., and Belton, V. (2017). A toolkit of designs for mixing discreteevent simulation and system dynamics. European Journal of Operational Research,257(3):907 – 918.

BIBLIOGRAFIA 121

OASIS XML Interchange Language (XMILE) for System Dynamics TC. XML InterchangeLanguage for System Dynamics (XMILE).

Powersim Software AS. Powersim Studio 10.

Pugh, A. (1963). DYNAMO user’s manual. M.I.T. Press.

Santi, L., Ponieman, N., Jun, S. Y., Genser, K., Elvira, D., and Castro, R. (2017). Applica-tion of state quantization-based methods in hep particle transport simulation. Journalof Physics: Conference Series, 898(4):042049.

Sarjoughian, H. S. and Zeigler, B. P. (2014). Devsjava : Basis for a devs-based collaborativem & s environment.

Simulistics Ltd. Simile.

Sterman, J. (2000). Business Dynamics: Systems Thinking and Modeling for a ComplexWorld. Pegasus Communications.

Van Tendeloo, Y. (2014). Activity-aware devs simulation. Master’s Thesis, University ofAntwerp, Antwerp, Belgium.

Van Tendeloo, Y. and Vangheluwe, H. (2017). An evaluation of devs simulation tools.Simulation, 93(2):103–121.

Ventana Systems, Inc. of Harvard, Massachusetts. Vensim.

Wainer, G. A. (2002). Cd++: a toolkit to define discrete-event models. Software, Practiceand Experience. Wiley, 32(3):1261–1306.

Wainer, G. A. (2009). Discrete-Event Modeling and Simulation: a Practitioner’s approach.CRC Press, Montreal, Quebec.

Wainer, G. A. and Mosterman, P. J. (2011). Discrete Event Modeling and Simulation:Theory and Applications. CRC Press, Montreal, Quebec, 1st edition.

Yergeau, F., Sperberg-McQueen, M., Bray, T., Paoli, J., and Maler, E. (2008). Ex-tensible markup language (XML) 1.0 (fifth edition). W3C recommendation, W3C.http://www.w3.org/TR/2008/REC-xml-20081126/.

Zeigler, B. P. (1984). Multifaceted modeling and discrete event simulation. AcademicPress.

Zeigler, B. P. (1990). Object oriented simulation with hierarchical, modular models. Aca-demic Press.

Zeigler, B. P., Moon, Y., Kim, D., and Ball, G. (1997). The devs environment for high-performance modeling and simulation. IEEE Computational Science and Engineering,4(3):61–71.

Zeigler, B. P., Muzi, A., and Kofman, E. (2018). Theory of Modeling and Simulation: Dis-crete Event & Iterative System Computational Foundations. Academic Press, London,UK, 3nd edition.

122 BIBLIOGRAFIA

Zeigler, B. P., Praehofer, H., and Kim, T. G. (1976). Theory of Modeling and Simulation:Integrating Discrete Event and Continuous Complex Dynamic Systems. Academic Press,London, UK, 2nd edition.

Zeigler, Bernard P.; Kim, T. P. H. (2000). Theory of modeling and simulation: Integratingdiscrete event and continuous complex dynamic systems. Academic Press.