“Estudio Comparativo del Paquete de Simulacion´ Orientado ...

UNIVERSIDAD DE LOS ANDESFACULTAD DE INGENIERIA

ESCUELA DE SISTEMASDEPARTAMENTO DE INVESTIGACION DE OPERACIONES

“Estudio Comparativo del Paquete de SimulacionOrientado a Eventos Discretos SimPy. Desarrollo de un

Manual de Usuario con Ejemplos Resueltos.”

P: E J BM

P U L A I S

T:P. SM

A 2007

“Nunca consideres el estudio

como una obligacion

sino como una oportunidad

para penetrar en el bello

y maravilloso mundo del saber”.

Albert Einstein

Dedicatoria

Dedico este gran paso y logro en mi vida a:

Dios y la divinidad por estar velando de mi en todo momento y darme lo mas grande

que todo ser humano posee ... “Vida”.

A mis padres Jose Briceno y Marıa Marquez, por ser fuente ejemplar de constancia,

dignidad y entusiasmo, brindandome ası su constante apoyo, carino y amor durante toda

mi carrera !Lo logramos¡.

A mis hermanos Karen, Richards y Katiuska, por creer y confiar en mi en todo

momento, brindarme su apoyo, y compartir el siginificado de tener una familia para vencer

todos los obstaculos. Espero que esta meta que he alcanzado los impulse para que logren

las de ustedes, de la misma manera. “El que persevera vence”.

A mi Tıa Carmen, que con su apoyo incondicional, me enseno que la verdadera lucha

de la vida es luchando con teson y tenacidad.

A mi novia Marbely, la mujer que llego a mi vida y desperto la alegria de mis suenos,

que con su constante apoyo, ayuda y carino brindado me impulso en los momentos que mas

lo necesite, es por ello que este gran logro alcanzado tambien es tuyo. !Te amo mi NENA¡

Agradecimientos

A la ilustre Universidad de los Andes por ser una fuente de conocimientos y refugio a

lo largo de mi carrera.

Al mi profesor tutor Sebastian Medina por su ayuda, apoyo, dedicacion, esfuerzo y

paciencia que lo caracteriza para el cumplimiento de esta meta.

A mis compadres Wolfgang y Elena por ser una fuente constante de apoyo y ayuda en

los momentos mas difıciles de esta etapa en la vida, como lo es ser Estudiante.

A la Sra. Alba por abrirme las puertas de su casa y brindarme resguardo a lo largo de

esta carrera.

A mis amigos Jesus y Juan Miguel por todas las alegrıas, tristezas y logros vividos y

que faltan por vivir.

Al Dr. Klauss Muller por toda la colaboracion brindada durante el desarrollo de esta

investigacion.

A todas aquellas personas que de una u otra manera contribuyeron con el objetivo de

esta investigacion.

!MUCHAS GRACIAS!

Resumen

En el siguiente trabajo de investigacion se presenta el desarrollo de un manual comen-

tado y ejemplificado del paquete de Simulacion Orientado a Eventos Discretos SimPy.

Se sugiere un enfoque para la implantacion de un modelo en SimPy junto con una

descripcion de los comandos y sentencias que hacen posible una rapida y eficaz simulacion.

Se presentan un conjunto de ejemplos, extraıdos de casos tıpicos en los diferentes

sistemas tales como sistemas de produccion, manufactura, transporte logıstica y otros. Se

evidencian las capacidades y ventajas que ofrece SimPy a la hora de modelar estos sistemas.

Ademas se desarrollan los ejemplos en otros paquetes como Arena y Glider para mos-

trar los resultados de cada uno de estos junto con los de SimPy.

Palabras Clave:

SimPy, Python, modelo, simulacion, simulacion por eventos discretos.

Indice General

1. Introduccion y Planteamiento del Problema. 1

1.1. Introduccion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2. Antecedentes de la investigacion. . . . . . . . . . . . . . . . . . . . . . . . 2

1.3. Planteamiento del Problema. . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4. Justificacion y alcance de la investigacion. . . . . . . . . . . . . . . . . . . 4

1.5. Objetivos de la Investigacion. . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.5.1. Objetivo General. . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.5.2. Objetivos Especıficos. . . . . . . . . . . . . . . . . . . . . . . . . 5

1.6. Metodos y Herramientas. . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.6.1. Simulacion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.6.2. Python. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.6.3. SimPy (Simulador en Pyhon). . . . . . . . . . . . . . . . . . . . . 7

1.6.4. Glider. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.6.5. Arena. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.7. Organizacion del Documento. . . . . . . . . . . . . . . . . . . . . . . . . 8

2. Marco Teorico. 10

2.1. Introduccion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2. Conceptos Basicos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2.1. Sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2.2. Modelos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

INDICE GENERAL

2.2.3. Tipos de modelos. . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3. Simulacion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3.1. Ventajas, desventajas y peligros de la Simulacion. . . . . . . . . . . 19

2.3.2. Simulacion de sistemas orientados a eventos discretos. . . . . . . . 26

2.3.3. Elementos de un Simulador de Eventos Discretos. . . . . . . . . . 26

2.3.4. Estrategias de Simulacion de Sistemas Orientados a Eventos Dis-

cretos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.3.5. Simulacion Orientada a Objetos. . . . . . . . . . . . . . . . . . . . 32

2.4. Softwares de Simulacion. . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3. Modelado y Simulacion en SimPy. 35

3.1. Introduccion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.2. SimPy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.2.1. Concepto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.2.2. Caracterısticas Generales. . . . . . . . . . . . . . . . . . . . . . . 36

3.3. Desarrollo de un programa de Simulacion en SimPy. . . . . . . . . . . . . 38

3.3.1. Estructura basica de un programa en SimPy. . . . . . . . . . . . . . 38

3.3.2. Enfoque para la implantacion de un Modelo en SimPy. . . . . . . . 42

3.3.3. Construyendo el primer modelo en SimPy. . . . . . . . . . . . . . 43

3.4. Proceso (Process). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3.4.1. Definicion de un Proceso. . . . . . . . . . . . . . . . . . . . . . . 56

3.4.2. Comienzo y parada de un Proceso. . . . . . . . . . . . . . . . . . . 57

3.4.3. Avance del tiempo durante la ejecucion de un Proceso. . . . . . . . 58

3.4.4. Ejemplo de la definicion de un Proceso. . . . . . . . . . . . . . . . 58

3.5. Manejo de Sincronizaciones en SimPy. . . . . . . . . . . . . . . . . . . . . 59

3.5.1. Definiendo un SimEvent. . . . . . . . . . . . . . . . . . . . . . . . 59

3.5.2. Esperando en cola por un SimEvent. . . . . . . . . . . . . . . . . 60

3.5.3. Esperando una senal para un SimEvent. . . . . . . . . . . . . . . . 61

3.5.4. Ejemplo de Sincronizacion. . . . . . . . . . . . . . . . . . . . . . 61

INDICE GENERAL

3.5.5. Sincronizacion “wait until”, en espera de una condicion. . . . . 63

3.6. Recurso.(Resources) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

3.6.1. Definicion de un Recurso. . . . . . . . . . . . . . . . . . . . . . . 64

3.6.2. Solicitando un recurso. . . . . . . . . . . . . . . . . . . . . . . . . 65

3.6.3. Ejemplo de un recurso. . . . . . . . . . . . . . . . . . . . . . . . . 66

3.7. Nivel (Level). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

3.7.1. Definiendo un Nivel. . . . . . . . . . . . . . . . . . . . . . . . . . 68

3.8. Almacenes (Store). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

3.8.1. Definiendo un Almacen. . . . . . . . . . . . . . . . . . . . . . . . 70

3.9. Registrando los resultados de la simulacion. . . . . . . . . . . . . . . . . . 71

3.9.1. Definiendo un objeto de tipo Tally y Monitor. . . . . . . . . . . . . 71

3.9.2. Observando los datos. . . . . . . . . . . . . . . . . . . . . . . . . 72

3.9.3. Sumario de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

3.10. Graficando los Resultados. . . . . . . . . . . . . . . . . . . . . . . . . . . 73

4. Ejemplos de muestra. 76

4.1. Modelos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

4.1.1. Modelo de una Panaderıa. . . . . . . . . . . . . . . . . . . . . . . 77

4.1.2. Modelo de Maquinas Inestable. . . . . . . . . . . . . . . . . . . . 88

4.1.3. Modelo de un Puerto de Traslado de Carbon. . . . . . . . . . . . . 94

4.1.4. Modelo de Gruas en un Puerto. . . . . . . . . . . . . . . . . . . . . 102

4.1.5. Modelo de un Recurso Limitado. . . . . . . . . . . . . . . . . . . . 110

5. Conclusiones y Recomendaciones. 114

5.1. Conclusiones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

5.2. Recomendaciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Bibliografıa 116

INDICE GENERAL

A. Instalacion del paquete SimPy en las plataformas Windows y GNU/Linux. 119

A.1. Requisitos del Sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

A.2. En Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

A.3. En GNU/Linux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Indice de Tablas

2.1. Aplicaciones de la Simulacion . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Indice de Figuras

2.1. Proceso de manufactura como sistema. . . . . . . . . . . . . . . . . . . . . . . 12

2.2. Correspondencia entre un sistema y modelo. . . . . . . . . . . . . . . . . . . . 14

2.3. Formas de estudiar un Sistema. . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.4. Etapas en un estudio de Simulacion. . . . . . . . . . . . . . . . . . . . . . . . 25

2.5. Flujo de control entre los elementos de un simulador orientado a eventos discretos. . 28

3.1. Grafico Generado por el modulo SimPlot. . . . . . . . . . . . . . . . . . . . . . 75

4.1. Grafico para el numero de Baguetts (SimPy). . . . . . . . . . . . . . . . . . . . 81

4.2. Diagrama del Modelo Panaderıa en Arena. . . . . . . . . . . . . . . . . . . . . 82

4.3. Grafico para el numero de Baguetts (Arena). . . . . . . . . . . . . . . . . . . . 83

4.4. Grafico para el numero de Baguetts (Glider). . . . . . . . . . . . . . . . . . . . 87

4.5. Diagrama del Modelo de Maquina Inestable en Arena. . . . . . . . . . . . . . . . 91

4.6. Diagrama del Modelo del Puerto de Carbon en Arena. . . . . . . . . . . . . . . . 98

4.7. Diagrama del Modelo de Gruas en Arena. . . . . . . . . . . . . . . . . . . . . . 106

4.8. Diagrama del Modelo de un Recurso Limitado. . . . . . . . . . . . . . . . . . . 113

A.1. Acceso a la carpeta SimPy-1.7.1 en modo MS-DOS a traves de un terminal. . . . . . 120

A.2. Ejecucion del comando de instalacion de SimPy, a traves de la lınea de comando

MS-DOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Capıtulo 1

Introduccion y Planteamiento delProblema.

El siguiente capıtulo tiene como finalidad realizar una exposicion de los elementos mas

importantes que componen la presente investigacion. Entre estos aspectos se resaltan: los

antecedentes que motivaron la realizacion del mismo, el problema planteado, la justifica-

cion e importancia, el objetivo general y los objetivos especıficos, la metodologıa y las

herramientas a usar.

1.1. Introduccion.

La simulacion desde sus inicios ha perseguido predecir los resultados, a traves de mo-

delos, de ciertos procesos antes de ser llevados a cabo por el hombre, para ası comprobar

hipotesis o mejoras al sistema que se estudia y posibles soluciones (optimas) para el mejor

rendimiento de la problematica planteada. Es por ello que el hombre utiliza como una de

las herramientas principales hoy en dıa el computador, para desarrollar simulaciones de

los modelos de sistemas en los diferentes campos con ciertos niveles de tolerancia y tiem-

1

CAPITULO 1. INTRODUCCION Y PLANTEAMIENTO DEL PROBLEMA. 2

pos de corrida o simulacion mınimos; obteniendo de esta manera resultados que permiten

entender, explicar o mejorar la dinamica del sistema en cuanto al interes del estudio.

Hoy en dıa existe diversidad de herramientas computacionales, que simulan los com-

portamientos de los sistemas de acuerdo al modelo y al espacio donde este se desenvuelve;

estos pueden ser discretos o continuos y orientados a eventos discretos. Uno de los mayores

inconvenientes en el uso de estas herramientas es el hecho de que son software privado, que

se usa bajo licencia comercial y algunas de estas poseen un elevado costo economico, lo

que imposibilita la capacidad de hacer uso extensivo de estas herramientas. Por tales razo-

nes ya existen, dentro de la comunidad “Open Source” herramientas computacionales para

el Modelado y Simulacion especıficamente en el campo de la Simulacion por Eventos Dis-

cretos, tal es el caso del simulador SimPy, el cual es un paquete de simulacion por eventos

discretos desarrollado en el lenguaje de alto nivel Python que es de codigo abierto y con

una amplia variedad de caracterısticas de lenguajes como C++ o Java, gratuito y presenta

muchas ventajas respecto a otros softwares.

1.2. Antecedentes de la investigacion.

El desarrollo de manuales en espanol para los softwares que se usan en la Escuela de

Sistemas tiene un antecedente en el trabajo de pasantıas “Desarrollo de un manual de la

herramienta NS Network Simulator”. (Profesora Tania Jimenez, Asesora). NS es un simu-

lador discreto para la implementacion de redes, fue desarrollado en Berkley UC; escrito en

C++ y OTcl. Su principal area de aplicacion son las redes de area local y amplia del tipo

IP. La caracterıstica mas resaltante de esta herramienta es el establecimiento de protocolos

de redes en ejecucion tales como TCP y UDP y comportamiento de la fuente del trafico

tales como FTP (File Tranfer Protocol) y CBR (Constant Bit Rate).

La escuela de Ingenierıa de Sistemas incluye un curso en Simulacion de Sistemas, es


por ello que ha venido trabajando con diversos software de modelado y simulacion; algu-

nos de ellos comerciales, es decir son software privados con un elevado costo, tal es el caso

de Arena; en otros casos son gratuitos, aunque no de fuente abierta, como Glider. Recien-

temente hay un gran interes por el uso de herramientas libres en Venezuela, debido a un

decreto presidencial el cual expone el uso de Software Libre para entes publicos. Por tales

razones se plantea la idea de estudiar un software de simulacion de eventos discretos como

SimPy, ya que este conjuga los hechos de ser gratuito y de fuente abierta.

Actualmente hay un desarrollo muy importante del lenguaje Python en la comunidad

internacional de Open Source. Tanto ası, que se habla de que este es un posible reemplazo

de Java, dado que este ultimo, a pesar de ser gratuito, no es de fuente abierta. Este aumento

en el uso del lenguaje Python influye en el desarrollo de un sinnumero de herramientas para

usos especıficos escritas haciendo uso de el.

1.3. Planteamiento del Problema.

En la estrategia de Modelado y Simulacion debe prestarse especial atencion en la selec-

cion de las herramientas computacionales en cuanto a capacidad, eficiencia y rendimiento

economico. Actualmente existen un sinnumero de lenguajes y/o paquetes para la Simula-

cion por Eventos Discretos que ofrecen al modelador grandes capacidades para representar

al sistema en estudio, tal es el caso de Arena, Witness, GPSS/H por mencionar algunos. A

pesar del conjunto de caracterısticas y bondades que puedan presentar estos paquetes, se

requiere de grandes inversiones de dinero para su adquisicion.

Cabe destacar que para la eleccion de un Software de Simulacion en el campo de la

Simulacion por Eventos Discretos depende de multiples factores: funcionalidad, facilidad,

eficiencia y portabilidad, entre otros. Es por tal razon que en el presente proyecto de investi-

gacion se pretende dar a conocer el paquete de Simulacion por Eventos Discretos SimPy, el


cual reune en cierta manera las caracterısticas antes expuestas, ademas el hecho de ser gra-

tuito y de fuente abierta (Open Source). Concretamente, con la realizacion de este proyecto

de investigacion se pretende desarrollar un manual en espanol comentado y ejemplificado

de SimPy, para dar a conocer las potencialidades y bondades del simulador, esto debido a

la inexistencia de documentacion en espanol de esta herramienta.

1.4. Justificacion y alcance de la investigacion.

El gran auge que ha venido presentando los paquetes bajo la filosofıa de Software Libre

es debido a que estos presentan caracterısticas de ser gratuitos, poderosos y eficientes. Cada

dıa se desarrollan herramientas bajo estas premisas en los diferentes campos de aplicacion

empresarial, uno de estos campos es la Simulacion por Eventos Discretos. A pesar que

ya existen herramientas de Simulacion por Eventos Discretos que se aplican a diferentes

areas, tal es el caso de SimPy, este aparte de presentar caracterısticas de ser Software Libre

y Open Source, no cuenta con una buena documentacion en espanol. Por tal razon, es

evidente la importancia de este proyecto de investigacion como respuesta a la necesidad de

una herramienta computacional para la Simulacion por Eventos Discretos que cumpla con

las caracterısticas antes mencionadas.

El desarrollo del manual en espanol de SimPy permitira mostrar el uso y aplicacion de

este paquete en el modelado y simulacion de diferentes sistemas; ası el usuario contara con

un programa que presenta las siguientes libertades:

Usarlo para cualquier proposito dentro del campo de la Simulacion por Eventos Dis-

cretos, es decir, como instrumento para el modelado de sistemas.

Dar soluciones a los problemas de Simulacion Orientados a Eventos Discretos de

manera mas rapida y sencilla.


Posibilidad de adaptar el programa a sus necesidades ya que, el usuario contara con

el codigo fuente.

Mejorar el programa y hacer publicas las mejoras, de forma que toda la sociedad se

beneficie.

Todas las razones expuestas previamente justifican y dan importancia al desarrollo de

la presente investigacion.

1.5. Objetivos de la Investigacion.

1.5.1. Objetivo General.

Desarrollar un manual de usuario en espanol comentado y ejemplificado, donde se pue-

da reflejar la capacidad del simulador con ejemplos bien probados y corridos.

1.5.2. Objetivos Especıficos.

Obtener conocimientos del lenguaje de programacion Python.

Revisar los conceptos de simulacion orientada a eventos discretos.

Aprender a utilizar el lenguaje de simulacion SimPy.

Aprender y/o repasar el uso de los paquetes de simulacion que se usan en la carrera

de Ingenierıa de Sistemas.

Desarrollar un conjunto de ejemplos de muestra, desde casos de sistemas sencillos

hasta problemas complejos, que seran resueltos usando simulacion en SimPy.


Desarrollar los modelos en SimPy de los ejemplos generados en el punto anterior.

Ejecutar la simulacion en SimPy de los modelos del punto anterior y mostrar los

resultados obtenidos.

Intentar simular en otros paquetes los modelos desarrollados en SimPy

Escribir el manual de usuario de SimPy en espanol.

1.6. Metodos y Herramientas.

1.6.1. Simulacion.

Simular implica crear un modelo que aproxima cierto aspecto de un sistema del mundo

real y que puede ser usado para generar historias artificiales del sistema, de forma tal que

