Formulario para Simulación Con Arena
Formulario para Simulación Con Arena
Formulario para Simulación Con Arena
ABC
Guía Laboratorio
SIS645
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ÓNUTILIZANDO 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
A1
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.
A2
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.
Luego de colocar el primer módulo, se continuará con los demás procesos del diagrama.
A3
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:
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.
A4
Una vez los dosmó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”.
A5
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.
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
A6
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:
A7
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.
A8
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.
A9
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.
A10
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.
A11
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: “2way 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 mism a 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.
A12
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.
Este módulo representa el procesamiento automático. Los parámetros se muestran en el diagrama
siguiente:
A13
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.
A14
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.
A15
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:
A16
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).
Luego aparecerá el cuadro de diálogo siguiente:
A17
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:
A18
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:
A19
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.
A20
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.
A21
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 quepor su naturaleza se ejecutarán con más de una réplica.
El periodo de calentamiento o Warmup 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.
A22
Para ejecutar la simulación, en la barra de menú se selecciona run > go, o simplemente dar clic en
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
A23
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.
A24
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.
A25
All entities : en este caso solamente existe una entidadque 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 valorde $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 costosde 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.
A26
En la pestaña de vista previa, se puede desplegar los diferentes reportes mostrados por C ategory
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.
A27
A28
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 ( NonValue Added ). En el ejemplo que se
desarrolla, ninguno de los procesos ha sido catalogado como NonVakue Added por lo que
en este campo aparece el valor de 0.
A29
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.
A30
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.
A31
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 lassecciones 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)).
A32
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).
A33
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.
A34
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.
herramientas estándar .
A35
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
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 seencargan 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.
A36
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:
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.
A37
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:
A38
Para el módulo Create 1:
Para el módulo Create 2:
Para el Módulo Create 3:
A39
Una vez se ha terminado de definir cada módulo, la ventana del submodelo se debe observar de la
siguiente manera:
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:
A40
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.
A41
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:
A42
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:
A43
Para el proceso de recepción de vehículos livianos:
Para el proceso de recepción de motocicletas:
A44
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.
A45
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:
A46
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ánicosestá asignado a unproceso determinadoyque para procesar unvehí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:
A47
Para el proceso de entrega de vehículos liviano:
Para el proceso de entrega de motocicletas:
A48
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í:
A49
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.
Una vez definidos estos parámetros, dar clic en Aceptar para guardar los cambias.
A50
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.
A51
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.
A52
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 universidadse 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:
A53
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:
A54
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:
A55
De la misma forma se definen los horarios de trabajo de los encargados:
A56
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
A57
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.
A58
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.
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
Utilizandoel 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:
A59
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.
A60
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
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.
A61
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.
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
A62
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.
5.9. IMPRIMIR Y SELLAR CREDENCIAL
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.
A63
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.
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).
A64
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.
A65
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.
A66
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.
A67
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.
A68
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 asignarnuevosvaloresa lasvariables, atributos,tiposdeentidad,
imagen de la entidad u otras variables del sistema.
3.2. ANIMACIÓN DE OBJETOS
A69
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
A70
5.1. CAMBIAR DE IMAGEN PREDETERMINADA
5.2. CAMBIAR IMAGEN DE LA ENTIDAD
La modificación del modelo de forma gráfica se aprecia de la siguiente manera:
A71
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.
A72
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.
A73
A74
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”.
A75
PRÁCTICA Nº 6
AJUSTE DE DATOS CON EL INPUT ANALYZER
1. OBJETIVO GENERAL
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.
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.
A76
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:
AndersonDarling, ChiCuadrada y la de KolmogorovSmirnov.
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:
A77
Luego, guardar el archivo para poder importarlo desde Arena. A continuación, abrir Arena y entrar
en la ventana del Input Analyzer.
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…
A78
Al buscar el documento de bloc de notas, Arena despliega un histograma y los parámetros
correspondientes a dichos datos.
A79
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.
A80
A81
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.
A82
2. Determinar si los siguientes datos de fractura de un bloque de cemento siguen una distribución
de Weibull.
A83
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”).
A84
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.
A85
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.
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 submodelo se simulará la llegada de bandejas grandes de 10 panes al
horno, así como las variaciones de temperatura dentro del mismo.
Empaquetado: otro submodelo 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:
A86
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 pan1, salado y el tipo de pan 2, dulce, luego se arrastra la celda hasta simular 100
datos.
A87
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”:
A88
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 972003)
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.
A89
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”:
A90
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.
A91
A continuación se agregaran dos submodelos, uno para el horno y uno para el empaquetado, los
cuales serán editados más adelante; para agregar un submodelo 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
A92
repartidor. Los submodelos y el módulo hold deberán quedar conectados de la siguiente
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.
A93
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:
A94
A95
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í:
A96
Para el Dispose:
5.2. HORNO
Para simular el horno, se dará doble clic en el primer submodelo, (para cambiar nombre solamente
se debe dar clic derecho al submodelo > propierties > Submodel Name : Horno).
A97
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:
A98
A99
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”:
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:
A100
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”.
A101
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:
5.4. REPARTIDORES
A continuación se procederá a simular las llegadas de los repartidores, este puede hacersejunto al
modelo general, ya que será otro modelo independiente, pero relacionado.
A102
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.
A103
El módulo Dispose representa la partida de los repartidores:
Al final el modelo deberá verse de la siguiente manera:
A104
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)
A105
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.
A106
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.
A107
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.
A108
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
A109
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 examinaro 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 A lt+ 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:
A110
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 unacolecció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:
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 mo delo
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)
A111
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 sehan 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 carga r
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 subeventos 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.
A112
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:
A113
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 debeacceder 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:
A114
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:
A115
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.
A116
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 dobleclick 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 dobleclick se deberá escribir el código siguiente:
Private Sub CommandButton1_Click()
Dim m As Model
Dim Modulo As Module
Dim i As Long
A117
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):
A118
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”.
A119
4.4.2. PROPIEDADES DEL FORMULARIO.
Cuando se crea un formulario se tiene la opción de modificar su formato segúnconvenga 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.
A120
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”.
A121
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”.
A122
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
A123
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
Al hacer dichas selecciones la primera línea del código será automáticamente escrita,
compleméntese el código como aparece en seguida:
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
EndFunction
Cuando se haya introducido el código VBA la pantalla del editor se verá de ésta manera (véase
comentarios aclaratorios en verde):
A124
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”.
A125
5. EJERCICIOS PROPUESTOS
1. Modifíquese el modelo presentado en la guía de manera que el valor introducido enel
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 unaexpresión de tipo “UserFunction” (utilizandocomo base la estudiada enla 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.
A126
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.
A127
Ventana de diseño
Barra de
elementos
Panel de propiedades
Para ejecutar una animación en Arena 3DPlayer se necesitan dos tipos de archivos, un Playback y
un Layout. Un Playbackes 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.
A128
Se desea simular este proceso para 10 días.
5. PASOS PARA CREAR EL MODELO EN 3D.
a. Crear el modelo a simular.
El modelo a simular debe quedar de la siguiente manera:
A129
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:
A130
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:
A131
Route 1
Route 2
Route 3
A132
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.
A133
Entrega de orden al cliente.
A134
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 3D, se modificará la imagen asignada a la entidad. Se
utilizará la imagen con el nombre de Pinture.Van en el menú de Entity.
A135
b. Generar el Playback.
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.
A136
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.
A137
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.
A138
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:
A139
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:
A140
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.
A141
El último paso es definir las rutas por las cuales se moverán las entidades a través del sistema. Dar
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.
A142
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.
A143
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.
A144
PRÁCTICA Nº 10
ANÁLISIS DE ALTERNATIVAS: OUTPUT ANALYZER Y PROCESS ANALYZER.
1. OBJETIVO GENERAL
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.
A145
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:
A146
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.
Departamento de Departamento de
Alternativa
aprobación desembolso
Pablo
1 Imelda Juan
Salvador
Imelda Juan
2
Pablo 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.
A147
Para crear los S et 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:
Para el Set 1:
Para el Set 2:
Una vez definidos los Set, se comenzará a definir cada uno de los módulos.
A148
Para el módulo Create:
El módulo Process 1 el cual tendrá el Practicante, queda definido de la siguiente forma:
A149
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:
A150
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:
A151
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.
A152
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:
Una vez definidas las expresiones, la ventana de Statistic queda de la siguiente manera:
A153
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:
A154
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.
A155
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:
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.
A156
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 archivosdiferentes 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.
A157
A158
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.
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.
A159
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.
A160
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 elnú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.
A161
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.
A162
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.
A163
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.
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
A164
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.
A165
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 de65 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”.
A166
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 proces o 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.
A167
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.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 desimulació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
A168
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 pa ntalla, con su respectivo “tanque” a la izquierda del módulo. La hoja de trabajo lucirá de
ésta manera:
A169
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)
A170
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:
A171
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
A172
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 estasecciónse añadirá la animacióncorrespondiente a lastuberías, que unenlostanquesde
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
A173
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álogode la siguiente manera:
A174
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:
A175
“Expression Builder”
“Level”
A176
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 s e 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:
A177
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.
A178
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
12. Como siguiente paso se duplicará la línea de lógica del modelo recién creado.
A179
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.
A180
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í:
A181
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.
A182
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.
A183
Primer módulo “ Delay”. Éste es el módulo que simulará la espera de 20 minutos, como tal
se nombrará “Espera 20 minutos”.
A184
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.
El campo “ Location Type”, indica el criterio que seguirá el módulo para percibir cuand o 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.
A185
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 sens or 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 desarr ollado 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.
A186
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 ta nques, 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.
A187
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
A188
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.
A189
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, yel 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.
A190
Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.
Alternative Proxies: