diseno de guias de laboratorio para la catedra de simulacion utilizando software arena extension
TRANSCRIPT
UNIVERSIDAD CENTROAMERICANA
“JOSÉ SIMEÓN CAÑAS”
DISEÑO DE GUÍAS DE LABORATORIO PARA LA
CÁTEDRA DE SIMULACIÓN UTILIZANDO SOFTWARE
ARENA.
TRABAJO DE GRADUACIÓN PREPARADO PARA LA
FACULTAD DE INGENIERÍA Y ARQUITECTURA
PARA OPTAR AL GRADO DE
INGENIERO INDUSTRIAL
POR:
OSCAR ORLANDO ARÉVALO RODRÍGUEZ
LUIS EDUARDO CARBALLO CENTENO
FRANCISCO ROBERTO CUÉLLAR GUZMÁN
FRANCISCO JAVIER FARRAR OSORIO
OCTUBRE 2009
ANTIGUO CUSCATLÁN, EL SALVADOR, C.A.
RECTOR
JOSÉ MARÍA TOJEIRA, S.J.
SECRETARIO GENERAL
RENÉ ALBERTO ZELAYA
DECANO DE LA FACULTAD DE INGENIERÍA Y ARQUITECTURA
EMILIO JAVIER MORALES QUINTANILLA
DIRECTOR DEL TRABAJO
LAURA BEATRIZ ORELLANA
LECTOR
MAURICIO SVEN GUZMÁN ALVARADO
i
RESUMEN EJECUTIVO
El objetivo primordial del presente trabajo de graduación es elaborar, desarrollar y ejemplificar una
guía práctica para la materia de Simulación utilizando el Software ARENA, haciendo referencia a
las distintas aplicaciones que se pueden tener en el área de ingeniería para la resolución de
problemas utilizando las herramientas y conocimientos de esta materia.
En el capítulo 1, de forma inicial, se presentan las generalidades del presente trabajo de
graduación, mostrando los objetivos, tanto generales como específicos, los límites y alcances en su
realización; se detallan los antecedentes en la ejecución de proyectos similares realizados dentro
de la universidad y, finalmente, se muestran los limitantes que se manifestaron en la elaboración
del mismo.
Cada una de las partes previamente definidas se detalla de manera breve y concisa ya que son
estos fundamentos los que han formado los cimientos del presente documento. De forma particular
se puede afirmar que dichos fundamentos no servirán únicamente para el presente documento sino
que servirán como parámetros y lineamientos para futuras investigaciones dentro del campo de la
ingeniería y de la simulación.
Dentro del capítulo 2 se presenta una introducción a la simulación, comenzando por su definición,
según autores diversos especialistas en el tema, enfoques para la simulación, sus tipos y métodos
dependiendo del propósito que se persiga con el estudio a realizar y las ventajas y desventajas que
acarrea su implementación.
Es fundamental comprender exactamente lo que se está estudiando, ya que es esto lo que
determina el punto de partida y hasta donde se puede llegar dentro de una determinada área de
investigación, es por esto que se utilizaron diversos puntos de vista de diversos autores para definir
lo que sería la amplitud del presente documento.
Para el estudio de la simulación se vuelve una necesidad el conocer sus distintos enfoques, es
decir, para simular un sistema se debe tener conocimiento de las secuencia de los sucesos y como
se abordarán en el modelo, es decir, el tipo enfoque que se ha de utilizar para seguir las sutiles
variaciones en el sistema a medida entran y salen las entidades, como son registradas dichas
variaciones y a cuales se le dará mayor prioridad.
De manera representativa, se presentan los conceptos básicos relacionados a la simulación, tales
como la explicación de sistema, modelo y las clasificaciones de estos, cuya comprensión se vuelve
básica para el desarrollo de cualquier aplicación, esto se ejemplifica en el hecho que cuando se
lleva a cabo el modelado del sistema de simulación existen varios caminos para diseñarlo, la
elección del método a utilizar dependerá del propósito que se persigue con el estudio de la
ii
simulación y los aspectos del sistema que se consideren de especial relevancia en el posterior
análisis.
Para el desarrollo de la simulación, como todo proceso de ingeniería, se presenta una metodología
definida como una serie de pasos en secuencia lógica, enumerados de forma descriptiva, así como
mostrados en forma de esquema para facilitar su compresión.
En el capítulo 3 se presentan una introducción general al software ARENA, haciendo referencia a
su entorno de trabajo, características básicas, aplicaciones, procesos y módulos que posee,
permitiendo de esta forma al experimentador hacer un estudio más completo sobre el modelo que
se pretende simular.
El software Arena es un programa computacional que, dependiendo de su versión, tiene diferentes
características, desde una edición básica académica hasta una versión especializada para las
grandes empresas, contando con diferentes aplicaciones tales como:
Documentar, animar y demostrar la variabilidad y dinámica de un mapa de procesos.
Análisis de procesos de negocios generalmente relacionado con el cliente y el manejo de
documentos.
Análisis de procesos simples y complejos de manufactura.
Análisis de diferentes alternativas.
De forma detallada, se explica el entorno de trabajo que posee el software ARENA, las barras de
herramientas que permiten al usuario personalizar su ambiente dependiendo de su especialidad, la
barra de proyectos que contiene todos los paneles de módulos y navegación que se utilizan en la
simulación con Arena, el panel de procesos básicos que es donde se encuentran los diferentes
módulos para la creación de entidades, procesos, salida de entidades, decisiones, etc., el panel de
procesos avanzados que se utiliza para modelos donde es importante hacer énfasis en las
circunstancias particulares que se desean evaluar, el panel de módulos de flujo que contiene los
módulos que sirven al constructor del modelo como herramientas para la elaboración de
situaciones que reflejen el involucramiento de flujo o movimiento de sustancias.
Finalmente, en el capítulo 4 se presentan las conclusiones y recomendaciones que se obtuvieron a
partir de la elaboración del presente trabajo de graduación, mostrando énfasis en la teoría de la
simulación y su aplicación a partir de la utilización del software ARENA.
En los Anexos se detallan las distintas guías de laboratorio que se elaboraron y desarrollaron
utilizando el software ARENA, tomando como punto de partida la construcción de un modelo
básico, correr la simulación, analizar los resultados obtenidos y agregar cierta complejidad a los
iii
problemas que permitió, en definitiva, la elaboración de un modelo que ilustra las diversas
herramientas que contiene el programa para el desarrollo de las distintas formas de aplicación de
la simulación en los diversos campos de estudio.
ÍNDICE
RESUMEN EJECUTIVO ....................................................................................................................... i
ÍNDICE DE FIGURAS ........................................................................................................................ vii
SIGLAS ............................................................................................................................................... ix
ABREVIATURAS ................................................................................................................................. xi
SIMBOLOGÍA .................................................................................................................................... xiii
PRÓLOGO ......................................................................................................................................... xv
CAPÍTULO 1: GENERALIDADES ....................................................................................................... 1
1.1. Objetivos.............................................................................................................................. 1
1.1.1. Objetivo general .......................................................................................................... 1
1.1.2. Objetivos específicos .................................................................................................. 1
1.2. Límites y alcances. .............................................................................................................. 1
1.3. Antecedentes. ..................................................................................................................... 2
1.4. Limitantes ............................................................................................................................ 2
CAPÍTULO 2: INTRODUCCIÓN A LA SIMULACIÓN. ........................................................................ 5
2.1. Definición ............................................................................................................................. 5
2.2. Enfoques para la simulación. .............................................................................................. 6
2.3. Tipos y métodos de simulación. .......................................................................................... 6
2.4. Ventajas y desventajas de la simulación. ........................................................................... 7
2.5. Metodología para la simulación. ......................................................................................... 9
2.6. Esquema de metodología parar el proceso de simulación ............................................... 12
2.7. Conceptos. ........................................................................................................................ 13
2.7.1. Sistema. ..................................................................................................................... 13
2.7.2. Modelo. ...................................................................................................................... 14
CAPÍTULO 3: SOFTWARE ARENA ................................................................................................. 19
3.1. Introducción ....................................................................................................................... 19
3.2. Entorno de trabajo ............................................................................................................. 21
3.3. Barras de herramientas ..................................................................................................... 27
3.4. Barra de proyectos (project bar) ....................................................................................... 29
3.5. Panel de procesos básicos ............................................................................................... 29
3.5.1. Módulo create ............................................................................................................ 30
3.5.2. Módulo dispose ......................................................................................................... 31
3.5.3. Módulo process ......................................................................................................... 32
3.5.4. Módulo decide ........................................................................................................... 33
3.5.5. Módulo batch ............................................................................................................. 33
3.5.6. Módulo separate ........................................................................................................ 34
3.5.7. Módulo assign ........................................................................................................... 35
3.5.8. Módulo record ............................................................................................................ 36
3.5.9. Módulo entity ............................................................................................................. 36
3.5.10. Módulo queue ............................................................................................................ 37
3.5.11. Módulo resource ........................................................................................................ 37
3.5.12. Módulo schedule........................................................................................................ 37
3.5.13. Módulo set ................................................................................................................. 38
3.6. Panel de procesos avanzados .......................................................................................... 39
3.6.1. Módulo delay: ............................................................................................................ 40
3.6.2. Módulo hold: .............................................................................................................. 41
3.6.3. Módulo match: ........................................................................................................... 42
3.6.4. Módulo readwrite: ...................................................................................................... 43
3.6.5. Módulo release: ......................................................................................................... 44
3.6.6. Módulo remove: ......................................................................................................... 45
3.6.7. Módulo seize: ............................................................................................................. 46
3.6.8. Módulo signal: ............................................................................................................ 47
3.6.9. Módulo adjust variable: .............................................................................................. 48
3.6.10. Módulo file: ................................................................................................................ 49
3.7. Panel de módulos de flujo ................................................................................................. 50
3.7.1. Módulo tank: .............................................................................................................. 51
3.7.2. Módulo sensor: .......................................................................................................... 52
3.7.3. Módulo flow: ............................................................................................................... 54
3.7.4. Módulo seize regulator: ............................................................................................. 55
3.7.5. Módulo release regulator: .......................................................................................... 56
3.8. Lenguaje vba en arena ...................................................................................................... 57
3.8.1. ¿Qué es VBA? ........................................................................................................... 57
3.8.2. El entorno VBA .......................................................................................................... 58
3.8.3. Formularios userform ................................................................................................ 61
3.8.4. Propiedades de un formulario ................................................................................... 63
3.8.5. Navegador de objetos ............................................................................................... 64
3.8.6. Escritura de código en la ventana de VBA ................................................................ 66
CONCLUSIONES .............................................................................................................................. 69
RECOMENDACIONES ..................................................................................................................... 71
GLOSARIO ........................................................................................................................................ 73
REFERENCIAS ................................................................................................................................. 77
BIBLIOGRAFÍA .................................................................................................................................. 79
ANEXO:
ANEXO A: GUÍAS DE LABORATORIO
vii
ÍNDICE DE FIGURAS
Figura 2. 1. Esquema de metodología para el proceso de simulación. ............................................ 12
Figura 3. 1. Ambiente de trabajo Arena ............................................................................................ 21
Figura 3. 2. Menú "File" ..................................................................................................................... 22
Figura 3. 3. Menú "Edit" .................................................................................................................... 23
Figura 3. 4. Menú "View" ................................................................................................................... 24
Figura 3. 5. Menú "Tools" .................................................................................................................. 25
Figura 3. 6. Menú "Object" ................................................................................................................ 25
Figura 3. 7. Menú "Arrange" .............................................................................................................. 26
Figura 3. 8. Menú “Run” .................................................................................................................... 26
Figura 3. 9. Barra de Herramientas "Standard" ................................................................................ 27
Figura 3. 10. Barra de Herramientas "Arrange" ................................................................................ 27
Figura 3. 11. Barra de Herramientas "Draw"..................................................................................... 27
Figura 3. 12. Barra de Herramientas "Animate" ................................................................................ 28
Figura 3. 13. Barra de Herramientas "Animate Transfer" ................................................................. 28
Figura 3. 14. Cuadro de Diálogo "Customize" .................................................................................. 28
Figura 3. 15. Panel "Basic Process" ................................................................................................. 30
Figura 3. 16. Módulo "Create" ........................................................................................................... 31
Figura 3. 17. Módulo "Dispose" ......................................................................................................... 31
Figura 3. 18. Módulo "Process" ......................................................................................................... 32
Figura 3. 19. Módulo "Decide" .......................................................................................................... 33
Figura 3. 20. Módulo "Batch" ............................................................................................................ 34
Figura 3. 21. Módulo "Separate" ....................................................................................................... 35
Figura 3. 22. Módulo "Assign" ........................................................................................................... 35
Figura 3. 23. Módulo "Record" .......................................................................................................... 36
Figura 3. 24. Módulo de Datos "Entity" ............................................................................................. 36
Figura 3. 25. Módulo de Datos "Queue" ........................................................................................... 37
Figura 3. 26. Módulo de Datos "Resource" ....................................................................................... 37
Figura 3. 27. Módulo de Datos "Schedule" ....................................................................................... 38
Figura 3. 28. Módulo de Datos "Set" ................................................................................................. 38
Figura 3. 29. Panel "Advanced Process" .......................................................................................... 40
Figura 3. 30. Módulo "Delay" ............................................................................................................ 41
Figura 3. 31. Módulo "Hold" .............................................................................................................. 42
Figura 3. 32. Módulo "Match" ............................................................................................................ 43
Figura 3. 33. Módulo "ReadWrite" ..................................................................................................... 44
Figura 3. 34. Cuadro de diálogo "Assignments" del módulo "ReadWrite" ........................................ 44
Figura 3. 35. Módulo "Release" ........................................................................................................ 45
viii
Figura 3. 36. Cuadro de diálogo "Resources" del módulo "Release" ............................................... 45
Figura 3. 37. Módulo "Remove"......................................................................................................... 46
Figura 3. 38. Módulo "Seize" ............................................................................................................. 47
Figura 3. 39. Cuadro de diálogo "Resources" del módulo "Seize" .................................................... 47
Figura 3. 40. Módulo "Signal" ............................................................................................................ 48
Figura 3. 41. Módulo "Adjust Variable" .............................................................................................. 49
Figura 3. 42. Módulo de Datos "File" ................................................................................................. 50
Figura 3. 43. Módulo "Flow Process" ................................................................................................ 51
Figura 3. 44. Módulo "Tank" .............................................................................................................. 52
Figura 3. 45. Cuadro de diálogo "Regulators" del módulo "Tank" .................................................... 52
Figura 3. 46. Módulo "Sensor"........................................................................................................... 53
Figura 3. 47. Cuadro de diálogo "Actions" del módulo "Sensor" ....................................................... 54
Figura 3. 48. Módulo "Flow" .............................................................................................................. 55
Figura 3. 49. Módulo "Seize Regulator" ............................................................................................ 56
Figura 3. 50. Cuadro de diálogo "Regulators" del módulo "Seize Regulator" ................................... 56
Figura 3. 51. Módulo "Release Regulator" ........................................................................................ 57
Figura 3. 52. Cuadro de diálogo "Regulators" del módulo "Release Regulator" .............................. 57
Figura 3. 53. Ventana del Editor de Visual Basic de Arena .............................................................. 58
Figura 3. 54. Formulario "UserForm" ................................................................................................ 62
Figura 3. 55. Acceso a las propiedades del "UserForm" .................................................................. 63
Figura 3. 56. Ventana "Properties" del "UserForm" .......................................................................... 64
Figura 3. 57. Navegador de Objetos, "Object Browser" .................................................................... 65
Figura 3. 58. Ventana de código del Evento "ModelLogic_RunBegin" ............................................. 66
Figura 3. 59. Acceso a la ventana de código del "UserForm" ........................................................... 67
Figura 3. 60. Ventana de código del "UserForm", programando la subrutina
"CommadButton1_Cilck" ................................................................................................................... 68
ix
SIGLAS
VBA: Visual Basic for Applications.
VBE: Visual Basic Editor.
UCA: Universidad Centroamericana “José Simeón Cañas”.
SQL: Structured Query Language.
HTML: HyperText Markup Language
CAD: Computer Aided Design
DXF: Drawing eXchange Format
FIFO: First In First Out.
LIFO: Last In First Out.
ADO: ActiveX Data Objects.
OLE DB: Object Linking and Embedding of Data Bases
PDF: Portable Document Format
WIP: Work in Progress
VA: Value Added
NVA: Non Value Added
UF: User Function 190
xi
ABREVIATURAS
Ej.: ejemplo.
Etc.: etcétera
Inc.: incorporated
Min.: minutos
p.m.: pasado meridiano (post meridiem)
a.m.: antes del meridiano (ante meridiem)
xiii
SIMBOLOGÍA
®: Registrado
©: Copyright
%: Porcentaje
$: Dólar americano
xv
PRÓLOGO
La Ingeniería Industrial desde sus inicios ha buscado la implementación las prácticas que
garanticen que una empresa u organización realice sus actividades de la manera más conveniente
y económica para la empresa, pero sin dejar de lado los intereses del capital humano de que esta
dispone. Han surgido conceptos como los de eficiencia y eficacia orientados a la buena utilización
de los recursos para la consecución de los objetivos primarios de la empresa, esto ha resultado en
un esfuerzo focalizado de todos los involucrados en el bien de la organización y la sociedad.
Para enfrentar los nuevos problemas que plantea la sociedad tecnócrata, corresponde a los
administradores e ingenieros (administradores científicos) acoplarse a los retos presentes, y más
aun, tomar conciencia de las oportunidades que se les presentan en sus respectivos campos. En la
obligación de las Universidades y escuelas superiores actualizar sus métodos de enseñanza para
las demandas de los problemas contemporáneos. La Sociedad globalizada en la era de la
información, deslumbra un amplio campo de acción para las empresas, pero también implica una
fuerte competencia en cada sector; es por ello, que es de tal importancia mantenerse al tanto de
las nuevas herramientas y la manera de integrarlas, si es posible, a las necesidades de
organización particular. Sin embargo, no sólo se debe procurar estar al tanto de las nuevas formas
de conocimiento sino que se debe buscar formar el propio, mediante investigación seria y
responsable.
Una de las disciplinas que se ha venido desarrollando en gran manera en las últimas décadas y
que cuenta con múltiples aplicaciones, es la simulación mediante ordenadores. La simulación
permite la representación de sistemas muy complejos mediante modelos más sencillos, lo que abre
la oportunidad del estudio del sistema para: investigar la viabilidad de variantes a implementar en
los recursos o procesos, sin la necesidad de invertir “a ciegas”; descubrir oportunidades dentro del
sistema ya existente, conservando lo bueno y mejorando lo que sea posible; analizar la posibilidad
de utilizar prácticas que se han obtenido por medio del “Benchmarking”, ya sea interno o externo,
si representa un beneficio; entre otras.
La simulación como tal, tiene cierto tiempo de estar al servicio de la sociedad principalmente como
una herramienta matemática en todo tipo de disciplinas desde la logística militar o civil, en el
ámbito financiero, inclusive en medicina, en la preparación de estudiantes; es por esto que puede
considerarse como un área de estudios completa que sirve a muchos propósitos del conocimiento
humano. Algunos juegos de video se basan en los fundamentos teóricos de la simulación, para
representar realidades virtuales con un giro lúdico; ahora es posible instruir a un aprendiz de piloto
en los aspectos básicos de su entrenamiento sin ponerle en peligro. Sin lugar a dudas la
xvi
simulación ha avanzado mucho desde sus comienzos, hasta convertirse en la gran asistencia que
es para la sociedad actual.
En el área particular del estudio y mejora de los procesos, en el caso de Ingenieros Industriales o
Ingenieros en sistemas, encontramos una gran variedad de software, que sirven tanto para fines
didácticos como a nivel de ingeniería y reingeniería de procesos, manejo de recursos, análisis de
impacto financiero de cambios en los procesos. Uno de éstos, y del que trata el siguiente
documento, es el software Arena® por Rockwell Automation. Arena es un software diseñado como
un asistente mediante el modelado de sistemas de negocio, principalmente en el área de logística y
manejo de la cadena de suministros, aunque es flexible como para analizar sistemas de servicios y
producción. Arena trabaja en base a módulos que permiten al analista representar la estructura
lógica del sistema, desde el momento en que la entidad es creada, se desplaza a lo largo del todo
sistema, pasando por procesos, capturando recursos hasta que finalmente es desecha o
despachada por el sistema.
Con Arena se pueden representar una infinidad de configuraciones, según se dispongan los
módulos en orden y cantidad, pero además cuenta con una sección de módulos que permiten
tomar en cuenta variables contenidas entre procesos, como el tiempo que tomará a una entidad
llegar desde la localización de un proceso a la localización de otro. Esta sección de módulos se
encuentra bajo el nombre de “Advance Transfer” y permite profundizar más en la simulación,
describiendo mejor sistemas en donde la transferencia de entidades entre procesos no es
“inmediata”.
Una de las ventajas que tiene Arena, en comparación con otros software, es que tiene disponible
código VBA (Visual Basic For Applications), esto le proporciona más flexibilidad que si solamente
se manejara con los módulos. El código VBA, mediante su interfaz el Editor Visual Basic permite el
control de objetos mediante comandos al programador, además de ser una forma adicional de
introducir información a los módulos.
Existen muchas características de Arena que lo hacen un software muy atractivo para análisis de
sistemas; entre estos se encuentran su animación y módulos de flujo (útil para representar
sistemas que manejan substancias), pero quizá las herramientas más interesantes son las que se
utilizan para analizar datos con soporte estadístico como lo son: Input Analyzer, Output Analyzer,
Process Analyzer.
El Input Analyzer, proporciona la capacidad de analizar datos provenientes de otros programas,
como procesadores de texto y hojas de cálculo; por medio de este se puede determinar la
distribución de probabilidad que mejor se ajusta a los datos, utilizando pruebas de bondad de
xvii
ajuste. Mientras que el Output Analyzer, analiza la información generada por el mismo Arena
utilizando pruebas de hipótesis para determinar si existe o no diferencia significativa entre dos
escenarios distintos, con la limitante de que solamente puede analizar dos simultáneamente.
También en la misma línea de evaluación de alternativas se encuentra el Process Analyzer, que
permite la evaluación de dos o más alternativas, utilizando un método estadístico que discrimina
entre las mejores alternativas, arrojando más de una según si no son significativamente diferentes
entre sí; cuenta también con un asistente de gráficos, que muestra las repuestas de los escenarios
e identifica claramente las mejores alternativas.
Es el deseo de los autores que éste documento sirva como un manual de gran ayuda para fines
didácticos y que estimule el desarrollo de la investigación de sistemas mediante la simulación en el
país.
1
CAPÍTULO 1: GENERALIDADES
1. ABC
1.1. OBJETIVOS
1.1.1. OBJETIVO GENERAL
Desarrollar las guías para el laboratorio de la materia de simulación, utilizando el software ARENA.
1.1.2. OBJETIVOS ESPECÍFICOS
Determinar los temas que se abordarán en los laboratorios y la secuencia que se
impartirán, basándose en el programa de la materia de simulación.
Elaborar las guías de manera que el manejo del software ARENA sea accesible para el
estudiante y pueda aplicar los conocimientos teóricos en la creación de modelos de
simulación.
Desarrollar guías de laboratorio que permitan la práctica y fortalecimiento de los
conocimientos adquiridos en la cátedra de simulación.
Desarrollar las guías con el propósito de facilitarle al instructor su tarea de dirigir el trabajo
de los estudiantes.
1.2. LÍMITES Y ALCANCES.
Este documento pretende ser una guía que oriente el trabajo que se realizará en las prácticas de
laboratorio. Con la intención de facilitar el aprendizaje de los estudiantes en la parte práctica de los
modelos de simulación y auxiliar al catedrático en la ilustración de la dimensión aplicable de la
materia.
Además las guías estarán elaboradas de tal forma que apoyen la tarea del instructor de orientar a
los estudiantes en el desarrollo de los laboratorios.
Introducir los conocimientos básicos del software ARENA que se utilizará en la materia de
simulación de una manera simple y práctica tratando que el contenido de las guías refuerce los
conceptos difundidos en clase.
Debido a la finalidad de este trabajo, solo se abordarán algunos módulos en las prácticas
quedando a libertad del estudiante explorar aquellos que queden fuera de estudio.
2
1.3. ANTECEDENTES.
En la Universidad “José Simeón Cañas”, particularmente en la Facultad de Ingeniería y
Arquitectura, se han realizado proyectos de graduación de gran similitud al que se tiene por
objetivo elaborar. Anteriormente se han desarrollado guías de laboratorio correspondientes a
materias que también forman parte del pensum de la carrera de Ingeniería Industrial, como lo son
las guías correspondientes a las materias de Investigación de Operaciones I y II. Inclusive se
desarrollo, como proyecto de graduación para el título de Ingeniero Industrial, una serie de guías
de laboratorio para la materia de simulación pero utilizando como software de apoyo
PROCESSMODEL.
El proyecto de graduación concerniente a la elaboración de la guías de laboratorio de Investigación
de operaciones I y II se tituló: “DESARROLLO DE MANUALES DE LABORATORIO DE
INVESTIGACIÓN DE OPERACIONES I Y II”, y se presentó en el mes de Mayo del año 2008, para
optar al grado de Ingeniero Industrial. En este documento el primer paso fue la selección de
recursos, que básicamente consiste en un evaluación mediante el método del AHP de las distintas
alternativas de software que se podrían utilizar para impartir los laboratorios; en el caso que aborda
este trabajo no se realizará tal labor porque el programa que ocupará ya está determinado, es el
Software ARENA de Rockwell.
En cuanto al proyecto de graduación que desarrolló las guías de simulación utilizando
PROCESSMODEL, éste se tituló: “DESARROLLO DE LAS PRÁCTICAS DE LABORATORIO DE
SIMULACION CON EL SOFTWARE PROCESSMODEL”, y fue presentado en Octubre del año
2002. Este trabajo abordó los conceptos de la materia a manera de una introducción teórica, para
luego pasar a describir cómo utilizar el software y como trabajar con él para realizar simulaciones.
Otro proyecto de graduación muy similar al anterior fue desarrollado utilizando el software Pro-
Model. El titulo de dicho trabajo fue: “DESARROLLO DE GUIAS DE LABORATORIO DE
SIMULACION PARA MANUFACTURA UTILIZANDO EL SOFTWARE PRO-MODEL”, y fue
presentado en Mayo del año 2007. En este proyecto se abordaron conceptos básicos de la
simulación para luego pasar a describir detalladamente las herramientas que proporciona el
software y como anexo se presentaron las guías que se utilizaron en los laboratorios.
1.4. LIMITANTES
Dentro de las limitantes se tiene el factor tiempo el cual impide que la investigación y desarrollo del
documento se haga posterior a los cinco meses que la universidad proporciona para desarrollar el
tema.
3
Para el desarrollo de las guías se utilizará una copia del programa ARENA versión 10.0
proporcionada por el asesor la cual difiere a la utilizada en los laboratorios de simulación, los
cuales utilizan la versión 12.0. La versión 10.0 del software ARENA es una versión didáctica la cual
presenta una guía muy completa del funcionamiento del software. Si bien, todas las herramientas
utilizadas para desarrollar las guías con la versión 10.0 se pueden desarrollar con la versión 12.0,
hay ciertos módulos que se abordarán en el trabajo los cuales se deben desarrollar exclusivamente
en la versión 12.0.
La falta de un programa de estudio actualizado de la materia de simulación, el cual trabaje en
paralelo con el software de apoyo, ARENA, para lograr un máximo desempeño y aprendizaje tanto
teórico como práctico.
5
CAPÍTULO 2: INTRODUCCIÓN A LA SIMULACIÓN.
2. ABC
2.1. DEFINICIÓN
Según Robert Shannon (1975) “La simulación es el arte de diseñar y desarrollar
un modelo computarizado de un sistema o proceso y conducir experimentalmente con este modelo
con el propósito de entender el comportamiento del sistema del mundo real o evaluar
varias estrategias con los cuales puedan operar el sistema”.
Naylor et al. (1966), la define así: "Simulación es una técnica numérica para conducir
experimentos en una computadora digital. Estos experimentos comprenden ciertos tipos de
relaciones matemáticas y lógicas, las cuales son necesarias para describir el comportamiento y la
estructura de sistemas complejos del mundo real a través de largos periodos de tiempo".
Para Shubik (1960): “Es un modelo, dice que la simulación de un sistema o de un organismo es la
operación de un modelo lo cual se va a llamar simulador el cual es una representación del sistema.
Este modelo o simulador estará sujeto a diversas manipulaciones, las cuales serían imposibles de
realizar, demasiado costosas o imprácticas. La operación de un modelo puede estudiarse y con
ello conocer las propiedades concernientes al comportamiento del sistema o subsistema real –
costoso”.
Utilizando la simulación es posible representar sistemas reales mediante “modelos” que reflejen el
comportamiento de dichos sistemas, haciendo énfasis en los aspectos que el estudio considere
relevantes. Es una herramienta de gran utilidad cuando se desea realizar análisis de distintos
escenarios en un sistema que cuenta con una amplia gama de variables a tomar en cuenta.
La simulación es de utilidad para empresas que desean experimentar con un nuevo sistema, ya
sea en atención al cliente o un determinado proceso de producción, porque usualmente es más
económico que realizar un proyecto piloto de experimentación con el nuevo sistema. Éste podría
tener una falla intrínseca, difícil de observar, pero que representaría un costo evitable de haber
realizado una simulación.
El campo de la simulación es muy diverso, se ha utilizado en la medicina para el entrenamiento de
nuevos especialistas, permitiendo simular el entorno de una operación sin que la vida de una
persona sea expuesta en la práctica. También es de suma utilidad en todas las áreas de ingeniería:
permite simular la distribución de esfuerzos que experimentaría una edificación en determinadas
condiciones; solución de problemas complejos, por la cantidad de variables que se manejan, de
transferencia de calor o mecánica de fluidos; es aplicable al estudio de la teoría de colas; también
6
puede utilizarse para representar una red de distribución eléctrica y el funcionamiento de medidas
de contingencia en caso fallara el sistema; etc.
2.2. ENFOQUES PARA LA SIMULACIÓN.
Para simular un sistema se debe tener conocimiento de las secuencia de los sucesos y como se
abordarán en el modelo, es decir, el tipo enfoque que se ha de utilizar para seguir las sutiles
variaciones en el sistema a medida entran y salen las entidades, como son registradas dichas
variaciones y a cuales se le dará mayor prioridad. S. Barba (1985) señala tres enfoques para la
simulación de procesos:
1. Enfoque orientado al suceso (event orient). Se construye el modelo definiendo los cambios
que ocurren con cada suceso. Por tanto, en este enfoque lo que hay que determinar, son los
sucesos que pueden cambiar el estado del sistema, y desarrollar la lógica asociada con cada
tipo de suceso. La simulación se produce al ir avanzando el tiempo de suceso en suceso y
ejecutando la lógica de cada suceso al que se va llegando.
2. Enfoque orientado a actividades (activity scanning). Se describen las actividades en las que
las entidades del modelo se ven ocupadas, y se definen las condiciones que determinarán el
inicio o fin de cada actividad, los sucesos de fin o inicio de actividad no se planifican como
tales, sino que ocurren como consecuencia de las condiciones antedichas. El tiempo simulado
avanza en forma síncrona, a saltos iguales sucesivos, en cada uno de los cuales se exploran
todas las actividades para ver si su status ha variado y obrar en consecuencia.
3. Enfoque orientado al proceso (process oriented). Combinan las filosofías anteriores, consiste
en modelar desde el punto de vista de la secuencia de operaciones o procesos, que tienen
que realizar las entidades que se mueven en el sistema modelado. Los sucesos se producen
de forma natural, al acabar los procesos. Es entonces cuando se actualizan el estado del
sistema, se mueven las entidades, que inician nuevos procesos, y se planifican el fin de los
mismos. El mecanismo interno de simulación es análogo al del enfoque orientado al suceso,
pero no es así desde el punto de vista de la modelización. Modelar de esta forma suele ser
muy simple e intuitivo, aunque a veces rígido.
2.3. TIPOS Y MÉTODOS DE SIMULACIÓN.
Cuando se lleva a cabo el modelado del sistema de simulación existen varios caminos para
diseñarlo, la elección del método a utilizar dependerá del propósito que se persigue con el estudio
de la simulación y los aspectos del sistema que se consideren de especial relevancia en el
posterior análisis. Existen, a la vez, varios tipos de simulación, según S. Barba (1985):
7
1) Según las variables utilizadas:
a) Simulaciones Estocásticas o Simulaciones Monte Carlo: cuando se trabaja con variables
aleatorias.
b) Simulaciones Deterministas: en caso de trabajar con variables que no son aleatorias.
2) Según la influencia del tiempo:
a) Simulación Dinámica: interviene el tiempo, el sistema evoluciona a través del tiempo (modelo en
ecuaciones diferenciales o en diferencias).
b) Simulación Estática: no interviene el tiempo, se representa el sistema en un instante
determinado (modelo con ecuaciones algebraicas).
3) Según el tipo de modelo utilizado:
a) Simulación Discreta: cuando las variables del modelo toman valores en un dominio discreto.
b) Simulación Continua: cuando las variables del modelo adoptan valores en un dominio continuo
(números reales). Los modelos de simulación continua son completamente diferentes a los de
simulación discreta. Dentro de ésta hay dos enfoques: Orientadas al bloque u Orientadas a la
ecuación.
c) Simulación combinada: cuando haya variables que tomen valores continuos y otras que los
tomen discretos.
2.4. VENTAJAS Y DESVENTAJAS DE LA SIMULACIÓN.
A continuación se presenta una serie de ventajas propuestas por E. Luque:
Permiten experimentar con un modelo del sistema, en vez del sistema real que está
funcionando, pudiendo controlar los parámetros del modelo y pudiendo replicar la simulación
de un modelo tantas veces como se desee. Una réplica, es una nueva simulación en la que
todos los parámetros y condiciones experimentales son idénticos a los de la simulación
anterior excepto los valores que pueden tomar las variables aleatorias.
Con los estudios de simulación, se puede descomponer en subsistemas un sistema
complicado, y estos subsistemas se pueden simular individual o conjuntamente con otros.
En los casos en que hay relaciones complicadas de naturaleza predecible y aleatoria, es más
fácil utilizar un proceso simulado que desarrollar un complicado modelo matemático que
represente todo el proceso que se estudia.
Permiten incluir el tiempo en el análisis de situaciones esencialmente dinámicas.
8
Provee de un medio de conocimiento del comportamiento de nuevos sistemas, con el objetivo
de mejorar los ya existentes, y así como para la puesta a punto de un medio susceptible de
proveer un conocimiento completo del sistema global y de sus componentes.
Permiten resolver un cierto tipo de sistemas de ecuaciones, o de transformaciones
matemáticas, que debido a su complejidad no pueden resolverse analíticamente.
Las técnicas de simulación no requieren simplificaciones y suposiciones hasta el grado, en
que las requieren las técnicas analíticas, y por tanto, cualquiera, aún sin ser técnico, la
utilizará con mayor facilidad.
Un modelo de simulación puede explicarse más fácilmente al personal administrativo, porque
esencialmente es una descripción del comportamiento de un sistema o proceso.
Con ellas se puede estudiar un sistema sin construirlo, sin perturbarlo y sin destruirlo, en
definitiva sin deformarlo; y a velocidades de comportamiento simulado mucho mayores que en
la realidad, por la capacidad de condensar en breves intervalos de tiempo presente, el tiempo
de acaecimiento de los sucesos previstos para el futuro y sin tener que soportar los problemas
reales inherentes a la introducción de estos cambios, no correr los riesgos de llevarlos a la
práctica.
Los procesos de simulación son herramientas muy efectivas de entrenamiento personal, y
generan una visión macro y micro del sistema bajo estudio mucho más profundo y detallado
que cualquier modelo analítico o numérico.
Permite la comparación de un cierto número de alternativas para ahorrar costes, aunque a
veces la simulación es cara, ganar dinero, evitar riesgos y hacer posible el análisis, que en la
realidad puede ser imposible.
Permite el desarrollo y/o validación de relaciones funcionales, buscando leyes ocultas bajo
apariencia multiforme de los fenómenos. Es decir, se pueden obtener sencillas expresiones
matemáticas del comportamiento del sistema en estudio, por medio de repetidas
simulaciones, para extraer interesantes consecuencias que la mera experimentación no
permite.
Es útil como entrenamiento profesional, para la formación de futuros responsables de un cierto
sistema en el conocimiento más profundo del mismo, o para familiarizarlo con un sistema o
una situación que puede no existir en la realidad.
En una toma de decisiones, los resultados de un modelo de simulación pueden ser
verdaderamente valiosos: análisis de sensibilidad que discrimine que variables de control son
más efectivas y en qué medida; contrastes entre políticas de gestión alternativas; análisis de
los efectos de situaciones anormales, etc.
En problemas en los cuales no se conocen anticipadamente todos los valores de las variables,
o sólo se conocen parcialmente y no hay manera de averiguarlos fácilmente; entonces con la
9
simulación, se pueden encontrar esos estados sucesivos, como pueden ser la estimación de
los riesgos, beneficios y posibilidades de éxito de un cierto proceso o de un cierto método.
A diferencia de los modelos de optimización analítica, los modelos de simulación tienden a
presentar mejores descripciones de la realidad.
En cuanto a las desventajas, o más bien limitaciones Luque enumera:
A causa de su relativa facilidad de aplicación, puede haber una tendencia a depender
frecuentemente de esa técnica, originando la sustitución de la simulación por técnicas
matemáticas analíticas cuando estas últimas sean más adecuadas.
La simulación no ésta exenta de las mismas deficiencias que otros modelos matemáticos,
como la imposibilidad de cuantificar todas las variables que afecten al comportamiento del
sistema, o que el número de variables que se revisan pueda sobrepasar la capacidad de la
computadora de la que se dispone.
Aunque los resultados sean correctos, una validación perfecta de un modelo de simulación es
prácticamente imposible de conseguir, y por tanto, las conclusiones que se obtengan
conllevan deformaciones achacables a los defectos de modelización.
2.5. METODOLOGÍA PARA LA SIMULACIÓN.
Para el desarrollo de una simulación se cuenta con una serie de pasos en secuencia lógica, que
facilitan la elaboración del modelo y permiten que los sistemas sean convenientemente
representados, tomando en cuenta la validez del modelo para su propósito establecido y la utilidad
de la información que será analizada. Existe pequeñas variaciones entre autores entre el nombre
de los pasos y que comprende cada uno, pero en general el procedimiento es estándar. La
secuencia propuesta por E. Luque es la siguiente:
1. Observación. Ésta lleva a la formulación del problema real que se estudia. Se trata de fijar
exactamente el problema que quiere abordarse, así como establecer el objetivo u objetivos
que se persigue en la simulación, limitantes y alcances
2. Recolección y procesamiento de la información requerida. Con la recolección lo que se indica,
es la necesidad de hacerse con todos los datos disponibles para la simulación del
comportamiento del sistema. Y el procesamiento no es más que la transformación de esos
datos en información que podamos utilizar imprescindible para simular un sistema.
Se pueden considerar tres posibles fuentes para generar información: datos históricos o series
temporales, opiniones de expertos y estudios de campo.
10
3. Formulación del modelo. Ya es sabido que modelar es más un arte que un técnica. Al
modelar, se caracterizan las relaciones que gobiernan la interacción de las componentes del
sistema y de las actividades endógenas y exógenas. La cuestión clave al modelar es saber
distinguir lo relevante de lo que no lo es. Porque el mejor modelo no es el más complejo y el
que tiene más detalles, sino el que, siendo muy simple, se adecua al objetivo perseguido, ya
que cuanto más detalles, más pesado, confuso y costoso de experimentar es el modelo
resultante.
4. Evaluación de las características de la información procesada. Es necesario para fabricar un
modelo determinar cuál será la distribución de probabilidad que gobierna la información o la
que mejor se ajusta, en caso de no existir una totalmente satisfactoria. Para determinar dicha
distribución son de utilidad pruebas estadísticas como:
a) Test referentes a valores medios.
b) Test referentes a variaciones.
c) Test referentes a recuento de datos, ej.: pruebas de bondad de ajuste.
d) Pruebas no paramétricas.
5. Programación del Modelo. Para ello se puede emplear los diseños generalizados y los
modulares (o de bloque). Es aconsejable que el programa tenga bastante flexibilidad para
adaptarse a los posibles cambios que impongan las futuras revisiones. Se pueden distinguir
las siguientes fases:
a) Elaborar un diagrama de flujo que muestre el efecto de las diferentes actividades sobre las
componentes importantes del sistema.
b) Diseñar la programación en algún lenguaje especial, para el caso de ésta tesis será el SIMAN.
c) Probar el programa en el ordenador hasta eliminar todos los errores.
d) Generar resultados.
6. Verificación del programa. En esta fase se comprueba que el programa se ajusta al modelo,
es una tarea esencial y muy laboriosa, así como también, consiste en buscar errores en el
código del programa, errores tales como la creación incorrecta de entidades, flujo erróneo de
las entidades en el modelo, etc.
7. Validación del Modelo. Puede ocurrir que aunque el programa funcione acorde y
correctamente con el modelo, éste sea inexacto, es decir, que no se ajuste a la realidad. Para
ello se debe comprobar que el modelo simulado reproduce resultados conocidos del sistema
real en estudio.
11
8. Experimentación o diseño de experimentación de simulación. Una vez verificado y validado el
programa, el sistema en estudio está recogido en el programa de ordenador y podemos
reproducir su comportamiento, en diversas situaciones cuantas veces se desee. Es
aconsejable una planificación rigurosa de la combinación de posibilidades de experimentación,
lo que se denomina un diseño experimental.
9. Documentación final y análisis de resultados. En un estudio de simulación, es preciso
documentar todo lo hecho en las distintas fases, para poder realizar revisiones o investigar
posibles errores de los resultados. El análisis de resultados consiste en recolectar,
sistemáticamente, los datos producidos por la simulación, calcular ciertas estadísticas, y por
último interpretarlas.
10. Implementación
12
2.6. ESQUEMA DE METODOLOGÍA PARAR EL PROCESO DE SIMULACIÓN
Figura 2. 1. Esquema de metodología para el proceso de simulación.
13
2.7. CONCEPTOS.
2.7.1. SISTEMA.
Según J Prawda, un sistema es un “Conjunto de objetos que interactúan entre sí como una unidad,
para la consecución de un propósito explícito o implícitamente definido”.
Los sistemas se pueden clasificar en según varios criterios, cada clasificación es útil de acuerdo al
propósito que se persigue. Estos se pueden clasificar de acuerdo a:
Influencia en el tiempo
Sistema Dinámico: Aquel que incluye la variable tiempo en él mismo, más no todo sistema que
tenga incorporada dicha variable tiene por qué ser un sistema dinámico, para que sea
dinámico debe aparecer explicitado cómo evoluciona éste, es decir, deberá existir un sistema
diferencial o en diferencias que siga el mismo, que serán denominadas ecuaciones del
movimiento.
Sistema Estático: Cuando las relaciones entre los elementos son inmutables.
Origen de las actividades:
Sistema Cerrado: Cuando no tiene actividades exógenas.
Sistema Abierto: El sistema que si posee actividades exógenas o actividades que están
determinadas fuera del sistema.
Efecto de las actividades:
Sistema Determinístico: Aquél que donde los efectos de una actividad se explican
completamente en función de sus entradas. Actividad Determinista, cuando es posible
describir completamente el resultado de una actividad.
Sistema Estocástico: Atendiendo a los efectos aleatorios producidos por una actividad.
Actividad Estocástica, cuando los efectos de la actividad varían aleatoriamente en distintas
salidas.
Cambios que producen las actividades en el sistema:
Sistema Continuo: Cuando los efectos de una actividad son continuos.
Sistema Discreto: Cuando los efectos de una actividad no son continuos y producen cambios
en el estado del mismo.
14
En toda simulación se deben estipular ciertos parámetros que representan el comportamiento del
sistema de interés, cada uno de estos parámetros tiene propiedades particulares e interactúa con
el sistema generando cambios en el mismo, estos son:
Entidades: Son los objetos de interés del sistema. Estos pueden ser: personas, objetos o
intangibles.
Atributo: Es una propiedad o característica de una entidad.
Suceso o Evento: Proceso que provoca uno o más cambios en el sistema.
Estado de un sistema: Es el conjunto de variables que son necesarias para describir el
sistema en cualquier momento: entidades, atributos y sucesos en valores numéricos, en un
determinado periodo de tiempo. El Estado del Sistema cambia cuando el valor de algunos de
estos parámetros también lo hace.
Evento: Es un suceso instantáneo que puede cambiar el estado del sistema.
Actividad: Son las tareas llevadas a cabo sobre las entidades.
Recursos: Los agentes usados para realizar actividades y movilizar las entidades, estos
pueden ser compartidos por varias actividades. Los recursos pueden tener características
tales como capacidad, velocidad, tiempo de ciclo y confiabilidad.
Localizaciones: Son todos aquellos lugares en los que una entidad puede detenerse para ser
transformada o esperar a ser transformada.
Controles: son los que deciden cómo, cuándo y dónde se realizan las acciones, así como
también, determinan la acción cuando se presentan ciertos eventos o condiciones. En el más
alto nivel, los controles los podemos encontrar en forma de políticas, planes u horarios,
mientras que en un nivel bajo están en forma de procedimientos o programas.
Variables: Condiciones que se crean y modifican por medio de ecuaciones matemáticas o
relaciones lógicas.
2.7.2. MODELO.
Un modelo es una representación de un objeto, sistema o idea, de forma diferente al de la entidad
misma. El propósito de los modelos es ayudarnos a explicar, entender o mejorar un sistema. Un
modelo de un objeto puede ser una réplica aproximada de éste o una abstracción de las
propiedades dominantes del objeto, es decir, es una simplificación del sistema.
Elementos de un modelo [Traducción de Shannon, 1975]
a) Componentes: son partes que cuando son vistas en conjunto forman al sistema. Algunas
veces nos referimos a los componentes como elementos o subsistemas. Por ejemplo, en un
modelo de un misil, los componentes pueden ser cosas como el sistema de propulsión, el
15
sistema de dirección, el sistema de control, el sistema estructural, etc. En el modelo de una
ciudad, los componentes pueden ser el sistema de educación, el sistema de salud, el sistema
de transporte, etc. En un modelo económico, los componentes podrían ser compañías o
firmas individuales, consumidores, sistema de producción, el mercado, etc.
b) Variables: son cantidades cuyos valores están determinados por las funciones o relaciones
dentro del modelo. Pueden reconocerse dos tipos de variables en los modelos de simulación:
exógenas y endógenas. Las exógenas son también llamadas variables de entrada, y son
aquellas generadas o producidas afuera del sistema, las variables endógenas pueden
clasificarse según su función, como variables de estado, si indican un estado o condición del
sistema; o variables de salida, si representan un resultado, producto o salida del sistema.
c) Parámetros: son cantidades cuyos valores pueden ser asignados de manera arbitraria por el
operador del modelo. Importante es mencionar que los parámetros son asignados una vez, y
se mantienen constantes a lo largo de la simulación, no así con las variables, que por lo
general cambian con el correr de la simulación.
d) Relaciones funcionales: las relaciones funcionales describen variables y parámetros en una
manera que muestra su comportamiento dentro de un componente o entre componentes del
sistema. Estas relaciones pueden ser determinísticas o estocásticas en su naturaleza. Por lo
general, ambos tipos de relaciones pueden tomar forma matemática de ecuación, en la que se
relacionan las variables endógenas y exógenas.
e) Restricciones: son limitaciones impuestas sobre los valores de las variables o en la manera en
que los recursos pueden ser asignados o consumidos. Dichas restricciones pueden ser
impuestas arbitrariamente por el analista o bien determinadas por la naturaleza del sistema a
simular.
f) Funciones de criterio: son las definiciones explícitas de los objetivos o metas del sistema, y
cómo son evaluadas. El término equivalente en la investigación de operaciones es función
objetivo. Por lo general, la intención de manipular el sistema es optimizar o satisfacer los
criterios establecidos.
Según G. Gordon (1986), existen principios que pueden ser utilizados como una guía al momento
de construir un modelo de simulación, estos principalmente se enfocan el tratamiento de la
información:
a) Formación en bloques: La descripción del sistema se debe organizar en una serie de bloques
o subsistemas, con el objetivo de simplificar las interacciones dentro del sistema. Cada bloque
explica parte del sistema que depende de unas variables de entrada y produce unas variables
16
de salida. Es decir, puede describirse al sistema como un todo en términos de las
interconexiones entre bloques.
b) Relevancia: En el sentido en que el modelo sólo debe incluir los aspectos del sistema
relevantes con los objetivos del estudio. Y aunque la información irrelevante en el modelo no
perjudica, se debe excluir debido a que aumenta la complejidad del modelo y genera más
trabajo en la solución del modelo.
c) Exactitud: Porque la información que se utilice debe ser exacta.
d) Agregación: Un factor adicional que debe considerarse, es el grado en que pueden agruparse
las distintas entidades individuales en entidades mayores. En algunos estudios pueden ser
necesarios construir entidades artificiales mediante el proceso de agregación.
Clasificación de los Modelos
Modelos físicos:
Son los que más se asemejan a la realidad, se encargan de modelar procesos.
Modelos analógicos:
Se encargan de representar una propiedad determinada de un objeto o sistema
Modelos denominados juegos administrativos:
Ya empieza a involucrarse al ser humano el comportamiento del ser humano. Ej.: modelos de
planeación, estrategias militares
Modelos abstractos (simulación):
Viene a ser una herramienta ya que se convierte en algo abstracto
Modelos matemáticos:
Se tiene en cuenta las expresiones materia y lógicas ejemplo: representar un objeto. Aquí se debe
hacer muchas suposiciones dentro de un modelo matemático
Clasificación de los modelos de simulación
1. Modelos determinísticos
Ni las variables endógenas y exógenas se pueden tomar como datos al azar. Aquí se permite que
las relaciones entre estas variables sean exactas o sea que no entren en ellas funciones de
probabilidad. Este tipo determinístico quita menos de cómputo que otros modelos.
17
2. Modelos estocásticos
Cuando por lo menos una variable es tomada como un dato al azar las relaciones entre variables
se toman por medio de funciones probabilísticas, sirven por lo general para realizar grandes series
de muestreos, quitan mucho tiempo en el computador son muy utilizados en investigaciones
científicas
3. Modelos estáticos
Es que en ellos no se toma en cuenta el tiempo dentro del proceso, por ejemplo: los modelos de
juegos, modelos donde se observa las ganancias de una empresa
Ejemplo: Arquitectónicos: líneas de teléfono, tubos de agua
4. Modelos dinámicos
Si se toma en cuenta la variación del tiempo, ejemplo: la variación de la temperatura, del aire
durante un día, movimiento anual de las finanzas de una empresa.
En estos modelos físicos podemos realizar modelos a escala o en forma natural, a escala menor, e
escala mayor, sirven para hacer demostraciones de procesos como para hacer experimentos
nuevos.
5. Modelos a escala
Son los modelos sencillos de maquetas -> casa -> baño, cuartos, etc. También se pueden tener a
tamaño natural a menor o mayor escala, bidimensional, tridimensional.
19
CAPÍTULO 3: SOFTWARE ARENA
3. ABC
3.1. INTRODUCCIÓN
La simulación es una parte esencial para la reducción de riesgos y la mejora de toma de
decisiones, evaluación de inversiones y planificación; basado en la construcción de un modelo de
un proceso existente, así como de un proceso inexistente o hipotético, se puede simular el
funcionamiento de estos registrando diferentes alternativas, sin necesidad de detener su actividad
normal, para luego ser analizadas y tomar una decisión con base en estas pruebas.
Diferentes software han sido creados para la simulación y análisis de procesos de negocios, entre
ellos se encuentra Arena, el cual es un software diseñado exclusivamente para la simulación,
modelaje y análisis de situaciones reales en negocios, manufacturas, servicios, cadena de
abastecimiento, entre otros; es basado en un ambiente Windows, es decir, barras de herramientas,
menús y ventanas; si bien Arena está compuesto para realizar simulaciones de sistemas y
procesos, su objetivo es generar una herramienta que permita reducir el riesgo de una mala
inversión, identificar un impacto real de los cambios y mejoras que se tienen planeadas sin tener
que ser realizadas parcial o completamente.
El software Arena cuenta con diferentes aplicaciones tales como:
Documentar, animar y demostrar la variabilidad y dinámica de un mapa de procesos.
Análisis de procesos de negocios generalmente relacionado con el cliente y el manejo de
documentos.
Análisis de procesos simples de manufactura.
Arena es un software el cual dependiendo de su versión tiene diferentes características, desde una
edición básica académica con requerimientos mínimos y opciones básicas, hasta una versión para
empresas grandes especializada, en este documento se basará en la utilización de la versión 10.0,
básica y didáctica la cual contiene las siguientes características:
Plantillas.
Modelaje básico y lógica.
Analizador de datos de entrada.
Datos de salida del analizador de confianza estadística.
Analizador de procesos para ejecutar / comparación de escenarios.
Características.
Construcción de Modelo Visual – no requiere programación.
20
Modelo integrado de datos de interfaz de hoja de cálculo.
Conectores de diagrama de flujo animados.
Grabación de macros.
Diseño de experimentos.
Controles de ActiveX.
Modelaje Jerárquico / submodelaje.
Capacidad.
Simulación discreta.
Tutoriales.
SMART Libraries/Tutorials.
Manuales electrónicos y ayuda de comprensión en línea.
Conocimiento basado en la web.
Foro de usuarios en internet.
Conectividad.
VBA Visual Basic para aplicaciones de Microsoft.
Modelo de objetos de ActiveX para Control Externo.
Oracle, Access, Excel, SQL.
Enlace de importación AutoCad.
Enlace de importación de Visio.
Gráficos
Editor de gráficos 2D.
Editores de patrón de tiempo / calendario.
Symbol Factory Clipart
Microsoft Clipart/Cliboard Link.
Reportes.
Salidas de Crystal Reports.
Actividad basada en costos.
Exporter resumen de estadísticas a Excel/Access.
Documentación de model HTML.
Aplicaciones.
Procesos de negocios, servicio al cliente, flujo de papeles.
21
3.2. ENTORNO DE TRABAJO
Arena es un programa para un ambiente de trabajo basado y diseñado para Windows, su entorno
incluye barra de herramientas, menús y ventanas, tal como se muestra en la figura 3.1:
Figura 3. 1. Ambiente de trabajo Arena
Entre los diferentes menús que contiene el software se encuentran:
Menú File(archivo): contiene la interface de abrir y crear nuevos archivos de arena, así como
guardar e impresión, también se incluye la opción de importar dibujos CAD con formato DXF para
utilizarlos como fondos o elementos activos (DXF import). Ver figura 3.2.
Vista de organigrama Ventana del modelo
Hoja de Calculo
Barra de
procesos
básicos
22
Figura 3. 2. Menú "File"
Menú Edit: este menú (figura 3.3) contiene las opciones básicas de edición como lo es pegar
(paste), copiar (copy), cortar (cut), borrar (delete), deshacer (undo), rehacer (redo), etc. también la
opción Find con la cual se pueden buscar módulos y objetos de animación, la opción properties
(propiedades) que muestra la propiedades de cada objeto, Link la cual muestra los enlaces que
contenga el modelo permitiendo modificarlos. Insert New Object, permite insertar objetos de otras
aplicaciones como gráficos u objetos multimedia.
23
Figura 3. 3. Menú "Edit"
Menú View (Ver): con este menú (figura 3.4) se controla la visualización del modelo que se está
trabajando, por medio de la opción Views (vistas), Zoom, toolbars (barras de herramientas),
permite controlar diferentes facetas como poner o quitar cuadricula (Grind) y agregar flechas de
dirección a los conectores (Connector Arrows); named views (vistas nombradas) sirve para
personalizar y crear accesos directos de las vistas, la opción layers permite elegir los tipos de
objetos que se mostraran durante la edición o ejecución.
24
Figura 3. 4. Menú "View"
Menú Tools (Herramientas): En el menú (figura 3.5) se encuentran las opciones para cambiar y
personalizar la forma y aspectos de trabajo de Arena de acuerdo a lo que se necesite, la opción
Input Analyzer (Análisis de entrada) permite encajar distribuciones de probabilidad sobre un
conjunto de datos de entrada, es posible escribir un código de programación en Visual Basic para
completar un modelo con la opción Show Visual Basic Editor, así como también, contiene las
opciones para importar o exportar bases de datos
25
Figura 3. 5. Menú "Tools"
Menú Object (objeto): Este menú (figura 3.6) controla las conexiones entre objetos, animación de
conectores y sub-modelos, la opción Smart Connect (conexión inteligente) divide las nuevas
conexiones realizadas en segmentos para una mejor organización, también se puede agregar, abrir
o cerrar un submodelo.
Figura 3. 6. Menú "Object"
Menú Arrange (organizar): Con el menú Arrange (figura 3.7) es posible organizar los módulos y
gráficos del modelo como traer al frente (Bring to front), agrupar (Group), desagrupar (Ungroup),
rotar (Rotate), alinear (Align), entre otros.
26
Figura 3. 7. Menú "Arrange"
Menú Run (Ejecutar): Dentro de este menú (figura 3.8) se controla la ejecución (Go) del modelo,
así como la configuración de la simulación y los reportes requeridos en la opción Setup; se puede
comprobar la existencia de errores (Check Model) antes de una corrida, pausar o revisar paso a
paso (Step) por errores.
Figura 3. 8. Menú “Run”
27
3.3. BARRAS DE HERRAMIENTAS
Cada menú contiene gran parte de sus opciones o todas sus opciones en una barra de
herramientas, todo está sujeto a la personalización del menú View (vista) de cada usuario, como
por ejemplo:
La barra de menú Standard (figura 3.9) contiene la mayoría de las opciones del menú File
(archivo), menú Edit (edición), menú Run (ejecutar), etc.
Figura 3. 9. Barra de Herramientas "Standard"
Para el menú Arrange (figura 3.10) es posible utilizar la barra de herramientas arrange la cual
contiene todas las opciones del menú.
Figura 3. 10. Barra de Herramientas "Arrange"
Existen algunas barras de herramientas cuyas opciones no provienen de un menú, como lo son:
la barra de herramientas Draw (figura 3.11), la cual permite dibujar líneas, arcos, figuras,
agregar cuadros de texto, dar configuración a un texto, con el fin de personalizar el modelo.
Figura 3. 11. Barra de Herramientas "Draw"
La barra de herramientas Animate (figura 3.12) donde es posible modificar o agregar
animación a los objetos. Es posible agregar gráficos de seguimiento con el botón Plot
28
también se puede, con el icono resource , agregar un recurso animado de acuerdo a
algún proceso existente dentro de modelo
Figura 3. 12. Barra de Herramientas "Animate"
La barra de herramientas Animate transfer (animación de transferencia)(figura 3.10) sirve
para la animación de objetos de transferencia.
Figura 3. 13. Barra de Herramientas "Animate Transfer"
Todas las barras de herramientas pueden ser modificadas y personalizadas por medio de el menú
View, Menú View > Toolbars…, en la pestaña Toolbars se pueden elegir las barras de
herramientas que se desean ver así como las que se deseen quitar, en la pestaña Customize se
puede personalizar estas barras de herramientas tal como se muestra en la figura 3.14.
Figura 3. 14. Cuadro de Diálogo "Customize"
29
3.4. BARRA DE PROYECTOS (PROJECT BAR)
La barra de proyectos contiene todos los paneles de módulos y navegación que se utilizan en la
simulación con Arena, el más utilizado y la base, como su nombre lo dice, es el panel de procesos
básicos ya que contiene los módulos más utilizados en los sistemas simulados.
Algunos paneles no se encuentran como predeterminados al abrir el programa Arena, por lo tanto
es necesario agregarlos para poder utilizarlos, para ello se recurre al menú File > Template Panel
> Attach…, o dando click en el botón Attach Template.
Otros paneles que contiene la barra de proyectos son:
Panel de procesos avanzados (Advanced process): el cual contiene módulos que son
utilizados para simular situaciones y procesos con una mayor complicación, con una mayor
cantidad y ajuste de variables, búsqueda datos, etc.
Panel de navegación (Navigate): con este panel es posible moverse a través de todo el
sistema simulado, salir y entrar en los submodelos y recorrer toda la página.
Panel de reportes (reports): al terminar una simulación, los datos que se generan son
organizados en reportes, los cuales pueden ser visualizados con éste panel.
Panel de transferencia avanzada (Advanced Transfer): es necesario para la simulación de
transporte y movimientos de entidades, para aproximar de una manera más exacta la realidad
3.5. PANEL DE PROCESOS BÁSICOS
Para la creación de un diagrama de flujo de un modelo en Arena se necesitan diferentes módulos
para creación de entidades, procesos, salida de las entidades, decisiones; para ello, se utiliza la
barra de procesos básicos, ubicada generalmente a la izquierda de la ventana, la cual contiene
todos los objetos que se utilizan para la representación de un modelo de simulación, estos objetos
son también llamados módulos de flujo de datos (Flowchart modules); de igual forma esta barra
contienen las hojas de datos (spread sheets) básicas, las cuales almacenan todos los datos de las
colas, entidades, variables, calendarios, etc., tal como se muestra en la figura 3.15.
30
Figura 3. 15. Panel "Basic Process"
3.5.1. MÓDULO CREATE
Este módulo (figura 3.16) representa el punto de partida en cada uno de los modelos. Las
entidades son creadas basándose en un calendario predeterminado o utilizando una función de
probabilidad para definir el tiempo entre llegadas. Una vez las entidades son creadas, estas dejan
dicho módulo para comenzar a ser procesadas por el sistema.
Existe un diferencia entre la casilla “Name”, que identifica con un nombre único al módulo, además
de aparecer dentro de la figura que lo representa en el diagrama de flujo; y “Entity type”, que es el
nombre único del grupo de entidades que se crearán en ese módulo, y que tiene características
comunes como el dibujo que las representa y los costos que se les pueden asignar. Un mismo
“Entity type” puede generarse desde dos o más módulos “Create”.
Usos posibles:
Llegada de clientes al sistema.
Creación de piezas
31
Figura 3. 16. Módulo "Create"
3.5.2. MÓDULO DISPOSE
El módulo dispose (figura 3.17) es utilizado para representar y contabilizar la salida de las
entidades antes de abandonar el sistema por completo. Cuando las entidades arriban a este
módulo, Arena almacena las estadísticas de cada entidad para utilizarla posteriormente en la
creación del reporte y luego, dicha entidad desaparece del sistema. Usos posibles:
Salida de clientes del sistema
Salida de piezas del sistema.
Figura 3. 17. Módulo "Dispose"
32
3.5.3. MÓDULO PROCESS
Con este módulo (figura 3.18) se configuran los diferentes procesos que pueda llevar un modelo de
simulación, es posible definir el tipo de proceso, ya sea estándar o un submodelo, al igual que la
lógica y los recursos que forman parte del mismo. La lógica del proceso puede constar de una, dos
o tres de las siguientes operaciones: Seize representa la captura de uno o varios recursos por una
entidad, Delay representa la demora correspondiente a dicho proceso y Release representa la
liberación de las entidades por el recurso utilizado para capturar dicha entidad. Si en este módulo
se ha creado un recurso, y la capacidad de procesar las entidades es inferior a la tasa con la que
arriban a dicho módulo, se generará una cola en la cual se acumulan las entidades que están
esperando ser procesadas por el recurso asignado en ese proceso.
Al definir este módulo como un subproceso, todas las estadísticas de los procesos que se
desarrollan dentro de él, son presentadas en el reporte como un único proceso siendo la suma de
los procesos internos en dicho módulo.
Usos posibles de dicho módulo:
Proceso de atención a un cliente
Proceso de fabricación de una pieza
Proceso de inspección
Proceso de transporte de piezas
Figura 3. 18. Módulo "Process"
33
3.5.4. MÓDULO DECIDE
Este módulo (figura 3.19) permite crear decisiones dentro de los proceso ya sean en base a
condiciones o a probabilidades. Este módulo no genera ningún tiempo de valor agregado al
sistema. Las condiciones pueden ser definidas por el tipo de entidad, alguna variable especifica o
alguna expresión específica para dicho proceso. Al definir el módulo en base a condiciones, se
pueden generar dos a más condiciones las cuales se deben definir mediante operadores lógicos o
en base a valores o atributos de las entidades. Cuando una entidad llega a este módulo, se evalúa
en base a las condiciones y si cumple con una, dicha entidad es expulsada por la salida
correspondiente a esa condición, en caso contrario existe una salida particular para que las
entidades puedan salir del módulo. Posibles usos:
Envió de partes defectuosas en un sistema para su reprocesamiento.
Envió de clientes hacia diferentes procesos.
Figura 3. 19. Módulo "Decide"
3.5.5. MÓDULO BATCH
El módulo Batch (figura 3.20) permite agrupar un conjunto de entidades en lotes, del tamaño que
sea requerido; el tipo de Batch puede ser, permanente o temporal.
Un Batch permanente significa que el grupo de entidades se simularán como una sola a partir de
su agrupación y no serán separadas durante todo el proceso, un Batch temporal simula un grupo
de entidades que eventualmente dentro del mismo sistema serán separadas con un módulo
separate. Cuando las entidades llegan a este módulo, son enviadas hacia una cola en la cual
esperarán hasta que se tengan el número de entidades requeridas para formar un batch, cuando
se tienen suficientes entidades para formar el lote, las entidades son eliminadas y se crea una
nueva entidad en representación de las que fueron eliminadas.
34
La opción “save criterion” sirve para asignar valores representativos de todo el “Batch” a cada
entidad que sale del módulo y que representa a todo el grupo o lote, como puede ser el valor de
última, la primera o a suma de todas la entidades que conforman el batch. Si en el módulo no se ha
determinado el “Entity type” que utilizará la entidad representativa del “Batch”, se le asignará según
el criterio elegido, si es last, será el “Entity type” de la última entidad que ingresó al módulo.
Posibles usos:
Lotes de artículos
Simular un conjunto de artículos agrupados en cajas.
Un grupo de entidades necesita pasar por un procedimiento al mismo tiempo y luego
separarse.
Figura 3. 20. Módulo "Batch"
3.5.6. MÓDULO SEPARATE
El módulo separate (figura 3.21) es utilizado para separar entidades previamente agrupadas con la
modalidad de temporal, en un módulo batch, o para duplicar entidades en un sistema. Las
estadísticas de tiempos y costos de todo el sistema se ven afectadas al duplicar una entidad o
separar un batch por lo que en este módulo se definen los valores de las entidades que se
generan.
Cuando una entidad previamente agrupada llega a este módulo, dicho lote es desagrupado y las
entidades son liberadas mientras que la entidad que representaba el lote se elimina del sistema. Si
35
una entidad se desea duplicar, al llegar a este módulo se crearán copias de la entidad original más
la entidad original que ingreso al módulo. Posibles usos:
Ensamblar ciertas partes antes de comenzar un proceso
Unir un número definido de copias antes de ser almacenadas.
Figura 3. 21. Módulo "Separate"
3.5.7. MÓDULO ASSIGN
Este módulo (figura 3.22) permite asignar nuevos valores durante la simulación del sistema tales
como atributos, imágenes, u otras variables del sistema. Se pueden asignar múltiples valores
dentro de un mismo módulo assign.
Figura 3. 22. Módulo "Assign"
36
3.5.8. MÓDULO RECORD
Este módulo (figura 3.23) sirve para almacenar estadísticas de las entidades dentro del sistema
tales como tiempos y costos entre procesos, tiempos de salidas, intervalos entre diferentes
procesos, etc. Otra de las funciones de este módulo es un contador de piezas que sirve para tener
un control más detallado de las piezas que salen o entran en un determinado proceso.
Posibles usos:
Recolectar información específica, requerida por el usuario, como tiempo que una entidad
se tarda dentro del sistema.
La frecuencia en que un artículo sale del sistema.
Figura 3. 23. Módulo "Record"
3.5.9. MÓDULO ENTITY
Este elemento (figura 3.24) sirve para definir los costos relacionados a cada una de las entidades
generadas por el módulo create. Posibles usos:
Clientes se que moverán a través de un proceso con un costo de espera dado.
Elemento que serán procesados en el sistema con un costo de ensamble.
Figura 3. 24. Módulo de Datos "Entity"
37
3.5.10. MÓDULO QUEUE
En este elemento (figura 3.25) se define todo lo relacionado a las colas que se generan en ciertos
procesos como el módulo process y batch. El tipo de regla que se utiliza por defecto es FIFO pero
existen más reglas disponibles como LIFO, y otras basadas en atributos de entidades. También
existe la opción de compartir colas con otros procesos en el sistema. Posibles usos:
Cola de espera antes de entrar a un proceso
Cola de espera para formar un lote
Figura 3. 25. Módulo de Datos "Queue"
3.5.11. MÓDULO RESOURCE
Este módulo (figura 3.26) de datos define los recursos en un sistema de simulación, incluyendo
información de costes y disponibilidad del recurso. Los recursos pueden tener una capacidad fija
que no varía durante la simulación o pueden operar basándose en una planificación. Los fallos y
estados del recurso se pueden definir también en este módulo. Posibles usos:
Equipo o maquinara necesaria para procesar materiales
Empleados atendiendo clientes
Figura 3. 26. Módulo de Datos "Resource"
3.5.12. MÓDULO SCHEDULE
Este módulo (figura 3.27) de datos se puede usar en conjunción con el módulo Resource para
definir una operación de planificación para un recurso o con el módulo Create para definir una
38
planificación de llegada. Además, una planificación se puede usar y referir a factores de retardos
de tiempo basados en el tiempo de simulación. Posibles usos:
Planificación del trabajo incluyendo descansos.
Volumen de clientes que llegan a un sistema
Figura 3. 27. Módulo de Datos "Schedule"
3.5.13. MÓDULO SET
Este módulo de datos (figura 3.28) define varios tipos de conjuntos, incluyendo recursos,
contadores, cuentas, tipos de entidad, y figuras de entidad. Los conjuntos de recursos se pueden
usar en los módulos Process (y Seize, Release, Enter y Leave en el panel Advanced Transfer). Los
conjuntos counter y tally se pueden usar en el módulo Record. Los conjuntos queue se pueden
usar con Seize, Hold, Access, Request, Leave, y Allocate de los paneles Advanced Process y
Advanced Transfer. Posibles usos:
Maquinas que realizan una misma tarea.
Grupo de supervisores en un proceso.
Figura 3. 28. Módulo de Datos "Set"
39
3.6. PANEL DE PROCESOS AVANZADOS
Existen sistemas con un grado de complejidad superior del hasta ahora tratado. Al representar
dicho sistema mediante un modelo de Arena con los módulos de los procesos básicos (“Basic
Process Panel”) se incurre en una simplificación que muchas veces pierde de vista circunstancias
importantes que se desean evaluar. Para modelos como estos pueden resultar útiles los módulos
comprendidos en el panel de procesos avanzados.
Un ejemplo claro del grado de mayor complejidad que estos módulos aportan a la simulación, es la
existencia de los módulos diferentes: “Seize”, “Delay” y “Release”. Como se recordará cuando se
necesitaba utilizar un recurso para un proceso específico, el módulo “Process” tiene la opción
“logic” para determinar el tipo de retención del recurso que el módulo seguirá; pues bien, la
existencia de un módulo separado “Seize” permite al analista simular la captura del recurso por
parte de la entidad, sin tener que liberarlo inmediatamente. Esto puede ser de utilidad cuando la
entidad pasa por varios módulos distintos antes de liberar al recurso.
Al igual que los módulos del panel de procesos básicos, los procesos avanzados tienen dos
categorías de módulos los de diagrama de flujo (rectángulos de color amarillo), que son los que
aparecen en la ventana del modelo; y los módulos de datos (hojas de cálculo), utilizados para
definir características de procesos, lo cual se muestra en la figura 3.29.
En esta sección se presentaran únicamente los módulos que se ocuparan posteriormente en este
documento, y los módulos que aunque no aparecerán en las guías desarrolladas, son necesarios
para la completa comprensión de los módulos que sí se explorarán a lo largo de éste documento.
Si el lector desea ahondar en la comprensión de los módulos que no se han tratado en esta
descripción puede servirse de leer la Guía del Usuario que viene incluida al instalar el Software
Arena. Los módulos que se tratarán son los siguientes:
“Delay”
“Hold”
“Match”
“ReadWrite”
“Release”
“Seize”
“Signal”
“Adjust Variable”
“File”
40
Figura 3. 29. Panel "Advanced Process"
3.6.1. MÓDULO DELAY:
Este módulo (figura 3.30) permite al modelador simular un retraso programado en el sistema.
Cuando una entidad llega al módulo “Delay” ésta es retrasada dentro de éste de acuerdo a la
duración proporcionada por expresión de retraso que se le haya asignado. El tiempo puede ser
asignado a las categorías “value-added”, si el proceso agrega valor; “non-value added”, si no
agrega valor; “transfer”, si es un tiempo de movimiento entre procesos; “wait”, si es de espera;
“other”, si no aplican las anteriores. Los costos asociados son calculados de igual manera de
acuerdo a la asignación. Usos comunes son:
Duración de un proceso en una empresa de servicio.
Duración del “setup” o ajuste de una máquina.
Duración de la transferencia de un documento entre departamentos.
41
Figura 3. 30. Módulo "Delay"
3.6.2. MÓDULO HOLD:
Este módulo (figura 3.31) es utilizado para retener a una entidad en una línea de espera mientras
se envía una señal, cumple una condición o es liberada mediante el uso del módulo “Remove”.
En caso de que se desee programar el módulo para que espere una señal, se debe utilizar en
combinación con el módulo “Signal” que es el encargado de emitir la señal; si el caso es que
espera a una condición, la entidad esperará en el módulo hasta que dicha condición se cumpla; si
se ocupa la opción del módulo “Remove”, la entidad aguardará en el espera hasta que se le
permita seguir su procesamiento. Usos posibles:
Espera de una señal.
Retención de una parte para inspección.
Espera de una pieza para ensamble.
42
Figura 3. 31. Módulo "Hold"
3.6.3. MÓDULO MATCH:
Éste módulo (figura 3.32) se utiliza para juntar o formar grupos de entidades. El procedimiento
consiste en separar las entidades en varias categorías (hasta 5 por módulo) y formar líneas de
espera en cada categoría. El módulo libera una entidad de cada línea de espera cuando exista en
cada una por lo menos una entidad, las entidades son liberadas simultáneamente ó pueden ser
agrupadas por atributos (type: base on atrribute)
Para realizar la separación por categorías, el módulo cuenta con varios puntos de entrada que
automáticamente coloca las entidades en colas diferentes; sin embargo, también existe la opción
de separar entidades que han entrado en el mismo punto de entrada, esto mediante la
especificación de un atributo que los coloque en líneas de espera distintas. Ejemplos de usos:
Ensamble de partes.
Formación de paquetes con surtido de productos (se utiliza en conjunto con el módulo
“Batch”.
Sincronización de salida de dos o más entidades.
43
Figura 3. 32. Módulo "Match"
3.6.4. MÓDULO READWRITE:
Es utilizado para extraer datos (de una lista de variables, atributo u otra expresión) de un archivo
externo, del teclado o para escribirlos en un archivo externo. El tipo de archivo debe ser
especificado dentro del módulo “File”. Puede ser de especial utilidad cuando los datos reales se
encuentran ya en un archivo de base de datos u hoja de cálculo y desea importarlos, cuando por
comodidad los valores han sido generados y almacenados en este tipo de archivo o si se desee
exportar valores de resultado para un análisis desde otro programa. Para que la simulación se
ejecute el archivo debe, en efecto existir, lo cual no es problema si el analista ha desarrollado el
archivo en el mismo ordenador dónde se ejecuta la simulación; sin embargo, si se desea ejecutarla
en otro ordenador no se debe olvidar adjuntar el archivo correspondiente. Este módulo se presenta
en la figura 3.33.
Archivo secuencial o base de datos de Lotus. Cuando la entidad llega al módulo da la orden de
extraer o escribir los datos, el archivo externo con el que se trabaja se abre en caso no se
encontrase abierto.
Archivo de Microsoft Excel, Microsoft Access y objetos de información ActiveX. Cuando una
entidad arriba al módulo se examina el archivo externo respectivo por una conexión ADO. En caso
de que el programa no esté abierto, se crea una conexión ADO automáticamente usando Microsoft
Jet OLE DB Provider (si es un archivo de Microsoft Excel o Microsoft Access) o la especificada
“cadena de conexión” (si es un objeto de información ActiveX), para luego leer o escribir en él.
Archivo de lenguaje extensible. Cuando la entidad arriba al módulo, se evalúa si el archivo se
encuentra abierto, de no ser el caso el archivo es abierto automáticamente en un conjunto de
registro o “Recordset” ADO. Luego es posible extraer información del archivo o escribir en él.
Entre los usos que comúnmente se le da al módulo “ReadWrite”, se encuentran:
44
Lectura de números aleatorios de programas de cálculo, tipo Microsoft Excel.
Exportación de datos de costos de diversas corridas para su análisis.
Creación de un menú para el usuario final.
Figura 3. 33. Módulo "ReadWrite"
Figura 3. 34. Cuadro de diálogo "Assignments" del módulo "ReadWrite"
3.6.5. MÓDULO RELEASE:
El módulo “Release” (figura 3.35) se ocupa cuando se desea liberar unidades de un recurso, o
unidades de recurso comprendidas en un “set de recursos”, es decir, un grupo de recursos con
propiedades similares creado por el modelador, previamente capturado por una entidad. Se debe
explicitar para cada recurso, el nombre y la cantidad que será liberada. Una vez el recurso ha sido
liberado, éste se encuentra disponible para que sea capturado por otras entidades en espera.
Ejemplos de uso:
45
Finalización de una actividad de atención al cliente.
Autorización de una requisición de material por encargado de bodega. (libera al encargado de
bodega para otra labores)
Dar de alta en un Hospital.
Figura 3. 35. Módulo "Release"
Figura 3. 36. Cuadro de diálogo "Resources" del módulo "Release"
3.6.6. MÓDULO REMOVE:
Es utilizado para remover una entidad de una posición específica de una línea de espera, y luego
mandarla al módulo designado. Éste es útil al momento de construir una lógica del modelo que
permita remover una entidad de un módulo “Hold”; para ello se debe especificar el nombre de la
línea de espera del módulo “Hold” (en el campo “Queue Name”) y el lugar que la entidad ocupa en
46
la línea (en el campo “Rank of Entity”), el valor predeterminado es 1, indicando la primera entidad
en cola. Se muestra en la figura 3.37.
El funcionamiento del módulo consiste en que cuando una entidad arriba, éste remueve a la
entidad de la línea de espera; luego libera a la entidad que ha generado al suceso en el punto de
salida nombrado como “Original” (la entidad se pudo haber generado con el sólo propósito de
remover la entidad o no); para posteriormente liberar a la entidad removida de la cola en el punto
de salida nombrado como “Removed Entity” y la envía a otro módulo. Ejemplos de uso:
Remover una orden de la línea de espera, para ser completada.
Llamar a un paciente desde sala de espera para examinarle.
Tomar una solicitud de entre una pila de ellas.
Figura 3. 37. Módulo "Remove"
3.6.7. MÓDULO SEIZE:
El módulo “Seize” (figura 3.38) se encarga de asignar uno o más recursos a una determinada
entidad; puede capturar unidades de recurso o “sets” de recursos. La entidad que entra al módulo
espera en cola hasta que todos los recursos de lo que necesita estén disponibles simultáneamente.
Se puede declarar el tipo de asignación de uso de recurso: si agregar valor, no agrega valor, es un
proceso de tránsito o de espera, etc.
Es importante recordar que para que otra entidad haga uso del recurso, éste debe ser liberado,
haciendo necesario usar en conjunto los módulos “Seize” y “Release”. Ejemplo de uso (de acuerdo
a los ejemplos sugeridos en el módulo “Release”).
Inicio de una actividad de atención al cliente.
Arribo de una requisición al escritorio de el encargado de bodega para su autorización.
Ingreso a un Hospital.
47
Figura 3. 38. Módulo "Seize"
Figura 3. 39. Cuadro de diálogo "Resources" del módulo "Seize"
3.6.8. MÓDULO SIGNAL:
Envía, a cada módulo “Hold” que la espera, una señal ordenándole liberar el número máximo de
entidades estipulado. Es absolutamente necesario para utilizar un módulo “Signal” que exista o en
el modelo un módulo “Hold”, pero no es necesario para un módulo “Hold” que exista un módulo
“Signal”.
48
Luego una entidad entra al módulo “Signal” la señal es enviada al módulo “Hold” (dicha señal no
tiene representación en pantalla), en este instante, las entidades que esperan la señal son
removidas de sus líneas de espera. La cantidad de entidades removidas depende del número
explicitado como máximo en el campo “Limit” y, en caso de que no exista en cola el número
máximo de entidades, depende del número que en ese momento haya en cola (se presenta el
ejemplo en la figura 3.40). Usos típicos:
Analizando el comportamiento de una máquina, esperando para emitir la señal.
Indicación de un que un proceso ha alcanzado su terminó y esta listo para el siguiente.
Figura 3. 40. Módulo "Signal"
3.6.9. MÓDULO ADJUST VARIABLE:
El módulo “Adjust Variable” permite al modelador ajustar una variable a cierto valor objetivo con
una tasa de cambio estipulada. Este es de gran utilidad para simular procesos que requieren un
aumento continuo en una variable a través del tiempo.
Es posible especificar el tiempo entre actualizaciones del módulo (el campo “Update Interval”). Esto
se vuelve útil cuando se esta graficando el comportamiento de la variable, con actualizaciones más
frecuentes se producen gráficas más suaves, sin saltos abruptos en el período en que la variable
alcanza su valor objetivo. La desventaja, al utilizar actualizaciones más frecuentes, es que
disminuyen la velocidad de ejecución de la simulación, debido a que una mayor cantidad de
cálculos es necesaria; por ello, si se desea incrementar la velocidad de ejecución se deben utilizar
actualizaciones no tan frecuentes (Ver figura 3.41). Ejemplos de usos:
Temperatura de un Horno en control.
Ingresos mensuales acumulados.
49
Figura 3. 41. Módulo "Adjust Variable"
3.6.10. MÓDULO FILE:
Es un módulo de datos, por lo que no tiene representación en la vista del diagrama de flujo. Este
debe ser incluido cuando se accede a archivos externos mediante el módulo “ReadWrite”, permite
identificar el nombre del archivo, define el método de acceso, formato y las características
operacionales de los archivos (ver figura 3.42). Ejemplos de uso (relacionados con los ejemplos
sugeridos en el módulo “ReadWrite”):
Archivo de números aleatorios de Excel.
Archivo de datos vacío, destinado a la escritura de datos de costos.
50
Figura 3. 42. Módulo de Datos "File"
3.7. PANEL DE MÓDULOS DE FLUJO
El panel “Flow Process” contiene módulos que sirven al constructor del modelo como herramientas
para la elaboración de modelos que reflejen sistemas tengan dentro de si procesos que involucren
el flujo o movimiento de substancias. Este panel puede ser de suma utilidad para modelar plantas
químicas o de tratamiento de aguas, que involucren el almacenamiento o retención de líquidos, y el
flujo de estos a una tasa específica.
En esta sección se presentarán los módulos que se abordarán posteriormente en el documento, a
saber: “Tank”, “Sensor”, “Flow”, “Seize Regulator”, “Release Regulator”. En la figura siguiente se
muestra el panel “Flow process”, tal como aparece en la ventana de trabajo de Arena.
51
Figura 3. 43. Módulo "Flow Process"
3.7.1. MÓDULO TANK:
El módulo “Tank” se utiliza para representar un dispositivo de almacenamiento de material. Viene
acompañado por una animación que simula a un tanque que retiene un líquido azul, a su vez,
posee dos cuadros de texto, como parte de su animación, que sirven de indicadores del
comportamiento dentro del tanque. Uno representa el nivel que alcanzado la substancia que el
tanque almacena, o en otras palabras, el volumen de substancia que se encuentra dentro del
tanque (“Tank level”); el otro representa la razón neta del flujo de substancia al interior del tanque
(“Tank Net Rate”), expresada en unidades de volumen (ninguna en específico) por unidad de
tiempo.
En el cuadro de diálogo se puede declarar la capacidad de almacenamiento del tanque, dentro del
campo bajo el nombre de “Capacity”. Además, cuenta con un campo destinado a especificar el
nivel inicial del tanque, bajo el nombre “Initial level”. (Figura 3.44)
Al seleccionar el botón “Add” (figura 3.45) del cuadro de diálogo se accede a declarar las
características de cada regulador, a saber: su nombre y la tasa máxima de flujo que se le permite,
con sus respectivas unidades de tiempo. La tasa máxima de flujo determina la velocidad en que se
vaciará o llenara el tanque, según sea un regulador de entrada o salida. Se puede añadir cuantos
reguladores se necesite para propósito de la simulación, cada uno con su propia tasa máxima de
flujo.
52
Figura 3. 44. Módulo "Tank"
Figura 3. 45. Cuadro de diálogo "Regulators" del módulo "Tank"
3.7.2. MÓDULO SENSOR:
El módulo “Sensor” permite al analista monitorear el comportamiento de las operaciones de un
tanque, para ello se debe ingresar el nombre del tanque que se desea monitorear; luego
seleccionar de la lista desplegable “Location Type” el tipo de medición que se utilizará, así:
selecciónese “Specific level” si se desea monitorear un nivel específico, escribiendo en el campo
que se encuentra a su derecha la cifra exacta; o “Percentage Capacity” si se monitoreará de
acuerdo a un porcentaje de la capacidad total del tanque respectivo.
53
Una vez especificado el valor objetivo, se debe especificar si el sensor se activará una vez el nivel
sobrepase ese valor o si lo hará cuando alcance un valor inferior, eso se realiza seleccionado de la
lista desplegable “Crossing Direction” la opción “Positive”, si se desea que se active cuando
alcanza un valor superior, o “Negative”, para un valor inferior al nivel objetivo.
El sensor puede o no estar habilitado, según sea el objetivo del constructor del modelo, ya sea
dejándolo habilitado desde el principio de la simulación o habilitándolo durante la ejecución con
ayuda de la lógica del modelo y la variable “Sensor ID”, lo cual no se discutirá aquí.
Se puede determinar que acciones ejecuta el sensor cuando está habilitado, las cuales
comprenden: regular el flujo de determinado regulador, mandar una señal o asignar una variable.
Sin embargo, ninguna de estas acciones se utilizará en este documento, sino que se habilitará la
casilla “Create Discrete Entity” para que cuando el sensor sea activado éste cree una entidad que
pueda se ocupada por la lógica del modelo para la ejecución de una acción.
Como último punto se aclara que la figura 3.46 que aparece sobre el módulo es una animación que
representa un semáforo que se mantiene con color rojo mientras permanece inactivo y cambia a
verde cuando se activa.
Figura 3. 46. Módulo "Sensor"
54
Figura 3. 47. Cuadro de diálogo "Actions" del módulo "Sensor"
3.7.3. MÓDULO FLOW:
Este módulo (Figura 3.48) permite el movimiento de substancia. Para declarar la acción que se
efectuará, dentro de la lista desplegable “Type” puede seleccionarse una de tres opciones:
“Transfer”. En cuyo caso se ordena a Arena que la substancia fluye de un tanque a otro.
Por lo que se debe de especificar el tipo de fuente de regulación (“Source Regulator
Type”), ya sea un regulador o un set de reguladores. En este documento no se discutirán
los set de reguladores. Luego de seleccionar el regulador, se debe seleccionar, por su
nombre, el regulador que fungirá como fuente y el que lo hará como destino del flujo.
“Add”. En este caso sólo es necesario seleccionar el tipo de regulación y el nombre del
regulador que servirá de destino del flujo.
“Remove”. Para esta opción solamente se selecciona el tipo de regulación y el nombre del
regulador que se utilizará como fuente del flujo.
Cuando una entidad arriba al módulo “Flow”, esta es retenida hasta que la primera de las
siguientes opciones ocurra: cuando la cantidad estipulada ha sido transferida, cuando una
señal ha sido enviada o cuando el tiempo indicado haya acabado. Para los objetivos del
documento se utilizara el límite de la cantidad estipulada, para lo que, en dentro del campo
“Quantity” se deberá escribir el valor o la expresión objetivo.
55
Figura 3. 48. Módulo "Flow"
3.7.4. MÓDULO SEIZE REGULATOR:
El módulo “Seize Regulator” (Figura 3.49) se utiliza para capturar uno o más reguladores. Un
regulador de tanque debe ejecutar una sola operación a la vez, es decir, que si el regulador ha sido
capturado para desarrollar cierta operación, no estará disponible hasta que sea liberado de dicha
operación. Cuando una entidad arriba al módulo espera en una línea de espera hasta que todos
los reguladores requeridos estén disponibles.
Para agregar reguladores simplemente se da clic sobre el botón “Add” y se elige el nombre del
regulador en la lista desplegable “Regulator Name”(Figura 3.50).
56
Figura 3. 49. Módulo "Seize Regulator"
Figura 3. 50. Cuadro de diálogo "Regulators" del módulo "Seize Regulator"
3.7.5. MÓDULO RELEASE REGULATOR:
Este módulo (Figura 3.51) se utiliza para liberar uno o más reguladores que han sido “capturados”
previamente por otras entidades, dejándolos disponibles para que otras entidades en espera
(dentro de una cola del módulo “Seize Regulator”) los utilicen para otras operaciones.
De manera idéntica al módulo anterior, para declarar los reguladores debe darse clic al botón “Add”
y luego elegirse el nombre del regulador de la lista desplegable “Regulator Name”(Figura 3.52).
57
Figura 3. 51. Módulo "Release Regulator"
Figura 3. 52. Cuadro de diálogo "Regulators" del módulo "Release Regulator"
3.8. LENGUAJE VBA EN ARENA
3.8.1. ¿QUÉ ES VBA?
Es un componente de Arena bajo licencia de Microsoft® Corporation. Es el mismo lenguaje de
programación que ofrece Microsoft Office en sus aplicaciones, tales como Microsoft Word o
Excel®. Con ésta aplicación es posible escribir código personalizado que aumenta la lógica del
modelo y, por ende flexibiliza la simulación para beneficio del usuario. Además al integrar la
aplicación VBA a Arena, los desarrolladores o usuarios pueden utilizar Arena con otros programas
58
que soportan la interface de programación Microsoft ActiveX™, que permite a las aplicaciones que
la poseen controlarse las unas a las otras.
La aplicación VBA soporta acciones que son definidas por lo que se llama un modelo de objetos.
Los desarrolladores construyen este modelo de objetos para suministrar una interfaz de modo que
el usuario pueda realizar, mediante el lenguaje de programación, lo que usualmente haría con el
mouse o teclado. El modelo de objetos incluye:
Una lista de objetos que se pueden controlar, tales como: hojas de cálculo y gráficos.
Colecciones de objetos, que son agrupaciones de objetos del mismo tipo.
Las propiedades de estos objetos que se pueden examinar o modificar, tales como: el nombre
de los objetos y el valor dentro de determinado campo (una celda de una hoja de cálculo).
Los métodos que se pueden efectuar sobre los objetos o que éstos pueden realizar, tales
como: crear o eliminar un objeto.
3.8.2. EL ENTORNO VBA
Para ingresar al editor de Visual Basic (VBE) se debe seguir la siguiente ruta: Tools > Macro >
Show Visual Basic Editor; presione las teclas Alt+ F1; ó simplemente presione el icono que
aparece en la barra de herramientas “Integration”, en caso de estar habilitada. El aspecto del VBE
se presenta en la figura 3.53:
Figura 3. 53. Ventana del Editor de Visual Basic de Arena
En el lado izquierdo se encuentra el panel “Project (Proyecto)” que muestra una lista de modelo
abiertos, conteniendo a su vez una lista de los objetos de Arena, siendo estos: “Logic” y
“ThisDocument”.
El objeto “Logic” no permite modificación por parte del usuario; éste contiene las funciones,
subrutinas y variables que son convertidas a código por parte de los módulos de Arena, es decir,
59
que los módulos sirven de interfaz del usuario con el editor de Visual Basic. El usuario no debe
escribir código adicional en este objeto, ya que este espacio es utilizado exclusivamente por Arena
para escribir código automáticamente mientras se ejecuta el modelo.
El objeto “ThisDocument” es, como lo pone en evidencia su nombre (en castellano “Este
documento”), una referencia al modelo mismo. Permite modificación mediante la introducción de
propiedades y métodos, que pueden se asociados con los módulos de Arena. El objeto
“ThisDocument” posee una colección de eventos que contienen el código VBA, según David Kelton
et al. en el libro Simulación con Software Arena, estos pueden ser catalogados en tres grandes
categorías, se presentan algunos de ellos en seguida:
Eventos previos a la ejecución, como: DocumentOpen [AbrirDocumento] o DocumentSave
[GuardarDocumento].
Eventos de ejecución iniciados por Arena, tales como: RunBegin [IniciarEjecución],
RunBeginSimulation [IniciarEjecuciónDeSimulación], RunEndReplication
[FinalizarEjecuciónDeReplicación].
Eventos de ejecución iniciados por el modelo/usuario, como: UserFuntion
[FunciónDelUsuario], VBA_Block_Fire [VBA_Block_Disparar], OnKeystroke
[GolpeDeTeclaParaAcción].
En este documento se le dará énfasis a lo eventos iniciados por la ejecución de Arena. Cuando se
inicia la ejecución del modelo Arena sigue una secuencia de eventos, en algunos de los cuales
puede ser introducido código VBA para flexibilizar la simulación. En caso de no existir código VBA
dentro de dichos eventos, Arena simplemente continúa la secuencia dando la impresión de que el
evento no existiera. Se muestra a continuación la secuencia de eventos, en negrita tal como se
definen en el libro Simulación con Software Arena, los eventos en los que es posible introducir
código VBA:
1. RunBegin (iniciarEjecución)
2. Arena hace las verificaciones e inicializa el modelo
3. RunBeginSimulation (IniciarEjecuciónDeSimulación)
4. RunBeginReplication (IniciarEjecuciónDeReplicación)
5. Arena ejecuta la replicación
6. RunEndReplication (FinalizarEjecuciónDeReplicación)
7. RunEndSimulation (FinalizarEjecuciónSimulación)
8. Arena termina la ejecución de la simulación
9. RunEnd (FinalizarEjecución)
60
MODELLOGIC_RUNBEGIN
En este evento es posible realizar cambios estructurales en la simulación, como por ejemplo para
preguntar sobre que valor de media que el usuario desea asignar a la distribución de probabilidad
de arribos del módulo “Create”. Empero, dado que no se ha ejecutado la simulación no es posible
modificar valores propios del tiempo de ejecución como los atributos de las entidades.
ARENA HACE LAS VERIFICACIONES E INICIALIZA EL MODELO
En este evento de Arena todas las variables tiene asignados sus valores iniciales, por mencionar
un ejemplo las capacidades de los recursos, pero no aún no se han introducido entidades al
modelo.
MODELLOGIC_RUNBEGINSIMULATION
Es en este evento que se debe insertar código VBA con el propósito que sólo se ejecute una vez al
principio de la simulación. Claro está, es necesario que el modelo no presente errores, de otra
manera no se ejecutará y Arena no “llamará” a éste evento. Puede ser utilizado para cargar
grandes cantidades de datos provenientes de fuentes externas tales como Excel, asignar valores a
las variables en el modelo de Arena, crear entidades, modificar las capacidades de recursos, etc.
MODELLOGIC_RUNBEGINREPLICATION
Durante la simulación, al principio de cada réplica Arena llamará a este evento. Sus aplicaciones
son similares a las descritas en el evento anterior (ModelLogic_RunBeginSimulation), con la
excepción que lo que se defina aquí se repetirá en cada una de las réplicas programadas.
ARENA EJECUTA LA SIMULACIÓN
En este paso se ejecuta la simulación del modelo, contemplando todo los que el usuario definió en
su desarrollo, se crean entidades, se toman y liberan recursos, las unidades salen del sistema.
Arena permite la introducción de código VBA por medio de sub-eventos como:
ModelLogic_UserFunction: se llama siempre que se hace referencia a la variable UF en la
lógica de Arena. Se podría utilizar este evento para realizar cálculos complejos para la demora
de un proceso o el criterio de decisión.
ModelLogic_VBA_Block_Fire: se llama cuando una entidad pasa a través de un módulo VBA
(aparecen en el panel Blocks) en la lógica del modelo.
ModelLogic_OnKeystroke: Se llama siempre que el usuario golpee una tecla en el curso de
ejecución de la simulación.
ModelLogic_OnClearStatistics: se llama siempre que se eliminan las estadísticas, como
cuando el tiempo de simulación llega al valor introducido para el periodo de calentamiento.
61
MODELLOGIC_RUNENDREPLICATION
Es llamado cuando cada réplica llega a su fin, por lo que si se suspende la simulación antes de que
la réplica termine el evento no se ejecutará. Puede ser utilizado para almacenar la información
proveniente de cada réplica en un archivo externo.
MODELLOGIC_RUNENDSIMULATION
Este evento es llamado cuando finalice la simulación, independientemente de cómo finalice ésta.
Aquí todavía siguen disponibles los datos del tiempo de ejecución de la simulación para la toma de
estadísticas.
ARENA TERMINA LA EJECUCIÓN DE LA SIMULACIÓN
En este evento Arena elimina todos los datos del tiempo de ejecución de la simulación.
MODELLOGIC_RUNEND
En este evento no se puede tener acceso a la información de tiempo de ejecución de la simulación,
sin embargo, es posible introducir código VBA a manera de un “UserForm” consultando si desea
ejecutar la simulación de nuevo.
3.8.3. FORMULARIOS USERFORM
Los formularios proporcionan al creador del modelo una herramienta hacer cambios fácilmente en
la lógica del modelo, mediante la inclusión de un programa ejecutable que pregunta al usuario o
analista, al principio o durante la simulación, el valor que se desea asignar a uno o más parámetros
definidos en el formulario. Para crear un formulario, una vez en el editor insértese desde el menú
“Insert” del editor siguiendo la ruta Insert > Userform; este comando creará un formulario con el
nombre de “UserForm1”, a un lado de dicho formulario se verá también un cuadro llamado “Control
Toolbox”, que contiene todos las herramientas para controlar el formulario, véase la figura 3.54.
62
Figura 3. 54. Formulario "UserForm"
La caja de herramientas “Toolbox”, proporciona varias opciones de diseño al modelador, bajo el
nombre de “Controls”. Estas herramientas forman las herramientas de control estándar. A
continuación se presentan una breve descripción de las más usadas de ellas, para ver las
descripciones de las herramientas restantes el lector puede hacer uso de la ayuda de Visual Basic
y buscar la categoría “Toolbox”.
Seleccionador de objetos. Es el único elemento dentro de las herramientas que no
dibuja un control, cuando se selecciona sólo se puede mover o cambiar de tamaño algún
control que ya se ha dibujado.
Etiqueta. Permite introducir texto al formulario que no es modificable por el usuario.
Cuadro de texto. Permite al usuario introducir texto o modificar el ya escrito.
Combo box. Permite dibujar una combinación de un cuadro de lista y un cuadro de
texto. De manera que el usuario puede escoger de una lista o escribir texto en ella.
Lista. Se utiliza para mostrar al usuario una lista de opciones de las que puede
escoger una.
Botón de Comando. Crea un botón que el usuario puede presionar para ejecutar un
comando.
63
3.8.4. PROPIEDADES DE UN FORMULARIO
Cuando se crea un formulario se tiene la opción de modificar su formato según convenga al
modelador o al usuario. Desde el editor de Visual Basic dese clic derecho sobre el formulario y
selecciónese “Properties”. Ver figura 3.55.
Figura 3. 55. Acceso a las propiedades del "UserForm"
Aparecerá el Editor de propiedades del Formulario (Figura 3.56). Cada campo representa una
determinada propiedad del formulario como: el color, el tipo y formato de letra, sus dimensiones, su
nombre, su comportamiento etc. La ventana de propiedades ofrece dos presentaciones, cada una
dentro de su respectiva pestaña. En la pestaña “Alphabetical”, se presentan las propiedades del
formulario en orden alfabético; y en la pestaña “Categorized” clasificadas en categorías, según su:
apariencia, fuente, comportamiento, dibujo, posición, desplazamiento y miscelánea.
64
Figura 3. 56. Ventana "Properties" del "UserForm"
3.8.5. NAVEGADOR DE OBJETOS
Para que el analista que utiliza código VBA pueda familiarizarse y hacer uso de la biblioteca de
objetos, VBA proporciona un navegador que le permite examinar las colecciones de objetos, sus
propiedades y métodos. Para visualizar el navegador, desde la ventana de Visual Basic Editor,
sígase la ruta View> Object Browser. En la figura 3.57 se presenta la vista del navegador.
65
Figura 3. 57. Navegador de Objetos, "Object Browser"
Como se puede ver en la figura el “Object Browser” permite, desde una lista desplegable,
seleccionar una librería en especial, de entre: Arena, Project, stdole, VBA; siendo la opción
predeterminada “All Libraries”, que engloba todas las anteriores. Justo bajo la lista desplegable de
librerías se encuentra la casilla de búsqueda, que permite la búsqueda de una colección de objetos
en especial, para ello basta con escribir en el campo y dar clic en el botón de búsqueda .
En el costado izquierdo de la ventana aparece la lista bajo el nombre “Classes”. Una “Class” o
clase representa la definición formal del objeto, que define las propiedades del objeto y lo métodos
utilizados para controlar su comportamiento. En la lista “Classes” se muestra las clases disponibles
en la librería, si existe código para la clase éste aparece en negrita.
En el centro del navegador de objetos aparece la lista “Members”, que representa los miembros o
elementos de la clase seleccionada. Los métodos, propiedades, eventos o constantes tienen
código que aparece en negrita. Si se selecciona una clase y no se selecciona un “miembro”, VBE
automáticamente seleccionará el miembro predeterminado.
En la parte inferior del navegador se localiza el panel de detalles, que muestra la definición de un
miembro de clase. Éste presenta en letras verdes la librería y clase a la que pertenece, por ejemplo
la propiedad que aparece seleccionada en la figura “Calendar”, muestra en el panel de detalles que
pertenece a la librería “VBA” y a la clase “Datetime”.
66
3.8.6. ESCRITURA DE CÓDIGO EN LA VENTANA DE VBA
La ventaja que proporciona el Editor de Visual Basic a la simulación con Arena es la flexibilidad que
aporta a la lógica del modelo, permitiendo el control de objetos mediante código VBA. Cada
formulario, cada módulo de clase y cada módulo estándar tienen su propia ventana de código. Los
objetivos del documento no contemplan un curso o explicación extensiva de código VBA, por lo que
sólo se introducirá generalidades.
El editor de código posee un código de colores, el código escrito por el usuario aparece en negro,
las palabras clave de Basic en azul, los comentarios en verde, los errores en rojo, etc. Esto permite
al programador identificar posibles causas de error del programa, y también facilita el trabajo al
analista que estudia el código sin haberlo creado.
En la parte superior de la ventana aparecen dos listas desplegables, la de la izquierda corresponde
a diversos elementos en los que se escribe código (“ModelLogic”, “UserForm”, etc.), la de la
derecha muestra los distintos procedimientos o eventos que corresponden con el elemento de la
izquierda
Anteriormente mientras se describía el panel “Project”, se discutieron los eventos que engloba el
objeto “ThisDocument”. Como se podrá apreciar en la figura 3.58, la ventana de edición de código
consta de las mencionadas dos listas desplegables, la izquierda con el título (General) y la derecha
con (Declarations). Como se trata del objeto “ThisDocument” en la primera lista desplegable sólo
cuenta con la opción “ModelLogic”, y en la derecha aparecen los eventos ya vistos: RunBegin,
RunBeginSimulation, RunEnd, etc. Al seleccionar un evento el encabezado del código es
automáticamente escrito, como aparece en la figura.
Figura 3. 58. Ventana de código del Evento "ModelLogic_RunBegin"
Para abrir la respectiva ventana de edición de código del formulario, se da clic derecho sobre el
formulario, como se muestra en la figura 3.59.
67
Figura 3. 59. Acceso a la ventana de código del "UserForm"
El editor del formulario presenta otras opciones, sus eventos correspondientes, dentro de la lista
desplegable en la parte superior derecha de la ventana, en la que la opción predeterminada es el
evento “Click”. Los distintos eventos permiten programar el formulario, con el apoyo de las
herramientas, de manera que cuando se vaya a ejecutar o se esté ejecutando la simulación el
usuario pueda, mediante la interacción con el formulario, introducir información o parámetros según
necesite para los propósitos de su análisis.
A continuación se muestra en la figura 3.60, la ventana de edición de código del formulario, con un
código que permite introducir en el campo “Entities per Arrival” del módulo “Create”, el valor que
introduzca el usuario en el cuadro de texto del formulario. Se puede apreciar en ella claramente la
utilidad del código de colores.
68
Figura 3. 60. Ventana de código del "UserForm", programando la subrutina "CommadButton1_Cilck"
69
CONCLUSIONES
La simulación utilizando el Software ARENA permite, de manera práctica y sencilla,
comprender y ejemplificar las relaciones que se establecen en los sistemas, tanto dinámicos
como estocásticos, brindando herramientas para la construcción de modelos que representan
problemas en las distintas áreas del conocimiento humano donde la experimentación no es
factible.
El software Arena tiene disponible un editor de código VBA (Visual Basic for Applications) lo
que le permite flexibilizar la lógica del modelo mediante la asistencia del control de objetos que
VBA provee, como es el caso de los formularios o alguno de los contenidos en la amplia
librería de objetos que posee. Los objetos de VBA permiten: extraer, introducir o comunicar
información entre los módulos de Arena, que de otra manera sería muy difícil de realizar;
además, ofrecen un método adicional de control sobre las entidades, recursos y procesos.
Con el apoyo de VBA es posible programar un modelo que facilite la labor del usuario final. El
programador se puede valer de formularios que simplifiquen la introducción de parámetros
que varían sensiblemente los resultados de la simulación, por lo que puede ser usada para un
análisis de escenarios diversos.
El panel de módulos de flujo ofrece una gama de herramientas útiles en el modelaje de
procesos que impliquen el manejo de sustancias, o bien, todo tipo de operaciones semi-
continuas, como sería operación de ensamblado en serie o de fabricación a alta velocidad.
Las animaciones correspondientes al panel facilitan la comprensión de los procesos, además
de proporcionar un instrumento didáctico en el estudio de simulaciones de este tipo.
Arena es un software de simulación orientado a las entidades, es decir, toda la ejecución gira
en torno a éstas; Para ello utiliza un flujograma, en base a distintos módulos para representar
los sistemas que se modelan.
Arena monitorea el recorrido de todas las entidades que entran en el sistema. En este tipo de
software orientado hacia las entidades, es la entidad la que captura el recurso y no a la
inversa. Sin embargo, es posible calcular porcentaje de utilización y eficiencia de procesos
mediante los datos proporcionados por las entidades y el tiempo global de ejecución.
70
Los modelos creados con un software de simulación como Arena no difieren por mucho de la
realidad; por lo tanto, es posible tomar como referencia los datos y conclusiones que se
generan de un modelo simulado para evitar riesgos y gastos en una situación real.
Al familiarizarse con la utilización del software ARENA, al estudiante le es posible la
implementación de conceptos y conocimientos adquiridos durante la cátedra de la materia de
Simulación, y de igual forma mantenerse actualizado con la tecnología de toma de decisiones.
Determinar, entre un grupo de alternativas cual es la que proporciona los mejores resultados
al sistema, es uno de los propósitos de la simulación. Process Analyzer y Output Analyzer son
herramientas que permiten evaluar diversos escenarios, creados en Arena, utilizando métodos
estadísticos de experimentación, gráficas, histogramas, etc.
Arena es compatible con programas externos como los paquetes de Microsoft Office,
documentos portables como PDF, procesadores de texto como NotePad, programas de
diseño de los paquetes CAD, etc. Esta compatibilidad ayuda al usuario a crear modelos más
complejos haciendo uso de otras herramientas especializadas en otras ramas.
71
RECOMENDACIONES
Se recomienda que el estudiante se familiarice con la teoría correspondiente a cada
práctica antes de realizarla, leyendo la respectiva guía de laboratorio previamente a su
desarrollo, facilitando la comprensión y asimilación de los temas.
El tiempo que se utilizará para la realización de cada práctica de laboratorio se encontrará
dispuesto en función del grado de dificultad de cada una; Es por esto que se recomienda
que la mayor parte del tiempo sea utilizado para la explicación de los elementos
avanzados, funciones, menús u otras herramientas que provee el software ARENA para
terminar, finalmente, con una retroalimentación de los conceptos a partir de la ejecución de
los ejercicios propuestos.
Para la comprensión de un software de simulación, la mejor forma es basar su
implementación en situaciones reales con el propósito de demostrarle al usuario como esto
puede ser una ventaja en un ambiente laboral.
Es imprescindible el contar con equipo suficiente y capaz para los laboratorios, y, de igual
forma, el mantenerlo actualizado ya que los cambios y mejoras en la tecnología actual son
cada vez más frecuentes.
73
GLOSARIO
Aleatorio: La palabra aleatorio se usa para expresar una aparente carencia de propósito,
causa, u orden.
Animación: La animación es aquella técnica para dar sensación de movimiento a imágenes
o dibujos.
Arribo: Llegada
Bloc de notas: Es el sencillo editor de textos que Windows pone a su disposición para que
cree o modifique sencillos archivos de texto sin formato
Código: En Informática, combinación de letras o de números que identifican un producto o
a una persona, permiten realizar determinadas operaciones o manejar algunos aparatos.
Coeficiente de variación: Es el cociente entre la desviación típica y la media aritmética.
Valores muy bajos indican muestras muy concentradas.
Control Toolbox (cuadro de Herramientas de control): Contiene todos los objetos y
controles que se pueden añadir a los formularios para crear aplicaciones.
Costo: Se denomina coste o costo al monto económico que representa la fabricación de
cualquier componente o producto, o la prestación de cualquier servicio
Desviación estándar: Raíz cuadrada de la varianza.
Diagrama de flujo: Representación sistemática de la secuencia de fases u operaciones
llevadas a cabo en la producción o elaboración de un determinado producto alimenticio.
Distribución de probabilidad: En teoría de la probabilidad y estadística, la distribución de
probabilidad de una variable aleatoria es una función que asigna a cada evento definido
sobre la variable aleatoria una probabilidad. La distribución de probabilidad describe el
rango de valores de la variable aleatoria así como la probabilidad de que el valor de la
variable aleatoria esté dentro de un subconjunto de dicho rango.
Evento de objeto: Un evento es una acción que es reconocida por el objeto. Un evento
ocurre (se dispara) como resultado de la interacción del usuario con el objeto. También
puede dispararse debido a la ejecución de código (sentencias) o como resultado de la
interacción de otro objeto con el objeto de poseedor del evento.
Histograma: Es una representación gráfica de una variable en forma de barras, donde la
superficie de cada barra es proporcional a la frecuencia de los valores representados. En el
eje vertical se representan las frecuencias, y en el eje horizontal los valores de las
variables, normalmente señalando las marcas de clase, es decir, la mitad del intervalo en
el que están agrupados los datos.
Hoja de cálculo: Software que permite que los usuarios trabajen con renglones y columnas
de datos.
74
Interfaz: En electrónica e informática, dispositivo que transforma las señales generadas por
un aparato en señales comprensibles por otro.
Lenguaje de programación: Un lenguaje de programación es un conjunto de símbolos y
reglas sintácticas y semánticas que definen su estructura y el significado de sus elementos
y expresiones. Es utilizado para controlar el comportamiento físico y lógico de una
máquina.
Lógica del modelo: Es la secuencia de instrucciones que se le ha indicado a Arena,
expresándolo generalmente por medio de sus módulos, que debe seguir durante la
simulación; describe como las entidades captaran recursos y serán procesadas.
Media: En matemáticas y estadística una media o promedio es una medida de tendencia
central
Mediana: En Estadística, una mediana es el valor de la variable que deja el mismo número
de datos antes y después que él, una vez ordenados estos.
Métodos de objetos: Los métodos son un conjunto de procedimientos que permiten que un
objeto ejecute una acción o tarea sobre sí mismo.
Microsoft ActiveX™: Es un marco para la definición de componentes de software
reutilizables (conocidos como controles) que realizan una función o un conjunto de
funciones en Microsoft Windows de una forma que es independiente del lenguaje de
programación utilizado para su aplicación.
Moda: En Estadística, la moda es el valor con una mayor frecuencia en una distribución de
datos.
MS Word: Procesador de textos realizado por Microsoft
Muestreo: En estadística se conoce como muestreo a la técnica para la selección de una
muestra a partir de una población.
Objeto: Cada formulario (ventana), menú o control que se crea con Visual Basic es un
módulo autocontenido llamado objeto. Los bloques básicos de construcción de una
aplicación con Visual Basic son los objetos. Cada objeto tiene un conjunto de
características y un comportamiento definido (propiedades, métodos y eventos) que lo
diferencian de otros tipos de objeto.
PDF (acrónimo del inglés Portable Document Format, formato de documento portátil):
Formato de archivo que reproduce un documento tal y como éste se despliega en pantalla
o en papel manteniendo su apariencia original.
Probabilidad: Porcentaje que representa las posibilidades de victoria de un equipo en un
evento.
Propiedades de objetos: El conjunto de datos que describen las características de un
objeto se le conoce como sus propiedades.
Proyecto: Es una colección de archivos que utiliza para construir una aplicación.
75
Reporte: Informe
Simulación: Representación de un sistema dinámico de manera que permita su tratamiento
en el ordenador.
Software: Conjunto de instrucciones y datos codificados para ser leídas e interpretadas por
una computadora. Estas instrucciones y datos fueron concebidos para el procesamiento
electrónico de datos.
Teoría de la decisión: La teoría de la decisión es una área interdisciplinaria de estudio,
relacionada con casi todos los participantes en ramas de la ciencia, ingeniería
principalmente la psicología del consumidor (basados en perspectivas cognitivo-
conductuales).
Validación: Confirmación, mediante el suministro de evidencia objetiva, que se cumplen los
requisitos para una utilización o aplicación especifica prevista.
Varianza: Es la media aritmética de la suma de los cuadrados de las desviaciones de una
variable con respecto a su media. Por tanto, cuanto mayor sea esta medida, menos
representativa de la realidad será la media de dicha variable.
VBA (Visual Basic for Applications): Es el lenguaje de macros de Microsoft Visual Basic
que se utiliza para programar aplicaciones Windows y que se incluye en varias
aplicaciones Microsoft. VBA permite a usuarios y programadores ampliar la funcionalidad
de programas de Microsoft Office. Visual Basic para Aplicaciones es un subconjunto casi
completo de Visual Basic 5.0 y 6.0.
VBE (Visual Basic Editor): Es el editor de código de Visual Basic, que permite la
introducción de código para controlar diferentes objetos, incluyendo formularios y cuadros
de diálogo.
Visual Basic: Es un ambiente gráfico de desarrollo de aplicaciones para el sistema
operativo Microsoft Windows. Las aplicaciones creadas con Visual Basic están basadas en
objetos y son manejadas por eventos.
WordPad: Procesador de textos de sencillo empleo y con una amplia gama de
prestaciones.
Work in progress: Trabajo en proceso.
77
REFERENCIAS
Luque Domínguez, Eugenio; Elementos de Simulación. Sistemas y Modelos.; Colección de papeles
de trabajo.
http://externos.uma.es/cuadernos/pdfs/papeles22.pdf
Conceptos de Sistemas y Modelos, introducción a la Simulación.
Dorado, Cristian; Simulación de Sistemas; Monografías.com
http://www.monografias.com/trabajos20/simulacion-sistemas/simulacion-sistemas.shtml
Conceptos de Sistemas y Modelos, introducción a la Simulación.
Vallés Miquel, Marina; Herramientas de Simulación de Arena; Simulación Discreta 3º FI.
http://personales.upv.es/~marmoag/marena.pdf
Presentación de Menús y Módulos básicos de Arena.
García de Jalón, Javier; Rodríguez, José Ignacio; Brazález, Alfonso. [1999]; Aprenda Visual Basic
6.0 como si estuviera en primero; Escuela Superior de Ingenieros Industriales, Universidad de
Navarra. España.
http://mat21.etsii.upm.es/ayudainf/aprendainf/VisualBasic6/vbasic60.pdf.
Conceptos del lenguaje de programación Visual Basic.
Montoya Guzmán, Jaime Oswaldo; Visual Basic; Universidad Católica de Occidente; Santa Ana, El
Salvador; Monografías.com
http://www.monografias.com/trabajos33/visual-basic/visual-basic.shtml
Conceptos de Visual Basic.
Simulación de problemas de colas (Arena).
http://gio.uniovi.es/documentos/asignaturas/descargas/practicasARENAresueltas.pdf
Presentación de problemas de colas resueltos en el software Arena.
Shannon, Robert E.; La Simulación de los Sistemas: El Arte y Ciencia, los Precipicios de
Englewood, N.J.: Prentice-Hall, 1975.
Naylor, Thomas H.; Balintfy,Joseph l.; Burdick, Donald S.; y Chu, Kong. Computer Simulation
Techniques. John Wiley, New York, 1966.
Shubik, Martin. Simulation of the industry and the firm. American Economic Review, L(5), 908-919,
1960.
78
Barba-Romero Casillas, Sergio. Métodos de Simulación. Instituto Nacional de
Administración Pública. Madrid, 1985.
Prawda, Juan. Métodos de Investigación de Operaciones. Vol. 2. Limusa, México, 1980.
Gordon, Geoffrey. Simulación de Sistemas. Diana. Mexico, 1986.
79
BIBLIOGRAFÍA
David T. Sturrock, Randall P. Sadowski, W. David Kelton. Simulación con Software Arena.
Cuarta edición, 2008
Allen-Bradley. Rockwell Software; User’s Guide; Rockwell Automation Technologies, Inc.,
todos los derechos reservados, impresa en Estados Unidos de América. © 2007
Allen-Bradley. Rockwell Software; Arena Online Help; Rockwell Automation Technologies, Inc.,
todos los derechos reservados, impresa en Estados Unidos de América. © 2007
ANEXO A
GUÍAS DE LABORATORIO
A-1
A. ABC
PRÁCTICA Nº 1
CONSTRUCCIÓN DE UN MODELO DE SIMULACIÓN CON ARENA
1. OBJETIVO GENERAL
Que el alumno se familiarice con el software de simulación ARENA, sus herramientas y la forma de
construir modelos básicos de simulación.
2. OBJETIVOS ESPECÍFICOS
Que el alumno sea capaz de comprender y diferenciar los distintos módulos básicos de
ARENA.
Que al final de la práctica el alumno sea capaz de construir un modelo sencillo de
simulación, utilizando las herramientas básicas que proporciona ARENA.
3. CONSTRUCCIÓN DEL MODELO DE SIMULACIÓN UTILIZANDO ARENA.
Simulación es una técnica numérica para conducir experimentos en una computadora digital. Estos
experimentos comprenden ciertos tipos de relaciones matemáticas y lógicas, las cuales son
necesarias para describir el comportamiento y la estructura de sistemas complejos del mundo real
a través de largos periodos de tiempo
ARENA es un programa especialmente diseñado para llevar a cabo la simulación de procesos
haciendo uso de diagramas de flujo y animaciones gráficas. ARENA es una herramienta útil para la
representación, análisis y mejora de los procesos; diseñado específicamente para ayudar en la
toma de decisiones de administración y planificación dentro de las empresas.
La simulación involucra menores recursos económicos y de tiempo para investigar como se ve
afectado el desempeño del proceso debido a cambios en las actividades y recursos de este. Otra
ventaja radica en que la simulación se lleva a cabo en una computadora, los cambios introducidos
A-2
al modelo no afectan directamente el funcionamiento real del proceso, permitiendo el desarrollo y
evaluación de experimentos en el sistema que de otra manera implicarían costos elevados.
4. MODELO PROPUESTO
Los clientes llegan al banco “El Auxilio” a solicitar un préstamo personal. La tasa de arribo de cada
cliente al banco se distribuye exponencialmente con una media de 10 minutos. El encargado de los
préstamos, recibe las solicitudes y las revisa para asegurarse que estén completas. Este proceso
de revisión toma usualmente 8 minutos pero puede tardar de 6 a 10 minutos. El encargado de los
préstamos encuentra que el 10% de las solicitudes están incompletas y las manda de regreso al
solicitante.
Las solicitudes completas son enviadas a un centro de procesamiento automático. Este proceso
toma de 30 hasta 90 minutos pero usualmente toma una hora para ser procesada. Se asume que
este proceso puede trabajar cuantas solicitudes sean necesarias.
Después de ser procesadas las solicitudes, estas son enviadas a los clientes con los resultados de
la evaluación.
El encargado de los préstamos gana $1 por hora independientemente si trabaja o no y recibe $0.05
por cada solicitud revisada.
5. PASOS PARA CONSTRUIR EL MODELO DE SIMULACIÓN.
Como primer paso, se creará el diagrama de flujo completo del proceso a elaborar. Se comenzará
el diagrama utilizando el módulo “Create” de la barra de proyectos “Basic Process”. El módulo
“Create” indica el punto en el cual las entidades entrarán al sistema.
A-3
Para colocar un módulo en la ventana del diagrama de flujo, se debe arrastrar el icono del módulo
que se desea utilizar sobre la ventana del diagrama de flujo.
Se creará un módulo con el nombre “Create 1”. Al colocar diferentes módulos en la ventana,
ARENA designará por defecto un número correlativo posterior al nombre de cada módulo. A
medida se vaya desarrollando el problema se le designará un nombre apropiado para cada módulo
y los parámetros adecuados para dicho ejemplo.
Luego de colocar el primer módulo, se continuará con los demás procesos del diagrama.
A-4
El siguiente módulo a colocar es “Process” el cual, al igual que el módulo de “Create”, solamente
se debe arrastrar hacia la ventana del diagrama y automáticamente los dos procesos se
entrelazarán.
En caso que los dos procesos no se enlacen, se debe hacer lo siguiente:
Entrar en la opción de menú “Object” > “Connect”
Luego al colocar el puntero del mouse sobre el proceso “Create” aparecerá un cuadro de color
verde el cual indicará que sobre ese objeto se puede colocar una conexión. Dar clic sobre el
módulo “Create”.
Al dar clic se desplegará una flecha la cual deberá unir el módulo “Create” con el módulo “Process”
mediante un clic.
A-5
Una vez los dos módulos estén enlazados, se continuará con los procesos posteriores. A
continuación de colocará un módulo de decisión.
Se debe observar que en el módulo “Decide”, existen dos conectores de salida (“True” y “False”).
Cada una de esas salidas debe de estar conectada a otros módulos los cuales procesarán cada
uno de las entidades que sean destinadas a ellos. Si una de las salidas no está conectada, Arena
no podrá ejecutar el modelo.
Continuando en la elaboración del diagrama, se colocarán los módulos correspondientes en cada
una de las salidas del módulo “Decide”. Un módulo de “Process” conectado a la salida True y un
módulo “Dispose” conectado a la salida False.
El módulo “Dispose” indica el punto en el cual las entidades salen del sistema; por dicha razón el
módulo “Dispose” no puede ser conectado a otros procesos como el módulo “Process”.
A-6
Para finalizar el diagrama de flujo, se colocará un módulo “Dispose” posterior al módulo “Process 2”
así como se muestra en la siguiente figura.
Una vez terminado el diagrama de flujo, se procederá a definir cada uno de los módulos con los
parámetros correspondientes.
Para introducir los datos correspondientes en cada módulo se debe dar doble clic en dicho módulo.
Se comenzará a trabajar en el módulo “Create 1”. Al darle doble clic aparecerá la siguiente
ventana:
En esta ventana se colocarán los parámetros con los cuales las entidades entrarán al sistema.
Name: El nombre que tendrá dicho módulo. Para este ejemplo se le colocará Entrada de
solicitudes.
Entity Type: El nombre de la entidad que se creará en este módulo. Para este ejemplo se colocará
Solicitud
A-7
Type: En este menú aparece el tipo de distribución con la cual las entidades arriban al sistema.
Para este ejemplo se colocará Expression.
Expression: Indica los parámetros de la distribución designada en Type. Para el ejemplo se
colocará EXPO(10).
Units: Son las unidades con las que trabaja el tipo de distribución que se ha elegido. Para el
ejemplo seleccionar Minutes.
Entities per Arrival: Representa la cantidad de entidades que arriban al sistema. Para este
ejemplo se asumirá que las entidades llegan al sistema de una en una para lo cual se colocará 1
en dicho parámetro.
Max Arrivals: Son la cantidad máximas de entidades que se crearán en dicho módulo. Se colocará
Infinite asumiendo que no hay límite en el sistema para almacenar solicitudes.
First Creation: Es el tiempo en el cual aparece la primera entidad. Se asumirá que la primera
entidad llega al sistema en el minuto 0.0.
Una vez colocados los datos correspondientes la ventana se deberá de ver de la siguiente forma:
El siguiente módulo a trabajar es “Process 1”. Al igual que el módulo Create, dar doble clic al
módulo correspondiente y aparecerá la siguiente ventana:
A-8
En esta ventana, se definen los parámetros con los cuales se procesarán las solicitudes que entran
al sistema.
Name: El nombre que tendrá dicho módulo. Para este ejemplo se le colocará Revisión de
Solicitudes.
Type: Método que especifica la lógica dentro del módulo. Un procesado “Standard” significa que
toda la lógica se guardará dentro del mismo proceso y se definirá por una acción particular.
“Submodel” indica que la lógica se definirá jerárquicamente en un submodelo que puede incluir un
número indeterminado de módulos lógicos. Para este ejemplo se seleccionará la opción Standard.
Action: Esta nos da la opción de definir como se procesará la entidad con respecto a los recursos
disponibles. Delay simplemente indica que sólo se llevará a cabo un proceso de retardo sin que
existan restricciones de recursos. Seize indica que los recursos deben de capturar a las entidades
que llegan a dicho proceso antes de ser procesados. Release indica que las entidades deben de
ser liberadas por los recursos para que dicho recurso quede libre para procesar otra entidad. Para
este ejemplo se seleccionará la combinación Seize Delay Release.
A-9
Al colocar esa opción, aparece un nuevo cuadro.
En este cuadro, se nombrará la clase de recurso que dicho proceso necesita para operar. Al dar
clic en el botón Add aparece una nueva ventana.
Type: Especificación de un determinado recurso o selección a partir de un conjunto de ellos.
Resource Name: Nombre del recurso que será creado en este módulo. Para este ejemplo se
colocará Encargado de Prestamos.
Quantity: Cantidad de recursos que se necesitan para procesar una entidad. Para este ejemplo de
colocará 1.
A-10
Luego dar clic en el botón OK y se regresará a trabajar en la ventana de proceso tomando en
cuenta que un recurso ha sido agregado en la ventana de recursos.
Delay Type: Tipo de distribución o método de especificar los parámetros del retardo. Para este
ejemplo se colocará la distribución Triangular. Al colocar esa opción, aparecerán los parámetros
que se deben colocar para poder utilizar dicha distribución. Colocar en Minimum (6), Value (8) y
Maximum (10).
Unit: Unidades de tiempo para los parámetros del retardo. Para este ejemplo se seleccionará
Minutes.
A-11
Luego de seleccionar las unidades, la ventana de proceso se debería de ver de la siguiente forma:
Dar clic en OK y luego en la ventana de procesos básicos, dar clic en el módulo Resource.
En la ventana inferior del diagrama de flujo, aparece la información relacionada con los recursos
utilizados en el sistema a modelar.
Capacity: Indica la cantidad de recursos disponibles en cada módulo. Para este ejemplo,
posicionarse en la casilla de Capacity y colocar 1 indicando que solo hay un recurso disponible
para ese módulo.
Busy/Hour: Indica el costo de dicho recurso mientras está ocupado. Para este ejemplo se colocará
1.
Idle/Hour: Indica el costo de dicho recurso mientras no está siendo ocupado. Para este ejemplo se
colocará 1.
A-12
Per Use: Indica el costo de dicho recurso por procesar una entidad. Para este ejemplo se colocará
0.05.
Luego se procederá a trabajar en el siguiente módulo, el módulo Decide. Dar doble clic en el
módulo Decide.
Name: Indica el nombre de dicho módulo. Para el ejemplo colocar Completa?
Type: Indica si la decisión se basa en una condición o una probabilidad. Las diferentes
condiciones pueden ser: atributos, variables, tipo de entidad o una expresión. Para este caso se
seleccionará por probabilidad: “2-way by Chance.”
Atributo: Un atributo es una característica común de todas las entidades pero con un valor
específico que puede diferir entre las entidades.
Variable: Es una información que refleja alguna característica de un sistema sin importar
cuantos y que tipos de entidades haya a su alrededor. Se diferencia de un atributo en que
no están unidas a una entidad específica, sino más bien pertenecen al sistema en su
conjunto.
Tipo de entidad: Es una característica que permite clasificar a las entidades en un grupo de
la misma clase, en módulo “create” (que es el que genera entidades) a que grupo de
entidades se desea asignar..
Expresión: Es un conjunto de valores o funciones de arena relacionados mediante signos,
aritméticos, que pueden ser utilizados como criterio de decisión o para ejecutar una acción.
Arena cuenta con el asistente para construir expresiones “Expression Builder” que facilita
el uso de expresiones complejas.
A-13
Percent True: Valor que se comprobará para determinar el porcentaje de entidades que se han
enviado a través de la salida True. Para este ejemplo se colocará 90.
Dar clic en el botón OK y avanzar en el siguiente módulo, Process 2. Al darle doble clic a este
módulo, aparecerá la ventana de parámetros del módulo Process.
Este módulo representa el procesamiento automático. Los parámetros se muestran en el diagrama
siguiente:
Dar clic en el botón OK y abrir la ventana del módulo Dispose conectado a la salida False del
módulo Decide.
A-14
En este módulo, solo se colocará su respectivo nombre y se marcará la opción Record Entity
Statistics.
Dar OK y hacer el mismo procedimiento en el módulo Dispose conectado al módulo Procesamiento
Automático diferenciándolo con el nombre de Solicitudes Procesadas.
Una vez colocado el nombre, dar clic en el botón OK y el diagrama de flujo se debe de ver de la
siguiente manera:
Hasta este punto, se ha terminado de elaborar el diagrama de flujo. El siguiente paso es simular el
modelo pero esto se realizará en la siguiente guía, por lo tanto, guardar dicho modelo para utilizarlo
en la siguiente práctica.
En la barra de menú seleccionar File > Save. Aparece la ventana de Guardar como. Digite el
nombre del archivo y la ubicación donde será guardado.
A-15
6. EJEMPLOS PROPUESTOS.
1. Una máquina recibe 3 camisas cada 2 minutos. El tiempo que la máquina toma para empacar
es de 5 camisas cada 3 minutos. Construya el modelo de simulación.
2. Una maquina produce 1 pieza cada 15 minutos. El tiempo requerido para realizar la inspección
de estas piezas sigue una distribución Normal (15,2) min. Construya el modelo de simulación.
3. En un proceso automatizado, una máquina produce 5 piezas cada 10 minutos. El 5% salen
defectuosas y es necesario reprocesarlas. El reprocesamiento de las piezas tarda usualmente
10 minutos pero puede tardar entre 7 y 13 minutos. Una vez las piezas son reprocesadas,
estas se enviarán junto con las demás piezas hacia una maquina que las empaca tardando 10
minutos por pieza. Construya el modelo de simulación.
A-16
PRÁCTICA Nº 2
ANÁLISIS DE REPORTES
1. OBJETIVO GENERAL
Que el alumno aprenda a ejecutar un modelo en el software de simulación Arena, y que sepa
interpretar los reportes que son generados luego de correr la simulación.
2. OBJETIVOS ESPECÍFICOS
Que los estudiantes conozcan como establecer los parámetros de ejecución más
adecuados, dentro del software Arena, para el sistema que se esté modelando.
Lograr que el estudiante obtenga la capacidad de interpretar correctamente los reportes
generados por Arena y que pueda realizar análisis de variables de interés del sistema.
Que luego de la práctica el estudiante sea capaz de utilizar los gráficos de seguimiento de
variables relevantes del sistema.
3. EJECUCIÓN DE UN MODELO
3.1. ABRIR EL MODELO REALIZADO EN LA PRÁCTICA PASADA.
Para efectos de ésta práctica utilizaremos el modelo de la guía Nº1. Para eso se debe ingresar a
File > Open y se elige el archivo ya creado:
A-17
3.2. CREACIÓN DE GRÁFICOS DE SEGUIMIENTO (CON LA FUNCIÓN “PLOT”).
Al momento de la ejecución de una simulación resulta de gran utilidad el uso de gráficos de
seguimiento que permite observar el comportamiento de variables que son relevantes para poder
apreciar el comportamiento del sistema. Por nombrar un ejemplo, el seguimiento de la cantidad de
entidades que se encuentran en cola en cada instante de la simulación; éste tipo de gráfico
indicará como varía a lo largo del tiempo la gente en cola, pero además dejará un registro de cómo
se comportó durante toda la simulación.
Existen una variedad de atributos del sistema que se pueden representar mediante gráficos. Por
ser de obvia utilidad y de fácil comprensión, se profundizará en el ejemplo mencionado
anteriormente (cantidad de entidades en cola).
Para éste propósito se debe de dar clic en el icono “plot” , en la barra de herramientas
“animate” que se encuentra en la parte inferior derecha de las barras de herramientas.
Luego aparecerá el cuadro de diálogo siguiente:
A-18
Primero se procederá a añadir la expresión para el seguimiento de la cantidad de entidades en
cola, para lo cual se debe dar clic en el botón “Add”; en la sección bajo el nombre “Series 1
Properties”, dentro de la rama “Source Data” seleccionar la opción “Expression”, luego
selecciónese “Build Expression…”, como se ilustra a continuación:
A-19
Posteriormente, una vez se ha ingresado al constructor de expresiones, en el árbol que aparece en
bajo el campo “Expression Type” se selecciona la opción Basic Process Variables > Queue>
Current Number In Queue, como sigue:
A-20
En la lista desplegable “Queue Name” es posible seleccionar el nombre de cola que se generé en
cualquiera de los procesos del modelo, como en el ejemplo tratado aquí solamente se forma una
cola, únicamente aparece disponible “Revision de Solicitudes.Queue” , que es la de interés. Luego
se le da clic en el botón OK para guardar los cambios. Una vez de regreso en la ventana Plot, se
modificará la escala de tiempo. Dar clic en la pestaña “Axes” y en la rama “Scale” modificar el
parámetro “Maximum” y colocar 2400 minutos.
Luego dar clic en Ok para guardar los cambios y se debe crear un cuadro en el cual estará
contenida la gráfica. A continuación se muestra esquemáticamente como deberá quedar la gráfica:
A-21
Es posible que luego de ejecutar la simulación el gráfico no posea la escala adecuada porque se
desconoce el valor máximo que alcanzará la cantidad de entidades en cola, por lo cual es
recomendable hacer el ajuste luego de que se ha revisado en los reportes éste dato. Sin embargo,
en el cuadro de diálogo “Plot” existía una opción llamada “Scale” dentro de la opción del eje vertical
titulada “Autoscale” que permite que la escala se ajuste a medida cambian el valor máximo, por lo
que cambiar la escala es sólo una opción del analista.
3.3. ESTABLECIMIENTO DE LOS PARÁMETROS DEL MODELO.
Para la ejecución de una simulación, es necesario que se haya finalizado de modelar el sistema.
Una vez se cuente con un modelo fabricado se deben definir en la opción “setup” del menú “run”,
los parámetros que permitan la representación del sistema.
En la pestaña “Project Parameters”, se define el titulo del proyecto, el nombre del analista y una
descripción del proyecto, además se selecciona el grupo de estadísticas (Statistics Collection) que
se desean obtener al final de la simulación; en el ejemplo del banco El Auxilio, se elegirá Costing,
Entities, Resources y Queues. A continuación se muestra la apariencia de del cuadro de diálogo:
A-22
En la pestaña “Replication Parameters”, se puede modificar las unidades de tiempo, la duración de
una réplica, el número de replicas, las hora de trabajo por día. Por número de replicas se entiende
por el número de veces que se repite el experimentos con diferentes números aleatorios; esto se
hace con el objetivo de estimar el error experimental y observar si los datos son estadísticamente
significativos logrando reducir los errores estándar. Definir el número de replicas es un factor muy
importante para el análisis de los resultados obtenidos pero, para efectos prácticos de laboratorio,
se ejecutará el modelo con una réplica para simplificar el análisis de los reportes. En guías
posteriores se crearán modelos que por su naturaleza se ejecutarán con más de una réplica.
El periodo de calentamiento o Warm-up Period, es el tiempo que se le da al sistema, al principio de
la simulación, con el cual se espera que los datos lleguen a un punto en el cual se estabilicen.
Cuando se crea un sistema, por lo general comienza con ninguna entidad en él, y en la práctica
sucede todo lo contrarió ya que las grandes fabricas o compañías manejan inventarios o personas
en sus sistemas permanentemente por lo que con agregarle un tiempo inicial a la simulación se
está tomando en cuenta ese factor. Este tiempo afecta las estadísticas generadas en el reporte ya
que el sistema comenzará a recopilar información a partir del punto en el que termina el periodo de
calentamiento. Para poder análisis los reportes de esta guía se dejará el tiempo de calentamiento
como 0.0 indicando que no habrá un tiempo de calentamiento.
En el cuadro de Replication Parameters modificará la duración de la réplica (“Replication length”)
de infinito a 5, con esto se pretende definir el tiempo en el cual se prolongará la simulación, para el
caso del ejemplo, las unidades en que se expresará la duración (“Time Units”) es en días, con esto
se pretende simular 5 días de trabajo en el banco El Auxilio en el proceso de solicitud de
préstamos. Para las horas por día (“Hours per day”) se pondrán 8 horas y las unidades en que se
expresaran los reportes (Base Time Units) serán en minutos, esto permitirá ver los resultados de
los reportes en unidades de minutos.
A-23
Para ejecutar la simulación, en la barra de menú se selecciona run > go, o simplemente dar clic en
la barra de herramientas “standar”, al icono “go”.
La barra de herramientas “Standar” contiene las opciones del menú “Run” para controlar la
velocidad de la simulación, detenerla, pausarla o adelantar hasta al final. En seguida se muestra
una imagen congelada de la simulación
A-24
Cuando la simulación llega a su fin, Arena pregunta si se desea ver los resultados de dicha
simulación, en este caso se elegirá Sí.
4. VISUALIZACIÓN DE REPORTES
Los resultados que Arena despliega luego de la ejecución de un modelo se dividen en diferentes
partes, según lo seleccionado anteriormente en el menú “run setup”, en el ejemplo del banco El
Auxilio se despliega el reporte Category Overview.
4.1. EXPORTACIÓN DE REPORTES
Estos reportes pueden ser exportados del programa Arena al procesador de texto (MS Word) o
bien ser convertido al formato de documento portátil (PDF) u otro tipo de formato de texto, sí se
desea archivarlos para una revisión posterior; aunque es de gran utilidad, ya que permite
almacenar la información en un formato agradable, Arena automáticamente guarda una síntesis de
estos reportes en archivos de formato .out que se pueden abrir con WordPad u otros procesadores
de texto similares.
Para exportar los reportes una vez se han generado, debe buscar el icono Exportar informe
que se encuentra en la barra de herramientas que aparece justo arriba del reporte y darle clic.
A-25
Luego aparecerá el siguiente cuadro de diálogo.
Una vez aparezca, se deberá elegir el formato de exportación bajo la lista desplegable “Format”:
MS Word, sí se desea exportarlo a Microsoft Word; Acrobat Format (PDF) si se desea exportarlo
a formato de documento portátil. Posteriormente se deberá elegir de la lista desplegable
“Destination” la opción “Disk file” y por último OK.
Arena arrojará un cuadro de diálogo preguntado cuales páginas desea guardar, para éste caso
seleccioné, la opción “All”, que seleccionará todas.
Como siguiente paso se le preguntará el directorio donde se desea guardar el documento, elíjase
el que considere adecuado.
4.2. ANÁLISIS DE REPORTES
En ésta sección se presentarán los reportes, y se dará una explicación de cómo interpretarlos. El
reporte generado, Category Overview, se presenta en seguida junto con una explicación breve de
la información más relevante.
A-26
All entities: en este caso solamente existe una entidad que son las solicitudes, el costo de valor
agregado (Value Added Cost) se refiere al costo del uso del recurso que realiza la revisión de las
solicitudes, para este ejercicio tiene un valor de $44, solamente se contabiliza el costo del recurso
(encargado de préstamos), el cual es $32 por el número de horas trabajadas y $12 por el número
de solicitudes revisadas. Es importante recalcar que los costos que aquí aparecen son
aproximaciones al siguiente entero, se podrán ver los valores exactos en los siguientes reportes,
específicamente en el reporte del costo por uso del recurso.
All resources: este apartado muestra los costos de cada recurso dentro del modelo, el ejemplo solo
se toma en cuenta un recurso, el encargado de préstamos, ya que es el único que tiene salario ($1
por hora), esté o no trabajando. En total trabajo 40 horas en los 5 días simulados esto se resume
en $40 de salario, $32 de trabajo (Busy cost) y $8 de descanso (Idle cost), y como bono $12, el
cual toma en cuenta el número de solicitudes que han salido del sistema 234 y las que se
encuentran en el mismo al final de la simulación. Una vez más estos datos son aproximados por
Arena, pero se puede ver su valor exacto en la ventana reports > resources.
A-27
En la pestaña de vista previa, se puede desplegar los diferentes reportes mostrados por Category
Overview:
Entity:
Queue:
Resourse
Reporte Entity: Muestra los valores promedio, mínimo y máximo de: costos, tiempos, el número de
entradas de entidades y de salidas; así como el WIP (work in progress) de cada entidad que haya
salido del sistema.
A-28
A-29
Algunas de las secciones incluidas en los reportes de Entities, Processes, Queues, Resources y
Transfers contienen una columna llamada "Half width". Este dato se incluye para ayudar a
determinar la fiabilidad de los resultados de la replicación. Dependiendo de los valores con los que
se trabajen, Arena mostrará tres posibles respuestas en este campo las cuales se describen a
continuación:
Insuficiente (Insufficient): La fórmula utilizada para calcular este campo requiere que la
muestra se distribuya de forma normal. Esa suposición puede ser violada si el número de
muestras es muy pequeño (menos de 320). Si ese es el caso, Arena devolverá el mensaje
de "Insufficient" indicando que no hay datos suficientes para calcular este valor. Ejecutar el
modelo durante más largo debe corregir esta situación.
Correlativo (Correllated): La fórmula utilizada para calcular este campo requiere que las
muestras se distribuyan en forma independiente. Los datos que se correlacionan (el valor
de una observación influye fuertemente en el valor de la observación siguiente) resultan
estar en un intervalo de confianza no valido. Si se determina que los datos que se
correlacionan, Arena devolverá el mensaje "Correllated" indicando que no hay datos
suficientes para calcular este valor. Ejecutar el modelo durante más largo debe corregir
esta situación.
Un valor: Si aparece un valor en esta categoría, ese valor se puede interpretar que "en el
95% de los ensayos repetidos, la media de la muestra que se registra dentro del intervalo
muestral mas menos el ancho de la media". Este valor se puede reducir al ejecutar la
simulación durante un largo período de tiempo.
VA Time: Es el tiempo acumulado que una entidad utiliza un recurso dentro de los
procesos que están catalogados como VA (Value Added). Como se recordará cuando se
introducían los datos del proceso, aparecía una lista desplegable con el nombre de
“Allocation” en el que “Value Added” es la selección predeterminada, y es por ello que el
tiempo que aparece en este campo es el tiempo acumulado que la entidad permaneció en
ambos procesos.
NVA Time: Es el tiempo acumulado que una entidad utiliza un recurso dentro de los
procesos que están catalogados como NVA (Non-Value Added). En el ejemplo que se
desarrolla, ninguno de los procesos ha sido catalogado como Non-Vakue Added por lo que
en este campo aparece el valor de 0.
A-30
Wait Time: Es el tiempo que la entidad ha pasado en cola. Para éste caso como solamente
existe una línea de espera, representa el valor que ha pasado en la cola que precede al
proceso Revisión de solicitudes.
Total Time: Es el tiempo que la entidad ha pasado en el sistema. El promedio se puede
obtener sumando los promedios de los tiempos anteriores.
Number in: Es la cantidad de entidades que entraron al sistema.
Number out: Es la cantidad de entidades que salieron del sistema.
WIP: Representa el número de entidades que estaban en el sistema en un momento
determinado. Este representa el número de entidades que estaban en cola y en servicio en
cierto punto de la simulación.
VA Cost: Es el costo de utilización del recurso por entidad procesada. Es el único costo
que se aparece, ya que por el momento no se han definido costos para los otros
parámetros. Se obtiene sumando multiplicando el VA Time por el costo por unidad de
tiempo del recurso ($1/60, para el caso) y luego sumándole el costo promedio por solicitud
procesada , así:
Total Cost: Es el costo total por entidad, tomando en cuenta los costos: VA Cost, NVA
Cost, Wait Cost, Transfer Cost y Other Cost. Para el caso es equivalente al valor del VA
Cost.
A-31
Reporte Queue: Muestra la información referente al comportamiento de la cola del proceso
Revisión de solicitudes, ya que es el único proceso que genera una espera.
Waiting Time: Es el tiempo que las entidades han pasado en espera. Difiere del Wait Time,
en que éste sólo cuenta las entidades que han salido del sistema, empero, el Waiting Time
cuenta todas las entidades que han pasado por líneas de espera, aun sino han salido del
sistema.
Waiting Cost: Representa el costo de espera en el sistema. Este en caso de que exista un
costo porque la entidad se encuentre en línea de espera de ser procesada u en otra
actividad que requiriese una espera.
Number Waiting: En el caso del promedio es la media de entidades que estuvieron en
espera. El máximo es precisamente el mayor número de entidades que estuvieron en cola
en determinado momento de la simulación.
A-32
Reporte Resource: En éste reporte se presenta la información concerniente al recurso o recursos.
En el ejemplo que se sigue, el reporte generado se divide en las secciones de utilización (usage) y
del costo de esa utilización (cost).
Number Busy. Reporta las unidades de recursos ocupados. El promedio se calcula como
un promedio ponderado considerando el valor como una función del tiempo (B (t)).
A-33
Number scheduled. Reporta el número de unidades de recursos programados. Es el
promedio se pondera considerándolo el valor de unidades programadas como una función
del tiempo (M (t)). Si la capacidad es fija, como lo es en éste ejemplo, el valor es
constante.
Instantaneous Utilization: Es la utilización en un instante particular; Se calcula dividiendo el
número de unidades de recurso ocupadas entre el número de unidades de recurso
programadas (Number Busy / Number Scheduled ). Se obtiene el promedio, precisamente
calculado el promedio ponderado de todas los instantes considerados. Si sucediera que las
unidades de recurso no estén programadas, la Instantaneous Utilization es cero.
Siendo U (t) = B (t) / M (t) siempre y cuando M (t) >0, y U (t) será 0 cuando M (t) = 0.
Scheduled Utilization. Reporta al utilización promedio acumulativa sobre el periodo de
tiempo que el recurso estuvo programado. Es decir, indica el tiempo que el recurso estuvo
ocupado mientras estaba programado. Este valor será igual a Instantaneous utilization, si
la capacidad del recurso se mantiene constante.
Total Number Seized: En éste reporte aparece el número total veces que una unidad del
recurso fue capturada.
Busy Cost. Reporta el costo de tener disponible todos los recursos. El costo de utilización
de cada recurso es el producto del promedio de Number busy, de la duración de la
simulación (unidades de tiempo) y el costo del recurso especificado (en el ejemplo $1).
Idled Cost. Reporta el costo de no utilización del recurso, es decir, cuando se encuentra
ocioso durante el período que está disponible. El costo de ocio de cada recurso es el
producto del promedio de unidades del recurso ociosas, de la duración de la simulación y
el costo del recurso en estado de ocio (en este caso $1).
Usage Cost. Reporta el costo de utilización de todos los recursos. Se calcula como el
promedio del número de veces que han sido “capturadas” las unidades de recurso por el
costo de uso del recurso (para el ejemplo $0.05, por entidad).
A-34
5. EJEMPLOS PROPUESTOS.
1. Una empresa en expansión desea colocar una nueva fábrica de producción de su reconocida
marca de zapatos deportivos y ha considerado los países de Helsinki y Libia para dicha
inversión. Debido a que ambos países poseen distintos mercados de adquisición de materia
prima y maquinaria, los gerentes de la empresa se encuentran con dos posibles casos:
a) En el país de Libia se puede adquirir una máquina que produce 10 zapatos cada 5 minutos,
de los cuales el 2% es defectuoso y necesita reproceso, el cual puede tardar entre 1 y 5
minutos, aunque por lo general tarda 3 minutos. Después del reproceso, los zapatos pasan
a una inspección final y empacado la cual sigue una distribución Normal(6,1). La máquina
que produce los zapatos tiene un costo de producción de $8 la hora y la que inspección
final tiene un costo de $3 por hora independiente trabaja o no.
b) En el país de Helsinki se puede adquirir una máquina que produce zapatos según la
distribución Normal(15,8) de los cuales el 0% es defectuoso. La inspección final y el
empacado se realizan de forma automatizada por lo cual se ahorra en tiempo al hacer toda
esta operación en 23 minutos exactos. La máquina que produce los zapatos tiene un costo
de producción de $4 la hora y la operación de inspección final y empacado tiene un costo
de $8 por hora únicamente cuando se encuentra activa.
Evaluar ambas alternativas mediante el análisis de los costos totales del modelo de simulación
planteado y presentar la mejor alternativa para los gerentes de la empresa.
2. Con base al ejemplo anterior, asumir que en los dos países, ambas máquinas de
procesamiento del zapato deportivo tardan por lo general 4 minutos en completarlo aunque
dicho proceso puede tomar desde 2 hasta 5 minutos. Si la inspección y el empacado se
mantienen invariables, evaluar ambas alternativas mediante el análisis de los costos
totales del modelo de simulación planteado y presentar la mejor alternativa para los
gerentes de la empresa.
A-35
PRÁCTICA Nº 3
JERARQUIZACIÓN
1. OBJETIVO GENERAL
Que el alumno aprenda a construir un modelo utilizando las herramientas de submodelos y que
comprenda la importancia de ellos en el análisis del sistema.
2. OBJETIVOS ESPECÍFICOS
Que el alumno comprenda el funcionamiento y la importancia de los submodelos en un
sistema.
Que el alumno aprenda a utilizar los submodelos como una herramienta de jerarquización.
Que el alumno pueda identificar las diferencias entre los tipos de submodelos que se crean
en Arena.
3. CONSTRUCCIÓN DE UN MODELO UTILIZANDO LA JERARQUIZACIÓN
La Jerarquización es una parte muy importante dentro del entorno de Arena ya que permite detallar
procesos y segregarlos formalmente unos de otros.
La Jerarquización consiste principalmente en crear submodelos dentro de cada uno de los
procesos presentes en el modelo a simular con el objetivo de hacer procesos más detallados y
complejos pero facilitando la comprensión del sistema.
Existen dos formas de crear un sub-modelo. Una es definiendo un módulo “Process” como un
submodelo lo cual se hace en la ventana del proceso y en el menú “Type” se selecciona
“Submodel”. La otra forma de crear un submodelo es mediante un objeto, en el menú Object >
Submodel > Add Submodel, o simplemente dando un clic en el botón “Submodel" en la barra de
herramientas estándar .
A-36
Las diferencias principales entre los dos métodos son las estadísticas que se generan. Cuando un
módulo Process se define como submodelo y se introducen alguna lógica en la vista del
submodelo, cualquier estadística acumulada cuando la entidad está en el submodelo se va a
reflejar directamente en las estadísticas de ese proceso. Esto se refiere a sumar las estadísticas
hacia las estadísticas del proceso principal. Esto es verdad independientemente de las cantidades
de niveles de jerarquización que sean definidos. Las estadísticas acumuladas de un submodelo
definido como objeto no son sumadas en los reportes.
4. MODELO PROPUESTO
El taller automotriz “Las Américas”, da mantenimiento a motocicletas, vehículos livianos y pesados.
Cuando un vehículo llega al taller, inmediatamente pasa a recepción en donde los encargados de
dicho trabajo se ocupan de verificar el estado en el que se encuentra el vehículo y tomar los datos
correspondientes. Este proceso varía según el tipo de vehículo. Para vehículos livianos y
motocicletas, el proceso de recepción toma normalmente de 10 a 15 minutos. Para vehículos
pesados el proceso es un poco más tardado y toma de 15 a 25 minutos.
Luego de entrar al taller, el proceso de revisión es independiente para cada clase de vehículo. Para
una motocicleta, el tiempo que toma hacer todos los ajustes correspondientes a su revisión se
distribuye de forma normal (60min, 20min). Para los vehículos livianos, el tiempo que tarda su
revisión se distribuye de forma normal (120min, 30min). Y para los vehículos pesados, el tiempo
estimado de su revisión suele tomar de 2 a 3 horas.
Una vez terminada la revisión de dicho vehículo, este está listo para ser entregado a su respectivo
dueño. En este proceso, los recepcionistas se encargan de mostrarle a los clientes los detalles del
mantenimiento y el cliente toma su tiempo para revisar dichas mejoras para garantizar el buen
trabajo de los mecánicos. Este proceso es muy similar al de recepción con la única diferencia que
para motocicletas y vehículos livianos toma de 5 a 10 minutos y para los vehículos pesados toma
de 10 a 15 minutos.
En el proceso de recepción y entrega de vehículos, se utilizan dos técnicos, uno para vehículos
pesados y otro para motocicletas y vehículos livianos. Los dos técnicos se encargan de la
recepción y entrega de los vehículos, si en un momento el técnico encargado de los vehículos
pesados está entregando un vehículo a un cliente y llega otro vehículo pesado, este tendrá que
esperar hasta que se desocupe dicho técnico. La misma regla aplica para el técnico encargado de
los vehículos livianos y las motocicletas.
Para el proceso de revisión, existen dos mecánicos para cada tipo de vehículo que ingresa al taller
haciendo un total de seis mecánicos. Esto se debe a que se necesitan dos mecánicos para darle
mantenimiento a un solo vehículo.
A-37
La tasa de arribo de las motocicletas al taller se distribuye exponencialmente con una media de 1
hora. Los vehículos livianos llegan máximo dos y mínimo uno por hora y la tasa de arribos de los
vehículos pesados es igual que las motocicletas con la diferencia que tiene una media de 1.5
horas.
Simular para 5 días y analizar los reportes. ¿Qué recomendaciones haría?
5. PASOS PARA CONSTRUIR EL MODELO.
Para comenzar a elaborar este modelo, se debe crear el flujograma que ilustre cada uno de los
procesos existentes en dicho modelo.
Como primer paso y de forma esquemática, el modelo se comenzará a partir del siguiente
diagrama:
Los tres módulos Create, representará la entrada de los tres tipos de vehículo. Process 1
representará la recepción de los vehículos. El Process 2 representará la revisión de los vehículos
por parte de los mecánicos. Process 3 representará la entrega de los vehículos a sus respectivos
dueños y el módulo Dispose 1 es la salida de los vehículos del taller y por consecuente del
sistema. Más adelante a medida se vaya avanzando en la elaboración del modelo se les
designaran nombres adecuados a dichos módulos.
El siguiente paso será crear los submodelos. Comenzaremos por agrupar los módulos Create con
el objetivo de simplificar la vista del modelo. Para este caso se utilizará un submodelo con la
característica de objeto.
Primero seleccionar los tres módulos Create ya sea enmarcándolos con el ratón o dando clic en
cada uno de los módulos Create mientras se tiene presionada la tecla Ctrl.
A-38
Una vez seleccionado los tres módulos, seleccionar la opción “Aggregate” desde el menú Object >
Submodel > Aggregate. Posteriormente los tres módulos Create se agruparán en un submodelo
como se muestra en la figura:
En el submodelo se observan tres salidas representando las tres conexiones de los módulos
Create que se encuentra dentro de él. Para observar el contenido dentro del submodelo, dar doble
clic sobre él.
Al entrar en el submodelo, se observan los tres módulos Create los cuales están conectados a tres
puntos al lado derecho de la ventana que representan las salidas del submodelo.
A continuación se colocarán los parámetros correspondientes a los arribos de los vehículos al
sistema. De manera gráfica los módulos deben quedar de la siguiente forma:
A-39
Para el módulo Create 1:
Para el módulo Create 2:
Para el Módulo Create 3:
A-40
Una vez se ha terminado de definir cada módulo, la ventana del submodelo se debe observar de la
siguiente manera:
Para salir del submodelo, dar clic derecho sobre la ventana y seleccionar “Close Submodel” y
nuevamente aparece la ventana del modelo principal. Para colocarle nombre al submodelo, dar clic
derecho sobre él y seleccionar la opción “Properties…”. En “Submodel Name” colocar “Entrada de
vehículos”. “Number of entry points” y “Number of exit points” tiene por defecto 0 y 3 ya que Arena
modifica las entradas y salidas de los submodelos dependiendo de la naturaleza de los módulos
que están dentro de él. Si en caso se desea modificar dicho submodelo, el número de entradas y
salidas se pueden modificar en cualquier momento. Dar clic en OK para guardar los cambios y
regresar a la ventana principal.
El siguiente paso será definir los procesos de Recepción, Revisión y Entrega de vehículos.
Para continuar con la lógica del flujograma, el siguiente proceso a modificar será la recepción de
los vehículos. Dar doble clic al módulo Process 1 para desplegar la ventana de dicho proceso. El
nombre de este proceso será “Recepción de vehículos” y en la opción Type, colocar la opción
Submodel. La ventana deberá quedar de la siguiente forma:
A-41
Esto indica que el proceso se ha definido como un Submodelo por lo que cualquier lógica se debe
de realizar dentro de dicho submodelo. Dar clic en OK para guardar los cambios. Ahora el icono de
dicho módulo se debe ver de siguiente manera:
La flecha que se forma en la esquina superior derecha indica que ese proceso está definido como
un submodelo. Para entrar en el submodelo dar clik derecho en el proceso y seleccionar “Edit
Submodel”.
La ventada del submodelo es muy parecida a la primera que se creó con la diferencia que esta
tiene una entrada y una salida las cuales no se pueden modificar ya que son parámetros ya
definidos para este tipo de procesos.
Para entrar en este submodelos se debe dar clic derecho sobre él y seleccionar “Edit Submodel” y
aparece la ventana del submodelo en la cual se definirán los procesos que intervienen en dicho
módulo.
A-42
Primero colocar dentro de la ventana del submodelo un módulo Decide y tres módulos Process. El
módulo Decide servirá para identificar qué tipo de vehículo entra a dicho proceso y enviarlo a su
respectivo proceso para ser recibido en el taller. Los cuatro módulos que se colocaron en el
submodelo deben quedar así:
El módulo Decide servirá para identificar los vehículos que entran al sistema. Dar doble clic en
dicho módulo para establecer la lógica del mismo. De forma gráfica el módulo debe quedar de la
siguiente manera:
El tipo de condición “N-way by Condition” indica que habrán N salidas y cada una de ellas estará
determinada por una condición la cual se define posteriormente. Para agregar una condición se da
clic en el botón Add. Por ejemplo para la condición designada para los vehículos livianos, la
ventana debe quedar así:
A-43
Una vez definidas las 2 condiciones, dar OK para guardar los cambios y observar que el módulo
decide cambió de apariencia.
La lógica planteada en dicho módulo dice que si los vehículos que llegan a ese módulo son
Livianos o Motocicletas, deben dirigirse hacia su respectiva salida, en caso contrario de no ser
ninguno de los dos casos, como es el caso de los vehículos pesados, dicha entidad se dirigirá a la
salida definida como Else.
El siguiente paso será definir cada uno de los tres procesos que se colocaron en el submodelo
representando el tiempo que toma a cada técnico en recibir los vehículos. Tomando en cuenta que
el mismo técnico se encarga de recibir los vehículos livianos y motocicletas y otro técnico es el
encargado de recibir únicamente los vehículos pesados. Cada uno de los procesos dentro del
submodelo “Recepción de vehículos” debe quedar de la siguiente manera:
A-44
Para el proceso de recepción de vehículos livianos:
Para el proceso de recepción de motocicletas:
A-45
Para el proceso de recepción de vehículos pesados:
Lo que resta por hacer en este submodelo para terminarlo es hacer las conexiones
correspondientes. Dichas conexiones deben quedar de la siguiente forma:
Una vez hechos todos estos pasos dentro del submodelo, salir de dicha ventana dando clic
derecho a la ventana y seleccionar “Close Submodel”.
Continuando con los procesos de revisión y entrega de vehículos, se debe tomar en cuenta que
cada proceso está formado por los mismos módulos que conformaron el proceso de “Recepción de
Vehículos” por lo que se mostrarán las ventanas de los parámetros respectivos a cada módulo.
A-46
El siguiente proceso según la lógica del problema es el de “Revisión de Vehículos”. Al igual que en
el módulo anterior, Se modificará el tipo de proceso de estándar a submodelo y se colocarán tres
módulos Process y un Decide. La lógica del módulo Decide será la misma que se usó en el módulo
anterior ya que su función será la de dirigir a sus respectivos módulos los vehículos que llegan al
sistema. Los parámetros de cada proceso quedarán de la siguiente forma:
Para el proceso de revisión de vehículos liviano:
Para el proceso de revisión de motocicletas:
A-47
Para el proceso de revisión vehículo pesado:
Se debe tomar en cuenta que los recursos de cada módulo son diferentes ya que un par de
mecánicos está asignado a un proceso determinado y que para procesar un vehículo se requiere
de dos mecánicos.
Una vez los procesos estén definidos correctamente, el submodelo se debe ver así:
Una vez terminado este submodelo se continuará con la elaboración del último submodelo el cual
corresponde a la entrega de los vehículos. Dicho módulo al igual que los anteriores, está
compuesto por tres módulos Process y un Decide. El módulo Decide tiene la misma lógica que los
que se colocaron en los submodelos anteriores y los módulos Process dentro de este último
submodelo quedan definidos de la siguiente forma:
A-48
Para el proceso de entrega de vehículos liviano:
Para el proceso de entrega de motocicletas:
A-49
Para el proceso de entrega de vehículo pesado:
Tómese en cuenta que los recursos designados para estos procesos son los mismos que los
designados en el proceso de recepción de vehículos ya que las mismas personas están
encargadas de realizar ambas tareas.
El submodelo se debe ver de la siguiente forma:
Una vez terminado dicho submodelo, lo único que falta por definir en la ventana de grafico es el
módulo Dispose al cual se le colocará el nombre “Salida de vehículos”. El modelo completo se
debe ver así:
A-50
Antes de definir los parámetros de la simulación, hay que tomar en cuenta ciertos aspectos:
En los procesos de revisión de vehículos hay dos mecánicos en cada proceso por lo que para
definir dicho parámetro dar clic en el módulo “Resource” en la barra de procesos básicos. La hoja
de cálculo de debe ver de la siguiente manera:
Y por último, con el objetivo de mejorar la interfaz gráfica del modelo a medida se vaya simulando,
se modificaran las imágenes que representan a las diferentes entidades del sistema, para ellos,
seleccionar el módulo Entity en la barra de menú de procesos básicos. La hoja de cálculos debe
quedar de la siguiente forma:
Se les ha colocado imágenes a las respectivas entidades con el objetivo de diferenciarlas cuando
se ejecute el modelo.
Como último paso, antes de ejecutar el modelo, se deben definir los parámetros de la simulación lo
cual se hace en la opción Setup del menú Run.
En la ventana de “Run Setup” en el menú “Replication Parameters” se debe especificar que se
ejecutará el modelo para 5 días y cada día está compuesto por 8 horas laborales. Las unidades del
reporte se expresarán en horas. En el menú “Project Parameters” se den seleccionar los reportes
de entidades, recursos, colas y procesos.
Una vez definidos estos parámetros, dar clic en Aceptar para guardar los cambias.
A-51
El siguiente paso será ejecutar el modelo para generar los reportes correspondientes. Los
parámetros de entidad, cola y recursos fueron analizados en la guía anterior por lo que no se
profundizará en ellos. Existe un nuevo parámetro dentro de los reportes que Arena genera y es el
de procesos.
En el reporte de procesos, se identifican tres parámetros que son:
Time per Entity: Indica el tiempo que las entidades permanecieron en cada uno de los procesos ya
sea el tiempo en el que estuvo siendo trabajada por un proceso específico o el tiempo que estuvo
esperando en ser atendió. En este parámetro se identifican todos los procesos del sistema
incluyendo los procesos que se definieron como submodelos.
Accumulated Time: Indica el tiempo total acumulado de cada uno de los procesos que ha sido
definidos como submodelos.
Other: Indica la cantidad de entidades que entraron y salieron de cada proceso.
6. EJEMPLO PROPUESTO
1. Realizar el mismo ejemplo de la guía con la diferencia que los procesos que se definieron como
submodelos deben de ser definidos como un objeto. Observar los cambios generados en el reporte
de procesos.
A-52
PRÁCTICA Nº 4
CONSTRUCCIÓN DE UN MODELO UTILIZANDO MÚLTIPLES RECURSOS
1. OBJETIVO GENERAL
Que el alumno aprenda y se familiarice con la utilización de múltiples recursos dentro de un modelo
de simulación a partir de la ejecución de los diversos módulos básicos que presenta el software de
ARENA.
2. OBJETIVOS ESPECÍFICOS
Que el alumno comprenda y pueda utilizar los módulos Entity, Resources, Schedule y Set.
Que al final de la práctica el alumno sea capaz de construir un modelo de simulación
utilizando múltiples recursos a partir de los diversos módulos que ofrece el software
ARENA.
3. CONSTRUCCIÓN DEL MODELO UTILIZANDO MÚLTIPLES RECURSOS.
3.1. RECURSOS
Los recursos representan elementos necesarios para procesar las entidades, es decir, personal,
equipo, máquinas, materia prima, documentos, etc.
Las entidades capturan una o más unidades de un recurso para tener control de él y sueltan a
dicho recursos cuando ya no requieren utilizarlo. Se vuelve necesario aclarar que la entidad debe
soltar en algún punto del modelo al recurso para no bloquearlo.
El recurso debe considerarse como aquel que está siendo utilizado por la entidad en lugar que a la
entidad se le está asignando un recurso ya que una entidad puede necesitar varios recursos a la
vez. De igual forma, esta consideración se vuelve factible por el hecho que Arena es un software
guiado por las entidades y no por los recursos.
A-53
Al momento de realizar el análisis del sistema se deben identificar y definir claramente todos los
recursos que están involucrados en el proceso, sus capacidades y su disponibilidad de horario, así
como fallas y paros en el mantenimiento que se vayan a considerar en el estudio.
Finalmente, se debe plantear claramente cuáles son los recursos clave del sistema con el propósito
de generar estadísticas individuales de utilización.
4. MODELO PROPUESTO
Cada año, los alumnos de nuevo ingreso de cierta universidad se reúnen en el auditorio, de
acuerdo a un horario establecido, para la obtención de su credencial universitaria. Lo más
importante dentro de este procedimiento es que los alumnos sean atendidos lo más rápido posible,
ya que, cuando los alumnos llegan al auditorio, éstos se forman en una fila esperando a que uno
de los encargados de credencial los atienda.
El encargado de la credencial revisa la forma de inscripción de cada alumno, toma su foto
respectiva, captura su firma en el sistema de forma electrónica e imprime la credencial. El
encargado principal de este procedimiento ha estimado que para revisar la forma y tomar la foto del
alumno se utilizan normalmente 40 segundos, sin embargo, en ciertas ocasiones esto puede tardar
15 segundos e, incluso, hasta un minuto.
Para capturar la firma en el sistema de forma electrónica, se dispone de 10 a 20 segundos y la
máquina destinada para la impresión de las credenciales se tarda exactamente 30 segundos en
imprimir y sellar la credencial.
El horario en que los alumnos pueden gestionar su credencial es de 8:00 am hasta 5:00 pm y son
atendidos por los siguientes encargados:
Diana: Encargada que trabaja medio tiempo diariamente de 8:00 am a 12:00 pm.
Laura: Encargada que trabaja tiempo completo diariamente de 8:00 am a 5:00 pm con una
hora de descanso entre las 11:00 am y 12:00 pm.
Mónica: Encargada principal solamente atiende alumnos cuando todos los encargados se
encuentran ocupados y existen alumnos en fila esperando obtener su credencial
universitaria. Tiene un descanso de 2:00 pm a 3:00 pm.
El promedio de llegadas por los estudiantes depende de la hora del día y se define en la siguiente
tabla:
A-54
HORA PROMEDIO DE ALUMNOS
8:00 am – 9:00 am 12
9:00 am – 10:00 am 14
10:00 am – 11:00 am 10
11:00 am – 12:00 pm 2
12:00 am – 1:00 pm 5
1:00 pm – 2:00 pm 7
2:00 pm – 3:00 pm 8
3:00 pm – 4:00 pm 7
4:00 pm – 5:00 pm 18
5. PASOS PARA CONSTRUIR EL MODELO DE SIMULACIÓN.
5.1. APROXIMACIÓN DEL MODELO
Horarios de los encargados y llegadas: Crear un horario para cada empleado.
Prioridad de los encargados: Crear un Set de recursos y capturarlos de acuerdo a la regla
Preferred order (orden preferencial)
Horario de llegada de los alumnos: Crear un horario de llegada para el módulo CREATE
Llegada de alumnos: Utilizar módulo CREATE que siga un horario de llegadas
Revisar forma y tomar foto: Captura y demora un encargado (Seize Delay)
Capturar firma en el sistema de forma electrónica: Una demora del tiempo de capturar
firma manteniendo el control del mismo encargado. (Delay)
Imprimir y sellar credencial: Demora para el tiempo de imprimir la credencial y liberar al
encargado que se capturó de forma inicial. (Delay Release)
5.2. ESQUEMATIZACIÓN INICIAL DEL MODELO
De forma esquemática, el modelo se plantea de la forma siguiente:
A-55
A partir de esta esquematización se puede ver de forma general los procesos que se encuentran
involucrados en la simulación, por lo que, con esta apreciación inicial, se consigue construir el
modelo.
5.3. HORARIOS DE LOS ENCARGADOS Y LLEGADAS
En ciertas ocasiones los recursos no se encuentran disponibles todo el tiempo de la corrida de la
simulación, por lo que, Arena, permite que los usuarios puedan crear horarios para poder
acomodar cambios en la disponibilidad del recurso.
Un horario es un patrón de cambios de la capacidad del recurso basado en el tiempo y este se
especifica introduciendo pares de datos de la capacidad del recurso y la duración de esa cantidad.
La capacidad de los recursos, es decir, los encargados, se encuentra definido por un horario, por lo
que dichos valores deben definirse en el módulo Schedule
Haciendo Clic en Schedule, se definen en la parte inferior de la pantalla los siguientes valores:
Name LLEGADAS
Type Arrival
Time Units Hours
Scale Factor 1
Durations Valores de la tabla
de llegadas de los alumnos
Los valores para las llegadas se introducen haciendo clic derecho sobre celda ROW y
seleccionando la opción Edit Via Spreadsheet
De forma gráfica, el horario de llegadas se percibe de la siguiente manera:
A-56
De la misma forma se definen los horarios de trabajo de los encargados:
A-57
Tiempo completo
Name TIEMPO COMPLETO
Type Capacity
Time Units Hours
Durations Duración del horario para el encargado
Medio Tiempo:
Name MEDIO TIEMPO
Type Capacity
Time Units Hours
Durations Duración del horario para el encargado
A-58
Encargado Principal:
Name ENCARG. PPAL
Type Capacity
Time Units Hours
Durations Duración del horario para el encargado
5.4. PRIORIDAD DE LOS ENCARGADOS
En ciertas ocasiones se pueden utilizar diferentes recursos para realizar las mismas tareas, sin
embargo estos recursos pueden tener horarios diferentes o pueden ser usados bajo un esquema
de prioridades, situación que se resuelve utilizando el módulo SET.
A-59
El Set agrupa elementos similares para que puedan ser referenciados a través de un nombre
común y un índice, típicamente pueden contener recursos, colas, estaciones, figuras, contadores o
expresiones, formándose con elementes del mismo tipo.
Para el modelo propuesto, y utilizando el módulo Set, se define el nombre del módulo Set y el
nombre de los encargados en orden de preferencia, ya que de acuerdo al enunciado del modelo
propuesto, los alumnos son atendidos en primer lugar por la encargada a medio tiempo (Diana),
luego por la encargada a tiempo completo (Laura) y en última instancia por la encargada principal.
De forma gráfica, la conformación del Set de Recursos se realiza de la siguiente forma:
5.5. LLEGADA DE LOS ALUMNOS EN BASE A HORARIO
Utilizando el módulo CREATE se define el nombre de la entidad y el tiempo de arribos que limitan
las llegadas de los alumnos en base a un horario (denominado “LLEGADAS”).
De forma gráfica, el módulo CREATE se rellena de la siguiente manera:
A-60
5.6. ASIGNAR LOS HORARIOS A LOS RECURSOS
A partir de los datos del problema se puede observar que cada uno de los encargados se
encuentra trabajando en base a un horario de asignación, es decir cada recurso cuenta con un
horario en el que este recurso se encuentra disponible dentro de la corrida de la simulación.
La capacidad de los recursos se encuentra basada en un patrón de cambios en el tiempo, por lo
que, para efectos del modelo, es necesaria la asignación de dichos horarios en el módulo
resources con los parámetros previamente establecidos dentro del módulo Schedule.
El software Arena cuenta con tres opciones para manejar el cambio en la capacidad del recurso
definido por el horario:
Preempt (Reemplazar): El cambio de la capacidad del recurso es instantáneo. El proceso
que se le está realizando a la entidad se completa cuando el recurso se encuentre
nuevamente disponible.
Wait (Espera): El cambio de capacidad del recurso ocurre cuando el proceso de la entidad
está completo. El siguiente cambio de la capacidad es desplazado.
Ignore (ignorar): El cambio de la capacidad del recurso ocurre cuando el proceso de la
entidad está completo. El siguiente cambio de capacidad ocurre en el tiempo señalado
impactando la duración del cambio.
A-61
Dicha asignación de horarios a los recursos se realiza dando clic sobre el módulo RESOURCES y
agregando en cada uno de los campos del módulo los datos que proporciona el modelo planteado.
De forma particular se tiene que la encargado Diana trabaja en base un horario de medio tiempo,
con regla de horario wait (espera), ya que, como recurso, su paro comienza hasta que la entidad lo
libera,
Name Diana
Type Base on Schedule
Schedule Name Medio tiempo
Schedule Type Wait
De forma gráfica, y para el conjunto total de encargados, la asignación de recursos se visualiza de
la siguiente manera:
5.7. REVISAR FORMA Y TOMAR FOTO
Utilizando el módulo PROCESS se define el proceso de “revisar forma y tomar foto”. Se utiliza la
acción “Seize Delay” ya que la entidad captura el recurso y lo demora para que no sea capturado
por otra entidad hasta que libera.
Se determina que el recurso del proceso de “revisar forma y tomar foto” se basa en el Set
previamente denominado como “Encargados”; Los elementos de un Set de recursos pueden
seleccionarse usando el nombre del Set y una regla de selección y los miembros de éste se
escogerán de acuerdo a la regla que se haya determinado:
Cyclical: Selecciona un recurso de manera cíclica.
Random: Selecciona un recurso de manera aleatoria.
A-62
Preferred Order: Selecciona el primer recurso disponible de acuerdo al orden que tenga en
el Set.
Specific member: Selecciona un miembro específico del Set por medio de un índice.
Largest Remaining Capacity: Selecciona el recurso que tenga la mayor capacidad
disponible.
Smallest Number busy: Selecciona el recurso que tenga el menor número de unidades
ocupadas.
La definición del recurso como un Set se realiza dando clic sobre el botón Add, recordando que la
captura del recurso se utiliza bajo la regla de “preferred order” y finalmente se deben llenar los
campos del tipo de retraso basado en la distribución triangular de los datos del problema. Es
necesario mencionar que se tiene que seleccionar la opción Value added ya que este proceso en
el que el usuario está dispuesto a pagar para que se realice el servicio.
De forma gráfica, la captura del recurso se define con el módulo process, creando el proceso
“revisar y tomar foto” y llenando los respectivos campos de la siguiente manera:
5.8. CAPTURAR FIRMA EN EL SISTEMA DE FORMA ELECTRÓNICA
Utilizando el módulo PROCESS se define el proceso de “capturar firma en el sistema de forma
electrónica”. Se utiliza la acción “Delay” ya que la entidad continúa en demora del recurso para que
no pueda ser capturada por otra entidad hasta que lo libera.
A-63
Del modelo propuesto se deduce que el tipo de distribución que sigue la demora es uniforme con
un mínimo de 10 segundos y un máximo de 20 segundos. Es necesario mencionar que, al igual
que en el proceso de “revisar forma y tomar foto” se tiene que seleccionar la opción Value added
ya que este proceso en el que el usuario está dispuesto a pagar para que se realice el servicio.
De forma gráfica, utilizando el módulo process, el proceso se define como “capturar firma” y se
llenan los respectivos campos de la siguiente manera:
5.9. IMPRIMIR Y SELLAR CREDENCIAL
Utilizando el módulo PROCESS se define el proceso de “imprimir y sellar credencial”. Se utiliza la
acción “Delay Release” ya que la entidad termina la demora del recurso para finalmente liberarlo.
Dentro de este proceso se especifica que los recursos se encuentran bajo un Set delimitado como
“encargados”. La definición del recurso como un Set se realiza dando clic sobre el botón Add,
recordando que la liberación del recurso se utiliza bajo la regla de “Specific Member” por el hecho
que se tiene que liberar el recurso específico que se tiene capturado.
A-64
Del modelo propuesto se deduce que el tipo de distribución que sigue la demora es Constante
debido a la automatización del proceso, por lo que, finalmente, se deben llenar los campos del tipo
de retraso basado en la distribución Constante de los datos del problema. Al igual que en los
previos procesos, se tiene que seleccionar la opción Value added ya que este proceso en el que el
usuario está dispuesto a pagar para que se realice el servicio.
De forma gráfica, utilizando el módulo process, el proceso se define como “imprimir y sellar
credencial” y se llenan los respectivos campos de la siguiente manera:
5.10. SALIDA DE ALUMNOS
Para definir la salida de los alumnos del modelo se utiliza el módulo Dispose y únicamente se
define con el nombre de “Salir”, recordando dejar chequeado el campo de record entity statistics
(grabar estadísticas de la entidad).
A-65
5.11. DEFINIR LOS PARÁMETROS DE LA RÉPLICA
Finalmente se corre la simulación delimitando los parámetros de la réplica con el comando RUN
dentro de la barra de menús y posteriormente seleccionando SET UP.
Para el modelo propuesto se define que se realizará una réplica de longitud de 9 horas, con la
limitante de 24 horas al día y basando las unidades de tiempo en Minutos como se muestra a
continuación.
A-66
6. EJERCICIOS PROPUESTOS
1. En cierto hospital especializado en el tratamiento de pacientes con deficiencias respiratorias se
tiene un arribo de pacientes según la siguiente tabla:
HORA PACIENTES
8:00 am – 9:00 am 34
9:00 am – 10:00 am 54
10:00 am – 11:00 am 34
11:00 am – 12:00 pm 34
12:00 am – 1:00 pm 65
1:00 pm – 2:00 pm 43
2:00 pm – 3:00 pm 21
De acuerdo los procedimientos del hospital, los pacientes deben ser admitidos, instalados con su
cilindro de oxígeno y despachados de las instalaciones. La admisión de los pacientes toma 3
minutos exactos, instalar a los pacientes con su cilindro de oxígeno puede tomar desde 5 minutos
hasta 10 minutos, aunque normalmente toma 7 minutos. Para el despacho de los pacientes se
debe firmar un formulario que el tiempo para esto sigue una distribución normal de Normal(4,1).
Los pacientes pueden ser instalados con su respectivo tanque de oxígeno por 2 voluntarios que
trabajan según el siguiente horario:
Voluntario1: Trabaja de 8:00 am a 3:00 pm con 1 hora de descanso al medio dia.
Voluntario2: Trabaja de 9:00 am a 1:00 pm sin descanso alguno.
Ya que el servicio debe ser brindado lo más rápido posible, determinar, por medio de un modelo de
simulación, cual es el tiempo máximo de espera por cada paciente y el total de pacientes atendidos
en el día.
2. Asumiendo que se incorpora un nuevo voluntario de tiempo completo al ejercicio anterior,
determinar, por medio de un modelo de simulación, el nuevo tiempo máximo de espera por cada
paciente.
A-67
3. La administración del hospital desea incorporar programas de voluntariado por tiempos
parciales, por lo que se pretende averiguar si la mejor opción para reducir el tiempo de espera en
los pacientes es tener 2 voluntarios a tiempo completo o 4 voluntarios que trabajen de la siguiente
forma:
2 voluntarios de 8:00am a 12:00pm
1 voluntario de 12:00 pm a 2:00 pm
1 voluntario que trabaje tiempo completo únicamente cuando los otros tres se encuentren
ocupados.
Determinar cuál de las dos opciones es más factible para los pacientes del hospital mediante la
elaboración del modelo de simulación.
A-68
PRÁCTICA Nº 5
ANIMACIÓN
1. OBJETIVO GENERAL
Que el alumno, a partir de la creación de un modelo de simulación, aprenda a utilizar la animación
de las entidades y recursos por medio de las herramientas que proporciona el software ARENA.
2. OBJETIVOS ESPECÍFICOS
Familiarización con la barra de herramientas de animación
Que el alumno sea capaz de animar las distintas entidades dentro del modelo de
simulación.
Que el alumno sea capaz de animar los distintos recursos dentro del modelo de simulación.
Que al final de la práctica el alumno sea capaz de construir un modelo de simulación
utilizando las diversas herramientas de animación que proporciona el software ARENA.
3. ANIMACIÓN
3.1. ANIMACIÓN DE LAS ENTIDADES
Animar las entidades es un medio efectivo para la visualización del flujo de las entidades a través
del modelo de simulación. Generalmente a esto se le llama “animación de conectores” ya que se
realiza la animación del flujo de las entidades a través de los conectores, es decir, a través de las
líneas que conectan los módulos gráficamente.
3.1.1. IMAGEN DE LA ENTIDAD (ENTITY PICTURE)
La imagen que se utiliza de forma inicial por un tipo específico de entidades se define en el módulo
ENTITY. La figura que el software utiliza como predeterminada es llamada “picture.report”, la cual
hace referencia a una hoja de papel. Esta figura será utilizada en todos los modelos planteados a
menos que se seleccione otra diferente de la lista predefinida de figuras en el módulo Entity.
A-69
Es necesario hacer mención que el software ARENA permite definir un nuevo nombre para una
imagen con su respectivo símbolo.
3.1.2. CAMBIAR LA IMAGEN DE LA ENTIDAD
Con el propósito de animar un cambio en la imagen de las entidades es necesario utilizar el módulo
ASSIGN, ya que, de otra forma, las entidades serán representadas por su imagen inicial y se
mantendrán sin ningún cambio durante todo el tiempo de corrida.
Módulo Assign
El módulo assign se utiliza para asignar nuevos valores a las variables, atributos, tipos de entidad,
imagen de la entidad u otras variables del sistema.
3.2. ANIMACIÓN DE OBJETOS
A-70
La barra de herramientas de animación proporciona la interface para animar objetos dentro del
Software Arena, sin embargo, es necesario aclarar que estas opciones no se encuentran
disponibles dentro de ningún menú.
Comúnmente, existen tres tipos de objetos utilizados:
Queues (Colas): Muestra las entidades que están esperando a que algún evento ocurra,
como por ejemplo, que un recurso esté disponible para su captura dentro del modelo.
Resources (Recursos): Un recurso se puede animar a partir de una imagen única asociada
para cada uno de los estados predeterminados y, durante la corrida, el recurso cambia de
imagen dependiendo del estado actual del recurso:
o Idle (ocioso)
o Busy (ocupado)
o Inactive (inactivo)
o Failed (fallado)
Pantalla de estatus:
o Reloj
o Fecha
o Variables
o Niveles
o Histogramas
o Gráficas
4. MODELO PROPUESTO
Utilizando el modelo propuesto en la Guía de laboratorio “Construcción de un modelo utilizando
múltiples recursos” realizar los siguientes cambios en el sistema:
Cambiar la imagen predeterminada de la entidad de “Picture.Report” a “Picture.Blue Page”.
Utilizando el módulo Assign, cambiar la imagen de la entidad después del proceso “revisar
y tomar foto” a “Picture.Yellow Page”.
Animar los recursos del modelo y el reloj que indica el tiempo de la simulación.
5. PASOS PARA CONSTRUIR EL MODELO DE SIMULACIÓN
A-71
5.1. CAMBIAR DE IMAGEN PREDETERMINADA
Utilizando el módulo Entity, se selecciona en la columna “Initial Picture” la imagen de “Picture. Blue
Page”.
5.2. CAMBIAR IMAGEN DE LA ENTIDAD
Se añade el módulo Assign a la lógica para reasignar la imagen de la entidad a “Picture.Yellow
Page”. A partir de los datos del modelo propuesto, el módulo assign debe colocarse posterior al
proceso “Revisar y tomar foto” y previo al proceso “capturar firma” con el nombre de “cambio de
imagen”.
La modificación del modelo de forma gráfica se aprecia de la siguiente manera:
Haciendo doble clic en el módulo assign nombrado “cambio de imagen” se llenan los campos
respectivos, agregando un assignment (asignación) y posteriormente seleccionando Entity picture
en el campo de Type (tipo) y Picture.Yellow Page en el campo de Entity Picture.
A-72
5.3. ANIMAR RECURSOS
Con la finalidad de animar los recursos dentro del modelo propuesto, se debe seleccionar con un
clic del ratón el botón Resource dentro de la barra de herramientas de animación.
En el campo Identifier (identificador) se selecciona el recurso que se desea animar. ARENA
permite utilizar imágenes de las librerías o crear alguna otra para los distintos estados del recurso.
A-73
Al seleccionar OK, el cursor aparecerá como una cruz la cual permitirá colocar el recurso en
cualquier parte de la página del modelo cuando se presione el botón izquierdo del ratón.
Esta misma secuencia se utiliza para los otros dos recursos presentes en el modelo propuesto y se
visualiza de la siguiente forma:
Cuando se realice la corrida del modelo, los recursos cambiarán de forma de acuerdo a los
atributos seleccionados para cada uno de los estados posibles que éstos puedan tomar.
5.4. ANIMAR EL RELOJ
Con la finalidad de animar el reloj dentro del modelo propuesto, se debe seleccionar con un clic del
ratón el botón Clock dentro de la barra de herramientas de animación.
Esta acción desplegará una nueva ventana donde se definen los atributos del reloj como starting
time (tiempo de inicio), formato del reloj, título del reloj, etc. Al terminar de definir los atributos, se
selecciona OK y el cursor aparecerá como una cruz la cual permitirá colocar el recurso en cualquier
parte de la página del modelo cuando se presione el botón izquierdo del ratón.
A-74
A-75
6. EJERCICIOS PROPUESTOS
1. Utilizando el modelo desarrollado en la práctica, animar todos los recursos con las imágenes
de la librería “contactcenter” de la forma siguiente:
2. Animar los diferentes recursos del set “ENCARGADOS” (Diana, Laura y Mónica), del ejercicio
de la práctica Nº 4: “construcción de un modelo utilizando múltiples recursos”.
A-76
PRÁCTICA Nº 6
AJUSTE DE DATOS CON EL INPUT ANALYZER
1. OBJETIVO GENERAL
Que el estudiante pueda, con el uso del Input Analyzer, ajustar, convertir o arreglar una serie de
datos que se recolecten para representar de forma realista los modelos de simulación.
2. OBJETIVOS ESPECÍFICOS
Facilitar el aprendizaje en la utilización de las herramientas de Input Analyzer, que le den la
capacidad al estudiante para ajustar una serie de datos, de manera que representen el
modelo a simular, como una distribución de probabilidad continua o discreta.
Que el estudiante maneje de forma eficaz Input Analyzer para establecer el mejor modelo
probabilístico que represente a los datos de un modelo real.
3. AJUSTE DE DATOS UTILIZANDO EL INPUT ANALYZER.
Una simulación basada en el comportamiento casual requiere de un mecanismo para generar
secuencias de eventos, en donde cada uno de ellos obedece a una ley de probabilidad que regula
determinado elemento del comportamiento casual en cuestión. La ley de probabilidad puede
adoptar muchas formas. Una que se encuentra comúnmente en el trabajo de simulación supone
que los eventos entre las secuencias son independientes y están distribuidos idénticamente.
El mecanismo para generar eventos debe, por tanto, tener la capacidad para producir variaciones
casuales o aleatorias a partir de una variedad de distribuciones de probabilidad continuas y
discretas. Cuando se dispone de datos se pueden hacer inferencias estadísticas con respecto a
cuáles distribuciones de probabilidad son apropiadas y qué valores deben de tomar los parámetros.
A-77
Arena se utiliza para realizar la simulación, mientras que el Input Analyzer determina la distribución
de probabilidad que más se asemeja a un conjunto de datos, además calcula los parámetros
adecuados para cada tipo de distribución de probabilidad, incluyendo información estadística
suplementaria como número de datos (data points), valor máximo (maximum), valor mínimo,
media, mediana, moda, desviación estándar, varianza, coeficiente de variación, sesgo, curtosis,
entre otros datos. Input Analyzer utiliza más comúnmente las pruebas de bondad de Ajuste de:
Anderson-Darling, Chi-Cuadrada y la de Kolmogorov-Smirnov.
Para preparar los datos que se utilizarán en el Input Analyzer, basta con crear un simple archivo de
texto ASCII que contiene los datos en formato libre. Cualquier editor de texto, procesador de textos,
hoja de cálculo o programa puede ser utilizado para este propósito. Los datos individuales deben
estar separados por uno o más caracteres de espacio en blanco. No existen otros requisitos de
formato. Cuando se usa un procesador de texto, asegúrese de guardar el archivo en un formato de
"texto único" (.txt). Esto elimina cualquier carácter o formato de párrafo que de otro modo serán
incluidos en el archivo. Arena utiliza una extensión de archivo predeterminado .dst para los ficheros
de datos.
4. MODELO PROPUESTO
Los datos de las personas que entran a un banco por hora son:
Determinar la distribución de probabilidad que más se ajusta a los datos.
5. PASOS PARA DETERMINAR LA DISTRIBUCIÓN DE PROBABILIDAD.
Primero se prepararán los datos para poder introducirlos a Arena. Abrir un Bloc de notas y colocar
los datos en una sola columna como se muestra a continuación:
A-78
Luego, guardar el archivo para poder importarlo desde Arena. A continuación, abrir Arena y entrar
en la ventana del Input Analyzer.
Al dar clic en Input Analyzer, aparece una nueva ventana. Dar clic en Nuevo para abrir un
proyecto nuevo.
El siguiente paso será importar los datos que fueron creados en el bloc de notas para que Arena
determine la distribución que más se ajusten a dichos datos.
Para importar datos, dar clic en File > Date File > Use Existing…
A-79
Al buscar el documento de bloc de notas, Arena despliega un histograma y los parámetros
correspondientes a dichos datos.
A-80
El siguiente paso es determinar la distribución de probabilidad que más se ajusta a estos datos.
En el menú Fit se muestra una lista de las distribuciones de probabilidad con las que Arena trabaja.
Como primera opción se podría revisar cada una de las distribuciones hasta observar cual es la
que más se ajusta o se elige la última opción, “Fit All” la cual evalúa cada una de las posibles
distribuciones hasta encontrar la que más se aproxima a los datos del ejemplo. Dar clic en “Fit >
Fit All”
Dicha herramienta permite evaluar, mediante la prueba de Chi cuadrado, cual distribución de
probabilidad muestra menor error indicando la que más se ajusta a los datos del ejemplo.
Para este ejemplo, Arena concluye que la distribución que más se ajusta a los datos una Normal
con media de 15.1 y desviación típica de 3.59.
A-81
La opción “Fit All Summary” , muestra el error que se obtiene al aproximar los datos del
ejemplo con todas las distribuciones de probabilidad. Al ver como se aproximan los datos con las
otras distribuciones de probabilidad, se puede observar que la siguiente distribución a la que los
datos más se ajustan es la distribución tipo Poisson.
A-82
6. EJERCICIOS PROPUESTOS
1. Cierta universidad, cuya especialidad es la economía y las finanzas, posee un sistema de
evaluación en el que las notas de los estudiantes de cada curso deben seguir una distribución
normal; Si esto no fuera así, se ha determinado que se sumará a un punto a todas las notas
menores de 6 y 0.5 a todas las notas mayores que 6. Ciertos alumnos insurgentes consideran que
esta regla no ha sido aplicada a la materia más difícil de la carrera por lo que quieren comprobar si
sus notas siguen una distribución normal.
Según el listado de publicado, las notas de los alumnos son las siguientes:
5 8 9 7 3 7
10 5 1 5 10 7
0 9 1 3 3 6
9 7 9 6 8 6
2 10 8 2 6 2
4 9 8 5 8 2
1 3 4 10 0 3
8 3 6 6 4 10
7 8 10 1 4 10
2 2 5 4 3 6
4 6 10 4 0 2
5 9 8 9 5 8
6 9 5 4 6 0
Determinar si la universidad ha obrado de forma embustera al no aplicar los procedimientos sobre
los cuales se rigen sus estatutos.
A-83
2. Determinar si los siguientes datos de fractura de un bloque de cemento siguen una distribución
de Weibull.
303 124 228 185 257
149 197 279 272 334
350 114 230 128 178
131 139 196 147 283
266 299 153 317 300
324 301 200 153 171
234 163 351 274 286
222 327 170 306 313
165 165 139 226 305
A-84
PRÁCTICA Nº 7
CONSTRUCCIÓN DE UN MODELO UTILIZANDO MÓDULOS AVANZADOS
1. OBJETIVO GENERAL
Que el Alumno aprenda y conozca las ventajas de utilizar los módulos avanzados del Software
Arena para la simulación y al mismo tiempo amplíe su capacidad de representar un modelo con
mayor precisión.
2. OBJETIVOS ESPECÍFICOS
El conocer las diferentes opciones que los módulos avanzados proponen y las ventajas
que estas representan.
Aprender a sincronizar con Arena datos existentes en diferentes programas y de igual
forma saber exportar datos de simulación hacia estos.
Que el alumno sea capaz de reconocer que módulo es el más conveniente para la
simulación de un sistema, el cual haga dicha simulación más apegada a la realidad.
3. CONSTRUCCIÓN DE UN MODELO AVANZADO.
3.1. MÓDULOS AVANZADOS
Los módulos avanzados representan un nivel diferente de simulación al momento de representar
un sistema real, estos permiten una mayor cantidad de opciones que los módulos básicos, aunque
siempre dependiendo de alguna forma de estos; es decir al aprender a utilizar los módulos
avanzados se puede simular muchos sistemas los cuales no pueden ser simulados solamente
utilizando módulos básicos, debido a que dichos sistemas son caracterizados por su gran
complejidad.
Los módulos avanzados se encuentran en el panel de procesos avanzados (advanced process), el
cual se está en la parte izquierda de la pantalla de Arena, (para agregarlo se da clic en el botón
“template attach” y se selecciona el archivo “advancedprocess.tpo”).
A-85
4. MODELO PROPUESTO
Se busca simular tres procesos diferentes de una panadería: horneado, empaquetado y entrega a
repartidores.
En una pequeña panadería se hacen un aproximado de 100 panes especiales diarios, la masa de
los panes es preparada y ésta puede ser para panes de dos diferentes tipos, dulce o salado, para
lo cual se sigue un orden específico (creado más adelante aleatoriamente para efectos de
práctica), contenido en la base de datos para la preparación.
Una vez la masa preparada, ésta llega en bandejas pequeñas de 4 panes, con una distribución
exponencial de una bandeja pequeña con una media de 30 minutos, sin importar si son dulces o
salados, luego son puestas en bandejas de mayor tamaño con capacidad para 10 panes, para
luego ser horneadas una bandeja a la vez; a continuación son separados y empaquetados en
bolsas.
A-86
Horno: Cuando una bandeja de 10 panes está completa se procede a hornear, el horno se calienta
hasta una temperatura de 120 grados centígrados, variando constantemente 2 grados por minuto,
una vez alcanza la máxima temperatura comienza el enfriamiento hasta una temperatura de 25
grados centígrados, al alcanzar ésta temperatura la bandeja es retirada y reemplazada por la
siguiente.
Empaque: al salir del horno la bandeja de 10 panes es separada y entra al proceso de
empaquetado donde se hacen bolsas de 4 panes, incluyendo dos panes salados y dos panes
dulces.
Entrega a repartidores: una vez empaquetados las bolsas de 4 panes pasan a la canasta de
finalizado, donde se espera a que llegue un repartidor, los repartidores llegan con una media de
una hora exponencialmente. Al llegar el repartidor, se avisa a la canasta de finalizado y se le
entrega hasta un máximo de 5 bolsas por repartidor, si no hay bolsas para entregar no se le
entrega nada y se espera el siguiente repartidor. Normalmente el máximo de repartidores que
llegan diariamente es de 10, pero esto es lo único que se puede modificar, la frecuencia de llegada
de los repartidores y la cantidad de estos que llegarán diariamente.
Para un mejor control se busca conocer cuantas bolsas se lleva cada repartidor, y el horario a las
que estas son entregadas, actualizando la base de datos de la panadería contenida en Excel.
5. PASOS PARA CONSTRUIR EL MODELO DE SIMULACIÓN.
El modelo de simulación se dividirá en 4 partes para un mejor orden y comprensión del mismo:
Modelo general: llegadas de bandejas pequeñas, espera y salida de bolsas las cuales
contienen 4 panes cada una.
Horneado: en un sub-modelo se simulará la llegada de bandejas grandes de 10 panes al
horno, así como las variaciones de temperatura dentro del mismo.
Empaquetado: otro sub-modelo tendrá la separación y empaquetado de las bandejas
grandes en bolsas de 4 panes selectos.
Repartidores: como un modelo independiente pero simultaneo se crearán las llegadas de
repartidores con la frecuencia especificada.
Nota: para este modelo es necesario agregar el panel de procesos avanzados.
5.1. MODELO GENERAL
Primero es necesario simular la llegada de bandejas pequeñas de 4 panes, esto se hace con un de
la siguiente manera:
A-87
Las bandejas son simuladas con la opción “entities per arrival”, es decir llegarán 4 panes al
mismo tiempo, se simulará un máximo de 25 arribos para simular la llegada de 100 panes.
Luego es necesario especificar que tipo de pan es cada uno, esta información se extraerá desde
un archivo de Excel donde se contienen todos los datos, con el módulo “ReadWrite” del panel de
procesos avanzados y al mismo tiempo ese mismo archivo servirá para la recolección de datos de
repartidores y tiempos de partida; antes de editar el módulo ReadWrite es necesario crear el
archivo de Excel contiendo las tablas que se utilizarán:
El tipo de pan puede ser simulado con la opción “ALEATORIO.ENTRE(1;2)” siendo el tipo
de pan 1, salado y el tipo de pan 2, dulce, luego se arrastra la celda hasta simular 100
datos.
A-88
Para nombrar rangos es necesario dar clic derecho a una celda y elegir la opción “asignar
nombre a un rango…”, aparecerá el siguiente cuadro:
Se pondrá como nombre “Tipo” y en la casilla “hace referencia a:” se marcaran los datos
de la celda A2 hasta la celda A101 donde se han simulado los tipos de pan; lo mismo se
hará para crear un rango de datos de salida, se nombrará a este rango “salida”:
A diferencia de los datos de entrada para este rango de salidas en la casilla “hace
referencia a:” se marcaran 3 columnas al mismo tiempo. DESDE B2 HASTA D101
A-89
Una vez marcados los rangos de entrada y salida se guardará el archivo de EXCEL en mis
documentos, con el nombre “avanzados”, este deberá ser un tipo de archivo de EXCEL 2003. (al
utilizar Microsoft EXCEL 2007, se deberá recurrir a guardar como > libro de EXCEL 97-2003)
Ahora en Arena se agregará un módulo ReadWrite, para la entrada de datos.
Luego se debe configurar el módulo File, contenido dentro del panel de procesos
avanzados, al dar clic en él, de la siguiente manera:
La casilla Access Type se define el programa de donde se tomaran los datos, en este caso
se elegirá Microsoft Excel; en la casilla operating system file, se buscará el archivo de
Microsoft Excel recién guardado.
A-90
End of File Action: ésta es la opción que le dirá a la entidad que hacer al terminar los datos
del archivo que está leyendo, en este caso se reiniciará (rewind).
Initialize Option: al inicio de cada réplica, el archivo que se está leyendo puede ser cerrado
(Close), reiniciado (rewind) o mantenerlo sin cambio alguno (Hold).
En la casilla Recordsets, se deben definir los rangos que se utilizaran, “tipo” y “salida” ya
creados en Excel, al dar clic en el botón “0 rows”:
En la casilla “Named Range”, deben aparecer los rangos ya asignados en el archivo de
Microsoft EXCEL, para el recordset 1 se elegirá “Tipo” luego clic en el botón “Add/Update”;
para el recordset 2 se elegirá el rango “Salida” y luego clic en el botón “Add/Update”.
A-91
Una vez editado el módulo File, en la ventana del modelo, se editará el módulo ReadWrite,
agregado anteriormente, y se agregará un módulo batch, del panel de procesos básicos, el
cual simulará las bandejas grandes para 10 panes.
El módulo batch sirve para agrupar un grupo de entidades en lotes, en éste caso 10 panes
en una bandeja, ya sea temporal o permanentemente; este módulo será temporal es decir
estará unido solamente para el horneado, eventualmente se sacarán los panes de la
bandeja, para esto se utilizará un módulo Separate.
A-92
Al dar clic en el botón Add… se elegirá un tipo de atributo y se nombrará “Tipopan”, éste
atributo se agregará a cada entidad que pase por el módulo ReadWrite.
Para el batch 1, la casilla Batch size deberá valer 10 para simular una bandeja de 10
panes, y deberá ser tipo temporal (temporary) para luego separarlo:
A continuación se agregaran dos sub-modelos, uno para el horno y uno para el empaquetado, los
cuales serán editados más adelante; para agregar un sub-modelo se recurre al menú Object >
submodel > add submodel, y luego se da clic donde se pondrá.
Al mismo tiempo se agregará un módulo hold del panel de procesos avanzados, para
simular la canasta de finalizado donde las bolsas de 4 panes esperaran la llegada del
A-93
repartidor. Los sub-modelos y el módulo hold deberán quedar conectados de la siguiente
forma: (Para conectar los módulos y los submodelos se utiliza el botón connect .)
Luego se necesita un módulo ReadWrite el cual permitirá guardar los datos de salida en el archivo
de Microsoft Excel, creado anteriormente; inmediatamente las bolsas con panes, salen del sistema
en la canasta de un repartidor, es decir se simulará con un dispose, ambos módulos se acoplarán a
continuación del módulo hold, de la siguiente manera:
Los módulos deberán quedar editados de la siguiente manera: (doble clic a cada módulo
para editarlo)
El tipo de espera que se simula
deberá ser Wait for signal, la cual
será enviada por el repartidor.
A-94
El valor esperado (Wait for value) es el valor que la señal enviará y el límite (Limit) quiere
decir que ese es el máximo de bolsas que se dejarán ir, al llegar la señal.
Para el ReadWrite, El tipo (Type) de éste módulo debe ser para escribir (Write to file).
Se usará el recordset 2, el cual contiene las tres columnas vacías en el documento de
Microsoft Excel
En cuanto las asignaciones (assignments) se agregarán una a una, en el orden que se
desean, es decir, primero la hora, luego los minutos y por el último el número de repartidor,
de la siguiente manera:
Dando clic en el botón Add se agregará la hora, la opción Type debe ser Other, ya que el dato que
se escribirá es un dato existente dentro del sistema (hora actual), al dar clic derecho en la casilla
de other, en el menú desplegable se elige la opción “Build Expression…”
A-95
Para poner la hora en que la entidad pasa por el módulo, en build Expression se despliega la
opción Date and Time Functions > Hour, así:
Al finalizar se da Ok y Ok a assignment y se procede a agregar los minutos de la misma forma,
excepto que esta vez en el Expression Builder se elegirá Minutes en lugar de Hour.
Y seguido se agregara la variable “repartidor”, es una variable debido a que es independiente de
las entidades pero está constantemente cambiando de valor, esto significa el número de repartidor
A-96
que llega a recoger, dando clic en el botón add, el tipo deber ser una variable y su nombre se
reemplazará por “repartidor”, así:
Al finalizar el cuadro del módulo ReadWrite deberá quedar de la siguiente manera: (NOTA: las
asignaciones deben tener el orden mostrado, ya que en ese orden serán escritas en las tres
columnas del archivo “avanzados” de Microsoft Excel.)
A-97
Para el Dispose:
5.2. HORNO
Para simular el horno, se dará doble clic en el primer sub-modelo, (para cambiar nombre solamente
se debe dar clic derecho al submodelo > propierties > Submodel Name : Horno).
Una vez abierto el submodelo horno, se agregaran cuatro módulos avanzados: Un seize, dos
adjust variable y un release, de la siguiente forma:
Para conectar los módulos y los submodelos se utiliza el botón connect . Estos deben
estar conectados a la salida y entrada del submodelo
El módulo Seize simula la utilización del horno, dando clic en el botón add… se agregará el
recurso “horno”:
A-98
Los módulos AdjustVariable representan el cambio de temperatura del horno, aumentando
en uno a un ritmo de 2°C por minuto hasta alcanzar los 120°C y disminuyendo en otro a un
ritmo de 4°C por minuto hasta una temperatura de 25°C, acá se agregará la variable
“temperatura”, al dar doble clic en cada uno de ellos deberán quedar de la siguiente forma:
A-99
La variable “temperatura” debe estar escrita de la misma forma en ambos módulos.
La casilla Update Interval, se refiere a la frecuencia con que estará actualizando la variable
temperatura. (para fines gráficos)
A-100
En el módulo release, se simula la liberación del horno, es decir, queda libre para una
nueva bandeja grande de 10 panes, al dar doble clic en el módulo y luego en la pestaña
Add se debe elegir de la lista desplegable el recurso “horno”:
Para cerrar el submodelo, se da clic derecho en la hoja de trabajo y luego clic a la opción close
Submodel.
5.3. EMPAQUE
Una vez terminado la edición del submodelo “horno”, se pasa a editar el submodelo 2, el cual se
nombrará “empaque” (clic derecho al submodelo y luego clic a la opción properties).
Al dar doble clic y abrir el submodelo se agregaran cuatro módulos: Un separate, un Batch,
un decide(del panel de procesos básicos) y un Match, quedando organizados de la
siguiente forma:
El módulo separate simulará la acción de extraer los panes de la bandeja grande, en el tipo
de separación se pondrá la opción Split existing batch, lo significa que se separará el batch
1, que simula la bandeja grande con capacidad máxima de 10 panes:
A-101
El módulo decide simula la separación de tipos de panes, en salado (tipo 1) y dulce (tipo 2),
el tipo será por condición, la cual será un atributo ya creado anteriormente, “Tipopan”, será
verdadero si su valor es igual a 1, de lo contrario será falso y se asumirá un valor igual a 2.
El módulo Match simula la organización de panes 2 salados y 2 dulces, la pestaña
“Number to match”, representa el número de entidades con atributos DIFERENTES que
deben llegar para poder ser desplegadas, es decir llegará un pan tipo 1 y un pan tipo 2
para lograr formar un “match”.
A-102
El módulo Batch simulará el empaquetado de los panes en bolsas de 4 panes previamente
separados y organizados, a diferencia del batch 1, éste tiene un tamaño de 4 y será
permanente:
Para salir del submodelo, se debe dar clic derecho a la hoja de trabajo y luego clic a la opción close
Submodel.
5.4. REPARTIDORES
A continuación se procederá a simular las llegadas de los repartidores, este puede hacerse junto al
modelo general, ya que será otro modelo independiente, pero relacionado.
Se necesitará agregar 4 módulos: un create y un dispose, del panel de procesos básicos y
un assign y un signal del panel de procesos avanzados, los cuales deberán quedar
organizados de la siguiente forma:
A-103
El create simulará la llegada de repartidores al sistema (pero no entran a la panadería), con
un máximo de 10 repartidores, todos con una media de 1 hora exponencialmente.
El módulo Assign permite asignarle una imagen y un valor al repartidor, al dar clic en el
botón Add... se agregan las asignaciones, en este caso será una variable ya existente,
“repartidor”, la cual ira aumentando de 1 a 1 cada vez que un repartidor llegue, deberá
quedar con los siguientes datos:
A-104
El módulo Signal envía una señal al módulo Hold (canasta de finalizado), el cual permite
liberar 5 bolsas de panes, el valor de la señal debe ser igual al valor editado en el módulo
Hold (100), y el límite de entidades liberadas será 5, así:
El módulo Dispose representa la partida de los repartidores:
Al final el modelo deberá verse de la siguiente manera:
A-105
Para éste modelo no será necesario editar las opciones de corrido (run setup), ya que al terminar
de llegar entidades la simulación finalizará, a continuación se correrá el sistema (es recomendable
tener cerrado el archivo de Microsoft Excel, para evitar conflictos).
Al finalizar la simulación y abrir el archivo “avanzados” de Microsoft Excel, se puede apreciar las
horas en que los repartidores recogen las bolsas, así como cual repartidor ha recogido dichas
bolsas.
6. ANÁLISIS Y CONCLUSIONES
Los datos obtenidos luego de correr la simulación deberán ser similares a los siguientes: tomando
en cuenta que los datos del tipo de pan son diferentes por ser simulados con la opción
ALEATOREO, lo que concluirá en que cada uno de las corridas (al actualizar la tabla aleatoria de
Excel) será diferente, también la hora variará, dependiendo a la hora que se haga la simulación.
A continuación se muestra un ejemplo de cómo modificar la llegada de repartidores: (tomando en
cuenta que los datos aleatorios de Excel no cambiaran si no se hace alguna modificación al
archivo)
A-106
Se puede ver que el repartidor 1 y el repartidor 2 no
aparecen dentro de la simulación, es decir, llegaron
antes que hubiera bolsas en la canasta de espera.
Para eso se puede modificar el módulo create de los
repartidores y especificar en la opción first creation la
hora a la que se quiere que llegue el primer repartidor,
para la cual se elegirá la cuarta hora del día (ya que
pasaron más de 3 horas antes que salieran las primeras
bolsas):
A-107
Al realizar este cambio y correr la simulación una vez más los datos deberán cambiar, (no es
completamente necesario cerrar el documento de Microsoft Excel, para correr la simulación):
En ésta recolección de datos se puede apreciar que el repartidor 1, si logró llevar bolsas de panes,
pero de igual forma se puede ver que algunos repartidores no llevan bolsas, como es el caso del
repartidor 2 y 5, y otros llevan menos de 5 bolsas, como es el repartidor 6, 9 y 10, para esto se
puede cambiar la frecuencia de llegada de repartidores y la cantidad de estos que llega.
Al simular un día de trabajo antes de empezarlo se puede (según el orden aleatorio de
tipos diferentes de panes) minimizar el tiempo perdido por los repartidores y los tiempos de
espera de los mismos, así como de la cantidad de ellos.
A-108
También es posible crear no un orden aleatorio de creación de tipos de panes diferentes,
sino tener un orden establecido, o un orden según pedidos, simularlos antes de
empezarlos y saber la cantidad de repartidores a contratar.
Este tipo de simulación permite disminuir costos logísticos y salariales.
7. EJERCICIO PROPUESTO
1. En una tienda popular de ventas varias se mantiene un inventario inicial de 50 cajas de
bebidas gaseosas; se ha comprobado que la venta de una caja sigue una distribución
exponencial de media 15 minutos. Al alcanzar un minimo de 10 unidades (punto de
reorden), se hace un pedido al centro de distribución cercano, éste tarda una hora en
arribar a la tienda desde el momento que es realizado.
El centro de distribución se mantiene en constante movimiento, en un promedio de 5 cajas
llega cada hora exponencialmente, cuando se hace el pedido se manda una señal y 50
cajas de bebidas son enviadas al inventario de la tienda.
Recomendación: Utilice el modulo delay para simular tiempo de transporte y módulos hold y
signal para simular inventarios.
A-109
PRÁCTICA Nº 8
EXPLORANDO VISUAL BASIC CON ARENA.
1. OBJETIVO GENERAL
Que el estudiante obtenga un panorama del funcionamiento básico del entorno del lenguaje de
programación “Visual Basic” y de sus aplicaciones con la interfaz de Arena, en el desarrollo de
simulaciones de modelos en las que sea necesaria o de gran servicio su utilización.
2. OBJETIVOS ESPECÍFICOS
Que el estudiante explore el lenguaje Visual Basic, y comprenda lo esencial de sus
aplicaciones adquiriendo un conocimiento que le será al útil al momento de simular con Arena.
Que el estudiante pueda desarrollar modelado de sistemas sencillos utilizando la herramienta
Visual Basic integradas en Arena (VBA).
3. INTRODUCCIÓN A VBA
A diferencia de las demás aplicaciones de Arena vistas hasta el momento, la aplicación de VBA
representa un grado mayor dificultad, esto porque implica una introducción teórica del
funcionamiento general de la aplicación. Por ésta razón antes de realizar una aplicación se
describirá brevemente los aspectos más importantes del lenguaje de programación.
3.1. ¿QUÉ ES VBA?
Es un componente de Arena bajo licencia de Microsoft® Corporation. Es el mismo lenguaje de
programación que ofrece Microsoft Office en sus aplicaciones, tales como Microsoft Word o
Excel®. Con ésta aplicación es posible escribir código personalizado que aumenta la lógica del
modelo y, por ende flexibiliza la simulación para beneficio del usuario. Además al integrar la
aplicación VBA a Arena, los desarrolladores o usuarios pueden utilizar Arena con otros programas
A-110
que soportan la interface de programación Microsoft ActiveX™, que permite a las aplicaciones que
la poseen contralarse las unas a las otras.
La aplicación VBA soporta acciones que son definidas por lo que se llama un modelo de objetos.
Los desarrolladores construyen este modelo de objetos para suministrar una interfaz de modo que
el usuario pueda realizar, mediante el lenguaje de programación, lo que usualmente haría con el
mouse o teclado. El modelo de objetos incluye:
Una lista de objetos que se pueden controlar, tales como: hojas de cálculo y gráficos.
Las propiedades de estos objetos que se pueden examinar o modificar, tales como: el nombre
de los objetos y el valor dentro de determinado campo (una celda de una hoja de cálculo).
Los métodos que se pueden efectuar sobre los objetos o que éstos pueden realizar, tales
como: crear o eliminar un objeto.
3.2. EL ENTORNO VBA
Para ingresar al editor de Visual Basic (VBE) se debe seguir la siguiente ruta: Tools > Macro >
Show Visual Basic Editor; presione las teclas Alt+ F1; ó simplemente presione el icono que
aparece en la barra de herramientas Integration, en caso de estar habilitada.
El aspecto del VBE se presenta a continuación:
En el lado izquierdo se encuentra el panel “Project (Proyecto)” que muestra una lista de modelo
abiertos, conteniendo a su vez una lista de los objetos de Arena, siendo estos: “Logic” y
“ThisDocument”.
A-111
El objeto “Logic” no permite modificación por parte del usuario; éste contiene las funciones,
subrutinas y variables que son convertidas a código por parte de los módulos de Arena, es decir,
que los módulos sirven de interfaz del usuario con el editor de Visual Basic. El usuario no debe
escribir código adicional en este objeto, ya que este espacio es utilizado exclusivamente por Arena
para escribir código automáticamente mientras se ejecuta el modelo.
El objeto “ThisDocument” es, como lo pone en evidencia su nombre (en castellano “Este
documento”), una referencia al modelo mismo. Permite modificación mediante la introducción de
propiedades y métodos, que pueden se asociados con los módulos de Arena. El objeto
“ThisDocument” posee una colección de eventos que contienen el código VBA, según David Kelton
et al. en el libro Simulación con Software Arena, estos pueden ser catalogados en tres grandes
categorías, se presentan algunos de ellos en seguida:
Eventos previos a la ejecución, como: DocumentOpen [AbrirDocumento] o DocumentSave
[GuardarDocumento].
Eventos de ejecución iniciados por Arena, tales como: RunBegin [IniciarEjecución],
RunBeginSimulation [IniciarEjecuciónDeSimulación], RunEndReplication
[FinalizarEjecuciónDeReplicación].
Eventos de ejecución iniciados por el modelo/usuario, como: UserFuntion
[FunciónDelUsuario], VBA_Block_Fire [VBA_Block_Disparar], OnKeystroke
[GolpeDeTeclaParaAcción].
En esta guía se le dará énfasis a lo eventos iniciados por la ejecución de Arena. Cuando se inicia la
ejecución del modelo Arena sigue una secuencia de eventos, en algunos de los cuales puede ser
introducido código VBA para flexibilizar la simulación. En caso de no existir código VBA dentro de
dichos eventos, Arena simplemente continúa la secuencia dando la impresión de que el evento no
existiera. Se muestra a continuación la secuencia de eventos, en negrita tal como se definen en el
libro Simulación con Software Arena, los eventos en los que es posible introducir código VBA:
1. RunBegin (iniciarEjecución)
2. Arena hace las verificaciones e inicializa el modelo
3. RunBeginSimulation (IniciarEjecuciónDeSimulación)
4. RunBeginReplication (IniciarEjecuciónDeReplicación)
5. Arena ejecuta la replicación
6. RunEndReplication (FinalizarEjecuciónDeReplicación)
7. RunEndSimulation (FinalizarEjecuciónSimulación)
8. Arena termina la ejecución de la simulación
9. RunEnd (FinalizarEjecución)
A-112
3.2.1. MODELLOGIC_RUNBEGIN
En este evento es posible realizar cambios estructurales en la simulación, como por ejemplo para
preguntar que valor de media el usuario desea asignar a la distribución de probabilidad de arribos
del módulo “Create”. Empero, dado que no se ha ejecutado la simulación no es posible modificar
valores propios del tiempo de ejecución como los atributos de las entidades.
3.2.2. ARENA HACE LAS VERIFICACIONES E INICIALIZA EL MODELO
En este momento en Arena, todas las variables tienen asignados sus valores iniciales, por
mencionar un ejemplo las capacidad de los recursos, pero no aún no se han introducido entidades
al modelo.
3.2.3. MODELLOGIC_RUNBEGINSIMULATION
Es en este evento que se debe insertar código VBA con el propósito que sólo se ejecute una vez al
principio de la simulación. Claro está, es necesario que el modelo no presente errores, de otra
manera no se ejecutara y Arena no “llamará” a éste evento. Puede ser utilizado para cargar
grandes cantidades de datos provenientes de fuentes externas tales como Excel, asignar valores a
las variables en el modelo de Arena, crear entidades, modificar las capacidades de recursos, etc.
3.2.4. MODELLOGIC_RUNBEGINREPLICATION
Durante la simulación, al principio de cada réplica Arena llamará a este evento. Sus aplicaciones
son similares a las descritas en el evento anterior (ModelLogic_RunBeginSimulation), con la
excepción que lo que se defina aquí se repetirá en cada una de las réplicas programadas.
3.2.5. ARENA EJECUTA LA SIMULACIÓN
En este paso se ejecuta la simulación del modelo, contemplando todo los que el usuario definió en
su desarrollo, se crean entidades, se toman y liberan recursos, las unidades salen del sistema.
Arena permite la introducción de código VBA por medio de sub-eventos como:
ModelLogic_UserFunction: se llama siempre que se hace referencia a la variable UF en la
lógica de Arena. Se podría utilizar este evento para realizar cálculos complejos para la demora
de un proceso o el criterio de decisión.
ModelLogic_VBA_Block_Fire: se llama cuando una entidad pasa a través de un módulo VBA
(aparecen en el panel Blocks) en la lógica del modelo.
ModelLogic_OnKeystroke: Se llama siempre que el usuario golpee una tecla en el curso de
ejecución de la simulación.
ModelLogic_OnClearStatistics: se llama siempre que se eliminan las estadísticas, como
cuando el tiempo de simulación llega al valor introducido para el periodo de calentamiento.
A-113
3.2.6. MODELLOGIC_RUNENDREPLICATION
Es llamado cuando cada réplica llega a su fin, por lo que si se suspende la simulación antes de que
la réplica termine el evento no se ejecutará. Puede ser utilizado para almacenar la información
proveniente de cada réplica en un archivo externo.
3.2.7. MODELLOGIC_RUNENDSIMULATION
Este evento es llamado cuando finalice la simulación, independientemente de cómo finalice ésta.
Aquí todavía siguen disponibles los datos del tiempo de ejecución de la simulación para la toma de
estadísticas.
3.2.8. ARENA TERMINA LA EJECUCIÓN DE LA SIMULACIÓN
En este evento Arena elimina todos los datos del tiempo de ejecución de la simulación.
3.2.9. MODELLOGIC_RUNEND
En este evento no se puede tener acceso a la información de tiempo de ejecución de la simulación,
sin embargo, es posible introducir código VBA a manera de un UserForm consultando si desea
ejecutar la simulación de nuevo.
4. MODELO PROPUESTO
Para ejemplificar los conceptos anteriormente vertidos, se utilizará un enfoque orientado a la
utilización de las herramientas, no explicándolo mediante un caso práctico, sino describiendo
detalladamente los pasos para crear código VBA satisfactoriamente en el Editor de Visual Basic.
El modelo que se propone deberá ser capaz de realizar mediante la automatización en VBA las
siguientes acciones:
Desplegar un formulario, del estilo “Userform”, que permita la introducción mediante un
campo de texto de la cantidad de entidades que entran simultáneamente al sistema.
Cambiar el valor medio de la distribución del tiempo entre arribos (el campo “Value”, del
cuadro de diálogo “Create”), por medio de la función de VBA “UserFunction” [UF()], de modo
que cuando la cantidad de entidades en línea de espera alcance cierto número (para el
ejemplo 5 entidades en espera) el tiempo promedio entre arribos sea considerablemente
grande (para el ejemplo 1000). Esto permitirá simular que el sistema rechaza nuevas
entidades cuando alcanza una capacidad crítica en cola, pero que una vez se “libere” puede
seguir procesando entidades al mismo ritmo.
A-114
Para hacer más asequibles lo conocimiento se utilizará un modelo sencillo del tipo: Create
ProcessDispose; con el que se ha trabajado previamente.
4.1. MÓDULO CREATE
Se supondrá que las entidades entran en lotes de cantidades variables, las cuales deben ser
especificadas por el usuario; que siguen una distribución de arribos exponencial con unidades de
referencia del tiempo en minutos (por el momento se dejará el campo “Value” con el valor de 1);
que el sistema no tiene un máximo de arribos, con la excepción de la restricción del número de
entidades en espera ; y que la primera entidad llega al momento en que se inicia la simulación (por
el momento se dejará el campo del número de entidades por arribo como 1, que es el números
predeterminado). El cuadro de diálogo del módulo lucirá como en la siguiente figura:
Con el propósito de simplificar la manipulación mediante código VBA del módulo “Create1” se
cambiará el nombre que éste tiene asignado, para ello se debe acceder al cuadro de diálogo de las
propiedades del módulo, selecciónese el módulo y luego presiónese la combinación de teclas Alt +
Enter. Una vez aparezca el cuadro de diálogo debe cambiarse en el campo “Tag” del nombre que
actualmente tiene (por ejemplo: Object.40) por la palabra Crear:
A-115
4.2. MÓDULO PROCESS
En cuanto a este módulo, se supondrá que es un proceso estándar con una lógica de acción del
tipo seize delay release y con un solo recurso capaz de ser “capturado” por una sola entidad a la
vez. La distribución que seguirá el proceso será triangular con un mínimo de 2, un valor más
probable de 4 y un valor máximo de 6 (todas la unidades en minutos). El tipo de asignación
(“allocation”) será Value Added. La ventana lucirá de esta manera:
A-116
4.3. MÓDULO DISPOSE
En este caso no será necesario ningún cambio al módulo, excepto, no esta demás revisar si la
casilla de verificación que reporta las estadísticas (Record Entity Statistics) ésta seleccionada. Se
verá así:
4.4. CREACIÓN DEL USERFORM
El siguiente paso para modelar el sistema que deseamos es abrir el Editor de Visual Basic, para
ello se sigue la ruta Tools > Macro > Show Visual Basic Editor. Una vez en el editor inserte un
formulario desde el menú Insert del editor siguiendo la ruta Insert > Userform; este comando creará
un formulario con el nombre de “UserForm1”, al lado izquierdo de dicho formulario se verá también
un cuadro llamado “Control Toolbox”, que contiene todos las herramientas para controlar el
formulario.
A-117
Ahora agréguese un cuadro de texto al formulario, para esto dese click al botón “TextBox” y
luego dibújese el correspondiente cuadro de texto utilizando el puntero del mouse. Posteriormente
agréguese un botón de comando dándose click al botón “CommandButton” y siguiéndose el
procedimiento anterior. El aspecto del formulario lucirá de ésta manera:
4.4.1. CÓDIGO DEL FORMULARIO.
Una vez se tenga el formulario de ésta manera dese doble-click sobre el botón “CommandButton”
para introducir código VBA. Lo que se pretende hacer con las líneas de código que se introducirá
es que cuando aparezca el formulario, luego de haber llenado el cuadro de texto y darse click al
botón, el valor que se ha introducido en el cuadro de texto sea el valor que se le asigne a la
cantidad de entidades que entran simultáneamente al sistema, es decir, el valor del campo
“Entities per Arrival” del cuadro de diálogo “Create”.
Luego de darse doble-click se deberá escribir el código siguiente:
Private Sub CommandButton1_Click()
Dim m As Model
Dim Modulo As Module
Dim i As Long
A-118
Set m = ThisDocument.Model
i = m.Modules.Find(smFindTag, "Crear")
Set Modulo = m.Modules(i)
Modulo.Data(“Batch Size") = TextBox1.value
Me.Hide
End Sub
Luego de escribirse el código la ventana del Editor de Visual Basic la ventana deberá verse como
la siguiente figura (para verse explicaciones de las líneas de código se debe leer los comentarios
escritos en color verde):
Nótese que en el método Data (que aparece en la línea 8 de código como “Modulo.Data”) aparece
el nombre “Batch Size”. En esa línea de código es donde se le dice a Arena a que campo debe
asignar el valor que se introduce en la en el cuadro de texto; como se habrá apreciado éste nombre
A-119
es distinto del campo que se quiere modificar, esto es porque el mensaje que el campo muestra,
“Entities per Arrival”, no es el nombre subyacente del operando, es decir, el nombre con el que
VBA llama al campo no es el mismo que aparece en el cuadro de diálogo del módulo.
Para saber el nombre “verdadero” del operando, se debe buscar en un archivo de texto que se
encuentra en el mismo directorio que todos los accesorios de Arena, para el caso como el módulo
que se esta explorando es el “Create” que forma parte de la colección “Basic Process”, estará bajo
el nombre BasicProcess.txt . Para buscarlo se debe encontrar el directorio en que Arena fue
guardado, la ubicación predeterminada es: Disco Local (C:) > Archivos de Programa> Rockwell
Software > Arena 12.0 > BasicProcess.txt . Una vez abierto el archivo el módulo “Create” es el
primero que aparece en lista, el archivo lucirá como la siguiente figura.
Como es posible distinguir, a la izquierda del archivo, aparecen los nombres de los operandos; y a
la derecha, mensajes con lo que aparecen los campos en el cuadro de diálogo de los módulos.
Para asignar un valor al operando por medio de código VBA, se debe hacer referencia al nombre
del operando y no a su mensaje. Es por esta razón que en el ejemplo que se trata, para asignar un
valor a “Entities per Arrival” se ha llamado a “Batch size”.
A-120
4.4.2. PROPIEDADES DEL FORMULARIO.
Cuando se crea un formulario se tiene la opción de modificar su formato según convenga al
modelador o al usuario. Desde el editor de Visual Basic de clic derecho sobre el formulario y
seleccióne “Properties”.
Aparecerá el Editor de propiedades del Formulario. Cada campo representa una determinada
propiedad del formulario como: el color, el tipo y formato de letra, sus dimensiones, su nombre, etc.
Para propósito de ésta guía se realizarán algunos cambios en los campos con el fin de ilustrar su
significado.
A-121
Colóquese en el campo “Caption” y escríbase la frase “Entidades por Arribo”. Nótese que
esto cambia el título del Formulario, mas no su nombre. La diferencia reside en que el título
(“Caption”) es lo que muestra el encabezado del formulario, y el nombre (“Name”) es como
VBA reconoce al formulario (“UserForm1”).
Ahora selecciónese el botón de comando (“CommandBottom1”), el cuadro de propiedades
cambia automáticamente al del botón de comando, e introduzca en el campo “Caption” la
palabra “Aceptar”.
4.5. CÓDIGO DEL EVENTO
Hasta este momento lo que se ha escrito en el editor Visual Basic, es el código VBA que permitirá
designar el número de entidades que arriban simultáneamente, sin embargo, no se ha ordenado a
Arena cuando debe ejecutar éste código. Para que el formulario aparezca al momento justo antes
que se ejecute la simulación, es necesario recordar los conocimientos vistos en la introducción a
VBA.
Como se recordará el evento en que es posible realizar cambios estructurales es
ModelLogic_RunBegin; por lo que las líneas de código deberán ser introducidas en este evento.
Ahora bien, para poder acceder a este evento se debe primero dar doble clic al icono con el
nombre “ThisDocument”, ubicado en la ventana “Project” a izquierda del editor bajo el folder con
nombre “Arena Objects”.
Paso seguido seleccionar de la lista desplegable (“combo box”), que aparecen arriba a la izquierda
del espacio destinado para escribir el código la opción “ModelLogic”; después en el “combo box” en
la parte superior derecha la opción “RunBegin”, tal como se muestra a continuación:
A-122
Hecho esto se procederá a escribir un código VBA que “llame” al formulario en el momento antes
en que se ejecute la simulación, para este propósito basta escribir el siguiente código:
Private Sub ModelLogic_RunBegin()
UserForm1.Show
End Sub
Con esta secuencia de pasos habrá terminado la creación y programación del “UserForm”. La
ventana del editor lucirá así:
4.6. UTILIZACIÓN DE LA FUNCIÓN “USERFUNCTION” [ UF() ]
Esta función es llamada cuando una entidad activa el evento SIMAN UF(); ésta, retorna un valor
que es proporcionado por la rutina programada por el usuario en VBA.
Para presentarla con un ejemplo, supóngase que se desea simular que el sistema rechaza
entidades una vez se haya alcanzado un número de entidades máximo en la línea de espera que
precede en el proceso. Una manera de hacerla sería incrementar el valor del promedio entre
llegadas ( “Value”, ya que se está trabajando con una distribución Exponencial) en una cantidad
suficientemente grande para que en la ejecución modelo de la impresión de que se han rechazado
entidades, cuando en realidad solamente se a incrementado el tiempo entre arribos.
4.6.1. INTRODUCCIÓN DE LA FUNCIÓN UF () EN EL CAMPO DEL MÓDULO “VALUE”
El primer paso es entrar al cuadro de diálogo del módulo entidad. Luego se debe introducir una
expresión que permita cambiar el valor promedio entre arribos utilizando el “Expression Builder”,
para ello dese click derecho en el campo asignado a “Value” y selecciónese “Build Expression”.
A-123
Cuando aparezca el cuadro de diálogo “Expression Builder” , en el cuadro de texto bajo el nombre
“Current Expression” escríbase la función UF(); posteriormente insértese, dentro del paréntesis de
la función, la expresión: NQ(Process 1.Queue). Para insertar la expresión véase el árbol que
aparece bajo el nombre “Expression Type”, selecciónese Basic Process Variables > Queue >
Current Number In Queue, y presiónese OK. La expresión terminada deberá verse así:
Luego de introducir toda la información en el cuadro de diálogo éste se vera así:
4.6.2. CREACIÓN DE LA RUTINA MODELLOGIC_USERFUNCTION EN EL EDITOR VBA
Hasta el momento sólo se ha escrito la expresión de la función UF () dentro del módulo entidad, lo
que garantiza que en el valor promedio del tiempo entre arribos sea generado por la función, sin
embargo, no se ha formulado una rutina en código VBA que estipule como se comportará la
A-124
función y que valores arrojará una vez sea ejecutada la simulación, eso se describe en esta
sección.
Accédase al editor Visual Basic, por alguno de los métodos ya estudiados. Posteriormente, en la
ventana “Project” selecciónese el objeto de Arena “ThisDocument” . Una vez ahí debe
seleccionarse de la lista desplegable izquierda, en el encabezado, la opción ModelLogic; y de la
lista despegable derecha la opción UserFunction , el encabezado lucirá como en la figura:
Al hacer dichas selecciones la primera línea del código será automáticamente escrita,
compleméntese el código como aparece en seguida:
Private Function ModelLogic_UserFunction(ByVal entityID As Long, ByVal
functionID As Long) As Double
Dim s As Arena.SIMAN
Dim t As Long
Set s = ThisDocument.Model.SIMAN
t = s.QueueNumberOfEntities(s.SymbolNumber("Process 1.Queue"))
If t < 5 Then
ModelLogic_UserFunction = "5"
Else
ModelLogic_UserFunction = "1000"
End If
End Function
Cuando se haya introducido el código VBA la pantalla del editor se verá de ésta manera (véase
comentarios aclaratorios en verde):
A-125
4.7. EJECUCIÓN DEL MODELO
Se han realizado ya el modelado y la programación VBA, es momento de ejecutar el modelo para
observar su funcionamiento. Para probarlo se asumirá que llegan tres entidades simultáneamente,
a manera de lote, por lo que en el formulario que aparecerá justo antes de ejecutar la simulación se
deberá escribir “3”.
Es importante recordar que en el código de la “UserFunction” se escribió que se aumentaría el
tiempo entre arribos, a partir de cuando el número de entidades en espera fuera superior a 4 ( 5 ó
más entidades); por lo que el número máximo que se debiera escribir en el formulario sería de 5,
de lo contrario las entidades que entrarán simultáneamente al principio de la simulación llenarán la
cola automáticamente por sobre el valor que se desea en cola, lo cual representaría una
contradicción. También se debe hacer la salvedad de que el modelo esta programado de tal
manera que cuando se cumpla la condición de entidades en espera, se cambie el tiempo en
promedio entre arribos, no obstante, esto no garantiza que existan menos de cinco entidades en
espera.
Ejecútese el modelo y luego de introducir el valor de “3” en el formulario dese click en “Aceptar”.
A-126
5. EJERCICIOS PROPUESTOS
1. Modifíquese el modelo presentado en la guía de manera que el valor introducido en el
formulario indique el número el tiempo promedio que cada entidad captura al recurso
(recuerde cambiar la distribución de probabilidad “Delay Type”). Además modifíquese el
formulario de manera que el título haga referencia al valor que se escribe en él y también
cámbiese el formato de color y escritura al gusto.
2. Créese una expresión de tipo “UserFunction” (utilizando como base la estudiada en la guía)
que esté en función de de la cantidad total de entidades en el proceso, a diferencia de las
entidades en cola como se hizo en el modelo propuesto.
A-127
PRÁCTICA Nº 9
UTILIZACIÓN DE LA HERRAMIENTA ARENA 3DPLAYER
1. OBJETIVO GENERAL
Que el estudiante conozca las herramientas necesarias y los procedimientos básicos para editar un
modelo en Arena que permita observar la simulación de dicho proceso en el editor de modelos en
3D.
2. OBJETIVOS ESPECÍFICOS
Que el alumno aprenda a crear los archivos en Arena, necesarios para editar los módulos
en 3DPlayer
Que el alumno se familiarice con la herramienta 3DPlayer.
Que el alumno pueda ejecutar un modelo en 3D.
3. ARENA 3DPLAYER.
3DPlayer es una herramienta que permite editar vistas en 3D de los modelos creados en Arena.
Esta herramienta es muy importante ya que simplifica, mediante una interfaz gráfica, la
comprensión de procesos utilizando dimensiones más reales del plano en el que se desarrollan los
procesos a simular.
La interfaz de Arena 3DPlayer es muy similar a la de Arena. La ventana principal se divide en tres
partes:
Ventana de diseño: Esta es el área en la cual de diseña el modelo en 3D. Se muestra un plano
cuadrado el cual simula la superficie en la cual se colocan todos los elementos a utilizar. Para
facilitar la creación de elementos, existe la opción de navegar a través del plano utilizando las
herramientas que cámara.
Barra de elementos: Esta es el área en la cual se muestran todos los elementos que forman parte
de la simulación como por ejemplo: recursos, estaciones, rutas, colas, etc.
Panel de propiedades: Esta es el área en la cual se definen cada una de las propiedades de los
elementos que se quieren modificar.
A-128
Para ejecutar una animación en Arena 3DPlayer se necesitan dos tipos de archivos, un Playback y
un Layout. Un Playback es un archivo en formato .pbf el cual se crea en Arena dentro de las
opciones de simulación y en la cual se almacenan todas las estadísticas generadas durante la
simulación del modelo. Un Layout es un archivo que se genera en Arena 3DPlayer o ya sea en
algún programa que maneje la extensión .cad; este archivo representa los elementos que se
observan en la simulación ya sea un cliente, un máquina, un recurso, etc.
4. MODELO PROPUESTO
En un centro de comida rápida, en el área de autoservicios, los clientes pasan por tres procesos
para poder recibir su orden. Primero, los clientes llegan a la ventanilla en la cual piden su orden,
este proceso puede tomar de 2 a 5 minutos. Luego, los clientes pasan a la siguiente ventanilla en
la cual pagan por lo que han ordenado, este proceso suele tomar entre 1 a 2 minutos. El último
paso del proceso es entregarle la orden completa al cliente, dicho proceso suele tomar entre 0 y 6
minutos. El tiempo que tarda un cliente en pasar de una ventanilla a otra es aproximadamente de
30 segundos. La tasa de arribos de los clientes al centro de comida se distribuye exponencialmente
con una media de 10 minutos.
Ventana de diseño
Panel de propiedades
Barra de
elementos
A-129
Se desea simular este proceso para 10 días.
5. PASOS PARA CREAR EL MODELO EN 3-D.
a. Crear el modelo a simular.
Para este modelo se utilizarán las herramientas del panel Advanced Transfer para ubicar rutas y
estaciones dentro del modelo. Estas servirán posteriormente en Arena 3Dplayer para identificar las
posiciones y recorridos de las entidades en el modelo.
El modelo a simular debe quedar de la siguiente manera:
En la lógica de módulo anterior se introducen dos nuevos módulos del panel “Advance Transfer” a
continuación se presenta una pequeña descripción de ambos:
Módulo “Route”: Este módulo transfiere una entidad a una estación específica o en la
siguiente estación, en la secuencia que ha sido definida. Permite al modelador representar
una el caso en que una entidad, requiere tiempo para desplazarse entre estaciones porque
estas no se encuentran adyacentes, además de definir la trayectoria que seguirá.
Módulo “Station”: Representa una locación, ya sea lógica o física, donde ocurre un
proceso. También se utiliza para almacenar la información de todos los tiempos y costos
acumulados por las entidades en su paso por esa estación, de manera que es posible
generar reportes con estos datos.
A-130
El módulo Create simulará la llegada de los clientes al sistema.
Los módulos Station que se han colocado en el modelo representarán las ventanillas en cada uno
de los procesos. Las entidades llegan a este módulo usando el módulo Route que tenga de destino
dicho módulo. Se definirá cada una de los módulos Station de la siguiente manera:
Station 1:
A-131
Station 2:
Station 3:
Los módulos Route simularán el recorrido de la entidad de una ventanilla a otra sin agregar tiempo
a los procesos. A estos módulos se les deberá definir el destino al cual serán enviadas las
entidades que lleguen a dicho módulo. Se definirá cada uno de los módulos Route como se
muestra a continuación:
A-132
Route 1
Route 2
Route 3
A-133
Los módulos Process se definirán de la siguiente forma (Tómense en cuenta que en cada proceso
se define un recurso diferente):
Tomar orden del cliente.
Pago de la orden.
A-134
Entrega de orden al cliente.
Por último se definirá el módulo Dispose con el nombre de “Salida de vehículos”.
A-135
Una vez definido cada uno de los módulos, el sistema se verá de la siguiente forma:
Para hacer más ilustrativa la simulación en 3-D, se modificará la imagen asignada a la entidad. Se
utilizará la imagen con el nombre de Pinture.Van en el menú de Entity.
A-136
b. Generar el Playback.
El Playback es el archivo que Arena genera para que Arena 3Dplayer reconoce todos los atributos
de dicho modelo.
Para generar este archivo se debe modificar la ventana Setup del modelo en la opción de Run
Control. Se debe marcar la opción Generate Playback File así como se muestra en la siguiente
figura:
Luego, se establecerá la longitud de la simulación para 50 horas y se correrá el modelo hasta que
finalice la simulación. Una vez terminen las 50 horas, guardar el archivo para que los últimos
cambios queden almacenados en el archivo que se acaba de generar.
A-137
c. Simula el sistema en Arena 3Dplayer.
Al ingresar en el módulo de Arena 3DPlayer, se tendrá que invocar el Playback generado en Arena.
Ingresar en File > Open Playback
Luego aparecerá una ventana en la cual se tendrá que buscar el Playback. Ese archivo se crea en
la misma dirección en la que se tiene el archivo .doe del modelo del cual se está simulando.
Una vez se abra el Playback, aparecerá en la ventana principal ciertos elementos en letras rojas lo
cual indica que el modelo está incompleto y se tienen que definir dichos elementos para poder
observar la simulación.
A-138
En este modelo, se deben definir las estaciones; representando las tres ventanillas, las colas en
cada uno de los procesos y los recursos que son los operarios en cada uno de los procesos.
Se comenzará por definir las estaciones, dar doble clic en Ventanilla1 para poder ubicar dicho
módulo en el plano. Al dar doble clic aparecerá una ventana en la cual se deberá colocar el nombre
de la estación que se desea ubicar, para este caso se colocará la que aparece por defecto y luego
dar OK en la ventana.
Luego se tendrá que ubicar la estación que representará la ventanilla 1. Dar clic en el plano para
ubicar la estación la cual es representada por un bloque de color blanco.
A-139
Seguir el mismo procedimiento para colocar las dos ventanillas restantes. El plano deberá verse de
la siguiente forma:
El siguiente paso será colocar las colas en cada uno de los procesos. Dar doble clic en la cola que
se desea colocar en el plano; aparecerá una ventana con sus respectivos parámetros. Dar clic en
el botón OK ya que no se modificarán dichos parámetros.
Luego, nuevamente en el plano se deberá trazar una línea simulando la línea de cola en la cual
esperaran los clientes. La cola debe quedar como se muestra en la figura siguiente:
A-140
Seguir el mismo procedimiento para colocar las dos colas restantes. El modelo debe quedar de la
siguiente forma:
El siguiente elemento a definir serán los recursos, para ellos dar doble clic en el nombre del
recurso que se desea colocar en el plano. Luego aparece una ventana con el nombre de dicho
recurso; dar clic en OK para colocar el recurso en el plano. El recurso se ubica de la misma forma
en la que se ubicaron las estaciones. El primer recurso queda ubicado de la siguiente forma:
A-141
Seguir el mismo procedimiento para colocar los otros dos recursos en el plano. El modelo debe
quedar de la siguiente forma:
Utilizando el cursor para navegar a través del plano se puede observar el modelo desde otra
perspectiva.
A-142
El último paso es definir las rutas por las cuales se moverán las entidades a través del sistema. Dar
clic en el icono Route para definir una ruta. Luego aparecerá una ventana en la cual de define
el origen y destino de la ruta. Dar en el botón OK para definir la ruta.
De clic en la estación que se desea establecer como origen y luego dar clic en la estación que se
desea establecer como destino.
A-143
Seguir el mismo procedimiento para unir mediante una ruta a las dos estaciones restantes.
Una vez definido cada uno de los elementos y las rutas en el sistema, solo queda ejecutar el
modelo. Al igual que en Arena, dar clic en el botón para ejecutar el modelo.
A-144
En este modelo solo se ha editado los elementos necesarios para la simulación, pero Arena
3DPlayer tiene una herramienta de dibujo la cual sirve para diseñar un entorno mucho más realista.
6. PROBLEMAS PROPUESTOS
1. Utilizando el modelo anterior, se desea agregar el área que corresponde a los clientes que
llegan al establecimiento sin vehículo. Utilizar un sistema de caja en la cual un operario
tomará la orden del cliente y recibirá el pago correspondiente y otro operario será el
encargado de entregar la orden al cliente. Utilizar los mismos tiempos de arribo y de
procesos.
2. Utilizando como base el problema propuesto Nº 3 de la práctica Nº1, animar el proceso
automatizado. No se debe olvidad el uso de los módulos estudiados del panel “Advance
Transfer” para mejorar la visualización del proceso.
A-145
PRÁCTICA Nº 10
ANÁLISIS DE ALTERNATIVAS: OUTPUT ANALYZER Y PROCESS ANALYZER.
1. OBJETIVO GENERAL
Presentar al estudiante dos herramientas dentro del paquete de Arena, el Output Analyzer y el
Process Analyzer, que permiten la evaluación de distintas alternativas o escenarios, capacitándole
para seleccionar la más adecuada en base a métodos estadísticos.
2. OBJETIVOS ESPECÍFICOS
Que el estudiante aprenda a utilizar ambas herramientas, y ofrecerle los criterios de decisión
para elegir cuál de ellas es la más adecuada para un problema particular.
Informar al alumno de las limitantes que tienen los algoritmos en los cuales se basan las
herramientas para elegir el escenario más conveniente, permitiéndole llegar a conclusiones
informadas aun cuando la respuesta del programa no sea concluyente.
Que el estudiante se capaz de generar desde un modelo de Arena, los archivos necesarios
para la evaluación de alternativas en las dos herramientas presentadas.
3. ANALISIS DE ALTERNATIVAS
Uno de los propósitos de la simulación es optimizar los sistemas mediante una comparación de
alternativas utilizando métodos estadísticos. Estos métodos se tienen ciertas limitantes a la hora de
evaluar grandes cantidades de información por lo cual se hace indispensable contar con un
sistema que realice dichos análisis.
El Output Analyzer y el Process Analyzer son una de las herramientas que proporciona Arena que
sirven para el propósito de evaluar escenarios en base a criterios especificados por el evaluador
para determinar la mejor opción ante dos o más alternativas.
El Output Analyzer únicamente puede evaluar dos alternativas como limitantes y su análisis lo hace
basándose en criterios previamente establecidos mediante una función la cual se crea utilizando la
herramienta de Expression Builder en el módulo Statistic.
A-146
El Process Analyzer a diferencia del Output Analyzer, puede comparar más de dos alternativas y
hacer un análisis global de todas las estadísticas generadas en el modelo.
Ambas herramientas se encuentran en la carpeta de Arena la cual puede ser ubicada desde el
menú principal así como se muestra en la figura siguiente:
4. MODELO PROPUESTO
Una cooperativa lanzara próximamente una nueva línea de créditos para sus cooperantes. Se ha
proyectado que la llegada de solicitudes para este tipo de créditos es cada 30 minutos de acuerdo
con una distribución exponencial.
Cuando llegan las solicitudes estas son recibidas por un practicante el cual revisa el monto
solicitado y las envía al departamento apropiado. El proceso de revisión al practicante le toma entre
dos y cinco minutos pero usualmente lo realiza en tres.
Aproximadamente el 25% de las solicitudes son de un monto superior a $2000. Estas solicitudes se
envían al departamento apropiado para su aprobación antes de proceder al desembolso. Este
proceso puede durar hasta 5 horas aunque casi siempre dura 2.5 horas y lo menos que puede
durar son 2. Solamente el 50% de las solicitudes son aprobadas y se envían a un agente de
desembolsos.
Las solicitudes de menos de $2000 se envían directamente a un agente de desembolsos.
Una vez que se le asigna una solicitud a un agente de desembolsos, este lo procesa entre 30 y 60
minutos.
La cooperativa planea contratar para la realización de sus funciones a un practicante y cuatro
ejecutivos con los salarios que se muestran en la siguiente tabla:
A-147
Empleado Salario/hora
Practicante $0.5
Imelda $5
Pablo $5
Juan $3
Salvador $3
Se desean evaluar las siguientes alternativas, para determinar aquella que genere los menores
costos y tiempos promedio en espera.
Alternativa Departamento de
aprobación
Departamento de
desembolso
1 Imelda
Pablo
Juan
Salvador
2 Imelda
Pablo
Juan
Salvador
5. OUTPUT ANALYZER
5.1. ELABORACION DEL MODELO A UTILIZAR
Primero se colocarán los módulos a utilizar en este modelo. La lógica a seguir tiene un esquema
como se muestra a continuación:
Antes de definir cada módulo, se crearán dos Set de recursos los cuales trabajarán en el proceso
de aprobación de solicitud y en el proceso de desembolso.
A-148
Para crear los Set de recursos, dar clic en el módulo Resource y en la hoja de cálculo
agregar los nombres de los recursos y sus respectivos salarios, la hoja de cálculo debe quedar de
la siguiente forma:
Luego de haber creado los recursos, ingresar en el módulo Set para crear los Set. Para la
primera alternativa, se creará un Set únicamente con Imelda y otro con Pablo, Juan y Salvador. Los
Set quedan distribuidos de la siguiente forma:
Para el Set 1:
Para el Set 2:
Una vez definidos los Set, se comenzará a definir cada uno de los módulos.
A-149
Para el módulo Create:
El módulo Process 1 el cual tendrá el Practicante, queda definido de la siguiente forma:
A-150
El siguiente módulo a definir es el módulo Decide el cual enviara las solicitudes menor a $2000 a
su respectivo proceso. El módulo queda definido de la siguiente forma:
Luego se definirán los procesos correspondientes a la aprobación de solicitud y desembolso. Los
módulos quedan definidos de la siguiente forma:
Para el Process 2:
A-151
Para el Process 3:
Seguido del proceso de aprobación, se definirá el módulo Decide que determina cuales son las
entidades que han sido aceptadas o no. Dicho módulo se define de la siguiente forma:
A-152
Por último, los módulos Dispose, para las solicitudes que saldrán del sistema, quedan definidas de
la siguiente manera:
Para Dispose 1:
Para Dispose 2:
Una vez definidos todos los módulos, el sistema debe quedar de la siguiente manera:
Como siguiente paso se definirán los archivos que se generarán en Arena los cuales analizarán las
estadísticas obtenidas. Para este ejemplo, se debe hacer una comparación entre los costos y el
tiempo de espera de los clientes utilizando la herramienta del Output Analyzer.
Ingresar en el módulo Statistic en la barra de Advanced Process. Luego se deben generar dos
estadísticas. El tipo de estadística será Output. Aparecerá una columna en la cual se debe colocar
la expresión la cual se generará desde la simulación misma. Para crear la expresión para los
A-153
costos de los recursos, dar clic derecho sobre la columna Expression y escoger la opción Build
Expression…
Luego, en el editor de expresiones, se deben sumar todos los costos relacionados a los recursos
que están involucrados en el sistema. Para ubicar los costos de recursos dar clic en el siguiente
directorio Basic Process Variable > Resource > Cost > Total Busy Cost / Total Idle Cost (si el lector
lo desea puede profundizar más en el significado y posibles aplicaciones de estas expresiones
utilizando el buscador en el menú Help > Arena Help). Se deberán agregar los costos de los
recursos cuando está ocupado y cuando esta ocioso ya que el costo por hora es fijo para cada
recurso y se deberá especificar el costo de cada uno de los recursos.
Para los costos de los recursos, la ecuación será la siguiente:
Para el costo de cada operario:
ResBusyCost(Practicante) + ResBusyCost(Imelda) + ResBusyCost(Juan) + ResBusyCost(Pablo) +
ResBusyCost(Salvador) + ResIdleCost(Imelda) + ResIdleCost(Juan) + ResIdleCost(Pablo) +
ResIdleCost(Practicante) + ResIdleCost(Salvador)
Además de los costos, otra estadística que se desea comparar es el tiempo en espera de los
clientes en cola.
Para el tiempo en cola:
TAVG(Aprobacion.Queue.WaitingTime) + TAVG(Realizar desembolso.Queue.WaitingTime) +
TAVG(Revision de monto.Queue.WaitingTime)
Una vez definidas las expresiones, la ventana de Statistic queda de la siguiente manera:
A-154
El siguiente paso será, definir los Output File que se crearán con las estadísticas que se han
definido; para ello, dar clic en la celda Output file y luego seleccionar el directorio en el cual se
desea guardar dicho archivo y colocarle un nombre diferente a cada uno ya que esos archivos
serán importados desde otra herramienta para su análisis correspondiente.
Antes de ejecutar el modelo, guardar el archivo con el nombre Alternativa 1.
Debido a que se desea una mayor precisión en los resultados, se simulará un día y se realizarán
100 réplicas.
Una vez termina la simulación, el siguiente paso será, crear la alternativa B en la cual Pablo pasa a
trabajar con Imelda. Para esta modificación, abrir el módulo Set y mover de un Set a otro el recurso
Pablo.
Luego se guardará el nuevo archivo con el nombre de Alternativa 2 y los archivos Output deberán
ser modificados para que al ejecutar el modelo, se creen las 2 alternativas por separado.
5.2. INGRESAR AL OUTPUT ANALYZER
El siguiente paso, después de ejecutar las dos alternativas, es ingresar en Output Analyzer desde
el menú inicio.
Dar clic en Nuevo para crear un nuevo proyecto, aparecerá la ventana siguiente:
A-155
Dar clic en Add para agregar las dos alternativas que se desean evaluar. En la ventana de
búsqueda se debe seleccionar la opción que permite visualizar todas las clases de archivos y luego
ubicarse en la carpeta en la cual se guardaron los archivos Output. Una vez agregadas ambas
alternativas la ventana se verá de la siguiente forma:
5.3. DEFINIR ALTERNATIVAS
Luego de agregar ambas alternativas, dar clic en el menú Analyze > Compare Means… Esta
opción lo que hará es comparar las medias estadísticas de ambas alternativas mediante una
prueba de hipótesis con un grado de significancia del 95% y determinar si las medias pueden
considerarse iguales o no.
Al dar clic en Compare Mean… aparecerá a siguiente ventana:
A-156
Para este ejemplo se dejara 0.95 el nivel de confianza. Dar clic en Add para agregar las
alternativas a evaluar. Aparecerá la ventana siguiente:
Se seleccionará para Data File A la alternativa 1 y para Data File B la alternativa B. y en
Replications se escogerá la opción Lumped lo cual indica que todas las replicas se analizarán
como un grupo y no por individual. Luego dar clic en OK para regresar a la ventana anterior y
nuevamente OK para realizar el análisis.
5.4. ANALISIS DE ALTERNATIVAS
Al analizar los datos, los resultados se muestran así:
Mediante la prueba de hipótesis de medias, con un 95% de confianza, se ha determinado que las
medias son iguales. En este caso se ha evaluado solamente los costos totales, para evaluar el
tiempo en cola se debe seguir el mismo proceso con la diferencia que al seleccionar las
alternativas, se deben colocar las que corresponden al tiempo en cola.
A-157
6. PROCESS ANALYZER
6.1. CREACIÓN DEL ARCHIVO .p
Como primer paso, para cada una de las alternativas se debe crear un archivo .p o utilizar uno
existente, el cual se generó al ejecutar el modelo y se encuentra en la misma ubicación que el
archivo .doe. (Otra forma de crearlo es: menú Run › Check Model, o se presiona F4, debe recordar
que las alternativas se encuentran en archivos diferentes y se creará un archivo .p para cada una
por separado.):
6.2. INICIANDO PROCESS ANALYZER
A continuación se debe abrir el “Process Analyzer” de Arena (Inicio › Programas › Rockwell
Software › Process Analyzer). La ventana principal del programa luce como se muestra en la
siguiente figura.
A-158
Una vez se ingresado al “Process Analyzer”, se procederá a crear un archivo nuevo (File › New).
En la ventana aparecerá una rejilla con varios campos, en la cual el título principal será “Scenario
Properties”, el cual hace referencia las propiedades de los escenarios.
A-159
6.3. INSERTAR ESCENARIOS
Para generar cada escenario, es decir, las tres alternativas previamente creadas, se puede dar
doble clic bajo la rejilla mencionada o seguir el menú insert › scenario. Cuando se agrega un
escenario aparece un cuadro de diálogo como el que se muestra a continuación.
En la casilla “Program File” se debe buscar la ubicación del archivo .p, presionando el botón
“Browse”, para la primera alternativa y así sucesivamente se crean los tres escenarios:
6.4. INSERTAR RESPUESTAS
Una vez creados los tres escenarios a partir de los archivos .p, se crearán las respuestas que se
generaran de la ejecución de cada escenario particular; cada escenario tendrá dos respuestas,
costos totales y tiempo de espera por cliente, las cuales son variables previamente definidas en el
modelo de Arena.
Para la primera respuesta se recurre al menú insert › response luego se abre el árbol User
Specified y luego se elige costos totales, se definirán dos posiciones decimales en la lista bajo el
nombre “Decimal Places”. En seguida se muestra el cuadro de diálogo correspondiente a “Insert
Response”.
A-160
Para la segunda respuesta en el menú insert › response se abre el árbol “User Specified” y luego
se elige Tiempo de espera por cliente, manteniendo siempre el número de posiciones decimales.
Deberán aparecer dos columnas de respuestas en la rejilla.
Nota: El proyecto debe ser guardado, de lo contrario al momento de ejecutar los escenarios, el
“Process Analyzer” pedirá que sea guardado.
6.5. EJECUCIÓN DE LOS ESCENARIOS
Para ejecutar los escenarios se deben seleccionar, posicionándose el puntero en el extremo de la
rejilla con los números correspondientes a los escenarios, aparecerá una flecha horizontal de color
negro, de clic sobre el número 1 arrastre hacia abajo.
A-161
Luego se sigue el menú Run › Go… o se da clic al botón play , aparecerá la siguiente ventana
que se muestra en la siguiente figura, clic en el botón ok para ejecutar.
Una vez finalizada la ejecución de los escenarios la columna de replicas y las columnas de
respuestas mostrarán los valores correspondientes a cada alternativa:
La columna con el título “reps”, indica el número de réplicas que se han ejecutado, en el transcurso
de la ejecución se puede apreciar como aumenta el número de réplicas hasta completar la cantidad
especificada (100 réplicas) en el archivo .doe de cada alternativa; la longitud de cada réplica (8
horas) también ha sido definida en este mismo archivo.
A-162
6.6. INSERTAR GRÁFICO Y DETERMINAR EL MEJOR ESCENARIO
Para poder apreciar de manera gráfica los resultados y poder determinar cual es la alternativa más
favorable para cada respuesta, es posible insertar un gráfico para cada una seleccionando la
columna de respuesta requerida, colocándose sobre el encabezado y dándole clic.
6.6.1. GRÁFICO DE COSTOS TOTALES
Luego de seleccionar al columna de costos totales se sigue la ruta Insert >Chart, y aparecerá la
siguiente ventana.
Se dejará marcada la casilla de la opción “compare the average values of a response across
scenarios”, en el tipo de gráfico se puede elegir cualquier gráfico, en éste caso se elegirá la opción
A-163
predeterminada “3D column”. Luego clic en siguiente, cambiará a la siguiente ventana,
correspondiente al paso 2 del asistente para gráficos.
En esta ventana se puede elegir ambas respuestas para ser presentadas en un solo gráfico, sin
embargo se utilizará solo una, ya que esto permitirá elegir la mejor alternativa posteriormente. Clic
en siguiente, cambiará a la siguiente ventana, que es el paso 3 del gráfico.
A-164
En esta ventana se puede modificar los nombres que llevarán los ejes, así como el título. Clic en
siguiente, cambiará a la ventana que se presenta a continuación, el paso 4 del asistente.
En esta ventana elegirá la opción “Identify Best Scenarios”, y por tratarse de costos totales se debe
seleccionar la opción “Smaller is better”, debido a que se busca minimizar costos. Para una vista
previa de cual escenario es el mejor se da clic en el botón “show best scenarios”.
Como se puede ver en la ventana, según el algoritmo utilizado por el “Process Analyzer” no se
puede asegurar que ninguna alternativa sea mejor en base a costos, ya que no varían
significativamente uno de otro.
En la ventana se muestra un campo con el nombre de “Error Tolerance”, que específica la distancia
(expresada en unidades de la respuesta) que se utiliza para dejar fuera las alternativas inferiores,
representa una medida de la tolerancia ha dejar fuera la verdadera mejor alternativa. Si se le
asigna un valor pequeño, menos alternativas serán eliminadas (como es el caso); si se le asigna un
valor mayor al predeterminado, menos escenarios serán elegidos como “mejores”, pero se correrá
el riesgo de elegir un mejor escenario cuando la diferencia entre estos no sea estadísticamente
significativa.
Una manera de solventar el problema anterior es correr un mayor número de réplicas, lo cual traerá
menor variabilidad, sin embargo, si aún se mantiene el problema significa que, realmente, los
A-165
escenarios son muy similares entre sí, por lo que correspondería evaluar otros distintos para
obtener un resultado más satisfactorio.
Para esta guía no se buscará corregir el resultado inicial del algoritmo, mas el lector está en
libertad de intentar alguna de las modificaciones. Luego al dar clic en finalizar, se generará el
gráfico que sigue:
6.6.2. GRÁFICO DE TIEMPO DE ESPERA POR CLIENTE
Para la columna de respuestas de tiempo de espera por cliente, se siguen los mismos pasos, sin
embargo, en este caso el algoritmo si arroja un solo escenario como el mejor. En la figura siguiente
se presenta la ventana correspondiente al paso número 4 del asistente para gráficos.
A-166
Al dar clic en el botón “Show best scenarios” muestra que el escenario 3, es decir, la alternativa 3,
es la más conveniente según el criterio de tiempo de espera.
El gráfico muestra en color rojo la columna que corresponde al mejor escenario, que como se
puede apreciar es el escenario 3.
7. EJERCICIOS PROPUESTOS
1. Una empresa está contemplando alternativas para establecer su política de salarios. La
empresa se dedica a la fabricación de paraguas artesanales a pequeña escala y necesita
un soldador. Al puesto del soldador arriban paraguas siguiendo una distribución normal con
media de 65 minutos y desviación típica de 10 minutos; el soldador procesa el paraguas
siguiendo una distribución uniforme con media de 25 minutos y desviación típica de 4
minutos; la empresa trabaja 40 horas a la semana y el proceso de soldadura es el último
en la cadena de producción. Las alternativas planteadas son las siguientes:
a. Pagarle $500.00 mensualmente, teniéndolo de planta.
b. La gerencia esta considerando pagarle $4.00 por hora efectiva trabajada,
dejándolo libre para elegir su horario.
Evalué las alternativas utilizando el “Output Analyzer”, y responda si hay evidencia
suficiente para considerar una alternativa mejor que otra. Selecciónese un nivel de
confianza de 0.95.
2. Utilizando el ejemplo anterior evalué las anteriores alternativas utilizando el “Process
Analyzer”.
A-167
PRÁCTICA Nº 11
UTILIZACIÓN DE LOS MÓDULOS DE FLUIDOS.
1. OBJETIVO GENERAL
Que el estudiante adquiera la habilidad para utilizar apropiadamente los módulos del panel “Flow
Process”, de manera que se capaz de simular procesos o sistemas que impliquen el flujo de
sustancias en tuberías o su respectivo almacenamiento en unidades contenedoras.
2. OBJETIVOS ESPECÍFICOS
Introducir los conceptos relativos a la simulación de procesos que conlleven flujo de
sustancias.
Que estudiante comprenda el funcionamiento de los módulos del panel “Flow Process”.
Que luego de la práctica el alumno se capaz de construir la lógica de un modelo que lleva
implícito el almacenamiento y transferencia de sustancias.
Que el estudiante pueda aplicar las técnicas de animación correspondientes a la herramienta
“level”, lo que le permitirá animar el flujo de sustancias en los dispositivos de almacenamientos
(tanques) y tuberías.
Que el alumno pueda interpretar y analizar la información que le proporciona Arena mediante
los informes, particularmente los relacionados con los módulos de flujo.
3. MODELO PROPUESTO
En un proceso industrial se necesitan dos substancias para obtener la mezcla comercializable.
Ambas substancias se almacenan en recipientes separados. El proceso consiste en descargar en
un recipiente para mezcla 75 Galones de substancia “A”, luego ésta se somete a un proceso con
una duración de 20 minutos, para posteriormente añadir 15 Galones de la substancia “B”. Una vez
que la mezcla tenga todos sus componentes, se somete otro proceso con una duración de 30
minutos, para en seguida descargar la mezcla y dejar el tanque de mezcla disponible para ejecutar
el proceso de nuevo. El proceso global tarda 1 hora 30 minutos.
A-168
El contenido de los tanques con substancia “A” (Tanque A) y con substancia B (Tanque B), es
vigilado mediante sensores diferentes, que cuando detectan el nivel especificado ejecuta una
orden de llenado del tanque con la substancia.
3.1. ESPECIFICACIONES DEL TANQUE CON SUBSTANCIA “A” (TANQUE A)
Capacidad del tanque: 300 Galones.
Estado inicial del tanque: Lleno
Velocidad de flujo de regulador de llenado: 5 Galones por minuto.
Velocidad de flujo de regulador de vaciado: 5 Galones por minuto.
Color de la substancia que contiene: Azul.
Nivel mínimo del tanque (antes de que el sensor lo detecte): 0 Galones.
3.2. ESPECIFICACIONES DEL TANQUE CON SUBSTANCIA “B” (TANQUE B)
Capacidad del tanque: 900 Galones.
Estado inicial del tanque: Lleno
Velocidad de flujo de regulador de llenado: 5 Galones por minuto.
Velocidad de flujo de regulador de vaciado: 5 Galones por minuto.
Color de la substancia que contiene: Azul.
Nivel mínimo del tanque: 600 Galones.
3.3. ESPECIFICACIONES DEL TANQUE CON MEZCLA (MEZCLA)
Capacidad del tanque: 100 Galones.
Estado inicial del tanque: Vacío
Velocidad de flujo de regulador de llenado: 5 Galones por minuto.
Velocidad de flujo de regulador de vaciado: 5 Galones por minuto.
Color de la substancia que contiene: Azul.
3.4. MÓDULO “TANK”
En el entorno de animación se utilizará el módulo “Tank” para simular los recipientes de
almacenamiento, junto con la herramienta de simulación “level”, que representa un esquema del
tanque o de tubería según se le indique.
Para comenzar a trazar la animación del modelo, se debe adjuntar el panel de módulos “Flow
Process”, para ello de clic en el ícono o sígase la ruta File > Template Panel > Attach, y en
A-169
el cuadro de diálogo “Template Panel” selecciónese el archivo “FlowProcess.tpo”, como se muestra
en la figura.
Ahora inserte el módulo “Tank” del panel recién adjuntado dándose clic sobre él y luego
arrastrándolo hacia la hoja de trabajo.
Luego repítase el procedimiento dos veces hasta tener tres tanques con su respectiva animación
(el cilindro plateado con un rectángulo de color azul dentro) y dispóngalos de manera que dos
queden a la izquierda de la pantalla, con los “tanques” a la derecha del módulo; y uno a la derecha
de la pantalla, con su respectivo “tanque” a la izquierda del módulo. La hoja de trabajo lucirá de
ésta manera:
A-170
3.5. INTRODUCCIÓN DE LA INFORMACIÓN EN EL TANQUE MEZCLA.
Paso seguido se introducirá la información en los módulos “Tank”. De doble clic al tanque “Tank 1”
y aparecerá el cuadro de diálogo siguiente:
El cuadro de diálogo se debe llenar acorde con la información del tanque correspondiente
proporcionada arriba. Este tanque es el de mezcla, por tanto llénese así:
En el campo “Name” introdúzcase el nombre de “Mezcla”
En el campo “Capacity” se debe escribir 100.0 (es la opción predeterminada)
En el campo “Initial level” se debe poner 0.0 (predeterminado)
A-171
Para el campo “Regulators”, debe darse clic en botón a la derecha “Add”, aparecerá otro
cuadro de diálogo. Debe seleccionarse el nombre que aparecerá como predeterminado
“Mezcla.Regulator 1” , en “Maximum Rate” el valor de 5.0 y en el campo “Units” déjese la
opción predeterminada en minutos (“Per minute”), de clic en OK como sigue:
Ahora recuérdese que el tanque tiene dos reguladores por donde entra la sustancia de los
otros dos tanques y por dónde es descargada la mezcla, por lo que debe agregársele otro
regulador (el cual se ocupará como regulador de salida. Siempre dentro “Regulators” de clic
en “Add” de nuevo, y llénese los campos como sigue:
Por último de clic en OK a ambos cuadros de diálogo. El cuadro de diálogo “Tank” lucirá de esta
manera una vez completo:
A-172
3.6. INTRODUCCIÓN DE LA INFORMACIÓN EN EL TANQUE A.
En este apartado se introducirá la información del Tanque A, que por ahora tiene el nombre de
“Tank 2”, llénese los cuadros de diálogo acorde a la información ya proporcionada anteriormente. A
continuación se describe el contenido de los módulos, evitando el uso de ventanas, por fines
prácticos:
Cuadro de diálogo del módulo “Tank”. Se le pondrá el nombre de “Tanque A”, tendrá una
capacidad de 300.0 y un nivel inicial de 300.0.
Regulador de salida. Se le dará el nombre de “Tanque A.Regulator 1” y tendrá una tasa
máxima de flujo de 5.0 por minuto.
Regulador de entrada. Se le dará el nombre de “Tanque A.Regulator 2” y tendrá una tasa
máxima de flujo de 5.0 por minuto.
3.7. INTRODUCCIÓN DE LA INFORMACIÓN EN EL TANQUE B.
Es momento de introducir la información que corresponde al Tanque B (“Tank 3”), siempre
utilizando como referencia la los datos que a éste atañen. Los cuadros de diálogo
complementados, se presentan en seguida:
Cuadro de diálogo del módulo “Tank”. Se le otorgará el nombre de “Tanque B” , contará con
una capacidad de 900.0 y un nivel inicial de 900.0
A-173
Regulador de salida. Se le dará el nombre “Tanque B.Regulator 1” y su tasa de flujo máximo
será de 5.0 por minuto.
Regulador de entrada. Tendrá el nombre de “Tanque B.Regulator 2” y una tasa de flujo
máximo de 5.0 por minuto.
3.8. CREACIÓN DEL AMBIENTE DE ANIMACIÓN
En esta sección se añadirá la animación correspondiente a las tuberías, que unen los tanques de
la izquierda con el de la derecha (el de mezcla); para ello debe darse clic en el ícono “level” de la
barra de herramientas “Animate”.
3.9. TUBERÍA TANQUE A MEZCLA
Luego de seleccionarse la opción “level” aparecerá el siguiente cuadro de diálogo:
Como se habrá notado con ésta herramienta es posible diseñar los tanques que Arena
automáticamente anexa en la hoja de trabajo junto al módulo “Tank”, pero esta vez se utilizará para
simular las tuberías. Para lograr esto en la sección “Type” selecciónese la opción “Flow”, la
A-174
estructura del cuadro de diálogo variará un poco para propósitos de la animación de la tubería.
Modifíquese el cuadro de diálogo de la siguiente manera:
1. En el campo “# Flow Arrows” cámbiese el valor a 5 (recuérdese que la velocidad de flujo es de
5 galones por minuto). Éste valor indica el número de flechas que recorrerán la “tubería”
mientras se desarrolla la simulación, a mayor número de flechas dará la impresión de que
fluye más rápido.
2. Sobre el campo con el nombre “Rate Expression” de clic derecho y selecciónese la opción
“Build Expression”, en el cuadro de diálogo “Expression Builder” elíjase del árbol de opciones
“Expression Type” la expresión “”, que se encuentra en el subconjunto “Regulator”, que a la
vez esta dentro del conjunto “Flow Process Variables” (ruta “Flow Process Variables” >
“Regulator” > Flow Rate Between Regulators).
3. Cuando se ha seleccionado la opción “Flow Rate Between Regulators”, aparecerán dos
campos de listas desplegables que aparecen en la esquina superior derecha. En la lista
desplegable bajo el nombre “Source Regulator Name”, selecciónese la opción “Tanque
A.Regulator 1”; y en lista desplegable bajo el nombre “Destination Regulator Name”,
selecciónese la opción “Mezcla.Regulator 1”. Así lucirá el cuadro de diálogo “Expression
Builder”:
A-175
La ventana del cuadro de diálogo “Level”, una vez complementada con la información aparece
abajo.
Cuando se le de clic al botón OK aparecerá el puntero en forma de cruz, de manera que se pueda
dibujar la tubería con el mouse; para ello, de clic al costado derecho del dibujo de animación del
“Tanque A” y luego doble clic al costado izquierdo de “Mezcla”, y así habrá terminado el diseño de
esta tubería.
3.10. TUBERÍA TANQUE B MEZCLA
Siguiendo el mismo procedimiento para ésta tubería, pero ajustando los parámetros acorde a los
del Tanque B tendríamos complementados los cuadros de dialogo de la siguiente manera:
A-176
“Expression Builder”
“Level”
A-177
Después de haberse dibujado ambas tuberías, la hoja de trabajo se verá de la manera siguiente:
3.11. LÓGICA DEL MODELO.
Hasta este punto sólo se ha descrito en el modelo cuales son los tanques que existen, sus
reguladores, el sentido de flujo, velocidad de flujo, etc.; sin embargo, no le se ha dejado explícita la
lógica que seguirá, es decir, cuando comenzará el flujo, los tanques involucrados, la cantidad de
substancia que fluye, y otras particularidades de la secuencia de simulación. En esta sección se
explicará como desarrollar dicha lógica para el ejemplo propuesto.
Para facilitar el desarrollo de ésta guía primero se insertarán todos lo módulos necesarios para
desarrollar la lógica, y luego de tener todo el “diagrama” del modelo se procederá a establecer los
parámetros de éste.
3.12. INTRODUCCIÓN DE LOS MÓDULOS DE LA LÓGICA DEL MODELO.
Al costado inferior derecho (sólo una sugerencia por estética, los módulos pueden ser colocados
en cualquier lugar de la hoja de trabajo), introdúzcanse y conéctese entre sí, es esta secuencia, los
siguientes módulos:
1. Del panel “Basic Process” introduzca un módulo “Create”.
2. Del panel “Flow Process” introduzca un módulo del tipo “Seize Regulator”.
3. Del panel “Flow Process” introduzca un módulo del tipo “Flow”.
4. Del panel “Flow Process” introduzca un módulo del tipo “Release Regulator”.
A-178
5. Del panel “Advanced Process” introdúzcase un módulo del tipo “Delay”.
6. Para facilitar el desarrollo, dibújese un rectángulo alrededor del modelo que englobe módulos
desde “Seize Regulator” hasta “Delay”, y luego utilícese la opción “Duplicate”, que aparece
luego de dar clic derecho.
7. Conéctese, con la herramienta “Connect”, el primer módulo “Delay” insertado con el módulo
“Seize Regulator” del grupo de módulos duplicados.
8. Repítase el mismo procedimiento para duplicar módulos “Seize Regulator”, “Flow” y “Release
Regulator”; luego conéctese al resto del modelo.
A-179
9. Ahora introdúzcase un módulo “Dispose” para recibir las entidades generadas. Con esto se ha
finalizado la “rama” principal de la lógica.
10. El siguiente paso consiste en construir la lógica del funcionamiento de los sensores, para ello
introdúzcase un módulo “Sensor”. Este módulo permite el monitoreo de las operaciones
de un tanque, y puede habilitarse para ejecutar un comando, según lo requiera el modelo. Se
profundizara más adelante en él.
11. Duplíquese la última línea del proceso creado arriba, desde “Seize Regulator” hasta “Dispose”
y se coloca a un lado del módulo “Sensor”. Por el momento no es posible conectar el módulo
“Sensor” al módulo “Seize Regulator”, se conectará luego.
12. Como siguiente paso se duplicará la línea de lógica del modelo recién creado.
A-180
Una vez se ha completado el modelo lucirá como se muestra en la figura.
3.13. ESTABLECIMIENTO DE LOS PARÁMETROS DE LOS MÓDULOS DE LA
LÓGICA PRINCIPAL.
Como se ha realizado ya el “mapa” del modelo, es momento para introducir la información de
acuerdo con las condiciones de comportamiento del modelo tal como fueron estipuladas en el
problema. Solamente se mostrarán los cuadros de diálogo correspondientes a los primeros
módulos de la lógica del modelo para ilustrar como se deben llenar.
A-181
Módulo “Create”. El módulo se nombrará “Comienzo de ciclo” y se llenará de la siguiente
manera.
Primer módulo “Seize Regulator”. El módulo debe ser nombrado “Captura Regulador 1”. Se
debe declarar los nombres de los reguladores que se “capturarán”, en éste caso
“Mezcla.Regulator 1” y “Tanque A.Regulator 1”, de clic en el botón “Add” y procédase a
elegirlos de la lista desplegable. Los cuadros de diálogo se verán así:
A-182
Primer módulo “Flow”. Se nombrará al módulo “Flujo A”. En el campo “Type” se erigirá la
opción predeterminada “Transfer” (esto determina que el flujo es entre módulos “Tank”); en el
campo “Source Regulator Type” se dejará la opción predeterminada, mientras que en el
campo a la derecha “Regulator Name” se seleccionará “Tanque A.Regulator 1”; en el campo
dedicado al nombre del otro regulador se seleccionará “Mezcla.Regulator 1”; por último el
campo “Quantity” tendrá el valor de 75.
A-183
Primer módulo “Release Regulator”. Se le dará el nombre de “Libera Regulador 1”. Se debe
declarar el regulador que se soltará, en este caso “Tanque A.Regulator 1”, el procedimiento es
idéntico al del módulo “Seize Regulator”. Los cuadros de diálogo complementados se
muestran en seguida.
A-184
Primer módulo “Delay”. Éste es el módulo que simulará la espera de 20 minutos, como tal
se nombrará “Espera 20 minutos”.
Segundo módulo “Seize Regulator”. Llevará el nombre de “Captura Regulador 2”. En este
módulo sólo se capturará al regulador “Tanque B.Regulator 1”.
Segundo módulo “Flow”. Se nombrará “Flujo B”, es el módulo que permite el flujo entre el
Tanque B y el de mezcla. La cantidad que de substancia que transfiere es de 25 . El
Regulador de origen (“Source Regulator”) será el “Tanque B.Regulator 1”, mientras que el de
destino (“Destination Regulator”) será el “Mezcla.Regulator 1”.
Segundo módulo “Release Regulator”. Se le dará el nombre de “Libera Regulador 2”, y se
utilizará para liberar los reguladores “Mezcla.Regulator 1” y “Tanque B.Regulator 1”.
Segundo módulo “Delay”. Este módulo permitirá simular el proceso con duración de 30
minutos, se le dará el nombre de “Espera 30 minutos”.
Tercer módulo “Seize Regulator”. Tomará el nombre “Captura Regulador 3”. En esta
ocasión el módulo sólo capturará el regulador “Mezcla.Regulator 2”, que es el regulador de
descarga del tanque Mezcla.
Tercer módulo “Flow”. Se le dará el nombre de “Descarga de Mezcla”. En el regulador de
origen se pondrá al único que se ha capturado “Mezcla.Regulator 2”; en cuanto a la cantidad,
debido a que se descargará todo el contenido, será de 100.
Tercer módulo “Release Regulator”. Recibirá el nombre “Libera Regulador 3”. Este módulo
liberará el módulo capturado “Mezcla.Regulator 2”.
Módulo “Dispose”. Este módulo sirve para depositar la entidad que generó el ciclo de flujos,
recibirá el nombre de “Fin de ciclo”.
3.14. ESTABLECIMIENTO DE LOS PARÁMETROS DE LA LÓGICA DEL SENSOR
DEL TANQUE A.
En este apartado se introducirá la información a los módulos que se encargarán de ejecutar la
acción de llenado del “Tanque A”, una vez éste haya alcanzado su nivel de contenido mínimo
establecido en el problema. Se utilizará la primera línea de lógica del modelo que contiene el
A-185
módulo “Sensor”, de arriba hacia abajo. De igual forma que el apartado anterior sólo se mostrarán
las imágenes de los cuadros de diálogo correspondientes a los módulos que aún no se han
abordado.
Módulo “Sensor”. Este módulo detecta cuando se ha alcanzado un nivel determinado del
contenido en tanque. En el campo “Name” se escribirá el nombre “Sensor A”; el campo con
lista desplegable “Tank Name” se seleccionará “Tanque A”; los demás campos se dejarán
como tal, pero la casilla “Create Discrete Entity” debe ser seleccionada, esto permitirá que
cuando se alcance el nivel programado en el sensor se generé una entidad que de origen al
resto de la lógica del evento de llenado del Tanque A.
El campo “Location Type”, indica el criterio que seguirá el módulo para percibir cuando el nivel
deseado, ya sea un nivel específico o un porcentaje del contenido total; el campo “level” indica el
nivel que activará el sensor; el campo “Crossing Direction”, en este caso seleccionado “Negative”,
indica que el sensor esperará que el nivel alcance ese nivel o inferior para activarse; el campo
“Initial State” sólo habilita al módulo; mientas que la casilla “Animation” es para establecer si se
desea o no, poner la animación de un generador de luz que aparece sobre el módulo
automáticamente, que mediante un código de luz establece si el sensor se ha activado.
A-186
Módulo “Seize Regulator” del sensor A. Se le dará el nombre de “Captura Regulador A”. Se
capturara el regulador de llenado del Tanque A, nombrado “Tanque A.Regulator 2”.
Módulo “Flow” del sensor A. Recibirá el nombre de “Llenado de Tanque A”. En el campo
“Type” se seleccionará “Add”, de esta manera se le ordenará a Arena que el flujo generado es
de llenado; en el nombre del regulador de destino selecciónese “Tanque A.Regulator 2”; y en
la cantidad 300.
Módulo “Release Regulator” del sensor A. Se le dará el nombre de “Libera Regulador A”.
Selecciónese solamente el regulador “Tanque A.Regulator 2”.
Módulo “Dispose” del sensor A. Se nombrará al módulo “Fin de Llenado Tanque A”.
3.15. ESTABLECIMIENTO DE LOS PARÁMETROS DE LA LÓGICA DEL SENSOR
DEL TANQUE B.
Ahora se ingresará a los módulos la información de acuerdo a lo pautado por el problema. Se
utilizará la línea de lógica de modelo restante, el procedimiento es similar al descrito arriba para el
Tanque A, por lo que no se ha considerado necesario agregar imágenes explicativas.
Módulo “Sensor”. Se le dará el nombre de “Sensor B”. En el nombre del tanque (“Tank
Name”) selecciónese el Tanque B, y en le nivel 600. No debe olvidarse de marcar la casilla
“Create Discrete Entity”.
Módulo “Seize Regulator” de sensor B. Le pondrá el nombre de “Captura Regulador B”. Se
capturará el regulador de llenado del Tanque B, “Tanque B.Regulator 2”.
Módulo “Flow” del sensor B. Se nombrará al módulo “Llenado de Tanque B”. El tipo de flujo
será “Add”; el nombre del regulador de destino “Tanque B.Regulator 2”, como es de esperar,
ya que es el único capturado; y la cantidad de substancia depositada dentro del tanque será
300.
Módulo “Release Regulator” del sensor B. Recibirá el nombre de “Libera Regulador B”. Se
liberará el regulador “Tanque B.Regulator 2”.
Módulo “Dispose” del sensor B. En este módulo se deposita la entidad generada por el
módulo “Sensor” para finalizar la sucesión de eventos para llenar el Tanque B.
4. EJECUCIÓN DEL MODELO
En este paso se establecerán los parámetros del modelo, para su ejecución y análisis. En el menú
Run > Setup, en la pestaña “Project Parameters”, nómbrese al proyecto como “Mezcla”; en el
campo “Analyst Name” póngase el nombre de quien ha desarrollado el modelo; y en las casillas de
la colección de estadísticas (“Statistics Collection”) márquese, además de las predeterminadas, la
correspondiente a “Tanks”. El cuadro de diálogo se verá como el que sigue.
A-187
Paso seguido, selecciónese la pestaña “Replication Parameters”. Para la ésta ejecución sólo se
desarrollará una réplica, con una duración de 8 horas y las unidades de tiempo estarán en minutos.
Según los parámetros establecidos se simularan ochos horas de los ciclos de llenado y vaciado de
los tanques, esto no permitirá observar al “Sensor B” entrar en acción, sin embargo, puede
ejecutarse de nuevo el modelo con una duración de réplica más larga. La ventana correspondiente
a la pestaña lucirá tal como sigue.
A-188
En última instancia para poder apreciar la animación del movimiento de substancias a través de
tuberías, así como el llenado y el vaciado de los tanques, se hará otra modificación al cuadro de
diálogo “Run Setup”, esta vez en la pestaña “Run Speed”. Para que Arena no ejecute el período
del tiempo que permitiría observar las animaciones instantáneamente (lo que resultaría en una
especie de “salto” de las animaciones), se seleccionará la casilla “Update Simulation Time Every”, y
el campo con el nombre “Time Units” escríbase la cantidad 0.01, esto permitirá apreciar la
animación sin cambiar la velocidad de la simulación. La ventana de la pestaña lucirá como la que
sigue.
5. ANÁLISIS DE REPORTES
El enfoque de esta sección será en el análisis exclusivo del reporte “Tank” generado, éste es muy
sencillo, básicamente se refiere a la utilización del los tanques: “Mezcla”, “Tanque A” y “Tanque B”.
El reporte se divide en tres secciones:
“Level”. Proporciona tres datos para los tres tanques: el nivel de contenido promedio
(“Average”), el nivel mínimo (“Minimum Value”) y el nivel máximo de contenido (“Maximum
Value”). Como se verá en el reporte el mayor nivel promedio fue el del Tanque B, lo que se
esperaba porque era el de mayor capacidad y no tenía mucha utilización, ya que sólo
demandaba 25 galones cada 90 minutos; al observar el reporte se nota que el Tanque B fue el
único que no alcanzó nivel de 0, esto porque la duración de la simulación no lo permitía;
además como era de esperarse la máxima cantidad de substancia es la capacidad máxima de
cada tanque.
“Total Quantity Added”. Esta sección reporta la cantidad total de substancia añadida a los
tanques, es decir, la cantidad de substancia que los respectivos sensores ordenan que se
añada a los tanques para llenarlos una vez se ha alcazado el límite establecido. Al observar
las cifras se puede constatar que el tanque “Mezcla” fue completamente llenado 5 veces(la
A-189
simulación se interumpio antes que se llenará las 6 veces), el “Tanque A” fue llenado tan sólo
una vez y el “Tanque B” ninguna.
“Total Quantity Removed”. Esta sección indica la cantidad de substancia que ha sido
removida de cada tanque. Se puede ver, como ya se había resaltado, que el tanque “Mezcla”
se vació 5 veces, que al “Tanque A” le fueron removidos 450 galones (capacidad para 300
galones) y al “Tanque B” se le removieron 125 galones de su capacidad total de 900 galones.
A-190
6. PROBLEMA PROPUESTO
1. Una comunidad obtiene su agua potable de un pozo común de con una capacidad 1000 litros.
La comunidad consta de 3 casas todas con demandas de agua diferentes, como sigue:
Casa A. Consume 5 litros cada vez que abre el grifo, y el comportamiento de grifo sigue una
distribución normal con una media de 2 horas y una desviación estándar de media hora.
Casa B. Consume de 13 a 18 litros con una distribución uniforme, cada 6 horas.
Casa C. Su consumo se comporta como una distribución triangular con los valores de (10,
15,20), cada 4 horas.
Modele las condiciones de la comunidad y determine durante cuánto tiempo se esperaría que el
contenido del pozo se agotará si el pozo estaba lleno al inicio del período.
Nota: Se debe asumir que todos los grifos abren por primera vez cuando inicia la
simulación y que solamente se abren un grifo por casa a la vez. Además para terminar la
simulación justo cuando ya el pozo esté vacío, constrúyase una expresión dentro del
campo “Terminating Condition” en el menú Run > Setup > Replication Parameters.