nos permite predecir cierto aspecto del comportamiento del sistema.

En particular, usaremos computadores para imitar comportamientos de los sistemas

evaluando numericamente un modelo del mismo. Estas evaluaciones numericas son las que

nos permiten generar los comportamientos artificiales que no son mas que experimentos.

Para llevar a cabo estas simulaciones partimos de un modelo, el cual nos es mas que

una representacion matematica del comportamiento de un objeto (ente) en un determina-

do sistema, realizando para ello abstracciones de las caracterısticas mas significativas del

objeto o sistema en estudio.


1.6.2. Python.

Python [9]1 fue desarrollado hace diez anos por Guido van Rossum, su sintaxis simple

se deriva en gran parte del ABC, un lenguaje desarrollado en los 1980s para la ensenanza.

Presenta una variedad amplia de caracterısticas de lenguaje de programa como C++, Java,

Modula-3 y Scheme. El comodo uso del lenguaje se deriva del hecho que es un lenguaje

interpretado, lo que ahorra un tiempo considerable en el desarrollo del programa, pues no

es necesario compilar ni enlazar. El uso del interprete es como invocar una maquina virtual,

que facilita experimentar con caracterısticas del lenguaje, escribir programas desechables

o probar funciones durante el desarrollo del mismo.

1.6.3. SimPy (Simulador en Pyhon).

SimPy [5] es un simulador orientado a objetos para procesos basados en eventos dis-

cretos, soportado en el lenguaje Python. SimPy esta basado en las ideas de los lenguajes

de simulacion como Simula y Simscript pero utilizando el estandar del lenguaje Python de

allı la etimologıa de su nombre (SimPy: Simulador en Python). El soporte del simulador

esta basado en la implantacion de corutinas utilizando la capacidad generadora de Python

introducida por versiones superiores a la 2.2.

1.6.4. Glider.

Glider [24] es un lenguaje de Simulacion para Sistemas discretos y continuos. Los

sistemas a simular se representan por medio de una red, donde cada nodo representa a un

subsistema y se comunican entre si a traves del paso de mensajes o por accion de metodos

sobre variables compartidas.

1 Tomado de Wikipedia. La encicloedia libre http://es.wikipedia.org/wiki/Python


1.6.5. Arena.

Arena R© [28]2 es un paquete de simulacion grafico para Sistemas discretos y conti-

nuos desarrollado por la empresa norteamericana Rockwell Automation, Inc. El sistema es

representado por diagramas de flujo y a traves del diseno orientado a objetos para esta-

blecer el modelo. Entre las aplicaciones que se pueden desarrollar con esta herramienta se

encuentran procesos de fabricacion, logıstica almacenes y transporte.

1.7. Organizacion del Documento.

El manuscrito del proyecto se desglosa en cinco (5) capıtulos, los cuales se describen a

continuacion:

Capitulo 1. Introduccion y Planteamiento del Problema. Donde se expone una breve

introduccion y los antecedentes del proyecto desarrollado, el planteamiento del problema,

ası como los objetivos tanto generales y especıficos que se persiguen, su justificacion y

metodologıa que se uso en el desarrollo del proyecto.

Capıtulo 2. Marco Teorico. En el se desarrollan los basamentos teoricos de los cuales

se nutre el proyecto; conceptos basicos de sistema y los elementos que lo forman, modelos

y tipos de modelos. Por otro lado, se encuentra la Simulacion, sus ventajas, desventajas e

inconvenientes; la simulacion de sistemas orientados a eventos discretos, (que en nuestro

caso es la base de este proyecto de investigacion por ser el enfoque de estudio) las etapas,

ası como tambien el uso de los distintos lenguajes y paquetes de simulacion.

Capitulo 3. Modelado y Simulacion en SimPy. Capıtulo donde se describe paso a

paso, la metodologıa en que se encuentra basado este paquete de simulacion a eventos

2 Tomado de la version en ingles de http://www.arenasimulation.com


discretos con un enfoque basado en los metodos descritos en el capıtulo anterior. Ası como

codigo de ejemplo para reflejar las secciones antes descritas.

Capıtulo 4. Aplicacion. En este capıtulo se mostrara un conjunto de modelos desde ca-

sos sencillos, pasando por los de nivel intermedio, para finalmente pasar a los mas comple-

jos. Estos se desarrollaran uno a uno, empleando para ello en primera instancia el paquete

SimPy, luego Arena de Rockwell Software y finalmente Glider de la ULA (freware).

Capıtulo 5. Conclusiones y Recomendaciones. Se detallaran las conclusiones arroja-

das por el proyecto y las recomendaciones que se plantean para ampliar esta investigacion

en estudios posteriores.

Capıtulo 2

Marco Teorico.

Este capitulo tiene la finalidad de sentar las bases teoricas fundamentales para el desa-

rrollo de la presente investigacion y el alcance de los objetivos planteados. Es por ello que

se hace necesario abordar las siguientes areas de estudio: Conceptos relacionados con sis-

temas, modelos y tipos de modelos, simulacion junto con sus diferentes enfoques; ası como

tambien informacion del software utilizado para llevar a cabo las simulaciones. A su vez

esta seccion pretende informar al lector sobre algunos conceptos que no le sean familiares,

y colaborar en que la informacion presentada sea comprensible.

2.1. Introduccion.

En la actualidad, la necesidad de encontrar soluciones al sinnumero de problemas que

se plantean en las diferentes empresas y corporaciones, es lo que ha generado que la Simu-

lacion se haya masificado. Para estas empresas, no es viable, comenzar con la implantacion

de un proyecto determinado sin antes realizar una serie de hipotesis a traves de pruebas y

experimentos, las cuales planteen buscar la rentabilidad economica del mismo. Es por ello,

que se ven en la necesidad de plantear un modelo, el cual represente de la manera mas

10

CAPITULO 2. MARCO TEORICO. 11

explicita posible, las caracterısticas relevantes del sistema a estudiar. Para llevar a cabo es-

tas pruebas con el modelo, se valen del soporte de una computadora. Estos experimentos

son los que permitiran realizar un analisis exhaustivo de las variables que juegan un pa-

pel determinante dentro del sistema. Los analisis mas empleados son los de sensibilidad y

los basados en tecnicas estadısticas y/o probabilısticas; ya que, la introduccion de factores

aleatorios al modelo es lo que permitira ajustarlo a la realidad.

2.2. Conceptos Basicos.

2.2.1. Sistema.

La palabra Sistema es muy empleada en diferentes contextos, es por ello que se ha-

ce difıcil dar una definicion concreta; pero en el area de Investigacion de Operaciones

algunos autores la definen como:

“Conjunto de cosas que ordenadamente relacionadas entre si contribuyen a determi-

nado objeto” [4].

Schimidt y Taylor en [7] “es una coleccion de entidades como por ejemplo personas

o maquinas, que actuan e interaccionan juntos entre si, hacia el cumplimiento de un

objetivo”.

Combinacion de elementos o componentes interrelacionados y relacionados con el

entorno, que actuan juntos para lograr un cierto objetivo [2].

Es de hacer notar en estas definiciones lo siguiente, para que un sistema este concebido

necesariamente tiene que estar formado por varias partes (objetos); los cuales, a su vez,


deben estar interconectados por varias relaciones. Hoy dıa existen una diversidad de sis-

temas tan complejos, que se hace un tanto difıcil establecer relaciones entre sus partes, es

por ello que conviene realizar una descomposicion en partes mas pequenas (subsistemas),

permitiendo simplificar su estudio. Ejemplo de esto son los sistemas de manufactura com-

puestos de varios departamentos, sistemas de transporte, logısticos, de gestion de recursos

y otros [4] (ver figura 2.1)1 .

Figura 2.1: Proceso de manufactura como sistema.

Debido a que las propiedades mas importantes de un sistema, involucran conocimiento

de sus partes, se hace necesario el conocimiento de algunos conceptos como entidad, en-

tidades permanentes, atributos, relacion, recursos, estado y evento, los cuales se detallan a

continuacion:

Entidad: Es algo (objeto), que tiene realidad fısica u objetiva y que posee un conjunto

de caracterısticas (atributos) distinguibles de los demas [3], por ejemplo: productos,

departamentos, piezas, clientes moviendose en un restaurant, empleados, etc.1 Tomado de Barcelo J. (1996) p.20


Entidades temporales: Son todos aquellos objetos que se procesan en el sistema [8],

como por ejemplo las piezas en un sistema de manufactura, los clientes en un banco.

Atributos: Conjunto de propiedades que caracterizan a las entidades que forman parte

del sistema [4], por ejemplo: cantidades de pedidos, numero de maquinas de un tipo

dado, color, prioridad, etc.

Relacion: Es la manera en que, las propiedades de una o mas entidades dependen

entre sı; causando de esta manera que, un cambio en la propiedad de una entidad

ocasiona un cambio en una propiedad de otra entidad [1]; ejemplo: En la clase en-

tidad: departamento de produccion en el sistema manufactura, sus cambios pueden

afectar a los departamentos de compra y ensamblaje.

Recursos o entidades permanentes: Como su nombre lo indica son una clase de enti-

dades estaticas, las cuales son los medios para ejecutar las actividades. Estos definen

quien o que ejecuta la actividad. Los recursos presentan caracterısticas como capaci-

dad, velocidad, averıas y reparaciones [8]. Ejemplo de recursos son las maquinas en

un sistema de manufactura, los mecanismos de transporte o los operadores.

Estado: Son los valores y/o condiciones de los atributos de las entidades en un instan-

te dado, despues de suscitarse un evento; de forma que se puede saber si una accion

se puede ejecutar o si se puede elegir entre varias [4]. Ejemplo: el numero de clientes

en una cola, los procesos de manufactura en cada departamento de una factorıa, etc.

Evento: Son los diferentes hechos que ocurren en instantes de tiempo, para dar lugar

a cambios en el estado del sistema y ası identificar que es lo que origina el cambio y

cuando se origina [17]. Ejemplo: Una llegada, una salida de una entidad.


2.2.2. Modelos.

El uso de modelos no es algo nuevo. Los estudios piloto que requieren las grandes em-

presas hoy dıa, pueden llevarse a cabo gracias a la tecnica de modelizacion, es decir, la

construccion de modelos donde se realizan estos analisis con el fin de obtener resultados,

conclusiones y/o recomendaciones aplicables al sistema real. Dicho lo anterior, un modelo

es una interpretacion explıcita de lo que se entiende de una situacion la cual puede expre-

sarse con sımbolos matematicos, grafismos (letras, signos) o fonemas; pero en esencia es

una representacion del sistema con sus partes y relaciones para un determinado fin [3].

Dado que uno de los requerimientos basicos de un modelo es que este debe describir al

sistema para realizar predicciones sobre el comportamiento del mismo, es decir las carac-

terısticas del modelo deben corresponder a caracterısticas del sistema bajo estudio y operar

en un rango de trabajo especıfico [4], explicacion que puede representarse a traves de la

figura 2.2.

Figura 2.2: Correspondencia entre un sistema y modelo.


2.2.3. Tipos de modelos.

Debido a que el campo del modelado es muy amplio, y dado que en este proyecto no se

abordara en profundidad este punto, solo se hara una breve descripcion (caracterısticas mas

relevantes) de los diferentes tipos de modelos. De acuerdo a la realidad que representen y

la perspectiva que le de el analista, los modelos se clasifican en [1]:

Modelos de Tiempo Continuo: Se representan cuando las variables de estado estan

definidas para instantes de tiempo determinado [1], muy utilizados en la actualidad

por ejemplo, para denotar el numero de trabajos en cola en espera por recurso.

Modelos de Tiempo Discreto: Empleados cuando el estado del sistema se define solo

para particulares instantes de tiempo especıficos [1], ejemplo el numero de clientes

que visitan el banco un dıa de semana determinado.

Modelos de Estado Continuo o de Eventos Continuos: Representan sistemas cu-

yos cambios de estado son graduales [1]. Las variables intervinientes son continuas.

Modelos representados por ecuaciones diferenciales donde una de las variables de

estado representa la cantidad de corriente en una bobina.

Modelos de Estado Discreto o de Eventos Discretos: En estos modelos, las variables

de estado que describen al sistema cambian de valor en instantes no periodicos del

tiempo. Estos instantes de tiempo se corresponde con la ocurrencia de un evento el

cual obedece a un patron aleatorio [8]. Por ejemplo el modelo de cola en un banco,

al cual llegan clientes de modo aleatorio y en el cual se desea prever el tiempo de

espera de los clientes en las colas en funcion del numero de cajeros disponibles.

Modelos Determinısticos: Son aquellos donde la solucion para determinadas condi-

ciones es unica y siempre la misma [1]. Ejemplo de este tipo, son los modelos de

optimizacion lineal donde la solucion esta sujeta por el conjunto de ecuaciones y/o

inecuaciones que se suministran como restricciones.


Modelos Probabilısticos o Aleatorios: Son aquellos donde las caracterısticas del sis-

tema se representan por variables aleatorias [1]. Por ejemplo los simuladores de co-

las, donde las llegadas a estas se produce a traves de una funcion de distribucion de

probabilidades .

Modelos Estaticos: Utilizados para representar sistemas cuyo estado es invariable a

traves del tiempo [1]. Por ejemplo la cantidad de materia en energıa E = m ∗ c2 .

Modelos Dinamicos: Contrario a los anteriores, en estos las variables de salida si

varıan en el tiempo [1], muy empleados en el area de control para modelar la dinami-

ca de un sistema fısico a traves de ecuaciones diferenciales dependientes del tiempo.

Modelos Lineales: Son aquellos cuya salida del sistema se representa por una lınea

recta [1], ejemplo de estos son los modelos de regresion lineal y = a ∗ x + b.

Modelos No Lineales: Empleados para representar sistemas en donde las salidas no

sean lineales [1], por ejemplo la solucion en el tiempo de una ecuacion diferencial de

segundo orden.

Modelos Abiertos: Si los datos de entrada son externos al modelo e independientes

de el [1], ejemplo los sistema de cola de un banco donde los arribos son externos al

modelo.

Modelos Cerrados: Estos no disponen de una entrada del exterior [1], ejemplo de

ellos son los modelos de control en su estado natural (No hay entrada presente).

Modelos Estables: Son aquellos donde la variable de salida converge a un valor (in-

dependiente del tiempo) [1], ejemplo cuando el intervalo de llegada de clientes es

mayor que el tiempo de servicio.

Modelos Inestables: Cuando el comportamiento del sistema cambia constantemente

[1], al contrario del anterior no hay tendencia a un valor estable, ejemplo de estos


modelos son los sistemas de colas en un banco, donde el intervalo entre llegadas es

menor que el tiempo de servicio.

Es de hacer notar que algunas veces los modelos y los sistemas no pertenecen al mismo

tipo, ejemplo de ello es el estudio del fluido por una canerıa (dinamica de fluido) el cual

corresponde a un sistema continuo. Sin embargo si el fluido se discretiza dividiendolo en

gotas y se construye un modelo discreto por el cual circulan gotas de agua (una, dos, diez,

cien, mil) se esta representando un sistema continuo por un modelo discreto [3].

2.3. Simulacion.

“Simular” significa imitar el comportamiento de una maquina, una persona o un

fenomeno. Generalmente son simuladas las conductas de un sistema fısico con el fin de

estudiarlo. Para efectuar esto, es necesario crear una representacion del sistema, un mo-

delo. Es decir, hacer algunas suposiciones, mas o menos precisas, acerca de su operacion.

Este conjunto de postulados, con frecuencia toman una forma matematica o de relaciones

logicas, y constituyen el modelo conceptual. Este modelo servira para entender mejor el

sistema, y posiblemente estudiar el impacto de ciertas modificaciones, lo cual es, basica-

mente, la razon del inicio de la simulacion.

En otras palabras, la simulacion consiste en una evaluacion numerica del modelo a

traves de un computador, durante un perıodo determinado de tiempo, tomando medidas y

experiencias durante este tiempo para hacer posible la descripcion de su comportamiento

[7].

Estas definiciones de simulacion permiten plantear suposiciones del sistema bajo estu-

dio en cualquiera de sus etapas, para ası evaluar distintos escenarios, encontrar repuestas a

preguntas del tipo “que pasara sı” y ası entender o mejorar el sistema.


Uno de los objetivos de la simulacion es realizar ensayos de cambios en el sistema

probandolos en el modelo, con el fin de elegir la mejor alternativa, y ası enfrentar mejor a

una realidad que varıa dıa a dıa [4].

Con respecto al sistema, modelo y simulacion, Law y Kelton (2000) [7] senalan:

“luego de definir el sistema de interes, se hacen experimentos con el siste-ma, sı implica mucho costo, se disena un modelo y se experimenta con el paraobtener un modelo fısico o matematico; y en caso de este ultimo, emplear lastecnicas analıticas y/o de simulacion”.

tal y como se esquematiza en la Figura 2.3 [7]2

Figura 2.3: Formas de estudiar un Sistema.

2 Tomado de (Law & Kelton, p. 4)


2.3.1. Ventajas, desventajas y peligros de la Simulacion.

A continuacion se presentara de manera esquematica las ventajas, desventajas y peli-

gros de la simulacion segun posturas de ciertos autores [1,2,3,4]:

Ventajas.

1. Con el modelo de Simulacion construıdo este se puede utilizar repetidamente para

analizar cambios en el diseno, polıticas y diversos escenarios de operacion con el

sistema.

2. Se identifica en un sistema complejo aquellas areas con problema (“cuellos de bote-

lla”).

3. Se adquiere una rapida experiencia a muy bajo costo y sin riesgos. No se compromete

la confiabilidad del sistema en los ensayos (las aglomeraciones, las largas demoras

son simuladas y no reales).

4. Generalmente los modelos de Simulacion son mas faciles de aplicar que los metodos

analıticos.

5. No es necesario interrumpir las operaciones de la companıa.

6. Permite estudiar el sistema por perıodos muy largos en un tiempo comprimido o al-

ternativamente un trabajo minucioso, analizarlo en tiempo expandido.

7. Se puede tener un mejor control sobre condiciones experimentales, para no experi-

mentar con el sistema real.

8. Puede ser aplicada para diseno de sistemas nuevos en los cuales se quieren comparar

alternativas muy diversas surgidas a traves de la utilizacion de diferentes tecnologıas.


9. La Simulacion puede utilizarse durante la vida de un sistema, para probar modifi-

caciones antes que estas se implementen (si es que los resultados de la simulacion

aconsejan su uso).

Desventajas.

1. Son costosas ya que requieren gran cantidad de corridas computacionales para en-

contrar soluciones, consume mucho tiempo en su desarrollo para que el modelo sea

valido.

2. Los resultados de simulacion son numericos; por tanto, surge el peligro de atribuir a

los numeros un grado mayor de validez y precision; en consecuencia, las soluciones

obtenidas no son optimas.

3. No se debe utilizar cuando existan tecnicas analıticas que permitan plantear, resolver

y optimizar todo el sistema o alguna parte del mismo.

4. No es posible asegurar que el modelo sea valido, ya que no existe criterio cientıfico

para la seleccion de alternativas a simular (Estrategias).

5. Dificultad en vender la idea por falta de conocimientos.

Peligros.

1. Subestimar el tiempo y costos involucrados en el proceso de modelacion.

2. Es posible elaborar todo un gran andamiaje3 de pruebas y resultados falsos, basados

en un modelo confiable y valido bajo otras condiciones.

3 La palabra andamiaje bajo este contexto significa como un soporte de lo que se esta diciendo. Segunla Real Academia Espanola andamiaje es un conjunto de andamios y andamio es una armazon de tablones,usado para trabajar sobre el en la parte alta de un edificio


3. Los modelos de simulacion son generalmente programas grandes, que si no se tienen

las precauciones respectivas, es posible tener errores de programacion que hagan las

conclusiones sin sentido. Es por ello, que se debe evitar el entendimiento superficial

del sistema a ser modelado.

4. Por tratar de ahorrar tiempo de analisis y de computacion, las corridas de simulacion

pueden ser muy cortas. Los resultados en estos casos dependen fuertemente de las

condiciones iniciales y pueden no representar al sistema real. El tiempo de corrida

adecuado depende de la metodologıa estadıstica, deseada (intervalos de confianza) y

de la varianza de las cantidades observadas.

Los campos y areas de aplicacion de la simulacion son extensos, sin embargo, se inten-

tara presentarlos de manera resumida en la tabla 2.1 [17]4 .

CAMPOS APLICACION

Computacion Redes de ordenadores, componentes,

programacion, bases de datos,

fiabilidad.

Manufactura Manejo de materiales, lıneas de montaje,

equipos de almacenamiento, control de inventario,

mantenimiento, distribucion en planta,

diseno de maquinas.

Negocios Analisis de existencias, polıtica de precios,

estrategias de marketing, estudios de adquisicion,

analisis de flujo de caja, prediccion,

alternativas del transporte, planificacion de mano de obra.

Gobierno Armamento y su uso, tacticas militares,

prediccion de la poblacion, uso del suelo,

continua. . .4 Tomado de la pagina del Profesor Jesus Racero http://racero.us.es/


. . .continuacion

CAMPOS APLICACION

prevencion de incendios, servicios de policıa,

justicia criminal, diseno de vıas de comunicacion,

servicios sanitarios.

Ecologıa y medio ambiente Contaminacion y purificacion del agua,

control de residuos, contaminacion del aire,

control de plagas, prediccion del tiempo,

analisis de seısmos y tormentas,

exploracion y explotacion de minerales,

sistemas de energıa solar, explotacion de cultivos.

Sociedad y comportamiento Estudios de alimentacion de la poblacion,

polıticas educativas, estructuras organizativas,

analisis de sistemas sociales, sistemas de asistencia social,

administracion universitaria.

Biociencias Rendimiento en el deporte, control de epidemias,

ciclos de vida biologicos, estudios biomedicos.

Tabla 2.1: Aplicaciones de la Simulacion

Segun lo anterior, la aplicacion de la simulacion a diferentes tipos de sistemas com-

binada con los diferentes enfoques de estudio, conducen a una gran variedad de maneras

en que se puede realizar un estudio de simulacion. No obstante, hay determinados pasos o

etapas basicas, los cuales se denominan: “Metodologıa de un estudio de Simulacion” [4],

las cuales seran explicadas en detalle a continuacion:

Las ideas aquı planteadas han sido tomadas, principalmente, de Guash A. et al. [8],

2005.


1. Definicion del problema y planificacion del estudio.

En esta etapa se definen los objetivos perseguidos por el planteamiento del problema.

Si estos objetivos no se definen con claridad existira el peligro de no abordar correc-

tamente el problema, para el cual se ha solicitado la tecnica de simulacion, como vıa

para su posible solucion.

2. Recogida de datos.

La recopilacion de datos e informacion deben ser de fuentes creıbles, y a su vez,

cuestionables. Como en el campo de trabajo esto sucede muy poco, se debe res-

ponder a las preguntas planteadas del problema, realizando hipotesis razonables en

colaboracion con el usuario final.

3. Formulacion del modelo conceptual.

Conocidos los objetivos del problema, existira la posibilidad (tentacion) de comenzar

la construccion del modelo de simulacion inmediatamente en el computador. Ello

conduce a obtener modelos de difıcil mantenimiento; es por esto que se recomienda

plantear un modelo conceptual con un nivel de abstraccion superior al planteado en

el codigo, este contemplara las relaciones estructurales mas importantes del sistema

y la coordinacion de la sucesion de actividades que ocurriran.

4. Construccion del modelo.

Para esto se plantearan varios modelos simplificados que caractericen las partes mas

esenciales del sistema, para ası avanzar rapidamente a la consecucion de los objetivos

planteados, y ası obtener un posible modelo general (decimos posible ya que un

modelo tiene que estar en constante mantenimiento y verificacion).

5. Verificacion, validacion y pruebas.

Una de las etapas mas importantes en la tecnica de la simulacion, ya que, con una bue-

na cantidad de pruebas se verificara que el modelo se ejecuta correctamente y segun

las especificaciones (modelo conceptual) y validaremos que las hipotesis plantea-

das, la teorıa empleada y otras suposiciones son correctas; esto favorece que nuestro


modelo tenga un comportamiento lo mas parecido posible a la realidad.

6. Diseno de los experimentos de simulacion.

Se decidira que caracterısticas del sistema se mostraran a traves de las estadısticas,

la duracion de cada simulacion, las condiciones iniciales y el numero de ejecuciones

(replicas); para ası inferir y tomar decisiones con mayor seguridad.

7. Analisis de los resultados.

Se estudiaran los resultados obtenidos, observando carencias y mejoras, realizando

un estudio de sensibilidad de las variables de estado.

8. Documentacion e implementacion.

En las etapas precedentes, es muy importante mantener un documento que muestre

el estado del proyecto de simulacion, su evolucion en paralelo de cada etapa. La

implementacion consistira en tomar decisiones como fruto del estudio de simulacion

realizado.

Como se puede apreciar en la Figura 2.4, estos pasos en general no son secuenciales,

sino iterativos, ya que, algunos de los pasos pueden tener que repetirse en funcion de los

resultados intermedios.


Figura 2.4: Etapas en un estudio de Simulacion.


2.3.2. Simulacion de sistemas orientados a eventos discretos.

Segun Law y Kelton [7], la Simulacion de Eventos Discretos es la que involucra el mo-

delo de un sistema que evoluciona en el tiempo, en donde, las variables de estado cambian

en determinados instantes de tiempo. Este comportamiento discreto del sistema permite la

implementacion del mismo en un programa computacional mediante una lista de sucesos

futuros, un reloj que salte en el tiempo hacia el siguiente suceso, las variables de salida

que miden el comportamiento del sistema y unos acumuladores estadısticos que tomen un

registro de los valores de las variables de estado [8].

2.3.3. Elementos de un Simulador de Eventos Discretos.

Actualmente la gran mayorıa de simuladores para Sistemas Orientados a Eventos Dis-

cretos, presentan una serie de caracterısticas inherentes a la estrategia de simulacion adop-

tada. Estas caracterısticas de por sı generales, no escapan de la filosofıa de SimPy y se

encuentran bien implantadas en el codigo fuente, estas caracterısticas son:

Un generador de numeros aleatorios U[0,1]: es el modulo base para la generacion

de valores aleatorios entre [0,1] uniformemente distribuidos. SimPy se vale de las

bondades del lenguaje Python, que ya tiene implantado un modulo para tales fines.

Generadores de variables aleatorias: Generar valores que siguen las distintas fun-

ciones de distribucion de probabilidades, a partir de los valores aleatorios U[0,1],

usando para ello diversas tecnicas.

Reloj de simulacion: Es una variable global que almacena el tiempo de la simulacion.

Lista de Eventos Futuros (LEF): Es una estructura que almacena los instantes de

tiempo, cuando deben activarse los eventos que esperan por suceder. Esta lista es


consultada antes de la simulacion de cada evento y durante la simulacion de un evento

para programar nuevos eventos.

Modulos para la generacion de estadısticas: conjunto de variables y rutinas para ob-

tener las medidas de comportamiento de interes y las salidas al final de la simulacion.

Modulo de inicializacion: En el se fijan los estados iniciales de las variables de es-

tado del modelo, el reloj de simulacion, la lista de eventos, ası como los generadores

de secuencias de numeros seudo-aleatorios, a traves de la semilla.

Rutina de actualizacion del reloj del simulador: es un subprograma que determina

el instante de tiempo en el que debe activarse el siguiente evento, ası como el evento

que debe ser disparado. Esta informacion es obtenida de la lista de eventos futuros.

Rutina de tratamiento de eventos: para cada tipo de evento existe una rutina de

tratamiento de evento, la cual actualiza los valores de algunas de las variables de

estado y puede generar entradas nuevas a la lista de eventos futuros.

Programa principal o codigo ejecutivo: Agrupa todas las rutinas para controlar la

ejecucion de la simulacion, en funcion de la estrategia de simulacion adoptada.

Rutinas de trazado: Utilizadas para desplegar resultados intermedios durante la eje-

cucion de la simulacion, se emplean para la depuracion (debugging) del simulador.

A traves del diagrama de flujo de la figura (Figura 2.5), se explica en forma grafica el

flujo de control existente entre los elementos de un Simulador Orientado a Eventos Discre-

tos.


Figura 2.5: Flujo de control entre los elementos de un simulador orientado a eventos discretos.

Al igual que en las etapas de un estudio de simulacion la explicacion de estos elementos

fue obtenida de Guash A. et al., 2005. [8].

El gran auge que han tenido en la actualidad los diferentes simuladores de eventos

discretos, es pues, la presencia de estos factores ya implantados intrınsicamente en ellos.

2.3.4. Estrategias de Simulacion de Sistemas Orientados a Eventos

Discretos.

Los lenguajes y paquetes para la simulacion de sistemas orientados a eventos discretos,

fundamentalmente se elijen de acuerdo a lo atractivo de sus caracterısticas, sin embargo

hay una de ellas que resulta determinante e impone su filosofıa, es la estrategia enfoque

o vision del mundo [4], utilizada para la seleccion del suceso siguiente y la gestion del

tiempo durante la simulacion. Segun Kiviat [19] estas estrategias o enfoques se clasifican

en:


1. Programacion de eventos (Event Schedulling).

2. Exploracion de actividades (Activity Scanning).

3. Interaccion de Procesos (Process Interaction).

1.- Programacion de eventos.

El enfoque de Programacion de Eventos (Event Schedulling), es una tecnica que en-

vuelve una secuencia de eventos incondicionados5 a lo largo del tiempo de simulacion. Es

por ello que los modelos de simulacion expresados a traves de esta tecnica, se basan en con-

siderar la operacion (es) del sistema como una secuencia temporal y ordenada de eventos

incondicionales. Barcelo (1996) considera la implantacion de esta tecnica de la siguiente

manera:

Se selecciona de la lista de eventos aquel evento cuyo tiempo de ocurrenciaes el mas cercano, solucionando los empates por las prioridades asignadas aestos, o por defecto, actualizando el tiempo de reloj de simulacion al valor enque ocurre tal suceso, llamando para ello a la rutina correspondiente para eseevento (p. 123).

El bosquejo de implantacion citado anteriormente hace inferir que una de las caracterısti-

cas mas resaltantes de esta estrategia de simulacion es que, tan solo pueden codificarse las

rutinas de tratamiento de eventos incondicionales. Por otro lado, como la mayorıa de siste-

mas a simular, presentan tanto eventos incondicionales como condicionales, estos ultimos

se deberan incluir en las rutinas de tratamiento de eventos incondicionales [8].5 Eventos incondicionados son aquellos eventos que estan planificados para su ejecucion y no dependen

de condiciones


2.- Exploracion de Actividades.

En este enfoque se presta mayor atencion al conjunto de actividades que tienen que

ejecutar cada una o lote de entidades (personas, mensajes, piezas) presentes en el sistema,

identificando ası el conjunto de condiciones que permiten que suceda la actividad y la natu-

raleza de estas. Bajo este esquema el modelador, se concentra en el conjunto de condiciones

que permite iniciar una actividad.

Segun Pooch [20], una de las debilidades principales de este enfoque es la necesidad

de tener un incremento de tiempo reducido ya que; en caso contrario, eventos que estan

separados en el tiempo puedan aparecer simultaneamente en el simulador. Por tanto, este

incremento de tiempo tiene que ser lo suficientemente pequeno para que dos eventos se-

parados en el tiempo tambien aparezcan separados en la simulacion. Debido a ello y otros

factores, este enfoque ha evolucionado hacia la denominada estrategia de tres fases, la cual

combina el incremento de tiempo propio de la programacion de eventos con la exploracion

de actividades. En la actualidad, esta evolucion se sintetiza en los siguientes pasos:

1. Extraer de la lista de eventos futuros el evento mas proximo a suceder, avanzar el

reloj de la simulacion hasta ese tiempo y extraer el resto de eventos de la lista de

eventos futuros que tienen el mismo tiempo.

2. Ejecutar todos los eventos extraıdos, del paso anterior. Recordar que estos eventos

son incondicionales. En esta fase se pueden liberar recursos y/o cambiar el estado

del sistema.

3. Buscar todas aquellas actividades asociadas a eventos condicionados para ejecutar

las que cumplen todas las condiciones. Esta busqueda se repite hasta que no halla

ninguna actividad adicional.

Es de notar que, a traves de esta nueva vision de tres fases, del enfoque de exploracion


de actividades, se separan claramente las actividades ligadas a eventos incondicionados de

los condicionados.

3.- Interaccion de Procesos.

Aquı el enfoque se basa en la entidad que fluye por el proceso. En donde, el proceso

es definido como todo el ciclo de vida de la entidad que fluye a traves del sistema. En esta

tecnica, se diferencian las entidades temporales (piezas, clientes, mensajes) que se mueven

en el sistema, de las entidades permanentes o tambien llamadas recursos (gruas, maquinas,

cajeros).

A traves de este paradigma el analista define la situacion (modelo) a resolver, desde

el punto de vista de las entidades temporales que llegan al sistema, demandando multi-

ples recursos de capacidad limitada, esperando en colas si los recursos estan ocupados o

retardandose cierta cantidad de tiempo en la utilizacion del recurso.

Segun Guash et al., 2005 [8], la popularidad de este enfoque radica en describir el mo-

delo de simulacion con bloques de alto nivel en los cuales la interaccion de los procesos

es tratada directamente por la herramienta de simulacion, para ası ahorrar gran cantidad de

tiempo en la etapa de implantacion del modelo. Intrınsicamente, estas herramientas mani-

pulan los eventos incondicionales de la lista de eventos futuros, tal como se realiza en el

enfoque de programacion de eventos (explicada previamente).

Ahora bien, el caso de estudio que compete al proyecto, es el enfoque basado en la

interaccion de procesos, por ser este el pilar fundamental en el cual esta sustentado el

simulador SimPy, a traves del Metodo de Ejecucion de Procesos (PEM Process Execution

Method -el cual sera tratado en detalle mas adelante en el capıtulo 3).


2.3.5. Simulacion Orientada a Objetos.

Recientemente ha comenzado un gran interes por la Simulacion Orientada a Objetos.

Esto, probablemente, como consecuencia del gran interes en general por la programacion

orientada a objeto. La programacion y la Simulacion Orientada a Objetos, nacieron de

SIMULA: que es un lenguaje de simulacion orientado a objeto, creado en los anos de

1960 [7], por Kristen Nygaard y Ole-Johan Dahl del Centro Noruego de Computacion en

Oslo, y su desarrollo se extendio desde 1962 a 1967 [29].

Partiendo de las ideas planteadas con la creacion de Simula, la Simulacion Orientada a

Objeto, considera que el sistema a simular, esta compuesto de objetos (por ejemplo clien-

tes), los cuales interaccionan con otros objetos a traves del tiempo. En el sistema, pueden

existir varias instancias de ciertos tipos de objetos (por ejemplo entidades), actualmente

presentes durante la ejecucion de la simulacion. Estos objetos contienen datos (atributos)

que se emplean para describir su estado en un punto particular en el tiempo. Tambien po-

seen metodos; estos describen las acciones que son capaces de ejecutar los objetos. Los

datos de un objeto unicamente pueden cambiar a traves de sus propios metodos [7]. Lo

antes expuesto es lo que se conoce hoy dıa como el paradigma de programacion orientada

a objeto.

2.4. Softwares de Simulacion.

Destacando el orden de ideas antes expuestas sobre las caracterısticas que deben pre-

sentar los simuladores de sistemas orientados a eventos discretos, es posible pensar que,

cualquier lenguaje de programacion podrıa ser utilizado para simular el comportamiento

de estos sistemas, aunque ello va a depender en alto grado de la estrategia adoptada y de

las virtudes presentadas por el lenguaje seleccionado. Es por ello, que las herramientas


de simulacion actuales ofrecen los modulos necesarios para programar de forma rapida y

habilidosa un modelo. Estas y otras caracterısticas presentes en los diferentes paquetes de

simulacion actuales reducen considerablemente el tiempo de programacion del modelo y

en anadidura el mantenimiento del mismo se ve enormemente simplificado [21].

En virtud de lo anterior, en la rama de la simulacion de sistemas orientados a eventos

discretos, existen los llamados “Lenguajes de Proposito General”, que son los lenguajes

de programacion convencionales (por ejemplo Pascal, Fortran, C++, Python). “Lenguajes

de Simulacion de Proposito General”, al igual que el anterior son lenguajes de programa-

cion, con la distincion que ya poseen modulos programados con caracterısticas especıficas

para la simulacion (por ejemplo GPSS, Simscript, Siman,), que aparecieron a partir de 1960.

“Paquetes de Simulacion de Proposito General”, a parte de poseer modulos especıficos

para simulacion, estos integran capacidades de animaciones para la simulacion e informes

de resultados (informes estandar o especıficos, tabulares o graficos, accesos a muestras

individuales), permiten definir el modelo empleando un dialogo. A pesar de todas estas

ventajas que pueden presentar los paquetes de simulacion, estos poseen un elevado costo

de adquisicion (licencia para su uso). Debido a la gran popularidad que ha tomado la si-

mulacion en el campo empresarial, ciertas corporaciones se han dedicado a la construccion

y mantenimiento de estas herramientas, haciendolas privativas y de difıcil acceso para el

ambito academico.

A pesar que los lenguajes de programacion disponen de librerıas completas para im-

plantar cualquier tipo de modelo (continuo o discreto) por complejo que este sea, requieren

de una gran inversion de tiempo y ademas de un conocimiento exhaustivo por parte del

analista (modelador) sobre el lenguaje empleado. Por su parte, los lenguajes y paquetes de

simulacion tienen como objetivo primordial facilitar el uso de la simulacion en la etapa de

programacion del modelo y permiten al analista concentrarse en aspectos especıficos del

sistema. El codigo de estos es modular, facil de leer y proveen herramientas para la depu-

racion de errores, a traves del trazado de sus corridas y experimentos con el modelo [1].


El constante desarrollo que han presentado los lenguajes de simulacion desde su crea-

cion, se caracteriza por la variedad de opciones que muestran, ya que son empleados para

fines especıficos. Entre los mas conocidos se pueden mencionar: General Purpose Simula-

tion System (GPSS desarrollado en por G. Gordon en la IBM en el ano de 1961 [22]), Si-

mulation Analysis (SIMAN, creado a mediados de 1960 por el centro Noruego de Compu-

tacion [23]), SIMULA67 (Creado por los mismos autores de Simula Kristen Nygaard y Ole

Johan Dahl), GLIDER (Creado durante los anos 1991-1996, en la Universidad de los Andes

por IEAC & CESIMO [24]), Simscript II.5 [23] y SLAM [23] por mencionar algunos.

Capıtulo 3

Modelado y Simulacion en SimPy.

En este capıtulo se presentaran de forma detallada, las diferentes estructuras que com-

ponen el paquete de simulacion SimPy, ası como tambien los pasos a seguir en la implan-

tacion de un modelo empleando este paquete.

3.1. Introduccion.

SimPy [5] nace en el ano 2002, bajo las ideas de Simulacion Orientada a Objetos deta-

lladas en el capıtulo anterior, las cuales fueron introducidas por SIMULA en la decada de

los 60. Bajo esta premisa y combinando las ideas de SIMULA y Simscript y empleando el

estandar de Python, el Dr. Klauss Muller (con experiencia en la programacion con Simula)

y Tony Vignaux (Programador de Simscript) crean SimPy .

35

CAPITULO 3. MODELADO Y SIMULACION EN SIMPY. 36

3.2. SimPy.

3.2.1. Concepto.

SimPy [5]1 es un sistema de simulacion de eventos discretos basado en Python. SimPy

usa procesos paralelos para modelar componentes activos tales como mensajes, individuos,

piezas. Proporciona un gran numero de herramientas para el analista del modelo y una in-

terfaz que puede ser manejada en plataformas Windows y en distribuciones GNU/Linux.

Incluye los procesos de las entidades a traves de la creacion de objetos de tipo Proceso

(Process) y tres tipos de objetos recursos: Recursos, Niveles y Almacenes (Resources, Le-

vel and Stores). Ademas, formas de almacenar las estadısticas de la simulacion, usando

Monitor y Tally.

3.2.2. Caracterısticas Generales.

Los elementos basicos de un modelo en SimPy son objetos de tipo proceso (por ejem-

plo, objetos de una clase Process -en el apartado 3.5 se explica en detalle). Estos son retar-

dados por tiempos fijos o aleatorios de acuerdo a las especificaciones del modelo conceptual

y colocados en cola para el uso de algunos de los recursos.

Un script de SimPy contiene la declaracion de una o mas instancias de procesos y la

creacion de una serie de objetos a partir de estos. Cada objeto proceso ejecuta su Metodo

de Ejecucion de Proceso (PEM: Process Execution Method, -este sera tratado en detalle

en el apartado 3.6 de este mismo capıtulo). Cada PEM se ejecuta en paralelo invocando

las diferentes rutinas de los subprocesos y, ademas puede interactuar con varios PEM de

otros objetos de tipo Process. En lo sucesivo se empleara el acronimo PEM para indicar las

1 El texto es una traduccion libre de la version en ingles de http://simpy.sourceforge.net/


actividades de las entidades dentro de los sistemas a modelar.

El paquete esta formado por un conjunto de modulos escritos en python, los cuales se

mencionan a continuacion:

1. Simulation: Es el Modulo que tiene implementada las definiciones de las clases y

metodos para los objetos Process (Procesos) y Resources (Recursos), empleados en

los modelos de simulacion.

2. Monitor: Modulo para la compatibilidad de versiones anteriores a SimPy (por ejem-

plo la version 1.7.1 con la 1.6).

3. SimulationTrace: Modulo que implementa las trazas para los eventos.

4. SimulationRT: Modulo para controlar la velocidad de la Simulacion a traves de la

sincronizacion de los eventos.

5. SimulationStep: Modulo para realizar la Simulacion paso a paso a traves del segui-

miento de los eventos

6. SimPlot: Modulo que permite realizar graficas de estadısticas durante la simulacion.

Esta basado en la librerıas Tk/Tkinter.

7. SimGui: Este Modulo provee las herramientas para implementar el modelo de si-

mulacion con interfaces graficas de usuario (GUI). Al igual que el modulo SimPlot,

SimGUI esta basado en las librerıas Tk/Tkinter.

8. Lister: Modulo empleado para darle un mejor formato de impresion a los objetos

SimPy empleados por el modelo.


3.3. Desarrollo de un programa de Simulacion en SimPy.

Este apartado describe los pasos y la estructura para describir un programa de simula-

cion en SimPy. Las ideas aquı planteadas han sido tomadas, principalmente, del capıtulo 3

del trabajo del Dr. Klauss Muller [27].

3.3.1. Estructura basica de un programa en SimPy.

Para implementar un modelo de simulacion en SimPy, el usuario tiene que programar

en Python los siguientes pasos observando el marco de referencia de SimPy:

1. Importar la librerıa de Simulacion de SimPy.

2. Definir al menos una clase de componentes activos de Simulacion (Procesos).

3. Formular un modelo, el cual:

a) Inicializa la maquinaria del tiempo de ejecucion de SimPy (Efectivamente, el

manejador de eventos).

b) Genera al menos una o mas instancias de estas clases de componentes activos.

c) Activa estas instancias.

d) Inicializa la coleccion de datos.

e) Comienza la ejecucion de la Simulacion.

4. Definir los valores de datos, para el experimento de Simulacion.

5. Ejecutar el experimento.

6. Analizar los datos recolectados.


7. Mostar la salida de los resultados

Esto se entendera en una estructura de programa SimPy tal como sigue:

import SimPy.Simulation as Sim (1)

# #Componentes del modelo

class MyProcess(Sim.Process): (2)

def myPEM(self):

yield hold,self,myDuration

# # Modelo

def model(): (3)

Sim.initialize() (4)

p=MyProcess() (5)

Sim.activate(p,p.myPEM(),at=tFirst) (6)

results=Sim.Monitor() (7)

Sim.simulate(until=endtime) (8)

return results

# # Datos del Experimento (9)

tFirst=100

myDuration=10

endtime=1234

# Experimento

outcome=model() (10)

# Analisis

answer=outcome.mean() (11)

# Salida

print ‘‘Result is: %s"\%answer (12)

Es de hacer notar que para el desarrollo de un programa de Simulacion en SimPy, es

muy util tener la estructura anterior de seis secciones en el desarrollo de los modelos. Estas

secciones son:


1. Componentes del modelo.

2. Modelo.

3. Datos del Experimento.

4. Experimento.

5. Analisis.

6. Salidas.

Esta estructura se empleara para el conjunto de modelos de ejemplo a ser desarrollados

en el capıtulo 4.

Si un programa de Simulacion tiene corridas de modelos (es decir experimentos), utili-

zando varios conjuntos de datos, las ultimas cuatros secciones deben repetirse tantas veces

como conjuntos de datos haya.

Es de hacer notar que esta estructura de seis secciones ayudara a plantear los modelos

a desarrollar.

Es altamente recomendable mantener la funcion model (modelo) libre de datos y sola-

mente utilizar variables a las cuales seran asignadas sus valores por un conjunto de datos del

experimento. Esto mantiene al modelo general y permite que sea utilizado para cualquier

numero de experimentos (es decir corridas de Simulacion) basados en diferentes conjuntos

de datos del experimento.

Similarmente, todos los componentes del modelo deben mantenerse libre de datos uti-

lizando variables, las cuales obtendran sus valores a partir de los datos del experimento

directamente o por el envıo de sus parametros a la funcion model.


Los objetos denotados por Sim son suministrados por el modulo SimPy.Simulation.

Estos objetos dan al usuario del programa las siguientes capacidades:

Por herencia de Sim.Process, las instancias de la clase MyProcess se pueden con-

vertir en componentes activos para los cuales se puedan definir o colocar en horario

eventos. El PEM con nombre myPEM define su ciclo de vida.

Sim.initialize inicializa la maquinarıa del tiempo de ejecucion (o corrida) de la simu-

lacion. Inicializa una lista de eventos y coloca el tiempo inicial de la simulacion en

0.

La llamada Sim.activate define un evento inicial para la entidad p de MyProcess en

el tiempo tFirst.

La llamada Sim.simulate ejecuta todos los eventos que estan en la lista de eventos en

una secuencia temporal hasta que no hayan mas eventos en la lista de eventos o hasta

que el reloj de la simulacion haya alcanzado endTime su tiempo final.

SimPy.Simulation, es solo uno de los cuatro modulos de la librerıa de simulacion que

dispone SimPy. Se utiliza en la mayorıa de los casos. Otros modulos alternativos de simu-

lacion que estan disponibles son:

SimPy.SimulationTrace.

Que provee todas las capacidades de Simulacion de SimPy mas la caracterıstica de

traza de la ejecucion. Esta orientado principalmente a la introspeccion de modelos,

para depurarlos y para propositos de ensenanza o documentacion.

SimPy.SimulationStep.

Todas las posibilidades de Simulacion de SimPy, mas la capacidad de ejecutar un

modelo evento por evento. Esto es util por ejemplo, en simulaciones interactivas con

una persona que este interactuando con el modelo.


SimPy.SimulationRT.

Tiene todas las capacidades de Simulacion de SimPy, mas la capacidad de sincro-

nizar el tiempo de Simulacion con el tiempo de reloj de pared (esto significa hacer

simulaciones en tiempo real). Esto es util por ejemplo, para implementar modelos de

sistemas fısicos donde el usuario de la simulacion quiere ganar vision acerca de los

tiempos de los eventos o el comportamiento dinamico de un sistema modelado.

Solo una de estas cuatro librerıas disponibles, puede ser invocada dentro de un script de

SimPy.

El nuevo usuario de SimPy debe siempre importar las facilidades de simulacion de

SimPy por medio de la sentencia SimPy.Simulation as (nombre) por ejemplo importar

SimPy.Simulation as Sim. En el modelo, esto identifica totalmente todos los objetos im-

portados. Por ejemplo Sim.Process, o Sim.hold. Esto muestra, rapidamente, que su cons-

truccion viene de la librerıa de SimPy y ademas proteje de la sobrecarga accidental con los

objetos propios del usuario. En etapas posteriores, cuando el usuario este mas familiarizado

con SimPy, la cantidad de escritura puede ser reducida empleando: from SimPy.Simulation

import * y escribiendo Process o hold.

3.3.2. Enfoque para la implantacion de un Modelo en SimPy.

Es altamente recomendable emplear un diseno interactivo incremental (tambien llama-

do “construir un poco”, “ejecutar un poco”, “aprendiendo mucho”).

El diseno del programa deberıa arrancar con un escenario que describa la situacion a

ser simulada. En este escenario se deben identificar los actores, sus acciones y los recursos

que ellos necesitan. En el diseno, se deben escribir los ciclos de vida de los actores. Mas

importante aun, se deben definir cuales son los resultados que se desean obtener de la


Simulacion.

Al lograr una comprension del modelo conceptual a traves de un analisis del mismo,

se debe comenzar a implementar el codigo, empleando comentarios que expresen lo que

hacen las diferentes sentencias (se debe recordar emplear el enfoque de las seis secciones

discutido previamente).

En la primera etapa del desarrollo se recomienda utilizar SimPy.SimulationTrace en lu-

gar de SimPy.Simulation, esto permite hacer trazas de la simulacion y ademas ganar vision

de como los procesos, eventos e interacciones estan funcionando dentro de los comandos

de SimPy.

Para realizar validaciones dentro del programa SimPy que aseguren sincronizaciones

entre multiples procesos paralelos se utiliza la sentencia assert de Python (ver el modelo

de visita al banco de la seccion 3.3.3).

3.3.3. Construyendo el primer modelo en SimPy.

En este apartado se emplea un escenario sencillo “La Visita al banco”, el cual se des-

cribe a continuacion:

“Un banco abre una nueva oficina e invita al publico a un dıa de apertura. Los visi-

tantes llegan, son bienvenidos por el gerente de la oficina uno a uno y pueden observar las

cosas nuevas que hay en el banco. Luego ellos se van.

Para obtener alguna idea de la situacion, se seguiran los eventos que le ocurren a tres

visitantes (entidades Tony, Klaus y Simon) que arriban en los tiempos 0, 0.5 y 1 minuto

despues de abrir respectivamente. El gerente de la oficina gasta exactamente un minuto

con cada visitante. Y un visitante se pasea por las oficinas del banco en un tiempo de 10


minutos aproximadamente.”

Una vez descrito el escenario del modelo conceptual, se debe plantear el objetivo de la

simulacion: ¿En que tiempo dejan las instalaciones del banco los 3 visitantes?

A continuacion se realiza un breve analisis del modelo conceptual identificando los

actores, los ciclos de vida de las entidades, los datos del escenario y las decisiones a tomar

para el diseno del programa. Este analisis se describe a continuacion:

Actores.

Visitante Tony.

Visitante Klaus.

Visitante Simon.

Gerente del banco.

Ciclos de vida para las entidades.

Llegadas.

Tratar de encontrar libre al recurso gerente (gerente del banco), esperar en una cola

si no esta disponible.

Ponerse en conversacion con el gerente (de forma que este pasa a estar ocupado).

Hablar con el gerente por un minuto.

Liberar al gerente (para que pueda atender a otra persona)

Darse una vuelta por el banco en 10 minutos.


Salir

Datos del escenario.

Tiempos de llegada: Tony tempo 0, Klaus tiempo 0.5, Simon tiempo 1.0 (todos en

minutos).

Tiempo de conversacion: 1 minuto.

Tiempo de observar las instalaciones del banco: 10 minutos.

Decisiones de diseno para el programa.

Dado que todos los visitantes son componentes activos se modelaran como entidades.

Puesto que las tres entidades visitantes tienen el mismo ciclo de vida y solo difieren

en sus atributos (nombre, tiempo de llegada) se modelaran como instancias de una

clase Visitor, con un metodo o proceso de ejecucion de nombre visit.

El gerente del banco no tiene realmente un ciclo de vida. Los visitantes hacen que

este ocupado y/o no ocupado. Puede ser modelado como una entidad, pero es mas

facil y suficiente modelarlo como una estructura de datos es decir como instancia de

una clase Manager (Gerente).

Una vez que se haya analizado en detalle el modelo conceptual, se realiza una primera

implantacion en SimPy, la cual se presenta a continuacion:


1 """bank-v0.py"""

2 import SimPy.SimulationTrace as Sim

3 ##Componentes del modelo

4 class Visitor(Sim.Process):

5 def visit(self,bank):

6 pass

7 # intentar obtener libre al gerente, esperar sino esta disponible

8 # colocar al gerente ocupado

9 # hablar con el gerente

10 # liberar al gerente para otros visitantes

11 # observar las oficinas

12 # salir

13 class Manager: pass

14 class Bank: pass

15 ## Modelo

16 def model():

17 Sim.initialize()

18 myBank=Bank()

19 myBank.manager=Manager()

20 for visname,arrivaltime in visitorlist:

21 vis=Visitor(name=visname)

22 Sim.activate(vis,vis.visit(bank=myBank),at=arrivaltime)

23 Sim.simulate(until=simtime)

24 ## Datos del experimento

25 visitorlist=[("Tony",0),("Klaus",0.5),("Simon",1.0)]

26 tChat=1; tLook=10

27 simtime=100

28 ## Experimento

29 model()

30 ## Analisis y Salidas

31 print "All visitors gone at time %s"%Sim.now()

Al ejecutar el programa se obtiene:


Traceback (most recent call last):

File "bank_v0.py", line 29, in ?

model()

File "bank_v0.py", line 22, in model

Sim.activate(vis,vis.visit(bank=myBank),at=arrivaltime)

File "C:\Python23\lib\site-packages\SimPy\SimulationTrace.py",line

359, in activate

raise Simerror("Fatal SimPy error: activating function which"+

SimPy.SimulationTrace.Simerror: "Fatal SimPy error: activating

function which is not a generator (contains no ’yield’)")

Este mensaje de error indica que en la funcion visit se debe tener implantado un PEM,

a traves de sentencias yield, las cuales son sentencias generadoras de Python y la principal

caracterıstica de SimPy (mas adelante se explica cada uno de los estados yield empleados

por SimPy). Sin esto el modulo SimPy.SimulationTrace reporta un error como el antes

senalado.

En vista de lo anterior se ejecuta la activacion de cada una de las sentencias del ciclo

de vida (PEM) para las entidades (visitantes) del ejemplo. Estas sentencias son las lıneas

comentadas dentro del metodo visit perteneciente a la clase Visitor. A continuacion se rea-

liza la activacion de los estados, hablar con el gerente y darse una vuelta por el banco las

cuales comienzan justo detras de las lıneas (9 y 11). Hecho lo anterior se evalua una condi-

cion, la cual tiene que ser verdadera al final de la simulacion: El numero de visitantes que

tienen completos los ciclos de vida, debe ser igual que el numero generado y activado, esto

se consigue anadiendo un atributo de nombre nrDone a la clase Visitor, el cual incrementa

su valor al final del PEM, obteniendo de esta manera el siguiente codigo:


32 """bank_v1.py"""

33 import SimPy.SimulationTrace as Sim

34 ##COmponentes del Modelo

35 class Visitor(Sim.Process):

36 nrDone=0

37 def visit(self,bank):

38 # intentar obtener libre al gerente, esperar sino esta disponible

39 # colocar al gerente ocupado

40 # hablar con el gerente

41 yield Sim.hold,self,tChat

42 # liberar al gerente para otros visitantes

43 # observar las oficinas

44 yield Sim.hold,self,tLook

45 # salir

46 Visitor.nrDone+=1

47 class Manager: pass

48 class Bank: pass

49 ## Modelo

50 def model():

51 Sim.initialize()

52 myBank=Bank()

53 for visname,arrivaltime in visitorlist:

54 vis=Visitor(name=visname)

55 Sim.activate(vis,vis.visit(bank=myBank),at=arrivaltime)

56 Sim.simulate(until=simtime)

57 assert Visitor.nrDone==len(visitorlist),\

58 "wrong nr of visitors are done"

59 ## Datos del experimento

60 visitorlist=[("Tony",0),("Klaus",0.5),("Simon",1.0)]

61 tChat=1; tLook=10

62 simtime=100

63 ## Experimento

64 model()

65 ## Analisis y salidas


66 print "All visitors gone at time %s"%Sim.now()

Las modificaciones hechas son las que corresponden a las lıneas [36,41,44,46] de lafuncion Visit y [57,58] de la funcion modelo. Ejecutando ahora esta version se obtiene:

0 hold <Tony> delay: 1

0.5 hold <Klaus> delay: 1

1.0 hold <Simon> delay: 1

1.0 hold <Tony> delay: 10



11.0 <Tony> terminated

11.5 <Klaus> terminated

12.0 <Simon> terminated

All visitors gone at time 12.0

A pesar de que el programa corre, no hace lo que se esta buscando. Se puede observar

que el error consiste en que las tres entidades estan utilizando el recurso simultaneamente,

es decir Tony, Klaus y Simon estan hablando con el gerente al mismo tiempo. Esto se

corrige anadiendo un atributo a la clase Manager, de nombre nrTalking, el cual indica el

numero de visitante con los que el gerente puede hablar a la vez, este se inicializa a cero,

incrementando su valor al comienzo de la fase de conversacion y se decrementa al final de

esta.

Ahora la version del programa es la siguiente:

"""bank_v3.py"""

import SimPy.SimulationTrace as Sim

## Model components

class Visitor(Sim.Process):


nrDone=0

def visit(self,bank):

# intentar obtener libre al gerente, esperar sino esta disponible

# colocar al gerente ocupado

bank.manager.nrTalking+=1

assert bank.manager.nrTalking==1,\

"At %s: Manager is talking to more than one visitor"%Sim.now()

# hablar con el gerente

yield Sim.hold,self,tChat

# liberar al gerente para otros visitantes

bank.manager.nrTalking-=1

# observar las oficinas

yield Sim.hold,self,tLook

# salir

Visitor.nrDone+=1

class Manager:

def __init__(self):

self.nrTalking=0

class Bank: pass

## Model

def model():

Sim.initialize()

myBank=Bank()

myBank.manager=Manager()

for visname,arrivaltime in visitorlist:

vis=Visitor(name=visname)


Sim.simulate(until=simtime)

assert Visitor.nrDone==len(visitorlist),"wrong nr of visitors are done %s"%Visitor.nrDone

## Experiment data

visitorlist=[("Tony",0),("Klaus",0.5),("Simon",1.0)]

tChat=1; tLook=10

simtime=100

## Experiment


model()

## Analysis/output

print "All visitors gone at time %s"%Sim.now()

Ejecutando se obtiene:


Traceback (most recent call last):

File "bank_v3.py", line 39, in ?

model()

File "bank_v3.py", line 32, in model


File "C:\Python23\lib\site-packages\SimPy\SimulationTrace.py", line

1484, in simulate

a=_e._nextev()

File "C:\Python23\lib\site-packages\SimPy\SimulationTrace.py", line

336, in _nextev

tt=tempev.who._nextpoint.next()

File "bank_v3.py", line 10, in visit


AssertionError: At 0.5: Manager is talking to more than one visitor

Tal como lo indica el error, hay mas de un visitante hablando con el gerente al mismo

tiempo, esto en simulacion es lo que llaman sincronizacion de actividades para que no se

solapen. Corrigiendo este error se obtiene:


"""bank_v5.py"""


## Model components


nrDone=0



if bank.manager.nrTalking>0:

bank.manager.visitorQ.append(self)

yield Sim.passivate,self


ank.manager.nrTalking+=1






bank.manager.nrTalking-=1

# continua el primer visitantes hablando?

if len(bank.manager.visitorQ)>0:

nextVisitor=bank.manager.visitorQ.pop(0)

Sim.reactivate(nextVisitor)



# salir

Visitor.nrDone+=1

class Manager:

def __init__(self):

self.nrTalking=0

self.visitorQ=[]

class Bank: pass

## Model

def model():

Sim.initialize()


myBank=Bank()

myBank.manager=Manager()





assert Visitor.nrDone==len(visitorlist),"wrong nr of visitors are done"

## Experiment data


tChat=1; tLook=10

simtime=100

## Experiment

model()

## Analysis/output


Como se especıfica en el codigo anterior, para establecer la sincronizacion de las ac-tividades en las entidades se establece una decision la cual indica si el recurso esta o nodisponible. En el caso de que no este disponible el recurso, se agrega en una cola la entidada la espera de que el recurso sea liberado. Ejecutando la version corregida del programa seobtiene:


0.5 passivate <Klaus>

1.0 passivate <Simon>

1.0 hold <Tony> delay: 10





11.0 <Tony> terminated

12.0 <Klaus> terminated

13.0 <Simon> terminated


Con la correccion hecha, el programa sı hace lo que se plantea en el modelo concep-

tual. Para la correccion de este error, se emplearon herramientas propias de la programacion

orientada a objetos, como se explico previamente. Es de hacer notar que para hacer esto, el

usuario debe tener alguna experiencia previa en el ejercicio de la programacion. Ahora em-

pleando herramientas propias del paquete SimPy, es mas sencillo establecer sincronizacion

entre los procesos internos de cada actividad.

Estas estructuras de sincronizacion entre el uso de un recurso y la disponibilidad paraese tiempo es un problema tıpico en la simulacion de eventos discretos. Es por ello queSimPy posee unas estructuras de nivel superior, como la clase recurso (mas adelante en estecapıtulo se explicaran en detalle) con dos comandos de sincronizacion: yield requesty yield release. Los cuales hacen la peticion de un recurso y la liberacion del mismo.Haciendo uso de lo anterior, el programa quedarıa estructurado como sigue:

"""bank_highlevel.py"""


## Model components


nrDone=0




yield Sim.request,self,bank.manager

assert len(bank.manager.activeQ)==1,\





# continue first waiting visitor

yield Sim.release,self,bank.manager



# salir


Visitor.nrDone+=1

class Bank: pass

## Model

def model():

Sim.initialize()

myBank=Bank()

myBank.manager=Sim.Resource(name="Managers",capacity=1)





assert Visitor.nrDone==len(visitorlist),"wrong nr of visitors are done"

## Experiment data


tChat=1; tLook=10

simtime=100

## Experiment

model()

## Analysis/output


Una vez conocida la estructura basica de un programa en SimPy y el enfoque de desa-

rrollo, en las siguientes subsecciones se explicara en detalle el uso de las estructuras de

nivel superior de SimPy las cuales son: Process, Resource, Level, Store, Monitor y Tally

respectivamente.

3.4. Proceso (Process).

Los Procesos en SimPy son objetos de la clase Process, estos se emplean en todas las

simulaciones para modelar el flujo de entidades dentro del sistema. En los programas se


pueden definir tantos objetos Process como lo requiera el modelo a simular. En cada uno

de estos procesos se debe tener definido un PEM:

PEM (Process Execution Method): Por lo general son funciones dentro de la defi-

nicion de un objeto de tipo Proceso, las cuales definen las acciones que pueden ser

llevadas a cabo por los objetos de tipo Proceso. Cada PEM a su vez debe contener una

serie de comandos (estados) yield con sus distintas capacidades (request, hold, relea-

se, put, get por mencionar algunas). Cada PEM inicia su ejecucion tan pronto como

el objeto de tipo procesos, haya sido activado y el comando simulate(until=endtime)

ejecutado.

3.4.1. Definicion de un Proceso.

Para definir un objeto proceso se emplea uno de los constructos de la Programacion

Orientada a Objeto como es la herencia. Obteniendo ası lo siguiente:

class nombre_entidad(Process):

Cada definicion de un proceso debe tener un metodo PEM asociado y un metodo

__init__(p1,p2,p3, ...pn)

En este ultimo se pueden anadir atributos y a su vez recibir una serie de parametros p,

donde el numero de estos va a depender del planteamiento adoptado por el analista.


3.4.2. Comienzo y parada de un Proceso.

Una vez definido el proceso, se debe activar para comenzar la simulacion a traves del

comando:

activate(p,p.PEM(arg,at=t,delay=period,prior=False))

Donde p es una instancia del Proceso. Ademas los argumentos que recibe el metodo

PEM son: arg conjunto de parametros empleados en la definicion del PEM, at es el

perıodo de veces que se activara p, delay es el retardo en la ejecucion del proceso y prior

es la prioridad de ejecucion.

Luego que se ha activado un proceso, este se puede parar, colocar en estado pasivo

o cancelar en caso de ser necesario, a traves de los siguientes comandos:

yield passivate,self, suspende la actividad del objeto sobre el cual se invoca.

Colocandolo en un estado pasivo.

reactivate(p,at=t, delay=period, prior=False), reactiva el objeto p. Colo-

ca el estado del objeto en activo. Los parametros opcionales funcionan de la misma forma

que para activate.

self.cancel(p), borra todos los eventos futuros programados para el objeto de pro-

ceso p.

Vale la pena acotar que aun cuando los objetos de tipo Proceso esten activos, los mismos

no comenzaran a operar hasta que la frase simulate(until=t) se ejecuta. Este comando

inicia la simulacion y avanza el reloj de simulacion hasta el evento mas proximo a ocurrir.


3.4.3. Avance del tiempo durante la ejecucion de un Proceso.

Los metodos PEM de cada proceso emplean el comando yield hold para retardar

temporalmente las operaciones del mismo, por ejemplo : yield hold, self, t, causa

que el objeto sobre el cual se invoca sea retardado t unidades de tiempo. Luego de este

retardo continuan las operaciones especificadas a continuacion en el PEM. Durante este

retardo las actividades del objeto proceso son suspendidas.

3.4.4. Ejemplo de la definicion de un Proceso.

El ejemplo presentado a continuacion emula la llegada de 10 peatones a un semaforo

para cruzar la calle luego de esperar el cambio de luz por 10 minutos:

from SimPy.Simulation import *

class Peaton(Process):

def ejecucion(self):

print now(), "Llega el primer peaton"

for i in range(10):

yield hold,self,1.0

print now(), "Llega otro peaton"

yield hold,self,10.0

print ‘‘\n", now(), "Cruzan los peatones"

initialize()

f = Peaton()

activate(f, f.ejecucion(), at=0.0)

simulate(until=100)

Salida de la ejecucion del programa:


0 Llega el primer peaton

1.0 Llega otro peaton










20.0 Cruzan los peatones

3.5. Manejo de Sincronizaciones en SimPy.

La nocion de sincronizacion fue tratada en el capıtulo 2, la idea es que hay actividades

durante la ejecucion de un modelo que requieren de la culminacion o del comienzo de

otras. Ademas, algunas aplicaciones necesitan activar ciertas actividades cuando ocurren

ciertas condiciones. Debido a ello, SimPy posee un comando que ayuda a solucionar este

inconveniente limpiamente, este es wait until el cual se explicara a continuacion a traves

de los objetos SimEvent.

3.5.1. Definiendo un SimEvent.

SimPy emplea un objeto del tipo SimEvent2 , para senalar los eventos durante la simu-

lacion, estos se definen como:2 SimEvent fue escogido como nombre ya que la palabra Event es usada por el lenguaje Python


sE = SimEvent(name=‘a SimEvent’),

Donde el parametro name=‘a SimEvent’, es el valor por defecto, el cual puede cam-

biar de nombre.

Este objeto a su vez, posee los siguientes atributos:

sE.occurred, es un valor booleano, el cual se emplea para indicar la ocurrencia de

un evento (el valor por defecto es False).

sE.waits, este es una lista de eventos en espera por la ocurrencia de un evento.

sE.queues, Cola de procesos en espera por eventos (el orden es FIFO).

sE.signalparam, es un atributo util para el metodo signal

3.5.2. Esperando en cola por un SimEvent.

Para colocar procesos en cola a la espera de la ocurrencia de un evento se emplea el

comando:

yield waitevent,self,<events part>

Donde el parametro en parentesis angulares puede ser:

Cualquier variable por ejemplo, mievento.

Una Tupla por ejemplo (evento1, evento2)

Una lista de eventos por ejemplo [evento1, evento2]


Si ninguno de los eventos en los events part ha ocurrido, el proceso entra en estado

pasivo y este se une a la lista de procesos en cola, a la espera de la ocurrencia de uno de los

eventos que se especifican haciendo uso de una de las estructuras antes mencionadas.

3.5.3. Esperando una senal para un SimEvent.

Para activar un objeto SimEvent a traves de una senal que indique la ocurrencia de un

evento se realiza a traves del comando:

sE.signal(<payload parameter>)

Al igual que los metodos anteriores, el parametro de carga (‘payload parameter’)

es opcional y ademas se puede emplear un tipo cualquiera.

3.5.4. Ejemplo de Sincronizacion.

A continuacion se presenta un programa completo, que ilustra los constructos antescitados.


class Waiter(Process):

def waiting(self,myEvent):

yield waitevent,self,myEvent

print ’%s: despues de esperar, el evento %s ha ocurrido’\

%(now( ),myEvent.name)

class Queuer(Process):

def queueing(self,myEvent):

yield queueevent,self,myEvent


print ’%s: despues de esperar, el evento %s ha ocurrido’\

%(now( ),myEvent.name)

print ’Solo pruebo que: event(s) %s se disparo’\

%([x.name for x in self.eventsFired])

class Signaller(Process):

def sendSignals(self):

yield hold,self,1

event1.signal( )

yield hold,self,1

event2.signal( )

yield hold,self,1

event1.signal( )

event2.signal( )

initialize( )

event1=SimEvent(’evento1’); event2=SimEvent(’evento2’)

s=Signaller( ); activate(s,s.sendSignals( ))

w0=Waiter( ); activate(w0,w0.waiting(event1))



q1=Queuer( ); activate(q1,q1.queueing(event1))

q2=Queuer( ); activate(q2,q2.queueing(event1))

simulate(until=10)

Cuya salida es la siguiente:

1: despues de esperar, el evento evento1 ha ocurrido



Solo pruebo que: event(s) [’evento1’] se disparo



Solo pruebo que: event(s) [’evento1’] se disparo


3.5.5. Sincronizacion “wait until”, en espera de una condicion.

El comando waituntil hace que el progreso del PEM en un proceso dependa del

estado de la simulacion. Esto es util por ejemplo para la reactivacion de un proceso.

La espera de una condicion para un proceso se debe programar en el PEM del mismo

con el comando:

yield waituntil, self, <cond>

Donde cond es una referencia a una funcion sin argumentos, que retorna un valor boo-

leano el cual indica si el estado o condicion de la simulacion a ser esperado ya ha ocurrido.

3.6. Recurso.(Resources)

A continuacion se describen en detalle las caracterısticas mas resaltantes ofrecidas por

SimPy para los Recursos como son Resources, Level y Store (Recurso, Nivel y Almacen),

junto con sus metodos para la obtencion de estadısticas. Cada modelo que se implanta con

SimPy, tiene un punto de congestion para las entidades (piezas, mensajes, carros, etc.) que

se procesan caracterizado por una cola para la obtencion de un recurso determinado.

Un ejemplo de colocar entidades en una cola de un Resource puede ser una planta

de manufactura en la cual una tarea (modelada como un objeto de proceso) requiere un

trabajo que es realizado por una maquina (modelada como un objeto Resource). Si la

totalidad de las maquinas estan siendo usadas actualmente, la tarea debe esperar en cola

a que alguna se encuentre disponible. Un recurso en SimPy puede tener cierto numero

de unidades identicas. Por ejemplo, cierto numero de unidades de maquinas identicas. Un

proceso obtiene una unidad del recurso (Resource) al requerirlo y cuando ha terminado lo


libera. Un recurso mantiene una lista de objetos de proceso que han sido requeridos pero

no han recibido aun alguna de las unidades de recursos (llamadas las “waitQ´´ o colas de

espera en espanol), y otra lista de los procesos que estan usando actualmente una unidad de

recurso (los activeQ o lista de procesos activos).

3.6.1. Definicion de un Recurso.

Para definir un recurso se procede de la siguiente manera:

r=Resource(capacity=1,

name=’a\_resource’,

unitName=’units’,

qType=FIFO, preemptable=False,

monitored=False,

monitorType=Monitor)

Donde:

capacity, indica la cantidad de recurso con iguales caracterısticas

name, es el nombre que se asigna a un determinado recurso.

unitName, es un nombre descriptivo para una unidad de un recurso

qType, este especifica la disciplina de la cola para el waitQ del recurso; tıpicamente,

este es FIFO (First-in, First-out) que es el valor por definicion.

Preemptable, es un booleano que indica si un recurso es solicitado con prioridad.

monitored, es un booleano (False o True) Si esta fijado en True, entonces la infor-

macion es reunida en base a los tamanos de r de waitQ y activeQ, de lo contrario,

no lo seran.


monitorType, es un objeto de tipo Monitor o Tally, los cuales sanalan el tipo de

seguimiento o registro que se hacen a los recursos .

Los recursos tambien poseen los siguientes atributos:

r.n, el numero de unidades que estan actualmente libres.

r.waitQ, una cola (lista) de procesos que han sido requeridos pero auno no han

recibido una unidad de r, de forma tal que len(r.waitQ) es el numero de objetos

de proceso que estan actualmente en la waitQ de r.

r.activeQ, una cola (lista) de los objetos de proceso que actualmente estan

usando una de las unidades de r, de tal manera que len(r.activeQ) es

el numero de unidades de r que estan actualmente en uso. Ası, por ejem-

plo, r.waitMon.timeaverage() es el numero promedio de procesos en cola

(r.waitQ).

r.actMon, el registro (hecho por un Monitor o un Tally siempre que

monitored==True) de la actividad en r.activeQ.

3.6.2. Solicitando un recurso.

En el modelo, para realizar la peticion de un recurso se hace a traves del comando.

yield request,self,r

Para modelar el tiempo (t) de uso es a traves del comando

yield hold,self,t

Y finalmente para que este sea liberado se debe ejecutar:


yield release,self,r

3.6.3. Ejemplo de un recurso.

El siguiente ejemplo modela un servidor, al cual llegan cuatro clientes.


class Client(Process):

def __init__(self,name):

Process.__init__(self,name)

def getserved(self,servtime,myServer):

print self.name, ’solicitando 1 unidad en el tiempo =’,now()

yield request, self, myServer

yield hold, self, servtime

yield release, self, myServer

print self.name,’efectuado en el tiempo =’,now()

initialize()

server=Resource(capacity=1,monitored=True,monitorType=Monitor)

c1=Client(name=’cliente1’) ; c2=Client(name=’cliente2’)

c3=Client(name=’cliente3’) ; c4=Client(name=’cliente4’)

activate(c1,c1.getserved(servtime=100,myServer=server))




simulate(until=500)

print ’Tiempo promedio de espera:’,server.waitMon.timeAverage()

print ’Numero Promedio de espera:’,server.waitMon.mean()

La salida del programa es la siguiente:

cliente1 solicitando 1 unidad en el tiempo = 0





cliente1 efectuado en el tiempo = 100




Tiempo promedio de espera: 1.5

Numero Promedio de espera: 1.5

El ejemplo anterior muestra el uso de un objeto de tipo Resource con capacidad uno,

el cual es solicitado por cuatro entidades, se observo como se obtiene una de las estadısticas

mas interesantes del modelo, como el tiempo promedio de espera y el numero promedio de

entidades en espera.

3.7. Nivel (Level).

El Nivel (Level)modela la produccion y consumo de un material homogeneo no dife-

renciado. Ası, la cantidad actualmente disponible de material puede ser descrita completa-

mente mediante un numero (real o entero). Los objetos de tipo proceso pueden incrementar

o disminuir la cantidad actual disponible de material de un nivel. Por ejemplo, una esta-

cion de gasolina almacena gasolina en grandes tanques. Los camiones cisterna incrementan

mientras que los carros cuando recargan gasolina disminuyen la cantidad de gasolina en los

tanques de almacenamiento de la estacion.


3.7.1. Definiendo un Nivel.

Para definir un Nivel se emplea la siguiente sentencia:

cB = Level(name=’a_level’, unitName=’units’,

capacity=’unbounded’,

initialBuffered=0,

putQType=FIFO, getQType=FIFO,

monitored=False, monitorType=Monitor,

Donde:

name, es un nombre descriptivo para el objeto de nivel cB

unitName, es un nombre descriptivo para las unidades en las cuales la cantidad de

material en cB es medida

capacity, es la capacidad del objeto de nivel cB.

initialBuffered, es la cantidad inicial de material en el objeto de nivel cB.

putQType, es la disciplina de cola para el productor.

getQType, es la disciplina de cola para el consumidor.

monitored, valor booleano que especifica si se debe o no llevar un registro.

monitorType, es un objeto de tipo Monitor o Tally, los cuales sanalan el tipo de

seguimiento o registro que se hace al nivel.

Los atributos mas importantes son:

cB.amount, es la cantidad actual contenida.


cB.putQ, es la cola de procesos que esperan para anadir cantidades a cB, de manera

que len(cB.putQ) es el numero de procesos que esperan para anadir cantidades.

cB.getQ, es la cola de procesos que esperan para obtener cantidades de cB, de mane-

ra que len(cB.getQ) es el numero de procesos que esperan para obtener cantidades

de material.

cB.monitored, si es verdadero (True) las colas deben ser registradas. En este caso

cB.putQMon, cB.getMon y cB.bufferMon existen.

cB.getQMon, es un registro para cB.getQ

cB.bufferMon, es un registro para cB.amount.

Para colocar y obtener cantidades de un objeto tipo nivel se utilizan los siguientes coman-

dos:

yield get,self,cB,q, para obtener del nivel cB una cantidad q.

yield put,self,cB,r, para colocar r cantidades

3.8. Almacenes (Store).

Los Almacenes modelan la produccion y el consumo de artıculos individuales de cual-

quier tipo. Los objetos de tipo proceso pueden insertar o remover artıculos especıficos de

la lista de artıculos disponible en un Almacen. Por ejemplo, los procedimientos quirurgicos

(tratados como objetos de proceso) requieren listas especıficas de personal y equipo que

pueden ser tratadas como los artıculos disponibles en un tipo de Almacen tal como una

clınica o un hospital.


3.8.1. Definiendo un Almacen.

Para definir un objeto de tipo almacen se utiliza la siguiente sentencia:

sB = Store(name=’a_store’, unitName=’units’,

capacity=’unbounded’,

initialBuffered=None,

putQType=FIFO, getQType=FIFO,

monitored=False, monitorType=Monitor)

Donde los parametros que lo describen tienen la misma descripcion que los niveles.

Los atributos se describen a continuacion:

sB.theBuffer, es una cola (lista) de los artıculos individuales en sB. Esta lista

esta en orden FIFO a menos que el usuario los almacene en un orden particular. Es

de solo lectura y no es directamente cambiable por el usuario.

sB.nrBuffered, es el numero actual de objetos en sB. Este es de solo lectura, y no

directamente cambiable por el usuario.

sB.putQ, es la cola de procesos que esperan para agregar artıculos a sB, de tal ma-

nera que len(sB.putQ) es el numero de procesos que esperan para anadir artıculos.

sB.getQ, es la cola de procesos que esperan para obtener artıculos de sB, de tal ma-

nera que len(sB.getQ) es el numero de procesos que esperan para obtener artıcu-

los.

sB.monitored, se emplea para llevar un registro de las colas para almacenar.

sB.putQMon, es un objeto monitor para observar a sB.put.

sB.getQMon, es un objeto monitor para observar a sB.get.


sB.bufferMon, es un objeto monitor para observar sB.nrBuffered.

3.9. Registrando los resultados de la simulacion.

Los registros son empleados para observar a las variables de interes, y retornar un su-

mario de datos simple, ya sea durante la corrida de simulacion o al culminar esta. Las

simulaciones en SimPy a veces usan objetos de clase Tally y Monitor para este proposi-

to.

Tanto los Tallys como los Monitors usan registros observe para almacenar datos

de una variable. Por ejemplo, se puede usar un objeto Monitor para grabar los tiempos de

espera de una secuencia de compradores, y otro para grabar el numero total de compradores

que hay en una tienda. Los Monitors y los Tallys proporcionan estadısticas elementales

utiles, ya sea solas o al inicio de un analisis estadıstico mas sofisticado.

3.9.1. Definiendo un objeto de tipo Tally y Monitor.

Para definir un objeto Tally:

m=Tally(name=‘a Tally’, ylab=‘y’, tlab=‘t’).

• name es un nombre descriptivo para el objeto Tally (default=‘a Tally’)

• ylab y tlab son etiquetas descriptivas usadas por el paquete SimPlot cuan-

do se grafican datos de los datos grabados, conducen por definicion a ‘y’y ‘t’,

respectivamente.

Definicion de un objeto Monitor:


m=Monitor(name=‘a Monitor’, ylab=‘y’, tlab=‘t’).

• name es un nombre descriptivo para el objeto Monitor (default=‘a Monitor’).

• Ylab y tlab son etiquetas descriptivas usadas por el paquete SimPlot cuan-

do se grafican datos de los datos grabados, conducen por definicion a ‘y’y ‘t’,

respectivamente.

3.9.2. Observando los datos.

Los Tallys y Monitors usan el metodo observe para grabar datos. Aquı y en la si-

guiente seccion, r es o un objeto Tally o un objeto Monitor:

r.observe(y [,t]) graba el valor actual de la variable, y, el tiempo t (o el tiempo

actual, now(), si t esta ausente). Un Monitor mantiene los dos valores como una

sublista [t,y]. Un Tally usa estos valores para actualizar las estadısticas acumuladas.

Para asegurar que los promedios de tiempo son calculados correctamente el metodoobserve deberıa ser llamado inmediatamente luego de un cambio en la variable. Por ejem-plo, si estamos usando un objeto r de tipo Monitor para registrar el numero N de trabajosen un sistema, la secuencia correcta de comandos sobre una llegada es:

N = N+1 \# Primero, incremento el numero de trabajos

r.observe(N) \# ENTONCES observe el nuevo valor de N usado por r

3.9.3. Sumario de datos

Los siguientes sumarios de datos pueden ser obtenidos tanto de Monitors como de

Tallys en cualquier momento durante o luego de la corrida de simulacion.


r.count( ), el numero total de observaciones. (Si r es un Monitor este es el mismo

que len(r)).

r.total(), la suma de los valores de y.

r.mean(), el promedio simple de los valores observados de y, que ignora los tiempos

a los cuales estos fueron observados.

3.10. Graficando los Resultados.

Para realizar graficos de las variables de interes en los modelos de simulacion, SimPy

ofrece una extension de nombre SimPlot para facilitar esta tarea.

SimPlot es una extension para realizar graficas de los datos del modelo, esta basada en

las librerıas Tk/Tkinter de Python.

Para usar esta extension y trazar graficos en los modelos, se deben seguir los siguientes

pasos:

1. Importar en la cabecera del programa SimPy el modulo a traves de la sentencia:

from SimPy.SimPlot import

2. Instanciar un objeto de tipo SimPlot.

3. Llamar a uno de los metodos para el trazado del tipo de grafica.

4. Llamar al metodo mainloop sobre el objeto SimPlot antes creado

El siguiente ejemplo muestra el uso y el despliegue de graficos en programas SimPy.



from SimPy.SimPlot import *

class Source(Process):

def __init__(self,monitor):

Process.__init__(self)

self.moni=monitor

self.arrived=0

def arrivalGenerator(self):

while True:

yield hold,self,uniform(0,20)

self.arrived+=1

self.moni.observe(self.arrived)

initialize()

moni=Monitor(name="LLegadas",ylab="Nllegadas")

s=Source(moni)

activate(s,s.arrivalGenerator())

simulate(until=100)

plt=SimPlot()

plt.plotStep(moni,color=’blue’)

plt.mainloop()

Al ejecutar el script se obtiene:


Figura 3.1: Grafico Generado por el modulo SimPlot.

Capıtulo 4

Ejemplos de muestra.

Este capıtulo tiene el objetivo de mostrar un conjunto de modelos los cuales parten

desde casos sencillos, pasando por los de complejidad intermedia hasta llegar a los de cierta

dificultad. Estos se caracterizan por presentar factores de bloqueos (congestiones en las

colas), eleccion por prioridad de las entidades para un recurso determinado, sincronizacion

de actividades, en fin un conjunto de caracterısticas particulares que se presentan a la hora

de modelizar un sistema.

Los siguientes cinco modelos presentados, se plantearan enfocandose en la estrategia

de interaccion de procesos, explicada en el capıtulo 2, basandonos en el escenario (modelo

conceptual) de cada uno junto a un pequeno analisis.

Con la finalidad de mostrar al lector que SimPy es capaz de enfrentar las exigencias

de modelado y simulacion que plantean estos modelos de igual forma que lo hacen pa-

quetes similares y de conocida reputacion tales como Arena 5.0 y Glider 5, se presenta

esta comparacion no detallada entre los tres paquetes mencionados, es decir, mostrar que

empleando el Lenguaje de Simulacion SimPy se pueden modelar Sistemas tan complejos

como se hecen en los paquetes de Simulacion mencionados previamente. No se pretende

en ningun momento comparar los paquetes en cuanto a sus bondades y/o deficiencias para

76

CAPITULO 4. EJEMPLOS DE MUESTRA. 77

el modelado y simulacion o en cuanto a la “calidad de los resultados”de las simulaciones

ejecutadas. La razon ultima de la eleccion de estos paquetes para la comparacion ha sido

que los mismos son, en la actualidad, los paquetes que se emplean en la Escuela de Inge-

nierıa de Sistemas para el dictado de los diversos cursos en los que se hace modelado y

simulacion.

4.1. Modelos.

4.1.1. Modelo de una Panaderıa.

Modelo Conceptual.

La panaderıa Patisserie Francaise tiene en 3 hornos cocinando sus famosos baguettes

para ventas al menor y duenos de restaurant. Ellos comienzan a hornear una hora antes

de abrir y culminan a la hora de cerrar. Hornean en lotes de 40 panes a la vez en cada

horno, tomando para ello entre [25,30] minutos por lote (distribuidos uniformemente). Los

clientes llegan a razon de 40 clientes/hora (distribuidos exponencialmente). Ellos compran

1, 2 o 3 baguettes con igual probabilidad. Los duenos de restaurant llegan a razon de 4

por hora (distribuidos exponencialmente). Ellos compran 20, 40 o 60 baguettes con igual

probabilidad. Simular esta operacion por 100 dıas durante 8 horas de jornada laboral.

¿Cual seria el tiempo medio de espera para los clientes normales y duenos de restau-

rant?

¿Cual es su maximo tiempo de espera?

¿Que porcentaje de clientes tienen que esperar por mas de 15 minutos?

¿Grafique el numero de baguettes sobre tiempo en un dıa cualquiera.


Componentes del Modelo.

Entidades Temporales y Recursos: Las entidades temporales son los panes tipo ba-

guettes los cuales son horneados en lotes de 40 panes, los clientes al detal y duenos

de restaurant que efectuan las compras. Los recursos son los hornos presentes en la

panaderıa para cocinar (proceso) los baguettes.

Actividades: Las actividades que se efectuan en el sistema estan definidas por el

proceso de horneado de los panes tipo baguettes y las compras de los dos tipos de

clientes. Modelo en SimPy. Es importante senalar que para realizar los modelos y las

simulaciones en SimPy, se uso el enfoque de seis secciones presentado en el capıtulo

anterior.

Modelo en SimPy


from SimPy.SimPlot import *

import random

## Componentes del Modelo

class Panaderia: #Entidad Panaderia

def __init__(self,Nhornos,toMonitor):

self.inventario=Level(name="baguette en inventario",\

monitored=toMonitor)

for i in range(Nhornos):

hor=Horno()

activate(hor,hor.hornear(capacidad=TamLote,panaderia=self))

class Horno(Process):# Entidad Horno

def hornear(self,capacidad,panaderia):# PEM para el horneado

while now()+Tmax<Tcierre:

yield hold,self,r.uniform(Tmin,Tmax)

yield put,self,panaderia.inventario,capacidad


class Cliente(Process): # Cliente

def Compra(self,TipoCli,panaderia):# PEM para la compra

Tentrada=now()

yield get,self,panaderia.inventario,r.choice(compra[TipoCli])

espera[TipoCli].append(now()-Tentrada)

class GeneroCliente(Process): #generacion de clientes

def generar(self,TipoCli,panaderia):

while True:

yield hold,self,r.expovariate(1.0/Tllegada[TipoCli])

if now()<(TiempoAbrir+Tantes):

c=Cliente(TipoCli)

activate(c,c.Compra(TipoCli,panaderia=panaderia))

## Modelo

def model():

toMonitor=False

initialize()

if dias==(Ndias-1): toMoni=True

else: toMoni=False

b=Panaderia(Nhornos=Nhornos,toMonitor=toMoni)

for Tipo in ["detal","mayor"]:

cg=GeneroCliente()

activate(cg,cg.generar(TipoCli=Tipo,panaderia=b),delay=Tantes)

simulate(until=Tantes+TiempoAbrir)

return b

# Datos del experimento

Nhornos=3

TamLote=40 #nr baguettes

Tmin=25/60.; Tmax=30/60. #horas

Tllegada={"detal":1.0/40,"mayor":1.0/4} #horas

compra={"detal":[1,2,3],"mayor":[20,40,60]} #nr baguettes

TiempoAbrir=8; Tantes=1; Tcierre=Tantes+TiempoAbrir #horas

Ndias=100

r=random.Random(12371)

# Experimento


espera={}

espera["detal"]=[]; espera["mayor"]=[]

for dias in range(Ndias):

panaderia=model()

# Analisis y Salidas

for Tipo in ["detal","mayor"]:

print "\nPromedio de espera para Clientes al %s: %4.2f horas\n"\

%(Tipo,(1.0*sum(espera[Tipo]))/len(espera[Tipo]))

print "La espera mas larga para Clientes al %s: %4.1f horas\n"\

%(Tipo,max(espera[Tipo]))

nrLong=len([1 for x in espera[Tipo] if x>0.25])

nrCust=len(espera[Tipo])

print "Porcentaje de Clientes al %s que tienen que esperar\

por mas de 0.25 horas: %s\n"%(Tipo,100*nrLong/nrCust)

# Graficando los resultados

plt=SimPlot()

plt.plotStep(panaderia.inventario.bufferMon,

title="Numero de baguetts en inventario en un dia cualquiera",\

color="blue")

plt.mainloop() print "Numero de clientes al detal en los 100 dias

que compraron baguettes: ",

len(espera["detal"])

print "Numero de clientes al mayor en los 100 dias que compraron baguettes: ",

len(espera["mayor"])

Una vez corrido y ejecutado el programa en SimPy se obtine la siguiente salida, para

un tiempo de simulacion de 8 horas y 100 replicas.

Promedio de espera para Clientes al detal: 0.0115552339059 horas

La espera mas larga para Clientes al detal: 1.9 horas

Porcentaje de Clientes al detal que tienen que esperar por mas de


0.25 horas: 1

Promedio de espera para Clientes al mayor:0.0339435157269 horas

La espera mas larga para Clientes al mayor: 2.1 horas

Porcentaje de Clientes al mayor que tienen que esperar por mas de

0.25 horas: 4

Figura 4.1: Grafico para el numero de Baguetts (SimPy).


Modelo en Arena.

Figura 4.2: Diagrama del Modelo Panaderıa en Arena.

Resultados en Arena.

Panaderia

Replications: 100 Time Units: Hours

Wait Time

Average

detal 0.00774941

Entity 1 0.00

restaurant 0.02338551

Hold 1.Queue 0.05914929


Las salidas generadas por el paquete Arena se crean automaticamente; pero hacen refe-

rencia a las variables de interes planteadas en el modelo conceptual, por ejemplo, la variable

Wait Time indica los tiempos de espera para los clientes al detal y duenos de restaurant al

igual que Hold 1.Queue indica el tiempo maximo de espera. Cabe destacar que las salidas

generadas por la simulacion efectuada con el paquete SimPy, difiere de las generadas en el

paquete Arena ya que en este ultimo no se pudo generar la variable que mide el porcentaje

de clientes (al detal y duenos de restaurant) con una espera mayor a 15 minutos.

Figura 4.3: Grafico para el numero de Baguetts (Arena).

Modelo en Glider.

MODELO PANADERIA

NETWORK

MENOR (I) CUSTOMER:: {Defino la entidad Cliente Detal}

IF (TIME>(K*480)) THEN BEGIN

IT := 60;

K:=K+1;

END ELSE BEGIN

IT := EXPO(1.5);

TIPO:=1;

COMPRA:=UNIFI(1, 3);


ACT(GRA,0);

SENDTO(CUSTOMER);

END;

MAYOR (I) CUSTOMER :: {Defino la entidad cliente al Mayor}

IF (TIME>(Q*480)) THEN BEGIN

IT := 60;

Q:=Q+1;

END ELSE BEGIN

IT := EXPO(15.0);

TIPO:=2;

COMPRA:=UNIFI(1,3)*20;

ACT(GRA,0);

SENDTO(CUSTOMER);

END;

HORNO1 (I) BAKERY ::

IT := UNIFI(25, 30);

SENDTO(BAKERY);


IT := UNIFI(25, 30);

SENDTO(BAKERY);


IT := UNIFI(25, 30);

SENDTO(BAKERY);

BAKERY (E) :: {Defino la panaderia}

BAGUETTES:=BAGUETTES+40; {Incremento la cantidad de pan}

ACT(GRA,0);

IF EXISTENCIA=FALSE THEN

EXISTENCIA:=TRUE;


CUSTOMER (G) :: {Efectua la compra el cliente}

IF (BAGUETTES<COMPRA) THEN

EXISTENCIA:=FALSE;

IF EXISTENCIA THEN BEGIN

TIEMPO:=TIME-GT;

IF (TIEMPO>TIEMPO_MAX[TIPO]) THEN

TIEMPO_MAX[TIPO]:=TIEMPO;

IF (TIEMPO>15) THEN

ESPERARON_MUCHO:=ESPERARON_MUCHO+1;

TIEMPO_ESPERA[TIPO]:=TIEMPO_ESPERA[TIPO]+TIEMPO;

CLIENTES[TIPO]:=CLIENTES[TIPO]+1;

SENDTO (PAY);

STOPSCAN;

END;

PAY (E) ::

BAGUETTES:=BAGUETTES-COMPRA;

ACT(GRA,0);

STCS(A) ::

TIEMPO_PROM_1:=TIEMPO_ESPERA[1]/CLIENTES[1];

TIEMPO_PROM_2:=TIEMPO_ESPERA[2]/CLIENTES[2];

WRITE(’TIEMPO MEDIO DE ESPERA DE CLIENTES AL DETAL: ’);

WRITE(TIEMPO_PROM_1);

WRITELN(’’);

WRITE(’TIEMPO MEDIO DE ESPERA DE CLIENTES AL MAYOR ’);

WRITE(TIEMPO_PROM_2);

WRITELN(’’);

WRITE(’TIEMPO MAXIMO DE ESPERA DE CLIENTES AL DETAL: ’);

WRITE(TIEMPO_MAX[1]);

WRITELN(’’);

WRITE(’TIEMPO MAXIMO DE ESPERA DE CLIENTES AL MAYOR: ’);

WRITE(TIEMPO_MAX[2]);


WRITELN(’’);

WRITE(’CLIENTES QUE ESPERARON MAS DE 15 MINUTOS: ’);

WRITE(ESPERARON_MUCHO*100/(CLIENTES[1]+CLIENTES[2]));

WRITELN(’’);

PAUSE;

ENDSIMUL;

GRA (A) ::

GRAPH(0,480,BLACK; TIME:6:0,WHITE;

BAGUETTES:6:0,BAGUETTES,0,500,WHITE);

INIT

BAGUETTES:=0;

TIEMPO:=0;

TIEMPO_MAX[1]:=0;

TIEMPO_MAX[2]:=0;

ESPERARON_MUCHO:=0;

TIEMPO_ESPERA[1]:=0;

TIEMPO_ESPERA[2]:=0;

CLIENTES[1]:=0;

CLIENTES[2]:=0;

TIEMPO_PROM_1:=0;

TIEMPO_PROM_2:=0;

EXISTENCIA := TRUE;

Q:=1;

K:=1;

ACT(MENOR,60);

ACT(MAYOR,60);

ACT(HORNO1,0);

ACT(HORNO2,0);

ACT(HORNO3,0);

ACT(STCS,48000);

TITLE := ’MODELO DE PANADERIA’;


DECL

VAR BAGUETTES, ESPERARON_MUCHO, K, Q : INTEGER;

TIEMPO, TIEMPO_PROM_1, TIEMPO_PROM_2 : REAL;

TIEMPO_MAX : ARRAY[1..2] OF REAL;

TIEMPO_ESPERA : ARRAY[1..2] OF REAL;

CLIENTES : ARRAY[1..2] OF INTEGER;

EXISTENCIA : BOOLEAN;

MESSAGES ENTRADA(TIPO, COMPRA: INTEGER);

STATISTICS ALLNODES;

END

Resultados en Glider.

TIEMPO MEDIO DE ESPERA DE CLIENTES AL DETAL:9.06317194009697E-0004

TIEMPO MEDIO DE ESPERA DE CLIENTES AL MAYOR: 0.00000000000000E+0000

TIEMPO MAXIMO DE ESPERA DE CLIENTES AL DETAL: 5.27663130168276E+0000

TIEMPO MAXIMO DE ESPERA DE CLIENTES AL MAYOR: 0.00000000000000E+0000

CLIENTES QUE ESPERARON MAS DE 15 MINUTOS: 0.00000000000000E+0000

Figura 4.4: Grafico para el numero de Baguetts (Glider).


4.1.2. Modelo de Maquinas Inestable.

Modelo Conceptual.

Una vieja e inestable maquina produce widgets. Toma entre 4 y 3 minutos para hacer un

widgets (Distribuido uniformemente). La maquina se deteriora a razon de una vez por hora

(Distribuido exponencialmente). Cuando la maquina se deteriora, el widget actualmente en

produccion tiene que ser desechado. Para reparar la maquina toma un tiempo estimado de

10 minutos (Distribuido Exponencialmente). Simular esta maquina por 100 horas. Sobre el

promedio de 200 modelos en ejecucion para calcular

¿Cuantos widgets son completados?

¿Cuantos tienen que ser desechados a causa de la falla de la maquina?

Componentes del Modelo.

Entidades temporales y recursos: Las entidades temporales son los widgets.

Actividades: El proceso de elaboracion de widgets, bajo las siguientes condiciones:

si la maquina no se dana, widgets procesado y listo, si la maquina falla se desecha el

widgets.

Modelo en SimPy.


import random

# Componentes del modelo

class Maquina(Process):

def __init__(self):



self.desechados=0

self.widgets=0

f=Falla()

activate(f,f.BloqueoMaquina(maquina=self))

self.FallaMaquina=f

def ProcesandoWidgets(self):

while True:

yield hold,self,r.uniform(Tmin,Tmax)

if self.interrupted():

self.desechados+=1

yield hold,self,r.expovariate(1.0/TReparacion)

reactivate(self.FallaMaquina)

else:

self.widgets+=1

class Falla(Process):

def BloqueoMaquina(self,maquina):

while True:

yield hold,self,r.expovariate(1.0/TPromedioFalla)

self.interrupt(maquina)

yield passivate,self

# Modelo

def model():

initialize()

m=Maquina()

activate(m,m.ProcesandoWidgets())

simulate(until=TEjecucion)

return m.desechados,m.widgets

# Datos del experimento

TPromedioFalla=60 # minutos

TReparacion=10 # minutos

Tmin=3; Tmax=4 # minutos

TEjecucion=100*60 # minutos


NReplicas=200

r=random.Random(12345)

# Experimento

CuentaDesechados=Tally(name="Numero de Desechados")

CuentaBuenos=Tally(name="Numero de Widgets")

for run in range(NReplicas):

nrscraps,nrwidgets=model()

CuentaDesechados.observe(y=nrscraps)

CuentaBuenos.observe(y=nrwidgets)

# Analisis/salida

print "En %s horas, promedio: \n\t%s widgets hechos\n\t%s widgets desechados"\

%(TEjecucion/60,CuentaBuenos.mean(),CuentaDesechados.mean())

Resultados en SimPy.

En 100 horas, promedio:

1429.055 widgets hechos

84.935 widgets desechados


Modelo en Arena.

Figura 4.5: Diagrama del Modelo de Maquina Inestable en Arena.


ARENA Simulation Results

Output Summary for 200 Replications

Project:Maquina Inestables Run execution date : 2/ 1/2007

Analyst:Einstein Briceno Model revision date: 2/ 1/2007

OUTPUTS

Identifier Average Half-width Minimum Maximum # Replications

_______________________________________________________________________________

widget bueno.NumberIn 1484.8 4.0181 1423.0 1560.0 200

widget bueno.NumberOut 1484.8 4.0181 1423.0 1560.0 200

widget defectuoso.Numbe 80.820 1.2955 57.000 107.00 200

widget defectuoso.Numbe 80.820 1.2955 57.000 107.00 200

System.NumberOut 1815.5 1.6409 1785.0 1852.0 200

Simulation run time: 0.98 minutes. Simulation run complete.


Modelo en Glider

MAQUINAS INESTABLES

NETWORK

DANYA (I) REPARA ::

ABIERTA:=FALSE;

IT := EXPO(60.0);

REPARA (R) DANYOS::

RELEASE BEGIN

ABIERTA:=TRUE;

SENDTO(DANYOS);

END;

REP:=EXPO(10.0);

REP_TIME:=REP+TIME;

STAY:=REP;

DANYOS (E)::

PROD (I) GOODS, BADS ::

IF ABIERTA THEN BEGIN

IT:=UNIF(3,4);

SENDTO(GOODS);

END ELSE BEGIN

IT:=REP_TIME-TIME;

SENDTO(BADS);

END;

GOODS (E) ::

WIDGET:=WIDGET+1;


ACT(GRA,0);

BADS (E) ::

REJECTED:=REJECTED+1;

ACT(GRA,0);

FIN(A) ::

REJECT_PROM:=200*REJECTED/(WIDGET+REJECTED);

WIDGET_PROM:=200*WIDGET/(WIDGET+REJECTED);

WRITE(’WIDGETS HECHOS:’);

WRITE(WIDGET_PROM);

WRITELN(’’);

WRITE(’WIDGETS DESECHADOS:’);

WRITE(REJECT_PROM);

WRITELN(’’);

PAUSE;

ENDSIMUL;

GRA (A):: GRAPH(0,6000,BLACK; TIME:6:0,WHITE;

WIDGET:6:0,WIDGETS_PRODUCIDOS,0,2000,WHITE;

REJECTED:6:0,WIDGETS_RECHAZADOS,0,2000,YELLOW);

INIT

WIDGET:=0;

REJECTED:=0;

REJECT_PROM:=0;

WIDGET_PROM:=0;

REP_TIME:=0;

REP:=0;

ABIERTA := TRUE;

ACT(DANYA, EXPO(60.0));

ACT(PROD,0);

ACT(FIN,6000);


TITLE := ’MAQUINA INESTABLE’;

DECL

VAR WIDGET, REJECTED: INTEGER;

REJECT_PROM, WIDGET_PROM, REP_TIME, REP: REAL;

ABIERTA: BOOLEAN;

MESSAGES WIDGTS;


END.

Salida en Glider.

WIDGETS HECHOS: 1.89878283151826E+0002

WIDGETS DESECHADOS: 1.01217168481742E+0001

4.1.3. Modelo de un Puerto de Traslado de Carbon.

Modelo Conceptual.

A un puerto de traslado de carbon llegan 5 barcos en una semana en intervalos distri-

buidos exponencialmente. Sus cargas son de 3000 a 7000 toneladas (distribuidos uniforme-

mente). El carbon es llevado en camiones de carga. Esto ocurre 5 dıas por semana. Todos

los dıas 200 camiones llegan, en intervalos distribuidos exponencialmente. Cada camion

puede trasladar 25 toneladas de carbon. Inicialmente hay 5000 toneladas de carbon en el

pilon. La simulacion comienza un lunes.

¿Con que frecuencia ocurre, que un camion deba esperar por carbon?

¿Cual es el tamano maximo del pilon?


Componentes del modelo.

Entidades temporales y recursos: Las entidades en el sistema son los barcos que

llegan para descargar el carbon y los camiones que lo trasladan.

Actividades: En el sistema suscitan dos actividades, la descarga del barco y el traslado

del carbon por los camiones.

Modelo en SimPy.


import random

# Componentes del modelo.

class Barco(Process):

def __init__(self,carga):


self.carga=carga

def descarga(self): #PEM o actividad de descarga

yield put,self,pilon,self.carga

class Camion(Process):

TiempoEspera=0

waitMon=Monitor()

def sacar(self): #PEM o actvidad de cagar el camion

llego=now()

yield get,self,pilon,CapCamion

salio=now()

Camion.TiempoEspera=salio-llego

Camion.waitMon.observe(y=salio-llego,t=now())

class GeneroBarcos(Process):

def generar(self):


while True:

yield hold,self,random.expovariate(1.0/LlegadaBarcos)

s=Barco(carga=random.uniform(cargamin,cargamax))

activate(s,s.descarga())

class HorarioCamion(Process):

def horario(self): #Comienzo del PEM

camion=GenerarCamiones() #Genero entidades segun expo(24/200)

activate(camion,camion.generar()) #activo esa entidad

while True:

yield hold,self,horacamiones # Genero entidades hasta los 5 dias

self.cancel(camion) # cancelo la generacion de entidades

yield hold,self,24*2 #Sabados y domingos

reactivate(camion) # despues del fin de semana activo de nuevo el horario

class GenerarCamiones(Process):

def generar(self):

while True:

yield hold,self,random.expovariate(1.0/LlegadaCamion)

t=Camion()

activate(t,t.sacar())

#Datos del modelo

cargamin=3000 #toneladas

cargamax=7000 #toneladas

barcoporsem=5

LlegadaBarcos=(24.0*7)/barcoporsem #horas

camionespordia=200

LlegadaCamion=24.0/camionespordia # espera entre cada intervalo de llegada

CapCamion=25 #toneladas

Taminicialpilon=5000 #toneladas

horacamiones=24*5

# Modelo y experimento


initialize()

pilon=Level(name="pilon",monitored=True,initialBuffered=Taminicialpilon)

barcos=GeneroBarcos()

activate(barcos,barcos.generar())

horario=HorarioCamion()

activate(horario,horario.horario())

simulate(until=7*24) # Simular por una semana de 7 dias

# Analisis/Salidas

RegistroPilon=pilon.bufferMon.yseries()

print "Maximo tam. del pilon",max(RegistroPilon),\

"Minimo tam. del pilon",min(RegistroPilon)

print "Cantidad de carbon que resta, despues de la llegada del

ultimo camion %6.2f toneladas:\t"%pilon.bufferMon[-1][1]

print "Frecuencia del Num. de camiones en espera hasta que halla carbon:%6.2f"\

%len(pilon.getQMon)

print "Tiempo de espera de los camiones",Camion.TiempoEspera,"horas"

print "Promedio de espera de los camiones para obtener carga: %6.2f"\

%Camion.waitMon.mean()

Resultado SimPy.

Estadisticas del modelo del puerto de carbon:

======================================================================================

Maximo tam. del pilon es: 7062.94305034

Minimo tam. del pilon es: 1.2736910471

Cantidad de carbon que resta, despues de la llegada del ultimo camion: 4002.16 toneladas

Tiempo de espera de los camiones: 0 horas

Modelo en Arena.

Salida en Arena.

Queue


Figura 4.6: Diagrama del Modelo del Puerto de Carbon en Arena.

Time

Waiting Time

Average

esperar por carbon.Queue 2.2396

T_pilon 8849.40


Modelo en Glider.

MODELO

NETWORK

CAMION (I) CARGA ::

IF (TIME>((K*168)-48)) THEN BEGIN

IT := 48;

K:=K+1;

END

ELSE BEGIN

IT := EXPO(0.12);

ACT(GRA,0);

SENDTO(CARGA);

END;

BARCOS (I) PUERTO ::

IT := EXPO(33.6);

SENDTO(PUERTO);

PUERTO (E) ::

CARBON:=CARBON+UNIF(3000, 7000);

IF (CARBON > MAX_CARBON) THEN

MAX_CARBON:=CARBON;

ACT(GRA,0);

IF EXISTENCIA=FALSE THEN

EXISTENCIA:=TRUE;

CARGA (G) ::

IF (CARBON<25) THEN

EXISTENCIA:=FALSE;


IF EXISTENCIA THEN BEGIN

SENDTO (SALIDA);

STOPSCAN;{QUITAR A VER QUE TAL}

END;

SALIDA (E) ::

TIEMPO:=TIME-GT;

IF (TIEMPO>0) THEN

ESPERARON:=ESPERARON+1;

T_ESPERA:=T_ESPERA+TIEMPO;

CAMIONES:=CAMIONES+1;

CARBON:=CARBON-25;

ACT(GRA,0);

GRA (A) ::


CARBON:6:0,CARBON,0,70000,WHITE);

STCS (A) ::

ESPERAN:=ESPERARON/CAMIONES;

T_ESP:=T_ESPERA/CAMIONES;

WRITE(’TAMANO MAXIMO DE ESCOMBROS’);

WRITE(MAX_CARBON);

WRITELN(’’);

WRITE(’TIEMPO PROMEDIO DE ESPERA POR CAMION’);

WRITE(T_ESP);

WRITELN(’’);

WRITE(’RAZON DE CAMIONES QUE ESPERAN’);

WRITE(ESPERAN);

WRITELN(’’);

IF (ESPERARON>0) THEN BEGIN

T_E_ESP:=T_ESPERA/ESPERARON;

WRITE(’PROMEDIO DE ESPERA DE LOS QUE ESPERAN’);


WRITE(T_E_ESP);

WRITELN(’’);

END;

PAUSE;

ENDSIMUL;

INIT

CARBON:=5000;

MAX_CARBON:=0;

T_ESPERA:=0;

CAMIONES:=0;

ESPERARON:=0;

ESPERAN:=0;

T_E_ESP:=0;

T_ESP:=0;

TIEMPO:=0;

EXISTENCIA := TRUE;

K:=1;

ACT(BARCOS,EXPO(33.6));

ACT(CAMION,0);

ACT(STCS, 24*70);

TITLE := ’MODELO DE COALPORT’;

DECL

VAR K, CAMIONES, ESPERARON : INTEGER;

CARBON, MAX_CARBON, T_ESPERA, TIEMPO : REAL;

ESPERAN, T_E_ESP, T_ESP : REAL;

EXISTENCIA : BOOLEAN;

MESSAGES TRUCK;


END.


Salida en Glider.

TAMANO MAXIMO DEL PILON 7.25717306020771E+0004

TIEMPO PROMEDIO DE ESPERA POR CAMION 0.00000000000000E+0000

FRECUENCIA DE ESPERA DE LOS CAMIONES 0.00000000000000E+0000

4.1.4. Modelo de Gruas en un Puerto.

Modelo Conceptual.

Un puerto tiene 4 gruas para cargar y descargar barcos. Las llegadas de los barcos

se producen en intervalos de 12 horas (Distribuidos exponencialmente). Cada barco carga

entre 4000 y 10000 toneladas (Distribuidos Uniformemente). Hay 2 tipos de cargas: Una

que se descarga con prioridad normal y otro que requiere descarga con prioridad alta. Las

gruas son colocadas, de acuerdo a estas 2 prioridades. El 50Cada barco requiere 2 gruas

para cargarse. La descarga no arranca antes de que ambas gruas esten disponibles. La tasa

de descarga es de 250 toneladas/hora por grua. Simula esta operacion por 100 dıas.

¿Con que frecuencia (en promedio) los barcos tienen que esperar para ser descarga-

dos?,

¿En que porcentaje de tiempo se ocupa una grua?


Entidades temporales y recursos: las entidades son los barcos que llegan al puerto

para ser descargados y los recursos las cuatro gruas que se encuentran en el puerto

Actividades: Las actividades que se llevan a cabo en el sistema es la ocasionada por


la llegada de los barcos y la disponibilidad de dos gruas para realizar la descarga del

barco segun la prioridad que este posea.

Modelo en SimPy.


import random

# Componentes de modelo

class Gruas(Process):

def operacion(self,GruaLibre):

while True:

yield put,self,GruaLibre,[self]

yield passivate,self

class barco(Process):

espera=Monitor()

Numbarcos = 0

def __init__(self,carga,PrioridadCarga):


self.prioridad=PrioridadCarga # Atributo Prioridad

self.carga=carga #Atributo carga

barco.Numbarcos+=1

def visit(self,GruaLibre):

llegada=now()

yield get,self,GruaLibre,GruasPorBarco,self.prioridad

partida=now()

barco.espera.observe(y=partida-llegada,t=now())

GruasPuerto=self.got

yield hold,self,self.carga/(GruasPorBarco*TasaDescarga)

for gruas in GruasPuerto:

reactivate(gruas)

class GenerarBarcos(Process):

def generate(self,carbon):


while True:

yield hold,self,random.expovariate(1.0/llegadaBarcos)

r=random.random()

if r>PrioridadGenerada: prioridad=Palta

else: prioridad=Pbaja

br=barco(carga=random.uniform(cargaMin,cargaMax),\

PrioridadCarga=prioridad)

activate(br,br.visit(carbon.GruaLibre))

class Carbon:

def __init__(self,Ngruas):

self.GruaLibre=Store(capacity=Ngruas,getQType=PriorityQ,\

monitored=True, monitorType=Monitor)

for i in range(Ngruas):

c=Gruas()

activate(c,c.operacion(self.GruaLibre))

# Datos del modelo

llegadaBarcos=12 #horas

cargaMin=4000; cargaMax=10000 #toneladas

TasaDescarga=250.0 #toneladas/Gruas por hora

GruasPorBarco=2

Ngruas=4

PrioridadGenerada=0.5

Palta=10; Pbaja=1

endTime=100*24 #horas

Nreplicas = 30

# Modelo

def model():

initialize()

car=Carbon(Ngruas)

bar=GenerarBarcos()

activate(bar,bar.generate(car))

simulate(until=endTime)

print "El tiempo promedio de uso de las gruas es: ",car.GruaLibre.bufferMon.mean()


print "El Numero de gruas disponibles: ", car.GruaLibre.nrBuffered

return car.GruaLibre.bufferMon

# Experimento

bufferMon=model()

tiempo=0

for replica in range(Nreplicas):

gru = model()

tiempo=tiempo + (1-gru.timeAverage()/Ngruas)

# Analisis/salidas

print "\tPromedio sobre 30 replicas del uso de las gruas: %6.2f"\

%((tiempo/30)*100)

print "\tPorcentaje de carga en gruas: %4.2f "\

%((1-bufferMon.timeAverage()/Ngruas)*100)

print "\tEl numero de barcos que llegan son: %s"\

%barco.Numbarcos

print "\n\n\tEl promedio de espera de los barcos es: %6.2f hras"\

%(barco.espera.mean()/2)

Resultados en SimPy.

Porcentaje de carga en gruas: 58.49 porciento

Promedio sobre 30 replicas del uso de las gruas: 57.08

El promedio de espera de los barcos es: 1.73 hras

Modelo en Arena.


Descarga de barc

Replications: 30 Time Units: Hours


Figura 4.7: Diagrama del Modelo de Gruas en Arena.

Resource

Usage

Number Busy

Average

grua 1 0.5717

grua 2 0.5703

grua 3 0.5739

grua 4 0.5796

Total 0.5738

Queue

Time

Waiting Time

Average

Espera por gruas.Queue 4.2607


Modelo en Glider.

MODELO GRUAS

NETWORK

LLEG (I) COLA ::

IF BER(0.5) THEN BEGIN

PRIOR:=1;

END ELSE BEGIN

PRIOR:=2;

END;

IT := EXPO(12.0);

CARGA:=UNIF(4000, 10000);

ACT(GRA, 0);

SENDTO(COLA);

COLA (L) ::

ORDER(PRIOR, A);

GRUA (G) FPAR, SPAR ::

IF (U_FPAR = 0) THEN BEGIN

SENDTO (FPAR);

END ELSE BEGIN

IF (U_SPAR = 0) THEN

SENDTO (SPAR);

STOPSCAN;

END;

FPAR (R) ALTA, BAJA ::

RELEASE

IF (PRIOR = 1) THEN BEGIN

SENDTO (ALTA);


END ELSE BEGIN

SENDTO (BAJA);

END;

STAY:=CARGA/500;

SPAR (R) ALTA, BAJA ::

RELEASE

IF (PRIOR = 1) THEN BEGIN

SENDTO(ALTA);

END ELSE BEGIN

SENDTO(BAJA);

END;

STAY:=CARGA/500;

BAJA (E) ::

BA:=BA + 1;

IF (ET-GT-(CARGA/500) > 0) THEN BEGIN

E_BA:=E_BA+1;

T_E_B:=T_E_B+GT-ET;

END;

ACT(GRA, 0);

ALTA (E) ::

AL:=AL + 1;

IF (ET-GT-(CARGA/500) > 0) THEN BEGIN

E_AL:=E_AL+1;

T_E_A:=T_E_A+GT-ET;

END;

ACT(GRA, 0);

STCS (A) ::

F_AL:=E_AL/AL;


F_BA:=E_BA/BA;

WRITE(’FRECUENCIA DE ALTA PRIORIDAD: ’);

WRITE(F_AL);

WRITELN(’’);

WRITE(’NUMERO DE BARCOS DE ALTA PRIORIDAD ’);

WRITE(AL);

WRITELN(’’);

WRITE(’FRECUENCIA DE BAJA PRIORIDAD: ’);

WRITE(F_BA);

WRITELN(’’);

WRITE(’NUMERO DE BARCOS DE BAJA PRIORIDAD’);

WRITE(BA);

WRITELN(’’);

PAUSE;

ENDSIMUL;

GRA (A) ::


E_BA:6:0,E_BA,0,100,YELLOW;

E_AL:6:0,E_AL,0,100,WHITE);

INIT

BA:=0;

AL:=0;

T_E_A:=0;

T_E_B:=0;

E_AL:=0;

E_BA:=0;

F_AL:=0;

F_BA:=0;

ACT(LLEG, EXPO(12.0));

ACT(STCS, 2400);

TITLE:=’MODELO DE GRUAS’;


DECL

VAR BA : INTEGER;

AL : INTEGER;

E_BA, E_AL : INTEGER;

T_E_A, T_E_B : REAL;

F_AL, F_BA : REAL;

MESSAGES BARCO(PRIOR, CARGA : REAL);


END.

Salida en Glider

FRECUENCIA DE ALTA PRIORIDAD: 7.26315789473684E-0001

NUMERO DE BARCOS DE ALTA PRIORIDAD 95

FRECUENCIA DE BAJA PRIORIDAD: 8.31932773109244E-0001

NUMERO DE BARCOS DE BAJA PRIORIDAD119

4.1.5. Modelo de un Recurso Limitado.

Modelo Conceptual.

Una estacion de trabajo consta de 2 maquinas (M1, M2), las cuales procesan ciertas

piezas. Las piezas llegan de acuerdo a una distribucion exponencial con media igual a

10 minutos, para ser procesados por una de las maquinas. Estas compiten entre si por

la disponibilidad de una de las maquinas. El tiempo de procesado de cualquiera de las

maquinas es de 15 a 25 minutos (Distribuidos Uniformemente). Simular esta operacion por

un dıa.

Calcular el numero de piezas procesadas.


El tiempo promedio en espera de las piezas por una de las maquinas.


Entidades temporales y recursos: Las entidades temporales son las piezas, y los re-

cursos son las 2 maquinas.

Actividades: El procesado de las piezas por una de las maquinas.

Modelo en SimPy


import random

import math

# Componentes de modelo

class piezas(Process):

espera=Monitor()

NumPiezas = 0

def __init__(self):


piezas.NumPiezas+=1

self.id = "pieza " + str(piezas.NumPiezas)

def procesado(self,Maquinas):

llegada = now()

#Solicito una de las maquinas si esta disponible

yield request,self,Maquinas

libera = now()

yield hold,self,r.uniform(TMinProceso,TMaxProceso)

yield release,self,Maquinas

Tsistema=libera-llegada

print "En el tiempo %s, la %s salio, con un tiempo en la maquina de %s "\

%(now(),self.id,Tsistema)


piezas.espera.observe(y=libera-llegada,t=now())

class GeneracionPiezas(Process):

def __init__(self):


def generar(self,Maquinas):

while True:

yield hold,self,r.expovariate(1.0/TLlegada)

p = piezas()

activate(p,p.procesado(Maquinas=Maquinas),)

# Modelo

def model():

initialize()

Maquinas=Resource(capacity=2,name=’Maquinas’,qType=FIFO,monitored=True,\

monitorType=Monitor)

llegaPiezas = GeneracionPiezas()

activate(llegaPiezas,llegaPiezas.generar(Maquinas=Maquinas))

simulate(endTime)

#Datos de experimento o Datos del modelo

TLlegada=10 # minutos

TMinProceso=15; TMaxProceso=25 # minutos

endTime =24*60 # minutos

NMaquinas=2

r=random.Random(9)

#Experimento

model()

#Analisis/Salidas

print "\nEl tiempo promedio de espera de las piezas es: %2.1f minutos"\

%piezas.espera.mean()

print "\n\t" print "Numero de entidades (piezas) generadas : ",

piezas.NumPiezas

Salida en SimPy.


El tiempo promedio de espera de las piezas es: 12.2 minutos

Entidades generadas son piezas: 124

Modelo en Arena.

Figura 4.8: Diagrama del Modelo de un Recurso Limitado.

Salida en Arena.

System Average

Number Out 123.00

Queue

Time

Waiting Time

Average

Construcion de Piezas.Queue 22.7995

Capıtulo 5

Conclusiones y Recomendaciones.

En este capitulo se plantean las conclusiones y recomendaciones a que se llego, luego

de llevarse a cabo los objetivos planteados.

5.1. Conclusiones.

Al culminar el presente trabajo de investigacion y cumpliendo con los objetivos plan-

teados al inicio de esta, se llegaron a las siguientes conclusiones:

Con el cumplimiento de los objetivos planteados a traves de la presente investigacion,

se desarrollo un manual en espanol que permite el aprendizaje de SimPy, mediante

la realizacion de un conjunto de ejemplos con casos reales de uso, lo que facilitara el

aprendizaje de esta herramienta a otras personas.

Dado que se pudo comprobar la capacidad de Simpy para el modelado y simula-

cion de sistemas complejos, se puede concluir que no es necesario realizar grandes

inversiones en la adquisicion de Software privativo para la simulacion de ciertos sis-

temas, cuando existe un Software que presenta las mismas caracterısticas que estos

114

CAPITULO 5. CONCLUSIONES Y RECOMENDACIONES. 115

y, ademas, es gratuito ya que se distribuye bajo los lineamientos de la GPL (General

Public License o Licencia publica General) y de fuente abierta (Open Source).

Como la filosofıa de desarrollo de SimPy es libre, es decir de fuente abierta, el codigo

fuente esta disponible, ası cualquier persona (con cierto grado de conocimiento en

programacion) podra modificarlo y extenderlo, para de esa forma contar con una

herramienta ajustable a las necesidades planteadas.

SimPy mostro ser una herramienta facil de utilizar una vez que el analista se ha

familiarizado con el lenguaje de programacion Python y sobre todo en el paradigma

orientado a objeto.

El desarrollo del manual en espanol del paquete de Simulacion SimPy resulta ser un

gran aporte a la comunidad de simulacion de habla hispana, ya que toda la documen-

tacion existente del Simualdor SimPy esta en Ingles.

5.2. Recomendaciones.

Con la finalidad de extender y complementar el presente proyecto, se sugieren las si-

guientes recomendaciones:

Difundir el uso del paquete SimPy en las materias de Simulacion y Modelado de la

Escuela de Sistemas.

Ampliar el manual a traves de la inclusion del modulo SimulationRT (para sincroni-

zacion en tiempo real).

Estudiar y desarrollar si es posible la implantacion del simulador como una herra-

mienta grafica donde el usuario pueda realizar diagramas de flujo para la esquemati-

zacion del modelo.

Bibliografıa

[1] Hoeger, Herbert.(2000). Apuntes de Simulacion. Guias en Linea, octubre 2006. Con-

sultado en noviembre de 2006. http://webdelprofesor/hhoeger/Simulacion

[2] Universidad de Sonora, Departamento de Ingenerıa Industrial. (2005). Simulacion de

Sistemas. Consultado en noviembre de 2006. http://us.com

[3] Universidad de Buenos Aires, Facultad de Ingenerıa. (2005). Simulacion. Consultado

en noviembre de 2006. http://fiabula.com

[4] Barcelo, Jaime. (1996). Simulacion de Sistemas Discretos (primera edicion). Barce-

lona: Isdefe.

[5] Muller, Klauss;(2003). SimPy Homepage. Consultado en abril de 2006. Disponible

en:http://simpy.sourceforge.net/ .

[6] Muller, Klaus (2006). Chapter 3 Developing a SimPy simulation program. Disponible

en:[email protected].

[7] Law, A.M.;Kelton, W.D.(2000). Simulation Modeling & Analysis.McGraw-Hill, ter-

cera edicion, 2000.

[8] Guash A.; Piera, M.A.; Casanovas J.; Figueras J.(2005). Aplicaciones a procesos

logısticos de fabricacion y servicios (1a ed). Mexico: Edicions UPC,2005.

116

BIBLIOGRAFIA 117

[9] Wikipedia La enciclopedia libre. Python. Articulo en linea, mayo 2006. Consultado

en mayo de 2006. http://es.wikipedia.org/wiki/Python.

[10] Wikipedia La enciclopedia libre. Simulacion. Articulo en linea, octubre 2006. Con-

sultado en octubre de 2006. http://es.wikipedia.org/wiki/Simulaci

[11] Kelton, W.D.; Sadowski R.P.; Sadowski D.A. (2001). Simulation with Arena (2a ed).

Norteamerica: McGraw-Hill.

[12] Muller, Klaus.(2005). SimPy: System Simulation in Python. Consultado en Junio de

2006. http://simpy.sourceforge.net/images/SimPy %20paper.pdf

[13] Muller, Klaus.(2004). Advanced Systems Simulation Capabilities in SimPy. Consulta-

do en agosto de 2006. http://simpy.sourceforge.net/

[14] Matloff, Norm. (2005). Introduction to Discrete-Event Simulation and the SimPy Lan-

guage. Consultado en Noviembre de 2006. http://heather.cs.ucdavis.edu/

[15] Vignaux, Tony.(2005). SimPy Notes. Consultado en Julio de 2006.

http://www.mcs.vuw.ac.nz/courses/OPRE352/2006T2/Lecture-Notes/

[16] Lauwenswww, Ben. SimPy. (2004). Royal Military Academy. Consultado en diciem-

bre de 2006. http://sic.rma.ac.be/ flapierr/divers

[17] Racero, Jesus.(2004). Ingenerıa Industrial-Simulacion de Eventos Discretos. Univer-

sidad de Sevilla Grupo de Investigacion Tecnologıas de la informacion e informatica.

Consultado en Noviembre de 2006. http://racero.us.es/

[18] Muller, Klaus y Vignaux, Tony. (2002). SimPy: Simulating Systems in Pyt-

hon. Omlap.com Python DevCenter, febrero 2003. Consultado en Junio de 2006.

http://www.onlamp.com/pub/a/python/2003/02/27/simpy.html

[19] Kiviat, P. J (1971). Simulation Languages, in: Computer Simulation Experiments with

Models of Economic Systems. John Wiley.

BIBLIOGRAFIA 118

[20] Pooch, U.W. y Wall, J.(2000). Discrete Event Simulation: A practical approach

(2aed). CRC Press.

[21] Zeigler B.; Praehofer H.; Kim T.G. (2000). Theory of Modeling and Simulation.

(2aed). Academic Press.

[22] Ortiz, Oswaldo.(2005). Aplicacion del lenguaje GPSS/H a un problema de acarreo

minero. Revista del Instituto de Investigacion FIGMMG, 8 (15) pag. 1

[23] Wikipedia La enciclopedia libre. Lenguajes de Simulacion. Articulo en linea, diciem-

bre 2006. Consultado en diciembre de 2006. http://es.wikipedia.org/wiki/Simulacion

[24] CESIMO & IEAC Universidad de Los Andes.(1996) GLIDER Reference Manual.

Consultado en diciembre 2006. http://afrodita.faces.ula.ve/gliweb/index.html

[25] Wikipedia La enciclopedia libre. Simula. Articulo en linea, mayo 2006. Consultado

en mayo de 2006. http://es.wikipedia.org/wiki/Simula.

[26] ONlamp. ONlamp.com Python Devcenter. Articulo en linea, febrero 2003. Consulta-

do en junio 2006. http://onlamp.com/pub/a/python/2003/02/27/simpy.html

[27] Muller Klauss; Frost, Simon. SimPy – Simulation in Python. Libro sin publicar.

[28] Arena Rockwell Software. Forward Visibily For Business, enero 2000. Consultado en

enero 2007.http://www.arenasimulation.com/

[29] Fernandez, F. (2005). El lenguaje Simula. Consultado en marzo 2007.

http://www.lcc.uma.es/ blas/apuntes/PDAv/p2005-2006/simula1.pdf

Apendice A

Instalacion del paquete SimPy en lasplataformas Windows y GNU/Linux.

A.1. Requisitos del Sistema.

Cualquier sistema operativo Windows o GNU/Linux (Pruebas hechas en la distribucion

Linux Ubuntu Dapper 6.06 y Microsoft Windows XP SP2).

Para la instalacion del paquete en cualquiera de las dos plataformas se debe tener insta-

lado previamente Python2.3 o versiones superiores y descargar el paquete SimPy (Version

1.7.1) de la pagina http://simpy.sourceforge.net/ en formato .zip para window o en

formato .tar.gz para distribuciones GNU/Linux

A.2. En Window

1. Desempaquetar el archivo SimPy-1.7.1.zip con la herramienta WinZip o WinRar.

2. Al descomprir el archivo, se creara una carpeta con el mismo nombre del archivo

119

APENDICE A. INSTALACION DEL PAQUETE SIMPY EN LAS PLATAFORMASWINDOWS Y GNU/LINUX. 120

comprimido en este caso SimPy-1.7.1. Luego se abre un terminal en modo MS-DOS

y se dirige a la ruta de la carpeta creada previamente, tal como se ilustra en la figura

(Figura A.1).

Figura A.1: Acceso a la carpeta SimPy-1.7.1 en modo MS-DOS a traves de un terminal.

3. Una vez parado en la carpeta se ejecuta el siguiente comando, el cual instalara SimPy

version 1.7.1 en tu computador (Ver Figura A.2).

APENDICE A. INSTALACION DEL PAQUETE SIMPY EN LAS PLATAFORMASWINDOWS Y GNU/LINUX. 121

Figura A.2: Ejecucion del comando de instalacion de SimPy, a traves de la lınea de comando MS-DOS

A.3. En GNU/Linux.

1. Desempaquetar el archivo descargado SimPy-1.7.1.tar.gz con el comando

tar xvzf SimPy-1.7.1.tar.gz.

2. Dirigirse a la ruta de la carpeta creada al descomprimir el archivo, de la misma ma-

nera como se explico para el caso Window.

3. Al estar parado en la ruta de la carpeta ejecutar el comando python setup.py install,

el cual instalara el paquete SimPy en la computadora.

“Estudio Comparativo del Paquete de Simulacion´ Orientado ...

Documents

Transcript of “Estudio Comparativo del Paquete de Simulacion´ Orientado ...